ACP-226: Dynamic Minimum Block Times

[avalanche-foundation-admin]

Proposes replacing the current block production rate limiting mechanism on Avalanche EVM chains with a new mechanism where validators collectively and dynamically determine the minimum time between blocks.

https://github.com/avalanche-foundation/ACPs/blob/main/ACPs/226-dynamic-minimum-block-times/README.md

[meaghanfitzgerald]

@tactical-retreat raised a good question about the impact (or lack of) this mechanism would have during times of peak activity. His question essentially was:

If enforced pauses are happening all the time because demand is at or above the capacity refill rate, then doesn’t the theoretical minimum block time become irrelevant? Even if the protocol could make blocks faster, you’re still bottlenecked by the pause caused by gas refill.

In other words, does the gas-refill pause dominate the block timing under high demand?

[michaelkaplan13]

It's completely correct that the gas limit for a given block would still be limited by the available capacity (as governed by ACP-176).

With shorter block times, assuming the same target gas rate, you'd likely expected to see more frequent smaller blocks, rather than less frequent larger blocks. For example, with a capacity refill rate of 4.0M gas/second (i.e. target consumption of 2.0M gas/second), if the C-Chain switched from a 2 second target block time to a 1 second target block time, during periods of max utilization we'd expect to see blocks every second consuming 4.0M gas, rather than blocks every other second consuming 8.0M gas.

[tactical-retreat]

Well, no, because there's a minimum capacity that needs to be available before a block can be minted, right?

E.g. if there's a block that takes 20M gas, and the required minimum is 14M gas, then at 4M/s you have 3.5s until the next block could even be potentially minted.

If that block now consumes 14M gas, you've got another 3.5s until the next block, etc etc.

But that scenario shouldn't last long gas prices will ramp up right. But I still see a scenario where the capacity is near the minimum and then ongoing blocks are consuming the refill rate. You'd still have about 1 block per second in that case.

[meaghanfitzgerald]

I believe you're both right, just describing what happens under different loads/circumstances.

As I understand both mechanisms, if the minimum capacity needed for a block is lower than what gets refilled each target interval, then shorter block times just mean you’ll see more, smaller blocks. But if the minimum is higher than what refills in one interval (or if big blocks keep draining it below the threshold), then the refill delay takes over and you’ll be stuck waiting; so in that case the pause dominates.

[meaghanfitzgerald]

But I think what tactical is pointing out lines up with the note in ACP-176: block producers wait until there’s enough refill to fit a large tx, not just whatever has accumulated since the last block. So in those moments the refill pause can stretch block times beyond the target, even if the protocol could otherwise make blocks faster.

Is this correct? @StephenButtolph

[StephenButtolph]

If the chain is eating into the reserved capacity, then the chain may produce blocks less frequently.

If the chain isn't eating too much into the reserved capacity, then this ACP allows the chain to produce blocks at a faster rate.

Looking at the Mainnet C-chain metrics, it seems that the chain normally has > 15m gas capacity. With spikes of capacity getting consumed:

last 30m:

This ACP would allow faster block production (lower latency) when the capacity is > 15m capacity.

[michaelkaplan13]

Oh gotcha. There's actually no protocol-level minimum capacity that is required to he available prior to a block being proposed/accepted other than that block can only consume up to the availability capacity at the time it is produced. The note in ACP-176 suggests that block builders choose to wait to produce a block if there isn't a certain available capacity to allow for large transactions to be included, but that is optional and not enforced by the protocol. Generally speaking, the minimum block delay doesn't ensure that blocks will be produced at that frequency since block builders may be offline or choose to wait.

…

On Thu, Aug 21, 2025, 3:20 PM Meaghan FitzGerald ***@***.***> wrote: But I think what tactical is pointing out lines up with the note in ACP-176 <https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/176-dynamic-evm-gas-limit-and-price-discovery-updates#backwards-compatibility>: block producers wait until there’s enough refill to fit a large tx, not just whatever has accumulated since the last block. So in those moments the refill pause can stretch block times beyond the target, even if the protocol could otherwise make blocks faster. Is this correct? @StephenButtolph <https://github.com/StephenButtolph> — Reply to this email directly, view it on GitHub <#228 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANFFUVDU547KUVDCDZH5FA33OYLWDAVCNFSM6AAAAACDXGKUBSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJYGIZTKNI> . You are receiving this because you commented.Message ID: ***@***.*** com>

[michaelkaplan13]

Practically speaking though, you're completely right that if a block builder waits for a certain capacity level, that would slow the rate of block production regardless of how quickly they are allowed to be produced.

…

On Thu, Aug 21, 2025, 3:20 PM Meaghan FitzGerald ***@***.***> wrote: But I think what tactical is pointing out lines up with the note in ACP-176 <https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/176-dynamic-evm-gas-limit-and-price-discovery-updates#backwards-compatibility>: block producers wait until there’s enough refill to fit a large tx, not just whatever has accumulated since the last block. So in those moments the refill pause can stretch block times beyond the target, even if the protocol could otherwise make blocks faster. Is this correct? @StephenButtolph <https://github.com/StephenButtolph> — Reply to this email directly, view it on GitHub <#228 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANFFUVDU547KUVDCDZH5FA33OYLWDAVCNFSM6AAAAACDXGKUBSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMJYGIZTKNI> . You are receiving this because you commented.Message ID: ***@***.*** com>

[meaghanfitzgerald]

🔊 ACP-226 Developer Community Call

Meeting Date/Time: 08-28-2025, 14:30 UTC (10:30 AM ET)
Meeting Duration: 1 hour
Presenters: @ceyonur, @michaelkaplan13

Purpose of the Meeting

In this meeting, we will discuss ACP-226: Dynamic Minimum Block Times, which proposes replacing the current block production rate limiting mechanism on Avalanche EVM chains with a new system where validators dynamically determine the minimum time between blocks.

This change introduces millisecond-level precision for block timing, enables sub-second block times in the future, and improves flexibility by allowing block delays to adapt dynamically—without requiring network upgrades.

Who is invited?

Any protocol developer, ACP author, researcher, validator, or Avalanche community member is welcome to attend this meeting.
If you have signed up for an ACP call in the past, there is no need to fill out the form again.

Links

Sign Up Form: Google Form
Recording: Will be posted to YouTube after the call

Preparation Material

Mandatory

ACP-226 Discussion

Suggested Reading

ACP-176: Dynamic Gas Target
ACP-194: Asynchronous Execution

Agenda

This call will cover the rationale, technical design, and planned implementation of ACP-226, including how the new dynamic minimum block delay works, what changes are needed in block headers, and its implications for network performance.
There will be time reserved for community questions and discussion.

FAQs

Q: How does ACP-226 differ from the current “block gas cost” mechanism?
A: Currently, validators can produce blocks faster than the target by burning extra fees. ACP-226 replaces this with an explicit, enforced minimum block delay, ensuring stable block production while still allowing dynamic adjustment over time.

Q: What new data is added to block headers?
A: Two fields:

timeMilliseconds → allows millisecond-level precision for block timestamps.
minimumBlockDelay → specifies the enforced minimum delay before the next block can be accepted.

Q: Why is millisecond precision important?
A: As Avalanche improves performance, sub-second block times become feasible. Millisecond granularity ensures more accurate timing control while maintaining backward compatibility for tools that only use second-level timestamps.

Q: How do validators influence block timing?
A: Validators set preferences for their desired block delay. The network dynamically adjusts according to these preferences, similar to how ACP-176 manages gas targets.

Q: Will this change affect transaction fees?
A: Priority fees remain relevant for transaction inclusion, but the removal of the block gas cost mechanism means users only need to set non-zero priority fees when blocks are full.

👉 Sign up to join the call here: Google Form

[jeffreydunaway]

Cool. I'm looking forward to this discussion tomorrow.