The mint button on the home page takes one second at a time. Pick a number, paste a link, confirm, done. But the contract behind it can do more than the button asks of it. Sitting in the ABI, right next to the ordinary mint call, is a second entry point: mintBatch. It takes a whole list of seconds and claims them together, in a single transaction on Base.
This is a primer on what that function says it does, read straight off the interface, and on where the honest limits sit. I am reading the signature, not guessing at prices or promising anything the code does not.
Here is what the ABI declares:
mintBatch(uint256[] _seconds, string[] _urls, address _referrer) payable
Compare it to the single version, mint(uint256 _second, string _url, address _referrer) payable, and the shape of the idea is obvious. Where the single call takes one second and one URL, the batch call takes an array of seconds and a matching array of URLs. The referrer is still a single address, so one batch carries one referral, not one per item. And it is payable, meaning it expects ETH to travel with the call, the same way a single mint does.
The pairing matters. Position by position, _seconds[0] gets _urls[0], _seconds[1] gets _urls[1], and so on. You are not attaching one link to a bundle of seconds. Each second still carries its own URL, its own editable pointer, its own token. The batch is a convenience for claiming them, not a merge that turns many seconds into one thing.
Every transaction on Base carries a fixed cost just for being a transaction, on top of whatever the work inside it costs. Fire off five separate mints and you pay that base overhead five times, and you sign five times, and you wait for five confirmations. Bundle the same five into one mintBatch and there is one transaction envelope, one signature, one confirmation to watch. The per-second work still happens five times inside the call, but the fixed wrapper is paid once.
There is a subtler property too: a batch is atomic. It either all goes through or none of it does. If one second in your list has already been taken by someone else between the moment you built the list and the moment your transaction lands, the whole call is expected to revert rather than quietly mint the available ones and drop the rest. That is the normal behavior of a batch mint that validates each item, and it is usually what you want. You do not end up half-holding a set you meant to grab whole.
Convenience is the whole pitch here, and it is worth being clear about what stays exactly the same. Each second you claim is still its own ERC-721 token. You still do not custody the ledger; Base does. The URL on each one is still editable later through updateUrl, and still just a string the contract stores without visiting or vouching for. Claiming ten seconds at once does not make any of them rarer, more valuable, or more "yours" than claiming them one by one on ten separate days. The only thing that changed is the number of times you paid the transaction overhead and hit confirm.
It also does not change the arithmetic of the set. There are 86,400 seconds, and a batch draws from the same fixed pool as a single mint. Grabbing a run of them, say a full minute of sixty consecutive seconds, is a claim on sixty slots, not a discount on the concept.
Because the batch carries a single _referrer address, a whole bundle credits one referrer, the same way a single mint does. If you arrived through someone's ?ref= link and claimed a handful of seconds together, that one address is what the mint records for the batch. Referral credit here is written into the mint itself rather than reconciled by a server afterward, and a batch does not change that; it just applies the one address across the items in the call. There is more on how that referral field behaves in the referrals primer linked below.
To be precise about what is live: the site's own mint button calls the single mint, one second per press. The mintBatch function is a capability of the contract, visible to anyone reading the ABI, not something the current interface drives for you. If you wanted to batch today, you would be calling the contract directly. I am flagging that gap rather than implying the button does something it does not, and if that ever changes on the site, it will change here too.
None of this is financial advice, and a second is not an investment. Batch or single, the caveats that always apply still apply: a real fee on Base, transactions that cannot be undone, keys that cannot be recovered if lost, and phishing links that imitate the real contract. Batching multiplies the stakes of a single confirm, so it is worth reading the list twice before you sign once.
→ How referrals work onchain · What happens when you mint a second · Read your second off Base
mintBatch(uint256[] _seconds, string[] _urls, address _referrer) payable alongside mint(uint256 _second, string _url, address _referrer) payable; batch reads use the parallel getBatchSecondData(uint256[]) view.mint(second, url, referrer, { value: parseEther(MINT_PRICE) }) with MINT_PRICE = '0.001' ETH on chain ID 8453 (Base mainnet); the front end does not currently drive mintBatch.