← The Journal Onchain Primer

Read your second straight off Base, without this site

Published July 18, 2026 · Corrected July 26, 2026 · Buy One Second

Here is a claim this project keeps making: when you mint a second, it is yours, and it does not live on our website. Fair enough. But a claim like that is only worth something if you can check it without us. If the only place you can see your second is the page we control, then in practice you are trusting a page, not a blockchain.

So this is the check. No wallet signature, no connecting anything, no spending. Every step below reads public data that already sits in the contract on Base.

Correction, July 26: The first version of this article told readers to use a generated "Read Contract" form on Basescan. That form is not available for this address because Basescan currently labels the contract unverified. The contract can still be read through Base's public RPC, but the function signature has to be supplied by the reader. The walkthrough below now uses that route.

The one address everything hangs off

There is a single contract behind the whole project, and its address is public on the about page: 0x069DCA9E0090B5c32Aa1ac73D9a748d7c27E31E5. That string is the thing to trust, not a logo or a familiar-looking domain. Its Basescan address page lists it as a contract, but it also says "Contract: Unverified." Without a published ABI, Basescan cannot build its usual set of friendly read buttons.

An unverified explorer page does not make the bytecode unreadable. It makes the reading less convenient and asks you to bring the function signature yourself. A read-only RPC call asks the contract a question without sending a transaction, so there is no wallet connection, signature, or network fee.

Verify the address before you lean on it. Copy it from the about page on the real domain, compare it character by character, and be suspicious of any second-hand link that hands you a slightly different one. A single swapped character is the whole phishing playbook.

Ask the contract about one second

Say you want to check second 43200, which is noon. Every second is stored as a plain integer from 0 to 86399, so noon really is just the number 43,200. With Foundry's Cast command-line tool, the read is one command:

cast call 0x069DCA9E0090B5c32Aa1ac73D9a748d7c27E31E5 \
  "getSecondData(uint256)(bool,uint256,address,string)" 43200 \
  --rpc-url https://mainnet.base.org

The quoted text contains both the function input and the four output types, so Cast can encode the question and decode the answer. Replace 43200 with any number from 0 through 86399. The result has four fields:

  1. minted: true or false. Has anyone claimed this second yet?
  2. tokenId: the ID of the NFT that represents it, if minted.
  3. owner_: the wallet address that currently holds it.
  4. url: the link the owner has attached, which they can change any time.

That is the whole state of a second in one call. The same contract exposes narrower reads called secondToTokenId and secondUrls. Once getSecondData gives you a token ID, the ERC-721 ownerOf function can check its current holder:

cast call 0x069DCA9E0090B5c32Aa1ac73D9a748d7c27E31E5 \
  "ownerOf(uint256)(address)" TOKEN_ID \
  --rpc-url https://mainnet.base.org

Replace TOKEN_ID with the number returned by the first call. Agreement between the two reads is a useful consistency check, though it is not an independent source: both answers come from the same contract state. The ERC-721 specification defines ownerOf as the function that returns an NFT owner's address.

Reading the answer honestly

A few things are worth being precise about, because it is easy to read more into this than the contract actually says.

The owner_ field is the truth about who holds the token right now. It is not a name, it is a wallet address, and the contract has no idea who is behind it. Ownership onchain means control of a key, nothing warmer than that. If the token changes hands on a marketplace, this field updates on its own, because it is reading the ledger, not a record we keep.

The url field is whatever the owner last set, and it is a pointer, not a promise. The contract stores the string; it does not visit the link, vouch for it, or keep the page at the other end alive. A stored URL can rot like any other. What the contract guarantees is narrow and real: it faithfully remembers the exact text the owner put there, and it lets that owner replace it whenever they want through the write function. We covered what that editing actually does in what happens onchain when you mint a second.

Why bother doing this by hand

Most days you will just use the site. It reads the same contract and formats the answer. The manual path matters when the interface is unavailable, or when you want to check whether the interface is telling the truth. Once the contract answers getSecondData for a second you hold, the dashboard becomes a convenience rather than the record.

There is also a plain safety payoff. Phishing works by getting between you and the real contract, usually with a lookalike site that wants you to sign something. If your instinct is to verify a second with a read-only RPC call to the known address, a fake front end has much less to work with. It cannot change what the real contract on Base returns.

None of this is financial advice, and being able to verify a token says nothing about what it is worth. Transactions on Base are irreversible and carry network fees, keys can be lost, and a link you attach is only as durable as the page behind it. The read itself is simpler: the contract either returns the state or it does not, and you can check that without asking Buy One Second for permission.

Sources

→ Pick a second on the clock · Rarity by construction · How Buy One Second works