Trust chain

From source to a running agent

Each stage connects its evidence to the previous stage by hash. The review names the source code. The build record connects that code to an image. The deployment connects that image to a signing key. A live check asks the agent to prove it holds that key.

Sealed and open deployments

A sealed deployment follows the full chain below: private source goes through review, an enclave builds the image, and Base records the evidence before the loader can run it.

An open deployment runs public code without requiring a review first. Its evidence connects the source to an approved loader and a live signing key. It skips sealed-image admission and starts uncertified. You can add a review later with epoche certify.

These are deployment choices. They are separate from the investor tracks, which describe how investors participate and which account controls a strategy needs.

Why trust the reviewer

The reviewer reads your code, so you need a reason to trust it that does not depend on trusting Epoche. The reviewer’s code is public. Anyone can read it and build the same Docker image. When that image starts inside an enclave, Azure measures it and signs the result, along with the fresh keys the enclave just made. A prover checks Azure’s signature and records the signing key on Base for thirty days, tied to the approved version of the reviewer.

Register a review on chain

For a sealed deployment, this is what happens when you submit code. Your CLI encrypts it and sends it to the reviewer enclave. The reviewer reads it and signs a receipt. A builder enclave then builds the same code into a Docker image and signs a record with the hash of the image and the hash of the code. A prover checks, without revealing either document, that the receipt and the record are about the same code. Two things get written to Base: the review, and the image it belongs to.

Prove your endpoint runs the verified code

For a sealed deployment, this is what happens when you deploy. The CLI starts Epoche’s loader in your own Azure account, with a config that says which of your images it should run. Azure measures the loader and signs a JWT with the fresh keys it made. The loader shows that JWT to Epoche and gets the key that unlocks your Docker image. It checks the image’s hash against the one on Base, then starts it. A prover checks the JWT and records the loader’s signing key on Base. You then sign a short message with your review key that says this signing key belongs to your image.

Where trust remains

Check the running agent

Recorded evidence connects the stages, but you still need to check the endpoint you are about to use. Verify a running agent explains that check. What it proves defines the scope and limits of each result.

For the SDK example, see checking an open deployment.

For missing or mismatched evidence, see when verification fails.