Every day
9 PM · UTC
SYSTEM DESIGN This page explains the Lottery of Robin flow, draw rules and on-chain verification model.
THE RULES BEHIND THE ROBIN.
How It Works.
Three ticketed draws. One bonus yearly draw.
A winner chosen by verifiable randomness.
Quiver randomness is used for draw selection.
Read the Quiver security model ↗
Lottery of Robin uses a Quiver-style verifiable randomness flow: each closed round requests randomness through the configured adapter, the provider fulfills the request through the on-chain coordinator, and the contract derives the winning ticket from the returned randomness.
Read the Quiver security model ↗Pick a draw. Keep your ticket.
DAILY $5 · WEEKLY $4 · MONTHLY $3Every Sunday
9 PM · UTC
Last day of the month
9 PM · UTC
December 31
Midnight · UTC · no separate ticket sale
The contract records each ticket's owner and round. Tickets receive sequential numbers; you do not need to pick a winning combination. Every Daily, Weekly and Monthly ticket also creates one entry in the Yearly Lottery for that calendar year. The annual winner is selected at midnight immediately after December 31.
Ticket prices are fixed at $5 Daily, $4 Weekly and $3 Monthly. At purchase, a verified ETH/USD price determines the ETH cost. Stale or invalid price data must stop the purchase. Network fees are extra, and the USD value of an ETH prize can change.
How every ticket is split
Selected draw pool
Allocated to the selected Daily, Weekly or Monthly prize pool.
Developer & Operational Costs
Allocated to Developer & Operational Costs.
Revenue Sharing
Reserved for claimable ETH rewards for LOR holders.
Yearly Lottery pool
Allocated to the shared annual prize pool.
Daily, Weekly and Monthly rounds keep separate 94% prize balances. The 1% yearly allocation brings the total prize allocation to 95% and accumulates in a distinct annual pool shared by every eligible ticket sold during that calendar year. The 2.5% revenue share allocation remains a separate ETH pool until the daily 10 PM UTC snapshot execution. Each snapshot can increase eligible holders' claimable ETH balance, which holders can collect themselves.
From ticket to prize
- 01
Enter before the deadline
Your purchase joins one ticketed round and also adds one entry to the annual draw.
- 02
Sales close. Entries are locked.
After closing, that round accepts no more tickets. The yearly entry set closes at its published year-end deadline.
- 03
Quiver delivers the random result
The Quiver adapter accepts callbacks only from its fixed coordinator and provider, and binds each sequence number to one draw. The website and developer do not choose the random number.
- 04
The contract selects the winning ticket
A published calculation maps the accepted random value to an eligible ticket. Duplicate callbacks cannot replace the recorded outcome.
- 05
The applicable pool goes to its winner
Automation triggers payment of the selected pool. If the recipient rejects ETH, only the winning wallet can claim that prize to another address.
DRAW PROTECTIONS
No administrator chooses the winner.
The system removes discretionary control over the result. These protections are enforced by the draw flow and can be checked through the contract records.
No rerolls
A submitted randomness request cannot be cancelled or replaced to discard an unwanted outcome.
No late entries
Ticket ownership and the entry count are fixed before randomness is requested.
Only the authorized source
The Quiver adapter authenticates its fixed coordinator and provider, then matches each sequence number to one draw.
No developer prize withdrawal
The contract has no owner-controlled prize transfer or upgrade function. Developer fees and the revenue sharing pool are separate from prize liabilities.
Randomness assumptions and liveness risks are described in the Quiver security model ↗
Verifiable does not mean risk-free.
These rules are designed to prevent the operator from choosing or replacing the winner. They are not a promise that the entire system is impossible to influence or can never fail. Contract bugs, service dependencies and chain reorganizations still need to be addressed.
The callback records the result without sending ETH, reducing the risk of a failed payout blocking result storage. Quiver can buffer and retry the same callback result, but its provider can withhold a reveal and delay a draw. Automation is also required to request randomness and settle prizes.
Operational note: pending randomness can delay a draw if the provider withholds a reveal. Automation also needs to stay online to request randomness, publish snapshots and settle prizes on time.
A few things worth knowing
Does every round have a winner?+
Every successfully completed round with tickets has one winning ticket. With no tickets, the round closes empty. With just one ticket, its owner wins without a randomness request. If one wallet owns every ticket, that wallet necessarily wins. There is no rollover to another round.
Do more tickets increase my chance?+
Yes. In an evenly sampled draw, 10 tickets out of 1,000 represent a 1% chance. The contract maps a 256-bit randomness value to an eligible ticket. This modulo mapping has a negligible mathematical bias for practical ticket counts, but it is not a claim of perfect mathematical uniformity.
Can I verify a live result myself?+
The interface links to the lottery contract, ticket purchases, randomness request and fulfillment, selected ticket, and payment transaction. Those records let you check which entries were included and how the result was used. Open Draw History & Verify ↗
Can the team change the rules mid-round?+
Each round's price, allocations and selection rules are fixed before sales begin. The contract has fixed prices and dependencies, with no upgrade function. Any new contract version must leave existing rounds and their funds under their original rules.
Back to the draws
Use ETH on Robinhood Chain for transactions.