Don't take our word for it.
Verify it.

Valid round transitions are permissionless: a participant or independent keeper can submit them without selecting a preferred winner. Empty rounds finish without a winner.

Perpetual describes the intended schedule, not guaranteed uptime. Solana, oracle availability and funded transaction executors must continue operating. Public 24-hour configuration still needs deployment verification.

ONE records round timing, ticket ownership ranges, jackpot accounting, randomness references and settlement state in public accounts. Transactions record the actions taken.

An accurate-looking website is not proof. Check the network, deployed program and actual transaction results. On-chain software can contain vulnerabilities, and on-chain operation does not establish legal authorization.

Numbers begin at 1 in each round. If five tickets exist, a purchase of three receives 6–8. One canonical receipt stores that range; there is not a separate account for every ticket. Multiple purchases create separate receipts.

My Tickets reads these on-chain receipts. A purchase proof also checks the successful instruction, wallet, quantity and actual token changes. If transaction history is unavailable, recorded ownership and missing payment proof are labelled separately.

You approve a wallet signature; ownership starts only after the purchase confirms. Network fees and receipt-account rent are separate. There are no secret paper codes to remember. Localnet test tokens are not authentic Mainnet USDG.

The final denominator is fixed only after the on-chain deadline. Decimal percentages are display approximations; the exact ticket fraction is more precise.

A boost contributes prize funds without buying tickets or changing anyone’s odds. No strategy or particular ticket number guarantees a win.

A purchase must execute before the stored deadline. At or after that timestamp it is rejected, even if you clicked Buy or signed earlier. A last-second click cannot guarantee inclusion.

Expired blockhashes and transactions that arrive after the cutoff are rejected. Drawing and settlement can take place after the countdown reaches zero. Keeper delays do not reopen ticket sales.

The reviewed configuration supports shorter development rounds. The public release must verify its actual configured duration is 86,400 seconds; the preview has no live deadline.

The program derives a domain-separated seed from the ONE program and round, checks the canonical ORAO request, owner, client, fulfilled state and replay flags, then deterministically maps the authenticated randomness to a ticket.

The integration currently requests no custom payout callback. A keeper polls for frozen fulfillment, then submits winner selection and settlement. The browser does not invent a winning number.

Round 6 used designated Localnet test oracle authorities. That proves the tested local workflow, not independently operated public oracle fulfillment. A delayed or unfulfilled request leaves the draw pending; there is no promised fulfillment deadline or automatic replacement draw.

Settlement requires the authenticated winner, canonical winning receipt, eligible token accounts with matching owners and mint, sufficient vault funds and the correct round state. The winner does not need to sign to receive the payout. Token-account creation can require a funded executor.

The candidate uses six decimal places and integer base units: the treasury allocation is floor(net proceeds × 5 / 100), and the remainder goes to the jackpot. At the fixed 1 USDG ticket price, that is exactly 0.05 and 0.95 USDG. It requires exact zero-transfer-fee delivery and rejects unsupported token behavior.

A jackpot allocation or WinnerSelected account does not establish payment. Verify a successful settlement transaction and the actual winner credit, treasury credit and vault debit. Round 6 proved 0.95/0.05 local test-token transfers, not genuine Mainnet USDG settlement.

The candidate accepts boosts only during an open purchase window with at least one ticket. Late or empty-round contributions are rejected; they are not automatically redirected by the lottery contract. A contributor or future collection component must choose an appropriate future eligible round.

UNUS is proposed and has not launched. Its net creator fees are intended to fund boosts after necessary collection, conversion and network costs. Automatic routing and conversion are not active, guaranteed or proven trustless. Lottery operation does not depend on UNUS trading.

A wallet connection reveals a public address to the app after authorization; it does not itself prove signing or network compatibility. Support is verified per wallet, version and platform. The app checks the selected RPC genesis, constructs the transaction and verifies returned message bytes and signatures before any authorized broadcast.

Funds still in your wallet remain separate from assets deposited into the lottery vault. Escrowed funds are subject to the program’s rules, upgrade authority and token issuer controls. A failed transaction can still consume network fees; account rent may also apply.

The published preview disables connection, signing, funding, purchases and broadcasts. Future mobile support depends on a compatible wallet browser or separately implemented connection transport.

The candidate initializes the approved mint, treasury and round duration through a designated bootstrap authority. Its current public instruction set has no routine treasury-change or rule-update instruction, but an upgrade authority could replace program logic while upgrades remain enabled. Production custody decisions are pending.

The protocol treasury owns its destination token account and can control funds received there. That does not grant a routine withdrawal from the lottery vault. Production treasury ownership and signing authority are not yet established.

The ORAO client has a program-derived request authority and a separately managed client owner. Their production identities, client controls and funding require review. Keepers execute permitted transitions and pay fees; they do not supply a chosen winner.

The program checks payout recipients and balances, prevents reuse of consumed randomness and closes zero-ticket rounds without requesting an unwinnable draw. The keeper re-reads chain state and journals uncertain submissions before retrying; bounded retries can stop for investigation.

The frontend independently checks transaction message bytes and Ed25519 signatures. Wallet rejection, account changes and expired purchase windows must stop submission.

Evidence has different strengths: candidate source review; internal unit and browser tests; adversarial transaction simulations; and the genuine Localnet Round 6 purchase and payout. None is an external audit or proof of independent public-network fulfillment.

Any funded participant can submit valid permissionless transitions when their prerequisites are met. After interruption, a keeper rechecks the round and recorded transaction signatures. It must not invent randomness, reset a committed draw or pay twice.

Website or RPC failure can hide data while the chain continues. Incomplete history is labelled unavailable rather than treated as missing ownership or a confirmed refund. A selected winner can still await account creation or a valid settlement transaction.

Token issuer freezes and controls can block transfers. There is no approved timeout/refund recovery policy or guaranteed rescue path in this release. Routine permissionless execution cannot override issuer powers or contract checks; an upgrade is a separate authority-controlled action with material risks.

Account state can establish recorded timing, tickets and settlement status. Transaction history adds provenance and actual token-transfer evidence. Both are checked separately; an indexer label alone is not canonical proof.

Explorer links use the selected network. Localnet test-authority results are never presented as public oracle results. The preview cannot query rounds because no ONE deployment is configured and its RPC proxy permits genesis checks only.

The read-only preview proxy creates a fixed getGenesisHash query. It does not forward incoming wallet identifiers, cookies, authorization headers or visitor-supplied RPC parameters to upstream RPC. It rejects wallet-account queries, simulations and writes.

Cloudflare receives browser requests and network metadata; Cloudflare and RPC providers can retain operational logs under their own policies. Platform-added network metadata and network anonymity are not guaranteed.

In an authorized interactive runtime, a wallet connection shares your public address with the app, and account/history reads reveal queried addresses to its RPC provider. An unresolved purchase signature is kept in browser session storage for confirmation recovery. No recovery phrase is requested; no complete anonymity is claimed.

Congestion, changing fees, RPC failures and confirmation/finality uncertainty can delay actions. An internal test cannot establish that a future deployment is completely secure. Public security review, independent ORAO acceptance, genuine USDG acceptance and production authority verification remain launch blockers.

Permissionless paid chance-based activity can still be subject to gambling and lottery laws. On-chain operation is not a legal exemption. Jurisdictional eligibility, licensing and authorization have not been established for ONE; this preview does not accept paid participation.