REFERENCE / GUIDE

Security model

Fixed-input proofs with explicit operator and upgrade-authority trust.

Operator, source and chain assumptions

The pilot uses a single operator and a genuine fixed secp256k1 VRF key. A proof establishes the output for its fixed input; it does not force operator availability or establish source truthfulness, independence or lack of bias. The operator can withhold preparation, publication or fulfillment. Publication must precede the randomness target block so the final block hash is unknown when the packet is chosen. Independent chain context remains necessary for replay.

Upgrade and role authority

Both stable proxy addresses have trusted upgrade authority. The current implementation fixes the VRF key without a setter, but an owner-authorized implementation upgrade can change behavior. Ownership uses a two-step transfer; fee recipients and keeper/committer addresses are configurable. Verify historical implementation code and configuration when replaying earlier receipts, and review upgrades before trusting new requests. Do not describe the service as immutable merely because its proxy address is stable.

Release boundaries

A restricted Arc Testnet pilot is deployed on chain 5042002. Public addresses, code hashes and deployment receipts are recorded in github.com/d20dao/keeper/blob/main/deployments/arc-testnet.json. Consumer allowlisting is required. This does not establish mainnet approval, an external cryptographic audit, or a public SLA. Monitor actual preparation, publication and request deadlines. The lab remains illustrative; the Explorer displays indexed chain evidence.

Work with your agent

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

Plain text Agent guide

View prompt

Review my D20DAO integration for callback authentication, exact fees, request association, duplicate handling, reentry, selective outcome cancellation and refund accounting. Check historical proxy implementations and explicit operator/source/upgrade trust assumptions. Report findings with code evidence.

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/SECURITY.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.