Introducing Sona: Verifiable Transaction Infrastructure for Solana

In modern DeFi, almost every transaction you sign or send originates from some off-chain infrastructure. Keepers, bots, and API servers automate everything from liquidations to yield compounding.
But under the surface, there’s an unspoken assumption: that the off-chain code did what it claimed to do.

You can verify what’s on-chain — but not what built the transaction that put it there.
That’s the hidden trust layer of DeFi automation. And it’s a growing risk as more value — and institutional capital — moves on-chain.

Sona introduces a new layer of verifiable infrastructure for Solana: attested transaction generation.
Transactions are constructed inside AWS Nitro Enclaves, producing cryptographic attestations that prove exactly what code and inputs were used. Instead of trusting a server, you can now verify the builder.

1. The Hidden Trust Problem

Every yield router, liquidation bot, and automation service today depends on off-chain code to build transactions.
Even when that code is open source, once deployed, there’s no proof that the running binary matches the audited source.

As a result:

Users and funds rely on unverifiable transaction builders.
Protocol integrations often run on untrusted infrastructure.
Auditors and custodians can’t reproduce the execution environment.

This creates an invisible but critical trust gap — one that has kept many institutions on the sidelines.

2. The Core Idea: Attested Transaction Generation

Sona’s architecture eliminates that gap.

When a transaction is created through Sona, it’s built inside an attested, sealed enclave — a trusted execution environment provided by AWS Nitro Enclaves.
Each enclave produces an attestation document, cryptographically signed by AWS, proving:

The enclave’s image and configuration (hash-verified).
The code that generated the transaction.
A nonce binding the proof to a specific request.

The result: a Solana transaction, plus a verifiable attestation that proves how it was built.

Developers, protocols, auditors, and even end users can verify this attestation independently — locally or through AWS’ public attestation service.

📊 Diagram: Concept overview

Show: user/client → Sona enclave (builds transaction) → attestation proof → Solana network.
Annotate: “verifiable code + inputs → signed transaction + proof”.

3. System Overview

Sona consists of three primary layers:

a. Enclave Layer

Each transaction builder runs inside an AWS Nitro Enclave.
It’s isolated from the network and the host OS — only capable of communicating through a secure local channel.
The enclave code is deterministic and open source, allowing anyone to reproduce the exact image hash that will later appear in attestation proofs.

This means protocol builders, the community, and independent security researchers can verify that the running code matches the published, audited version.
Once verified, any transaction produced by that enclave can be trusted to reflect that logic — not a modified binary.

b. Verification Layer

Every transaction produced by an enclave is accompanied by an attestation document.
The Verification Layer provides two main interfaces:

A public verifier API and CLI that validates the attestation against AWS’ root of trust.
A registry of approved enclave image hashes, linking each builder to its corresponding open-source commit or container digest.

This allows external validators, auditors, or institutional partners to confirm the provenance of any transaction before accepting or relaying it.

c. Client Layer (`@sona/sdk`)

Developers interact with Sona through a lightweight TypeScript SDK.
The SDK handles:

Serialization and secure API requests.
Attestation proof retrieval and optional local verification.
Transaction submission to the Solana RPC.

With one function call, developers can route user deposits or manage yield positions — without operating their own backend.

📊 Diagram: Layered architecture

Three stacked layers labeled “Client SDK”, “Verification Service”, “Enclave Builders”.
Show data flow arrows for “request → attested tx + proof → verification”.

4. Integration with Open Protocols

Sona integrates directly with existing Solana yield protocols such as Kamino, Marginfi, and Sanctum.
Each integration runs as a modular adapter inside the enclave — meaning the logic that interacts with these protocols is part of the attested code path.

Because these protocols are open source, their builders — and the community at large — can independently:

Audit the enclave source code.
Verify that the enclave’s image hash matches the published source.
Confirm that each transaction was generated using only the verified, open logic.

This creates a transparent, verifiable link between open-source protocol logic and real-world execution — a level of assurance not previously available in DeFi automation.

📊 Diagram: Protocol integration map

Show Sona enclave as central node connecting to Kamino, Marginfi, Sanctum logos.
Label arrows: “verified adapter logic (open source)”.

5. Example Flow

Let’s walk through a simple example — depositing into Kamino via Sona.

A client calls:

await sona.deposit({
  protocol: "kamino",
  amount: 100,
  wallet: userPublicKey,
});

The SDK sends a signed request to Sona’s enclave endpoint.
The enclave builds the transaction using Kamino’s verified adapter.
It generates an attestation document proving the enclave image, source hash, and nonce.

The response includes:

{
  "tx": "<base64>",
  "attestation": "<aws_document>",
  "enclaveId": "sona-kamino-2025-10",
}

The client can verify the attestation locally or via the public verifier API.
Once verified, the transaction is submitted to Solana RPC.

📊 Diagram: Flow sequence diagram

Show: Client → SDK → Enclave → Verifier → Solana RPC.
Annotate: “tx + attestation proof”.

6. Attestation Verification

An attestation document is a signed statement from AWS proving that a specific enclave image executed a request.
It contains:

PCR values: cryptographic measurements of the enclave code and configuration.
Public key & certificate chain: rooted in AWS’s attestation CA.
Nonce: binds the proof to a single request.

Verification can be done in two ways:

Local verification: SDK validates PCRs and signatures against a known image hash.
Remote verification: using Sona’s verification service, which checks proofs against AWS’s live attestation service.

Every attested enclave image is linked to a reproducible build artifact and Git commit.
That means anyone can rebuild the enclave and confirm that the resulting hash matches what’s running in production.

📊 Diagram: Attestation verification path

Show attestation doc structure (PCRs, hash, signature), arrows to “AWS root CA” and “Sona verifier”.

7. Security and Compliance Advantages

Sona introduces a new trust primitive for DeFi and institutional infrastructure:

Verifiable build provenance — the logic constructing a transaction is cryptographically proven.
Institutional reproducibility — auditors can rebuild the enclave and match its hash to proofs.
Key isolation — private keys never leave the enclave boundary.
Tamper resistance — host OS and IAM isolation limit compromise surface.
Open verification — proofs are publicly checkable, enabling third-party security research.

In effect, Sona replaces trust in an operator with verification of the system.

8. Roadmap

Public verifier API & CLI: release for independent attestation validation.
Open-source SDK: @sona/sdk with example integrations for Kamino, Marginfi, and Sanctum.
Builder image registry: public list of attested enclave hashes and their source commits.
Cross-chain extensions: adapting the Sona attestation pattern to other ecosystems.
Standardization: define an Attested Transaction Specification (ATS) for verifiable transaction generation across DeFi.

9. Closing Thoughts

Sona doesn’t replace existing protocols — it certifies how they’re accessed.
It turns transaction generation from a black box into a verifiable process, bringing cryptographic integrity to the last unverified step in DeFi.

By combining open-source protocol logic with attested execution, Sona enables a new standard of transparency — one where users, builders, and institutions can finally verify how a transaction was built, not just what it does.

We’re opening early access to protocol teams, auditors, and infrastructure partners who want to help define this standard.
If you’re building on Solana and care about verifiable automation, reach out or join the waitlist.

Would you like me to:

Add sample diagram sketches (ASCII or Mermaid) for each section,
or
Format this for your blog framework (e.g., Markdown/MDX with headings, code blocks, and diagram placeholders ready for Figma/SVG embeds)?