Operate nodes

Operators are vetted datacenter companies that run confidential GPUs for Sealroom models. You apply with your wallet, Sealroom vets the company and registers that wallet as an operator, and from then on you manage everything from the Operate page: the bond, your servers, your nodes and their attestations. You earn the operator share of every lane your nodes serve.

Hardware

1. Apply

Open https://sealroom.cloud/apply?kind=operator, or Apply as an operator on the app's Operators page.

1. Choose An operator.
2. Fill in Organisation, Your name, Work email and, optionally, Website (an https:// address).
3. Operator wallet: the Solana address that will post the bond and register your nodes. Approval registers this address on-chain, so use the wallet you will sign with.
4. Datacenter regions: comma-separated, for example "Frankfurt, Virginia".
5. H100 GPUs and H200 GPUs: how many of each you run.
6. Certifications: comma-separated, for example "ISO 27001, SOC 2".
7. Tick Our GPUs already run in confidential-computing mode with Intel TDX if that is the case.
8. Tick Sealroom may contact me about this application, complete the check above the button, and select Send application.

The page confirms with Application received and a reference for your application.

2. Vetting and approval

Sealroom vets the company off-chain: its legal entity, its datacenter certifications and the signed Operator Agreement. On approval, the admin multisig sends register_operator for your wallet. The Operator account records the hash of your signed agreement and your tier.

Until the registration lands, the Operate page says "This wallet is not an operator yet". Select Check again to re-read the registry. Once you are registered, the page shows your Operator account:

3. Post the bond

The bond is USDC collateral held by the program. A ruling in a dispute can slash it, and its size is part of what models check before your nodes qualify.

1. In the Bond panel, enter the amount in Deposit, USDC. The placeholder shows your tier's minimum.
2. Select Deposit bond and sign.

The minimum for each tier is published as bondMinimumsByTier in GET <api-url>/v1/parameters. A model can ask for more with its own minBond; your nodes qualify for that model when your bond meets the higher of the two. The deposit transaction also creates your USDC account and your payout account if they do not exist yet.

Unbonding

1. Select Request unbond (30 days). The unbond_at field shows when the bond matures, 30 days later.
2. After that time, select Withdraw. The whole bond returns to your USDC account.

While unbonding you cannot add to the bond. To keep operating instead, send cancel_unbond (see the Public API). While a dispute against you is open, the bond stays in place: unbonding cannot be requested and the bond cannot be withdrawn until the dispute is ruled.

4. Register a server

Each physical server is a platform. Registering it pins its hardware identity on-chain, so only that machine and those GPUs can be attested for you.

In the Register a server panel:

1. Platform identity: the server's Intel PPID/PCK identity.
2. GPU UEIDs, one per line: the device ID of each GPU in the server, 1 to 8.
3. Select Register platform and sign.

The app hashes the identity and each UEID with SHA-256 before anything leaves your browser; only the hashes go on-chain. A platform identity and a GPU UEID can each be registered once across all of Sealroom. The admin multisig co-signs platform registration after checking the identity against your vetting record: the transaction reaches your wallet with that signature already in place, and you add yours.

Your platforms appear in the Platforms table with their identity hash, number of GPUs and number of nodes.

5. Register nodes

A node is one confidential VM on a registered platform, with 1 to 8 of its GPUs.

In the Register a node panel:

1. Platform: the server the node runs on.
2. Endpoint: the HTTPS base URL where the node serves, at most 128 bytes, for example https://node.example.com/v1. Callers send requests to /chat/completions under it.
3. GPU: H100 or H200.
4. Count: how many GPUs the node uses, 1 to 8.
5. Select Register node and sign.

Each node claims its GPUs exclusively: a GPU that belongs to one node cannot be claimed by another. With register_node from code you name the exact gpuUeidHashes the node claims, along with its index on the platform and its nodeKey.

Your nodes appear in the Nodes table with their GPUs, status and attestation ("until" the expiry time, or "none").

6. Run the node runtime

The node runs the Sealroom runtime, a reproducibly built confidential VM image on Confidential Containers (Kata). Its measurement must be on Sealroom's allowed runtime list (GET <api-url>/v1/runtimes?status=allowed) and on the list of each model it serves. New runtime versions join the allowed list after a 48-hour timelock.

The runtime contains:

Owner-supplied code is never run: models load as weights only.

Boot and attestation

1. The runtime boots inside the confidential VM and generates three keys there: an HPKE key pair (X25519 + ML-KEM-768), a TLS key and an Ed25519 voucher key.
2. It computes H = SHA-256(public keys ‖ recent Solana slot hash), writes H into the TDX quote's REPORTDATA and uses H as the nonce for the GPU evidence. The evidence is fresh and bound to these exact keys.
3. The verifiers each check the TDX quote against Intel collateral, the GPU evidence against NVIDIA reference measurements (RIMs) and OCSP, the platform identity and GPU UEIDs against your registered platform, and the runtime measurement against the allowed list.
4. When three of the five verifiers have signed, record_attestation stores the attestation on-chain: runtime measurement, GPU reference hash, evidence hash, enclave key hash, TCB status, slot and expiry.

Every 24 hours

An attestation expires 24 hours after it is recorded, and the node re-attests before then. The registry shows the state of each node's current attestation:

The Nodes page marks each node with its Seal: sealed (registered, not yet attested), attested, serving, lapsed (attestation expired) or refused (attestation revoked or node disabled). A node's status is registered, serving, offline or disabled. The runtime serves only while its own attestation is valid, and the TCB status must be UpToDate.

7. Serving models

Your node becomes eligible for a model when it passes the model's policy: valid attestation, allowed runtime, registered platform, your tier and bond at or above the model's minimums, your operator on the model's allowlist if it has one, and your operator not frozen. GET <api-url>/v1/eligibility?modelId=…&nodeId=… shows each rule for one model and node.

A model's owner, or anyone, opens a lane for that model on your node. Your node then requests the model's data key from the owner's key broker, loads the weights and answers calls at its endpoint. Every payment for those calls goes into that lane's vault.

8. Earnings

Each model's split has an operator entry. At every distribution of a lane on one of your nodes, that entry's share of the lane's revenue after the protocol fee goes to your payout_ata. Anyone can distribute a lane, including you, with Distribute on the model's page.

To follow your revenue:

• GET <api-url>/v1/operators/<operator> returns revenue with totalIn, totalDistributed and claimable.
• GET <api-url>/v1/lanes?operatorId=<operator> lists the lanes on your nodes, each with its vault balance and totals.
• GET <api-url>/v1/distributions?nodeId=<node> lists the distributions for one node, each payout with its role and amount.

Your on-chain record is your reputation: the Operators page shows your tier, bond, status, number of nodes and open disputes, and the API adds your attestation history and measured uptime (uptime.availabilityBps over uptime.windowSeconds).