From 4c1703f369045cf43414339644174ffdcebd3a73 Mon Sep 17 00:00:00 2001 From: Stephen Buttolph Date: Tue, 5 May 2026 11:40:57 -0400 Subject: [PATCH 01/11] sae: Add README.md to describe C-Chain wrapper design --- vms/saevm/cchain/README.md | 155 +++++++++++++++++++++++++++++++++++++ 1 file changed, 155 insertions(+) create mode 100644 vms/saevm/cchain/README.md diff --git a/vms/saevm/cchain/README.md b/vms/saevm/cchain/README.md new file mode 100644 index 000000000000..7c28cb91418f --- /dev/null +++ b/vms/saevm/cchain/README.md @@ -0,0 +1,155 @@ +# C-Chain VM (`cchain`) + +`cchain` is the C-Chain VM. It is a thin chain-specific harness around [saevm](../), the generic EVM framework that implements [ACP-194](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/194-streaming-asynchronous-execution). `saevm` does the heavy lifting — block execution, settlement, gas accounting, and EVM gossip. `cchain` adds what makes the chain *the C-Chain*: transactions for moving assets between Primary Network chains, Warp messaging, and validator-voted chain parameters. + +## Architecture + +The C-Chain is composed of three major components: + +1. **AvalancheGo** — networking, consensus, validator-set management, and the external API surface. +2. **SAE** — the generic, Turing-complete EVM implementation. +3. **C-Chain** (this package) — the wrapper that adds C-Chain-specific behavior. + +```mermaid +flowchart TB + subgraph avago["AvalancheGo"] + direction LR + consensus["Consensus"] + network["Network"] + apiserver["API Server"] + end + + subgraph sae["SAE"] + direction LR + execution["Execution"] + p2pn["P2P Network"] + rpc["/rpc"] + ws["/ws"] + end + + subgraph cchain["C-Chain"] + direction LR + hook["Hooks"] + warp["Warp"] + db[("Database")] + txpool[("Txpool")] + avax["/avax"] + end + + network <--> consensus + network --> p2pn + consensus --> execution + apiserver --> rpc + apiserver --> ws + apiserver --> avax + execution --> hook + + hook --> warp + p2pn --> warp + + hook --> txpool + p2pn --> txpool + avax --> txpool + + hook --> db + warp --> db + txpool --> db +``` + +Hooks are the seam through which SAE calls into C-Chain–specific code. SAE invokes them at the relevant points of a block's lifecycle: + +- **Build** — construct custom header fields and embed cross-chain transactions into the block body. +- **Verify** — enforce validation rules on header fields, embedded transactions, and Warp predicates. +- **Execute** — apply cross-chain transaction state effects. + +## What `cchain` adds + +`cchain` extends the standard Ethereum block format. The block header gains the following extra fields: + +- `blockGasCost` — legacy block-level required priority fee. +- `extDataGasUsed` — legacy gas used by cross-chain transactions. +- `extDataHash` — keccak256 of the block's cross-chain transaction data. +- `gasTargetExcess` — ACP-176 gas-target vote tracker. +- `minDelayExcess` — ACP-226 minimum-delay vote tracker. +- `minimumPriceExcess` — ACP-283 minimum-gas-price vote tracker. +- `timestampMilliseconds` — millisecond-precise timestamp. + +The block body adds one extra field: + +- `blockExtraData` — encoded cross-chain transactions; their semantics are described under [Cross-chain transactions](#cross-chain-transactions) below. + +The standard `extraData` field carries Warp predicate verification results — see [Warp messaging](#warp-messaging). + +### Cross-chain transactions + +The Primary Network is the set of three chains — P, X, and C — that exchange assets through pair-wise shared stores. Each pair of chains has its own store, readable and writable by both chains in the pair. + +```mermaid +flowchart TB + P((P-Chain)) + X((X-Chain)) + C((C-Chain)) + + PX[("PX")] + CP[("CP")] + CX[("CX")] + + P --> PX + X --> PX + P --> CP + C --> CP + X --> CX + C --> CX +``` + +A cross-chain transfer happens in two steps. An **Export** transaction on the source chain burns the asset and writes a UTXO into the shared store between the source and destination chains. The UTXO specifies who is allowed to consume it. An **Import** transaction, issued by that party on the destination chain, consumes the UTXO and credits funds to addresses of the Import issuer's choice. + +`cchain` defines both transaction types, their validation rules, and runs a dedicated mempool that gossips them in a bandwidth-optimized way using bloom filters. + +#### How transactions enter the Txpool + +Cross-chain transactions reach the mempool from four independent sources. Each transaction passes the same checks — signature, state validity, and conflict resolution — before being added. + +```mermaid +flowchart LR + rpc["/avax"] + pushgossip["push-gossiper"] + push["Inbound push gossip"] + pull["Inbound pull gossip"] + rej["Block rejection"] + mempool[("Mempool")] + + rpc --> pushgossip + rpc --> mempool + push --> mempool + pull --> mempool + rej --> mempool +``` + +The four entry paths in detail: + +User RPC submission is the only path that registers transactions with the local push-gossiper for proactive propagation; the other three sources reach the mempool without enqueuing for outbound gossip. + +- **User RPC submission.** The `/avax` JSON-RPC endpoint receives a transaction and forwards it to the mempool, also enqueuing it on the push-gossiper. +- **Inbound push gossip.** A peer pushes a transaction over the transaction gossip protocol; the transaction is routed to the same add path. +- **Inbound pull gossip.** Periodically, `cchain` sends a bloom filter representing the current state of the mempool to a peer. The peer returns transactions not referenced in the bloom filter; those transactions are forwarded to the same add path. +- **Block rejection.** When the consensus engine rejects a block this node had previously verified, `cchain` extracts the transactions from the block and submits each to the mempool. The point is to keep otherwise-valid transactions from being dropped by an unlucky conflict. + +### Warp messaging + +The C-Chain participates in cross-subnet Warp messaging on both sides — sending messages to other chains and receiving messages from them. Four pieces are involved: + +- A custom precompile that lets EVM contracts emit and consume Warp messages. +- Incoming Warp messages encoded into the access-list, so the hook implementation can verify them prior to EVM execution. +- Predicate verification results encoded into the block header's `extraData`, so a bootstrapping node doesn't need to re-verify historical Warp messages. +- The [ACP-118](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/118) p2p protocol for collecting BLS signatures from peer validators on outbound messages. + +`cchain` persists this chain's Warp messages, serves signature requests against that store, and verifies Warp predicates during block verification. + +### Validator-voted parameters + +Three chain parameters are settled by validator vote on each block. The block builder casts the vote: when building a block they can move each parameter toward their ideal value. Because block production is stake-weighted, this yields a stake-weighted voting mechanism over the long run. + +- **Gas target per second** ([ACP-176](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/176)) — the throughput target. The rest of ACP-176 (gas accounting and excess tracker) lives in SAE; `cchain` contributes only the target value. +- **Minimum block delay** ([ACP-226](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/226)) — a lower bound on the time between consecutive blocks. Prevents block production faster than the network can maintain. +- **Minimum gas price** ([ACP-283](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/283)) — a floor on the gas price for transactions to be included in a block. From c7887012398011ae7ea335887e6e2edc33fbad38 Mon Sep 17 00:00:00 2001 From: Stephen Buttolph Date: Tue, 5 May 2026 11:55:18 -0400 Subject: [PATCH 02/11] fix links --- vms/saevm/cchain/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/vms/saevm/cchain/README.md b/vms/saevm/cchain/README.md index 7c28cb91418f..4533148c16ac 100644 --- a/vms/saevm/cchain/README.md +++ b/vms/saevm/cchain/README.md @@ -142,7 +142,7 @@ The C-Chain participates in cross-subnet Warp messaging on both sides — sendin - A custom precompile that lets EVM contracts emit and consume Warp messages. - Incoming Warp messages encoded into the access-list, so the hook implementation can verify them prior to EVM execution. - Predicate verification results encoded into the block header's `extraData`, so a bootstrapping node doesn't need to re-verify historical Warp messages. -- The [ACP-118](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/118) p2p protocol for collecting BLS signatures from peer validators on outbound messages. +- The [ACP-118](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/118-warp-signature-request) p2p protocol for collecting BLS signatures from peer validators on outbound messages. `cchain` persists this chain's Warp messages, serves signature requests against that store, and verifies Warp predicates during block verification. @@ -150,6 +150,6 @@ The C-Chain participates in cross-subnet Warp messaging on both sides — sendin Three chain parameters are settled by validator vote on each block. The block builder casts the vote: when building a block they can move each parameter toward their ideal value. Because block production is stake-weighted, this yields a stake-weighted voting mechanism over the long run. -- **Gas target per second** ([ACP-176](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/176)) — the throughput target. The rest of ACP-176 (gas accounting and excess tracker) lives in SAE; `cchain` contributes only the target value. -- **Minimum block delay** ([ACP-226](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/226)) — a lower bound on the time between consecutive blocks. Prevents block production faster than the network can maintain. -- **Minimum gas price** ([ACP-283](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/283)) — a floor on the gas price for transactions to be included in a block. +- **Gas target per second** ([ACP-176](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/176-dynamic-evm-gas-limit-and-price-discovery-updates)) — the throughput target. The rest of ACP-176 (gas accounting and excess tracker) lives in SAE; `cchain` contributes only the target value. +- **Minimum block delay** ([ACP-226](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/226-dynamic-minimum-block-times)) — a lower bound on the time between consecutive blocks. Prevents block production faster than the network can maintain. +- **Minimum gas price** ([ACP-283](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/283-dynamic-minimum-gas-price)) — a floor on the gas price for transactions to be included in a block. From be06994e95da0eaa6f6540ad17fa2660069022a9 Mon Sep 17 00:00:00 2001 From: Stephen Buttolph Date: Tue, 5 May 2026 12:05:02 -0400 Subject: [PATCH 03/11] call it a mempool, rather than a txpool --- vms/saevm/cchain/README.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/vms/saevm/cchain/README.md b/vms/saevm/cchain/README.md index 4533148c16ac..9d1d381882a7 100644 --- a/vms/saevm/cchain/README.md +++ b/vms/saevm/cchain/README.md @@ -32,7 +32,7 @@ flowchart TB hook["Hooks"] warp["Warp"] db[("Database")] - txpool[("Txpool")] + mempool[("Mempool")] avax["/avax"] end @@ -47,13 +47,13 @@ flowchart TB hook --> warp p2pn --> warp - hook --> txpool - p2pn --> txpool - avax --> txpool + hook --> mempool + p2pn --> mempool + avax --> mempool hook --> db warp --> db - txpool --> db + mempool --> db ``` Hooks are the seam through which SAE calls into C-Chain–specific code. SAE invokes them at the relevant points of a block's lifecycle: @@ -106,7 +106,7 @@ A cross-chain transfer happens in two steps. An **Export** transaction on the so `cchain` defines both transaction types, their validation rules, and runs a dedicated mempool that gossips them in a bandwidth-optimized way using bloom filters. -#### How transactions enter the Txpool +#### How transactions enter the mempool Cross-chain transactions reach the mempool from four independent sources. Each transaction passes the same checks — signature, state validity, and conflict resolution — before being added. From 8135e76298b7f25c1599fd7f8debd1cd264ff2b0 Mon Sep 17 00:00:00 2001 From: Stephen Buttolph Date: Tue, 5 May 2026 12:13:23 -0400 Subject: [PATCH 04/11] nit cleanup diagram --- vms/saevm/cchain/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vms/saevm/cchain/README.md b/vms/saevm/cchain/README.md index 9d1d381882a7..33538b59cfac 100644 --- a/vms/saevm/cchain/README.md +++ b/vms/saevm/cchain/README.md @@ -113,7 +113,7 @@ Cross-chain transactions reach the mempool from four independent sources. Each t ```mermaid flowchart LR rpc["/avax"] - pushgossip["push-gossiper"] + pushgossip["Push gossiper"] push["Inbound push gossip"] pull["Inbound pull gossip"] rej["Block rejection"] From b1a577aa549f05712ef50fcbed3579b04bfbee36 Mon Sep 17 00:00:00 2001 From: Stephen Buttolph Date: Tue, 5 May 2026 12:14:11 -0400 Subject: [PATCH 05/11] nit --- vms/saevm/cchain/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vms/saevm/cchain/README.md b/vms/saevm/cchain/README.md index 33538b59cfac..0b7db0f480c8 100644 --- a/vms/saevm/cchain/README.md +++ b/vms/saevm/cchain/README.md @@ -113,7 +113,7 @@ Cross-chain transactions reach the mempool from four independent sources. Each t ```mermaid flowchart LR rpc["/avax"] - pushgossip["Push gossiper"] + pushgossip["Output push gossiper"] push["Inbound push gossip"] pull["Inbound pull gossip"] rej["Block rejection"] From d5691bff6eec7d2b4319ffee558287a9e89d2c6f Mon Sep 17 00:00:00 2001 From: Stephen Buttolph Date: Tue, 5 May 2026 12:14:26 -0400 Subject: [PATCH 06/11] nit --- vms/saevm/cchain/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vms/saevm/cchain/README.md b/vms/saevm/cchain/README.md index 0b7db0f480c8..f82f548ffa29 100644 --- a/vms/saevm/cchain/README.md +++ b/vms/saevm/cchain/README.md @@ -113,7 +113,7 @@ Cross-chain transactions reach the mempool from four independent sources. Each t ```mermaid flowchart LR rpc["/avax"] - pushgossip["Output push gossiper"] + pushgossip["Outbound push gossiper"] push["Inbound push gossip"] pull["Inbound pull gossip"] rej["Block rejection"] From dfbd92516781586eda26c077625b0445ae34d703 Mon Sep 17 00:00:00 2001 From: Stephen Buttolph Date: Tue, 5 May 2026 12:16:07 -0400 Subject: [PATCH 07/11] nit --- vms/saevm/cchain/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vms/saevm/cchain/README.md b/vms/saevm/cchain/README.md index f82f548ffa29..36aa453a7f7a 100644 --- a/vms/saevm/cchain/README.md +++ b/vms/saevm/cchain/README.md @@ -140,7 +140,7 @@ User RPC submission is the only path that registers transactions with the local The C-Chain participates in cross-subnet Warp messaging on both sides — sending messages to other chains and receiving messages from them. Four pieces are involved: - A custom precompile that lets EVM contracts emit and consume Warp messages. -- Incoming Warp messages encoded into the access-list, so the hook implementation can verify them prior to EVM execution. +- Incoming Warp messages encoded in the access-list, so the hook implementation can verify them prior to EVM execution. - Predicate verification results encoded into the block header's `extraData`, so a bootstrapping node doesn't need to re-verify historical Warp messages. - The [ACP-118](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/118-warp-signature-request) p2p protocol for collecting BLS signatures from peer validators on outbound messages. From 4629c1bc21a7c54fd8b123b10176f90700895c50 Mon Sep 17 00:00:00 2001 From: Stephen Buttolph Date: Tue, 5 May 2026 13:09:20 -0400 Subject: [PATCH 08/11] technically not even turing complete yo --- vms/saevm/cchain/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/vms/saevm/cchain/README.md b/vms/saevm/cchain/README.md index 36aa453a7f7a..93a7ee8aebec 100644 --- a/vms/saevm/cchain/README.md +++ b/vms/saevm/cchain/README.md @@ -7,7 +7,7 @@ The C-Chain is composed of three major components: 1. **AvalancheGo** — networking, consensus, validator-set management, and the external API surface. -2. **SAE** — the generic, Turing-complete EVM implementation. +2. **SAE** — the generic EVM implementation. 3. **C-Chain** (this package) — the wrapper that adds C-Chain-specific behavior. ```mermaid From 3c9a043d5e4863f3b6195cc828f2b8160738075c Mon Sep 17 00:00:00 2001 From: Stephen Buttolph Date: Tue, 5 May 2026 13:32:48 -0400 Subject: [PATCH 09/11] feedback --- vms/saevm/cchain/README.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/vms/saevm/cchain/README.md b/vms/saevm/cchain/README.md index 93a7ee8aebec..70841e987a46 100644 --- a/vms/saevm/cchain/README.md +++ b/vms/saevm/cchain/README.md @@ -90,9 +90,9 @@ flowchart TB X((X-Chain)) C((C-Chain)) - PX[("PX")] - CP[("CP")] - CX[("CX")] + PX[("P&X Database")] + CP[("C&P Database")] + CX[("C&X Database")] P --> PX X --> PX @@ -128,9 +128,7 @@ flowchart LR The four entry paths in detail: -User RPC submission is the only path that registers transactions with the local push-gossiper for proactive propagation; the other three sources reach the mempool without enqueuing for outbound gossip. - -- **User RPC submission.** The `/avax` JSON-RPC endpoint receives a transaction and forwards it to the mempool, also enqueuing it on the push-gossiper. +- **User RPC submission.** The `/avax` JSON-RPC endpoint receives a transaction and forwards it to the mempool, also enqueuing it on the push-gossiper. This is the only path that registers transactions with the push-gossiper. - **Inbound push gossip.** A peer pushes a transaction over the transaction gossip protocol; the transaction is routed to the same add path. - **Inbound pull gossip.** Periodically, `cchain` sends a bloom filter representing the current state of the mempool to a peer. The peer returns transactions not referenced in the bloom filter; those transactions are forwarded to the same add path. - **Block rejection.** When the consensus engine rejects a block this node had previously verified, `cchain` extracts the transactions from the block and submits each to the mempool. The point is to keep otherwise-valid transactions from being dropped by an unlucky conflict. From 3697ea949d15ffcdfefeb8d80a792b7bc9b86f1d Mon Sep 17 00:00:00 2001 From: Stephen Buttolph Date: Tue, 5 May 2026 13:41:38 -0400 Subject: [PATCH 10/11] link to other readmes --- vms/saevm/cchain/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/vms/saevm/cchain/README.md b/vms/saevm/cchain/README.md index 70841e987a46..a84974006357 100644 --- a/vms/saevm/cchain/README.md +++ b/vms/saevm/cchain/README.md @@ -6,7 +6,7 @@ The C-Chain is composed of three major components: -1. **AvalancheGo** — networking, consensus, validator-set management, and the external API surface. +1. **AvalancheGo** — [networking](../../../network), [consensus](../../../snow), validator-set management, and the external API surface. 2. **SAE** — the generic EVM implementation. 3. **C-Chain** (this package) — the wrapper that adds C-Chain-specific behavior. @@ -82,7 +82,7 @@ The standard `extraData` field carries Warp predicate verification results — s ### Cross-chain transactions -The Primary Network is the set of three chains — P, X, and C — that exchange assets through pair-wise shared stores. Each pair of chains has its own store, readable and writable by both chains in the pair. +The Primary Network is the set of three chains — P, X, and C — that exchange assets through pair-wise [shared stores](../../../chains/atomic). Each pair of chains has its own store, readable and writable by both chains in the pair. ```mermaid flowchart TB @@ -135,11 +135,11 @@ The four entry paths in detail: ### Warp messaging -The C-Chain participates in cross-subnet Warp messaging on both sides — sending messages to other chains and receiving messages from them. Four pieces are involved: +The C-Chain participates in cross-subnet [Warp messaging](../../platformvm/warp) on both sides — sending messages to other chains and receiving messages from them. Four pieces are involved: - A custom precompile that lets EVM contracts emit and consume Warp messages. - Incoming Warp messages encoded in the access-list, so the hook implementation can verify them prior to EVM execution. -- Predicate verification results encoded into the block header's `extraData`, so a bootstrapping node doesn't need to re-verify historical Warp messages. +- [Predicate verification](../../evm/predicate) results encoded into the block header's `extraData`, so a bootstrapping node doesn't need to re-verify historical Warp messages. - The [ACP-118](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/118-warp-signature-request) p2p protocol for collecting BLS signatures from peer validators on outbound messages. `cchain` persists this chain's Warp messages, serves signature requests against that store, and verifies Warp predicates during block verification. From aae29d3e5baacec85dbccf00ab0a8a5b5b5651a7 Mon Sep 17 00:00:00 2001 From: Stephen Buttolph Date: Fri, 8 May 2026 09:33:58 -0400 Subject: [PATCH 11/11] nits --- vms/saevm/cchain/README.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/vms/saevm/cchain/README.md b/vms/saevm/cchain/README.md index a84974006357..602890a51093 100644 --- a/vms/saevm/cchain/README.md +++ b/vms/saevm/cchain/README.md @@ -64,10 +64,12 @@ Hooks are the seam through which SAE calls into C-Chain–specific code. SAE inv ## What `cchain` adds +### Block format extensions + `cchain` extends the standard Ethereum block format. The block header gains the following extra fields: -- `blockGasCost` — legacy block-level required priority fee. -- `extDataGasUsed` — legacy gas used by cross-chain transactions. +- `blockGasCost` — block-level required priority fee - no longer used, but can't be removed. +- `extDataGasUsed` — gas used by cross-chain transactions - no longer used, but can't be removed. - `extDataHash` — keccak256 of the block's cross-chain transaction data. - `gasTargetExcess` — ACP-176 gas-target vote tracker. - `minDelayExcess` — ACP-226 minimum-delay vote tracker. @@ -82,7 +84,7 @@ The standard `extraData` field carries Warp predicate verification results — s ### Cross-chain transactions -The Primary Network is the set of three chains — P, X, and C — that exchange assets through pair-wise [shared stores](../../../chains/atomic). Each pair of chains has its own store, readable and writable by both chains in the pair. +The Primary Network is the set of three chains — P, X, and C — that exchange assets through pair-wise [shared databases](../../../chains/atomic). Each pair of chains has its own database, readable and writable by both chains in the pair. ```mermaid flowchart TB @@ -115,7 +117,7 @@ flowchart LR rpc["/avax"] pushgossip["Outbound push gossiper"] push["Inbound push gossip"] - pull["Inbound pull gossip"] + pull["Pull gossip responses"] rej["Block rejection"] mempool[("Mempool")] @@ -130,7 +132,7 @@ The four entry paths in detail: - **User RPC submission.** The `/avax` JSON-RPC endpoint receives a transaction and forwards it to the mempool, also enqueuing it on the push-gossiper. This is the only path that registers transactions with the push-gossiper. - **Inbound push gossip.** A peer pushes a transaction over the transaction gossip protocol; the transaction is routed to the same add path. -- **Inbound pull gossip.** Periodically, `cchain` sends a bloom filter representing the current state of the mempool to a peer. The peer returns transactions not referenced in the bloom filter; those transactions are forwarded to the same add path. +- **Pull gossip responses.** Periodically, `cchain` sends a bloom filter representing the current state of the mempool to a peer. The peer returns transactions not referenced in the bloom filter; those transactions are forwarded to the same add path. - **Block rejection.** When the consensus engine rejects a block this node had previously verified, `cchain` extracts the transactions from the block and submits each to the mempool. The point is to keep otherwise-valid transactions from being dropped by an unlucky conflict. ### Warp messaging @@ -138,7 +140,7 @@ The four entry paths in detail: The C-Chain participates in cross-subnet [Warp messaging](../../platformvm/warp) on both sides — sending messages to other chains and receiving messages from them. Four pieces are involved: - A custom precompile that lets EVM contracts emit and consume Warp messages. -- Incoming Warp messages encoded in the access-list, so the hook implementation can verify them prior to EVM execution. +- Incoming Warp messages encoded in the access list, so the hook implementation can verify them prior to EVM execution. - [Predicate verification](../../evm/predicate) results encoded into the block header's `extraData`, so a bootstrapping node doesn't need to re-verify historical Warp messages. - The [ACP-118](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/118-warp-signature-request) p2p protocol for collecting BLS signatures from peer validators on outbound messages. @@ -146,7 +148,7 @@ The C-Chain participates in cross-subnet [Warp messaging](../../platformvm/warp) ### Validator-voted parameters -Three chain parameters are settled by validator vote on each block. The block builder casts the vote: when building a block they can move each parameter toward their ideal value. Because block production is stake-weighted, this yields a stake-weighted voting mechanism over the long run. +Three chain parameters are settled by validator vote on each block. The block builder casts the vote: when building a block they can move each parameter toward their configured value. Because block production is stake-weighted, this yields a stake-weighted voting mechanism over the long run. - **Gas target per second** ([ACP-176](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/176-dynamic-evm-gas-limit-and-price-discovery-updates)) — the throughput target. The rest of ACP-176 (gas accounting and excess tracker) lives in SAE; `cchain` contributes only the target value. - **Minimum block delay** ([ACP-226](https://github.com/avalanche-foundation/ACPs/tree/main/ACPs/226-dynamic-minimum-block-times)) — a lower bound on the time between consecutive blocks. Prevents block production faster than the network can maintain.