BitMillions — Protocol Documentation
A fully automated, on-chain lottery protocol built on Base. Powered by Chainlink. Designed to run forever.
Play for the prize, stay for the cause.
Last updated: 2026-04-10
Table of Contents
- Introduction
- How It Works — Overview
- Ticket Format
- Prize Tiers
- Proceeds & Economics
- The Jackpot
- Charity System
- Referral & Loyalty System
- Draw Lifecycle
- Automation
- Randomness
- Financial Safety
- Governance & Owner Controls
- Technical Architecture
- Contract Constants & Limits
- Launch Configuration
- How to Play
- How to Claim Prizes
- FAQ
Introduction
BitMillions is a lottery protocol deployed on Base, built to operate without human intervention. It combines the familiar main numbers and lucky stars format with fully on-chain automation, verifiable randomness, and protocol-enforced charity donations.
No operator pockets the majority of what players spend. There is no manual draw operation. There is no trust required. The rules are encoded in the smart contract and enforced by constants that not even the protocol owners can override.
Four headline features define BitMillions:
1. Parimutuel prize structure — the prize pool is driven by ticket sales and distributed among winners. There are no fixed jackpots or house promises. The total prize value scales directly with player participation.
2. Protocol-enforced charity donations — between 5% and 25% of every ticket sale is allocated to charity by the contract — enforced, not optional. When a charity is active, funds go directly to their wallet. Charities rotate automatically each draw.
3. Verifiable randomness — winning numbers are derived from a Chainlink VRF seed with a cryptographic proof verified on-chain before it is accepted. No party — not the owners, not Chainlink, not miners — can predict or influence the outcome. This is a mathematical guarantee, not a promise.
4. Non-custodial withdrawals — once prizes are allocated to your address, only you can claim them. The contract holds the funds, but no operator can block, redirect, or delay your withdrawal. You claim when you are ready.
Additional key properties:
- Fully automated via Chainlink Automation — no manual draws, ever
- USDC-denominated — no price volatility, stable prizes
- Built on Base — low gas costs, native USDC, Coinbase ecosystem
- Referral and loyalty system — earn points for bringing in new players; redeem for discounts on future tickets
- Accessible via Farcaster miniapp, Base App, and web browser
- Transparent prize pool — all funds visible on-chain at all times
- Fully verifiable — smart contract is open source and verified on-chain; anyone can read the exact code that holds player funds
How It Works
- A draw opens with a jackpot and a featured charity
- Players buy tickets by choosing their numbers
- At draw time, Chainlink VRF generates a verifiably random seed
- Winning numbers are derived from that seed on-chain
- Winners across all prize tiers are computed automatically
- Prizes, donations, and royalties are allocated and become claimable
- A new draw opens immediately with the jackpot carried forward, and the cycle repeats
This cycle repeats indefinitely, fully automated, with no required human action.
Ticket Format
Each ticket consists of two sets of numbers:
- Main Numbers — pick 5 numbers from 1 to 50
- Lucky Stars — pick 2 numbers from 1 to 12
Each ticket costs 3 USDC.
Duplicate Tickets: You may choose to buy the same set of numbers multiple times. In a parimutuel system, each ticket represents a share of the prize pool. Buying duplicate tickets effectively acts as a prize multiplier; if your numbers win, you will claim a share for each ticket you hold.
Validation: Every ticket is validated at purchase time. A ticket that does not match the required format — exactly 5 main numbers and 2 lucky stars — is rejected on-chain.
Prize Tiers
Each draw has a jackpot tier — matching all 5 main numbers and both lucky stars — and 12 lower prize tiers that reward partial matches.
Prize tier structure:
| Tier | Main matched | Lucky Stars matched | % of prizes pool | Odds (1 in) |
|---|---|---|---|---|
| Jackpot | 5 | 2 | — | 139,838,160 |
| 2 | 5 | 1 | 6.525% | 6,991,908 |
| 3 | 5 | 0 | 1.525% | 3,107,515 |
| 4 | 4 | 2 | 0.475% | 621,503 |
| 5 | 4 | 1 | 0.875% | 31,075 |
| 6 | 3 | 2 | 0.925% | 14,125 |
| 7 | 4 | 0 | 0.650% | 13,811 |
| 8 | 2 | 2 | 3.250% | 985 |
| 9 | 3 | 1 | 3.625% | 706 |
| 10 | 3 | 0 | 6.750% | 314 |
| 11 | 1 | 2 | 8.175% | 188 |
| 12 | 2 | 1 | 25.750% | 49 |
| 13 | 2 | 0 | 41.475% | 22 |
The easiest prize — matching 2 main numbers and no lucky stars — has odds of 1 in 22. This tier pays approximately 6.57 USDC under conservative assumptions; actual payouts are typically higher, since fewer discount redemptions mean a larger effective prize pool.
Overall odds of winning any prize: 1 in 13. Across all 13 tiers combined, roughly 1 in every 13 tickets wins something.
Rules enforced on-chain:
- All tier allocations sum to exactly 100% of the prizes pool
- Every configured tier must have a non-zero allocation
- No tier can exceed the jackpot tier in numbers matched
What happens if a tier has no winners: The allocation for that tier is not paid out. The allocation remains in the contract and rolls into the next jackpot, growing it further.
Proceeds & Economics
Parimutuel Structure
BitMillions uses a parimutuel prize model: prizes are funded entirely by ticket sales and distributed among winners. There are no fixed jackpots promised by the protocol, no external funding, and no yield used to supplement the pool. The prize pool is exactly what players put in, minus the defined allocations. Every USDC goes back to players.
The practical implication: prize size scales directly with ticket volume. The more tickets sold in a draw, the larger the prizes for that draw's winners.
Allocation Breakdown
Every ticket purchase is automatically split into four allocations:
| Allocation | Launch value | Allowed range | Destination |
|---|---|---|---|
| Jackpot Rollover | 55% | min 25% | Next draw's jackpot |
| Prizes Pool | 30% | min 15% | Current draw tier winners |
| Charity Donation | 15% | 5%–25% | Featured charity wallet |
| Royalties | 0% | max 15% | Protocol owners |
pie
"Jackpot Rollover (55%)" : 55
"Prizes Pool (30%)" : 30
"Charity Donation (15%)" : 15
These bounds are hard-coded constants in the contract. The owner can configure values within these ranges, but cannot set values outside them — not even in an emergency. The sum of prizes, donations, and royalties cannot exceed 75%, guaranteeing at least 25% always rolls into the jackpot.
Why USDC: The prize pool is denominated in USDC, a stable, dollar-pegged token natively issued on Base by Circle. The jackpot value shown is exactly what winners receive: no conversion, no volatility, no slippage. A 50,000 USDC jackpot is 50,000 USDC, regardless of market conditions.
Using USDC rather than a volatile token means prize values do not fluctuate between when a draw closes and when a winner claims. Players entering the protocol take on no price exposure beyond what they chose to play for.
The Jackpot
The jackpot for each draw is the entire unlocked USDC balance of the contract at the time the draw opens. This includes:
- The jackpot fraction carried forward from the previous draw's ticket sales
- All unawarded tier allocations from draws where a tier had no winners
- Any external USDC sent directly to the contract
The jackpot grows every draw until someone wins it. If no one wins, the full jackpot carries forward automatically. More tickets sold means a larger amount carried into the next draw; player activity directly drives jackpot growth.
If the jackpot is won, a new draw opens immediately. The new jackpot is funded by that draw's jackpot fraction plus any unawarded tier allocations — smaller than the one just won, but not zero, and growing from the first ticket sold in the new draw. The protocol runs identically whether the jackpot was won last draw or has not been won in years.
There is no jackpot cap. There is no jackpot expiry.
External funds: Anyone can send USDC directly to the contract. That balance is added to the next draw's jackpot when it opens and has no effect on the current draw.
Jackpot splitting: If multiple players match the jackpot tier in the same draw, the jackpot is divided equally among all of them — the same as any other prize tier. This is handled automatically by the contract. A 100,000 USDC jackpot with two winners means 50,000 USDC each.
Charity System
Every draw is associated with one charity wallet address. A portion of every ticket sale is allocated to that charity — enforced by the contract, not left to the owners' judgment.
Rotation: Charities are maintained in an on-chain list. After each draw, the next charity in the list is automatically selected with no manual scheduling required. Each charity gets its turn in sequence, indefinitely.
Claiming: Donations use the same pull model as prize claims — charities call the contract to withdraw their allocated funds. Nothing is pushed automatically to any external address. This means a charity's inability or delay in claiming has no effect on any other part of the protocol.
Charity management: The protocol owner can add, update, or remove charities from the list. Any change to the charity list only affects the next draw — the charity featured in the current draw is fixed when that draw opens. Funds already allocated to a charity in a past draw are never affected by removal — those funds remain claimable by that charity indefinitely.
Charity information: Each charity has a name and website stored on-chain, visible to all players.
If no charities are registered: When the charity list is empty, the donation allocation for that draw is treated as additional rollover and added to the next draw's jackpot. No funds are lost — they flow through the protocol normally.
Referral & Loyalty System
Referrals: When buying tickets, a player can optionally provide a referrer address. The referrer earns 1 point for every ticket the referred player purchases in that transaction. Points accumulate and never expire.
Discounts: A player with enough points can apply a discount to a ticket purchase instead of providing a referral. Redeeming a discount costs a fixed 5 points — equal to the buy limit — and reduces the total cost of that transaction by 20%. Because the point cost is fixed, your savings scale with how many tickets you buy: redeeming on a full transaction of 5 tickets saves 3.00 USDC; redeeming on a single ticket saves only 0.60 USDC for the same 5-point spend. For best value, use discounts when buying a full transaction.
Rules:
- A referral and a discount cannot be used in the same transaction
- You cannot refer yourself
How points work:
- Points are per-address and non-transferable
- Points never expire — they accumulate indefinitely until spent
- There is no token; points are a balance tracked in the contract
- The referral reward is 1 point per ticket purchased — based on ticket count, not ticket price
This system rewards genuine player growth. Referrers benefit from bringing in new players, and active players are rewarded for their volume over time.
Draw Lifecycle
Each draw goes through a defined state machine:
stateDiagram-v2
direction LR
[*] --> OPEN
OPEN --> MIXING : upkeep trigger
MIXING --> DRAWING : VRF fulfilled
DRAWING --> OPEN : new draw opens
MIXING --> OPEN : postponed
Open
- Players can buy tickets
- The draw has a jackpot, a charity, a ticket price, and prize tier configuration
- The draw stays Open until the configured schedule triggers upkeep
Mixing
- Upkeep has been triggered
- A Chainlink VRF randomness request has been submitted
- A 1-hour timelock begins — the system waits for the random seed to arrive
- If the seed does not arrive within the timelock window, the draw is postponed: state resets to Open and the draw continues with the same jackpot and configuration
- Players cannot buy tickets during Mixing
Drawing
- The random seed has been received
- The next upkeep call resolves the draw:
- Winning numbers are derived from the seed
- Winners are counted per tier
- Prizes, donations, and royalties are allocated
- Immediately after, the next draw opens
Postponement
If conditions are not met (no new ticket sales, VRF failure), the draw is postponed rather than failing. The system resets cleanly and the next upkeep trigger will attempt the draw again. This ensures the protocol never enters a broken state.
Automation
BitMillions uses Chainlink Automation as its default trigger mechanism. Once the contract is deployed and registered, draws advance automatically without any human action.
Zero operational dependency: Traditional lotteries require staff to operate draws, validate results, and process payments. BitMillions has none of that. There are no servers to maintain, no backend to monitor, no employees required to run a draw. The contract tells Chainlink when to act, Chainlink acts, and the cycle continues. The protocol's ability to run the next draw is not dependent on the owners being available or taking any action.
The Chainlink Automation and VRF subscriptions are monitored and topped up automatically via an external Chainlink-based process — not manually, and not from within the BitMillions contract itself. This separation is deliberate: Chainlink's subscription management interfaces may evolve over time, and keeping that logic outside the core contract ensures the lottery itself remains simple, auditable, and unaffected by any future infrastructure changes.
Automation as a convenience layer: Chainlink Automation is the default and expected way draws are triggered — but it is not the only way. The draw advancement function is public, meaning anyone can call it directly if the conditions are met. If Chainlink Automation were ever to fail, be discontinued, or be replaced by a better solution, the protocol would continue operating. The draw schedule is enforced by the contract itself, not by Chainlink. Automation is the convenience layer — the contract is the source of truth.
The only component that cannot be substituted is Chainlink VRF. Randomness must come from a verifiable, tamper-proof source, and VRF is the only system that provides that guarantee on-chain today.
How it works: Chainlink nodes continuously check whether the contract needs action. The contract responds based on its internal state and schedule. When action is needed, Chainlink triggers the next step in the draw lifecycle automatically.
Schedule configuration: The upkeep schedule is defined by a repeating period and a set of trigger offsets within that period. Draw times are anchored to a fixed reference point so they land consistently on the same days of the week.
Randomness
Why randomness matters
Every lottery lives or dies by one question: can the outcome be predicted or manipulated? In traditional lotteries, players trust an organization. In most blockchain lotteries, players trust that block hashes or timestamps haven't been gamed by miners. Neither is good enough.
BitMillions uses Chainlink VRF V2 Plus, a verifiable random function that produces cryptographic proof alongside every random value it generates. This proof is verified on-chain before the seed is accepted. If the proof fails, the seed is rejected. There is no fallback to a weaker source of randomness.
The result: nobody in the world — not the protocol owners, not Chainlink, not miners, not any party anywhere in the system — can know what the winning numbers will be before they are drawn. This is not a policy or a promise. It is a mathematical guarantee enforced by the contract.
How it works:
- At draw time, the contract requests one random word from the Chainlink VRF coordinator
- Chainlink generates the random word off-chain alongside a cryptographic proof of its validity
- The proof is verified on-chain before the seed is accepted by the contract
- The seed drives a sequence of cryptographic hashes to derive each winning number
- Numbers are drawn without replacement — duplicate values are skipped and the next hash is used
What this means for players: Once a draw enters the Mixing state, the outcome is cryptographically sealed from external influence. The winning numbers will be whatever the VRF produces — unpredictable, unbiased, and publicly verifiable after the fact by anyone who wants to check.
The VRF is configured to require the maximum number of block confirmations before delivering the random seed. This means the draw takes slightly longer to resolve, but provides the strongest security guarantee Chainlink VRF offers — making any attempt to predict or influence the outcome even more computationally infeasible.
Financial Safety
Non-Custodial Withdrawals
Prizes, charity donations, and royalties are all claimed via a pull model — the recipient calls the contract to withdraw their allocated funds. Nothing is pushed automatically to any external address. The contract holds the funds until claimed, but no operator has any ability to redirect or withhold them.
This has two important properties:
- No frozen funds — there is no operator who can block, delay, or deny your withdrawal. Once a prize is allocated to your address, only you can claim it.
- No single point of failure — every claim is independent. No recipient's inability to claim has any effect on any other withdrawal in the system.
All prizes across every draw you've ever participated in are aggregated and claimed in a single transaction — no need to go draw by draw. Prizes are claimable indefinitely, weeks or years later. There is no expiry.
Governance & Owner Controls
Multisig ownership: The contract is owned by a multisig wallet requiring multiple keyholders to sign off on any action before it executes. No single person — not even one of the founders — can unilaterally change protocol parameters, add or remove charities, or claim royalties. This eliminates single points of failure and single points of compromise.
What the owner can do:
- Set the draw configuration for the next draw (pool sizes, tier allocations, ticket price, limits)
- Add, update, or remove charities
- Update the Chainlink VRF subscription configuration
- Update the automation schedule
- Claim accumulated royalties
Any change takes effect only when the next draw opens. The current draw always runs with the parameters it started with — no owner action can alter it mid-draw.
What the owner cannot do:
- Override the hard-coded minimum and maximum allocation bounds
- Manipulate the random seed or influence the draw outcome
- Access locked funds belonging to players or charities
- Change the USDC token address
Non-upgradeable by design: The contract cannot be upgraded after deployment. This is a deliberate choice: upgradeability, even with proper access controls, means someone retains the power to change the rules after the fact, which reintroduces the human trust dependency that on-chain protocols are designed to remove. What is deployed is what runs, permanently.
The tradeoff is real: if a bug is found, it cannot be patched. That is precisely why the protocol went through an extended development and testing period before deployment. The objective is correctness before launch, not a fallback mechanism afterwards.
Open source and verifiable: The smart contract source code is publicly available and verified on-chain via the Base block explorer. The frontend is open source on GitHub. Any player, researcher, or auditor can inspect exactly what code is running and verify that it matches what is deployed. There are no hidden components.
Technical Architecture
The Parimutuel Challenge
The most technically significant problem in building BitMillions was making a true parimutuel lottery work on-chain at scale.
In a parimutuel lottery, prizes depend on how many winners there are in each tier — you cannot know the payout per winner until after the draw. The naive approach to counting winners requires checking every ticket against the winning numbers at draw time. With potentially millions of tickets, this becomes impractical on a blockchain: gas costs grow with ticket volume and draws become impossible to execute reliably.
Most on-chain lotteries sidestep this by abandoning the parimutuel structure entirely, using fixed prizes, or compromising the format — for example, making number order matter on tickets, which converts winner identification into a simple hash lookup but changes the nature of the game. Another common approach is to move the winner-counting computation off-chain, but that reintroduces the trust dependency that on-chain protocols are designed to eliminate.
BitMillions solves this with a custom on-chain data structure that is updated incrementally as each ticket is purchased. By the time a draw closes, the contract already holds everything needed to resolve winner counts across all tiers in a single bounded operation — one whose cost is determined by the number of drawn numbers, not the number of tickets sold. Draw execution cost is constant regardless of ticket volume.
Prize amounts per winner are computed once at draw time and stored. When a player claims, the contract reads those pre-computed values directly — claims are cheap and every winner in the same tier receives exactly the same amount, regardless of when they claim.
For a full technical treatment of the algorithm — including the on-chain data structure, the Möbius inversion, and the gas complexity analysis — see the BitMillions technical whitepaper.
Contract Constants & Limits
The anti-abuse guarantee
The protocol owners can configure draw parameters — ticket price, pool sizes, prize tier allocations, charity percentages. But they cannot configure their way into exploiting the system. A set of immutable constants, compiled into the contract bytecode, defines the boundaries of what is permissible. These cannot be changed by anyone, ever, without redeploying an entirely new contract.
The practical effect: players do not need to trust that the owners will behave fairly. The contract enforces fairness regardless of owner intent. A minimum always goes to charity. A minimum always rolls into the next jackpot. The owners' cut is capped. These are facts about the code, not promises from a team.
The specific values below represent the current deployment. They are noted here for completeness and transparency — not as the primary point, which is simply that they exist and cannot be overridden:
| Constant | Value | What it prevents |
|---|---|---|
| Main numbers pool minimum | 32 | Pool too small to be meaningful |
| Lucky stars pool minimum | 8 | Pool too small to be meaningful |
| Jackpot margin (main numbers) | 16 | Jackpot too easy to win |
| Jackpot margin (lucky stars) | 4 | Jackpot too easy to win |
| Minimum prize tiers | 4 | Too few prize tiers, reducing player value |
| Minimum jackpot rollover | 25% | Jackpot growth starved |
| Minimum prizes allocation | 15% | Prize pool gutted |
| Minimum charity allocation | 5% | Charity allocation removed |
| Maximum charity allocation | 25% | Donations used to drain the prize pool |
| Maximum royalties | 15% | Owners taking more than their fair share |
| Draw timelock | 1 hour | Minimum interval between draws; also the window after which a VRF non-response is treated as a failure |
The 25% ceiling on charity donations serves a dual purpose. The obvious one is preventing the prizes pool from being gutted via inflated charity allocations. The less obvious one concerns the charity list itself: the owner controls which wallet addresses are registered as charities in the protocol. A compromised owner key could add an attacker-controlled address and set the charity allocation to its maximum. By capping that maximum at 25%, the protocol bounds the value extractable via this vector — limiting the economic incentive to target the owner role for charity misdirection in the first place.
Launch Configuration
These are the parameters set at launch. They can be adjusted by the owners within the contract's hard-coded bounds, but the intent is to keep them stable.
| Parameter | Value |
|---|---|
| Ticket price | 3 USDC |
| Main numbers pool | 1–50 |
| Lucky stars pool | 1–12 |
| Numbers to pick | 5 main + 2 lucky stars |
| Ticket buy limit | 5 per transaction |
| Ticket total limit | 100 per draw per address |
| Prizes allocation | 30% |
| Charity allocation | 15% |
| Royalties | 0% |
| Jackpot rollover | 55% |
| Draw schedule | Tuesday & Friday, 21:00 CET |
| Prize tiers | 12 tiers below jackpot |
How to Play
- Open BitMillions in Farcaster, Base App, or at https://bitmillions.app/
- Connect your wallet (or use the miniapp — your Farcaster wallet is used automatically)
- Make sure you have USDC on Base
- Pick 5 Main Numbers (1–50) and 2 Lucky Stars (1–12)
- Optionally provide a referrer address or apply a discount if you have points
- Submit your ticket purchase and confirm the transaction
- Your ticket is recorded on-chain — no email, no account needed
You can buy up to 5 tickets per transaction and up to 100 tickets total per draw.
Draw schedule: Draws run twice a week — every Tuesday and Friday at 21:00 CET. This is set in the contract and verifiable on-chain at any time.
How to Claim Prizes
Prizes are not sent automatically. To claim:
- Open BitMillions after the draw has closed
- Your total winnings are shown — across every draw you have participated in
- Submit a claim and confirm the transaction
- USDC is transferred to your wallet
As you play across draws, your winnings accumulate automatically — the protocol tracks them for you. When you claim, everything is collected in a single transaction. There is no need to claim after every draw, and no expiry — your prizes will be there whenever you are ready.
FAQ
What is the ticket price? 3 USDC per ticket.
Do I need USDC on Base specifically? Yes. BitMillions only accepts USDC on the Base network. USDC on other chains (Ethereum mainnet, Arbitrum, etc.) cannot be used directly — you would need to bridge it to Base first.
Can I buy tickets on behalf of someone else? No. Tickets are associated with the address that submits the transaction. Prizes are claimable only by that address.
Is my ticket data public? Yes. All tickets are stored on-chain and visible to anyone. The numbers you chose can be seen by anyone who looks.
What if two people both win the jackpot? The jackpot is split equally between all jackpot tier winners in that draw. This is enforced by the contract — there is no human decision involved.
What happens to prize money from a tier that has no winners? If a prize tier has no winners in a draw, the allocation for that tier is not paid out. It remains in the contract and rolls into the next jackpot, growing it further.
Is there a maximum jackpot? No. The jackpot has no cap and no expiry. It grows every draw until someone wins it — and if it goes unclaimed for years, it keeps accumulating. There is no mechanism that resets or limits it.
What happens after the jackpot is won? The draw closes, prizes are distributed, and a new draw opens immediately — automatically, with no human intervention. The new jackpot starts from the rollover fraction of that draw's ticket sales, plus any tier allocations that had no winners. It is smaller than the jackpot that was just won, but it is not zero, and it begins growing again from the first ticket sold.
The protocol does not depend on an unclaimed jackpot to keep running. Every ticket sold generates rollover regardless of whether the jackpot was won last draw or hasn't been won in years. The lottery runs the same way either way.
Can I lose my prize if I don't claim quickly? No. Your winnings accumulate across draws as you play and sit in the contract until you claim them. There is no expiry, no timeout, and no mechanism that can redirect your funds elsewhere. They will be there whenever you are ready.
Do my referral points expire? No. Points accumulate indefinitely and are never cancelled. They sit in the contract until you choose to spend them on a discount.
When should I use my discount? For best value, redeem your discount when buying a full transaction of 5 tickets. The discount costs a fixed 5 points regardless of how many tickets you buy, but the savings scale with ticket count — 5 tickets saves 3.00 USDC, while 1 ticket saves only 0.60 USDC for the same point spend.
What happens if nobody buys tickets? If there are no new ticket sales before the draw trigger, the draw is postponed. The jackpot carries forward and the draw tries again at the next scheduled trigger.
What happens if Chainlink VRF fails? The contract enters a 1-hour timelock in the Mixing state. If the random seed is not received within that window, the draw is postponed, state resets to Open, and the next trigger will try again.
What happens to my tickets if a draw is postponed? Your tickets are safe. The draw restarts with the same jackpot and configuration — nothing is lost or cancelled. Your tickets remain valid and will be entered into the draw when it runs.
Can the owners change the rules mid-draw? No. Any change the owner makes — draw configuration, charity, ticket price, pool sizes — only takes effect when the next draw opens. The current draw always runs with the parameters it started with, and cannot be altered once it is open.
Is BitMillions audited? Audit status will be listed here when available.
Is the code open source? Yes. The smart contract is verified on the Base block explorer and the frontend is publicly available on GitHub. Anyone can read and verify the exact code that is running.
Why does each draw take two automated steps instead of one? The randomness request and the draw computation are intentionally separated. The first step requests the random seed and waits for it to arrive. The second step uses that seed to derive the winning numbers, count winners, and allocate prizes. Splitting them ensures the draw computation always has the full resources it needs, and that the randomness request is kept as simple as possible.
Does someone need to manually top up the Chainlink subscriptions to keep the protocol running? No. The subscriptions are monitored and topped up automatically via an external process — not manually, and not from within the BitMillions contract. If Chainlink Automation were ever unavailable, anyone can trigger the draw directly — the function is public. The only irreplaceable component is Chainlink VRF, which provides the verifiable randomness that makes the draw trustworthy.
BitMillions smart contract is open source. Contract address and verified source will be published at launch.