One validator proposes. The network agrees.
Execution keeps moving.
Follow a block from its proposer’s slot to its place in the chain. Helicon lets consensus and the EVM work concurrently, so agreeing on the next block can overlap with executing the last.
Explore the moving partsWatch the same block change color as it moves through the system. Select any block to inspect it, or step through at your own pace.
The schedule is stake-weighted and deterministic.
Built & broadcast
Agreed order · queued
EVM results available
Results committed later
Press play or step to follow a block.
Toy schedule, fictional validators, and compressed timings. Block spacing is 1s in this example; it is not a measurement or a current network setting. The 5s proposer window and 5s protocol execution-to-settlement delay are different mechanisms. Polling rounds are schematic. A slow executor scenario shows overlap, not unlimited queue growth.
ProposerVM wraps the C-Chain VM. For a height and slot, it samples one validator using the eligible set and weights at a referenced P-Chain height. Everyone can reproduce that selection. Greater weight means greater selection probability; the same validator can win successive slots or heights.
Read the v1.15.0 scheduler ↗Slots last five seconds and restart for the next height. A healthy first proposer can build much sooner. ACP-226 separately sets a dynamic minimum delay in milliseconds, influenced by validator preferences. That lower bound is not a guarantee of observed block spacing.
Read ACP-226 ↗Snowman uses repeated, stake-weighted sampling of peers to converge on a preferred chain and accept blocks. A proposer’s signature proves eligibility, not acceptance. The small network above compresses those repeated polls; it is not a single all-validator vote.
Read about Snowman ↗If a scheduled proposer fails to deliver, a later slot has its own sampled proposer. Since Durango, there is no ordinary timeout that opens building to everyone. Consecutive misses are possible. Timestamp gaps suggest elapsed slots; attributing them requires the historical schedule and more evidence.
Read about ProposerVM ↗Previously, validators executed a proposed block before accepting it. Continuous Execution puts accepted work into an ordered queue while a concurrent executor computes results.
Acceptance guarantees inclusion and eventual execution, not a successful contract call. A transaction can still revert. Its outcome becomes known on execution; later settlement records those results in consensus.
Checks still cover signatures, nonces and conservative affordability. A sender must cover the worst-case gas cost and value. Queue and block bounds constrain admitted work.
Accepted order is final under Snowman’s consensus guarantees. Execution computes effects. Settlement commits execution results in a later accepted block. If a node falls behind on execution needed to verify a settlement, it must catch up before judging that block.
Helicon integration notes ↗Real C-Chain observations, separate from the simulation. Refreshes every eight seconds while this tab is visible.
Loading public RPC observations…
ACP-194 defines latest as most recently executed and safe/finalized as most recently settled. pending may map to accepted or executed, depending on the implementation. This page does not use it to claim an acceptance lead.
Polling does not expose proposal broadcasts, consensus votes or the executor’s queue. Head distance is not execution latency. An EVM header’s miner address does not identify the ProposerVM signer. Unsupported fields or tags stay unavailable.
State-dependent calls may wait for execution. eth_getBlockReceipts refers to the transactions included in that block, even when their receipts are committed later. RPC semantics ↗
These changes address different bottlenecks: who proposes, how often blocks can arrive, and when transactions execute.
ProposerVM adds scheduled production around Snowman consensus. The original design had ordered eligibility windows and a later unsigned-block fallback.
Activation configuration ↗The deterministic per-slot schedule replaces expanding eligibility. The ordinary unsigned fallback is removed. A new height gets a new schedule.
Durango release ↗A validator-influenced minimum delay replaces the old block-gas-cost pacing mechanism. Millisecond timestamps make subsecond timing expressible without conflating it with five-second proposer windows.
Granite release ↗Mainnet activation at 15:00 UTC, with AvalancheGo v1.15.0. Continuous Execution separates accepted order from execution and later commitments. ACP-283 also makes the minimum gas price responsive to validator preferences.
Helicon release ↗ Watch the gas floor →Continuous execution enables specialized execution clients and is a prerequisite for some encrypted-mempool designs. These are opportunities discussed in ACP-194, not features activated by Helicon or a promised release schedule.
Design motivation ↗