1. Introduction

1.1 What Sealroom is

Sealroom is a Solana registry and payment rail where model owners sell per-call inference on vetted confidential-GPU operators, and the weight key is released only to attested, bonded enclaves.

A model owner encrypts its weights once, under a random 256-bit data key, and publishes the ciphertext wherever it likes. The data key stays with the owner. It leaves the owner's key broker only as an HPKE ciphertext addressed to a public key that was generated inside a confidential virtual machine (CVM) and whose attestation is recorded on Solana. That CVM is a Sealroom node: one Intel TDX trust domain with one to eight NVIDIA H100 or H200 GPUs in confidential computing mode, running a measured Sealroom runtime, on a physical server that a vetted operator has registered and bonded in USDC.

Callers reach a node over TLS that terminates inside the enclave and pay for each call over x402 in USDC. Each payment lands in a lane vault, a token account the program owns for one (model, node) pair. Anyone can then call distribute on the lane, and one transaction pays the protocol fee, the serving operator's share and every recipient in the model's revenue split. The protocol fee then buys $SEALROOM, the protocol's fixed-supply, fairly launched token, on the market and burns it (14.7).

Solana holds the registry and the money: operators, platforms, nodes, attestations, runtime allowlists, models with their policies and splits, lanes, bonds and disputes. Weights, data keys, prompts, completions, raw attestation evidence and the GPUs themselves stay off chain. The chain records hashes of everything a verifier or a broker needs to compare against: the operator agreement, the platform identity, each GPU's identity, the runtime measurement, the evidence, and the enclave's public keys.

1.2 The problem it answers

A team with a valuable specialist model has three established ways to sell inference, and each leaves one party exposed.

Sealroom serves the case of two-sided distrust. The owner will not ship weights to the buyer's infrastructure, and the buyer will not send data to the owner's. Both can accept a third machine when its hardware proves which software it runs and its operator is named and bonded, with access to the weights decided by a public policy the owner wrote.

Between many owners, many operators and many callers, that requires four things, and Sealroom provides each of them:

1. A public, machine-checkable record of which physical machines are attested and which operator is liable for them.
2. Key release gated on that record, by the owner's own broker.
3. Per-call payment without an account, so that software agents can pay as easily as enterprises.
4. Revenue splits to upstream contributors, enforced by the program at distribution time.

1.3 Who uses it

Model owners list models, each with its own key broker, runtime pins, operator requirements, price and split. The primary segment is model vendors selling to regulated buyers, such as banks, hospitals and government agencies, that refuse vendor-hosted APIs. Enterprises licensing internal models to partners and subsidiaries, and specialist fine-tuners in legal, medical and financial domains seeking agent distribution, use the same path.

Operators are vetted datacenter companies running confidential-mode GPUs. Each signs the Operator Agreement, posts a USDC bond, and registers its servers' platform identities and the device identities of their GPUs. An operator earns the Operator-role share of every lane its nodes serve.

Callers are applications, enterprises and AI agents. A caller checks a node's attestation on chain, opens TLS to the enclave, and pays per call over x402, either a fixed price (exact) or a metered amount under a ceiling (upto).

Contributors are the base-model owners, fine-tuners and data providers named in a model's split. A base model can require a derivative royalty, which every derivative model must carry as a locked split entry paid to the base owner's canonical USDC account.

Verifiers form a committee of five independent parties. Each verifier checks node evidence against Intel and NVIDIA collateral and against the registry, and signs a fixed 200-byte message; three signatures are required for an attestation to land. Sealroom runs at most two of the five verifiers.

The arbitration panel is a named multisig, distinct from the admin multisig, that rules on disputes under the Operator Agreement. It can freeze an operator, revoke every attestation the operator holds, and slash its bond to the claimant.

1.4 Design commitments

The rest of this paper elaborates a small number of fixed decisions.

• Supply is permissioned. Operators are vetted off chain, then admitted on chain by the admin multisig with an agreement hash and a tier. Only admitted, bonded operators can register platforms and nodes.
• Platforms are pinned. A quote counts only if its platform identity and the identities of the GPUs that produced its companion evidence were registered by that operator for that node.
• Owners hold their keys. The default key broker is run by the owner, reads Solana directly, re-verifies the evidence itself, and publishes an audit record for every release and every denial.
• Policy is public. Runtime allowlists, tier and bond minimums, operator allowlists, attestation expiry and revocation state are on-chain accounts that any party can read.
• Payment needs no account. A node answers HTTP 402 with x402 payment terms; the caller signs a USDC transfer to the lane vault and retries.
• Splits are settled at distribution. Each call is one transfer to one vault; distribute later allocates the vault across the protocol fee and the split in one atomic transaction.
• Money is USDC. Prices, bonds, fees, deposits and payouts are USDC base units moved with checked integer arithmetic.

1.5 What this paper covers

Chapter 2 gives the system overview: actors, the lifecycle, trust boundaries, the division between chain and off-chain services, and the reasons for Solana. Chapter 3 covers Intel TDX, NVIDIA Hopper confidential computing, the device identities Sealroom pins, and the construction that binds a node's fresh keys and a recent slot hash into both pieces of hardware evidence.

Chapter 4 describes operator admission and platform pinning, Chapter 5 the attestation pipeline, and Chapter 6 key management and release. Chapter 7 documents the sealroom program: accounts, PDAs, instructions, errors, timelocks and upgrade authority. Chapters 8 to 10 cover payments over x402, settlement and distribution, and bonds, disputes and arbitration. Chapters 11 to 14 cover services and infrastructure, security design, parameters and governance, and economics. Appendix A is an instruction reference and Appendix B a glossary.

1.6 Conventions

Amounts are USDC base units (1 USDC = 1,000,000 base units). Hashes are SHA-256 and 32 bytes unless stated otherwise; runtime measurements are 48 bytes. On chain, integers are little-endian, public keys are 32 raw bytes, and every account begins with an 8-byte Anchor discriminator followed by a version: u8 and a bump: u8. A program-derived address is written with its seeds, for example ["att", node]. The symbol ‖ (written || in formulas) denotes byte concatenation. In the API, keys and signatures are base58, hashes are lowercase hex, and amounts and slots are decimal strings.

2. System overview

2.1 Actors and roles

Figure: The seven actors of Sealroom and their relationships to the sealroom program.

Alongside the actors, a set of services operates the system. Each runs as its own process with its own credentials.

2.2 The lifecycle

Figure: List, Onboard, Attest, Release, Serve and pay, Distribute and Dispute, with the instruction or service call at each step.

A model is served by a node through seven steps. The first two are registrations that happen once. Attestation repeats at least every 24 hours for each node. Release happens when a node loads a model. Serving, payment and distribution run continuously. Dispute is invoked when an owner has evidence against an operator.

2.2.1 List

1. The owner generates a random 256-bit data key, encrypts the weights with AES-256-GCM in chunks, and uploads the ciphertext to any storage, public storage included.
2. The owner signs create_model, which creates Model ["model", owner, id] (2,348 bytes) with the 32-byte manifest hash, the key broker's public key and URL (at most 128 bytes), up to 8 allowed runtime measurements of 48 bytes, min_tier (1 to 3), min_bond, an operator allowlist of up to 16 operators (empty admits any operator meeting tier and bond), a price (Exact { per_call } or Upto { input_per_million_tokens, output_per_million_tokens, max_per_call }), derivative_royalty_bps, an optional base model, and a split of 1 to 8 entries summing to exactly 10,000 bps. Each entry names a recipient token account, a beneficiary wallet, bps, locked and a role: Owner, Operator, BaseModel or Contributor.
3. The program checks every split recipient is a canonical USDC account of its declared owner and, if the base model sets a royalty, requires a locked BaseModel entry of at least that many bps paid to the base owner.

Later split changes go through propose_split and become applicable after 7 days (604,800 seconds); a locked entry can be lowered or removed only with its beneficiary's signature.

2.2.2 Onboard

1. Sealroom vets the operator off chain: legal entity, datacenter certifications, and the signed Operator Agreement.
2. The admin multisig signs register_operator(agreement_hash, tier), creating Operator ["op", authority] with its bond vault and payout account.
3. The operator signs deposit_bond. An operator is healthy while it is unfrozen and its bond is at least its tier's minimum in Config.tier_bond_minimums.
4. For each server, the operator and the admin multisig both sign register_platform(platform_id_hash, gpu_ueid_hashes), creating Platform ["plat", operator, platform_id_hash] with up to 8 GPU UEID hashes, a global PlatformPin, and one global GpuPin per GPU.
5. For each CVM, the operator signs register_node with an index (u16), a node key, an HTTPS endpoint of at most 128 bytes, the GPU model (H100 or H200) and the UEID hashes of the GPUs it claims; each claimed GPU must be on the platform and unclaimed.

Runtime images are admitted separately: allow_runtime, signed by the admin multisig, creates Runtime ["rt", SHA-256(measurement)], which becomes effective after a 48-hour timelock (172,800 seconds). revoke_runtime takes effect immediately.

2.2.3 Attest

1. The node boots the measured runtime in a TDX trust domain with its GPUs in confidential computing mode.
2. Inside the CVM it generates three key pairs: an X-Wing HPKE key pair (ML-KEM-768 + X25519), an Ed25519 TLS key and an Ed25519 voucher key.
3. It reads a recent (slot, hash) pair from Solana's SlotHashes sysvar.
4. It computes H = SHA-256(public keys ‖ recent slot hash), places H in TDX REPORTDATA, and uses H as the attestation nonce for every GPU (Chapter 3 gives the exact construction).
5. It assembles a sealroom-evidence-v1 object with the node address, the slot pair, the three public keys, the TD quote and one GPU report per GPU, and submits it to the coordinator.
6. The coordinator proposes the next revision (sequence + 1, the active verifier epoch, the operator's attestation epoch, expires_at = chain time + 86,400 − 1 seconds) to the five verifiers. Each independently verifies the TD quote against Intel collateral and the GPU evidence against NVIDIA RIMs and OCSP, checks the registry, archives the evidence by its hash, and signs the 200-byte canonical message.
7. The coordinator checks each signature against its member key and submits one v0 transaction: an Ed25519 precompile instruction with three signatures, then record_attestation, which writes Attestation ["att", node]. The transaction is 1,056 bytes, under the 1,232-byte packet limit.

2.2.4 Release

1. The node posts a key request to Model.key_broker_url: a request UUID, the model address, and the evidence object that was attested.
2. The broker reads the model, node, platform, operator, attestation, runtime, verifier set and pin accounts directly from RPC in one context, and runs the eligibility rules: attestation current, unexpired and unrevoked; runtime allowed and pinned by the model; platform registered; tier and bond at the required minimums; operator unfrozen and allowlisted; TCB UpToDate; node enabled; protocol running.
3. It checks that the evidence hash, enclave key hash and slot pair equal those in the Attestation account, re-verifies the vendor evidence itself, and repeats the registry checks.
4. It wraps the 32-byte data key with HPKE (X-Wing, HKDF-SHA256, AES-256-GCM) to the enclave's HPKE public key, with associated data that binds the chain, program, model, node, attestation revision, evidence hash and request.
5. It reads the chain a final time, persists the audit record, and returns the wrapped key.

Inside the CVM the key client unwraps the data key, decrypts the weights in CVM memory and loads them into GPU protected memory. Only the CVM holding the HPKE private key can unwrap it. Chapter 6 gives the full protocol.

2.2.5 Serve and pay

1. The caller's SDK reads the node's Attestation account and the model's eligibility, recomputes the enclave key hash from the node's public keys, and checks that the node's TLS key is the committed one, so prompts terminate inside the enclave.
2. Without a payment, the node answers HTTP 402 with x402 version 2 PAYMENT-REQUIRED terms: scheme, USDC mint, the lane vault as payTo, amount, a 120-second timeout, fee payer, invoice memo and session identifier.
3. The caller signs its own transaction (compute-budget instructions, one TransferChecked of USDC to the payee, the memo) and retries with the PAYMENT-SIGNATURE header.
4. The facilitator verifies the authorization without moving funds; the node runs inference and checks eligibility again; the facilitator co-signs as fee payer and submits; the node returns the completion.

With exact, the amount is per_call. With upto, the caller escrows max_per_call in the payment-channels program, and the node settles actual usage with a voucher signed by the enclave's voucher key, binding the domain sealroom:usage:v1, the chain, lane, channel, request, nonce, cumulative amount, expiry and attestation revision. Settlement and refund of the unused ceiling form one atomic transaction. The metered charge is:

Because the voucher key exists only inside the attested enclave, the operator cannot raise a charge without breaking the enclave. The runtime stops serving when its own attestation lapses.

2.2.6 Distribute

Anyone can call distribute(lane). With G the vault's unreserved balance:

The fee goes to the treasury. The Operator-role weight is paid to the payout account of the operator whose node owns the lane, so one model can serve on several operators and each receives its own share. Every other entry is paid to its declared account; a share whose account cannot receive it is reserved in the lane as a claimable entitlement. With the 500 bps launch fee, each 1,000,000 base units of revenue yields 50,000 to the treasury and 950,000 to the split.

2.2.7 Dispute

1. A model owner with evidence of leaked weights or attestation fraud signs open_dispute against an operator, with the evidence hash and the configured deposit. The owner must hold a lane on that operator whose unconsumed protocol fees, actually paid to the treasury, cover the deposit.
2. The arbitration multisig signs rule_dispute. A ruling for the claimant can slash up to the tracked bond principal, freeze the operator, and advance Operator.attestation_epoch, which invalidates every attestation of that operator at once. A dismissal forfeits the deposit.
3. settle_slash funds the reserved slash, and the claimant signs claim_dispute to receive it.

An operator with an open dispute cannot withdraw its bond. arbitrate_operator lets the panel freeze or revoke an operator without a claimant.

2.3 Trust boundaries

Sealroom's components sit in six domains, each with its own material and its own enforcement.

The enclave. A node's trust domain and its GPUs in confidential computing mode hold the plaintext weights, the data key, the three enclave private keys, and every prompt and completion. The operator's host schedules the CVM and carries its encrypted traffic without access to its memory. The data key enters HPKE-wrapped to a key generated inside the enclave, and prompts enter over TLS terminated inside it. The runtime's egress allowlist permits only the key broker, the Solana RPC and the facilitator, and the runtime runs no owner-supplied code (trust_remote_code is disabled).

The physical platform. A node counts only on a server whose Intel platform identity and GPU identities are pinned to a vetted, bonded operator. The Operator Agreement, recorded as Operator.agreement_hash, covers the facility, and the USDC bond backs the operator's liability. Evidence from genuine hardware that no operator registered fails the pin checks.

The owner. The key broker holds the data key at rest and releases it only HPKE-wrapped, after its own chain reads and its own vendor verification. Each release and denial is public in /v1/key-releases with the attestation account and revision, the evidence hash, a policy hash, the chain read slot and the broker's public key.

The committee. Five verifiers each hold one Ed25519 key. The program accepts an attestation only with signatures from at least three distinct members of the active VerifierSet over a message that commits to the program, the genesis hash, the node, the epoch, the replay sequence, the attestation content and the recent slot. The coordinator that relays the signatures holds no verifier key.

The chain. The program enforces registration, pinning, timelocks, expiry, revocation, payment destinations and settlement arithmetic. The admin and arbitration multisigs are separate Squads multisigs that must differ. Runtime allowance, fee changes and dispute-configuration changes wait 48 hours, and an owner's own runtime pins and operator allowlist apply on top of the protocol's.

The caller. The caller signs only its own transfer to the lane vault, verifies the enclave's TLS key against the chain before sending data, and, under upto, accepts only vouchers signed by the attested voucher key.

Two vendor roots anchor the enclave domain: Intel, through its PCK certificate hierarchy and the Provisioning Certification Service collateral, and NVIDIA, through its device certificate hierarchy, Reference Integrity Manifests and OCSP. Each verifier keeps its own collateral cache, and running nodes continue to serve on their current attestation while collateral is refreshed.

2.4 On chain and off chain

The program stores identity, policy, attestation results and money. The table lists its accounts with their seeds and maximum allocated sizes.

USDC itself sits in program-controlled token accounts: one bond vault per operator, one vault per lane, and deposit vaults for disputes.

Off chain, the system holds everything that is large, secret or both:

Raw quotes stay off chain. A TD quote carries the full PCK certificate chain in its certification data, and the GPU reports carry their own certificate chains; the chain stores one 32-byte hash of the canonical evidence object and the derived values every party compares against.

2.5 Why Solana

Agent payments run on Solana. On January 20, 2026, x402 payments on Solana passed those on Base, 518,400 against 505,000. By mid-August 2026, Solana carried about 70% of monthly x402 volume and had processed more than 35 million x402 transactions in total.

Metered billing exists natively. Coinbase announced the x402 upto scheme in April 2026. On Solana, a caller escrows a ceiling in the Solana Foundation payment-channels program (CHNLxYvVA28MJP9PrFuDXccuoGXAx7jBacfLEkahyGsX, audited by Cantina in July 2026), and the server settles actual usage with an Ed25519-signed voucher. This maps directly onto per-token LLM billing; in Sealroom the voucher is signed by the enclave's voucher key.

State updates are cheap. Every node re-attests at least once a day, and lanes are distributed continuously, each transaction costing a fraction of a cent. A three-signature record_attestation uses 49,314 compute units in a 1,056-byte transaction; a distribution to a fee and eight split recipients uses 165,610 compute units in 268 bytes. Both fit in one packet, against a per-transaction limit of 1.4 million compute units.

Committee signatures verify natively. The Ed25519 precompile verifies the verifiers' signatures in the runtime. The program reads the precompile instructions through the instructions sysvar, requires every offset to point inside the verified instruction, and matches the signed message byte for byte against the message it derives itself. No signature arithmetic runs in the program.

The chain supplies its own freshness beacon. The SlotHashes sysvar exposes the hashes of the most recent 512 slots. A node binds one of them into its hardware evidence, and the program accepts the attestation only while that pair is still in the sysvar.

USDC is native. Bonds, prices, vaults and payouts are SPL Token USDC moved with TransferChecked. SVM x402 facilitators validate a fixed instruction layout around one TransferChecked to the payee; Sealroom keeps that layout by making each call a single transfer to the lane vault and moving the split into distribute, which stays atomic across all recipients.

Proof-based attestation fits the compute budget. The Attestation.method field distinguishes Committee from Zk. Groth16 verification over the alt_bn128 syscalls takes under 200,000 compute units in the groth16-solana crate and about 280,000 in sp1-solana, inside the 1.4 million limit, so a proof whose public inputs commit to the same attestation fields records into the same account.

3. Confidential computing foundations

3.1 The confidential node

A Sealroom node is a confidential virtual machine built from two hardware mechanisms. The CPU side is an Intel TDX trust domain, which isolates the VM's memory and CPU state from the host. The GPU side is one to eight NVIDIA Hopper GPUs (H100 or H200) in confidential computing mode, passed through to that trust domain. The runtime image is reproducibly built on Confidential Containers and Kata, and contains the attestation agent, the key client, vLLM, the x402 middleware for exact and upto, the voucher signer, TLS termination and the egress allowlist.

Each mechanism produces its own signed evidence. Intel's evidence is a TD quote, signed under a key that Intel certifies for one specific platform. NVIDIA's evidence is a GPU attestation report, signed by a key that NVIDIA certifies for one specific GPU. Sealroom ties both to one node, one boot and one set of enclave keys by writing the same 32-byte value into each: a hash over the enclave's public keys and a recent Solana slot hash. The following sections describe each mechanism, the identities Sealroom pins, and that binding.

3.2 Intel TDX

3.2.1 Trust domains

A trust domain (TD) is a virtual machine whose private memory and register state are protected by the processor and by the Intel TDX module. The TDX module is Intel-signed software that runs in the processor's Secure Arbitration Mode (SEAM) and mediates every transition between the host's virtual machine monitor and a TD. TD private memory is encrypted with a key specific to that TD, and the TDX module prevents the host from reading it or remapping it. The host still schedules the TD and carries its I/O, so everything a node exchanges with the outside is either public or encrypted end to end. The TDX module is itself measured: its measurement (MRSEAM), its signer's measurement (MRSIGNERSEAM) and its security version numbers (TEE_TCB_SVN) appear in every quote.

3.2.2 Measurement registers

A TD has one build-time measurement register and four runtime registers, each 48 bytes (the size of a SHA-384 digest).

• MRTD measures the initial contents of the TD: the memory pages the host adds and measures before the TD starts, which hold the virtual firmware. It is fixed once the TD is finalized.
• RTMR0 to RTMR3 are extended by software inside the TD as it boots. By convention RTMR0 records the firmware's configuration, RTMR1 the OS loader and kernel, RTMR2 the kernel command line and initial file system, and RTMR3 is available to the application.

An extend operation folds a new digest into a register; a register can only be extended, never set:

A reproducibly built runtime image therefore produces the same register values on every compliant platform. Sealroom records the runtime as one 48-byte measurement, the value the verifier's Intel adapter reports for the quote's measured image. That value is the key of the Runtime allowlist account (["rt", SHA-256(measurement)]), the content of Attestation.runtime_measurement, and an entry in each model's allowed_runtimes.

3.2.3 TDREPORT and REPORTDATA

Software inside a TD asks the TDX module for a TDREPORT with the TDG.MR.REPORT call, passing 64 bytes of its own choice: REPORTDATA. The TDX module returns a 1,024-byte TDREPORT containing the TD's measurements, attributes and REPORTDATA, authenticated with a MAC that only the same platform can check.

REPORTDATA is the channel through which a TD commits to data it generated itself. Whatever the TD writes there is carried unchanged into the quote and covered by the quote's signature. Sealroom writes H, the binding value defined in Section 3.5, into the first 32 bytes.

3.2.4 The TD quote

A TDREPORT is local to one machine. To make it verifiable anywhere, the host passes it to the TD Quoting Enclave (QE), an Intel-signed SGX enclave on the same platform. The QE verifies the TDREPORT's MAC, then signs the report contents with its ECDSA P-256 attestation key. The attestation key is in turn certified by the platform's Provisioning Certification Key (PCK): the QE's own SGX report, whose REPORTDATA holds SHA-256 of the attestation public key and the QE authentication data, is signed with the PCK. The PCK certificate chains to the Intel SGX Root CA.

A version 4 quote is laid out as follows; version 5 adds a type-and-size descriptor before the body.

TD quote v4
  Header                       48 bytes   version, attestation key type (ECDSA P-256),
                                          TEE type (TDX), QE vendor ID, user data
  TD quote body               584 bytes   see below
  Signature data length         4 bytes
  Signature data             variable
    ECDSA signature            64 bytes   over header || body, by the attestation key
    ECDSA attestation key      64 bytes   P-256 public key
    Certification data       variable
      QE report               384 bytes   SGX report body of the Quoting Enclave
      QE report signature      64 bytes   by the PCK
      QE authentication data variable
      PCK certificate chain  variable    PEM: PCK leaf, intermediate CA, root CA

The 584-byte body carries every value a verifier compares:

Because the PCK certificate chain travels inside the quote, the quote identifies its platform by itself: the PCK leaf certificate carries Intel's platform extensions, including the Platform Provisioning ID (PPID), the FMSPC that identifies the platform model, and the TCB levels the certificate was issued for.

3.2.5 Collateral and TCB status

A quote's signatures prove origin. Whether the platform's firmware and microcode are current is decided against collateral that Intel publishes through its Provisioning Certification Service (PCS): the TCB Info for the platform's FMSPC, the QE Identity, the PCK certificate revocation list and the root CA revocation list, each signed under the Intel SGX Root CA. Quote verification with Intel's DCAP libraries, or through Intel Trust Authority, proceeds in this order:

1. Validate the PCK certificate chain to the Intel SGX Root CA and check both revocation lists.
2. Verify the QE report signature with the PCK public key, check the QE report against the QE Identity, and check that the QE report's REPORTDATA commits to the attestation key and authentication data.
3. Verify the quote signature over the header and body with the attestation key.
4. Compare the PCK certificate's TCB components and the body's TEE_TCB_SVN against the TCB Info levels, and derive the platform's TCB status.

Sealroom carries the outcome as the TcbStatus enum (UpToDate, OutOfDate, ConfigurationNeeded, Revoked, Unknown). The verifier's claims type admits only UpToDate, and record_attestation rejects any other value with InvalidTcb.

3.3 NVIDIA Hopper confidential computing

3.3.1 Confidential computing mode

An H100 or H200 placed in confidential computing mode partitions its memory so that a protected region is reachable only by the GPU's own engines and by the confidential VM it is assigned to. The host cannot read protected memory or inspect the GPU's internal state through debug paths. The GPU driver inside the CVM and the GPU establish an authenticated session using SPDM (the DMTF Security Protocol and Data Model), and all data moving between CVM memory and the GPU passes through bounce buffers in shared memory, encrypted and authenticated with AES-GCM under that session's keys. Model weights decrypted inside the CVM are copied into GPU protected memory over that channel.

3.3.2 The GPU attestation report

Each GPU holds a device identity key pair provisioned by NVIDIA, with a certificate chain that leads to NVIDIA's device identity root. The attestation report is an SPDM measurement exchange:

• Request. The requester, here the attestation agent in the CVM, sends a 32-byte nonce.
• Response. The GPU returns its measurement record (indexed measurement blocks covering firmware, VBIOS and security configuration), opaque data including the driver and VBIOS versions, and a signature by the device's attestation key over the whole exchange, the requester's nonce included.

The report is accompanied by the GPU's certificate chain. The device certificate carries the GPU's unique entity identifier (UEID), and the verification result reports it.

3.3.3 RIMs and OCSP

NVIDIA publishes Reference Integrity Manifests (RIMs) for each driver and VBIOS release: signed documents listing the expected value of every measurement index. A verifier using NVIDIA's local verifier proceeds as follows:

1. Validate the GPU certificate chain to NVIDIA's root and check the status of every certificate with NVIDIA's OCSP service.
2. Verify the report signature with the device certificate's key.
3. Check that the nonce in the report equals the expected nonce.
4. Fetch the driver RIM and the VBIOS RIM matching the versions in the report from NVIDIA's RIM service, verify their signatures, and check their signing certificates by OCSP.
5. Compare every measurement in the report with the corresponding RIM value.

The NVIDIA Remote Attestation Service (NRAS) performs the same evaluation as a hosted service, and a verifier may use it as an optional cross-check. Sealroom's verifier reduces the result to a 32-byte gpu_rim_hash identifying the reference set the GPUs were checked against; all GPUs of one node must report under the same RIM hash and with distinct UEIDs.

3.4 Device identities Sealroom pins

Genuine evidence proves that a genuine Intel platform and genuine NVIDIA GPUs produced it. Sealroom additionally requires that they are the specific machines a vetted operator registered. Two identities make that possible, both readable from the evidence itself.

Intel platform identity. The PPID is the identifier Intel uses to provision a platform's PCK, and the PCK certificate that carries it is embedded in every quote that platform produces. Sealroom stores a 32-byte hash of this identity (Platform.platform_id_hash, identity kind intel_ppid_pck in the API). During onboarding the operator supplies it from its vetting record; at attestation the verifier derives it from the quote.

GPU identity. Each GPU's UEID comes from its NVIDIA device certificate and appears in its verified evidence. Sealroom stores a 32-byte hash per GPU.

The registry holds these identities in four accounts:

Because the pins are global accounts derived from the identity hashes alone, a platform identity cannot be registered under two operators and a GPU cannot be assigned to two nodes. Evidence from an unregistered machine, from a registered machine attributed to the wrong operator, or from GPUs borrowed from another server fails these comparisons before any signature is produced.

3.5 Binding enclave keys and a recent slot hash

3.5.1 The enclave keys

On every boot, the runtime generates three key pairs inside the CVM. Their private halves never leave it.

The X-Wing public key is the ML-KEM-768 public key (1,184 bytes) followed by the X25519 public key (32 bytes).

3.5.2 The public-key transcript

The three public keys are concatenated in a fixed order. Fixed order and fixed sizes make the encoding unambiguous: no two different key sets produce the same byte string.

public-key transcript (1,280 bytes)
  offset     0   1,184 bytes   ML-KEM-768 public key   } X-Wing HPKE public key
  offset 1,184      32 bytes   X25519 public key       } (1,216 bytes)
  offset 1,216      32 bytes   TLS Ed25519 public key
  offset 1,248      32 bytes   voucher Ed25519 public key

Its hash is the enclave key hash recorded on chain:

3.5.3 The recent slot hash

Solana's SlotHashes sysvar holds the most recent slot hashes as a list: an 8-byte little-endian count, followed by up to 512 entries of 40 bytes each, an 8-byte slot number and its 32-byte hash. The node reads one (recent_slot, recent_slot_hash) pair before it requests any evidence. A slot hash cannot be predicted before that slot exists, so evidence that commits to it was produced after it.

3.5.4 H in REPORTDATA and the GPU nonce

The binding value appends the slot hash to the transcript:

The input is 1,312 bytes and H is 32 bytes. The node writes H into both pieces of evidence:

TDX REPORTDATA (64 bytes)
  bytes  0..31   H
  bytes 32..63   reserved; a verifier rejects unexpected bytes here

GPU attestation nonce (32 bytes), for every GPU in the node
  bytes  0..31   H

The complete procedure inside the CVM is:

1. Generate the HPKE, TLS and voucher key pairs.
2. Build the 1,280-byte transcript and compute enclave_key_hash.
3. Read (recent_slot, recent_slot_hash) from SlotHashes.
4. Compute H over the transcript and the slot hash.
5. Call TDG.MR.REPORT with REPORTDATA = H in bytes 0 to 31, and have the Quoting Enclave convert the TDREPORT into a TD quote.
6. For each assigned GPU, request an attestation report with nonce = H.
7. Assemble the evidence object.

H links four facts. The TD quote proves that a measured runtime on a specific Intel platform produced H. Each GPU report proves that a specific genuine GPU, in a measured state, was asked to attest with H. H commits to exactly one set of enclave public keys, so the HPKE key the broker wraps to, the TLS key the caller connects to and the voucher key that signs charges all belong to that runtime. And H commits to a slot hash, so all of it happened after that slot.

Figure: The three enclave public keys and a recent slot hash are hashed into H, which is written into TDX REPORTDATA and used as every GPU's attestation nonce.

3.5.5 The evidence object

The node submits its evidence as a strict JSON object, format sealroom-evidence-v1:

The whole object is bounded to 1 MiB. Its hash is taken over a serialization with a fixed field order (version, nodeId, recentSlot, recentSlotHash, keys with hpkePublicKey, tlsPublicKey, voucherPublicKey, then tdxQuote, gpuEvidence):

evidence_hash is what the committee signs into the attestation and what verifiers use as the key of their private evidence archives. Any party holding the archived object can recompute it, recompute enclave_key_hash and H, and compare them with the chain.

3.6 What each verifier checks

Four parties examine a node's evidence or its on-chain result: each committee verifier (vendor verification, then registry checks), the program, the owner's key broker and the caller. Checks are listed with the error codes they produce.

3.6.1 Vendor verification

Each committee verifier runs Intel quote verification (Section 3.2.5) and NVIDIA GPU verification (Section 3.3.3) and reduces the result to a fixed set of claims:

3.6.2 Registry checks by the committee verifier

The verifier reads all policy accounts from RPC in one context, retrying if any changes between reads, and checks:

1. The chain's genesis hash is the expected one and the evidence names the node read (CHAIN_IDENTITY_MISMATCH, NODE_MISMATCH).
2. Protocol running, operator unfrozen, node enabled (PROTOCOL_PAUSED, OPERATOR_FROZEN, NODE_DISABLED).
3. The platform is registered to this operator, its platform_id_hash equals the claim, and the global PlatformPin agrees (PLATFORM_NOT_REGISTERED, PLATFORM_ID_MISMATCH, GLOBAL_PLATFORM_PIN_MISMATCH).
4. The UEID claims are distinct, match the node's assigned GPUs one for one, are registered on the platform, and every GpuPin names this platform and node (GPU_UEID_MISMATCH, EXCLUSIVE_GPU_PIN_MISMATCH).
5. The runtime is allowed, unrevoked and effective (RUNTIME_NOT_ALLOWED).
6. The slot pair is in SlotHashes (RECENT_SLOT_HASH_MISMATCH).
7. reportDataHash and every GPU nonce equal H recomputed from the evidence (ENCLAVE_KEY_BINDING_MISMATCH).
8. The bond meets the tier minimum (OPERATOR_BOND_BELOW_TIER_MINIMUM).
9. No sticky revocation; next sequence; current operator epoch; active verifier epoch with this verifier a member; expiry within the TTL (ATTESTATION_REVOKED_ADMIN_CLEAR_REQUIRED, ATTESTATION_SEQUENCE_MISMATCH, VERIFIER_NOT_ACTIVE, ATTESTATION_EXPIRY_INVALID).

Only then does the verifier archive the evidence and sign a 200-byte message: the 16-byte domain sealroom.att.v0\0, the program id, the genesis hash, the node, the verifier epoch, the replay sequence, the SHA-256 of a 194-byte commitment, the recent slot and the recent slot hash. The commitment carries the platform, the runtime measurement, the GPU RIM hash, the evidence hash, the enclave key hash, the TCB status, the expiry, the method and the operator epoch. Chapter 5 gives the byte offsets.

3.6.3 The program

record_attestation is permissionless to relay and checks the result rather than the raw evidence:

The resulting Attestation account (384 bytes) stores the committed values together with the slot pair, recorded_at, the verifier epoch, a signer bitmap and the SHA-256 of the signed message. Chapter 7 gives its full layout.

3.6.4 The key broker

The owner's broker repeats the decisive checks with its own reads and its own vendor verification. It requires the model to name this broker (BROKER_AUTHORITY_MISMATCH), the evidence hash, enclave key hash and slot pair to equal the attestation (EVIDENCE_CHAIN_MISMATCH), the eligibility rules and the registry checks of Section 3.6.2 to pass on its fresh vendor claims, and the runtime measurement and RIM hash to equal those recorded (VENDOR_CLAIMS_CHAIN_MISMATCH). The slot pair need not still be in SlotHashes at release time, because freshness was proved when the attestation was recorded and the record carries its own 24-hour expiry. A final chain read must match the first (REGISTRY_CHANGED_DURING_RELEASE).

3.6.5 The caller

The caller checks that the node it is about to send data to is the node the chain attested:

1. Read Attestation ["att", node] and the model's eligibility for this node: current, unexpired, unrevoked, operator epoch current, runtime pinned by the model.
2. Obtain the node's three public keys, recompute enclave_key_hash and compare it with the account. The registry API also publishes tlsPublicKeyHash, hpkePublicKeyHash and voucherPublicKey for each attestation whose archived evidence reproduces the on-chain value.
3. In the TLS handshake, require the server's Ed25519 public key to equal the 32-byte TLS key in the transcript.
4. Under upto, accept a usage voucher only if the transcript's voucher key signed it and it names the current attestation and revision.

These checks use only public data, so a caller performs them without an account with any party.

4. Operator admission and platform pinning

Sealroom admits operators by decision of its admin multisig after off-chain vetting, and it accepts a node only on hardware that an admitted operator registered. The threat model behind this design is an attacker with physical control of a confidential-computing server, who can extract the platform's attestation keys and produce quotes that verify as UpToDate. If key release accepted any genuine Intel platform, one purchased server would be enough to impersonate a node. Sealroom therefore accepts evidence only when its platform identity and every GPU UEID were registered by a vetted, bonded operator bound by the Operator Agreement.

This chapter follows the admission path in the order an operator walks it.

4.1 Off-chain vetting

4.1.1 Intake

An operator applies through the Sealroom intake at /apply with a strict, typed record:

Each submission carries an Idempotency-Key and passes a server-side Cloudflare Turnstile challenge. Its status moves from received to reviewing, then to accepted or declined.

4.1.2 What vetting establishes

Vetting is a legal and physical-security decision, so it happens off chain. Sealroom establishes:

1. Legal entity. The applicant is an identified company, with KYC on the entity behind the operator authority.
2. Facilities. The datacenters that will host registered servers, and their certifications.
3. Hardware. Intel TDX with NVIDIA H100 or H200 GPUs in confidential computing mode, the v0 hardware.
4. Machine identities. For each server, the platform identity (the Intel PPID carried by its PCK certificate) and the UEID of every GPU. The admin later co-signs these records into the registry.
5. The Operator Agreement. The contract under which the arbitration panel rules on disputes and slashes bonds.

Vetting continues as periodic review after onboarding, charged at cost recovery.

4.1.3 What reaches the chain

Vetting produces the operator's authority wallet, the hash of its signed agreement and its tier, which register_operator records, and the platform and GPU identities of each server, which register_platform records with their global pins. Both instructions are signed by Config.admin, the Squads admin multisig, which keeps the registry's identities tied to the vetting records.

4.2 register_operator and tiers

4.2.1 The instruction

register_operator(agreement_hash: [u8; 32], tier: u8) creates the operator's account, its bond vault and its link to a payout account. The operator does not sign: admission is the admin's act. The operator's first signature on chain is its first deposit_bond.

Checks, in order:

1. The signer is Config.admin (Unauthorized).
2. The protocol is not paused (Paused).
3. Config.tier_bond_minimums has an entry for tier (ConfigurationUnset).

The instruction then writes the account and emits OperatorRegistered { operator, authority, tier, agreement_hash, timestamp }. Because the PDA is seeded by the authority alone, one wallet controls at most one Operator.

4.2.2 The Operator account

payout_ata is where the Operator-role share of every lane on this operator's nodes is paid (Chapter 9). attestation_epoch is the operator-wide revocation counter described in Section 5.9.

4.2.3 Tiers

Config.tier_bond_minimums is a list of exactly three TierBondMinimum { tier: u8, amount: u64 } entries, for tiers 1, 2 and 3 in that order. The program refuses to initialize with any other shape (ConfigurationUnset, InvalidTier), and it refuses any register_operator or set_tier whose tier has no entry.

set_tier(tier) is signed by the admin and changes Operator.tier under the same check, emitting OperatorTierSet. A tier change takes effect at once in every rule that reads it: if the operator's bond is below the new tier's minimum, it stops being healthy (Section 4.3) and its next attestation is refused.

Models use tiers as a floor. Model.min_tier is between 1 and 3, and the key broker releases only to nodes whose operator's tier is at least that value (tier_below_min, Section 6.4).

4.3 Bonds per tier

4.3.1 The bond vault

Every operator's bond sits in its bond_vault, a USDC token account whose authority is the Operator PDA, so only the program can move it. Amounts are USDC base units (6 decimals), and every transfer is a TransferChecked.

Operator.bond_amount is the tracked principal. It rises only through deposit_bond and falls only through withdrawal or a slash. Tokens sent to the vault by a plain transfer do not increase it, and they do not count toward any minimum.

4.3.2 Health

An operator is healthy when it is not frozen and its tracked bond meets its tier's minimum:

Health is required by register_platform, register_node and record_attestation. The failures are OperatorFrozen and InsufficientBond.

A model can demand more than the protocol does. At release time the key broker applies the larger of the two minimums:

4.3.3 Deposits, unbonding and withdrawal

A slash ruled by arbitration subtracts from bond_amount and adds to pending_slash_amount in the same instruction, so a reserved slash is never part of the withdrawable principal. Chapter 10 describes slashing and its settlement.

4.3.4 Attestations follow the bond

An operator that has asked to leave cannot hold attestations past its departure. record_attestation requires every new attestation to expire no later than unbond_at when one is set (AttestationBeyondUnbond):

Worked timeline, in days from the unbond request:

When the bond leaves the vault, every node of the operator is already outside a valid attestation, and the broker has nothing to release against.

4.4 register_platform

4.4.1 What a platform is

A Platform is one physical server: one Intel platform identity and the GPUs installed in it. Its identity is stored as platform_id_hash, a 32-byte hash of the PPID/PCK identity that the server's TD quotes carry in their PCK certificate chain (identity kind intel_ppid_pck in the API). Each GPU is stored as gpu_ueid_hash, a 32-byte hash of the UEID from its NVIDIA device certificate. A platform holds 1 to 8 GPUs. Section 3.4 explains how the verifier derives both identities from evidence.

4.4.2 The instruction

register_platform(platform_id_hash: [u8; 32], gpu_ueid_hashes: Vec<[u8; 32]>) requires two signatures: the operator authority, which pays rent and binds the machine to its bond, and the admin multisig, which attests that the identities match the vetting record.

Steps:

1. The admin signed, the protocol is running and the operator is healthy (Unauthorized, Paused, OperatorFrozen, InsufficientBond).
2. gpu_ueid_hashes has 1 to 8 distinct entries and exactly that many remaining accounts are supplied (InvalidGpuSet).
3. Each GpuPin address equals its derived PDA, is writable, holds no data and is owned by the System Program (GpuAlreadyClaimed). The program tops up rent if the address already holds lamports, allocates 107 bytes, assigns the account to itself and writes { platform, gpu_ueid_hash, node: None }.
4. The PlatformPin is created; creation fails if the address is in use.
5. The Platform is written with registered = true, and PlatformRegistered is emitted.

The steps run in one transaction, so a platform is registered with all of its pins or not at all.

4.4.3 Layouts

Platform (343 bytes):

PlatformPin (106 bytes) and GpuPin (107 bytes):

4.5 Global pins: one machine, one registration

The Platform PDA includes the operator in its seeds, so by itself it would let two operators each create a Platform for the same server. The pins close that gap. Their seeds contain only the identity hash, so each pin address exists once across the whole program:

• PlatformPin ["platform_pin", platform_id_hash] maps one platform identity to one operator and one Platform account.
• GpuPin ["gpu_pin", gpu_ueid_hash] maps one GPU to one platform, and after register_node to one node.

Pins have no release or migration instruction. A platform identity or GPU, once registered, stays bound to the operator and platform that first registered it.

The verifier and the broker read the pins again at every attestation and every release. They require the PlatformPin to name this platform, the node's operator and the identity in the quote (GLOBAL_PLATFORM_PIN_MISMATCH); the GPU evidence to carry exactly the node's assigned UEIDs (GPU_UEID_MISMATCH); and every GpuPin to name this platform and this node (EXCLUSIVE_GPU_PIN_MISMATCH). Evidence borrowed from a GPU outside the node fails the UEID check. The GPU nonce, bound to H (Section 3.5.4), proves the evidence is fresh; the UEID check proves which GPUs produced it.

4.6 register_node

4.6.1 The instruction

A node is one CVM: a TDX trust domain with 1 to 8 of its platform's GPUs, running the measured Sealroom runtime. The operator registers it alone; the admin's co-signature was given at the platform level.

register_node(args: RegisterNodeArgs):

Steps:

1. The protocol is running, the operator is healthy and the platform is registered (Paused, OperatorFrozen, InsufficientBond, PlatformNotRegistered).
2. The endpoint passes the URL rules below (InvalidEndpoint).
3. gpu_ueid_hashes has 1 to 8 distinct entries, all in Platform.gpu_ueid_hashes, with one GpuPin supplied per entry (InvalidGpuSet).
4. Each GpuPin is at its derived address, program-owned, with a matching bump and hash (InvalidGpuSet), names this platform and has no node (GpuAlreadyClaimed). The program sets GpuPin.node to the new node.
5. The Node is written with gpu_count equal to the number of hashes and status Registered, and NodeRegistered is emitted.

Because each GPU can be claimed by one node and every node has at least one GPU, a platform's GPUs are partitioned among its nodes: an 8-GPU server can be one 8-GPU node, eight 1-GPU nodes, or any split in between.

4.6.2 Endpoint rules

The program accepts only an unambiguous HTTPS URL: ASCII, at most 128 bytes, no whitespace, control characters, backslash or user@ component; an optional port from 1 to 65,535; host labels of 1 to 63 letters, digits or hyphens with no xn-- labels; and numeric hosts only as canonical four-part IPv4 or bracketed IPv6. The same rules apply to Model.key_broker_url.

4.6.3 The Node account

A Disabled node cannot be attested (NodeDisabled) and fails the broker's node_disabled check. The registry API reports node status as registered, serving, offline or disabled; serving means the node is healthy and its current attestation matches its evidence.

4.7 Operator status and freezing

4.7.1 Status

The registry API derives one status for each operator from its account, in this order:

The API also publishes tier, agreementHash, bondAmount, the vault balance, attestationEpoch, openDisputeCount, pendingSlashAmount and the operator's platforms and nodes.

4.7.2 Who can freeze

None of these paths is blocked by the protocol pause, and none makes a token transfer, so a frozen USDC account cannot prevent a freeze. Clearing a freeze is an admin decision through freeze_operator(false).

4.7.3 What freezing stops

A freeze stops new key releases and service at the next read. To invalidate every attestation the operator holds at once, arbitration also advances Operator.attestation_epoch (Section 5.9.4), which makes every attestation signed under the previous epoch revoked for every consumer.

5. The attestation pipeline

An Attestation account states that a node, on a registered platform with registered GPUs, booted an allowed runtime measurement and holds a specific set of enclave keys, and that at least three of the five committee verifiers checked its vendor evidence within the last 24 hours. This chapter follows that statement from evidence to transaction, then through revocation, renewal and the ZK path that follows the committee.

Figure: The node submits bound evidence to the coordinator, five independent verifiers check it and sign one 200-byte message, and three signatures land on chain through the Ed25519 precompile and record_attestation.

5.1 The pipeline end to end

1. Bind. The runtime generates its enclave keys, binds them and a recent slot hash into H, and obtains a TD quote and one GPU report per GPU carrying H (Section 3.5).
2. Submit. The node sends its sealroom-evidence-v1 object to the attestation coordinator.
3. Propose. The coordinator verifies the evidence, reads the registry and fixes the next sequence, the verifier epoch, the operator epoch and the expiry.
4. Sign. All five verifiers check the evidence independently; each archives it and signs the 200-byte canonical message.
5. Record. The coordinator keeps three valid signatures and submits an Ed25519 precompile instruction followed by record_attestation, which re-derives the message, checks the signatures through the instructions sysvar and writes Attestation ["att", node].
6. Publish. The indexer mirrors AttestationRecorded as a new revision for the API, callers and key brokers.

5.2 The verifier set

5.2.1 Composition

The verifier committee has five members. They are independent parties; Sealroom operates at most two of the five. Each verifier runs as its own service with exactly one Ed25519 signing key, its own credential, its own host and secret store, and its own cache of Intel and NVIDIA collateral. A quorum is three distinct members signing the same message, so the committee produces attestations with any two members unavailable, and no two members can produce one on their own.

The coordinator is a separate service that holds no verifier key. Its only key is the fee payer that submits transactions, and it refuses to run if that key is a committee member. It cannot create a committee signature; it can only collect and relay them.

5.2.2 The VerifierSet account

The PDA is ["verifiers", epoch] with the epoch as u64 little-endian, so each committee membership lives in its own account. Config.active_verifier_epoch names the set whose signatures count. The account allocates room for seven members; the v0 committee is exactly five distinct, non-default keys with threshold 3. The program enforces that shape at initialization (InvalidVerifierSet) and again inside every record_attestation, before it counts a single signature. A set with retired_at set is never accepted.

A member's position in members is its bit in the attestation's signer_bitmap: member 0 is bit 0, member 4 is bit 4. Bitmap 0b00000111 (7) means members 0, 1 and 2 signed.

5.3 What each verifier checks

A verifier exposes one signing route that accepts only server requests carrying its own credential. The request is an attestation proposal: the evidence object plus the proposed sequence, verifier epoch, operatorEpoch and expiresAt. The verifier works through three groups of checks; Section 3.6 lists each with its error code.

1. Vendor verification. The TD quote is verified against Intel collateral (DCAP with Intel PCS, or Intel Trust Authority), admitting only TCB status UpToDate. Each GPU report is verified against NVIDIA's reference integrity manifests and OCSP with the NVIDIA local verifier, with NVIDIA's remote attestation service as an optional cross-check.
2. Registry checks. In one RPC read at confirmed commitment, the verifier loads Config, Node, Platform, Operator, Attestation, the active VerifierSet, the claimed Runtime, the PlatformPin, every GpuPin and the Clock and SlotHashes sysvars. It checks the genesis hash, pause and freeze flags, platform identity and pins, GPU set, runtime activation, slot pair, H binding and tier bond. "Now" is the chain's Clock.
3. Proposal checks. No sticky revocation is in place; sequence is the current sequence plus one; operatorEpoch equals Operator.attestation_epoch; epoch is active and includes this verifier; expiresAt is after now and at most 86,400 seconds ahead.

When every check passes, the verifier archives the evidence privately under evidence_hash with its byte length, format version and capture time; builds the 200-byte canonical message (Section 5.4) from its own registry read and vendor claims; and returns { publicKey, signature, messageHash, evidenceHash }. Raw quotes run to several kilobytes and include the PCK certificate chain, so they stay off chain; the on-chain hash and the archive let an auditor reproduce the verification. A verifier signs only a message it computed itself.

5.4 The canonical attestation message

5.4.1 Message layout

Every committee member signs the same 200 bytes. The program builds the identical bytes from its own accounts and the instruction arguments, and the client SDK encodes them the same way.

5.4.2 Commitment layout

The commitment is the AttestationCommitment struct, Borsh-encoded in field order. It is always 194 bytes.

5.4.3 What each field binds

5.5 Collecting signatures and the Ed25519 packet

5.5.1 The coordinator

The coordinator runs the vendor verification and registry checks itself before it asks anyone to sign, then fixes the proposal:

It sends the proposal to all five verifiers in parallel, each with a 30-second timeout. It accepts a response only if the public key equals the key configured for that endpoint and is a member of the active set, the evidenceHash matches, and the Ed25519 signature verifies over the coordinator's own copy of the message. Valid responses are deduplicated by public key; with fewer than three the coordinator records nothing (VERIFIER_QUORUM_UNAVAILABLE), and with more it uses exactly three.

5.5.2 Precompile instruction layout

The three signatures travel in one instruction to Solana's native Ed25519 program (Ed25519SigVerify111111111111111111111111111), placed before record_attestation in the same transaction. The message appears once and all three signatures reference it.

Ed25519 precompile instruction data, n signatures
  offset         size     field
  0              1        n (1 to 7)
  1              1        padding, must be 0
  2              14 x n   one offsets record per signature, seven u16 LE values:
                            signature_offset
                            signature_instruction_index   = 0xFFFF
                            public_key_offset
                            public_key_instruction_index  = 0xFFFF
                            message_data_offset
                            message_data_size             = 200
                            message_instruction_index     = 0xFFFF
  2 + 14n        96 x n   per signer: public key (32), then signature (64)
  2 + 110n       200      canonical message, shared by all signatures

For the three-signature packet:

5.5.3 How the program reads the packet

The Ed25519 program verifies every signature in the packet before record_attestation runs; a single invalid signature fails the whole transaction. record_attestation then reads the instructions sysvar to learn what was verified. For every instruction before its own index whose program id is the Ed25519 program, it requires:

1. The instruction has no accounts, n is between 1 and 7, the padding byte is 0, and the data holds all n offsets records (InvalidSignatureInstruction).
2. Every instruction-index field is 0xFFFF, meaning "this instruction". A packet therefore cannot point the precompile at bytes in another instruction while the program inspects different ones (InvalidSignatureInstruction).
3. The 64-byte signature and 32-byte public key lie inside the data (InvalidSignatureInstruction).
4. The message size is exactly 200 and the message bytes equal the message the program derived (WrongAttestationMessage).
5. The public key is a member of the active VerifierSet (UnknownVerifier).
6. That member's bit is not already set in the bitmap, across all Ed25519 instructions in the transaction (DuplicateVerifier).

After the scan, the number of set bits must reach the set's threshold of 3 (InsufficientSignatures). The resulting bitmap is stored as Attestation.signer_bitmap.

5.6 record_attestation

5.6.1 Signers, accounts and arguments

The only signer is the payer. Anyone can relay a committee packet; the authority of the record comes from the three committee signatures, which the program checks itself.

RecordAttestationArgs:

With the 8-byte instruction discriminator, the instruction data is 258 bytes.

5.6.2 Checks, in program order

1. The protocol is not paused (Paused).
2. The operator is healthy: not frozen, bond at its tier minimum (OperatorFrozen, InsufficientBond).
3. The platform is registered (PlatformNotRegistered).
4. The node's status is Registered (NodeDisabled).
5. Every GPU hash on the node is on the platform (InvalidGpuSet).
6. The runtime is not revoked and its 48-hour timelock has passed (RuntimeNotAllowed).
7. The commitment's measurement equals Runtime.measurement and its platform equals the platform account (AttestationMismatch).
8. The commitment's TCB status is UpToDate and its method is Committee (InvalidTcb).
9. now < expires_at <= now + 86,400, and expires_at <= unbond_at when an unbond is pending (AttestationExpired, AttestationBeyondUnbond).
10. args.epoch equals Config.active_verifier_epoch and the set's own epoch, and the set is not retired (InvalidVerifierSet).
11. The commitment's operator_epoch equals Operator.attestation_epoch (AttestationReplay).
12. The attestation is not revoked (AttestationRevoked), and args.sequence is 1 for a new account or the stored sequence plus 1 (AttestationReplay).
13. (recent_slot, recent_slot_hash) appears as a pair in SlotHashes, which holds at most 512 entries of 40 bytes after an 8-byte count (InvalidRecentSlot).
14. The program derives the 200-byte message and verifies the committee packet as in Section 5.5.3.

It then overwrites the node's single Attestation account and emits AttestationRecorded with every stored field, the signer bitmap and the canonical message hash.

5.6.3 The Attestation account

Offsets are from the start of the account. The three optional fields at the end occupy up to 75 bytes; the allocation reserves their maximum.

There is one Attestation per node. A renewal overwrites it; the history of every signed revision is kept by the indexer from the AttestationRecorded events, keyed by account address and sequence, together with the transaction signature, the signing verifiers and a link to the archived evidence.

5.7 Measured cost

A three-signature record_attestation is sent as a v0 transaction with an address lookup table:

The two instructions carry 532 bytes of Ed25519 packet and 258 bytes of record_attestation data. The legacy form spends 32 bytes on each of the 13 account addresses; the lookup table replaces them with one-byte indexes. The coordinator creates the table once, reuses it, and refuses to send any attestation packet over 1,232 bytes.

49,314 compute units is 3.5% of the 1.4 million units a transaction may use. With renewal at least every 24 hours, the committee path costs one such transaction per node per day.

5.8 Sequence, revision and expiry

sequence is the replay barrier: every committee record and every revocation consumes the next value. signed_sequence is the revision number of the latest committee-signed record, and it is the value that key-release logs, usage vouchers and the API cite. operator_epoch is fixed at signing; expires_at is at most 86,400 seconds after recording.

The registry API reports each attestation as valid, expiring_soon (3,600 seconds or less remain), expired or revoked. An attestation counts as revoked when revoked_at is set or when its operator_epoch is lower than the operator's current attestation_epoch. Every consumer compares expires_at with the chain's Clock.

5.9 Revocation

5.9.1 revoke_attestation

revoke_attestation(reason_hash: [u8; 32]) takes four accounts: the signing authority, config, a verifier_set and the writable attestation. The signer must be Config.admin or a member of the supplied VerifierSet when that set is the one at Config.active_verifier_epoch; anyone else fails with Unauthorized.

If the attestation is not already revoked, the instruction increments sequence, sets revoked_at to now, revoked_by to the signer and revoke_reason_hash to the supplied hash, and emits AttestationRevoked. Revoking an already revoked attestation succeeds and changes nothing. The instruction is not gated by the protocol pause.

5.9.2 Immediate effect

Revocation takes effect at the next read of the account by each consumer:

5.9.3 Held packets and the sticky latch

A revocation is sticky. The node cannot clear it by renewing, and a renewal packet that was already signed when the revocation landed can never be recorded:

1. The node's attestation is at sequence 10. The coordinator holds a fully signed renewal for sequence 11 that it has not yet submitted.
2. A verifier revokes. The revocation consumes sequence 11: sequence = 11, revoked_at set.
3. The held packet for 11 is submitted. It fails with AttestationRevoked.
4. The admin or arbitration multisig calls clear_attestation_revocation. It clears revoked_at, revoked_by and revoke_reason_hash and sets expires_at to now, so the account is valid for no time at all. sequence stays 11.
5. The held packet for 11 is submitted again. The program now expects sequence 12 and fails with AttestationReplay.
6. The node must produce fresh evidence and the committee must sign a new proposal at sequence 12. That record becomes signed_sequence = 12.

clear_attestation_revocation is signed by Config.admin or Config.arbitration and requires the attestation to be revoked (AttestationNotRevoked). Clearing never revalidates anything: it only permits a new committee record.

5.9.4 Operator-wide revocation through the epoch

Arbitration can revoke every attestation an operator holds with one field. rule_dispute and arbitrate_operator accept revoke_attestations: bool; when true, the ruling increments Operator.attestation_epoch.

Every attestation carries the epoch it was signed under, inside its signed commitment. After the increment, each of the operator's attestations has an operator_epoch below the operator's: the broker treats it as revoked (attestation_revoked), the indexer marks it revoked at the ruling's time, and the node's own eligibility check fails. Any held packet signed under the old epoch fails record_attestation with AttestationReplay. New attestations need fresh evidence signed under the new epoch, which a frozen operator cannot obtain. The Attestation accounts themselves are not touched, so the revocation costs one instruction however many nodes the operator runs.

5.9.5 Runtime revocation

revoke_runtime marks a Runtime revoked immediately. From then on record_attestation refuses that measurement (RuntimeNotAllowed), verifiers refuse to sign it (RUNTIME_NOT_ALLOWED), and the broker's eligibility rule requires the runtime to be globally allowed as well as pinned by the model (runtime_not_allowed). Existing attestations under a revoked runtime stop receiving keys at once.

5.10 Renewal

An attestation lives at most 86,400 seconds; the coordinator proposes chain now + 86,399. A node renews by running the pipeline again with a new (slot, hash) pair. If it keeps its key pairs, enclave_key_hash is unchanged while H and evidence_hash change with the slot hash. The committee signs at sequence + 1 under the operator's current epoch, and record_attestation overwrites Attestation ["att", node] with signed_sequence at the new revision.

The API flags an attestation as expiring_soon in its last hour. A renewal passes every rule a first attestation does, so the operator must still be healthy, the runtime still allowed and the pins intact each day. The node's key release is tied to the revision it was issued under (Section 6.6): after a renewal it requests a release for the new revision before serving again, and the runtime stops serving when its own attestation lapses.

5.11 The ZK verification path

The committee is the v0 verification method. The account layout already carries its successor: AttestationMethod has two variants, Committee and Zk, and the method tag is part of the signed commitment. record_attestation accepts only Committee (InvalidTcb for any other method).

The next method, record_attestation_zk, replaces the three committee signatures with one Groth16 proof:

The proof fits within the 1.4 million compute units of one transaction. Because the public inputs commit to the same fields, every check downstream of the account (the broker's eligibility rules, the caller's key check, revocation by epoch and sequence) reads a ZK attestation exactly as it reads a committee one. The ZK path removes trust in the committee's code; platform pinning and operator vetting remain the basis of hardware trust under both methods.

6. Key management and release

The model owner keeps its weights encrypted everywhere outside an attested enclave. One 256-bit data key per model opens them, and that key leaves the owner's key broker only as an HPKE ciphertext addressed to a specific enclave's key, after the broker has checked the chain, the evidence and the model's policy for itself. Every decision, release or denial, is logged with the attestation it relied on.

6.1 Weight packaging

The owner packages a model once:

1. Generate a random 256-bit data key for the model.
2. Encrypt the weights with AES-256-GCM in chunks. Each chunk is authenticated, so a modified chunk fails to decrypt.
3. Write a manifest describing the encrypted package and compute its 32-byte hash.
4. Upload the ciphertext and the manifest to any storage, public storage included; the ciphertext is unreadable without the data key.
5. Place the data key in the broker's key store (Section 6.2).
6. Sign create_model with the manifest hash, the broker's identity and the release policy.

The manifest hash pins exactly which ciphertext the model refers to. A node fetches the manifest, checks it against Model.manifest_hash, and decrypts chunk by chunk with the released data key.

The Model account fields that govern release:

create_model validates every bound (BoundsExceeded, InvalidBps, InvalidEndpoint). The full Model account, with price and split, is 2,348 bytes; Chapter 7 gives its layout.

6.2 The owner-run key broker

The key broker is an open-source service that the owner runs, or delegates to a party it chooses. Sealroom does not hold model keys.

A node contacts the broker after boot and after each renewal of its attestation; between those, it serves with the release it holds.

The owner-run broker is the v0 default. As an opt-in for owners who prefer not to run one, the v1 design adds a Sealroom threshold committee: the data key split into 3-of-5 Shamir shares held in HSMs at independent firms, each re-verifying the evidence before contributing its share.

6.3 The key request

The node sends a strict JSON body with three fields: requestId, a fresh UUID; modelId, the Model address; and evidence, the same sealroom-evidence-v1 object the committee attested.

attestationRevision is the attestation's signed_sequence. The request UUID never appears in any public record; the public audit identity is a separate random value.

6.4 Release checks

Figure: The broker reads the chain, checks the evidence against the on-chain attestation, re-verifies it, wraps the data key to the enclave's HPKE key, reads the chain again and logs the decision before returning the ciphertext.

6.4.1 The release procedure

The broker processes each request in this order:

1. Parse. Validate the request, compute evidence_hash, and draw a fresh audit id (32 random bytes, base58).
2. First chain read. In one RPC call, read Config, Node, Platform, Operator, Attestation ["att", node], the Clock and SlotHashes sysvars, the active VerifierSet, the Model, the attested Runtime, the PlatformPin and every GpuPin. If the node's links or the verifier epoch change between the preview and the full read, retry, up to three times. The genesis hash must be the configured one (CHAIN_IDENTITY_MISMATCH).
3. Policy checks. Run the twelve eligibility rules (Section 6.4.2); require Model.key_broker to be this broker (BROKER_AUTHORITY_MISMATCH); and require evidence_hash, the SHA-256 of the evidence's key transcript, recentSlot and recentSlotHash to equal the attestation's evidence_hash, enclave_key_hash, slot and recent_slot_hash (EVIDENCE_CHAIN_MISMATCH). Any failure denies with every failing reason.
4. Fix the release identity: genesis hash, attestation address, sequence, signed_sequence, evidence_hash, broker key and policy hash as read.
5. Re-verify the TD quote against Intel collateral and every GPU report against NVIDIA RIMs and OCSP.
6. Registry checks on fresh claims. Repeat the committee's registry checks (Section 5.3) against the broker's own vendor claims. The SlotHashes presence check is omitted: freshness was proved when the attestation was recorded, and its expiry bounds its age.
7. Claims against chain. The verified runtime measurement and RIM hash must equal Attestation.runtime_measurement and Attestation.gpu_rim_hash (VENDOR_CLAIMS_CHAIN_MISMATCH).
8. Build the context for the key release (Section 6.5.2).
9. Load and wrap the model's 32-byte data key with HPKE to evidence.keys.hpkePublicKey, with the context as associated data.
10. Final chain read. Every check of step 3 must still pass and the release identity must be unchanged. A revocation, a freeze, a slash below the minimum or a renewal between the two reads denies the release (REGISTRY_CHANGED_DURING_RELEASE).
11. Log the audit record with outcome released. If the write fails, nothing is returned.
12. Return the wrapped key with the audit id, attestation address and revision, and zero the broker's copy of the data key.

On any failure, the broker re-reads the chain once if it has not completed the final read, logs the denial with the policy reasons from its latest read plus the error that stopped the procedure, and returns 403. Every request is checked from the beginning; a repeated request never reuses an earlier decision.

6.4.2 Eligibility rules

The broker runs the same eligibility function that the public API serves at /v1/eligibility?modelId={modelId}&nodeId={nodeId}, so anyone can compute a broker's policy decision in advance from public data. The function evaluates twelve checks, in this order, and reports every one that fails:

6.4.3 Broker reason codes

Beyond the twelve eligibility codes and the registry codes of Section 3.6.2, a denial can carry:

6.5 HPKE wrapping to the enclave's key

6.5.1 The suite

The hybrid KEM derives the shared secret from both ML-KEM-768 and X25519, so recovering the data key from a recorded envelope requires breaking both.

The broker trusts the recipient key because its hash is the on-chain enclave_key_hash (step 3), and the same transcript produced the H carried in REPORTDATA and every GPU nonce (step 6) of a quote from an allowed runtime on a pinned platform. The private key was generated inside that runtime and never leaves the CVM.

6.5.2 The key-release context

The associated data is the UTF-8 JSON encoding of:

The envelope returned to the node has five fields: version (sealroom-key-wrap-v1), suite, and the base64 enc (KEM encapsulation), ciphertext (the sealed data key) and context (the associated data).

6.5.3 Unwrap inside the CVM

The runtime's key client:

1. Authenticates the broker's TLS identity against the broker recorded for the model in the registry, before accepting the response.
2. Rebuilds the expected context from its own values (program, genesis hash, model, node, its evidence hash and request id) and the attestation address and revision in the response, and requires the envelope's context to equal it byte for byte.
3. Opens the ciphertext with its HPKE private key, the same info and the context as associated data.
4. Requires a 32-byte plaintext.

Any failure in steps 2 to 4 yields one generic error, KEY_UNWRAP_FAILED. The client then fetches the manifest, checks it against Model.manifest_hash, decrypts the weights chunk by chunk in CVM memory and loads them into GPU protected memory.

6.6 Holding and using the key

The node keeps one release per model, bound to the attestation revision it was issued under. Before each inference it checks that its release revision equals the attestation's current signed_sequence and that the model is still eligible on the node; it checks eligibility again before settling the payment. After a renewal it requests a release for the new revision. After a revocation, a freeze or an epoch advance, both checks fail and the node neither serves nor charges.

The runtime's network egress is limited to the key broker, the Solana RPC and the payment facilitator, and it serves only architectures its pinned vLLM build supports, with trust_remote_code off, so no owner-supplied code runs next to the weights and prompts.

6.7 The release log

6.7.1 Record schema

The broker appends one record per attempt, released or denied:

The policy hash is taken over the JSON encoding of the model's release policy as read from chain:

6.7.2 Rules

A ciphertext leaves the broker only after its released record is persisted. Every attempt has its own audit id, and a denial is logged as durably as a release, with the revision and policy from the latest chain read. The log holds hashes and identifiers only: data keys, private keys, raw evidence, wrapped ciphertexts and request UUIDs never enter it. The log is public at /v1/key-releases, filterable by outcome, and each record also appears in the registry's activity feed as key_released or key_denied with source key_broker.

6.7.3 Auditing against the chain

Each record names everything needed to check it against the chain without trusting the broker. For a released record, an auditor:

1. Finds the AttestationRecorded event for attestationId at attestationRevision and checks that its evidence_hash and enclave_key_hash equal the record's.
2. Checks that the attestation had not expired at releasedAt and had no AttestationRevoked event or operator-epoch advance before readSlot.
3. Recomputes the model's policy hash from the Model account and compares it with policyHash.
4. Re-evaluates the twelve eligibility rules at readSlot.

Comparing the broker log with the chain this way is how Sealroom measures that no key is released outside policy.

6.8 Base-model royalties through key gating

6.8.1 What the program enforces

A base model sets derivative_royalty_bps, the share it requires from every model built on it. A derivative, such as a LoRA adapter trained on an encrypted base model, names its base in base_model. Split entries carry a role (Owner, Operator, BaseModel or Contributor) and a locked flag. At create_model with base_model = Some(base):

1. The base Model account must be supplied and equal base (InvalidBaseModel). Without a base_model, no base account may be supplied.
2. If the base's derivative_royalty_bps is above zero, the derivative's split must contain an entry with role BaseModel, locked = true, bps >= base.derivative_royalty_bps, paying the canonical USDC associated token account of the base's owner, supplied and verified as a token account owned by that owner (RoyaltyRequired).

At propose_split, every locked entry of the current split must reappear with the same recipient, beneficiary and role, still locked, with at least the same bps, unless the entry's beneficiary signs the proposal (LockedSplit). The base owner's royalty therefore cannot be lowered, unlocked or removed without the base owner's signature. Each lane snapshots its model's split, and distribute pays the BaseModel entry from every lane of the derivative.

6.8.2 The key gate

The base model's weights are encrypted under the base owner's own data key, held by the base owner's broker. A node serving the derivative needs two releases: the derivative's key from the derivative owner's broker, and the base key from the base owner's broker. The base owner's broker releases the base key only for derivatives whose split pays the base's derivative_royalty_bps as a locked entry. The program already guarantees that any Model naming the base in base_model carries that entry, so the broker's royalty check reduces to reading the derivative's base_model and confirming the locked BaseModel entry is present in its split.

6.8.3 Worked example

The protocol fee is 500 bps at launch. Take a base owner that sets derivative_royalty_bps = 1000, a derivative split that gives the base exactly that, and a lane that receives 100 USDC (100,000,000 base units) of caller payments:

The base owner receives 9.5 USDC from this distribution, in the same transaction that pays the protocol fee, the operator and the derivative's other recipients. Chapter 9 gives the complete distribution arithmetic, including the rounding remainder paid to the final entry.

7. The sealroom program

Sealroom keeps its registry and its money in one Solana program, sealroom, written with Anchor 0.31.1 and deployed through the upgradeable BPF loader. The program records operators and their bonds, the physical platforms and GPUs each operator has pinned, the nodes that run on them, the runtime measurements that are allowed, the attestations the verifier committee has signed, and the models that owners list with their policy, price and split. It holds three kinds of funds: operator bonds, the USDC that callers pay into per-(model, node) lane vaults, and dispute deposits. Each sits in a token account whose authority is a program-derived address, and leaves it only through the instructions described here.

The published interface (IDL sealroom, version 0.2.0) contains 39 instructions, 14 account types, 35 event types and 54 program error codes. This chapter documents all of them from the program source: the account layouts byte by byte, every instruction with its signers, constraints, state changes, events and failure codes, the fixed durations that govern change, the deployment and upgrade model, and the measured transaction sizes and compute costs.

7.1 Design principles

One program, one configuration. All Sealroom state lives in accounts owned by the sealroom program, anchored by a single Config account at the seed config. Config fixes the USDC mint, the genesis hash of the cluster, the admin and arbitration authorities, the fee treasury and protocol fee, the bond minimum for each operator tier, the dispute settings and the pause flag. Every instruction that reads configuration derives Config from that seed and its stored bump, so a transaction cannot substitute a configuration account of its own.

Program-derived addresses for every record. All fourteen account types are PDAs, and their seeds encode their relationships: a Node is derived from its Platform and an index, a Lane from a Model and a Node, a Claim from a Lane and a recipient token account, a Dispute from an Operator and a sequence number. Instructions re-derive each address from the account's own stored fields and check parent links with Anchor has_one constraints, so an account from another operator, model or lane fails before the handler runs. Uniqueness comes from creation with init: a second PlatformPin for the same platform identity, a second Lane for the same pair or a second Dispute with the same sequence number cannot exist.

USDC through the original SPL Token program. Every amount is a u64 count of base units of a six-decimal mint; initialize rejects a mint with any other decimals. Every USDC movement is an SPL Token transfer_checked against the Config mint with six decimals, so a token account of another mint fails inside the token program. Fee and split arithmetic multiplies in u128 before dividing, every counter uses checked addition and subtraction, and no value anywhere in the program is a floating-point number.

Canonical associated token accounts. Where an account holds funds, its address follows from derivation. The bond vault is the associated token account (ATA) of the Operator PDA for USDC, a lane vault is the ATA of the Lane PDA, and a dispute deposit vault is the ATA of the Dispute PDA. Recipients are held to the same rule: each split entry's recipient_ata must be the canonical USDC ATA of its recipient_owner, an operator's payout_ata must be the canonical ATA of the operator authority, and both the fee treasury and the dispute forfeiture account must be canonical ATAs whose owners are recorded at the moment they are bound. Deferred claims pay into the beneficiary's canonical ATA unless governance selects the alternative destination policy.

Custody by the program, with no admin path to user funds. Funds leave a vault only when the program signs with that vault's PDA seeds, and every such path names its destination by rule:

The admin key signs none of these instructions. Its influence over destinations is limited to the identity of the fee treasury and of the forfeiture recipient, both of which change only through 48-hour proposals that anyone can read on chain before they take effect, and to the claim destination policy, which under either setting pays only accounts owned by the beneficiary.

Timelocks on changes that redirect value or trust, immediate effect for protective actions. Allowing a runtime, changing the fee or treasury, changing dispute settings and changing a model's split all wait a fixed delay compiled into the program. Revoking a runtime, revoking an attestation, freezing an operator and pausing the protocol take effect in the slot they land.

Fail-closed configuration. Configuration values that represent a policy decision are Option fields, and None means the decision has not been made. Instructions that depend on them refuse to run until they are set: distribution and claims require a claim policy, dispute admission requires a deposit, an arbitration authority, a deposit policy and a per-claimant cap, and a positive arbitration slash requires a configured deposit.

Separated authorities. The admin and the arbitration authority must be different keys at initialization, at every dispute-configuration proposal and again when that proposal is applied. The arbitration authority must also differ from the owner of the forfeiture account, so the party that dismisses a complaint is never the party that receives the forfeited deposit.

Permissionless cranks. apply_fee, apply_dispute_config, apply_split, open_lane, prepare_claim, distribute and settle_slash take no privileged signer, and record_attestation accepts any relayer as fee payer. Their outcome is determined entirely by on-chain state and by the arguments, which the program validates, so the keeper service, a model owner or any third party can submit them.

Bounded accounts. Each account is allocated at its maximum size when it is created, with every vector and string bounded by max_len, and instructions check the same bounds before writing. No account is reallocated. The largest, Model, is 2,348 bytes.

Events through self-CPI. Every instruction except initialize emits its events with Anchor's emit_cpi!, which records the event bytes as an inner instruction signed by the __event_authority PDA. Indexers read those bytes from the transaction's inner instructions, so events survive the 10 KB limit on textual program logs. initialize emits its single event to the program log and is reconciled from the Config account it creates.

7.2 Accounts

7.2.1 Encoding

Every account begins with Anchor's eight-byte discriminator, followed by version: u8 and bump: u8. The version is 1 for every account written by this program. Fields are Borsh-encoded in declaration order: public keys and hashes are raw 32-byte arrays, the runtime measurement is a raw 48-byte array, amounts, identifiers, slots and sequence numbers are little-endian u64, timestamps are little-endian i64 Unix seconds, basis points are u16, and enum variants are one-byte tags. An Option<T> takes one tag byte plus the size of T, a vector takes a four-byte length prefix plus its maximum element count times the element size, and a string takes a four-byte prefix plus its maximum byte length. The sizes below are the allocated maximums, including the discriminator.

Figure: The fourteen program accounts, the seeds that derive them and the parent links that instructions check.

Several value types are embedded inside accounts:

The enumerations are:

7.2.2 Config

Seeds ["config"]. One per deployment, created by initialize. It holds every protocol-wide parameter, the authorities and the two governance proposals that can be pending at once.

The four duration fields record the compiled constants for readers; handlers apply the constants themselves, so no instruction can shorten a delay by editing configuration.

7.2.3 VerifierSet

Seeds ["verifiers", epoch.to_le_bytes()]. The committee whose Ed25519 signatures admit attestations. initialize creates the epoch-0 set with exactly five distinct keys and threshold three; the allocation holds up to seven members.

7.2.4 Operator

Seeds ["op", authority]. One per vetted operator, created by the admin after off-chain vetting. The PDA is also the token authority of the operator's bond vault.

7.2.5 Platform, PlatformPin and GpuPin

A Platform is one physical server identity (the hash of its Intel PPID or PCK identity) registered by one operator, with the UEID hashes of the GPUs installed in it. Seeds ["plat", operator, platform_id_hash].

The Platform seeds include the operator, so platform identity is made unique across operators by a second, global account. A PlatformPin at ["platform_pin", platform_id_hash] is created with init in the same instruction, so a platform identity can be registered exactly once across all operators.

A GpuPin at ["gpu_pin", gpu_ueid_hash] pins one GPU globally to one platform and, once a node claims it, to one node. GpuPins are created and read by the program directly from the instruction's remaining accounts.

7.2.6 Node

Seeds ["node", platform, index.to_le_bytes()] with a u16 index. One confidential VM on a registered platform, with one to eight of the platform's GPUs.

7.2.7 Attestation

Seeds ["att", node]. One per node, overwritten by each committee-signed renewal. It is the record the key broker and callers read before trusting a node.

7.2.8 Runtime

Seeds ["rt", SHA-256(measurement)]. The 48-byte measurement is hashed only to form the seed; the full measurement is stored. A Runtime is the protocol-level allowlist entry for one measured image; each model additionally pins its own list of measurements.

7.2.9 Model

Seeds ["model", owner, id.to_le_bytes()]. A model listing: the commitment to its encrypted weights, the key broker that releases its data key, its eligibility policy, its price and its revenue split.

7.2.10 Lane

Seeds ["lane", model, node]. The settlement unit for one model served on one node. Callers pay into its vault, the lane's own ATA, and distribute allocates the vault balance.

Two identities reconcile every lane, where payments_in is all USDC that has entered the vault:

7.2.11 Claim

Seeds ["claim", lane, recipient_ata]. A deferred entitlement for one recipient on one lane. Claims are prepared for recipients whose positive share cannot be paid directly; healthy payouts need none.

7.2.12 Dispute and ClaimantDisputes

Seeds ["dispute", operator, sequence.to_le_bytes()]. One complaint, or one arbitration action, against an operator. The Dispute PDA is the token authority of its deposit vault.

ClaimantDisputes at ["claimant_disputes", claimant, operator] counts the open disputes one claimant has against one operator, across all of that claimant's models.

7.3 Instructions

7.3.1 Conventions

Every instruction except initialize carries two trailing accounts for self-CPI events: event_authority, the PDA at seed __event_authority, and program, the sealroom program itself. Three checks recur. The admin check compares the signer with Config.admin and raises Unauthorized. The running check raises Paused while Config.paused is set. The healthy-operator check raises OperatorFrozen for a frozen operator and InsufficientBond when bond_amount is below the minimum for the operator's tier (ConfigurationUnset if the tier has none).

Anchor validates account constraints before a handler runs. An account typed as a Sealroom account must be owned by the program and carry the right discriminator. A failed seeds, has_one, address, token::mint, token::authority or associated_token constraint aborts with Anchor's constraint error (ConstraintSeeds, ConstraintHasOne, ConstraintAddress, ConstraintTokenMint, ConstraintTokenOwner, ConstraintAssociated), and creating an account with init at an address already in use fails in the System Program. The program's own error codes, listed in 7.5, are raised by handler checks and by the constraints that name them explicitly. Every instruction is atomic: any failure, including a failed token CPI, reverts the whole transaction.

7.3.2 Admin and governance

initialize(genesis_hash, protocol_fee_bps, arbitration, tier_bond_minimums, verifiers)

• Signer: admin, which pays for Config and the epoch-0 VerifierSet.
• Accounts: program must be sealroom with programdata_address equal to program_data; program_data.upgrade_authority_address must equal admin (Unauthorized). config is created at ["config"] and verifier_set at ["verifiers", 0]. fee_treasury is a token account of usdc_mint.
• Checks: fee ≤ 10,000 bps (InvalidBps); exactly five distinct, non-default verifier keys (InvalidVerifierSet); exactly three tier minima (ConfigurationUnset) listed for tiers 1, 2, 3 in order (InvalidTier); mint decimals 6 (InvalidMint); arbitration different from the admin (AuthoritiesMustDiffer); the treasury is the canonical ATA of its owner for the mint (InvalidRecipients).
• Effects: writes Config with the admin, mint, genesis hash, fee, treasury and treasury owner, the four duration constants, active_verifier_epoch = 0, claim_destination_policy = CanonicalAta, max_open_per_operator = 8, settlement_mechanism = LaneBoundary and every undecided policy as None; writes the VerifierSet with threshold 3.
• Event: ConfigInitialized (program log).

set_paused(paused) — Signer: admin (admin check). Sets Config.paused. No event.

set_settlement_policy(claim_policy, rescue_policy, split_settlement_policy, claim_destination_policy) — Signer: admin. Sets claim_policy and claim_destination_policy. The two retained arguments are accepted and ignored; their fields stay None, so the admin cannot alter the lane-boundary settlement mechanism. No event.

propose_fee(protocol_fee_bps)

• Signer: admin. Accounts: treasury, a token account of the Config mint.
• Checks: treasury is the canonical ATA of its owner (InvalidRecipients); fee ≤ 10,000 bps (InvalidBps); no fee proposal pending (PendingSplitExists).
• Effects: pending_fee = { protocol_fee_bps, treasury_ata, treasury_owner, effective_at = now + 172,800 }. The treasury owner is snapshotted, so a later change of the token account's owner cannot redirect fees.
• Event: FeeProposed.

cancel_fee() — Signer: admin. Clears pending_fee (NoPendingSplit if none). No event.

apply_fee() — No privileged signer. Requires a pending fee (NoPendingSplit) whose effective_at has passed (TimelockPending). Writes protocol_fee_bps, fee_treasury_ata and fee_treasury_owner and clears the proposal. Event: FeeApplied.

propose_dispute_config(arbitration, dispute_deposit, max_open_per_claimant_operator, max_open_per_operator, deposit_policy)

• Signer: admin. Accounts: forfeiture_treasury, a token account of the Config mint.
• Checks: arbitration is neither the admin nor the default key (AuthoritiesMustDiffer); deposit and both caps are positive and the policy is ForfeitOnDismissal (ConfigurationUnset); no dispute proposal pending (PendingSplitExists); the forfeiture treasury is canonical (InvalidRecipients) and its owner is not the proposed arbitration key (AuthoritiesMustDiffer).
• Effects: pending_dispute_config with the snapshotted forfeiture owner and effective_at = now + 172,800.
• Event: DisputeConfigProposed.

cancel_dispute_config() — Signer: admin. Clears the proposal (NoPendingSplit if none). No event.

apply_dispute_config() — No privileged signer. Requires a pending proposal (NoPendingSplit) past its effective time (TimelockPending), and re-checks that the proposed arbitration differs from the current admin and from the forfeiture owner (AuthoritiesMustDiffer). Writes arbitration, dispute_deposit, both caps, dispute_forfeiture_ata, dispute_forfeiture_owner and dispute_deposit_policy, and clears the proposal. Event: DisputeConfigApplied.

set_dispute_config(arbitration, dispute_deposit, deposit_policy) — Retained in the interface. It always fails with GovernanceTimelockRequired and changes no state; dispute settings change only through the proposal path above.

7.3.3 Operators

register_operator(agreement_hash, tier)

• Signer: admin, who pays rent. The operator's authority is named but does not sign; the admin admits it after off-chain vetting.
• Accounts: operator created at ["op", authority]; bond_vault created if needed as the ATA of the Operator PDA for USDC; payout_ata must already exist as the canonical USDC ATA of authority; usdc_mint must equal Config.usdc_mint.
• Checks: admin check, running check, the tier has a configured minimum (ConfigurationUnset).
• Effects: a new Operator with zero bond, no unbond request, not frozen, zero counters and attestation_epoch = 0.
• Event: OperatorRegistered.

set_tier(tier) — Signer: admin. The tier must have a minimum (ConfigurationUnset). Sets Operator.tier. Event: OperatorTierSet.

freeze_operator(frozen) — Signer: admin. Sets or clears Operator.frozen. A frozen operator cannot deposit, unbond, withdraw, register platforms or nodes, or record attestations. Event: OperatorFrozen.

deposit_bond(amount)

• Signer: operator authority. Accounts: operator at ["op", authority] with has_one = authority and has_one = bond_vault; source, a USDC account whose token authority is the signer; bond_vault, a USDC account whose token authority is the Operator PDA.
• Checks: running; amount > 0 (InvalidAmount); not frozen (OperatorFrozen); no unbond request (Unbonding).
• Effects: transfer_checked of amount into the vault; bond_amount += amount. Tokens sent to the vault by any other route do not raise bond_amount.
• Event: BondDeposited.

request_unbond() — Signer: operator authority (has_one = authority). Requires a positive bond (InvalidAmount), no freeze (OperatorFrozen), no open dispute (OpenDispute) and no existing request (Unbonding). Sets unbond_at = now + 2,592,000. Event: UnbondRequested.

cancel_unbond() — Signer: operator authority. Requires a request (UnbondNotRequested) and clears it; no funds move. Event: UnbondCancelled.

withdraw_bond()

• Signer: operator authority. Accounts: Operator with has_one = authority, bond_vault; destination, a USDC account owned by the authority.
• Checks: not frozen (OperatorFrozen); no open dispute (OpenDispute); a request exists (UnbondNotRequested) and now ≥ unbond_at (TimelockPending); the vault holds at least bond_amount (InvalidAmount).
• Effects: transfers exactly bond_amount, signed by the Operator PDA, and resets bond_amount and unbond_at. Reserved slashes are already outside bond_amount and stay in the vault for settle_slash. A matured request with zero principal, as after a full slash, clears unbond_at without a transfer.
• Event: BondWithdrawn when a transfer occurs.

register_platform(platform_id_hash, gpu_ueid_hashes)

• Signers: operator authority (rent payer) and admin. Accounts: Operator with has_one = authority; platform created at ["plat", operator, platform_id_hash]; platform_pin created at ["platform_pin", platform_id_hash]; one remaining account per GPU, each the GpuPin PDA for its UEID hash.
• Checks: admin check; running; healthy operator; 1 to 8 distinct GPU hashes with one remaining account each (InvalidGpuSet); each GpuPin address is the canonical PDA, writable, empty and System-owned (GpuAlreadyClaimed).
• Effects: creates every GpuPin with node = None, the PlatformPin and the Platform with registered = true. The program tops up a GpuPin address only by the lamports it lacks for rent, so lamports sent to that address in advance cannot block its creation.
• Event: PlatformRegistered.

register_node(index, node_key, endpoint, gpu_model, gpu_ueid_hashes)

• Signer: operator authority (rent payer). Accounts: Operator with has_one = authority; Platform at its seeds with has_one = operator; node created at ["node", platform, index]; one GpuPin per GPU as remaining accounts.
• Checks: running; healthy operator; platform registered (PlatformNotRegistered); endpoint is a valid HTTPS URL of at most 128 bytes (InvalidEndpoint); 1 to 8 distinct GPU hashes, all on the platform, with one account each (InvalidGpuSet); each GpuPin is the program-owned canonical PDA for its hash (InvalidGpuSet), belongs to this platform and has no node (GpuAlreadyClaimed).
• Effects: sets each GpuPin's node; writes the Node with gpu_count equal to the number of hashes and status = Registered.
• Event: NodeRegistered.

The endpoint validator accepts only ASCII https:// URLs with no user information, ports from 1 to 65535, DNS labels of at most 63 characters without punycode prefixes, a host of at most 253 characters, dotted-quad IPv4 without leading zeros, or bracketed IPv6. The same validator governs Model.key_broker_url.

7.3.4 Attestation

record_attestation(commitment, epoch, sequence, recent_slot, recent_slot_hash)

• Signer: any relayer, which pays for the Attestation account on first use. In service the coordinator submits it after collecting committee signatures.
• Accounts: verifier_set at ["verifiers", epoch]; operator at its seeds; platform at its seeds with has_one = operator; node at its seeds with has_one = platform, operator; runtime at ["rt", SHA-256(runtime.measurement)]; attestation created if needed at ["att", node]; instructions and slot_hashes at the exact sysvar addresses.

The handler checks, in order:

1. Running (Paused) and healthy operator (OperatorFrozen, InsufficientBond).
2. Platform registered (PlatformNotRegistered) and node status Registered (NodeDisabled).
3. Every GPU hash on the node is on the platform (InvalidGpuSet).
4. Runtime not revoked and now ≥ runtime.effective_at (RuntimeNotAllowed).
5. The commitment's measurement equals the Runtime's and its platform equals the Platform PDA (AttestationMismatch).
6. tcb_status = UpToDate and method = Committee (InvalidTcb).
7. now < expires_at ≤ now + 86,400 (AttestationExpired) and, during unbonding, expires_at ≤ unbond_at (AttestationBeyondUnbond).
8. epoch equals Config.active_verifier_epoch and the set's epoch, and the set is not retired (InvalidVerifierSet).
9. The commitment's operator_epoch equals Operator.attestation_epoch (AttestationReplay).
10. The record is not latched revoked (AttestationRevoked), and sequence is 1 for a new account or the stored sequence plus 1 (AttestationReplay).
11. The pair (recent_slot, recent_slot_hash) appears in the SlotHashes sysvar, which holds up to 512 recent entries (InvalidRecentSlot).
12. At least three distinct members of the set signed the canonical message (below).

It then writes every commitment field, sets sequence and signed_sequence to the new sequence, stores the signer bitmap and canonical_message_hash = SHA-256(message), clears the revocation fields and emits AttestationRecorded.

The committee signs a 200-byte message. Its 32-byte commitment field is the SHA-256 of the 194-byte Borsh encoding of the AttestationCommitment:

Canonical message (200 bytes)
offset  size  field
     0    16  "sealroom.att.v0\0"
    16    32  program id
    48    32  Config.genesis_hash
    80    32  Node PDA
   112     8  verifier epoch (u64 LE)
   120     8  sequence (u64 LE)
   128    32  SHA-256(AttestationCommitment)
   160     8  recent slot (u64 LE)
   168    32  recent slot hash

AttestationCommitment (194 bytes, Borsh)
offset  size  field
     0    32  platform (Platform PDA)
    32    48  runtime_measurement
    80    32  gpu_rim_hash
   112    32  evidence_hash
   144    32  enclave_key_hash
   176     1  tcb_status
   177     8  expires_at (i64 LE)
   185     1  method
   186     8  operator_epoch (u64 LE)

The message binds the program, the cluster, the node, the committee epoch, the replay sequence, the evidence and a recent slot, so a signature cannot be replayed against another deployment, another node or another revision.

Signatures arrive in native Ed25519 precompile instructions placed earlier in the same transaction; the runtime verifies them before the program executes. The program reads the Instructions sysvar, visits every Ed25519 instruction before the current one and parses each. The instruction must carry no accounts, a signature count from 1 to 7 and a zero padding byte; each 14-byte offsets entry must reference data inside that same instruction (all three instruction indices equal to 0xFFFF), and each referenced signature, key and message must lie within bounds (InvalidSignatureInstruction). The message must be exactly the 200 canonical bytes (WrongAttestationMessage), the key must be a member of the set (UnknownVerifier), and no member may count twice, including across separate Ed25519 instructions (DuplicateVerifier). Fewer than three distinct members raises InsufficientSignatures. The set itself must still be five distinct keys at threshold three (InvalidVerifierSet).

revoke_attestation(reason_hash)

• Signer: the admin, or a member of the VerifierSet whose epoch is the active epoch (Unauthorized).
• Effects: if the record is not already revoked, sequence += 1, revoked_at = now, revoked_by = signer, revoke_reason_hash = reason_hash, and AttestationRevoked is emitted. A second revocation is a no-op. signed_sequence is unchanged.

clear_attestation_revocation()

• Signer: admin or arbitration (Unauthorized). The record must be revoked (AttestationNotRevoked).
• Effects: clears the three revocation fields and sets expires_at = now, so the record is expired at once. The sequence keeps the value revocation consumed, and a node returns to service only through a new committee record at the next sequence.
• Event: AttestationRevocationCleared.

A worked sequence: a record at sequence 10 has signed_sequence = 10. Revocation moves sequence to 11. A renewal signed for 11 before the revocation fails with AttestationRevoked while the latch is set, and with AttestationReplay after a clear, because the next acceptable sequence is then 12. Arbitration invalidates every attestation of an operator at once by advancing Operator.attestation_epoch: existing records carry the old epoch, the key broker and callers treat an epoch mismatch as revocation, and new records must commit to the new epoch.

7.3.5 Runtimes

allow_runtime(measurement, image_name, image_version, source_commit)

• Signer: admin, who pays rent. Accounts: runtime created if needed at ["rt", SHA-256(measurement)].
• Checks: admin check; image name 1 to 64 bytes, version at most 32 bytes and a source commit of exactly 40 lowercase hexadecimal characters (BoundsExceeded); the Runtime is new or revoked (RuntimeAlreadyAllowed).
• Effects: writes the metadata, proposed_at = now, effective_at = now + 172,800, revoked = false. Re-allowing a revoked runtime starts a full new delay.
• Event: RuntimeProposed.

revoke_runtime() — Signer: admin. Sets revoked = true and revoked_at = now with immediate effect: no new attestation for that measurement can be recorded. Event: RuntimeRevoked.

7.3.6 Models and splits

create_model(id, manifest_hash, key_broker, key_broker_url, allowed_runtimes, min_tier, min_bond, operator_allowlist, price, derivative_royalty_bps, base_model, split)

• Signer: owner, who pays rent. Accounts: model created at ["model", owner, id]; base_model optional; one remaining account for each split recipient ATA, including a derivative's royalty recipient.
• Running check (Paused).
• Split checks: 1 to 8 entries, each with positive weight and a distinct, non-default recipient ATA, summing to 10,000 bps (InvalidSplit); exactly one entry with role Operator (InvalidOperatorPayout); that entry is not locked (OperatorLockUnsupported); every recipient's account is present, owned by SPL Token, of the Config mint, owned by recipient_owner, and is that owner's canonical ATA, with a non-default owner (InvalidRecipients).
• Policy checks: 1 to 8 distinct allowed runtimes and at most 16 distinct, non-default allowlisted operators (BoundsExceeded); min_tier from 1 to 3 and royalty ≤ 10,000 bps (InvalidBps); non-default key broker key and a valid HTTPS broker URL of at most 128 bytes (InvalidEndpoint); positive per_call or max_per_call (InvalidAmount).
• Base model: when base_model is named, the matching Model account must be supplied (InvalidBaseModel); if its derivative_royalty_bps is positive, the split must contain a locked BaseModel entry with at least that weight, paid to the base owner's canonical ATA (RoyaltyRequired). With no base model, no base account may be supplied (InvalidBaseModel).
• Effects: writes the Model with split_revision = 1 and no pending split.
• Event: ModelCreated.

The Operator-role entry declares a weight only. At distribution its destination is always the serving operator's payout_ata with the operator authority as beneficiary, whatever address the model stored, so one model served by several operators pays each operator on its own lanes.

propose_split(entries)

• Signer: owner, with has_one = owner on the Model; locked-entry beneficiaries co-sign as remaining accounts when needed.
• Checks: running; the split and recipient-account checks of create_model; no pending split (PendingSplitExists). Every locked entry of the current split must either survive unchanged in recipient, owner and role, still locked and with weight not lower, or its recipient_owner must sign the transaction (LockedSplit).
• Effects: pending_split = { revision: split_revision + 1, proposed_at: now, effective_at: now + 604,800, entries }.
• Event: SplitProposed.

cancel_split() — Signer: owner. Removes the pending split (NoPendingSplit). Available while paused. Event: SplitCancelled.

apply_split() — No privileged signer. Running check; a pending split exists (NoPendingSplit) and its effective_at has passed (TimelockPending). Sets split_revision and split from the proposal. Event: SplitApplied. Lanes adopt the new revision one at a time at their next settlement boundary (7.3.7), so revenue already in a vault settles under the split it accrued under.

7.3.7 Lanes and distribution

open_lane()

• Signer: any payer. Accounts: Model and Node at their seeds, Node with has_one = operator, Operator at its seeds; lane created at ["lane", model, node]; vault created if needed as the canonical ATA of the Lane PDA for USDC, which also accepts a vault created in advance by another party.
• Checks: running.
• Effects: a Lane with zero counters and a snapshot of the model's current split and revision. Opening a lane grants no key eligibility; the key broker applies the model's policy separately.
• Event: LaneOpened.

distribute()

• No privileged signer. Accounts: Config, Model, Node (has_one = operator), Operator; Lane with has_one = model, node and vault_ata == vault; vault, the Lane's canonical ATA; fee_treasury, whose address must equal Config.fee_treasury_ata and differ from the vault; fee_claim, the Claim PDA for the treasury; then one pair of remaining accounts (recipient ATA, Claim PDA) per split entry, in split order.

The handler proceeds as follows:

1. Running (Paused) and claim policy set (ConfigurationUnset).
2. Resolve the lane's active split, replacing the Operator-role entry's destination with Operator.payout_ata and Operator.authority.
3. Compute available = vault.amount − reserved_amount (InvalidAmount if negative).
4. If available = 0, the call is a settlement boundary: when the model's revision differs from the lane's and the vault holds only reserved funds, copy the model split into the lane and emit LaneSplitActivated; then return.
5. Require two remaining accounts per entry (InvalidRecipients), authenticate the fee Claim (InvalidClaim), and read the fee rate and treasury owner (ConfigurationUnset).
6. Compute the allocation (formula below).
7. Before any transfer, validate every pair: the ATA equals the resolved recipient, is writable and is not the vault (InvalidRecipients); the Claim slot is either an authenticated Claim for this lane, recipient and beneficiary or an empty System-owned placeholder at the right PDA (InvalidClaim); a positive share whose account cannot receive it requires an initialized Claim (InvalidClaim). The fee is held to the same rule.
8. Pay the fee and each share. An account is payable when it is an SPL Token account of the Config mint, owned by the beneficiary and in the Initialized state. A payable recipient receives a transfer_checked signed by the Lane PDA. An unpayable share (frozen, closed or owner-changed account) is added to its Claim and to reserved_amount, and the other payouts proceed.
9. Assert that paid plus deferred equals available (Overflow).
10. Update the lane: total_allocated += available, total_distributed += paid, total_in = total_allocated, reserved_amount += deferred, last_distributed = now, and add the fee to eligible_protocol_fees_paid when it was paid directly to a treasury whose owner is neither the model owner nor the operator authority.
11. Emit LaneDistributed with the fee paid, allocated and deferred, the paid and deferred totals, the fee rate, the treasury, the hash of the active split, its revision and one payout record per entry.
12. Reload the vault and run the boundary step of 4. Because the lane and its vault are write-locked by the instruction, a payment lands wholly before or wholly after the boundary.

A worked example at the launch fee of 500 bps, with an illustrative split of 7,000 bps to the owner, 2,000 to the operator and 1,000 to a contributor listed last: an available balance of 1,234,567 base units gives a fee of floor(61,728.35) = 61,728 and a net of 1,172,839. The owner receives floor(820,987.3) = 820,987 and the operator floor(234,567.8) = 234,567. The contributor's floor is 117,283, and as the final entry it also receives the 2 base units of rounding remainder, for 117,285. Fee and shares sum to exactly 1,234,567. With no fee and eight equal entries of 1,250 bps, 11 base units divide as 1, 1, 1, 1, 1, 1, 1 and 4.

rescue_unopened_lane() — Retained in the interface. It always fails with RescueDisabled, whoever signs, and never moves or closes a vault. Funds sent to a lane vault before its lane exists are settled by open_lane and distribute like any other revenue, under the model's split and fee.

7.3.8 Claims

prepare_claim(recipient_ata, recipient_owner)

• Signer: any payer. Accounts: Model, Lane (has_one = model, node), Node (has_one = operator), Operator; claim created if needed at ["claim", lane, recipient_ata].
• Checks: claim policy set (ConfigurationUnset); the pair is an entry of the lane's resolved split or the configured treasury and treasury owner (InvalidClaim); an existing Claim must match lane, recipient and beneficiary (InvalidClaim).
• Effects: a zero-amount Claim bound to the beneficiary; an existing matching Claim is left unchanged. The keeper prepares Claims only for recipients whose positive share cannot be paid directly. No event.

claim_deferred()

• Signer: the Claim's beneficiary. Accounts: Lane; Claim at ["claim", lane, claim.recipient_ata] with has_one = lane, beneficiary; vault at lane.vault_ata with token authority the Lane PDA; destination, a USDC account owned by the beneficiary and different from the vault.
• Checks: the destination is owned by the beneficiary and of the mint, and under CanonicalAta it is the beneficiary's canonical ATA (InvalidClaimDestination); claim policy set (ConfigurationUnset); reserved_amount ≥ amount (InvalidClaim). A zero amount returns without effect.
• Effects: transfers the amount, signed by the Lane PDA; adds the Claim's eligible fee portion to eligible_protocol_fees_paid; zeroes the Claim; reduces reserved_amount; increases total_distributed. Claims are not gated by the pause flag.
• Event: DeferredClaimPaid.

7.3.9 Disputes and arbitration

open_dispute(sequence, evidence_hash)

• Signer: the claimant, who must own the model (model derives from the claimant's key and model.owner == claimant, else Unauthorized) and pays rent.
• Accounts: Operator at its seeds; Node with has_one = operator; Lane with has_one = model, node; claimant_disputes created if needed at ["claimant_disputes", claimant, operator]; dispute created at ["dispute", operator, sequence]; source, a USDC account of the claimant; deposit_vault created if needed as the Dispute PDA's ATA.
• Checks: deposit, arbitration and deposit policy configured and the deposit positive (ConfigurationUnset); sequence == Operator.next_dispute_sequence (AttestationReplay); policy ForfeitOnDismissal (ConfigurationUnset); the lane's unused credit covers the deposit (InsufficientPaidUsage); the per-claimant cap is configured (ConfigurationUnset); the operator is below max_open_per_operator and the claimant below its cap (DisputeLimitReached).

• Effects: consumes the credit, increments the claimant counter, transfers the deposit into the deposit vault, increments next_dispute_sequence and open_dispute_count, and writes an Open Dispute that snapshots the deposit, the lane and node, the forfeiture destination and beneficiary, and admission_credit_used = admission_required_amount = deposit. Consumed credit never returns, whatever the ruling. At the launch fee of 500 bps, the eligible fees behind one deposit correspond to directly paid lane revenue of 20 times the deposit.
• Events: DisputeAdmission (credit used and remaining), then DisputeOpened.

rule_dispute(for_claimant, slash_amount, freeze, revoke_attestations, ruling_hash)

• Signer: Config.arbitration (Unauthorized). A proposed but unapplied arbitration key has no authority.
• Accounts: Operator with has_one = bond_vault; Dispute with has_one = operator, deposit_vault; ClaimantDisputes matching the Dispute's claimant and operator; the bond vault and deposit vault.
• Checks: the dispute is Open (DisputeAlreadyRuled); slash_amount ≤ bond_amount, and a dismissal carries no slash, freeze or revocation (InvalidAmount).
• Effects: bond_amount −= slash_amount, pending_slash_amount += slash_amount; frozen = true if ordered; attestation_epoch += 1 if ordered; open_dispute_count and the claimant counter each decrease by one. A claimant ruling sets claimable_amount = deposit; a dismissal sets forfeited_amount = deposit. slash_pending_amount records the slash. The ruling performs no token transfer, so a frozen token account cannot block it.
• Event: DisputeRuled, which records the ruling authority, the deposit returned or forfeited, the forfeiture destination, the freeze state and the new attestation epoch.

arbitrate_operator(sequence, evidence_hash, slash_amount, freeze, revoke_attestations, ruling_hash)

• Signer: Config.arbitration (Unauthorized), which pays rent.
• Accounts: Operator; claimant, a named wallet; optional model, node and lane; ClaimantDisputes and Dispute created as in open_dispute; the deposit vault created if needed.
• Relationship: either all three of model, node and lane are supplied, or none. When supplied, each must be the canonical PDA for its own fields, the node must belong to this operator, the lane must link that model and node, and the model's owner must be the claimant (Unauthorized on any mismatch or a partial set).
• Admission: a zero slash needs nothing more. A positive slash requires a configured, positive deposit (ConfigurationUnset) and a lane whose lifetime eligible_protocol_fees_paid is at least that deposit (InsufficientPaidUsage); no credit is consumed.
• Checks: sequence == next_dispute_sequence (AttestationReplay); slash_amount ≤ bond_amount (InvalidAmount).
• Effects: advances the sequence; reserves the slash as in rule_dispute; applies freeze and revocation; writes a Dispute already RuledForClaimant with zero deposit, arbitration_initiated = true, admission_credit_used = 0 and admission_required_amount equal to the threshold applied. It takes no open-dispute slot, so a security action is available even when every slot is occupied.
• Event: ArbitrationAction.

settle_slash()

• Signer: any; the account in the arbitration position is not compared with Config.arbitration, so settlement is permissionless. Accounts as in rule_dispute.
• Checks: the dispute is no longer Open (DisputeAlreadyRuled). A zero pending slash returns without effect.
• Effects: transfers slash_pending_amount from the bond vault to the deposit vault, signed by the Operator PDA; claimable_amount += amount; pending_slash_amount −= amount; slash_pending_amount = 0.
• Event: SlashSettled.

claim_dispute() — Signer: the claimant (has_one = claimant, deposit_vault). The destination must satisfy the destination policy (InvalidClaimDestination) and the dispute must be ruled (DisputeAlreadyRuled). Transfers claimable_amount from the deposit vault, signed by the Dispute PDA, and zeroes it. Event: DisputeClaimPaid.

claim_forfeited_deposit() — Signer: the Dispute's forfeiture_beneficiary (Unauthorized). The dispute must be Dismissed (DisputeAlreadyRuled) and the destination must satisfy the policy (InvalidClaimDestination). Transfers forfeited_amount to the beneficiary and zeroes it. Event: DisputeDepositForfeited.

The dispute amounts move through these states:

7.3.10 Events

set_paused, set_settlement_policy, cancel_fee, cancel_dispute_config and prepare_claim emit no event; their effects are read from the accounts they change.

7.4 Timelocks and governance actions

Four durations are compiled into the program as constants and copied into Config for readers:

A proposal records effective_at = now + delay using the cluster Clock's Unix timestamp, and its application succeeds in any later transaction whose Clock timestamp is at least effective_at. A fee proposed at Unix time T can be applied from T + 172,800 onward; a split proposed at T can be applied from T + 604,800; an unbond requested at T can be withdrawn from T + 2,592,000.

The arbitration authority changes only through the dispute-configuration path, so a newly proposed arbitrator waits 48 hours, is visible on chain throughout, and cannot rule until the change applies. Combined with the separation checks, the admin can neither appoint itself arbitrator nor pair a settings change with an immediate ruling.

These actions take effect in the transaction that carries them:

The pause flag stops the instructions that create registry entries or allocate revenue: register_operator, deposit_bond, register_platform, register_node, record_attestation, create_model, propose_split, apply_split, open_lane and distribute. All other instructions run while paused, including unbonding and withdrawal, cancellations, revocations, freezes, governance proposals and applications, claim preparation and deferred claims, dispute admission, rulings, arbitration actions, slash settlement and dispute claims.

7.5 Errors

The program defines 54 error codes, numbered from 6000 in Anchor's custom-error range:

7.6 Upgrade authority and program deployment model

The program is deployed through Solana's upgradeable BPF loader. Its executable lives in a ProgramData account that records the upgrade authority, the only key that can replace the executable.

At launch the upgrade authority is the deployer, and the program binds its own initialization to that key. The initialize accounts require program to be the sealroom program whose ProgramData address is the supplied program_data, and program_data.upgrade_authority_address to equal the admin signer. Because Config sits at the fixed seed config and is created with init, initialization happens exactly once, and only the holder of the upgrade authority can perform it. A party watching the deployment cannot initialize first with its own mint, treasury or verifier set. The launch transaction writes the configuration described in 7.3.2: the USDC mint, the genesis hash, the protocol fee of 500 bps and its canonical treasury ATA, the three tier bond minima, the five-member epoch-0 committee at threshold three, the optional arbitration key, and the signer as Config.admin.

After launch the upgrade authority passes to governance: the loader's authority-transfer instruction moves it from the deployer to the governance multisig, a Squads multisig operated with timelocks, and from then on a new executable can be written only with that multisig's approval. A Squads authority signs program instructions through the Squads program, so the same signing path serves every governance role. Arbitration is a separate named multisig, supplied at initialization or installed through the 48-hour dispute-configuration path, and each role's powers inside the program are exactly those listed in 7.3 and 7.4.

Upgrades keep the wire format. The upgrade procedure compares the instruction arguments, the account fields and their order, and the signer requirements of the new build with the deployed interface, and refuses a build that changes them. Retired behavior stays in the interface with fixed results instead of being removed: set_dispute_config and rescue_unopened_lane remain callable and always fail with their own error codes, rescue_policy and split_settlement_policy remain in Config and always hold None, and the UnopenedLaneRescued event type remains decodable. Every client, indexer and historical transaction therefore keeps decoding against the current IDL. Each account carries a version byte, 1 for every account in this release, as the marker for any future layout.

The program identity is part of what verifiers sign. Bytes 16 to 47 of the canonical attestation message carry the program id and bytes 48 to 79 the genesis hash stored in Config, so committee signatures produced for this deployment are valid nowhere else.

7.7 Transaction sizes and compute

Legacy and v0 Solana transactions are limited to 1,232 bytes on the wire, and every transaction to 1.4 million compute units. Two of the program's transactions carry enough data that their size is a design input: record_attestation, with its committee signatures, and distribute, with its per-recipient accounts.

Attestation. A committee attestation is one transaction with two instructions. The first is a single native Ed25519 instruction carrying all three signatures over one shared copy of the 200-byte message; the second is record_attestation:

record_attestation names thirteen accounts, and the transaction also references the Ed25519 program. In a legacy message every one of those addresses costs 32 bytes, and the complete transaction is 1,361 bytes, over the 1,232-byte limit. The coordinator therefore sends it as a v0 transaction with an address lookup table that holds the instruction's fixed accounts: Config, the VerifierSet, the Operator, Platform, Node, Runtime and Attestation accounts, the Instructions and SlotHashes sysvars and the System Program. Each looked-up account costs a one-byte index. The fee payer and the invoked programs stay in the static key list.

Distribution. distribute takes no arguments, so its instruction data is the eight-byte discriminator, but it names twelve accounts plus two per split entry: 28 accounts for eight recipients. It performs one transfer_checked CPI for the fee and one for each payable share, plus the self-CPIs that record its events. Healthy payouts and zero-amount shares use empty placeholder addresses in their Claim slots, so a healthy distribution allocates no Claim rent. With the distribution accounts in a lookup table, the eight-recipient transaction is 268 bytes.

Measured on the compiled program:

Compute varies slightly with the addresses involved, because each PDA derivation searches for its bump; the coordinator figure is the range observed across submissions. Reserving a frozen recipient's share in place of transferring it adds about a thousand units, and the costliest measured transaction, distribution to the fee and eight recipients, stays far below the 1.4-million-unit transaction limit.

Transaction builders follow the same budget. They place idempotent ATA-creation instructions in the same transaction as create_model or propose_split when the packet allows. Splits whose eight recipient ATAs are all new use a configured lookup table or a separate account-setup transaction, and a preview that would exceed 1,232 bytes is returned to the wallet as blocked instead of as a transaction it cannot submit. The keeper and the API load the deployment's configured lookup tables before building, so the attestation and distribution transactions above are the forms the service submits.

8. Payments over x402

A call on Sealroom is an HTTPS request to a node's registered endpoint, paid in USDC over x402 version 2. The caller needs no account with the operator, the owner or Sealroom; a Solana wallet holding USDC is enough, so AI agents can pay. Every payment for a model served by a given node lands in one token account, the vault of the lane for that (model, node) pair. No Sealroom instruction runs per call: the split between protocol, operator and contributors happens later, in one distribute per lane (chapter 9).

The caller signs a USDC transfer for the quoted amount, filling only its own signature slot. The node runtime quotes the price, has the payment verified, runs inference inside the enclave and has the payment settled; it holds no facilitator or channel custody key. The facilitator issues the requirements, verifies the signed transaction, pays the network fee as fee payer, broadcasts, confirms and settles usage vouchers.

8.1 Parties and endpoints

All write endpoints are rate-limited per client address and answer 429 with Retry-After when the limit is reached. Browser callers are admitted only from exact configured origins.

8.2 Reading the attestation before the call

Before it sends a prompt, the caller establishes from Solana that the node is attested and that the TLS session it is about to open terminates inside the attested enclave. The node's runtime generated three key pairs inside the CVM at boot: an HPKE key pair (X-Wing: ML-KEM-768 plus X25519), a TLS key pair and an Ed25519 voucher key pair. The hash of their public keys is the enclave_key_hash that three verifiers signed into the node's Attestation account.

The caller's SDK performs these steps:

1. Derive the accounts: Model at ["model", owner, id:u64], Node at ["node", platform, index:u16], Attestation at ["att", node], Lane at ["lane", model, node].
2. Read the Attestation and check that it is current: revoked_at is empty, expires_at is in the future (the program never accepts an expiry more than 86,400 seconds after recording), tcb_status is UpToDate, and operator_epoch equals the operator's current attestation_epoch.
3. Check the model's policy against the node: the attestation's 48-byte runtime_measurement is on the model's allowed_runtimes and its Runtime account is active; the platform is registered to the node's operator; the operator is not frozen, its tier is at least min_tier, its bond is at least the larger of min_bond and its tier minimum, and it is on the model's operator_allowlist when that list is non-empty; the node is not disabled; the protocol is not paused. The registry API serves the same rules at /v1/eligibility?modelId=…&nodeId=… with one reason code per failed check, such as attestation_revoked, runtime_not_allowed or operator_frozen.
4. Obtain the node's public-key transcript, recompute enclave_key_hash and compare it with the 32 bytes stored in the Attestation account. The registry publishes tlsPublicKeyHash and voucherPublicKey for an attestation only after this recomputation succeeds against the chain value.
5. Open TLS to Node.endpoint, hash the server's 32-byte TLS public key and compare it with tls_key_hash. On a mismatch the caller aborts before sending the prompt.
6. Keep the voucher public key. For upto calls it is the only key whose usage vouchers the caller accepts.
7. Read the model's price and the lane's vault_ata.

The on-chain price is a Borsh enum in the Model account:

All amounts are USDC base units with 6 decimals, so 1,000,000 base units are 1 USDC.

8.3 The request and the 402 challenge

The caller posts the call to the node with a caller-chosen requestId (a UUID that serves as idempotency key), the modelId, nodeId and laneId read in 8.2, the paying wallet as caller, the scheme (exact or upto), for upto a ceiling in base units, and the prompt.

The node hashes the prompt, bodyHash = SHA-256(prompt), and forwards everything except the prompt, together with bodyHash, to the facilitator's /requirements. The facilitator then:

1. Confirms that its RPC endpoint reports the configured genesis hash.

2. Reads the registry accounts from chain and runs the eligibility rules. An ineligible node fails with NODE_INELIGIBLE: followed by the reason codes.

3. Reads the Lane and checks that lane.model and lane.node are the requested model and node (LANE_IDENTITY_MISMATCH).

4. Computes the amount from the scheme and the on-chain price:

   exact: amount = per_call upto, Upto-priced model: 1 <= ceiling <= max_per_call and ceiling <= facilitator_max_ceiling upto, Exact-priced model: per_call <= ceiling <= facilitator_max_ceiling

   A metered (Upto) model cannot be bought with exact; the request fails with METERED_MODEL_REQUIRES_UPTO. A ceiling outside its bounds fails with PAYMENT_CEILING_INVALID.

5. Derives the session key that makes the call idempotent:

   request_id_hash = SHA-256(JSON([genesis_hash, requestId, modelId, nodeId, caller]))

   If a session with this hash exists, the facilitator returns its stored requirements unchanged, provided the scheme, amount, bodyHash and lane are the same; otherwise it answers IDEMPOTENCY_CONFLICT. A retried request therefore gets the same invoice and can never be charged twice.

6. Sets the session expiry to the chain clock plus 120 seconds and takes a recent blockhash.

7. Stores the session with status offered, the requirements, the attestation account and its signed revision, and, for upto, the voucher public key read from the attested evidence.

The requirements object is the x402 PaymentRequirements record:

payTo is the vault token account itself. A wallet must send to it directly and must not treat it as an owner address from which to derive another associated token account.

When the request carries no PAYMENT-SIGNATURE header, the node answers 402 Payment Required. The body and the PAYMENT-REQUIRED header carry the same JSON, the header as base64:

{
  "x402Version": 2,
  "resource": { "url": "https://<node endpoint>/v1/chat/completions", "mimeType": "application/json" },
  "accepts": [{
    "scheme": "exact",
    "network": "solana:<genesis hash prefix>",
    "asset": "<USDC mint>",
    "payTo": "<lane vault token account>",
    "amount": "<per_call>",
    "maxTimeoutSeconds": 120,
    "extra": {
      "feePayer": "<facilitator fee payer>",
      "memo": "sealroom:<sessionId>",
      "recentBlockhash": "<blockhash>",
      "lastValidBlockHeight": "<height>",
      "sessionId": "<sessionId>",
      "laneId": "<lane>"
    }
  }]
}

8.4 The payment transaction

The caller builds exactly one transaction shape. The facilitator rejects anything else, which keeps it compatible with the fixed instruction layout that SVM x402 facilitators validate around a single TransferChecked. The SDK function buildX402PaymentTransaction(requirements, caller) produces it.

The destination of instruction 2 is payTo (the lane vault) for exact and extra.escrow for upto. The message is a v0 message whose fee payer is extra.feePayer, so the caller needs no SOL. It uses extra.recentBlockhash, no address lookup tables and exactly two signatures, the facilitator's in slot 0 and the caller's in slot 1, and it serializes to between 100 and 1,232 bytes. The caller's USDC associated token account must already exist; the transaction contains no account-creation instruction. The wallet signs with signTransaction, filling only the caller's slot. It never uses sign-and-send: the facilitator broadcasts after its own checks.

The caller wraps the signed transaction in an x402 payment payload and retries the identical request with the header PAYMENT-SIGNATURE: base64(JSON(payload)). The node accepts a header of at most 8,192 characters.

{
  "x402Version": 2,
  "resource": { "url": "https://<node endpoint>/v1/chat/completions" },
  "accepted": { "...": "the requirements object from the 402, unchanged" },
  "payload": { "transaction": "<base64 of the partially signed v0 transaction>" }
}

The facilitator accepts the transaction only when every check below passes. Each failure has its own error code.

Fee-payer isolation means the facilitator's signature can only pay the network fee. Nothing in the transaction can move the facilitator's own lamports or tokens.

8.5 Verify, serve, settle

Figure: an x402 call from the attestation read through the 402 challenge, verification, inference and settlement into the lane vault.

The node orders the paid call so that the caller is charged only for a completion that an eligible enclave has already produced, and so that a completion that has been paid for is always delivered.

1. Challenge. The caller sends the request without a payment header and receives the 402 described in 8.3.
2. Signed retry. The caller signs the payment transaction and repeats the identical request with PAYMENT-SIGNATURE.
3. Binding. The node fetches the requirements for this request again (the facilitator returns the stored session) and requires the payload's accepted object to equal them field for field (PAYMENT_REQUEST_BINDING_MISMATCH). A payment signed for another request, lane or amount is rejected here.
4. Verify. The node posts the payload to /verify. The facilitator checks x402Version is 2, the resource URL is the session's, accepted equals the stored requirements, the transaction matches any earlier submission for the session, the session is in a payable state and unexpired, the node is still eligible, and the wire passes every check in 8.4. It returns { isValid: true, payer, sessionId }. It signs nothing and moves no funds.
5. Serving check. The node reads chain state and requires that it is still eligible and that the attestation account and signed revision are the ones its data-key release was bound to (NODE_KEY_RELEASE_STALE otherwise).
6. Inference. The runtime executes the call inside the enclave.
7. Second serving check. The node repeats step 5 with fresh chain state.
8. Settle. The node posts the same payload to /settle. The facilitator validates it again, adds its fee-payer signature, and stores the signed bytes and their hash with status processing before it broadcasts. It then broadcasts, waits for confirmed commitment, and compares the destination account's pre- and post-transaction token balances in the confirmed transaction: the increase must equal the session amount exactly (PAYMENT_POST_BALANCE_MISMATCH). The session moves to settled for exact and to funded for upto.
9. Voucher (upto only). The enclave signs a usage voucher and the node posts it to /settle-voucher (8.7).
10. Response. The node returns 200 with the completion and a PAYMENT-RESPONSE header carrying the base64 JSON receipt { success, transaction, network, payer, sessionId }. For upto the body also carries the voucher and its signature, so the caller can check the charge against the voucher key it read in 8.2.

If the node loses eligibility at step 5 or step 7, the call ends with an error before step 8, and nothing has been broadcast. Once step 8 has confirmed, the node returns the completion it already holds, even if the attestation is renewed or revoked in the meantime.

The facilitator records each session in one of these states:

Every state change is a compare-and-set on the previous status and payload, and signed bytes are stored before any broadcast. A retry first looks the stored signature up in transaction history and rebroadcasts the same bytes only while their blockhash is valid. A settled session returns its stored receipt; a refunded or expired one is never accepted as proof of payment.

8.6 The exact scheme

exact is a fixed price per call. The caller's TransferChecked moves per_call straight into the lane vault, and settlement is the confirmation that the vault balance rose by exactly that amount. The vault is the USDC associated token account of the lane PDA, so only the sealroom program, signing for the lane through distribute and claim_deferred, can move funds out of it. Whatever the model's split, each call stays one transfer to one recipient; an eight-recipient split costs nothing extra per call and is paid for once per distribute.

8.7 The upto scheme

upto is metered billing under a ceiling. The caller escrows the ceiling in a payment channel of the Solana Foundation payment-channels program (CHNLxYvVA28MJP9PrFuDXccuoGXAx7jBacfLEkahyGsX). After serving, the enclave signs a voucher for the actual charge, the facilitator settles that amount to the lane vault and returns the rest to the caller. The lane vault is the channel's only payee; the split stays in sealroom.

The requirements for an upto session add two fields. extra.escrow is the channel's escrow token account, and it is the destination of the caller's TransferChecked. extra.channelId identifies the channel for this session:

The caller signs the same four-instruction transaction with amount set to its ceiling. Settling it moves the ceiling into escrow, and the session becomes funded.

Usage price

The enclave counts the call's input and output tokens and prices them with integer arithmetic. The rates are USDC base units per million tokens.

The division rounds the whole call up once, so the charge exceeds the exact fractional price by less than one base unit. Token counts, rates and the result are checked against the u64 range, and a charge above max_per_call is refused (PAYMENT_USAGE_EXCEEDS_MODEL_MAX).

Worked example, with a sample price of 3,500,000 base units per million input tokens (3.50 USDC) and 10,000,000 per million output tokens (10 USDC), and a sample ceiling of 20,000 base units:

The lane vault receives 8,333 base units (0.008333 USDC) and the caller gets 11,667 back.

The usage voucher

The voucher is a JSON object signed by the enclave's Ed25519 voucher key. That key was generated inside the CVM, and its public key is one of the three inputs to the enclave_key_hash that the verifier committee signed. The operator never holds the private key, so it cannot produce a voucher for a larger charge.

The signed message is the UTF-8 JSON serialization of these fields in table order, with genesisHash (the cluster genesis hash) inserted after domain. The 64-byte Ed25519 signature travels as base64.

/settle-voucher accepts the voucher only when all of these hold; otherwise it answers VOUCHER_INVALID:

1. The session is upto, funded, and has no refund in progress.
2. laneId, channelId and requestId equal the session's lane, channel and request hash, and nonce is 1.
3. attestationId and attestationRevision equal the node's current attestation on chain and the revision stored when the session was offered.
4. signer equals the voucher key in the attested evidence. The facilitator loads the evidence archived under the on-chain evidence_hash, recomputes both evidence_hash and enclave_key_hash, and requires both to match the Attestation account and the evidence's node to be this node.
5. expiresAt is not in the past and not later than the session expiry.
6. cumulativeAmount is at most the escrowed ceiling.
7. The Ed25519 signature verifies over the message for signer.

The facilitator then settles in one transaction. A TransferChecked from escrow to the lane vault pays cumulativeAmount when it is positive; a second TransferChecked from escrow to the caller's USDC associated token account returns ceiling - cumulativeAmount when it is positive; a memo sealroom:settle:<sessionId> closes the instruction list. Payment and refund land together or not at all. The session stores the voucher hash: the same voucher submitted again returns the same receipt, and a different voucher for a settled session fails with VOUCHER_REPLAY.

A funded session whose expiry passes without a voucher is refunded in full. The keeper calls /reconcile, which sends the whole ceiling from escrow back to the caller with the memo sealroom:expire:<sessionId> and marks the session refunded. The same pass finishes interrupted payment and settlement transactions and marks a processing session expired when its transfer never landed.

8.8 Header reference

For browser callers the node exposes PAYMENT-REQUIRED, PAYMENT-RESPONSE and Retry-After to scripts and accepts PAYMENT-SIGNATURE as a request header. A rejected call returns { success: false, errorReason } carrying one of the codes named in this chapter.

9. Settlement and distribution

Payments accumulate in lane vaults. Distribution turns a vault balance into payouts: the protocol fee to the treasury, the operator's share to the operator that runs the node, and every other split entry to its recipient. One permissionless instruction, distribute, does this for one lane in one transaction, and either every transfer in it succeeds or none does.

9.1 Lanes

A lane exists for each (model, node) pair that serves traffic. Anyone can open one with open_lane; the payer signs and pays rent, and the protocol must not be paused. The instruction creates the Lane account at ["lane", model, node] and the vault, the USDC associated token account whose authority is the lane PDA. If someone created that token account in advance, open_lane adopts it. The lane copies the model's current split and split revision into active_split and active_split_revision. Opening a lane gives the node no right to a data key; key release depends only on the attestation and the model's policy.