A funded draw connects four steps: check balances, lock the prize budget, receive Quiver randomness, then purchase and deliver the selected asset. DEV runs the keeper and pays its gas.
Hold more than 99 of the configured token to meet the balance threshold. No tickets are sold on this site. Your eligible balance determines your weight, subject to the wallet exclusions.
PONS credits fees to an escrow. A compatible collector must claim them and forward ETH to the draw contract. Unclaimed escrow balances are not available prize funds. The lottery cannot claim PONS fees by itself.
The keeper records eligible holdings and the contract balance at a confirmed block. These inputs are committed before requesting randomness, so later activity does not change an accepted draw.
The Quiver response determines the recipient and stock. The purchase adapter follows the configured Uniswap v4 route from ETH through USDG to the stock token, delivering it to that recipient.
The countdown, holder preview and payout record describe different stages A displayed balance or selected recipient is not proof that a prize has been paid
For the deferred-token deployment, the first 300-second interval begins when DEV activates the holder token Reading the configured contract interval… Network confirmations, gas and the Quiver response can extend a funded draw Settlement starts the next interval
When the balance is at or below the 0.005 ETH reserve, the keeper records a no-prize cycle and starts another countdown. It does not submit a holder snapshot or request randomness Downtime does not create completed draws.
The keeper rebuilds ownership from Transfer events, checks total supply and reads historical balances at one confirmed block It reads the prize contract at that block too The publisher submits these balances; the contract does not independently prove every holding.
Exactly 99 tokens does not qualify. DEV, the designated fee wallet, configured liquidity pools and operational contracts have no draw weight. Each submitted snapshot supports up to 500 eligible wallets. The header CA identifies the holder token.
Weights use the token's base units, preserving fractional balances instead of rounding them into tickets.
Estimated chance = your eligible balance ÷ all eligible balances × 100.
Illustration: balances of 100, 300 and 600 tokens give approximately 10%, 30% and 60% of the draw weight. With only one eligible wallet, that wallet receives all selection weight.
The contract hashes the authenticated Quiver value with the label "HOLDER", the round ID and the snapshot commitment, then takes the result modulo total weight.
Wallets are ordered by numeric address. The first cumulative balance greater than that position identifies the recipient. The keeper does not pass in a replacement winner.
A second hash uses the label "STOCK", the same Quiver value, the round ID and the commitment. Its result modulo the fixed asset-list length selects a stock without using holder weights.
Retrying a purchase does not reroll the randomness, recipient or asset. The configured contract fixes the prize list.
The frozen prize budget is the snapshot contract balance minus 0.005 ETH. Deposits arriving later belong to a future draw. DEV pays transaction gas from its own wallet; the contract reserve does not pay keeper gas. No eligible wallets means no recipient.
The keeper supplies a quote, a positive minimum output and a short deadline for the configured Uniswap v4 route. A failed swap or delivery reverts the purchase without changing the selection.
After the relevant 48-hour timeout, the frozen budget may be recovered: to the fixed fee wallet before a Quiver response, or as ETH to an already selected winner. An available response must be applied first. This is not a general withdrawal: it cannot reclaim the 0.005 ETH reserve or PONS escrow balances.
Results links the snapshot and payout transactions. A stock delivery is recorded after the required confirmations and matching transfer logs. The holder history also links the Quiver request. Recovery transfers are distinct from stock purchases; selection alone never means payment.
Risk notes: this implementation has not received an independent audit. Quiver uses commit-reveal rather than a traditional VRF; provider influence and response delays remain possible. Hash/modulo selection introduces a very small mathematical bias. The publisher can omit or misstate holdings and delay submissions. Pool quotes can be manipulated and do not guarantee fair value. Recovery is limited to its on-chain conditions, and funds can remain locked. Local tests are not proof of safe mainnet operation.