Docs / Architecture
Architecture
The CLI prepares your code. Enclaves review, build, and run it. Provers check the evidence, and contracts on Base record the results.
How it is built
The CLI
Runs on your machine. It hashes your code, checks that the reviewer is running an approved release, and encrypts the code to that reviewer’s key. Nothing else ever sees the plaintext. Later, it runs the deployment through your own Azure login.
The enclaves
Azure confidential containers. Epoche runs the reviewer and the builder. You run the loader in your own Azure subscription. Each one makes fresh keys when it boots, and Azure signs a statement of what is running plus those keys. The reviewer reads the code and signs a receipt. The builder turns the code into an image and signs a record of it. The loader fetches the image, checks its hash, and runs it.
The provers
Two RISC Zero programs, run on the Boundless proving market. One checks an Azure attestation and publishes the measurement and the enclave’s fresh signing and encryption keys. The other checks, in private, that a review receipt and a build record describe the same code, and publishes only the hashes. A relayer wallet posts each proof to Base.
The chain
Four contracts on Base. One holds enclave signing keys, each valid for thirty days. One holds the approved reviewer, builder, and loader releases. One records review receipts and says whether each is still good. One admits an image once it has a valid proof and records the runtime key you authorize. Anyone can read all of it with an RPC and the open-source verifier.
Inside an enclave
An enclave is a virtual machine whose memory is encrypted by the CPU. The host, the cloud provider, and Epoche cannot read what runs inside it. Epoche uses Azure confidential containers, which run on AMD SEV-SNP hardware.
We use one because the reviewer has to read your code, and you should not have to trust whoever runs the reviewer. The hardware does two things that make that possible. It keeps the memory sealed, and it can measure what is running and sign a statement about it.
Each enclave is a container group with two containers: Epoche’s own code, which is open source, and Microsoft’s attestation sidecar. At boot the Epoche code makes a fresh signing key and a fresh encryption key and keeps them in memory only. The sidecar asks the CPU for a signed quote, attaches those keys, and sends it to Azure Attestation, which checks the quote and returns a signed JWT. The JWT carries the measurement, a hash of every image, command, and setting in the group, plus the two keys. Change anything that is measured and the hash changes, so it no longer matches an approved release.
That JWT is the enclave’s identity. Your CLI reads it before encrypting anything to the reviewer. A prover turns it into an on-chain registration of the signing key. The keys die with the container. The next boot makes new ones and attests again.
The loader is the enclave you run yourself. It has the same shape, but instead of reviewing code it fetches the Docker image the builder made from your reviewed code, checks that the image’s hash matches the one on Base, and starts it.
Follow the evidence
The trust chain explains how these components connect reviewed source to a running agent. Follow each stage: