Problem
Robinhood Chain's sf.ethereum.type.v2.Block extended Firehose stream omits
TransactionTrace.max_fee_per_gas and max_priority_fee_per_gas for Arbitrum type-2
transactions. The chain RPC exposes both fields, so this is an upstream data-completeness gap and
the values cannot be reconstructed exactly from Firehose's effective gas_price.
Observed in the first riv-dev1 production reconciliation:
- block:
26791650
- transaction:
0x9c77353445a059668cdf4b632b71e587280a2414693cf3c646102e9237bd063a
- Firehose: both fee-cap messages absent; effective
gas_price is 0x1321760
- RPC:
maxFeePerGas=0x1723d40, maxPriorityFeePerGas=0x0
The effective gas price is insufficient to derive the original maximum fee cap. Treating a missing
message as zero would silently create incorrect data.
Current behavior
The connector now treats this as an Arbitrum-specific source limitation: it keeps gasPrice and
omits the unavailable fee-cap keys. Ethereum typed transactions remain fail-closed when either
field is absent. A real Firehose request for the block above succeeds without fabricated values.
Desired resolution
Prefer fixing the Robinhood Firehose producer so its extended blocks populate both fields. If that
is not possible, evaluate a bounded exact enrichment path that does not restore per-transaction
RPC load to the backfill pipeline. Once exact values are available, remove the Arbitrum exception
and add live RPC-vs-Firehose fee-field parity coverage.
Do not infer the original cap from effective gas price or base fee.
Problem
Robinhood Chain's
sf.ethereum.type.v2.Blockextended Firehose stream omitsTransactionTrace.max_fee_per_gasandmax_priority_fee_per_gasfor Arbitrum type-2transactions. The chain RPC exposes both fields, so this is an upstream data-completeness gap and
the values cannot be reconstructed exactly from Firehose's effective
gas_price.Observed in the first riv-dev1 production reconciliation:
267916500x9c77353445a059668cdf4b632b71e587280a2414693cf3c646102e9237bd063agas_priceis0x1321760maxFeePerGas=0x1723d40,maxPriorityFeePerGas=0x0The effective gas price is insufficient to derive the original maximum fee cap. Treating a missing
message as zero would silently create incorrect data.
Current behavior
The connector now treats this as an Arbitrum-specific source limitation: it keeps
gasPriceandomits the unavailable fee-cap keys. Ethereum typed transactions remain fail-closed when either
field is absent. A real Firehose request for the block above succeeds without fabricated values.
Desired resolution
Prefer fixing the Robinhood Firehose producer so its extended blocks populate both fields. If that
is not possible, evaluate a bounded exact enrichment path that does not restore per-transaction
RPC load to the backfill pipeline. Once exact values are available, remove the Arbitrum exception
and add live RPC-vs-Firehose fee-field parity coverage.
Do not infer the original cap from effective gas price or base fee.