AES-1 defines what it means for a smart contract to be an enclave — an environment in which the operator has been architecturally excluded from execution outcomes after deployment.
The standard specifies five properties (P1–P5) and three certification tiers, culminating in the Sovereign Enclave: a deployment with both architectural finality and statutory recognition under a settlement-finality regime.
AES-1 is an open standard for certifying execution enclaves: smart contracts in which the operator has been architecturally excluded from execution outcomes after deployment. A contract that can be upgraded, paused, fee-tuned, or admin-overridden is not an enclave — it is a contract with a present operator.
The standard addresses what we call the Operator-Surface Problem: most contracts deployed today retain owner keys, upgrade slots, migration paths, and admin functions. A counterparty engaging with such a contract — or with an agent acting through it — cannot know whether the operator will alter the outcome after commitment. AES-1 specifies the architectural properties that, together, distinguish a true enclave from a contract that merely describes itself as one.
At its core AES-1 is a relationship between two parties — the operator deploys the contract and then exits; the participant engages on equal terms with every other participant. The five properties together close every architectural surface through which an operator could re-enter execution.
An execution enclave must satisfy all five properties to qualify. Each is independently verifiable from public chain data alone. The properties are conjunctive — partial compliance is not graded, it is not certified. Together they close every architectural surface through which an operator could re-enter execution after deployment.
The deployed bytecode is immutable. No proxy pattern, upgrade key, migration function, or selfdestruct path through which the code can be modified or replaced — including by the deploying address.
No discretionary-call surface through which a privileged address can alter outcomes, redirect assets, or selectively suspend execution. A symmetric, one-way statutory halt triggered exclusively by attested external conditions is permitted within constraints.
Verified by: source / ABI review + halt-trigger inspectionAll execution paths fully specified at deployment. Identical inputs produce identical outputs. No operator-modifiable parameters on the execution path; no probabilistic state that could be steered post-hoc.
Verified by: formal verificationEqual callable access to all eligible participants. No operator-controlled allow-lists, deny-lists, or asymmetric access. Participation gated only by economic preconditions any party may satisfy on identical terms.
Verified by: interface and modifier reviewP1–P4 are checkable by any third party from public chain data alone, without reliance on operator disclosure. An enclave claim that cannot be independently re-verified is not an enclave claim — it is an assertion.
Verified by: block explorer + verified sourceAll three tiers require satisfaction of the five core properties. Tiers differ in the level of independent verification and the legal status that attaches. Tier III is the convergence of architectural and statutory finality — the Sovereign Enclave.
// Verifying an AES-1 Enclave Certificate const cert = await aes1.fetch(contractAddress); const deployer = await ais1.resolve(cert.issuer.selfAttestation.aisBondRef); // 1. Recompute canonical hash and verify on-chain anchor const hash = keccak256(JCS.canonicalise(cert)); assert(hash === cert.anchor.certificateHash); // 2. Verify P1-P5 — all five required for (const p of ['P1', 'P2', 'P3', 'P4', 'P5']) { assert(cert.properties[p].satisfied === true); } // 3. Tier-specific evidence if (cert.tier.level === 'III') { assert(cert.issuer.auditor); // independent audit assert(cert.issuer.legalOpinion); // qualified counsel assert(cert.tier.jurisdiction); // settlement-finality regime }
Specification, Enclave Certificate JSON Schema, generic Tier III worked example, and the open-stack composition published under CC0. Open for public comment until 30 June 2026.
Automated P1–P5 verification toolchain. AES-1 Registry deployed on Ethereum, Arbitrum One, and Base. First Tier I and Tier II certifications issued.
Tier III framework finalised. Settlement-finality integration documented. Formal legal-opinion template published. Multi-chain extensions to non-EVM environments.
Submission to IEEE, ISO, and IETF. Full public registry. Automated certification pipeline. Multi-jurisdictional recognition framework. First Tier III Sovereign Enclave certified under an enacted settlement-finality regime.
The full technical working paper. Motivation, definitions, the operator-exclusion principle, the five properties (P1–P5), Enclave Certificate schema, three-tier classification, AIS-1 binding, settlement-finality integration, security and regulatory considerations.
JSON Schema 2020-12 for the Enclave Certificate. Required and optional fields, per-property attestations, tier-specific issuer requirements (auditor at Tier II, legal opinion at Tier III), evidence array, on-chain anchor.
An illustrative Sovereign Enclave Certificate showing a generic Tier III deployment: per-property attestations, audit and legal-opinion CIDs, halt-trigger list, and on-chain anchor.
The canonical AES-1 repository. Specification, schema, examples, lifecycle and anchoring docs, interop documentation, CONTRIBUTING guide, and the GitHub Actions workflow that validates every PR against the schema.
The identity layer AES-1 binds to. Every Enclave Certificate references an AIS-1 bond for the deploying party. At Tier II, the auditor's AIS-1 bond is required. At Tier III, counsel issuing the legal opinion must also be AIS-1-bonded.
The audit-record layer that runs above AES-1. AAS-1 records produced within a certified enclave reference the Enclave Certificate — a relying party reading the audit trail can immediately see the architectural posture of the execution environment.
Feedback is invited from smart-contract developers and auditors, AI agent developers, blockchain engineers, legal and regulatory professionals, institutional participants in digital-asset markets, standards organisations, and government bodies. The comment period closes 30 June 2026. A revised v0.2 will incorporate substantive feedback.
Technical review of the five-property framework · edge-case feedback on the § 4.2.1 Statutory Halt constraints · feedback on governance mechanisms, oracle dependencies and multi-sig configurations · regulatory perspectives on the settlement-finality framing in § 9 · real-world deployment use cases and Tier I / Tier II certification candidates · tooling proposals for the automated P1–P5 verification toolchain.