Understanding Arc's Transaction Model
Arc is EVM-compatible, but receipt fields, trace availability and fee accounting are not identical to Ethereum mainnet. This note records the differences that matter for an indexer.
Context
The first Arc node we pinned returned traces in a slightly different envelope than geth. Treating Arc as “just another EVM chain” produced silent gaps in arc.traces for contract-creating transactions.
Method
We compared 10,000 consecutive blocks from a local Arc node against the public RPC, field by field: header, receipts, logs, and traces. Divergent fields were written into a lineage table with the node version that produced them.
Findings
Transaction status, log bloom and cumulative gas match Ethereum. Contract-creation traces omit the `to` field rather than setting it to null. A small number of system transactions appear in the block body without a corresponding user signature.
Implications for the data model
arc.transactions.to_address is Nullable. arc.traces is flattened rather than stored as JSON. System transactions are flagged rather than dropped, so downstream decoders can ignore them without losing lineage.