Discussion on what the block timestamp should be as we move to a world where we produce multiple blocks per slot.
Where we are today
Every block has an associated timestamp. Today (Dec 2025), the Ignition network produces one block per slot (a 72s span), which gets checkpointed to L1 within that slot. The timestamp of the block is defined as the start of its slot. So we get predictable timestamps at 72s intervals, regardless of when the block is actually produced or mined.
Entering multiple blocks per slot
Now, we’re working towards building multiple blocks per slot. In this new model, we still partition time into 72s slots, and elect a single the proposer for a given slot. However, each proposer can emit multiple consecutive blocks within their slot, and checkpoints them all together to L1 in a single batch tx. This reduces latency for users, who can get a faster (albeit softer) finality for their txs as they get included in these “intermediate" blocks, without having to wait until their tx gets included in an Aztec block that reaches L1.
But this new model begs a question: since we’re decoupling L2 block production from its checkpointing to L1, as several blocks can be produced before they reach L1, how we define the timestamps for those blocks?
Option 1: Constant Timestamps
The easiest option is to keep the same approach: the block timestamp is the timestamp of its slot. And if there are multiple blocks within a slot, then they all have the same timestamp. The main benefit here is that we have predictable timestamps: given a block in a slot, we can derive its timestamp in advance. The downside is that “time” will advance at long discrete 72s intervals, as opposed to increase steadily with new blocks, which would mean that applications that rely on the passing of time will be “slower” to react.
Option 2: Fixed Increasing Timestamps
While block times are not enforced by the protocol (a proposer can churn out as many blocks per slot as they can get attested, as long as they fit within the global gas limits), we can define an arbitrary block time just for timestamps. So the first block within a slot has the slot initial timestamp, and then every block increases that value by (let’s say) 4s, enforced by the rollup circuits.
While this gives us predictable timestamps, it also means that we’ll have odd time “jumps” when we switch from one slot to the next if the previous slot was not “filled” with blocks, which will often be the case. It also means we’re setting an arbitrary hard limit for the number of blocks within a slot.
Option 3: Proposer Chooses
The alternative is to let the block proposer choose whatever increasing timestamps (all within the 72s slot) they want to set for their blocks. This gives us faster increasing timestamps as blocks progress, but at a cost: timestamps can now be manipulated by proposers (again, within a range). And we know from pre-eth2.0 times that that’s not a good a thing for smart contract developers, who really enjoy predictability.
Option 4: Attestor Bounded Timestamps
A slightly stricter version of the above is having attestors verify that the timestamps produced by the proposer are “reasonable”, where reasonable could mean a drift wrt their wall time. The issue is defining the drift: too strict, and p2p congestion would mean rejected proposals, and too lenient, and we’re back to option 3. And we still don’t have predictable timestamps.
Furthermore, with the introduction of Escape Hatches, a proposer does not need attestations to get their block on chain, which means that smart contract developers should still account for major timestamp manipulation in edge cases.
The Request for Comments
Given the options above, we’re strongly leaning towards option 1 due to its simplicity and its focus on security for smart contract developers. However, we’re aware that we may be damaging the user experience of some apps that rely on time if we keep it frozen for 72s intervals. So the question is: are there any apps or patterns you think that require time to advance frequently and on every block produced?
Disclaimer
The information set out herein is for discussion purposes only and does not represent any binding indication or commitment by Aztec Labs and its employees to take any action whatsoever, including relating to the structure and/or any potential operation of the Aztec protocol or the protocol roadmap. In particular: (i) nothing in these posts is intended to create any contractual or other form of legal relationship with Aztec Labs or third parties who engage with such posts (including, without limitation, by submitting a proposal or responding to posts), (ii) by engaging with any post, the relevant persons are consenting to Aztec Labs’ use and publication of such engagement and related information on an open-source basis (and agree that Aztec Labs will not treat such engagement and related information as confidential), and (iii) Aztec Labs is not under any duty to consider any or all engagements, and that consideration of such engagements and any decision to award grants or other rewards for any such engagement is entirely at Aztec Labs’ sole discretion. Please do not rely on any information on this forum for any purpose - the development, release, and timing of any products, features or functionality remains subject to change and is currently entirely hypothetical. Nothing on this forum should be treated as an offer to sell any security or any other asset by Aztec Labs or its affiliates, and you should not rely on any forum posts or content for advice of any kind, including legal, investment, financial, tax or other professional advice.
