Base only ever ticks on odd seconds

This project sells all 86,400 seconds of a day. The chain it sells them on has never written a block on half of them.

That is not a metaphor. It is arithmetic, and you can check it in about a minute with a public RPC endpoint and no wallet. Base block timestamps are not measurements of when a block happened. They are entries in a fixed lattice, and the lattice skips every other second.

The formula

Base is an OP Stack chain, and the OP Stack derivation spec is blunt about how an L2 block gets its timestamp: block.timestamp = prev_l2_timestamp + l2_block_time. The genesis block's timestamp is set explicitly in the chain config, and every block after it is the previous one plus a fixed interval. On Base that interval is two seconds.

So the whole clock collapses into one line. Base genesis carries timestamp 1686789347, which is 15 June 2023 at 00:35:47 UTC. Block number n therefore carries:

timestamp(n) = 1686789347 + 2n

I sampled 200 random block numbers between block 1 and the head of the chain, plus blocks 0, 1 and 2 and the last few blocks before the head. Every single timestamp matched that formula exactly. Zero drift, zero exceptions, across more than 49 million blocks and three years of chain history.

And 1686789347 is odd. Add an even number to it as many times as you like and it stays odd. Every Base block timestamp that has ever existed is an odd Unix second. In the 200-block sample, the count of even timestamps was zero.

Why that erases half the clock

To get a second of the day out of a Unix timestamp you take it modulo 86,400. And 86,400 is even, so that operation preserves parity. An odd timestamp always maps to an odd second of the day.

1686789347 mod 86400 = 2147   → 00:35:47
1784149233 mod 86400 = 75633  → 21:00:33

Both odd, because they had no other option. The consequence is a strange little fact about the chain: of the 86,400 seconds in a day, only the 43,200 odd ones can ever carry a Base block. The other 43,200 cannot. Second 42,000 will never host one. Noon, second 43,200 exactly, will never host one either. On Base, midday is a gap.

The mint that recorded a second

Which makes the first mint here quietly funny. The transaction that created the first Buy One Second token sits in Base block 48679943, timestamped 1784149233, or 15 July 2026 at 21:00:33 UTC. Second of day: 75,633. Odd, like every other block.

The second that token actually claims is 333, which is 00:05:33 in the morning. The two numbers have nothing to do with each other, and this is a third axis on top of the two I wrote about in the second you pick is not the token you get. There is the second you own, the token id you were assigned, and now the second at which the chain happened to write the whole thing down. Three clocks, one mint, no relation between them.

If you claim second 42,000, no Base block will ever share your timestamp. Your second exists as a number in a contract's storage, permanently, on a chain whose own clock cannot land on it.

What about the 200 millisecond blocks?

Base builds Flashblocks every 200 milliseconds, which sounds like it should break the two-second lattice. It does not. Flashblocks are preconfirmations, partial orderings broadcast inside the window while the block is still being assembled. The L2 block that lands in the canonical chain still arrives every two seconds and still carries a timestamp from the same lattice. Base's own finality docs keep the two apart: roughly 200ms to Flashblock inclusion, roughly 2s to L2 block inclusion. Only the second one gets a block.timestamp.

Every chain has a grid, they just differ

This is not a Base quirk so much as a rollup being honest about what a timestamp is. Ethereum L1 does the same thing with a coarser mesh: post-merge slots are twelve seconds apart, so L1 timestamps sit on a twelve-second grid. The post-merge blocks I sampled all landed on the same residue modulo twelve. On that grid only 7,200 of the day's 86,400 seconds can carry an L1 block at all, and the other 79,200 never will.

Once you notice this, block timestamps stop looking like clocks and start looking like sequence numbers wearing a clock's clothing. They are not when something happened. They are which slot it was filed under.

Check it yourself

No wallet, no fee, no signature. Ask the public endpoint for any block and do the arithmetic:

curl -s https://mainnet.base.org \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getBlockByNumber",
       "params":["0x2e6cc07", false]}'

# take the hex timestamp, convert to decimal,
# subtract 1686789347, divide by 2 → the block number

If the division comes out clean, the lattice held. Try it with a block number from last year and one from an hour ago. Same answer both times.

The part I keep turning over

A collection of every second in a day, stored on a machine that can only speak on half of them. I did not design that and neither did anyone on Base. It fell out of two unrelated decisions: a day has 86,400 seconds, and a rollup ships a block every two seconds starting from an odd number nobody chose for its parity.

It changes nothing about the tokens. Second 42,000 is exactly as ownable, transferable and permanent as second 42,001, and the contract has no idea which of them the chain's own clock can reach. There is no trait for it, no rarity tier, no reason to want one over the other. It is just a coincidence sitting underneath the whole thing, and I would rather write it down than pretend the machine and the metaphor line up perfectly.

Usual cautions, since some of this involves a real chain. Minting is a transaction on Base with a network fee, and it cannot be undone once confirmed. Lost keys mean a lost token. Phishing sites copy real ones, so check the contract address against the About page before connecting a wallet. Reading is free and needs no wallet at all. None of this is financial advice, and a second is not an investment.

→ Whose midnight is second zero? · Second number versus token number · Read your second off Base