The second you pick is not the token you get

There are two numbers hiding in every mint here, and people tend to notice only one of them. The first is the second you choose, somewhere between 0 and 86,399. The second is the token id the contract writes down when it records your mint. They are not the same number, and they are not assigned by the same logic.

The gap is easy to overlook because most of the site speaks in seconds. The clock shows a second, the picker takes a second, the leaderboard counts seconds. But underneath, this is a plain ERC-721 collection, and ERC-721 tokens are numbered in the order they are created, not in the order of whatever they happen to represent.

Two numbers, two jobs

The second is a coordinate you pick. It answers "which slot in the day do I want?" It maps to a clock face: 0 is 00:00:00, 43,200 is noon, 86,399 is the last tick before midnight. You decide it before you ever touch the contract.

The token id is a receipt number the contract decides. It answers "which mint was this, counting from the first one?" You do not choose it, and you cannot reserve it. It falls out of the order in which people show up. The tenth person to mint gets token 10, whether they claimed second 5 or second 70,000.

The first mint makes the gap concrete

You do not have to take this on faith. The contract's first SecondMinted event on Base is a matter of public record, and it settles the point in one line. The very first mint claimed second 333 and received token id 1.

So the earliest token in the entire collection is not second 0, or second 1, or any tidy number near the start of the day. It is second 333, which on a clock is 00:05:33, five minutes and change past midnight. Somebody picked that coordinate, and because they were first, the contract stamped their mint as token 1. The two numbers have nothing to do with each other.

The contract keeps a direct lookup between them, a read-only view named secondToTokenId. Ask it about second 333 and it returns 1. That is the bridge: you give it a clock coordinate, it gives you back the receipt number.

secondToTokenId(333) → 1
// second 333 (00:05:33) was minted first, so it holds token id 1

How the code carries both

Once you know to look, the pairing shows up everywhere in the interface. The getSecondData view returns four things for any second, and the first two are exactly this pair:

getSecondData(uint256 _second)
  → (bool minted, uint256 tokenId, address owner_, string url)

Pass it a second, and it tells you whether that slot is taken, which token id sits there, who owns it, and where its link points. The SecondMinted event does the same at write time, recording the second and the token id as two separate indexed fields so either can be searched independently:

event SecondMinted(
  uint256 indexed second,
  uint256 indexed tokenId,
  address indexed owner, ...)

The contract went to the trouble of indexing both. That is a small design tell: it expects you to want to find a token by its clock position sometimes, and by its mint order other times.

Why this matters when you collect

The practical payoff is that a low second number tells you nothing about how early a token was minted. Second 7 sounds like it should be ancient, near the birth of the collection. It is not. It is 00:00:07 on the clock, and it could be minted tomorrow, at which point it would carry a much larger token id than second 333 does. The clock coordinate and the mint order are simply different axes.

This connects to something covered before, the difference between clock order and mint chronology. If you care about being early in the collection's history, the token id is the number that speaks to that, along with the block and transaction that placed the mint in Base's ledger. If you care about the time itself, the meaning you attach to a coordinate on the clock, the second is your number. Neither one is better. They just answer different questions.

What the two numbers do not settle

Holding token id 1, or second 333, or any particular pair, does not make a token worth more. There is no field in the contract that ranks tokens, grades them, or promises anything to an early mint. A low token id is a fact about sequence, and a memorable second is a fact about the clock. Both are honest, and both are just descriptions. The chain records who owns what and in what order it happened. It does not record value, 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 imitate real ones, so confirm the contract address against the About page before connecting anything. Reading, though, costs nothing and needs no wallet: the views above are open to anyone. None of this is financial advice, and a second is not an investment.

→ Read your second straight off Base · Clock order versus mint order · Count the supply yourself