What a wallet actually sees when it looks at your second

You mint a second and the site draws it back to you. Fine. But the site is only one reader. A wallet app, a marketplace, an explorer, some indexer you have never heard of: they all ask the contract the same question, in the same standard way, and none of them load buyonesecond.com to do it. That question is tokenURI, and this is what it returns here.

The question every NFT tool asks first

ERC-721 defines an optional metadata extension with three functions: name(), symbol(), and tokenURI(uint256). The first two describe the collection, the third describes one token. A contract advertises which interfaces it implements through ERC-165, so a tool can check before it asks.

I ran those checks read-only against Base today. supportsInterface returned true for 0x80ac58cd (ERC-721 itself), for 0x5b5e139f (the metadata extension), and for 0x2a55205a (ERC-2981 royalties). name() returns BuyOneSecond and symbol() returns SECOND. So the standard doors are all open, and any tool that speaks ERC-721 can walk in without knowing anything about clocks or 86,400.

The metadata is not hosted anywhere

Most collections answer tokenURI with a link: an IPFS hash, or an https URL to a metadata server. Someone has to keep that thing alive. This contract does not do that. Calling tokenURI(1) returns a 321-character string that starts like this:

data:application/json;base64,eyJuYW1lIjoiU2Vjb25kICMzMzMi...

That is a data URL, the scheme defined in RFC 2397 back in 1998, which lets you inline a small payload instead of pointing at one. Base64-decode the part after the comma and you get 218 bytes of JSON that the contract assembled itself, on the fly, at the moment you asked:

{
  "name": "Second #333",
  "description": "BuyOneSecond - Second 333 (00:05:33)",
  "image": "",
  "attributes": [
    {"trait_type": "Second", "value": 333},
    {"trait_type": "Time",   "value": "00:05:33"}
  ],
  "external_url": "https://buy1second.com"
}

Token 1 is the second 333, which is 00:05:33 on the clock. The contract did the division and the zero-padding in Solidity and handed back a string. No server was involved, no pinning service, nothing to renew. The metadata for a second cannot rot while the chain is up, because there is no separate place for it to rot in. That is a nice property and it is worth naming plainly rather than dressing up: it is the difference between a token that describes itself and a token that points at a description someone else is renting.

The empty image field

Look again at that JSON. "image": "". There is nothing there.

The ERC-721 metadata schema describes image as a URI pointing at something with an image/* media type. An empty string is not that. Some contracts inline an SVG here as a second data URL and render the token entirely onchain. This one leaves the field present but blank, so any tool that wants a picture has nothing to draw and will fall back to whatever placeholder it uses. What each marketplace does in that situation is up to that marketplace, and I am not going to guess on their behalf.

I could have written around this. It seemed more useful to point at it, because it is the kind of detail you only find by decoding the thing yourself, and because it makes a real point about where the meaning of a second lives. The traits carry the whole payload: Second: 333 and Time: 00:05:33. A collection built on time does not strictly need a picture to be legible; a number and a clock reading tell you what you own. Whether it should have one anyway is a fair question, and an honest one to leave open.

The link in the metadata is not your link

Worth separating two things that both look like URLs. The external_url in the metadata for token 1 reads https://buy1second.com, with no token id in it, so it points at the project rather than at your particular second. I followed it: it answers HTTP 301 and redirects to https://buyonesecond.com/, which is where it should land, though it does mean the metadata leans on a redirect staying in place.

The URL you set on your second when you mint is a different record entirely. It lives in secondUrls and comes back through getSecondData, and you can rewrite it whenever you like. It does not appear in tokenURI at all. So a marketplace reading standard metadata will not show your link, and the site reading getSecondData will. Two readers, two different fields, both correct.

Royalties answer the same standard way

Since the contract reports ERC-2981 support, I asked it the standard royalty question: royaltyInfo for token 1 at a hypothetical sale price of 1 ETH. It returns a single receiver address and an amount of 0.1 ETH, which is the ten percent already stored as ROYALTY_BPS = 1000. The earlier piece on royalties covers what that does and does not compel a marketplace to do; the point here is narrower. The number is not only in the interface, it is answerable through the exact function outside tools already call.

Why any of this matters

Because it is the difference between a project telling you what your token is and your token telling you itself. Every fact above came out of the contract over a public RPC, with no wallet, no signature, and no fee. If this site vanished tomorrow, tokenURI(1) would still return the same JSON saying second 333 is 00:05:33, and any ERC-721 tool on earth could read it.

Nothing in that metadata says a second is worth anything, and none of it is financial advice or a suggestion to buy. Minting costs a real fee on Base, transactions cannot be undone, lost keys stay lost, and phishing stays a hazard around anything that touches a wallet. Reading is the free part. Decode the string yourself if you want; the bytes will say the same thing to you as they said to me.

→ Read your second straight off Base · The second you pick is not the token you get · Permanent token, mutable link · The 10% royalty on a resold second