Arbitrum Nitro launched in August 2022, replacing the original Arbitrum Classic architecture. The migration was framed primarily as a performance and cost upgrade — and in transaction throughput terms, that framing is correct. But Nitro also changed the internal mechanics of how transactions are represented, batched, and compressed before posting to Ethereum L1, and those changes have signing implications that most wallet tooling still hasn't fully absorbed.
If you're routing transactions through Arbitrum and relying on wallet UI calldata preview to verify what you're signing, there's a good chance the preview is partially or entirely wrong — not because of a security breach, but because the wallet's calldata decoder predates the Nitro format and has never been updated.
What changed in Nitro's calldata format
Under Arbitrum Classic, transaction batches were posted to L1 as relatively straightforward RLP-encoded transaction sequences. The batch format was custom but readable with standard Ethereum tooling if you knew the offset structure. Nitro changed the batch compression model significantly.
Nitro uses Brotli compression for L1 calldata batches, passed through a custom batch dissector on the sequencer side. The raw bytes posted to the SequencerInbox contract on Ethereum are Brotli-compressed and begin with a header byte sequence that identifies the compression type: 0x00 for uncompressed (legacy), 0x02 for Brotli-compressed. User transactions are no longer individually RLP-readable from the raw L1 calldata without first decompressing the batch.
For most users, this is invisible — your transaction appears in Arbiscan, it has a normal Ethereum-style transaction hash on the L2, and the gas fee shows up in your wallet. The compression happens at the sequencer batching layer, which you don't interact with directly. The issue surfaces when wallet software tries to decode calldata from transactions that are being constructed or verified at the L2 level, particularly in contexts where the wallet is reading the transaction structure to populate a human-readable preview before signing.
EIP-1559 fee structure on Arbitrum L2 — it's not the same
Arbitrum One supports EIP-1559 format transactions (type 0x02), but the fee model has a crucial difference from Ethereum mainnet. On Arbitrum, gas price has two components: the L2 execution fee and the L1 data fee (also called the L1 gas surcharge). The L1 data fee is computed from the current L1 base fee, multiplied by the estimated calldata size of your transaction's contribution to the next L1 batch.
This means that when you sign a transaction on Arbitrum and your wallet shows you a gas estimate, that estimate includes a dynamically computed L1 component that can change between when the estimate was fetched and when the transaction actually gets included in a batch. The maxFeePerGas and maxPriorityFeePerGas fields in the signed transaction only govern the L2 execution component; the L1 data fee is separately computed by the sequencer and added on top.
The practical result: you can sign a transaction where the total fee paid deviates from the estimate shown at signing time — sometimes materially, during periods of L1 base fee volatility. Wallets that display only the EIP-1559 gas fields from the signed transaction are showing you an incomplete picture of what you'll actually pay. We're not saying wallets are being dishonest — the L1 data fee genuinely isn't knowable precisely at signing time. But a signer that doesn't surface this dynamic creates an expectation mismatch.
Chain ID detection for Arbitrum One vs Nova
Arbitrum has two production networks with different chain IDs: Arbitrum One (42161, 0xa4b1) and Arbitrum Nova (42170, 0xa4ba). The two chains differ in their data availability model — Arbitrum One posts calldata to Ethereum L1 directly, while Nova uses AnyTrust with a data availability committee. From a signing perspective, a transaction signed for Arbitrum One will not land on Nova and vice versa, because the chain IDs are different and EIP-155 scopes the signature.
The problem arises when wallets or front ends don't distinguish between the two at the display layer. A user configured for Arbitrum One who inadvertently connects to a Nova RPC endpoint — one configured at some point in the past and forgotten — will see transaction previews that look plausible but will fail to land where expected. The signer needs to verify chain ID 0xa4b1 for One or 0xa4ba for Nova, not just "Arbitrum".
ArbOS versioning and fraud proof window differences
Nitro introduced ArbOS as the internal operating system layer of the Arbitrum L2. ArbOS versions affect the block structure, precompile behavior, and the fraud proof window parameters. ArbOS 20 (introduced as part of the BoLD protocol upgrade roadmap) changed the fraud proof challenge mechanism in ways that affect the finality timeline for L2 transactions.
The practical signing implication: the "confirmed" state of a transaction on Arbitrum One has different finality guarantees than on Ethereum L1, and those guarantees changed with ArbOS upgrades. A transaction included in an L2 block is not finalized until the challenge window closes — currently approximately seven days for Arbitrum One. Until then, the transaction is "safe" (included in a sequencer batch posted to L1) but technically reversible through a valid fraud proof.
For most DeFi trading, the seven-day finality window is irrelevant — you're not waiting for L1 finality before proceeding. But for cross-chain bridge operations, particularly canonical bridge withdrawals from L2 to L1, you are waiting for that window. Any tool that represents an Arbitrum withdrawal as "completed" before the fraud proof window closes is misrepresenting the transaction's finality state.
What this means for your signing workflow
The Nitro changes don't break anything catastrophically from a user perspective — but they create gaps between what a transaction preview shows and what the transaction actually does or costs. The relevant checks before signing on Arbitrum are:
- Verify chain ID in the signed transaction header is
0xa4b1(One) or0xa4ba(Nova) as expected — not just "Arbitrum". - Treat gas estimates as lower bounds, not exact amounts, given the L1 data fee component. Check current L1 base fee before large-value transactions during periods of Ethereum fee volatility.
- If the wallet's calldata preview shows an unreadable hex blob instead of decoded function calls, the decoder is likely operating on pre-Nitro assumptions. Do not treat the preview as accurate in that state.
- For bridge withdrawals, "transaction confirmed on L2" is not the same as "funds available on L1." The fraud proof window is real and matters for fund availability planning.
The Nitro migration was the right infrastructure direction for Arbitrum. But migration-era tooling rarely catches up immediately. If your wallet's Arbitrum integration was last audited before August 2022, it's operating on an architecture that no longer matches what it's connected to — and the differences matter when you're verifying what you're about to sign.