What this is.
A normal creator wallet can withdraw trading revenue for itself. $LOTTERY sets its creator fee to 5%, and Pons Lottery changes the destination: the creator-fee recipient is a contract that turns those revenues into recurring holder prizes. The rules are enforced by the controller and ticket vault instead of depending on a creator to distribute funds manually.
Trade $LOTTERY. Creator fees fill the pot. Deposit tokens for tickets. One weighted ticket holder wins 70% after the Dice fee.
Deposited $LOTTERY backs tickets 1:1 and never becomes prize or protocol revenue.
Your chance is your ticket balance divided by the total live ticket supply.
A sortition-sum tree chooses one exact winner without scanning every participant.
What runs the system.
The controller and persistent ticket vault belong to this project. Pons supplies token launch and fee escrow; Dice supplies authenticated randomness. The addresses below are read from the configured controller, not copied into this page.
Runs cadence, claims creator ETH, requests randomness, and accounts for the 70/30 split.
Holds deposited $LOTTERY 1:1, issues nontransferable tickets, and stores the weighted tree.
The Pons ERC-20 deposited for tickets and returned 1:1 on redemption.
Creates the token and records the lottery controller as creator-fee recipient.
Holds already-swept creator ETH until the lottery claims it at draw start.
Stores the paid randomness request and authenticates the callback that resolves one winner.
Commits to and reveals the hash-chain randomness used by the configured Dice oracle.
Controller migration does not move ticket principal. A compatible successor takes over the same vault, while recorded claims remain reserved in the controller that created them.
How the pot fills.
The launch is configured with a 5% creator fee and points its recipient at PonsTicketLottery. Fees first accrue inside the active Pons trading path. After Pons sweeps them, the lottery receives a claimable ETH credit in Pons escrow. The dashboard keeps pending Pons rewards and the next-draw pot separate so you can see both stages.
- 1Trading creates fees
Bonding-curve or graduated-pool activity accrues fees under the token's Pons launch policy.
- 2Pons sweeps the trading path
The trusted Pons sweep path converts or collects the creator share and credits its escrow.
- 3The draw claims escrow
startDraw()claims all already-swept creator ETH into the lottery before calculating the prize. - 4The pot is reserved
The exact Dice fee is paid first. The remaining ETH becomes 70% winner prize and 30% protocol revenue.
One token in. One ticket out.
Deposit $LOTTERY into PonsTicketVault and receive the same number of nontransferable ticket units. Tickets persist into every later round until you redeem them. Holding duration does not matter: a ticket deposited immediately before a round lock has the same weight as any other ticket.
- Every ticket remains backed by one deposited $LOTTERY token.
- Tickets cannot be transferred or traded; redeem them to recover the underlying token.
- Deposits and redemptions pause only while a Dice request has locked the current round.
- The immutable minimum nonzero position prevents dust-sized tree entries.
- The weighted tree updates logarithmically, so winner selection does not loop through all wallets.
Anyone starts it. Dice resolves it.
The cadence window, minimum winner prize, ticket supply, and bounded Dice fee must all pass.
The vault records total weight and participant count, then blocks every mint and redemption.
The controller pays the exact fee and stores the authenticated request ID and reserved allocations.
The callback draws one tree leaf, unlocks the vault, and records pull-based winner and protocol balances.
A callback only records liabilities. The winner later calls claimPrize(recipient), avoiding a failed receiver from blocking resolution. Unclaimed prizes stay reserved and cannot enter a later pot.
Fast at launch. Fixed after.
Of creator ETH remaining after the exact Dice request fee.
Reserved for the current protocol owner and claimable separately.
Draw spacing during the first 48 hours.
Draw spacing from day 3 through day 7.
Permanent spacing after the first seven days.
A scheduled time makes a draw eligible; it does not execute a transaction automatically. Any address must still call startDraw().
Public where possible. Bounded where necessary.
What the owner can change
While the controller is paused and no draw is pending, the owner may update bounded Dice configuration, Pons infrastructure, and the minimum prize, or migrate control to a compatible successor. Changes take effect immediately; there is no timelock.
What the owner cannot change
The owner cannot move user principal, edit ticket balances or tree weights, choose a winner, spend a recorded claim, change the token or 1:1 redemption rate, or alter the fixed cadence and 70/30 split inside a deployed controller.
Know what is guaranteed.
- Principal solvency. Vault token balance must always cover total redeemable tickets.
- Frozen randomness set. No ticket mint, burn, deposit, or redemption can occur while a round is locked.
- Authenticated callback. Only the configured Dice contract and provider can resolve the matching request.
- Separated liabilities. Pending prizes, winner claims, and protocol claims are excluded from every future pot.
- Principal liveness. Anyone can release an expired vault lock even if the oracle or controller stalls.
- Persistent custody. Controller migration changes operations without moving the ticket vault's deposited tokens.
The system reuses pinned PoolTogether-style 1:1 ERC-4626 custody and a pinned Kleros V2 sortition tree, but upstream review does not automatically audit this integration or its local adaptations.
Things worth knowing first.
- Depositing creates custody. You exchange wallet-held $LOTTERY for a nontransferable vault ticket until redemption.
- Just-in-time deposits count fully. There is no loyalty or time-weighted advantage.
- Pons sweep timing is external. Trading fees may exist before they become claimable ETH in Pons escrow.
- Dice has liveness risk. Its provider can delay or withhold a reveal; refund and lock-expiry paths recover liveness but do not force a scheduled result.
- Oracle fees can change. Draws stop if Dice quotes above the configured maximum until the owner explicitly updates it.
- No trade means no new pot. The lottery distributes creator revenue; it does not mint rewards.
- Audit status. The contracts are extensively tested, including a live-chain fork and large participant benchmarks, but have not completed an independent production audit.
- Legal status varies. Token lotteries may be regulated as gambling, promotions, securities, or consumer products depending on jurisdiction.
Pons Lottery only asks your wallet to approve tokens, deposit, redeem, start or recover a draw, and claim your own prize. Review the chain, contract, and transaction preview before signing.