Bitcoin Randomness Beacon

/draw

Entropy you can verify. Randomness nobody controls.

Every 5-minute epoch, contributors submit SHA-256 proof-of-work. The oracle XORs all leaves, signs the result with a Schnorr key anchored to a live Bitcoin block hash, and publishes it. No trusted party. No committee. No PRNG.

Current Epoch

Epoch ID loading…
Contributions —
Fetching epoch… closes in —

Try it — contribute entropy now

Your browser solves a SHA-256 puzzle (~5–10 seconds of CPU) and submits entropy to the current epoch. Free, no account, no wallet needed.

Use cases

Provably fair giveaway

Announce the epoch ID before entries close. Use the signed result to pick the winner. Anyone can verify you didn't cherry-pick — the result is on-chain before you know who wins.

Waitlist / slot assignment

500 applicants, 50 slots. Post the epoch ID in advance. Sort registrations by hash(entry_id + draw_result) mod N. Completely auditable, nobody can accuse you of favoritism.

Unbiased audit sampling

Pick which records to review without being able to cherry-pick. Commit to the epoch ID before the draw, use the result to select the sample. Useful when showing a third party you didn't steer the audit.

Tie-breaker for automated systems

Two jobs compete for a resource. Two bids arrive at the same millisecond. Instead of first-come-first-served (gameable) or a PRNG (not auditable), use the epoch result as a public coin flip.

Game & app randomness

Dice rolls, loot tables, card shuffles — anywhere your users might question the RNG. Publish the epoch ID before the game starts, reveal the result after. Every player can audit it independently.

Scheduled random selection

Run a daily or weekly draw at a predictable epoch. Commit the epoch number in your terms. Your service never touches the RNG — the beacon is sovereign and external to you.

DLC oracle input

Block hashes are predictable to miners — anyone with hashrate can retry until a favorable hash appears. Reference the epoch ID in your DLC announcement instead. The signed beacon is the attestation; any counterparty verifies it offline against the oracle pubkey.

The pattern in one line: commit to an epoch ID before the outcome matters, let the epoch close, use the signed result. You can't know the result ahead of time; your users can verify it after.

How it works

1
Get a PoW challenge — free, from the attest service. The challenge is a SHA-256 puzzle with 18 leading zero bits (~5–10 seconds of CPU).
2
Submit your entropy — POST to /api/v1/draw with your solved nonce. Your contribution is XOR-merged into the epoch's running state. Replay is impossible (the epoch ID is embedded in the hash input).
3
Epoch closes — after 5 minutes (or when enough contributions arrive), the oracle deterministically computes the final hash, anchors it to the latest Bitcoin block header, and signs the result with the oracle Schnorr key.
4
Retrieve the signed beacon — GET /api/v1/draw/:epoch_id for 50 sats (L402 Lightning payment). Returns the Schnorr signature, result hash, contributing leaf hashes, and the Bitcoin block anchor you can verify independently.

Contribute entropy — free

Contributions are free. The PoW gate costs ~5–10 seconds of CPU, not money. Anyone can seed the beacon.
# 1. Get a challenge from the attest service curl -s https://attest.powforge.dev/api/v1/switch/challenge # → {"challenge":"abc123...","difficulty":18,"algorithm":"sha256"} # 2. Solve the PoW (leading 18 zero bits) # Using @powforge/captcha (standalone solver) npx @powforge/captcha solve --challenge abc123 --difficulty 18 # → {"nonce":"7f3a...","hash":"000003..."} # 3. Submit to the draw endpoint curl -s -X POST https://attest.powforge.dev/api/v1/draw \ -H "Content-Type: application/json" \ -d '{"challenge":"abc123","nonce":"7f3a...","owner_pubkey":""}' # → {"ok":true,"epoch":12345,"leaf":"sha256-of-your-contribution"}

Retrieve the signed result — 50 sats

After an epoch closes, the oracle signs the result. Pay 50 sats over Lightning to retrieve it. The L402 flow is standard RFC 7235 + bolt11 — any Lightning wallet handles it programmatically.
# First request returns 402 + invoice curl -s https://attest.powforge.dev/api/v1/draw/12345 # → 402 Payment Required # → WWW-Authenticate: L402 invoice="lnbc500n...",macaroon="Ag..." # Pay the invoice, get the preimage, then: curl -s https://attest.powforge.dev/api/v1/draw/12345 \ -H "Authorization: L402 <macaroon>:<preimage>" # → { # "epoch": 12345, # "result": "0000ab3f...", // deterministic XOR of all leaf hashes # "bitcoin_block": 897201, // anchor block at epoch close # "bitcoin_hash": "000000...", // block hash mixed into result # "signature": "schnorr...", // verifiable against oracle pubkey # "leaves": ["sha256...", ...] // all contribution leaf hashes # }

Pricing

Action Cost Gate
Contribute entropy to any epoch Free PoW puzzle (~5–10s CPU)
Retrieve Schnorr-signed beacon 50 sats L402 Lightning payment
Oracle pubkey / verification data Free None — GET /api/v1/info

Why this randomness is hard to manipulate

→
No last-leaf control — submissions close 30s before epoch end. You cannot grind the final contribution to steer the XOR output.
→
Bitcoin block anchor — the signed result mixes in the block hash of the Bitcoin tip at epoch close. An attacker would need to control the next Bitcoin block to bias the output.
→
Merkle leaf audit — the full leaf list is returned with the beacon. Any contributor can verify their entropy is included in the result.
→
Oracle key custody — the Schnorr key is generated at server start and not persisted. The oracle cannot re-sign with a different key retroactively without a detectable key rotation.

Oracle

Verify beacon signatures against the oracle pubkey at attest.powforge.dev/api/v1/info. The oracle uses secp256k1 Schnorr (BIP-340). Independent verification requires only the result hash, the oracle pubkey, and the signature — no trust in this server.