Arbitrum scales Ethereum transactions through Nitro execution and compressed batches
Arbitrum uses Nitro to execute transactions outside Ethereum’s main execution layer while Arbitrum One posts compressed transaction data to Ethereum. This spreads posting costs across batches and supports Ethereum-compatible applications. Users can transfer assets, interact with smart contracts, and bridge between supported chains. Arbitrum One uses rollup data availability, while Nova uses AnyTrust with an additional committee trust assumption. Both use ETH for network fees. Choosing a network also means choosing where balances exist, which applications can use them, and how withdrawals settle. A quick transaction receipt and funds becoming available back on Ethereum represent different milestones.
Updated —
Nitro spreads Ethereum posting costs across compressed transaction batches, while execution, data availability, and withdrawal settlement impose different conditions.
Funding an application starts with its supported network
Suppose you need funds on an application’s supported network and will proceed only if funding costs stay within a firm spending limit. Your starting balance, chosen application, transfer amount, and spending limit are hypothetical. Would an existing balance on that network suffice, or would moving funds there be necessary?
Compare the available balance with a bridge deposit
Compare both options using the same conditions: the network, asset compatibility, available gas, and total funding cost. An existing compatible balance avoids a separate bridge transaction. Moving funds from a parent chain adds a transaction there and a destination credit to track. A matching wallet address alone does not establish that the balance exists on the required network.
Before authorizing a transfer, compare the transfer details and estimated charges with the spending limit. An unacceptable estimate means leaving the transfer unsigned. After submission, closing the application does not cancel the transaction or restore funds already committed.
Reconcile the destination credit before using it
In this hypothetical bridge deposit, the intended account receives the expected amount of the asset the application accepts, and actual funding charges remain within the limit. Match that credit to the initiating transaction and retain sufficient native currency for the application transaction. The funds are now usable for the application transaction; a source-chain receipt alone would not confirm their arrival.
Nitro lowers posting overhead through compressed batches
Nitro separates transaction ordering, execution, and settlement so Ethereum does not have to execute every application transaction directly. The sequencer establishes an order and broadcasts transaction information. Nodes apply the execution rules to reproduce the resulting balances and contract state. With rollup data availability, the batch poster compresses transaction data and submits batches to the parent chain.
Rollup batches can use Ethereum blobs or calldata. Compression reduces the data footprint, while batching distributes posting overhead across transactions. Neither mechanism establishes a fixed saving for every operation. The transaction’s contents and the cost of publishing data both matter. Nitro also includes ArbOS, which handles chain-specific functions such as fee accounting and cross-chain messaging.
Why do transaction fees change?
Transaction fees change because execution demand and parent-chain posting costs change independently, and different transactions consume different resources. A sequencer-submitted transaction normally pays for execution plus its estimated contribution to posting costs. Computation, storage activity, and transaction data therefore affect the charge.
The posting component uses an estimate of the transaction’s compressed footprint. Its pricing adjusts over time to compensate the batch poster. A wallet estimate describes the proposed operation under the conditions used for estimation; it does not establish a permanent network tariff. Application charges, where applicable, also remain separate from the network’s execution and posting charges.
One and Nova use different data availability guarantees
Arbitrum One and Nova both use Nitro, but they differ in where transaction data remains available for nodes to reconstruct execution. That distinction affects their trust assumptions and posting costs.
Rollup data goes to Ethereum
One publishes compressed transaction data to Ethereum using rollup infrastructure. Nodes can reconstruct execution from the ordered inputs. Ethereum’s consensus protects the published ordering once the relevant parent-chain data reaches finality. The separate dispute mechanism addresses claims about the resulting state.
AnyTrust normally uses a committee
Nova normally stores batch data with a Data Availability Committee and posts a certificate. The AnyTrust protocol assumes at least two committee members are honest. Its certificate rules connect that assumption to data availability. When the sequencer cannot obtain enough committee signatures, it can fall back to posting full batch data on the parent chain. This changes the posting cost without turning the committee into an application custodian.
Fast receipts and Ethereum settlement provide different assurances
A sequencer receipt provides early feedback about execution, while parent-chain data finality and confirmed rollup assertions establish stronger assurances. Those milestones answer different questions.
Execution feedback precedes settlement
A successful receipt reports that execution succeeded in the state the node reports. Application logs and resulting balances explain what actually changed. Early sequencing remains provisional until the transaction’s ordered inputs receive stronger parent-chain protection.
Once a rollup batch reaches Ethereum finality, its ordered transaction data inherits Ethereum’s consensus security. Settlement of the asserted state follows the rollup’s confirmation rules. Posting a batch does not, by itself, make a withdrawal executable on Ethereum.
Disputes protect execution correctness
Validators can challenge incorrect assertions about execution. BoLD narrows disagreements until Ethereum can verify the disputed execution step. These protections address protocol correctness; they do not make every application contract safe or reverse an authorized transfer. Sequencing availability, contract behavior, and protocol upgrades remain relevant to assessing an application transaction.
Ethereum compatibility supports applications and dedicated chains
Developers can deploy Ethereum Virtual Machine contracts on public Nitro chains using familiar Solidity tooling. Applications can implement transfers, exchanges, lending, and other contract operations. Each deployment has its own addresses, liquidity, and rules; compatibility does not automatically copy an Ethereum application’s state onto another network.
Stylus adds support for contracts written in languages such as Rust alongside EVM contracts. Teams can also launch dedicated chains with configurable gas tokens, data availability, governance, and validation. A dedicated chain’s settings require their own assessment. Shared Nitro software does not make every deployment identical to One or Nova.
ARB gives holders a role in governance
ARB supports voting and delegation in the ArbitrumDAO. Governance covers decisions affecting the governed protocols and chains, including upgrades. ETH pays transaction fees on One and Nova, so holding ARB alone does not provide the native balance needed for ordinary transactions. Governance participation and application use are separate activities, even when the same wallet performs both.
When can a withdrawal reach Ethereum?
A canonical withdrawal can execute on Ethereum after the relevant rollup assertion satisfies its confirmation requirements and the withdrawal message becomes executable. The challenge process creates a delay measured in days on the public mainnet chains. An early withdrawal receipt records initiation rather than an immediately spendable Ethereum balance.
Execution on Ethereum is a further transaction with its own gas cost. The initiating withdrawal and the destination execution therefore have separate records. A withdrawal’s completion requires the destination action to succeed, rather than merely a countdown reaching its end. The bridge’s message status determines whether execution is available.
Liquidity-based bridges can offer earlier destination funds by providing liquidity against the transfer. Their supported assets, liquidity, charges, and contract assumptions affect availability. They do not shorten the underlying rollup challenge process. The distinction applies to canonical exits from both Arbitrum One and Arbitrum Nova.
Things people ask about Arbitrum
Can a failed transaction still consume gas?
A transaction that executes and reverts can still consume gas. The failed execution does not preserve its intended contract changes, but the network charges for work performed. A rejected transaction that never executes is a different case, so the receipt matters when interpreting a failure.
What happens if an exchange does not support the network I used?
An exchange may not credit a transfer sent over an unsupported network, even when the destination address matches. Recovery depends on the receiving service’s control of that address and its recovery capabilities. An onchain success receipt does not establish that the service accepted the deposit.
Why can a parent-chain message succeed while its destination action remains pending?
Parent-chain submission and destination execution are separate operations for a retryable ticket. A successful initiating transaction can therefore coexist with an unexecuted destination call. Manual redemption may be possible while the ticket remains valid, but another attempt still needs sufficient gas and contract conditions that permit execution.
Which chain ID distinguishes One from Nova?
Arbitrum One uses chain ID 42161, while Arbitrum Nova uses chain ID 42170. These identifiers distinguish separate networks even though both use ETH for gas. A wallet displaying the same account address on both networks does not imply shared balances.
Does running a full node make someone a sequencer?
Running a full node does not grant sequencer privileges. A full node lets its operator access chain data through infrastructure they control and reproduce execution. Sequencing and posting batches involve distinct roles and permissions; running node software alone does not confer those permissions.
How can transactions enter the chain during sequencer censorship?
The Delayed Inbox provides a parent-chain submission path, with force inclusion available after the configured conditions permit it. This path requires a parent-chain transaction and its associated cost. It offers an alternative to cooperation from the sequencer, rather than a promise of immediate execution during an outage.