PROTOCOL / GUIDE

Verification

Replay public evidence: Arc epochs and requests, Robinhood rounds and requests.

Arc: collect independent chain evidence

Obtain chain ID, proxy and registry identities, canonical source anchor and randomness target blocks, request/publication/acceptance receipts and timestamps from independently trusted chain data. Resolve implementation history and configuration at those receipts: a proxy runtime hash alone is insufficient. EpochCommitted emits the complete accepted packet once when an epoch is used: for a drand epoch the round number, its scheduled time and its 64-byte BLS signature, for an earlier epoch the signed API record. Each accepted request records abi.encode(Proof), 416 bytes. No private keeper database or keeper connection is required.

Arc: replay epoch and request

Use replayEpochCommitment to reconstruct recipe selection, validate the committed record against its recipe and match the stored epoch record: a drand round against its recipe's round template, its scheduled time and its BLS signature under the registered group key, a signed API record against its data template and signer. Supply the catalog in force for the epoch (catalogAt, or CatalogScheduled events) and the definition of any recipe beyond the SDK's built-in recipes: readEpochRecipes reads getRecipe and, for a beacon, beaconOf, or rebuild them from RecipeRegistered and BeaconRegistered events. Beacon epochs need @d20dao/vrf-sdk 0.5.0 or newer; 0.4.0 rejects a beacon's 64-byte signature. Then call replayCoordinator with request context, fixed configuration, epoch evidence, proof and recorded acceptance. It checks request-block epoch membership, resolved epoch hash, the post-publication target, key and configuration, seed, VRF, mapping, transcript and acceptance time. Preserve both requestBlock and targetBlock; they need not be equal. Replay computes the pairing check in TypeScript (verifyBeaconRound) and does not call the registered verifier, so check that verifier's address and runtime code against the deployment manifest.

Robinhood Chain: replay a request

getRoundRequest(id) returns every seed input, the bound round and its cached randomness, the result, the proof and transcript hashes and the status in one read. FulfillmentEvidence carries the 416-byte proof, and the fulfilment transaction carries the round's 64-byte signature. Check that the request block's timestamp plus 3 seconds binds the round, that sha256 of the signature is the round's randomness and that the signature verifies under evmnet's group key. Recompute the seed, verify the VRF proof under the manifest's key and match proofHash, transcriptHash and the mapped result. Then check the implementation the proxy ran and whether the block is settled on Ethereum. The Explorer runs all of this for a request ID. @d20dao/vrf-sdk 0.6.2 or newer replays Robinhood requests, and so does the Explorer.

Explorer

Understand verification boundaries

Reject altered signed bytes, noncanonical packets, mismatched commitments, invalid proofs and acceptance outside the request deadline. Establish callback delivery separately from proof acceptance. A valid drand signature establishes what the beacon's key signed for that round, not that the beacon is unbiased or independent of its operators. The homepage Evidence Explorer checks, in the browser, the BLS signature of drand evmnet round 21115909, the round Arc Mainnet epoch 12448 committed, against evmnet's published group key. It checks that signature only: not the epoch's selection, chain inclusion or complete VRF validity.

Work with your agents

Copy a task-specific prompt with the protocol references and integration rules.

Plain text Agent guide

View prompt

Add independent D20DAO proof verification to my application using the reviewed SDK exports (@d20dao/vrf-sdk 0.6.2 or newer replays Arc drand epochs; @d20dao/vrf-sdk 0.6.2 or newer replays Robinhood requests, and so does the Explorer.). Verify epoch evidence, request binding, VRF, deterministic mapping and transcript, then separately verify canonical receipts and historical implementation context. Show missing evidence as unknown.

Read these public references first; do not guess signatures, addresses or limits:
- This guide: https://d20dao.org/docs/verification (full text of every guide: https://d20dao.org/llms-full.txt, agent guide: https://d20dao.org/agents.md)
- SDK README and AGENTS.md: https://github.com/d20dao/d20-sdk (also inside the installed package). It lists the randomness options, callback gas bounds, how to wait for results, compiler setup and gas needs for refunds and retries.
- Protocol source (contracts and replay library): https://github.com/d20dao/d20-sdk/tree/main/protocol, pinned to commit 98e537fb249dd0d3365b8d78e6040a9323a65a88 by PROTOCOL-PROVENANCE.json
- Deployment manifests: https://d20dao.org/deployments/arc-mainnet.json, https://d20dao.org/deployments/arc-testnet.json, https://d20dao.org/deployments/robinhood-mainnet.json, https://d20dao.org/deployments/robinhood-testnet.json
- Integration skills and templates: https://github.com/d20dao/skills (d20-consumer: methods.md, RandomnessConsumer.sol, mappings.mjs)
- Explorer for checking requests: https://d20dao.org/explorer (arc.d20dao.org for Arc Mainnet, arc-testnet.d20dao.org for Arc Testnet; Robinhood requests are read from the chain)
- Agent API, for agents and services without a contract: https://d20dao.org/docs/agents (0.05 USDC per call over x402)
If a link is unavailable, use the installed package's README, AGENTS.md, ABIs and protocol sources.

Networks: Arc Mainnet chain 5042 (live, USDC; RPC https://rpc.mainnet.arc.io; explorer https://explorer.arc.io); Arc Testnet chain 5042002 (build and test here first, USDC; RPC https://rpc.testnet.arc.io; explorer https://testnet.arcscan.app); Robinhood Chain chain 4663 (live, ETH; RPC https://rpc.mainnet.chain.robinhood.com; explorer https://robinhoodchain.blockscout.com); Robinhood Chain Testnet chain 46630 (build and test here first, ETH; RPC https://rpc.testnet.chain.robinhood.com; explorer https://explorer.testnet.chain.robinhood.com). Native USDC on Arc and ETH on Robinhood Chain have 18 decimals. The consumer interface is the same on both; Arc serves requests through epochs, Robinhood Chain binds each request to a future drand round. Compile with Solidity 0.8.28 and EVM version cancun, importing contracts from the installed @d20dao/vrf-sdk package. Take the coordinator proxy address from the manifest of the network you target and check that its implementation matches the manifest. Any consumer contract can request; there is no allowlist, and EOAs cannot request.

Requests and fees: use the D20VRFRequests helpers from the SDK for every randomness option (raw word, dice, custom dice, coin flip, ranges, choose one or many, shuffle). Never hardcode the fee. In a contract, quote with quoteFee(callbackGasLimit) inside the requesting transaction. Off chain, quote with quoteFeeAt(callbackGasLimit, latest block baseFeePerGas) plus a buffer, or the SDK's quoteRequestFee with an ethers v6 provider, because eth_call reports a base fee of 0. Choose one payment pattern deliberately: collect a buffered quote from the user, pay the exact fee from the contract and return the change; or forward msg.value and accept that the excess becomes refund credit of the refund address.

Results: store the delivered word or mapped result in your consumer when the authenticated callback arrives, keyed by request ID, and have the application read that state. Off chain, wait for the coordinator's fulfillment events or poll getRequest (getRoundRequest on Robinhood Chain); the SDK documents the fields and mapped-result readers. A browser app must bundle the ESM package. Delivery usually takes a few seconds; measured Arc Testnet completion times, including under burst load, are at https://d20dao.org/benchmarks (observations of the testnet keepers, not an SLA). On Robinhood Chain a typical delivery takes 5–8 seconds. An unserved request can be refunded strictly after its 60-second deadline at the refund ratio fixed when it was requested. Give refund and callback-retry transactions explicit gas limits as documented.

Keep callbacks small and authenticated through D20VRFConsumer, and never request randomness from inside a callback. An accepted proof with a failed callback is paid service: retry the same stored result, never reroll. Optional _onRefund(requestId) means the refund recipient was paid or credited, not that the consumer received funds, and notification retries must not pay twice. Keep application assets and settlement separate from RNG fees.

For verification, keep the original epoch packet, request and target context and accepted proof evidence. Mathematical replay alone does not prove chain inclusion; check receipts and the implementation history too.

Implement only the requested changes. Do not ask for keeper, VRF, deployer or bot secrets, and do not send funded or mainnet transactions without my explicit authorization. Compile, run lifecycle tests on a local chain or a testnet, then report changed files, results, anything unverified, and any documentation that was unclear or missing.