Technical Details

Architecture Diagram

+-------------------------------+
|         User / dApp           |
+-------------------------------+
                |
                | (1) Input Task
                v
+----------------------------------------------+
|           TEE-Backed Nada Agent              |
|----------------------------------------------|
|  Confidential Runtime:                        |
|  - Agent logic                                |
|  - Private models (LLMs, ML, rules)           |
|  - Secure key-store                           |
|  - Context tracing + attention proofs         |
|  - Attestation API                            |
+----------------------------------------------+
                |
                | (2) Execution Receipt
                v
+----------------------------------------------+
|              Nada Verifier (SVM Program)     |
|  - Vendor signature checks                    |
|  - Measurement validation                     |
|  - Output signature validation                |
|  - Context proof verification                 |
|  - Replay protection                          |
+----------------------------------------------+
                |
                | (3) Verified State Transition
                v
+------------------------------+
|        SVM Blockchain        |
+------------------------------+

---

Execution Flow

Step 1 – User Submits a Task

A user or smart contract provides a structured request:

{
  "task": "compute_something",
  "input": <private_data>,
  "context": ["...", "...", "..."],
  "agent_version": "model_v3"
}

The request is sent directly to the TEE agent—never on-chain.

---

Step 2 – The Agent Executes in the TEE

Inside the TEE:

1. The agent loads its verified binary.

2. The enclave measures itself (computes SHA-256 hash of binary).

3. The enclave loads private weights, tools, state.

4. The input is processed with full confidentiality.

5. The agent generates:

   • output

   • output hash

   • context provenance proofs

   • optional attention-check proofs

   • signature by enclave-bound key

---

Enclave-Bound Keys

Inside each agent enclave:

• A private key is generated:

  agent_sk ∈ enclave hardware

• It never leaves the enclave.

• The corresponding public key is included in the attestation.

This binds:

• the agent identity

• the execution environment

• the measurement

together cryptographically.

---

Context Provenance & Merkleization

To prove what context/model inputs the agent used, the agent SDK:

1. Hashes each context chunk.

2. Constructs a Merkle tree.

3. Uses Merkle proofs to show which items were used during inference.

This prevents:

• hallucinations

• unauthorized context injection

• tampering or replacement

Example:

Root = H( L1 || L2 || L3 || L4 )

Proof includes:
- Leaf used
- Neighbor hashes

---

Execution Receipt Format

The TEE returns a self-contained, verifiable proof called the Execution Receipt:

pub struct ExecutionReceipt {
    pub measurement: [u8; 32],        // Hash of enclave binary
    pub agent_pubkey: [u8; 32],       // Enclave-bound public key
    pub output_hash: [u8; 32],        // SHA-256(output)
    pub context_proofs: Vec<MerkleProof>,
    pub attention_proofs: Option<AttentionEvidence>,
    pub timestamp: u64,
    pub raw_attestation: Vec<u8>,     // Vendor-signed attestation
    pub output_signature: Vec<u8>,    // Signed by enclave SK
}

---

Example: Agent Execution Pseudocode

fn handle_request(req: Request) -> ExecutionReceipt {
    let bin_hash = measure_enclave(); // hash of binary
    let output = run_agent(req);
    let output_hash = sha256(&output);

    let ctx_proofs = build_context_proofs(&req.context);

    let att = hardware::get_attestation(bin_hash, agent_pubkey());

    let sig = sign_with_enclave(&output_hash);

    ExecutionReceipt {
        measurement: bin_hash,
        agent_pubkey: agent_pubkey(),
        output_hash,
        context_proofs: ctx_proofs,
        attention_proofs: None,
        timestamp: now(),
        raw_attestation: att,
        output_signature: sig,
    }
}

---

Step 3 – On-Chain Verification

The SVM program calls the Nada verification library:

nada::verify(receipt)?;

This runs:

• Vendor signature validation

• Measurement (binary hash) validation

• Output signature verification

• Context-proof validation

• Replay prevention

If and only if all checks succeed:

The result is accepted as authenticated and originating from a genuine TEE running trusted code.

---

Security Guarantees

Confidentiality

Only the enclave sees the input, code, intermediate state.

Integrity

The result is authenticated by enclave-bound keys.

Execution Authenticity

Measurement + attestation prove exactly what code ran.

Verifiability

SVM programs can trust results without seeing raw data.