Skip to main content
Anchoring makes a receipt permanent and checkable. It also makes it visible. Neither anchor target publishes what a run decided: the transcript stays owner-only on both. The difference is what an observer of the chain can learn.

​
Choosing

Pick the target in the dashboard under Settings → Record anchoring. The Starknet option is enabled only when the deployment has the Starknet registry, relayer and record key configured. The setting applies to runs started after the change. Receipts already issued keep the chain they were anchored on. The API response does not name the chain. To see where a record went, check the host of explorerTx, or anchorChain in the transcript JSON.

​
Fallback

If Starknet is selected but not available on the deployment, runs anchor on Base, and Settings shows a warning while that is the case. A run also anchors on Base if the enclave build that signed it produced the Base digest instead of the Starknet one. Settings does not flag that second case, so check anchorChain when it matters.

​
Encryption

The encrypted record holds runId, transcriptRoot, outputHash, hostdata, the transcript URL and the judge address. It is encrypted with AES-256-GCM under a per-record key, derived with HKDF-SHA256 from a master key Chance holds, using the runId as salt. This is custodial: Chance can decrypt a record for its owner. Chain observers see only ciphertext. The judge signs the commitment, not the ciphertext, so decryption checks that the recovered fields hash to the stored commitment.

​
Verification

Checking a Starknet receipt works the same way as a Base one (see Receipts), with two differences. The signature covers (Starknet chain id, registry, commitment), and the onchain check asks the Cairo registry for the commitment. The transcript JSON carries starknetChainId, starknetRegistry and commitment for this.