Say you want to know who holds a particular second. Maybe it is one you are thinking about, maybe it is your own and you just want to see it confirmed by the chain rather than by this website. There are two ways to ask, and the interesting part is that they take different routes to the same answer.
The first way is the one this site was built around. The second way is the one every wallet and marketplace already speaks, because underneath the clock metaphor a second is a plain ERC-721 token. Knowing both is worth the few minutes it takes, mostly because it means you never have to trust a single view to be honest with you.
The contract has a convenience view named getSecondData. You give it a second, and it hands back everything the front end needs in one call.
getSecondData(uint256 _second)
→ (bool minted, uint256 tokenId, address owner_, string url)
Ask it about second 333 and it tells you the slot is minted, that it carries token id 1, who the current owner is, and where the link points. This is the read behind the leaderboard, the timeline, and the panel that shows the seconds you hold. It is shaped for this project: it speaks in seconds, which is the unit the whole site cares about.
A second is a token, and ERC-721 already has a settled way to ask who owns a token. The catch is that ownerOf wants a token id, not a second. So you translate first. The contract keeps a lookup for exactly this: secondToTokenId takes a clock coordinate and returns the token id that sits there.
secondToTokenId(333) → 1
ownerOf(1) → 0x818f...1245
Two hops instead of one. Second becomes token id, token id becomes owner. The payoff is that the second hop uses ownerOf, the standard method, which means any tool that understands ERC-721 can finish the job without knowing a thing about Buy One Second. A block explorer, a wallet, a generic script: none of them have heard of seconds, but all of them know how to call ownerOf.
Here is the real point. Both routes end at the same owner. When I checked second 333 against Base, getSecondData reported token id 1 and an owner address ending in ...1245. The other route, secondToTokenId(333) returning 1 and then ownerOf(1), returned the same address. That is the design working as intended.
I want to be careful here, because it is easy to oversell this. If the two paths disagreed, it would mean the contract was doing something strange, not that you had caught it lying with an outside source. The two answers come from the same place. But the value is still real: ownerOf is the interface a marketplace uses to decide who can list a token, and the interface a wallet uses to show you what you hold. Being able to reach the same fact through that door means the site's version of ownership and the wider ecosystem's version are the same fact, not two stories that might drift apart.
If you are working in seconds, use getSecondData. One call, everything you need, no translation. It is the natural fit when you already think of a token by its place on the clock.
If you are working in token ids, or you are using a tool that only speaks ERC-721, go the other way. Translate the second once with secondToTokenId, then hand the token id to ownerOf and let the standard do its job. This is also the route to reach for if you ever want to confirm a claim without relying on any of this project's own views: the token id and ownerOf are enough.
There is a small honesty note worth keeping. secondToTokenId returns 0 for a second that was never minted, and 0 is also a valid token id in some collections, so pair it with the minted flag from getSecondData if you want to be sure a slot is actually claimed rather than empty. On this contract the first real token is id 1, but do not lean on that as a rule; check the flag.
Both routes prove one thing cleanly: ownership here is public and checkable by anyone, through a project view or through the ERC-721 standard, with no wallet and no permission. That is the whole promise of putting it onchain. What neither route proves is anything about worth. The contract records who holds a second and, through the token id, where it sits in mint order. It does not record value, demand, or a promise, and it never will.
The usual cautions hold. Minting is a real transaction on Base with a network fee, and it cannot be undone once it confirms. Lost keys mean a lost token. Phishing sites copy real ones, so confirm the contract address against the About page before connecting anything. Reading, though, is free and needs no wallet: every view above is open to anyone who wants to check. None of this is financial advice, and a second is not an investment.
→ The second you pick is not the token you get · Read your second straight off Base · One second, or the whole board
getSecondData(uint256) returning (bool minted, uint256 tokenId, address owner_, string url) and secondToTokenId(uint256) returning a token id. ownerOf(uint256) is the standard ERC-721 owner lookup.0x2105), read-only queries accessed August 4, 2026. For second 333: getSecondData returned minted with token id 1; secondToTokenId(333) returned 1; ownerOf(1) returned the same owner address (ending ...1245) as getSecondData. No wallet, signature, or transaction was used.ownerOf(uint256) interface.