Skip to content
D20DAO

Let chance
take shape.

Verifiable randomness for Arc Chain.
D20DAO combines signed AirnodeHub data
with a verifiable random function (VRF).

Built on Arc Testnet ↗
READ THE DOCS

≈8 blocksEstimated average completion

01 / THE ENTROPY PATH

External inputs.
Onchain evidence.

D20DAO prepares signed API data locally for each 200-block epoch. A paid request triggers publication, then a future block hash binds the fixed input for a verifiable result.

  1. 01

    Prepare the epoch

    The current epoch, catalog and start-minus-one anchor select a fixed recipe. Idle epochs stay local.

  2. 02

    Publish for demand

    A paid request escrows its fee. The keeper publishes the first valid packet for live demand.

  3. 03

    Prove and deliver

    A block strictly after publication supplies the target hash. The fixed-key proof is verified and the result delivered.

01AirnodeHub

Signed API response

02D20DAO

Request-bound VRF

03Onchain

Proof and result

02 / SOURCES THROUGH AIRNODEHUB

A wider world
of signed data.

From market activity to quantum numbers, D20DAO brings signed data from AirnodeHub into a shared, verifiable randomness process.

Source data. Your application.

The source supplies an input; your application decides how to use the verified result. Build game outcomes, community selections or automated decisions from the same random word.

Explore AirnodeHubOur source policy
CURRENT SOURCESINPUT RECORD

  • Market activity

    Hyperliquid

    BTC trading volume

  • Quantum numbers

    ANU

    Signed number data

  • BTC market data

    TickerLayer

    Latest trade record

  • ETH market data

    TickerLayer

    Latest trade record

Each published source record is preserved onchain, so anyone can check its signature as part of replaying a result.

03 / INSIDE THE KEEPER

One request.
Every step in view.

From local preparation to on-demand publication and a future-block proof. Explore an illustrative request trace.

Read the keeper architecture
KEEPER LABINTERACTIVE PREVIEW
Example block settings

Request #1 / epoch 1 / on-demand publication / 60s deadline

CHANGE A BLOCK. FOLLOW THE DATA.
Ready to trace

Illustrative data and output; no API signature or VRF proof is generated.

04 / INDEPENDENT VERIFICATION

Replay the path.
Byte for byte.

Follow a result back to its signed source data and onchain proof. Public evidence lets your application and its users check how the outcome was produced.

Verify the source signature, replay the randomness proof and reproduce the final selection using public chain records.

Explore the evidence format

Separate by design

Keeper Prepares epochs and submits request proofs.

Coordinator Verifies evidence and settles requests.

Public replay Reconstructs results from chain evidence.

EVIDENCE EXPLORERARCHIVED ATTESTATION
Hyperliquid / 15 Sep 2026

Change a value, then check the signature.

Signed query hash
0xa27c0925fba523a83a8ad7682effc979b23cb4a47b40abce5a1186b2d56d93bb
Data hash
Calculated when you check the signature.
Ready to verify

The query, timestamp and response are bound by one signature.

View archived source record

05 / BUILD ON THE SAME WORD

Applications. Communities.
Autonomous apps.

Turn a verified word into a selection, sequence or number. Public mappings make each outcome reproducible across applications.

Read the integration interface
01

Game outcomes

Reveal deterministic candidates through an authenticated callback, then let the player choose or mint in a separate transaction.

02

Community selections

Select entries from a list fixed before the request. Public mappings reproduce the selected indices and their order.

03

Agent-driven decisions

Bring verifiable selections into agent workflows. Each decision carries a result and the evidence behind it.

FOR DEVELOPERS / SOLIDITY

Integrate in
26 lines.

Request a word. Receive an authenticated callback. Build your application around a result you can verify.

  1. 01

    Connect the coordinator

    Use the consumer base to authenticate every callback.

  2. 02

    Send the exact fee

    Read the fee from the contract and pin the refund address.

  3. 03

    Store the result

    Keep delivery small. Apply your application rules separately.

Explore the integration guide
RandomApp.solSolidity / 26 lines
// SPDX-License-Identifier: MITpragma solidity 0.8.28;import {D20VRFConsumer} from "./protocol/D20VRFConsumer.sol";import {ID20VRF} from "./protocol/interfaces/ID20VRF.sol";contract RandomApp is D20VRFConsumer {    ID20VRF public immutable rng;    mapping(uint256 => bytes32) public results;    mapping(uint256 => bool) private requested;    constructor(address coordinator) D20VRFConsumer(coordinator) {        rng = ID20VRF(coordinator);    }    function request(bytes32 input) external payable returns (uint256 id) {        require(msg.value == rng.requestFee(), "Exact fee required");        id = rng.requestRandomness{value: msg.value}(input, 100_000, msg.sender);        requested[id] = true;    }    function _fulfillRandomness(uint256 id, bytes32 word) internal override {        require(requested[id], "Unknown request");        delete requested[id];        results[id] = word;    }}
Authenticated callback. Exact request fee.View source

06 / SPEED + PROOF

A few blocks.
A verifiable result.

From request to a result your application can use. Follow the proof, then build on the outcome.

≈8

BLOCKSEstimated average completion

Result delivered

The application receives the authenticated result and its evidence remains available for replay.

Ready for your application

Map the verified word into a range, selection or shuffle with repeatable built-in functions.

Inspect every result

Follow the request, epoch and proof in the Explorer. Replay the evidence and check the outcome independently.

Explore the proofs

07 / YOUR QUESTIONS

Ready to
build?

How to integrate, verify results and handle delivery.

Read the documentation

BUILD WITH THE EVIDENCE

Make room
for chance.

EXPLORE THE CODE