Full feature specification for Sweep — a crypto-native sweepstakes platform on Base. Every feature, every mechanic, every design choice. Review → sign off → ship.
A crypto sweepstakes where you buy NFT tickets with USDT, get entered into 5 simultaneous prize tiers (daily through annual), earn more chances through referrals, and have a guaranteed prize floor backed by an LP vault — all on Base, provably fair, no-custody.
Every ticket purchase auto-splits into five pools. Bigger pools = bigger prizes = higher suspense. This creates a reason to keep playing every day while building toward life-changing jackpots.
Status: Done = shipped in contracts · Sprint = in current sprint · Future = planned · TBD = direction not locked
User pays USDT to buy a ticket. One ERC-721 NFT is minted per ticket. NFT is the proof of entry — tradeable on any NFT marketplace. No token-gating, open to anyone.
Three-layer randomness stack. No single oracle can be manipulated. Fallback chain ensures draws always complete.
Every ticket automatically feeds all 5 pools. PrizeDistributor contract handles splits at draw time. Users don't have to choose which pool — they're entered in all of them.
On-chain referral tracking via ReferralRegistry contract. Influencers and affiliates get a cut of tickets they drive. Referred users get a bonus entry or discount.
The LP Vault is a prize floor mechanism. LPs deposit USDT and earn yield. The vault backs minimum prize guarantees — so even on day 1 with few players, the daily prize is real. This is what makes launch-day prizes credible.
Users can subscribe for recurring auto-entry. Every period (daily/weekly) their wallet is auto-enrolled. Reduces friction — no need to remember to buy tickets.
Automated smart contract keepers trigger draws, close rounds, and process payouts on schedule. No manual admin required after launch.
Factory contract for deploying custom lottery pools. B2B feature — partners can create their own branded sweepstakes using the same infrastructure.
Sweepstakes legal model requires "no purchase necessary." Free entry via mail-in or social share keeps us on the right side of lottery law in the US.
Players earn points for: buying tickets, referring friends, playing consistently, and winning. Points can boost ticket multipliers or be redeemed for guaranteed entries.
Option for players to route their winnings (or a % of ticket price) to vetted charities. Framework Ventures identified as potential partner for first charity round.
Next.js frontend. Connect wallet → buy ticket → see prize pools → track your entries → claim (if needed). Clean, minimal, mobile-first.
In-Telegram ticket buying and draw notifications. Users can participate without leaving Telegram. Draw announcements sent to groups.
React component SDK and REST API for embedding Sweep into partner products. B2B distribution layer.
<SweepWidget /> React component (embeddable)PayoutEscrow contract holds prizes until the winner claims or a timeout triggers auto-send. Prevents stuck funds.
OpenZeppelin AccessControl with OPERATOR_ROLE and ADMIN_ROLE. Emergency pause stops all ticket sales and draws. Protects against exploits.
We're not inventing from scratch. Each mechanic has precedent. The differentiation is the combination: transparent, on-chain, multi-tier, with sweepstakes legal cover.
Three archetypes. Each has a different motivation and play pattern. Sweep is designed to serve all three simultaneously.
7 sprints from contracts to mainnet. Current sprint: S1 (contracts in DESIGN phase, moving to BUILD).
Architecture, contract stubs, Notion import, CLAUDE.md, repo structure, forge research track created.
Full SweepLottery + SweepTicket + PrizeDistributor implementation with USDT on Base. Tests. No LP vault yet.
LPVault (prize guarantee), ReferralRegistry (on-chain affiliates), RandomnessRouter (Pyth→VRF→drand fallback chain).
PoolFactory (B2B deployment), PayoutEscrow (unclaimed prize handling), SweepSubscription (auto-entry), Keeper automation.
REST API for partner integrations. React SweepWidget component. Webhook support for draw events.
Next.js web app (wallet connect, live pools, ticket history). Telegram bot (buy, notify, share).
Security audit (when ready), Base testnet deployment, end-to-end testing, bug bounty.
Base mainnet deploy. Seed LP vault. Launch first daily lottery. Affiliate campaign kickoff.
These are the decisions that aren't locked yet. Each needs Joseph's input before we build the next sprint that depends on them.
Current placeholder: $1–10 USDT. Research swarma will sim this. Questions:
Draft: 36% daily / 24% weekly / 18% monthly / 12% quarterly / 10% annual. Swarma will optimize this. Do we want to lock the splits, or should they be governance-adjustable?
How big does the LP vault need to be at launch for credible guarantees? Swarma will model this. Inputs needed:
Required for sweepstakes classification (no lottery license needed). Design not finalized. Options:
Roadmap mentions influencer affiliate campaign at launch. Who is the first major affiliate partner? Framework Ventures mentioned for charity — are they also the first affiliate?
Multiple designs possible. Needs product decision before Sprint 3:
9 research questions being run through our autonomous research loop (Grok + Codex + Gemini). Each question gets 3+ passes across iterations with different model perspectives. Status shows what's been answered.
What is the optimal % split across 5 tiers at different volumes?
Which ticket price ($1, $2, $5, $10 USDT) maximizes revenue × participation?
How large does the LP vault need to be for credible prize guarantees at launch?
What referral % split maximizes viral growth without destroying unit economics?
Simulate concrete annual journeys for each user type (see User Groups below).
Deep dive on mechanics from PoolTogether, Rollbit, Powerball, DraftKings, Habitica.
Model 3 growth scenarios over 12 months with full unit economics.
Which win-probability mechanics create the most engagement?
What's the smallest viable configuration that is self-sustaining without LP vault?
Each group has different motivations, play patterns, spend levels, and retention hooks. The game design must serve all 6 simultaneously. Each is being simulated in our research loop.
All numbers assume $2/ticket, 36/24/18/12/10 prize split, 10% ops. Revenue = ops cut. These are being validated by our swarma research loop.
Our research loop runs autonomously: Grok answers questions, Codex reviews for flawed assumptions, Grok CTO scores and decides whether to continue or pivot. Results feed back into this spec.
This doc is a living draft. Updated 2026-03-31. Sign-offs gate sprint scope locks.