Forking Celo mainnet, anvil cannot decode receipts for CIP-64 fee-currency transactions (EIP-2718 type 0x7b). eth_getTransactionReceipt fails for those transactions, and because most Celo blocks contain at least one, eth_getBlockReceipts fails for nearly every block.
Repro
anvil --fork-url https://forno.celo.org
Pick a "type":"0x7b" transaction from a recent block, then:
cast rpc eth_getTransactionReceipt 0xf95d809f9c2fb47a56aaf517c23b6bf09b98c85b55273f5cec73555b32a85b2b --rpc-url http://127.0.0.1:8545
Both that call and eth_getBlockReceipts for the containing block return:
-32602 Failed to decode receipt
The upstream endpoint serves the receipt fine ({"type":"0x7b","status":"0x1"}), so this is purely anvil's decoding.
Per-type results against a forked Celo head block:
| tx type |
receipt |
0x0, 0x2 |
ok |
0x7e (OP-stack deposit) |
ok |
0x7b (CIP-64) |
Failed to decode receipt |
eth_getBlockReceipts |
fails whenever the block holds a 0x7b |
Cause
FoundryReceiptEnvelope in crates/primitives/src/transaction/receipt.rs has variants for the standard types plus optimism 0x7d/0x7e and tempo 0x76, but none for 0x7b. TryFrom<AnyTransactionReceipt> for FoundryTxReceipt in crates/primitives/src/network/receipt.rs therefore rejects it, and ClientFork::transaction_receipt / ClientFork::block_receipts in crates/anvil/src/eth/backend/fork.rs map the failure to BlockchainError::FailedToDecodeReceipt.
This is the same shape as the Arbitrum system-transaction gap (type 0x6a), which fails identically on Arbitrum One and Orbit chains such as Robinhood Chain. Both come down to FoundryReceiptEnvelope having no variant for the chain's type, so a fix that adds a fallback for unknown types would cover both; separate variants would need one each.
Coverage
The fork smoke tests added in #16464 deliberately restrict themselves to standard EIP-2718 types, so they pass on Celo today. Raising MAX_STANDARD_TX_TYPE in crates/anvil/tests/it/fork_chains.rs to 0x7b reproduces the failure through the test suite, which makes it a convenient regression check once this is fixed.
Forking Celo mainnet, anvil cannot decode receipts for CIP-64 fee-currency transactions (EIP-2718 type
0x7b).eth_getTransactionReceiptfails for those transactions, and because most Celo blocks contain at least one,eth_getBlockReceiptsfails for nearly every block.Repro
Pick a
"type":"0x7b"transaction from a recent block, then:Both that call and
eth_getBlockReceiptsfor the containing block return:The upstream endpoint serves the receipt fine (
{"type":"0x7b","status":"0x1"}), so this is purely anvil's decoding.Per-type results against a forked Celo head block:
0x0,0x20x7e(OP-stack deposit)0x7b(CIP-64)Failed to decode receipteth_getBlockReceipts0x7bCause
FoundryReceiptEnvelopeincrates/primitives/src/transaction/receipt.rshas variants for the standard types plus optimism0x7d/0x7eand tempo0x76, but none for0x7b.TryFrom<AnyTransactionReceipt> for FoundryTxReceiptincrates/primitives/src/network/receipt.rstherefore rejects it, andClientFork::transaction_receipt/ClientFork::block_receiptsincrates/anvil/src/eth/backend/fork.rsmap the failure toBlockchainError::FailedToDecodeReceipt.This is the same shape as the Arbitrum system-transaction gap (type
0x6a), which fails identically on Arbitrum One and Orbit chains such as Robinhood Chain. Both come down toFoundryReceiptEnvelopehaving no variant for the chain's type, so a fix that adds a fallback for unknown types would cover both; separate variants would need one each.Coverage
The fork smoke tests added in #16464 deliberately restrict themselves to standard EIP-2718 types, so they pass on Celo today. Raising
MAX_STANDARD_TX_TYPEincrates/anvil/tests/it/fork_chains.rsto0x7breproduces the failure through the test suite, which makes it a convenient regression check once this is fixed.