# Secret Zone > Confidential compute on a public chain. Secret Zone runs each program inside its own confidential virtual machine (CVM), protected by Intel TDX or AMD SEV, and keeps its data encrypted. Secret Zone (secret.zone) shows confidential programs on Secret's L1 chain and the roadmap to build them. This file is the site's full text, generated from the same source as the interactive Roadmap drawing. ## Products - **Secret Router**: A confidential agent router, being prototyped by the Secret³.dev team. It routes a person's AI agents across machines and accounts. They share memory and a job board, so work carries on as tools and machines change, and each task goes to the agent best suited to it. - **Secret Wallet** (iPhone and iPad app): Secret Wallet is the iPhone and iPad app. It holds the user's account key, seals transfers and balance views to the money program, and shows a transfer as sent once the money program confirms it. - **Secret.Zone**: Confidential compute on a public chain. Secret Zone runs each program inside its own confidential virtual machine (CVM), protected by Intel TDX or AMD SEV, and keeps its data encrypted. - **Secret Market**: A trading pool with a constant-product price curve. The first version answers price quotes, and checks its own math a second way before replying. - **Secret Bucket** ## Roadmap: the architecture The Roadmap is drawn as a stack of levels, from the chain at the bottom to people at the top, plus outside services. Each part is marked with its stage: Ready, Live on alphanet, or Next. ### Outside services Services the zone works with: Cloudflare and Let's Encrypt for certificates, Intel's attestation service for TDX, Base nodes for USDC deposits, Secret mainnet endpoints and an identity-verification provider for claims, and an email provider for reset codes. #### Intel PCS *TDX collateral* · stage: Outside service Intel's provisioning service. It publishes the signed collateral used to verify TDX quotes and says which platform versions are up to date. Anyone may relay that collateral to the chain. Holds: Intel-signed collateral. Talks to: x/pccs (relayed in a transaction). #### Cloudflare DNS *DNS* · stage: Outside service DNS for secret.express, with a wildcard record and no proxying. The edge's DNS token proves control of the domain to get its wildcard certificate. Holds: The secret.express DNS zone. #### Let's Encrypt *certificates* · stage: Outside service Issues the wildcard certificate for *.secret.express and a certificate for each custom domain. Public certificates come from Let's Encrypt, not the key machines. #### Base nodes *USDC deposits* · stage: Outside service Dedicated Base nodes, run for the project rather than rented. The money program reads USDC deposits from them and credits a deposit once they agree with each other on a finalized block. Holds: Base chain data. #### Identity check *identity checks* · stage: Outside service An identity-verification provider used for claim checks. Larger claims also ask for proof of address and source of funds. Holds: Identity-check records. #### Mainnet endpoints *saToken balances* · stage: Outside service Dedicated endpoints for Secret's current mainnet. The remediation program reads saToken balances from them. Holds: Mainnet state. #### Email provider *reset codes* · stage: Outside service The email provider Accounts uses to send password-reset codes. Holds: Outgoing mail. ### People and clients Browsers on secret.zone, the Secret Wallet app for iPhone and iPad, GitHub and the host operators. They reach programs through the edge; the programs behind it have no public address of their own. #### Browser canvas *the secret.zone screens* · stage: Ready The secret.zone web app (alpha.secret.express on alphanet), with sign-in, Account, Site, App, Storage and Admin screens. It keeps a short-lived login permit tied to a browser key that is designed to stay in the browser. Relies on: Is built to use the Accounts encryption key when the key machines return matching copies. Trusts replies signed with Accounts' post-quantum key (ML-DSA). Holds: A non-exportable browser signing key and the signed short-lived permit, kept in browser storage. The password is not stored. Talks to: Edge (HTTPS; login data sealed to Accounts); Key machine 1 (fetches the public half of the Accounts encryption key); Key machine 2 (fetches the public half of the Accounts encryption key). #### Secret Wallet *iPhone and iPad app* · stage: Next Secret Wallet is the iPhone and iPad app. It holds the user's account key, seals transfers and balance views to the money program, and shows a transfer as sent once the money program confirms it. Relies on: Is built to accept the money program's signed answer once it says confirmed and several independent chain nodes agree on the active writer named on chain. Holds: The account private key, a view permit tied to a non-exportable device key, and a passkey tied to the live domain. Talks to: Edge (sends sealed requests to the money site); Key machine 1 (fetches the public half of money's encryption key); Key machine 2 (fetches the public half of money's encryption key); Validators (asks several nodes which writer is active); x/vault (locks coins into the money vault). #### GitHub *webhooks, public source* · stage: Outside service Sends a notice to the Scheduler through the edge whenever a connected repository gets a push. It also serves the public source code the Builder downloads. Holds: A per-repository secret, created by Accounts, that signs each push notice. Talks to: Edge (sends push notices to the Scheduler's address). #### Operator *runs the host, holds a seat* · stage: Outside service A validator who holds a public seat and runs an Intel TDX host. Confirms each operator step and accepts or declines requests to run programs. The design gives operators no path to user data or keys. Holds: The validator account key, kept off the host. A separate operator key on the host with limited permissions granted by the validator account. Talks to: Operator CLI (confirms each step); x/host (confirms its public seat). ### The edge The zone's public front door, itself a confidential program. It handles public TLS, limits request rates and forwards to programs whose attestation it has checked. Logins, transfers and balance views are sealed end to end, designed to pass through the edge unread. #### Edge *the public entry point* · stage: Ready The public entry point for Secret Zone. It handles the public TLS certificate, routes by host name and path, limits request rates, and forwards to programs that have passed the attestation check. Relies on: Checks each peer's attestation quote on every connection. Reads the chain's record of the active writer through its own chain check. Is built not to read Site's or Accounts' data. Holds: Its own boot and identity keys, a DNS token for Cloudflare, and certificates for the zone and custom domains. It is designed to hold no user data, data keys or storage credentials. Talks to: Front proxy (the front proxy running inside it); Accounts; Site; Scheduler; Money program (the active writer named on chain); Remediation; App runner (user Apps); Secret Market; Chain RPC / LCD (checks which writer is active); Key machine 1; Key machine 2. #### Front proxy *TLS, routes, rate limits* · stage: Ready The open-source reverse proxy inside the edge. It handles TLS, picks where each request goes, spreads load, reloads routes and certificates live, and limits requests per source address. Relies on: The edge's own attestation check, which runs beside it. Holds: Certificates and certificate-renewal state in the edge's temporary storage, plus rate-limit counters. Talks to: Edge (the edge's attestation check); Let's Encrypt (requests certificates); Cloudflare DNS (proves control of the domain through DNS). ### Zone programs Each program runs in its own CVM, booted from an OS image that governance approved. Programs check their peers, verify the chain and encrypt their own data before storing it. Money runs under stricter rules than the rest. #### Accounts *users, logins, permits* · stage: Ready Accounts keeps users and their logins. It checks passwords with SRP, designed so the password does not reach the server, and handles passkeys, short-lived permits, wallet links, connected repos, build receipts, buckets and prepaid credit. Relies on: Takes the time from chain headers its own verifier has checked. Trusts peers after checking their attestation quotes. Trusts answers from Money once a chain checkpoint covers them. Holds: Its own encrypted log instead of a database. Its data, identity, encryption, boot and storage keys. A write lease from the chain: one active writer at a time, named on chain. Talks to: Edge (receives user requests); Scheduler (checks webhook signatures; reads job status); Builder (hands over the build command; receives the receipt); Site (answers whether a permit is valid); S3 store (stores its encrypted log); x/program (records the hash of its stored data); x/checkpoint (holds its write lease; posts checkpoints); Key machine 1 (fetches its keys); Key machine 2 (fetches its keys); Email provider (sends email). #### Site *static sites* · stage: Ready Site serves static websites. It records site names, keeps an index for each build and knows which build is live. It serves files by path and tells the edge which hostnames it serves. Relies on: Takes files from the Builder over an attested connection. Asks Accounts whether a permit is valid. Follows the Scheduler's latest job status and waits when it is unclear. Holds: Its encrypted log and files in storage, under its data key. Served files in memory. Its boot, identity and storage keys. Talks to: Edge (serves pages; sends its list of hostnames); Accounts (checks permits); Scheduler (reads job status); S3 store (stores its encrypted log and files); x/program (records the hash of its stored data). #### Scheduler *pushes become build jobs* · stage: Ready The Scheduler turns GitHub pushes into build jobs. Accounts verifies each webhook signature first. The Scheduler then logs the job, calls a ready Builder, and marks the job finished or stopped. Relies on: Relies on Accounts to verify each GitHub webhook signature. Takes the time from verified chain headers to apply a build time limit. Holds: Its encrypted job log. Its boot, identity and storage keys. Talks to: Edge (receives GitHub webhooks); Accounts (checks signatures; looks up receipts); Builder (starts a job); S3 store (stores its encrypted job log); x/program (records the hash of its stored data). #### Builder *a fresh CVM per build* · stage: Ready Each Builder runs a build in its own CVM. It clones a public repo at the pushed commit, runs the build command, sends the files to Site and a receipt to Accounts, and is then replaced. Relies on: Takes jobs from the Scheduler. Trusts the key machines for the public keys of Site and Accounts. Holds: Nothing that lasts: no log, no stored data and no storage key. Talks to: Scheduler (receives the job); Accounts (gets the build command; sends the receipt); Site (sends built files and their index); GitHub (clones the repo); Key machine 1 (gets public keys for Site and Accounts); Key machine 2 (gets public keys for Site and Accounts). #### Money program *the bank* · stage: Ready The bank of Secret Zone. It holds private balances of tokens deposited on the chain, applies private transfers, records withdrawals and signs regular checkpoints to the chain. One active writer at a time, named on chain, so balances can't be written twice; a standby can take over through the chain. Relies on: Trusts chain facts after its own verifier checks headers and proofs. Credits a USDC deposit on Base once several independent Base nodes agree it is final. Holds: Balances in memory as a cache. The money log in storage, encrypted under its own key. Its encryption and boot keys, and a short-lived post-quantum signing key for its write lease. Talks to: Edge (its incoming connection); Chain RPC / LCD (reads chain state); S3 store (stores the encrypted money log); x/checkpoint (holds its write lease; posts ticks and checkpoints); x/vault (reads deposits); x/program (records the hash of its stored data); Base nodes (watches USDC deposits); Key machine 1 (fetches its keys); Key machine 2 (fetches its keys). #### Remediation *saToken claims* · stage: Ready A claims program for current holders of eligible saTokens. It records claims, wallet proofs and identity-check tiers, and gives a surrender address for each claim. Payouts happen outside it. Relies on: Its own reads of the Secret mainnet. An identity-verification provider for identity checks. Admins through a key-bound login. Holds: A sealed claim log kept in storage. Read credentials, the identity provider's secret and surrender-address keys, released by the key machines. Talks to: Edge (public claims API; private admin access); Mainnet endpoints (reads mainnet balances); Identity check (identity checks); S3 store (stores the sealed claim log); Key machine 1 (fetches its keys); Key machine 2 (fetches its keys). #### App runner *runs user Apps* · stage: Next Runs user Apps. Each App gets its own CVM, booted from the runner image with the App's own container setup. Relies on: The key machines, which are built to release each App's keys to that App. Holds: Each App's disks and keys, kept separate per App. The App's settings, decrypted inside its VM. Talks to: Edge (routes App traffic; checks each VM regularly); S3 store (stores App data); x/program (records the hash of stored data); Key machine 1 (fetches App keys); Key machine 2 (fetches App keys). #### Secret Market *pool quotes* · stage: Next A trading pool with a constant-product price curve. The first version answers price quotes, and checks its own math a second way before replying. Relies on: The edge, which carries its traffic. Holds: Nothing in the quote version. Later, the pool reserves and liquidity-provider shares. Talks to: Edge (receives quote requests). #### Secret Router *a confidential agent router* · stage: Next A confidential agent router, being prototyped by the Secret³.dev team. It routes a person's AI agents across machines and accounts. They share memory and a job board, so work carries on as tools and machines change, and each task goes to the agent best suited to it. Relies on: Sign-in through Accounts, and the same attestation checks as every Zone program. Holds: The agents' shared memory, job board and notes. Secrets and raw output are meant to stay on the machines. #### Quote check *checks peer quotes* · stage: Ready Built into every program. Before answering a request, it checks the peer's TLS certificate and Intel TDX attestation quote, and confirms its measurements match those recorded on the chain. Relies on: Intel's certificate data and the approved measurements, both copied onto the chain and read through the chain verifier. Holds: Nothing. Connections continue once the checks pass. Talks to: Fork tool (reads verified chain facts); x/pccs (Intel certificate data); x/program (approved measurements); Key machine 1 (peer's public identity key); Key machine 2 (peer's public identity key). #### Fork tool *checks chain headers* · stage: Ready Each program's own chain verifier. It accepts a block header when enough known validators have signed it and it follows the last accepted header, then checks proofs of chain state against it. Relies on: The chain id, signing rules and validator keys built into its measured setup. It is designed not to rely on the host machine. Holds: The last accepted header and its height. The key machines also seal a minimum height to guard against rollback. Talks to: Chain RPC / LCD (fetches signed headers and proofs). #### Storage SDK *encrypts, writes to storage* · stage: Ready The library programs use to store data. It encrypts records before they leave the machine, writes them to storage, and records a hash of the stored data on the chain. Relies on: The hash recorded on the chain. Programs are built to check stored data against that hash before serving it. Holds: Recent unwritten records in memory. Storage credentials are kept out of the program's view. Talks to: S3 store (writes encrypted data); x/program (records the hash of stored data). ### Key machines and storage Independent key machines, run by separate operators, release a key when they agree and the chain's policy allows it. The S3-compatible store keeps encrypted data, not keys. #### Key machine 1 *releases its share of a key* · stage: Ready A key machine. It releases its share of a key after checking the caller's attestation quote and the chain's rules itself. A program's key forms from the shares of several independent key machines together. Relies on: Its own chain verifier and the minimum height it has sealed. The chain's current record of the key committee. Not outside APIs or webhooks. Holds: Its share of the committee's post-quantum signing key (ML-DSA), its own post-quantum decryption key (ML-KEM), wrapped program keys and its sealed height record. Talks to: Key machine 2 (creates keys together; confirms over attested TLS); Chain RPC / LCD (verifies chain headers); S3 store (reads program container setups); x/program (reads the committee and program versions); x/host (reads which machines may run what); x/pccs (Intel certificate data). #### Key machine 2 *its own share, checked apart* · stage: Ready Another key machine: same software, run by a separate operator on separate hardware. It checks everything on its own, and key machines are designed to release shares when they agree on the chain's history. Relies on: Its own chain verifier and the minimum height it has sealed. The chain's current record of the key committee. Holds: Its own share of the committee's post-quantum signing key, its own post-quantum decryption key (ML-KEM), wrapped program keys and its sealed height record. Talks to: Key machine 1 (creates keys together; confirms over attested TLS); Chain RPC / LCD (verifies chain headers); S3 store (reads program container setups); x/program (reads the committee and program versions); x/host (reads which machines may run what); x/pccs (Intel certificate data). #### Key-sharing library *shared key* · stage: Ready An in-house library for a post-quantum (ML-DSA) key split across the key machines. They create the key and sign with it together; it is designed so no machine holds the whole key. Relies on: The published research scheme and the ML-DSA standard (FIPS 204), at a pinned, audited version. Holds: Nothing itself. Talks to: Key machine 1 (holds a share); Key machine 2 (holds a share). #### S3 store *encrypted storage* · stage: Live on alphanet S3-compatible storage for every program's encrypted data, files and approved container setups. It is built to see ciphertext and hold no keys. Relies on: Nothing. Programs check its TLS certificate against a fingerprint built into their measured setup. Holds: Encrypted data layers, file blobs and container setups, filed per program. ### Host and operator tools The physical Intel TDX or AMD SEV servers and the operator tools that start CVMs, pass along transactions and keep their encrypted disks. Hosts are run by trusted infrastructure providers under compliance controls, and built so private data stays private even from them. #### TDX host server *the TDX server* · stage: Live on alphanet The physical Intel TDX server that runs the CVMs, operated by a trusted infrastructure provider. It starts them, carries traffic between them and stores their encrypted disks. It is designed so its operators don't see private data. Relies on: Its provider's compliance controls. The programs on it rely on hardware isolation (Intel TDX or AMD SEV) rather than on the host. Holds: Host files, the operator's account key, its firewall rules and an audit log. No program secrets or customer data. Talks to: dstack VMM (starts and manages CVMs through it); Intel QGS (asks it to sign attestation quotes); Operator CLI (runs the operator tool). #### Intel QGS *signs CVM quotes* · stage: Live on alphanet Intel's quote generation service on the host. It signs each CVM's attestation quote, the hardware-backed proof of what code the CVM runs, under the machine's Intel certificate. Relies on: Nothing. Its job is signing. Holds: No program secrets. Talks to: dstack VMM (receives quote requests from CVMs). #### dstack VMM *starts each CVM* · stage: Live on alphanet The dstack virtual machine manager. It starts each CVM from a verified image with the program's approved configuration. It is designed not to stop or restart a CVM on its own. Relies on: Nothing. Holds: The verified image store and the programs' read-only, integrity-checked volumes. Talks to: Intel QGS (passes quote requests); dstack OS image (boots it). #### dstack OS image *boots every program* · stage: Live on alphanet The dstack operating system image that boots every program. Governance records its fingerprint and measurements on chain, so anyone can check what a CVM booted. Relies on: Nothing. Holds: Measured settings: the chain id, consensus and key-service public keys, and fixed addresses. No secrets. #### Operator CLI *the operator's tool* · stage: Live on alphanet The operator's command-line tool on each host. It sets up the host, sends the operator's chain transactions, writes host files, launches and upgrades CVMs, and keeps an audit log. Relies on: Nothing. It is built so what it writes doesn't widen what a CVM accepts. Holds: The operator's account key, the host settings and the audit log. Talks to: Host files (writes the host files); dstack VMM (asks it to create CVMs); Chain RPC / LCD (reads chain state, sends operator transactions); x/host (registers the host and its placements); x/pccs (relays validators' compute keys); x/checkpoint (requests the writer lease for a program). #### Host files *plain config files* · stage: Ready Plain settings files on the host: chain and storage endpoints, program addresses and the front proxy's settings. They are not measured, so they are meant to hold addresses rather than anything that grants trust. Relies on: Nothing. Holds: Addresses and endpoints. No secrets. #### Alphanet tooling *operate alphanet* · stage: Live on alphanet Tested scripts that operate alphanet: backup, restore, health checks, the faucet, release builds, replay checks and governed upgrades. Relies on: Nothing. Holds: Snapshots, kept without seeds, master keys or sealed data. Talks to: Validators (upgrades and restores them); x/gov (submits software upgrade proposals); Intel PCS (reads the current Intel security level). ### The chain (L1 control plane) Secret's L1, built with the Cosmos SDK and CometBFT; on alphanet it runs as trinity-a. It runs no smart contracts. It admits programs and machines, holds locked coins, records each program's latest history and its active writer, and stores Intel's attestation data. #### Validators *order the blocks* · stage: Ready The machines that run the Secret L1 chain on CometBFT. They agree on the order of blocks and carry the money program's regular updates. They run no smart contracts and hold no application keys. Relies on: CometBFT consensus. Holds: Chain state and consensus keys. Earlier contract data stays as it is. Talks to: Chain RPC / LCD (serves the chain to programs). #### Chain RPC / LCD *chain access* · stage: Ready The chain access point programs use. It carries data, and programs check chain facts against consensus signatures themselves. Relies on: Nothing. Programs verify its answers. Holds: Nothing of its own. Talks to: Validators (reads blocks and state). #### x/program *who may run* · stage: Ready The chain's list of who may run. It records each program, its approved versions and the machines allowed to run it, plus OS image records, seat-holder votes and the key-service committee. Relies on: Nothing. Holds: Program and version records, image records, program proposals and votes, the key-service committee, and the list of coins that can be locked. Talks to: x/host (checks hosts and seats); x/gov (takes approvals from governance). #### x/host *hosts and seats* · stage: Ready Records hosts and seats. A seat is a public slot for a group of machines. It also tracks where customer programs are placed, run policies, run proofs and challenges, and the seat tax. Relies on: Nothing. Holds: Host, seat and placement records, run policies, run proofs and challenges, recent block hashes. Talks to: Staking + distribution (checks seat holders stay bonded, pays the seat tax); x/pccs (verifies machine quotes). #### x/vault *locked coins* · stage: Ready Gives each program a chain address holding locked coins. A user locks coins in; coins leave through a checkpoint's payout list once the totals are checked. It does not create or destroy coins. Relies on: Nothing. Holds: Vault balances, the lock sequence number and locks not yet processed. Talks to: Bank + IBC (moves the coins). #### x/checkpoint *progress and writer leases* · stage: Ready Keeps each program's progress: a frequent marker and a checkpoint. A lease names one active writer at a time on chain, so balances can't be written twice; a standby can take over through the chain. Checkpoints are what move vault coins. Relies on: Nothing. Holds: Each program's latest progress marker, latest checkpoint and writer lease (holder, machine and expiry). Talks to: x/program (checks the program and its machines); x/vault (pays out on checkpoints); x/pccs (verifies quotes on lease renewal); x/host (checks placements). #### x/pccs *Intel collateral* · stage: Ready Stores Intel's signed certificates and security levels, which anyone may upload, plus validators' post-quantum compute keys. Lets the chain verify attestation quotes in consensus, without web calls. Relies on: Intel's root certificate, set at the chain's start. Holds: Intel certificates and revocation lists, minimum security levels, an advisory allow-list and compute public keys. #### x/gov *governance* · stage: Ready Stake-weighted governance. It approves OS images, program versions, coins that can be locked, public seats, freezes and machine bans, and runs software upgrades. Relies on: Nothing. Holds: Proposals and votes. Talks to: x/program (approves images and versions); x/host (grants seats, bans machines). #### Staking + distribution *stake and rewards* · stage: Ready The standard Cosmos SDK modules for validators, staking, rewards and minting. Seats are tied to their holders staying staked. The seat tax is paid out through validator rewards. Relies on: Nothing. Holds: The validator set, delegations and rewards. Talks to: x/host (reports stake changes for seats). #### Bank + IBC *balances, IBC* · stage: Ready Standard balances and IBC transfers, the protocol for moving coins between Cosmos chains. Coins arriving over IBC land as public coins; locking them into a program is a separate step. Relies on: Nothing. Holds: Account and vault balances and coins held for IBC transfers. #### authz + feegrant *standard grants* · stage: Ready Standard permission grants. A program's creator lets the storage library record file fingerprints, and a validator lets its host's operator account send operator messages. Relies on: Nothing. Holds: Grants and fee allowances. Talks to: x/program (grants for recording file fingerprints); x/host (grants for operator messages). #### x/compute (earlier contracts) *earlier contracts, kept read-only* · stage: Ready The earlier smart contract module. Its data stays on chain, encrypted, and contract calls are switched off. The new chain does not run contracts. Relies on: Nothing. Holds: Earlier contract state, kept as is. ## Journeys Step-by-step paths a task takes across the stack. ### Sign in The browser proves its password with SRP, so the password is designed to stay in the browser. The edge passes the exchange along without reading it, and the browser signs its own short-lived permit. 1. Browser canvas → Key machine 1: Read the public half of Accounts' encryption key from a key machine. 2. Browser canvas → Key machine 2: Read the same key from another key machine and compare the copies before using it. 3. Browser canvas → Edge: Ask for the SRP challenge through the edge, sealed to Accounts' post-quantum key (ML-KEM). 4. Edge → Accounts: Pass the sealed request along over an attested connection; the edge is built not to read it. 5. Accounts → Browser canvas: Return the SRP challenge, signed with Accounts' post-quantum key and sealed to the browser. 6. Browser canvas → Accounts: Send the SRP proof; the password itself stays in the browser. 7. Accounts → Fork tool: Check the account is active, using the time from the latest verified chain header. 8. Browser canvas → Browser canvas: Sign a short-lived permit (name, email, program, chain, time) with the browser's own key. 9. Accounts → S3 store: Save a new browser's key in sealed storage before replying. 10. Browser canvas → Accounts: Show the permit with each later request; Accounts checks its signature, time window and revocation. ### Publish a site A push to a connected GitHub repository becomes a verified job. A fresh Builder machine builds it, Site stores the files, and the edge serves a preview until the build is promoted. 1. GitHub → Edge: Send a push notification (webhook) to the Scheduler's address. 2. Edge → Scheduler: Pass the notification along as is; the Scheduler checks it next. 3. Scheduler → Accounts: Check the webhook signature against the repository's stored secret, within a time limit. 4. Scheduler → x/program: Seal a job record in storage, record its hash on chain, then answer GitHub. 5. Scheduler → Builder: Hand the job (repository, commit, branch) to a Builder that is ready and waiting. 6. Builder → Accounts: Fetch the build command and output folder; the webhook secret stays with Accounts. 7. Builder → GitHub: Clone the public repository at that commit and run the build as an unprivileged user. 8. Builder → Site: Send the built files and an index, encrypted for Site. 9. Builder → Accounts: Send a receipt and power off; the host starts a fresh Builder and the job is marked finished. 10. Site → Edge: Give the edge the addresses to serve; the preview goes live, and promotion makes a build live. ### Send privately A sealed transfer travels through the edge to the active writer named on chain, so balances can't be written twice. It is stored as ciphertext and is confirmed once a checkpoint on the L1 covers it. 1. Secret Wallet → Key machine 1: Read the public half of the money program's encryption key from a key machine. 2. Secret Wallet → Key machine 2: Read the same key from another key machine and compare the copies before sealing. 3. Secret Wallet → Edge: Send the signed transfer through the edge, sealed to the money program's post-quantum key. 4. Edge → Money program: Look up the active writer named on chain and forward to it after checking its attestation. 5. Money program → S3 store: Confirm its writer lease is current, apply the transfer in order, and wait until it is sealed. 6. Money program → Secret Wallet: Reply "pending", signed with the program's keys and sealed to the wallet. 7. Money program → x/checkpoint: Post a fresh hash of its latest state, carried in validators' votes; no coins move. 8. Money program → x/checkpoint: Submit a checkpoint; the chain checks the lease and epoch, confirms totals balance, and records it. 9. Money program → Secret Wallet: Answer "confirmed" once an accepted checkpoint on chain covers the transfer. 10. Secret Wallet → Validators: Check that several endpoints agree on the writer and the signatures verify, then show sent. ### Release a key A starting program asks the key machines for its key. Each checks the attestation quote and the chain's policy independently and returns its share; the shares together open the disk. 1. Site → Key machine 1: Open a TLS session bound to its attestation quote and request its key at a chain height. 2. Site → Key machine 2: Send the same request to the other key machines; the key is built from several answers. 3. Key machine 1 → Chain RPC / LCD: Accept a fresh chain header that is newer than its saved minimum and signed by enough trusted keys. 4. Key machine 1 → x/pccs: Verify the TDX quote against Intel's collateral, proven from the chain's x/pccs module. 5. Key machine 1 → x/program: Check the measurements match an OS image and app configuration named on chain. 6. Key machine 1 → x/program: Check the program version is recent and active, and the key committee is live. 7. Key machine 1 → x/host: Check the program is placed on an active host seat, with stricter rules for money programs. 8. Key machine 1 → Site: Unwrap its own share of the stored key and return it, bound to the key label. 9. Key machine 2 → Site: Run the same checks independently and return its share, once the chain headers agree. 10. Site → Site: Combine the shares into the disk key and mount it, then start. ### Upgrade a program or image New code means a new measurement, named on chain. A new CVM starts beside the old one and receives the same keys, because keys follow the program rather than its code; then the old CVM retires. 1. Operator → dstack OS image: Start a build of the dstack OS image. 2. Operator CLI → dstack OS image: Verify the image hashes, record its measurements, and start a test machine. 3. x/gov → x/program: Register the new OS image and its expected measurements on chain through governance. 4. Operator → x/program: Add the new program version, with its configuration hash, to the chain. 5. Operator → S3 store: Publish the configuration to storage under the program's id. 6. Operator CLI → dstack VMM: Launch a new CVM with that configuration while the old one keeps running. 7. Money program → Key machine 1: Ask the key machines from the new CVM; the same keys return, tied to the program id. 8. Money program → S3 store: Load the same log from storage and check it against the latest checkpoint on chain. 9. Money program → x/checkpoint: Take over as writer for a new epoch through the chain once the previous lease ends. 10. Operator CLI → dstack VMM: Retire the old CVM once the new one is healthy; its version stays allowed for a while. ### Reading the chain Programs are designed to verify what the chain says rather than trust an endpoint. A built-in checker verifies block signatures against keys built into the program's image, and a Merkle proof ties each record to that block. 1. Money program → Fork tool: Ask for a chain fact, such as the current writer or a policy record, at a given height. 2. Fork tool → Chain RPC / LCD: Fetch each block's commit from the last accepted header up to that height. 3. Fork tool → Fork tool: Check each header continues the chain: same chain, next height, later time, linked to the previous hash. 4. Fork tool → Fork tool: Count signatures at the target height from the trusted keys and accept the header when there are enough. 5. Fork tool → Chain RPC / LCD: Ask the chain for the record together with a Merkle proof. 6. Fork tool → x/checkpoint: Verify the ICS-23 Merkle proof against the state hash in the accepted header. 7. Fork tool → Money program: Hand over the proven record, so the program acts on verified facts. ### Wrap and unwrap Coins are locked publicly in the program's vault and credited privately by the money program. They leave the vault through a checkpoint's payout list. 1. Secret Wallet → Bank + IBC: Complete a standard IBC transfer first, so the coins arrive as public coins. 2. Secret Wallet → x/vault: Lock coins in the program's vault; the public wrap counter goes up. 3. Money program → Fork tool: Look for the next wrap on chain and accept it once the chain check verifies it. 4. Money program → Money program: Credit the wrap's sender privately, once per wrap. 5. Secret Wallet → Money program: Request an unwrap through the edge, turning a private balance into a public payout. 6. Money program → S3 store: Seal the payout record in storage before submitting it. 7. Money program → x/checkpoint: Submit a checkpoint listing the payouts; the chain checks totals balance and the vault pays out. ### Add a host A validator receives a public seat, proves its machines with TDX attestation quotes, and accepts a placement. The operator tool then turns that chain state into host configuration and running CVMs. 1. x/gov → x/host: Pass a governance proposal granting a validator a public seat, with an expiry. 2. Operator → x/host: Confirm the seat from the validator's side. 3. Operator → authz + feegrant: Let the host's operator account act for the validator, with fees covered. 4. Operator CLI → x/pccs: Submit the machine's compute signing key, signed inside a CVM. 5. Operator CLI → x/host: Register the host and add each machine with a fresh TDX quote and signature. 6. Operator CLI → x/host: Set the run policy: which programs and configurations this host will run. 7. x/program → x/host: Propose a placement on this host after seat holders vote to bind a program. 8. Operator CLI → x/host: Accept the placement as host operator; setup begins after this. 9. Operator CLI → Host files: Read placements and run policy, then write the host's configuration, guest mounts and proxy settings. 10. Operator CLI → x/host: Launch the CVM and post its quote; proven uptime counts toward the seat fee. ### Upgrade alphanet Operator tooling builds a release candidate, rehearses it on a snapshot and runs a governed upgrade at an agreed height, with a snapshot kept so the chain can resume on the previous release. 1. Alphanet tooling → Alphanet tooling: Build the release candidate from a passing commit, with a record of the build. 2. Alphanet tooling → Validators: Rehearse the upgrade by running its migration on a copy of an earlier chain snapshot. 3. Alphanet tooling → x/gov: Propose the upgrade with its name, height and Intel's TCB evaluation number, then vote. 4. Validators → Validators: Pause the chain at the agreed height and take a snapshot. 5. Alphanet tooling → Validators: Install the new release and start it; the upgrade migrates state and runs no contracts. 6. Alphanet tooling → Validators: Confirm new blocks follow; otherwise resume from the snapshot on the previous release. ## How it is protected - Private work runs in sealed machines. Each program runs inside a CVM protected by Intel TDX or AMD SEV. The host starts and connects it but is designed to have no view inside, and production images are built without SSH, login or console access. - Approved code, checked by its peers. A program proves what it booted with an Intel-signed attestation, which has to match an OS image and program version approved on chain. Programs check each other's attestation before they talk, and accept chain facts only with validator signatures and a proof from the block. - Hosts are run by trusted infrastructure providers under compliance controls, and built to keep private data private even from their operators. Nothing a host writes is meant to widen what a program accepts. - Keys need independent agreement. Keys come from independent key machines run by separate operators. Each checks the program's attestation and the chain's policy before it helps, and no single machine is meant to hold a whole key. Secrets are kept out of images and host files. - Data leaves encrypted. Each program encrypts its data before it leaves its VM, so storage holds encrypted data. The chain records which stored version is the latest. - Logins and transfers are sealed end to end. The edge serves ordinary pages, while sign-ins, transfers and balance views are sealed with post-quantum encryption (ML-KEM) for the program they are meant for. - Money gets extra care. Money's history has one active writer at a time, named on chain, so balances can't be written twice; a standby can take over through the chain. Coins leave the vault through signed checkpoints that keep totals balanced. - The chain is a public control plane. Validators admit programs and machines and hold locked coins. They see deposits, withdrawals, checkpoints and policy, not private balances or history. - Like any system, it relies on a few things holding: Intel's hardware, an honest majority of validators, and key-machine operators who act independently. ## Glossary - **CVM**: A virtual machine protected by Intel TDX or AMD SEV. The host runs it but is designed not to see or change its memory. - **Attestation quote**: An Intel-signed report from inside a CVM that names what started and can carry a fingerprint of its TLS key. - **Measurement**: A hash of what started in a CVM: firmware, OS image and program. Approved measurements are listed on chain. - **Compose hash**: A hash of a program's definition, including its code and allowed network reach. Each one belongs to its program. - **Measured config**: Settings built into the OS image, such as the chain id and trusted validator keys. Changing them changes the measurement. - **Program id**: A program's stable name on chain, such as money, edge or accounts. Its keys follow this name across code upgrades. - **Seat**: A public slot held by a bonded validator that lists the machines it runs. Seats with proven uptime share the seat fee. - **Platform id**: A fingerprint of a physical Intel CPU. It identifies a machine; CVMs on the same chip share it. - **Placement**: A chain record that assigns a program to a host. The host operator accepts it before anything starts. - **Key machine**: A CVM, run by its own operator, that releases keys together with the other key machines. Keys are designed to need several of them. - **Program keys**: Keys from the key machines that unlock a CVM's disk, encrypt its records, sign its connections, and let clients seal requests to it. - **Fork check**: A program's own check that a chain block was signed by enough trusted validators and follows the last block it accepted. - **ICS-23 proof**: A Merkle proof that a piece of chain state is included in an accepted block. - **Writer lease**: The chain's record of a program's active writer: one at a time, named on chain, so balances can't be written twice. A standby can take over through the chain. - **Tick and checkpoint**: A tick records a fresh history fingerprint and moves no coins. A checkpoint moves vault coins and confirms transfers. - **Object hash**: The hash of a program's latest encrypted data, kept on chain. Each new hash points to the previous one. - **Vault and wrap**: A per-program locked account on the chain. Wrapping locks coins in publicly; they leave through a checkpoint's payout list. - **Storage confirmations**: Stages of saved data: stored, its hash recorded on chain, then covered by an accepted checkpoint. --- Built by Secret³.dev (https://secret3.dev).