foundry-rs / foundry-rs/foundry

anvil: cannot decode Celo CIP-64 (0x7b) receipts when forking

Open
#16,482 0 comments 0 reactions 1 assignee Claimed by @mattsse View on GitHub
C-anvil T-bug
Dominant language
Rust
Stars
10.6k
Forks
2.6k
Avg merge
16h 38m
Merged PRs (30d)
511

Description

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

```bash
anvil --fork-url https://forno.celo.org
```

Pick a `"type":"0x7b"` transaction from a recent block, then:

```bash
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 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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.