Documentation Index
Fetch the complete documentation index at: https://docs.auora.gg/llms.txt
Use this file to discover all available pages before exploring further.
The game
A weekly slate of games is posted. Pick the outcome of every game. If you get them all right, you win the entire jackpot. If nobody hits a perfect score, the pot rolls over to the next week — and keeps growing.Why it’s different
On Kalshi or a sportsbook, you bet against the house at house-set odds. Here, the pot is everything every player put in. The more people who enter and fail, the bigger your win when you finally nail it.How it works
Slate created
The operator posts a slate of games (e.g., 10 NFL Sunday games) with an entry deadline.
Enter and commit picks
Pick the winner of each game. Your picks are hashed and sealed — nobody can see them. Pay the entry fee.
Games settle
After games finish, outcomes are proposed on the resolver. A challenge window runs. Once finalized, the contract records each result.
Win thresholds
As the jackpot grows, hitting a perfect score gets harder to justify. The contract supports immutable pool-size thresholds set at deploy time. Example:| Pool size | Required correct |
|---|---|
| < 100 MATIC | 10/10 (perfect) |
| 100+ MATIC | 9/10 |
| 500+ MATIC | 8/10 |
Fallback mode
IfmaxRolloverSlates consecutive slates produce no winner, the next slate automatically switches to “highest score wins” — guaranteeing the pot pays out. The operator can also reduce the slate size (fewer games = easier to hit perfect) to naturally increase win probability.
Key details
- Rake: Taken per-slate on new entry fees only. Rollover pool is never re-raked.
- Anti-rug: The operator cannot access the rollover pool. Only winners can drain it.
- Min players: 2 per slate
- Games per slate: 2-30
- Oracle: UMA Optimistic Oracle or ResolverAdapter with challenge window
