Overview
What Sealroom is
Sealroom is a registry and payment rail on Solana for confidential inference. Model owners list encrypted models and sell them per call. Vetted datacenter operators serve those models on NVIDIA H100 and H200 GPUs running in confidential computing mode, inside Intel TDX confidential virtual machines. Callers, from applications to AI agents, pay for each call in USDC over x402, with no account to open.
The key that decrypts a model's weights is released only to a node that has proven, on-chain, that it is a registered server of a bonded operator running a runtime the model owner allows. Solana holds the registry and the money. Weights, keys, prompts and GPUs stay off-chain.
One Solana program, sealroom, holds the shared state. Around it run a five-member verifier committee, each owner's key broker, an x402 facilitator that settles payments, an indexer that serves the public API, and a keeper that carries out scheduled steps such as applying a matured split.
Fees, bonds and dispute deposits are all paid in USDC. The protocol's token is $SEALROOM: a fixed supply of 1,000,000,000, all of it launched publicly on equal terms, and the protocol's whole fee share buys it on the market and burns it. See Token.
Roles
| Role | What it does on Sealroom |
|---|---|
| Model owner | Encrypts the weights, publishes the ciphertext, lists a model with its policy, price and split, runs the key broker for it and opens lanes on nodes |
| Operator | A vetted datacenter company. Signs the Operator Agreement, posts a USDC bond, registers its servers, GPUs and nodes |
| Node | One confidential VM (Intel TDX with 1 to 8 GPUs) running the measured Sealroom runtime. It serves calls at a registered HTTPS endpoint |
| Verifier committee | Five independent verifiers. Three must check a node's attestation evidence and sign before the attestation is recorded |
| Key broker | The owner's service that hands the model's data key to an attested node, wrapped so that only that enclave can open it |
| Caller | An app, enterprise or agent that pays per call in USDC |
| Contributors | Base-model owners, fine-tuners and data providers named in a model's split |
| Arbitration panel | A named multisig that rules on disputes and can freeze an operator, revoke its attestations and slash its bond to the claimant |
The lifecycle in seven steps
1. List
The owner encrypts the weights in chunks with AES-256-GCM under a random 256-bit data key and uploads the ciphertext to any storage. It then signs create_model with the manifest hash, the key broker's public key and URL, the runtime measurements a node must run (up to 8), the operator constraints (minimum tier, minimum bond, an allowlist of up to 16 operators), the price and the split (up to 8 recipients).
2. Onboard
Sealroom vets each operator off-chain: legal entity, datacenter certifications and a signed Operator Agreement. The admin multisig registers the operator at a tier, and the operator posts a USDC bond. The operator registers each server's platform identity (a hash of the Intel PPID/PCK) and the UEIDs of its GPUs, then registers each node with its endpoint and the GPUs it claims.
3. Attest
The node boots the runtime. Inside the confidential VM it generates an HPKE key pair (X25519 + ML-KEM-768), a TLS key and an Ed25519 voucher key, and binds their hash, together with a recent Solana slot hash, into the TDX quote and the GPU evidence. Verifiers check the quote against Intel collateral, the GPU evidence against NVIDIA reference measurements and OCSP, and the platform, GPUs and runtime against the registry. Three of the five sign, and record_attestation stores the result on-chain. An attestation lasts 24 hours.
4. Release
The node asks the owner's key broker for the model's data key and sends its evidence along. The broker reads the Attestation, Platform and Model accounts on-chain, checks the evidence against the on-chain hash, verifies it again and wraps the data key to the enclave's HPKE public key. Only that enclave can unwrap it. The weights are decrypted in the confidential VM's memory and loaded into GPU protected memory.
5. Serve and pay
The caller reads the node's attestation and sends its request. The node answers HTTP 402 with a price payable to the lane vault for that (model, node) pair: a fixed price per call (exact) or a ceiling for metered calls (upto). The caller's wallet signs one USDC payment, the node serves the call inside the enclave, and the facilitator settles the payment on Solana.
6. Distribute
Anyone can call distribute on a lane. One all-or-nothing transaction pays the protocol fee, the operator's share and every split recipient from the lane vault.
7. Dispute
With evidence of leaked weights or attestation fraud, a model owner opens a dispute against an operator that serves one of its lanes. The arbitration panel rules on it and can freeze the operator, revoke its attestations and slash its bond to the claimant.
What lives on-chain
| Account | Holds |
|---|---|
| Config | Admin multisig, protocol fee, attestation lifetime, pause flag |
| VerifierSet | The verifier keys (up to 7) and the signing threshold |
| Operator | Agreement hash, tier, bond vault and amount, unbonding time, frozen flag, payout account |
| Platform | Hash of the server's Intel PPID/PCK identity and up to 8 GPU UEID hashes |
| Node | Node key, endpoint (up to 128 bytes), GPU model and count, status |
| Attestation | Runtime measurement, GPU reference hash, evidence hash, enclave key hash, TCB status, slot, expiry, method |
| Runtime | Image name and version, source commit, allowed or revoked |
| Model | Manifest hash, key broker, allowed runtimes, minimum tier and bond, operator allowlist, price, royalty, split and pending split |
| Lane | The USDC vault for one (model, node) pair, total paid in, last distribution |
| Dispute | Claimant, evidence hash, deposit, status, ruling |
The public API at <api-url> serves all of these as JSON, indexed from the chain, together with distributions, key releases and an activity feed.
Words used in these docs
| Term | Meaning |
|---|---|
| Model | An encrypted model listed by its owner, identified by its Model account address and shown in the app as "Model 1", "Model 2" and so on per owner |
| Lane | The pairing of one model with one node. Each lane owns a USDC vault that receives every payment for calls to that model on that node |
| Vault | The lane's USDC token account. Funds wait there until a distribution |
| Split | The list of recipients of a model's revenue and their shares in basis points (bps), summing to 10,000 |
| Bond | USDC an operator deposits as collateral. A ruling can slash it |
| Attestation | The on-chain record that a node's hardware, GPUs and runtime were verified by three of five verifiers |
| Runtime | The measured software image a node runs. Owners pick the measurements they accept |
| Platform | One physical server, pinned by its platform identity and GPU UEIDs |
| Tier | An operator's level (1 to 3). Each tier has a minimum bond, and a model can require a minimum tier |
| bps | Basis points. 100 bps is 1%, 10,000 bps is 100% |
USDC amounts in the API and the client are strings of base units with 6 decimals: "25000" is 0.025 USDC.
Where to go next
| You want to | Read |
|---|---|
| Connect a wallet and fund it | Connect a wallet |
| Pay for a call in the app or from code | Call a model |
| Sell inference on your model | List a model |
| Run nodes and earn the operator share | Operate nodes |
| See where each USDC goes | Fees and distribution |
| Understand $SEALROOM | Token |
| Act on leaked weights or attestation fraud | Disputes |
| Read the registry or build transactions over HTTP | Public API |
| Integrate in TypeScript | TypeScript client |
| Find a quick answer | FAQ |
The app is at https://sealroom.cloud/app. Its Registry page shows operators, attested nodes, models, open lanes and the USDC distributed so far, with three ways in: Call a model, List a model and Operate nodes.