RUN THE
NUMBERS
The number that decides which jet reaches Mars first is not ours. An outside beacon publishes it on its own clock, in public — and everything below exists so you can fetch that number and follow it all the way to a seat.
- SOURCE
- quicknet
- SCHEME
- bls-unchained-g1-rfc9380
- PERIOD
- 3s
- PUBLISHING SINCE
- 2023-08-23
- SEAL LEAD
- 60s
- SELECTS
- 1 / 50
The beacon, and who runs it
Every mission is settled from a value published by drand, a randomness network operated by a group of universities and companies that have nothing to do with $HELIOS. A fresh signed value has gone out every 3 seconds since 2023-08-23. It was running long before this launch, and it will carry on long after.
No value is visible to us early, none can be edited once it is out, and we have no way to swap in another. Should a valid beacon fail to arrive, the mission simply never settles — the code has no backup number to reach for — and you get your entry back.
Why the timing can’t be gamed
When booking closes, a separate transaction seals the mission, and the seal fixes which beacon round will decide it — computed rather than chosen, and fixed before that round is published. No one enters a round number by hand. The formula is:
round = floor((sealed_at + 60 - 1692803367) / 3) + 2
That trailing + 2 is doing security work, not tidying: it rules out the round published at the moment of sealing, which somebody watching drand could otherwise aim for while already knowing its value. The 60-second lead covers Arc's block timestamp trailing wall-clock time by a moment — any shorter, and the same gap opens back up.
The seal is open to anyone, but in practice our keeper sends it. So it would be wrong to claim nobody picks anything: the sealer picks when, and sealed_at is right there in the formula. What the formula takes away is any advantage in that pick. Whatever moment is chosen points at a beacon still at least 60 seconds from being published, so every option on the table is a value nobody has seen — including us.
Two claims, checked in two places
The beacon decides which jet lands first
Hash the signature with keccak256 to get the seed; the seed mod 50 is the jet that arrives first, and its 10 seats are the ones that share the award. The panel below repeats every step on your own device — and with no shuffle involved, you could work it out by hand.
This is the part players tend to question: whether the jet was picked once someone could see which seats had sold.
The signature really came from drand
Proving that takes a pairing check over BLS12-381. DrandVerifier.sol runs it on-chain, against drand's public key, before any mission is allowed to settle — so a forged beacon is stopped long before it could show up on this site.
Keeping the two apart is deliberate. A blanket label like “provably fair” would hide which part is proven where.
On-chain does not mean on trust. The terminal command in 05 puts that exact question to the deployed verifier with an eth_call, through whichever RPC you like, and shows you its answer. A pairing does not belong in a browser tab — but you can still run one yourself.
Try it on a live beacon
Choose a drand round, or leave the box empty for the newest. Your browser requests it directly from api.drand.sh, with nothing routed through our servers, then works out which jet that beacon sends to Mars first. The newest round makes the strongest test: it did not exist when this page was built.
Rather do it by hand? Open this and paste the signature below — https://api.drand.sh/v2/beacons/quicknet/rounds/latest
The full audit, from your terminal
COVERS EVERYTHING IN THE PANEL ABOVE, AND THE ONE STEP IT CANNOT DO. IT TALKS ONLY TO THE RPC YOU GIVE IT, NEVER TO OUR SERVERS, AND EXITS WITH AN ERROR UNLESS ALL FIVE CHECKS PASS.
- It asks two separate drand operators for the round this mission was sealed against, and requires an identical signature from both. A match is not proof on its own — check 03 is — but a mismatch halts the run before a single hash is computed.
- It confirms the seed recorded on-chain is the
keccak256hash of that signature. - It has the deployed verifier confirm the signature is drand's, using the group key built into the contract. This is the BLS step the browser skips, done properly.
- It rebuilds the manifest locally and requires it to agree, seat by seat, with the one the contract computes — which catches any drift between the TypeScript and the Solidity.
- It checks the seat counts against those locked in when the launch opened — 10 award seats of 500 — rather than against today's config.
pnpm --filter @helios/verify verify -- \
--rpc https://rpc.mainnet.arc.io \
--launch <HeliosLaunch address — nothing is deployed yet> \
--round <round id>No contract is live yet, so there is no address to insert and no mission to audit. The command above fills in both as soon as they exist.
Values locked into the verifier
- Beacon
- quicknet
- Scheme
- bls-unchained-g1-rfc9380
- Period
- 3s
- Chain hash
- 52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971
- Group public key
- 83cf0f2896adee7eb8b5f01fcad3912212c437e0073e911fb90022d3e760183c8c4b450b6a0a6c3ac6a5776a2d1064510d1fec758c921cc22b0e17e63aaf4bcb5ed66304de9cf809bd274ca73bab4af5a6e9c76a4bc09e76eae8991ef5ece45a
The group key is what actually matters. DrandVerifier.sol bakes it in as a constant with no way to update it, so moving settlement onto another beacon would mean deploying a new contract, at a new address, where everyone could see it. None of these values are ours — drand publishes them. Compare them with what drand returns at /v2/beacons/quicknet/info; if anything differs, we have made a mistake and we want you to catch it.
A fair pick is half the story. The other half is whether every USDC award on the manifest is fully backed — the proof page covers that, and the payout odds are laid out in the flight plan.