There is a small pink bar near the top of the home page that says "Monthly Jackpot," a balance in ETH, and a button marked Draw. Most of the time the button is greyed out and shows a countdown instead. It is easy to read past it as decoration. It is not. It is a working piece of the contract, and it behaves in a way that is worth slowing down for, because it says something about how these systems can run without anyone standing behind a counter.
I want to describe only what I can actually see in the site's code and the contract interface it talks to. Where the front end stops telling me something, I will say so plainly rather than fill the gap with a guess.
The balance you see comes from a single read. The contract exposes a view named getJackpotInfo(), and it hands back five things at once: the current balance, the timestamp of the last draw, the total paid out so far, the number of minted seconds, and a boolean called canDraw. The page calls this every thirty seconds and just prints the balance. There is also a plainer jackpotBalance() view if all you want is the number.
None of this needs a wallet. These are read-only queries, the same kind the leaderboard and the minted counter already lean on. Anyone pointing a block explorer at the contract can ask the same question and get the same five answers. The pool has no private state to hide behind. What it knows, you can know.
When the button is greyed out, the page computes a countdown by taking the last draw's timestamp and adding 2,592,000 seconds. That number is exactly thirty days. So "monthly" here is not a vibe or a marketing word. It is a fixed interval measured from the moment of the previous draw. The canDraw flag is the contract's own answer to whether that interval has elapsed and a draw is currently allowed.
There is a nice symmetry in a project built on 86,400 seconds keeping time this way. The clock on the home page counts a single day in seconds; the jackpot counts its own cycle in seconds too, just a much longer one. Same unit, different scale.
This is the part I find most interesting. When canDraw is true, the Draw button wakes up, and pressing it sends a transaction that calls drawJackpot() on the contract. The only thing the front end insists on is that a wallet is connected. It does not check that you are the owner, an admin, or anyone special. If the timer has elapsed, whoever gets there first and pays the gas can trigger the draw.
That means there is no host who has to remember to run the raffle. The pool does not wait on a person or a server to fire a monthly job. It sits there until the interval passes, and then the first participant who cares enough to click completes it for everyone. The mechanism is permissionless in the literal sense: the permission is the elapsed timer, not a name on a list.
When a draw goes through, the contract emits an event called JackpotPaid. Its fields are a token ID, a winner address, an amount, and a draw day. The winner is an address, but notice the token ID sitting right next to it. The payout is tied to a specific minted second. So the thing that wins is a token in the set, and the ETH lands with whoever holds it at the time of the draw. The event, like every event here, is permanent and public. The record of who won and how much is not a claim on a webpage; it is a line in the log anyone can pull.
Here is where I stop, because honesty matters more than a tidy explanation. The site's code shows me the balance, the thirty-day timer, the permissionless draw, and the shape of the payout event. It does not show me how a winning second is chosen, and it does not show me how the pool is funded. Those rules live in the contract's own logic, not in the browser JavaScript I can read from the page. I am not going to describe a selection method or a funding split I cannot see, because inventing that would be exactly the kind of confident guess this journal tries to avoid.
If you want the real answer to those questions, the honest path is the same one I would take: read the deployed contract on Base directly. The source and its verified logic are the authority, not this article and not the interface. Anything I told you about the odds would be a story; the contract is the fact.
A jackpot is a fun mechanic, and it is easy to let the word do more than it should. So, plainly: none of this is financial advice, and a second is not an investment. Minting costs a real fee on Base, transactions are irreversible, lost keys stay lost, and a prize pool that pays out is not the same as a prize pool that pays you. Most participants in any draw do not win it. Whatever the balance reads today, treat it as a feature of a thing you already find interesting, not as a reason to expect a return.
What holds up, after all the caveats, is the design. A public balance, a fixed timer, a draw no single person has to run, and a payout written to a log everyone can read. When the machinery is that visible, there is not much room for a private version of events. You do not have to trust the draw. You can watch it.
→ See the clock and the jackpot bar · Read your second straight off Base · How referrals work onchain
loadJackpot() reads the balance and gates the button on canDraw; the countdown adds 2,592,000 seconds (30 days) to the last draw; drawJackpot() is called after only a wallet-connection check.getJackpotInfo() returns (uint256 balance, uint256 lastDraw, uint256 totalPaid, uint256 mintedCount, bool canDraw); jackpotBalance() is a read-only view; drawJackpot() triggers a draw; the JackpotPaid(uint256 tokenId, address winner, uint256 amount, uint256 drawDay) event records each payout.