Two questions look similar but cost wildly different amounts to answer. "Who owns second 43,200?" is instant. "Who owns everything, and what have they attached to it?" takes real work. Both are answered from the same public contract on Base, but by two very different read paths. Knowing which is which explains why the site's leaderboard takes a moment to fill in while a single lookup snaps back immediately.
Ask about a single second and the contract answers directly. There is a view called getSecondData(second). You pass it one integer between 0 and 86,399, and it returns four things at once: whether that second is minted, its token ID, its current owner, and the URL stored on it. One call in, four values out. The contract keeps this in a lookup keyed by the second number, so the answer does not depend on how many other seconds exist. Checking second 5 costs the same as checking second 80,000.
This is the read behind the earlier verify-it-yourself walkthrough. It is fast because it asks a precise question. You already know the key you care about, so the contract just hands back the row. No searching, no scanning, no assembling.
Now ask for the entire board: every claimed second, its owner, its link, all at once. There is no single call that returns "everything," and there is a reason for that. A contract will not loop over 86,400 slots to build you a list on demand, because that kind of unbounded work does not fit inside a normal read. So the full picture has to be reconstructed from the outside, in two stages.
First, find out which seconds were ever claimed. Every mint emits a SecondMinted event, a small permanent log entry that records the second, the token ID, the owner at mint time, the URL, and the referrer. To collect them all, the site pages backward through block history from the deployment block, asking for those events in chunks of 9,000 blocks at a time. The chunking is not decoration: the standard log query has a ceiling of 10,000 blocks per request, so the work is deliberately kept under it. Out of that pass comes a set of second numbers that have been minted at some point.
Second, and this is the part people miss, the event log tells you who owned each second when it was minted, not who owns it now. Seconds can be resold or transferred, and a transfer does not re-emit a mint event. So the site takes the list of minted seconds and reads their current state in bulk with getBatchSecondData, which accepts an array of seconds and returns arrays of owners and URLs, done in slices of 500 at a time. Only after both passes finish does the board show who holds what today.
SecondMinted record is frozen at mint. Current ownership lives in the contract's present state, which is what getBatchSecondData reads. Mixing the two up is how a leaderboard ends up crediting the wrong wallet after a resale.
This maps neatly onto something an earlier primer touched on: the minted count tells you how many seconds are taken, not which ones. The count is the cheap number, one field read from a view. The map of which-and-by-whom is the expensive one, the two-stage scan above. Same underlying truth, very different cost to extract.
It is also why the site has no database. Rather than keep a private copy of the board and risk it drifting from the chain, the front end rebuilds the whole thing from Base on each visit. That rebuild is slower than reading a stored table would be, and the tradeoff is chosen on purpose: the chain is the record, and a page that reconstructs itself from the record cannot quietly disagree with it. The cost of the expensive read buys you a board you never have to take on faith.
For you as a reader, the practical takeaway is small but real. If you only want to confirm your own second, use the cheap path: one getSecondData call, instant, no wallet, no waiting for a full scan. If you want the whole landscape, expect it to take a beat, because behind the scenes it is paging through block history and then re-reading current state. Neither is more "true" than the other. One is a targeted question, the other is a census.
Both paths prove the same reassuring thing: the ownership data is public and reconstructable by anyone, not held hostage inside this site. You can check a single second yourself, and in principle you could rebuild the entire board yourself the same way the page does. That is the property worth caring about.
It proves nothing about value or demand. A fully reconstructed board is a fact about who holds what, not a signal about what any of it is worth. As always: minting a second costs a real fee on Base and cannot be undone, lost keys stay lost, and phishing pages imitate real contracts, so confirm the address against the About page before connecting a wallet. Reading, which is all this primer describes, never needs one. This is not financial advice and a second is not an investment.
→ The site has no database · Count the supply yourself · Read your second off Base
getSecondData(uint256 _second) view returns (bool minted, uint256 tokenId, address owner_, string url) and getBatchSecondData(uint256[] _seconds) view returns (bool[] minted, uint256[] tokenIds, address[] owners, string[] urls). The scanAllSeconds routine pages SecondMinted events from DEPLOY_BLOCK in chunks of 9,000 blocks (under the 10,000-block log limit), then reads current owner/url via getBatchSecondData in slices of 500. The SecondMinted event carries (second, tokenId, owner, url, referrer).