Architecture
TEE execution & evidence
How isolated execution, signed receipts, and durable evidence make model calls independently auditable.The enclave boundary
Provider credentials and the execution signing key stay inside.
Bounded ingress and allowlisted egress.
Authenticated TLS exchange terminates inside.
Receive content-addressed execution evidence.
Receives the signed receipt, never the key.
The Nitro enclave holds provider credentials and the non-exportable execution signing key. Its parent process only bridges bounded vsock ingress and destination-allowlisted egress; provider and archive TLS terminate inside the enclave, while the servicer receives only the signed receipt.
- No network interface: parent loopback ingress is bridged to enclave vsock.
- Outbound traffic is destination-allowlisted; provider and archive TLS terminates inside the enclave.
- Provider and archive credentials arrive through a one-time bootstrap channel and are not baked into the EIF.
- The Ed25519 execution key is generated inside enclave memory and never crosses the boundary.
- The enclave has no EVM, Native Chain, PostgreSQL, or validator credentials.
Registration proves identity and policy
The executor asks the Nitro Secure Module for a COSE_Sign1 attestation containing a fresh nonce, the execution public key, governed PCR measurements, and owner-bound user data. A signature over the registration message proves possession of the same private key.
Independent observers validate the P-384 COSE signature, AWS X.509 chain, freshness, nonce, key binding, module identity, owner, and active PCR0/1/2 policy before Native Chain commits teeKeyId. Observer startup requires an explicit development, test, or production environment and requires Nitro evidence by default; only an exact development/test synthetic flag can disable verification, and production rejects that flag. Governed live-network mode independently rejects an empty attestation document in consensus. Governance, observers, and registration validation reject any all-zero SHA-384 PCR bank, including debug-enclave measurements. The registration deliberately contains no validator-set commitment.
Bounded execution path
- Reconstruct the complete request and reject any inputHash mismatch.
- Enforce the selected model, provider, output schema, time limit, and consensus-authenticated assignment provider-cost ceiling.
- Call the allowlisted provider with a compact output contract and bounded completion tokens.
- Authenticate provider usage and cost; normalize the output into the selected schema.
- Hash and archive the complete request/response exchange to the required replica count; preserve a completed provider result across archive retries so one assignment cannot incur duplicate provider charges.
- Sign a canonical receipt that includes the assignment provider-cost ceiling and return it to the servicer for Native Chain submission.
Canonical receipt
The signed payload is a deterministic JSON array, not an unordered object. It covers identity, input, output, usage, actual provider cost, the assignment-bound maximum provider cost, evidence, nonce, key, and timing fields. The signature algorithm is Ed25519 over SHA-256 of those canonical bytes.
Verifiable only when attested work and protocol acceptance agree.
Binds provider exchange, typed output, usage, cost, nonce, and key.
Proves assignment, timeliness, uniqueness, and payment eligibility.
Lets readers verify the request and response against receipt hashes.
Shows the matching domain accepted the final payment effect.
| Field family | Bound evidence |
|---|---|
| Identity | executionId, requestId, inputHash, model, provider |
| Outcome | status, output, outputHash |
| Usage | promptTokens, completionTokens, costMicros, maxProviderCostMicros |
| Exchange | providerRequestHash, providerResponseHash, archiveId |
| Freshness | executionNonce, startedAtMs, completedAtMs |
| Attestation | teeKeyId plus signed public key |
One assignment means one provider attempt
An execution ID is consumed by its first provider attempt and retained for the lifetime of the enclave execution key. Repeated calls return the exact signed result or the same terminal error. The parent has no release or eviction authority; even a valid executor bearer token cannot cause another inference. Archive failures may retry only archival and receipt signing from the immutable cached request and provider result.
Replay capacity intentionally fails closed. Completed and failed execution IDs remain attached to a live key unless an enclave-verifiable Native Chain terminal certificate permits cleanup. If the bounded replay table fills, operators drain assignments and rotate to a newly attested key; silently evicting entries would re-enable result grinding.
Evidence survives the enclave
Archive IDs use sha256:<digest>. The executor writes its local content-addressed copy and requires configured independent replicas before treating evidence as durable. The API evidence endpoint retrieves the object and verifies its integrity. Hashes in the receipt let any reader detect modification.