A giveaway platform on Ritual Chain testnet where winners are picked by math, not by an organizer clicking a name. Anyone can create a giveaway, anyone eligible can enter, and when entries close, anyone at all can trigger the draw. The result comes from a signed public randomness beacon, checked cryptographically on-chain, with no room for the organizer, the admin, or Fair Draw itself to influence who wins.

You don't have to trust anyone, and that's the point. The entrant list is locked with a hash before the random number is even fetched, so nobody can edit who was eligible after seeing the outcome. The random number itself is checked against a cryptographic signature on-chain; if it were faked, the transaction would simply revert and there'd be no result at all. And the whole thing is re-checkable: the site has a "Run verification in this browser" button on every settled giveaway that recomputes the entrant hash and the winner selection live, from nothing but public chain data.

Ritual Chain testnet, chain ID 1979. Blocks land roughly every 0.35 seconds, which is why entry windows and countdowns are measured in blocks rather than plain minutes.

A randomness beacon: a small external service that publishes a fresh random number on a schedule and signs each one it publishes. Fair Draw's contract reaches out to that beacon's URL using Ritual's HTTP precompile, gets the number back inside the same transaction, and checks the signature before trusting it.

The verified random number becomes a "seed." To pick winner #1, the contract combines the seed with the number 0, hashes it, and takes the remainder after dividing by however many entrants there are. That remainder is an index into the entrant list, and whoever's sitting there wins first place. That person is removed from the pool, and the same process repeats with the number 1 for second place, and so on.

Because every step only depends on public, already-fixed values (the seed and the locked entrant list), anyone can redo this exact math by hand and get the same winners every time. That's what "deterministic" means here.

It proves the random number really came from the beacon and wasn't invented by anyone along the way. The beacon signs every number it publishes with a private key only it holds; the contract checks that signature against a public key that's been fixed in the contract since deployment and can never be changed by anyone, including the admin. If the signature doesn't match, the whole transaction reverts: no draw, no winners, nothing recorded.

Being honest about this one: the signature check stops anyone from forging a fake result, but it can't stop the beacon's own operator from generating a convenient number and signing it themselves. That part depends on who runs the beacon. The current testnet beacon is a single service, which is a real single point of trust worth naming plainly. Genuinely decentralized alternatives exist, like drand (the League of Entropy), which spreads randomness generation across several independent organizations using threshold cryptography, so no single party can produce or predict a result alone. That's the upgrade path for a production deployment.

• Open to everyone: no restrictions, any wallet can enter.
• Token holders: you must hold at least one unit of a specific token or NFT. The same field works for both ERC-20 tokens and ERC-721 NFT collections, since they share the same balanceOf(address) check. ERC-1155 collections aren't supported by this field.
• Manual whitelist: the organizer adds specific wallet addresses directly. Simple and editable any time, but costs a bit of gas per address added.
• Merkle allowlist: the organizer compresses a whole list of addresses down into one small on-chain "root" hash, and each entrant proves their own membership with a personal proof. Costs almost nothing to set up regardless of list size, but the list is locked in once published.

Use the built-in Merkle tool. There's a "Don't have a root? Build one" link next to the root field when creating a giveaway, and a "Don't have your proof? Get it here" link on the entry box for any Merkle-gated giveaway. Paste the full address list in, and it computes the root (for the organizer) or any single address's proof (for an entrant) entirely in your browser. The list never leaves the page.

Not automatically. A Ritual contract can only see Ritual's own state, not another chain's. The practical way to do this today is to compute the eligible list off-chain (using any indexer for the other chain) and publish it as a Merkle allowlist here, the same as any other pre-computed list.

Triggering a draw makes a real HTTP call out to the randomness beacon through Ritual's HTTP precompile, and that call has a small executor fee: a few millionths of a RITUAL token. That fee is billed to whichever wallet actually signs the trigger-draw transaction, not to the Fair Draw contract itself, and it has to be deposited into a separate escrow contract (RitualWallet) ahead of time, not just sitting in your normal wallet balance.

No. The site checks your RitualWallet balance automatically the moment you connect, and again right before submitting a draw. If it's too low, it deposits a small top-up (0.005 RITUAL, locked 30 days) on its own before continuing with the draw. You can also fund a larger amount manually any time from the wallet menu, under "Fund draw fee balance."

7 days maximum, whether you pick a preset (1 hour, 1 day, 3 days, 7 days) or a custom block count. The custom field shows you a live "≈ Xd Yh Zm" readout as you type, and rejects anything over the 7-day cap.

• HTTP Call precompile (0x0801): fetches the beacon's latest signed round directly from a smart contract.
• JQ precompile (0x0803): parses the round, randomness, and signature out of the beacon's JSON response, on-chain.
• Ed25519 precompile (0x0009): verifies the beacon's signature against its fixed public key.
• All three chained in one atomic transaction. Either the whole sequence succeeds and settles, or nothing happens at all.
• TEEServiceRegistry: the on-chain directory of trusted executors that service HTTP requests.
• RitualWallet: the escrow contract that fees for the HTTP call are paid from.

The entrant-list commitment and the winner-selection formula are both fully reproducible from public contract data, so the "Run verification in this browser" button redoes both live. The Ed25519 signature check can't be redone the same way after the fact, because the contract only stores a hash of the beacon's message, not the raw message itself. There's nothing to feed back into a signature verifier once it's settled. That check is instead guaranteed by the chain itself: if the signature hadn't matched at the time, the transaction would have reverted and there would be no result to look at in the first place. Every node re-validates that before accepting the block, the same guarantee that secures the rest of the chain, not something unique to Fair Draw.

No. The admin role only controls who's allowed to create giveaways (an anti-spam gate), nothing more. Triggering a draw is permissionless, anyone can call it, and the winner-selection math has no input from the organizer, the admin, or Fair Draw at any point.