One coin, one prize pot
Select an eligible collectible → launch a coin → confirmed creator fees fill its isolated prize pot → a qualifying holder wins.
Fees credited to another coin cannot fund this prize. Reference listings are potential prizes, not owned or guaranteed inventory.
Read each stage separately
- Funding: Confirmed fees are accumulating toward the selected prize.
- Funded: The prize budget has been reached. Funding alone does not verify acquisition.
- Secured: The collectible has been purchased or reserved and verified.
- Snapshot scheduled: The draw publishes its eligibility timing; its locked policy determines which snapshots count.
- Draw complete: The winner and verification record are available.
- Fulfillment pending: A winner has been selected, but delivery is incomplete.
- Delivered: Delivery is confirmed by the relevant transaction or fulfillment record.
These describe separate evidence requirements, not the current status of an item. Inventory may be secured before the pot fills; the current launch form requires verified inventory first.
Curated launches pair a new Solana coin with authenticated prize inventory. Each coin has its own funding target, fee receipts and draw records. Admins select the prize and review its complete SOL budget, including fulfillment costs, before a wallet signs the launch. The first version is admin-curated.
New launchpad creator fees use a fixed 90/5/5 policy: 90% funds that coin’s prizes, 5% is reserved to buy back and burn the platform token, and 5% supports operations. These percentages apply to finalized creator fees received, not total trading volume. The creator receives no separate payout under this policy. Existing CI and historical fee policies are unchanged.
Following Souvenir’s documented approach, half of the platform’s 10% share from other coins is reserved for buybacks. The platform token’s own fees do not fund its buybacks. Buybacks run only with verified configuration, available funds and bounded transaction costs; a reserve is not an executed burn. The public record shows finalized receipts.
A funded pot alone does not start a draw. The prize, complete budget and holder policy must be reserved and the snapshot commitment finalized before future verified randomness. Each draw publishes its own terms. Opening and closing snapshots do not prove continuous holding between those times.
Launch preparation, financial execution and physical fulfillment have separate readiness requirements. No coin, prize, burn or shipment is implied by an empty catalog or an unconfigured integration.
The separate Collector Inu holder lottery
Collector Inu’s holder lottery is a separate program from individual coin prizes. Its own confirmed fee allocation can fund eligible collectibles; a draw requires a fully covered budget and verified acquisition or reservation. Eligible balances are counted automatically from published finalized snapshots. No staking, wallet connection or manual entry claim is required.
Momento’s contract is published on the token page. A published address does not activate draws or buybacks. New CI eligibility requires separate mint and policy configuration. Historical transactions, asset units and locked reward terms remain unchanged. A reserve commitment is not proof that a physical collectible has been vaulted. Holding CI does not grant treasury ownership or index redemption rights.
100,000 $CI = 1 ticket. Every complete 100,000-token unit adds one entry under the proposed CI policy, which targets 30-minute epochs. It is not active until the new mint and approved inventory are configured. New confirmed creator fees are planned at 70% holder rewards, 20% pack inventory and 10% CI buyback-and-burn reserve. Initial $100 funding uses a separate $70 / $30 plan; neither plan proves funds are available. Historical terms remain unchanged.
Proposed/configured terms for future draws. A published draw retains its own immutable policy.
Operator funding notes: Pending configuration. No allocation or collection is active.
Entries & snapshots
Each full holding unit earns one entry. Token accounts owned by the same wallet are combined before rounding down. With a 100,000-token threshold, 100K earns 1 entry, 500K earns 5 and 1M earns 10. These examples are not wallet data.
Which snapshots count is set by the draw policy each draw locks when it opens; the policy never changes afterwards. The “Draw rule” row in the program policy panel above shows the rule for new draws, and every draw record names its own policy.
Closing snapshot (policy retro-holder-v1). Entries use the balance at the finalized closing snapshot, captured after the scheduled close within the disclosed window. Selling or transferring before that snapshot can reduce entries.
Two snapshots (policy retro-holder-v2). A snapshot is taken at the start of the epoch and again at draw time, and each wallet's entries use the smaller of the two balances. To keep your entries, hold at least that amount at both snapshots. Balances between the two snapshots are not checked: selling and buying back before the closing snapshot leaves entries unchanged. Tokens bought after the opening snapshot earn no entries in that epoch. Example: 500K at the opening snapshot and 300K at the closing snapshot earns 3 entries; a wallet that buys 1M after the epoch starts earns 0 until the next epoch. If the opening snapshot is missed, that epoch has no draw; it never falls back to a single snapshot.
Each snapshot is the complete finalized holder account response captured inside its disclosed window. It is not an exact historical wall-clock balance or a top-holder sample. Changes after commitment do not change that draw.
Missed windows defer the draw. RPC failures stop selection. Treasury, operator, system/incinerator, configured exclusions and off-curve program owners are omitted. Custodial balances are attributed to their actual onchain owner.
Use the public wallet lookup to inspect current finalized balances and stored historical snapshot records separately. Current holdings never reconstruct past entries.
Selection you can reproduce
- Canonical wallet ordering and exact integer balances determine entries.
- The snapshot (for retro-holder-v2 draws: both holder lists, both slots and the min-balance entries list), prize evidence and locked policy are hashed and anchored in a finalized Solana memo before a pinned future drand quicknet beacon.
- The beacon’s BLS signature is verified. Weighted selection uses rejection sampling without expanding one row per ticket.
- A separate result receipt binds the selected outcome. Public records link to snapshot evidence and the independent verifier.
Immutable terms, database uniqueness, worker leases and exact signed-transaction recovery protect against duplicate execution. Unknown transaction outcomes are reconciled before another receipt can be offered. A memo records selection; it does not transfer a physical collectible.
Real prizes require real custody
A prize is published only after ownership/custody, authentication, funding and fulfillment arrangements are attested. Each dedicated prize page distinguishes actual photographs from reference artwork, condition, grading, sourced valuations and shipping regions.
Tokenized graded cards require a confirmed transfer to the winning wallet; redemption follows the supported custody provider’s terms where available. Shipped items require a completed winner claim and confirmed fulfillment order. Digital assets require a confirmed onchain transfer. A selected winner is not a delivery confirmation. Shipment or redemption remains a separate operator fulfillment record. No automatic SOL cash-out or 24-hour resale is implemented. Holding tokens does not grant ownership of treasury assets or guarantee a prize.
Winner selection and delivery are separate
Any future physical delivery requires an explicit selection and a separate fulfillment process: verify the actual owned item, confirm recipient eligibility and shipping costs, complete the arrangement, then record delivery evidence. The current site does not collect postal addresses, automatically ship items or substitute SOL payments for collectibles.
Packs
The Packs page sells tiered packs of retro games, paid in USDC directly or in SOL routed through Jupiter into USDC. A tier is offered only while the treasury holds funded, priced items for every rarity beyond those already promised to open orders; odds and a future drand round are locked before payment, and each pull is a redeemable claim cNFT. Sales stay closed until they are enabled for the network, and on mainnet only after owner approval. The earlier fictional demonstration is retired; its order records remain reachable.
Treasury & funding
The treasury displays finalized SOL and supported token account balances plus the latest 12 wallet transactions. Transaction deltas can include fees and rent; they are not claimed as revenue or purchases.
Available funds, commitments, reward expenditure and collectible acquisition costs need reconciled accounting records. They stay unavailable until that ledger exists. Funding allocations apply only when the corresponding program is activated. The homepage illustrates the new-coin 90/5/5 policy; it does not report collected fees. CI and historical programs retain their separate allocations.
What is available?
Available: rewards/status dashboard, public wallet lookup with verified configuration, treasury reads, stored draw proofs, authenticated inventory views and collectible research.
Not activated: real recurring draws until a verified token, complete-snapshot RPC, isolated database, authenticated funded prizes and an owner-approved acceptance run are in place. Paid openings, automatic purchases and automatic physical redemption are unavailable.
Detailed environment placement, migration and acceptance steps remain in the repository’s developer operations documentation.
After verified activation
Future marketplace, physical redemption and collection analytics depend on real inventory, sourced data and working fulfillment. They are not offered as functioning purchases today.