PROTOCOL / GUIDE
Verification
Replay public epoch and request evidence against historical implementation context.
Read the repository referenceCollect 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 API packet once when an epoch is used. Each accepted request records abi.encode(Proof), 416 bytes. No private keeper database or keeper connection is required.
Replay epoch and request
Use replayEpochCommitment to reconstruct recipe selection, validate the exact signed packet and match the stored epoch record. 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.
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. The homepage Evidence Explorer authenticates a historical Hyperliquid candle response against a pinned signer. That historical record is not a current epoch recipe, and the inspector does not prove chain inclusion or complete VRF validity. Its downloadable record preserves the original signed bytes and historical provenance.
Work with your agent
Copy a task-specific prompt with the protocol references and integration rules.
View prompt
Add independent D20DAO proof verification to my application using the reviewed SDK exports. 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 references before choosing APIs: - Agent guide: https://github.com/d20dao/web/blob/main/public/agents.md - Full text docs: https://github.com/d20dao/web/blob/main/public/llms-full.txt - This guide: https://github.com/d20dao/keeper/blob/d7e785dda57499220bd37d73bc6fad9226872dcc/docs/epoch-protocol.md - Current deployment and upgrade history: https://github.com/d20dao/keeper/blob/main/deployments/arc-testnet.json - SDK and packaging instructions: https://github.com/d20dao/d20-sdk - Integration skills: https://github.com/d20dao/skills - Reviewed protocol source: https://github.com/d20dao/keeper/tree/d7e785dda57499220bd37d73bc6fad9226872dcc If a reference needs repository access, use the installed package's AGENTS.md and provenance or request the reviewed files. Do not invent signatures or addresses. Use the existing project toolchain. Install @d20dao/vrf-sdk from npm and read its AGENTS.md and PROTOCOL-PROVENANCE.json. Use Solidity 0.8.28. Configure the actual chain and coordinator proxy; Arc Testnet is 5042002 and requires consumer allowlisting. Read requestFee() instead of hardcoding the fee. Keep callbacks small and authenticated through D20VRFConsumer. Mapped requests still deliver a raw bytes32 word. Accepted proof with a failed callback is paid service; retry the same stored result, never reroll it. Unfulfilled requests are refundable strictly after 60 seconds. Optional _onRefund(requestId) means the fixed recipient was paid or credited, not that the consumer received funds; notification retries must not pay twice. Do not request randomness from inside a callback. Separate application assets and settlement rules. For verification, retain original epoch packets, request/target context and accepted proof evidence. Mathematical replay alone does not establish chain inclusion. An implementation upgrade inside a relevant block requires transaction-ordered evidence; block-end storage alone cannot prove which code ran. Implement only the requested application changes. Do not request keeper, VRF, deployer or bot secrets. Respect my authorization for any deployment or funded transaction. Run relevant compilation and lifecycle tests; report changed files, results, missing inputs and any remaining onboarding step.