How a number is made

1. Measure. At 17:50 UTC the day's experiment runs on an IBM quantum processor, thousands of shots, every outcome kept in order.
2. Commit. The SHA-256 of the raw outcomes is written on Solana before the sealing drand round exists.
3. Seal. The first drand quicknet round after the commit is confirmed on Solana is combined with the outcomes: value = SHA-256(outcomes ‖ drand).
4. Publish. The daily record holds backend, job id, counts, the Bell statistic, commit, drand round and value. The raw outcomes go to Arweave.
5. Pool. The same outcomes, split into 256-bit chunks under a Merkle root, form the day's entropy pool for on-demand requests.

Two ways to use it: read the daily value (free, one number per day), or request a fresh number from the pool (many per day, each sealed with its own future drand round).

Rollout

• Phase 1, built: no custom program. Commit, reveal, snapshot, vote tally, draw and payout are memo transactions signed by the oracle wallet, so their order is fixed on chain. The daily certificate is a Metaplex Core asset whose frozen on-chain attributes hold the whole record, so programs can already read it.
• Phase 2: the Anchor program below: records as PDAs, the entropy pool, and payouts that only the program can make.

DailyRecord account

One PDA per day, seeds ["record", day], where day is days since 1970-01-01 as u32 little-endian.

// TypeScript (Anchor client)
const [pda] = PublicKey.findProgramAddressSync([Buffer.from("record"), u32le(day)], ORACLE_ID)
const rec = await oracle.account.dailyRecord.fetch(pda)
if (rec.status.sealed) use(rec.value)

// Rust, inside your program
let rec = DailyRecord::try_deserialize(&mut &ctx.accounts.record.data.borrow()[..])?;
require!(rec.status == Status::Sealed, MyError::NotSealedYet);
let i = uniform(&rec.value, entries); // rejection sampling, no modulo bias

On-demand numbers from the entropy pool

1. Request. Your program calls request_randomness(seed). A Request PDA stores your seed, the next unused pool chunk and a target drand round about 6 seconds in the future.
2. Fulfil. When that round is out, a keeper submits the chunk with its Merkle proof and the round. The program checks the proof against the committed pool root and stores result = SHA-256(chunk ‖ drand ‖ seed).
3. Consume. Your program reads the Request account in a later instruction (or receives a CPI callback) and uses result.

let req = request_randomness(CpiContext::new(oracle, accounts), my_seed)?;
// … later, once status == Fulfilled
let r: [u8; 32] = ctx.accounts.request.result;

Each chunk is used once. The chunk was fixed when the pool was committed, the drand round did not exist when you asked, and your seed separates you from everyone else.

Recipes

Check any number yourself

1. Download the day's raw outcomes from Arweave (link in the record).
2. SHA-256 of the outcomes must equal commit. The commit transaction must be older than the drand round and the first commit of that day in the oracle wallet's history.
3. The holder snapshot memo must also be older than the drand round, and the first of its day: the list was fixed before anyone could know the number.
4. Fetch the drand quicknet round and verify its BLS signature with any drand client.
5. SHA-256(outcomes ‖ randomness) must equal value. For pool requests, check the chunk's Merkle proof and SHA-256(chunk ‖ drand ‖ seed).
6. Recompute the Bell statistic from the counts and compare it with stat_milli; the IBM job id is published too.
7. Rebuild the winner from the published holder list with the same rejection sampling. All of this is one command: node oracle.mjs verify-draw draw.json --oracle <address>, no key needed.

What is guaranteed, and what is not

• Nobody can choose the result. The outcomes are locked before the drand round exists, and drand is run by an independent network.
• The quantum part is published, not trustless. We submit the IBM job; IBM does not offer public third-party verification. Job id, code, counts and the Bell statistic are public.
• drand on chain: at first the keeper posts the round and anyone checks it off-chain. On-chain BLS verification comes once it is practical on Solana.
• Not a loophole-free Bell test. One chip, not distant stations.
• Holders are wallets. Accounts owned by a program (curve, pools, vaults, and multisig vaults too) are excluded from the snapshot.
• The pool can be refused, not steered. The operator could fail to answer a request, which is visible, but cannot change its chunk or the drand round.
• Not for keys. The numbers are public. Never derive wallets or secrets from them.
• Not real-time. Requests settle in seconds, the daily value once a day.