Skip to content
D20DAODocs
Keeper LabExplorerGitHub

PROTOCOL / GUIDE

Source inputs

Four fixed recipes across three API providers.

Read the repository reference
01

Fixed recipe catalog

Slot 0 uses Hyperliquid metaAndAssetCtxs with dex empty, projecting BTC symbol and dayNtlVlm. Slot 1 uses ANU randomNumbers with type hex8, length 4 and size 8. Slot 2 uses TickerLayer lastTrade for crypto BTCUSD. Slot 3 uses TickerLayer lastTrade for crypto ETHUSD. Initialization pins four signer addresses in slot order; the two TickerLayer slots use the same provider signing address. Four recipes do not mean four independent providers.

02

Selection and repeated data

D20_EPOCH_SELECT, catalog hash, epoch ID and the start-minus-one anchor hash determine a selector modulo four. Consecutive epochs may select the same recipe. A fresh API call can return identical raw values; the protocol does not resample to force different bytes. Epoch parameters bind distinct commitments, but hashing public data does not create fresh or secret entropy. A valid local snapshot is preserved and published only for live demand.

03

Exact signed record policy

Canonical 65-byte low-s EIP-191 signatures bind query hash, timestamp and exact UTF-8 data. At publication an attestation cannot be future-dated or more than 120 seconds old. Hyperliquid requires the exact BTC symbol and a nonnegative decimal value. ANU requires the exact successful body with four 16-character lowercase hex values. TickerLayer retains the complete symbol, price, size and timestamp record in its exact order and bytes. Raw signed data is at most 128 bytes; malformed or oversized records are rejected, never cropped. A stale first snapshot is not silently replaced to find another outcome.

Work with your agent

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

 

View prompt
Review D20DAO epoch source evidence for my integration. Use the exact four recipe definitions and signer order. Verify the original signed packet and epoch commitment; distinguish signature provenance from source truthfulness and randomness guarantees.

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.