dApp Registry
Register your dApp to request on-demand randomness via callbacks.
Request Fee Tiers
Standard (default)
0.01 XNT / req
NFT mints, one-off apps, low-volume dApps
Premium
0.05 XNT / req
Casinos, games, high-volume — maximises validator liveness
Fee Split
95% → validators
5% → crank runner
Higher fees mean larger validator rewards per round, directly incentivising the committee to remain live and responsive to your requests. Note: game_seed fees (0.001 XNT) also flow to validators via the same FeeEscrow mechanism — every fee paid through the protocol contributes to validator rewards.
Integration Guide
Step 1 — Choose how your program receives randomness
There are two ways to get randomness into your program. Pick the one that fits your use case:
Step 2 — Write a callback instruction in your Anchor program
Add an instruction to your Anchor program that the protocol will call when your randomness is ready. It must accept exactly two arguments: a 32-byte output array and a round number.
// In your Anchor program (Rust):
pub fn receive_randomness(
ctx: Context<ReceiveRandomness>,
output: [u8; 32], // the 32-byte random value
round: u64, // the protocol round number
) -> Result<()> {
// store output, use it for your game logic, etc.
Ok(())
}
The instruction name can be anything you like — receive_randomness is just a common convention. The protocol does not care what it is called; it uses the 8-byte discriminator to identify it.
Step 3 — Find your instruction's discriminator
Every Anchor instruction has a unique 8-byte fingerprint called a discriminator. Think of it as a function ID — it is the first 8 bytes of the SHA-256 hash of the string global:<your_instruction_name>. You need to find this and paste it into the registration form.
Option A — Read it from your Anchor IDL file (easiest)
After running anchor build, Anchor generates a JSON file at target/idl/your_program.json. Open it and find your instruction by name. The discriminator field is the exact array of bytes you need.
// target/idl/your_program.json (example)
{
"instructions": [
{
"name": "receive_randomness",
"discriminator": [232, 212, 165, 16, 0, 0, 0, 0],
...
}
]
}
Copy that array and format it as comma-separated bytes: 232,212,165,16,0,0,0,0. That is exactly what to paste into the registration form.
Option B — Calculate it here
Type your instruction name below. The discriminator will be computed instantly in your browser — no tools needed.
How the full flow works end-to-end
- 1
Your program or frontend calls request_randomness
A 0.01 XNT fee is transferred to the round's fee escrow. A RequestState account is created on-chain holding a unique request_id derived from your program ID, seed, and callback details.
- 2
Randomness is produced
If the entropy pool already has fresh entropy (warm pool), your request is fulfilled immediately in the same transaction — typically under 1 second. If the pool is stale, the request queues and is fulfilled once the next EE V4 commit/reveal cycle completes (~4–5 minutes).
- 3
Your callback is called (push model only)
A keeper calls deliver_callback, which CPIs into your program with the 32-byte output and the round number. Your program receives the randomness directly — no polling, no reading accounts.
- 4
The result is verifiable on-chain forever
The output formula is SHA256(pool_entropy ‖ request_id ‖ slot_hash). Anyone can call verify_entropy on the RequestState account to confirm the output is correct. The slot hash at transaction inclusion was unknown at submission time, making the result unpredictable even to the protocol operators.
Min Round Interval
Controls the minimum number of protocol rounds between consecutive requests from your dApp. One round is one full EE V4 commit/reveal cycle — typically ~4–5 minutes on X1 mainnet.
0
On-demand
Request as often as you like — every round if needed. Good for games, lotteries, NFT mints — any low-latency use case.
1
Once per round
One request per ~4–5 minute EE round. Suitable for scheduled draws or periodic randomness.
N
Every N rounds
One request per N rounds (~4–5 min × N). Use for weekly/daily draws or rate-limited games.