Arbitrum vs. Optimism vs. Base: Three Different Ethereum L2s

Arbitrum One, OP Mainnet, and Base all support Ethereum-compatible smart contracts, but they are not interchangeable Layer 2 systems.

They often appear in the same category: Ethereum L2 networks with familiar wallets, EVM compatibility, and lower transaction fees.

That is a useful starting point. It is not a complete explanation.

From the perspective of a straightforward Solidity contract, these networks can look remarkably similar. They use ETH for gas, support Ethereum JSON-RPC methods, work with Foundry, Hardhat, viem, and ethers, and usually appear inside the same wallet.

Underneath that familiar interface, however, they operate differently.

Arbitrum One uses Nitro, ArbOS, and Arbitrum’s own rollup protocol. OP Mainnet runs on the OP Stack, a modular software framework for building Ethereum rollups. Base was also built on the OP Stack, but it has its own state, sequencer, economics, users, and infrastructure. Its independent network upgrades now make it especially important not to assume that every current OP Mainnet rule also applies to Base.

After 25 years in traditional finance, I instinctively separate a fast acknowledgment from final settlement. That distinction matters just as much here. A transaction can look finished in a wallet while the underlying system is still moving through several different security milestones.

This is not simply a comparison of three RPC endpoints.

The practical questions are:

• How does each network produce and confirm blocks?
• Who determines transaction ordering?
• How can the network’s state be independently verified through Ethereum?
• What makes up the transaction fee?
• How long does a withdrawal to Ethereum take?
• Which network-specific features enter the application’s code?
• What kind of product is each network a sensible fit for?

Technical documentation reviewed October 18, 2026. Client support, proof configurations, withdrawal windows, and deployment restrictions can change, so production integrations should verify the active network configuration.

What Does an Ethereum Layer 2 Actually Do?

An Ethereum rollup executes transactions outside Ethereum L1 while using Ethereum for transaction-data availability and settlement through its rollup contracts.

Ethereum L1 provides execution, consensus, and data availability, but block space is limited. When many users want to transact, they compete for that shared resource through transaction fees.

A rollup moves much of the execution work into an L2 environment. It does not eliminate the need to establish transaction ordering, publish the necessary data, or verify claims about the resulting state.

For Arbitrum One and OP Mainnet, the baseline model is an optimistic rollup. Base shares that architectural lineage, although its current proof and withdrawal configuration needs separate treatment rather than assumptions copied from an older OP Stack comparison.

A simplified optimistic rollup transaction follows this path:

1. The user signs an L2 transaction.
2. A sequencer accepts the transaction and determines its position in the transaction order.
3. The transaction executes in the L2 environment.
4. The user receives a fast L2 confirmation.
5. The data needed to reconstruct the L2 chain is published to Ethereum.
6. The rollup protocol receives claims about the resulting L2 state.
7. Invalid state claims can be challenged under the protocol’s rules.

The application gets faster, less expensive execution. Ethereum provides the underlying data and settlement environment, while the rollup’s contracts and proof system determine how state claims become usable on L1.

Ethereum does not simply reexecute every L2 transaction as an ordinary Ethereum transaction.

Why an L2 Transaction Has More Than One Confirmation Status

An L2 transaction moves through multiple security milestones, and those milestones should not be collapsed into one “confirmed” label.

A transaction might be:

• Accepted by the sequencer.
• Included in an L2 block.
• Published as part of a batch of data on Ethereum.
• Independently derived from accepted L1 data.
• Associated with a finalized Ethereum block.

For a withdrawal, there is another question: has the relevant state claim satisfied the protocol’s requirements for execution on Ethereum?

That is different from asking whether the transaction’s data has reached Ethereum finality.

A social application might be comfortable reacting immediately to L2 inclusion. A large withdrawal, a collateral-crediting decision, or a treasury transfer may require a stronger threshold.

There is also an infrastructure detail worth remembering: Ethereum blob publication provides protocol-level data availability, not a promise that every ordinary RPC provider will serve every historical blob forever. Nodes rebuilding old history need access to the required historical data.

These are shared rollup concepts. Their implementation is not identical across Arbitrum One, OP Mainnet, and Base.

How Arbitrum One Works: Nitro, ArbOS, and Its Own Rollup Protocol

Arbitrum One is an Ethereum optimistic rollup built on Nitro, with ArbOS handling the additional rules that an L2 needs beyond ordinary EVM execution.

“Arbitrum” is not the name of just one blockchain.

The ecosystem includes multiple networks and technologies. For a conventional public dApp deployment, however, the network most teams mean is Arbitrum One.

The official Arbitrum chain information lists Arbitrum One’s mainnet chain ID as 42161 and Arbitrum Sepolia’s chain ID as 421614. Gas is paid in ETH. ARB is a governance token, not Arbitrum One’s native gas asset.

For an EVM developer, the initial experience is familiar:

• Solidity contracts.
• Ethereum ABI encoding.
• Standard events and logs.
• eth_call.
• eth_estimateGas.
• eth_sendRawTransaction.
• ERC-20, ERC-721, and ERC-1155 standards.
• Foundry and Hardhat.
• Standard wallet adapters.

Nevertheless, Arbitrum One is not simply a Geth instance producing shorter blocks.

How Arbitrum Nitro Processes Transactions

Nitro combines Ethereum-compatible execution with Arbitrum-specific sequencing, data publication, and dispute resolution.

The technical explanation of Arbitrum Nitro describes an architecture that uses Geth components for Ethereum compatibility while separating efficient execution from the machinery needed to prove disputed execution.

I find it helpful to break that architecture into responsibilities:

• The sequencer receives and orders user transactions.
• The execution engine performs EVM execution.
• ArbOS handles L2-specific system functions.
• The batch poster publishes transaction data to Ethereum.
• Independent nodes and validators check the derived state.
• The rollup protocol resolves disputes over state assertions.

The sequencer provides the fast user experience. Once it accepts and executes a transaction, an application can often receive a receipt and display the result almost immediately.

That receipt is not the same thing as Ethereum finality.

The transaction’s data still needs to become available through L1. Separately, state assertions must satisfy the rollup protocol’s rules before they can authorize certain L1 actions.

A backend should therefore maintain something more expressive than a single Boolean named confirmed.

An application might begin with a status model like this:

sequenced -> posted_to_l1 -> confirmed -> finalized

Those labels need explicit definitions.

For example, confirmed might mean that the application’s chosen L1 confirmation threshold has been reached, while finalized means the Ethereum block containing the batch data has finalized.

Arbitrum’s formal assertion-confirmation milestone is separate. It determines when the relevant L2-to-L1 message can become executable and can arrive much later.

The Arbitrum explanation of transaction finality distinguishes parent-chain data finality from full settlement through a confirmed assertion. I would preserve that distinction in the backend rather than hide both concepts behind one status.

The application does not have to expose every internal milestone to the user. It does need to know which milestone authorizes each business action.

Why ArbOS Exists

ArbOS supplies the L2-specific rules that ordinary Ethereum execution does not provide.

On Ethereum, an execution client processes transactions under Ethereum’s protocol rules. Arbitrum additionally needs rules for L1-to-L2 communication, data-cost accounting, system messages, and rollup-specific behavior.

ArbOS provides those functions.

For most Solidity contracts, ArbOS stays in the background. A contract still works with msg.sender, msg.value, storage, calldata, and familiar EVM operations.

ArbOS becomes relevant when an application:

• Estimates the L1 component of a transaction fee.
• Sends messages between Arbitrum and Ethereum.
• Reads supported L1 information from an L2 contract.
• Uses Arbitrum system precompiles.
• Works with retryable tickets.
• Depends on Arbitrum-specific chain behavior.

Once a contract directly uses an Arbitrum system interface, it is no longer fully portable to another EVM network without adaptation.

That is not automatically a problem. I see the real problem when a team introduces that dependency without treating it as an architectural decision.

How Retryable Tickets Handle L1-to-L2 Messages

Retryable tickets are Arbitrum’s canonical mechanism for many Ethereum-to-Arbitrum contract messages, separating message submission from execution on L2.

Sending an ordinary transaction directly to Arbitrum One is different from initiating a message on Ethereum that must later execute on Arbitrum.

A retryable ticket describes an intended L2 operation, including parameters such as:

• The destination L2 address.
• Calldata.
• The value being transferred.
• Funding for L2 gas.
• Refund addresses.
• The gas limit.

The broader L1-to-L2 system also includes other message types. A straightforward native ETH deposit, for example, should not be confused with every arbitrary contract-call workflow.

For implementation, I would start with the official Arbitrum bridge and SDK documentation rather than recreate the protocol manually.

These abstractions exist for a reason. Incorrect gas assumptions can leave execution unsuccessful, while an incorrect refund address can send returned funds somewhere the application did not intend.

A failed automatic execution may require a later redemption attempt. Ticket lifetime and any required maintenance also need monitoring.

The important operational consequence is that an L1-to-L2 workflow has at least two distinct events:

1. The initiating transaction succeeds on Ethereum.
2. The corresponding message successfully executes on Arbitrum.

A backend that watches only the Ethereum receipt can declare the overall operation complete too early.

How Arbitrum Transaction Fees Work

Arbitrum transaction fees account for both L2 execution and the cost of publishing transaction data to Ethereum.

The Arbitrum gas and fee documentation separates the charge for child-chain resources from the charge associated with parent-chain publication.

For Arbitrum One, the two basic economic components are:

• Execution on Arbitrum.
• Publication of transaction data on Ethereum.

The execution component depends on the work performed and Arbitrum’s gas price.

The data component depends on the transaction’s estimated contribution to published batch data and the network’s estimate of the relevant Ethereum publication cost.

Compression matters. Two transactions with similar calldata lengths can have different estimated compressed footprints. The fee model is an allocation mechanism, not a perfect calculation of each transaction’s eventual marginal contribution to an entire batch.

This is why I would not look only at the following expression and assume I had explained the economics:

gasUsed * gasPrice

There is an important accounting nuance here.

Arbitrum can represent the parent-chain data charge in L2 gas units. Consequently, multiplying the total gas charged in the receipt by the effective gas price can account for the transaction’s total native fee.

What would be wrong is using EVM execution gas alone, multiplying it by the L2 gas price, and assuming there is no additional data-publication cost.

For a standard transaction, a wallet or compatible library will generally obtain the appropriate estimate through RPC.

A more detailed breakdown becomes important when an application:

• Sponsors user gas.
• Displays execution and data fees separately.
• Compares operation costs across networks.
• Plans large numbers of automated transactions.
• Runs its own relayer.

Fees are not fixed. I would not hard-code a transaction’s expected cost into the interface or a business budget.

How Long Arbitrum Withdrawals Take

A canonical withdrawal from Arbitrum One to Ethereum normally requires about a week, while an Ethereum-to-Arbitrum deposit follows a much faster path.

Deposits and withdrawals are not symmetrical operations.

An L1-to-L2 deposit can complete relatively quickly after the Ethereum transaction and the corresponding L2 processing.

A standard L2-to-L1 withdrawal follows a longer sequence:

1. The user initiates the withdrawal on Arbitrum.
2. The outgoing message becomes part of the L2 state.
3. An assertion covering the relevant state is submitted to Ethereum.
4. The applicable challenge period and confirmation requirements run their course.
5. The message becomes executable on L1.
6. The user or a relayer submits the final Ethereum transaction.

For planning purposes, I would allow approximately seven days before the final L1 execution becomes available under the normal canonical flow.

That is not a guaranteed 168-hour service-level agreement. Assertion timing, disputes, protocol configuration, and the final execution transaction can affect the total elapsed time.

A fast bridge may pay the user sooner. It does not make the canonical protocol’s waiting period disappear. A liquidity provider effectively takes the waiting period onto its own balance sheet and charges for that service.

From a financial perspective, that is a liquidity arrangement, not instant elimination of settlement risk.

What Arbitrum Stylus Changes for Developers

Stylus adds a WebAssembly execution environment that can interoperate with EVM contracts, expanding the programming model beyond Solidity.

The introduction to Arbitrum Stylus explains how developers can write contracts in languages such as Rust, C, and C++, compile them to WebAssembly, and connect them with EVM contracts.

That creates several possibilities:

• Using Rust’s type system and development ecosystem.
• Reusing suitable existing code.
• Improving the efficiency of certain computation-heavy operations.
• Combining Solidity and Stylus contracts within one application.

A Solidity contract can call a Stylus contract, and a Stylus contract can interact with EVM contracts.

Nevertheless, Stylus is not automatically a reason to rewrite an existing application.

A team also introduces:

• A different build pipeline.
• A different programming model.
• Additional audit scope.
• A smaller pool of auditors with directly relevant experience.
• New assumptions about tools and libraries.

I would consider Stylus when there is a concrete benefit, such as computationally intensive logic or existing Rust code that can be safely adapted to a smart contract environment.

Deployment availability is a separate question from technical capability.

At this review, the notice pausing new Stylus activations states that new and expired Stylus contracts cannot be activated on Arbitrum One or Arbitrum Nova while the pause remains in effect.

Already activated contracts remain callable while active, and active contracts can be renewed through the documented keepalive mechanism. Ordinary Solidity and EVM deployment and execution are unaffected.

For a new product, I would therefore treat Stylus as an architectural capability whose current activation status must be checked, not as an unconditional deployment option.

A Practical Arbitrum Use Case: Automated Treasury Management

Arbitrum One can be a sensible choice when an application needs the DeFi protocols and liquidity already available on that network.

Consider an automated treasury system that:

1. Receives stablecoin payments.
2. Exchanges part of the balance for another asset.
3. Uses a lending protocol for short-term liquidity.
4. Periodically withdraws excess funds to Ethereum.
5. Maintains an internal ledger of every operation.

The Solidity component might be relatively small. Much of the difficult work sits in the surrounding infrastructure:

• Verifying the exact token contract addresses.
• Enforcing slippage limits.
• Monitoring oracle data.
• Indexing events.
• Monitoring open positions.
• Distinguishing L2 confirmation from L1 finality.
• Managing the withdrawal waiting period.
• Maintaining enough ETH for gas.

Provider capabilities matter, too. For example, Arbitrum’s listed public RPC endpoints do not provide WebSocket support, so an event-driven backend needs an appropriate provider or its own infrastructure.

The advantage here is not an abstract claim that Arbitrum is “faster.”

The advantage is that the application can interact with the specific protocols, assets, and markets it actually needs.

The Arbitrum Trade-Off

Arbitrum One offers a familiar EVM environment and a developed application ecosystem, but introduces a distinct rollup-specific systems layer.

A developer needs to understand:

• The sequencer and its availability assumptions.
• Nitro and ArbOS behavior.
• Retryable tickets.
• L1 and L2 fee components.
• The canonical withdrawal waiting period.
• Arbitrum-specific precompiles.
• The difference between sequencer confirmation and Ethereum finality.
• The separate role of assertion confirmation for L1 execution.

There are L1-based alternatives to the normal sequencer submission path, but those are recovery and censorship-resistance mechanisms, not substitutes for ordinary low-latency operation.

If an application uses only standard EVM functionality, most of this complexity can remain in its infrastructure layer.

If it uses cross-chain messaging and system contracts, Arbitrum-specific behavior becomes part of the business logic.

How Optimism Works: OP Mainnet and the OP Stack

OP Mainnet is a specific Ethereum L2 network, while the OP Stack is the modular software framework used to build it and other compatible rollups.

The word “Optimism” gets used for several different things:

• OP Mainnet is a particular Ethereum L2 network.
• OP Stack is the collection of software components used to build rollup networks.
• Optimism Collective is the broader governance and economic organization.
• Superchain describes an ecosystem of OP Stack networks adopting shared standards.

The OP Mainnet and OP Stack development documentation covers these different layers, but they should not be treated as synonyms.

When an application sends a transaction to “Optimism,” it usually means OP Mainnet.

OP Mainnet uses chain ID 10. OP Sepolia uses 11155420. Gas is paid in ETH, not OP.

How the Modular OP Stack Architecture Fits Together

The OP Stack separates transaction execution, chain derivation, data publication, and state verification into different components.

Its major responsibilities include:

• An execution client that processes EVM transactions.
• A rollup node that derives the L2 chain from L1 data.
• A sequencer that orders new L2 transactions.
• A batcher that publishes transaction data to Ethereum.
• A proposer that submits claims about L2 output state.
• Proof and dispute components that allow invalid claims to be challenged.

Older explanations commonly describe an op-geth execution client paired with op-node.

That remains useful historical context, but it is no longer current deployment guidance.

The current OP Stack node architecture reference states that op-geth reached end of support on May 31, 2026, and cannot follow the canonical chain under the now-active Karst hardfork. The primary supported execution client is op-reth; op-node remains the reference rollup-node implementation.

The architectural separation is the same:

• The execution client maintains EVM state and executes transactions.
• The rollup node follows Ethereum, processes published rollup data, and derives valid L2 block payloads.
• The two communicate through the Engine API.

This distinction matters more than memorizing one particular client pairing.

An OP Mainnet block is not canonical merely because an RPC endpoint returns it. An independently operated rollup node can read the relevant Ethereum data, apply the protocol rules, and verify how the L2 chain should be derived.

What OP Stack Derivation Means

Derivation is the process that reconstructs the canonical L2 chain from Ethereum data under the rollup’s rules.

The OP Stack derivation specification describes the pipeline responsible for turning L1 inputs into valid L2 execution payloads.

At a high level, the rollup node:

1. Reads Ethereum blocks.
2. Identifies relevant deposit events and batch data.
3. Decodes channels and batches.
4. Organizes the inputs around their L1 origin blocks.
5. Produces payload attributes.
6. Passes those attributes to the execution engine.
7. Checks and advances the chain according to the protocol’s rules.

Ethereum is therefore doing more than occasionally storing a hash.

The published data allows an independent node, with the required data access, to reconstruct the L2 history. The sequencer provides the fast path to new blocks, while L1 derivation establishes the independently verifiable chain.

For me, that is the central OP Stack concept. EVM compatibility explains how the contracts execute. Derivation explains how an independent observer can verify the chain they executed on.

What Unsafe, Safe, and Finalized Mean on OP Mainnet

OP Stack nodes distinguish sequencer-produced blocks from blocks supported by published L1 data and finalized Ethereum history.

These labels are particularly important for backend developers.

Unsafe head is the latest chain produced by the sequencer. A transaction can already be visible and executed, even though its data has not yet been published to Ethereum.

Safe head is the L2 chain that can be derived from data published on L1. The relevant Ethereum blocks can still reorganize before finalization.

Finalized head is the L2 chain derived from finalized Ethereum blocks.

“Unsafe” is a protocol term. It does not mean that every such transaction is likely to disappear. It means the application is still relying on the sequencer’s provisional view rather than L1-backed derivation.

There can also be an earlier preconfirmation signal. The current OP Mainnet transaction-finality guidance describes Subblock preconfirmations at approximately 200 milliseconds, followed by ordinary L2 block inclusion and the later L1-backed milestones.

Fast preconfirmation is therefore not a feature unique to Base.

Consider a backend that accepts a stablecoin deposit and immediately allows the customer to withdraw a different asset.

If it treats unsafe state as unlimited, irreversible credit, it takes the risk that the sequencer’s view will not become the safe chain.

If it waits for finalized state before every harmless interface update, it can make the product unnecessarily slow.

A risk-based policy might look like this:

• A small payment receives provisional credit after early L2 inclusion, with strict exposure limits.
• A medium-sized payment waits for safe status.
• A large payment waits for finalized status or additional review.

I would distinguish provisional display or credit from unrestricted release of value. Exchange-like services, bridges, and systems taking irreversible off-chain actions should generally use at least L1-backed safe status as their baseline, with stronger requirements where appropriate.

The transaction status is a technical signal. The business still needs to decide what that signal authorizes.

How OP Mainnet Transaction Fees Work

OP Mainnet fees include execution costs, Ethereum data-publication costs, and a configurable operator-fee component.

The current OP Mainnet fee model identifies these components:

• L2 execution fee.
• L1 data fee.
• Operator fee, according to the active protocol and configuration.

A configured component may be zero. Its existence in the protocol does not mean the same nonzero amount applies across every OP Stack network.

The execution fee depends on gas used and the effective L2 gas price, including the base fee and any applicable priority fee.

The L1 data fee covers the estimated cost of publishing the transaction’s data to Ethereum. Following EIP-4844 and the relevant OP Stack upgrades, blob-enabled networks can publish batches using Ethereum blob space.

The data fee consequently depends on factors including:

• The estimated compressed size of the serialized transaction.
• Ethereum’s relevant fee markets.
• The network’s active fee scalars and pricing rules.

It is not a constant.

Two functions with similar EVM execution requirements can have different total costs if one produces a substantially larger data footprint.

That matters for:

• Batch operations.
• Multisend contracts.
• Large proofs and signatures.
• Calldata-heavy oracle updates.
• Account abstraction operations.
• Contract deployment.

Optimizing Solidity execution alone may not be enough. On a rollup, data format and size are part of the application’s economics.

How OP Stack Fault Proofs Work

Fault proofs allow participants to challenge invalid claims about L2 execution results instead of requiring everyone to trust one operator’s proposed output.

An optimistic rollup treats a proposed state claim as eligible to progress unless it is successfully challenged under the protocol’s rules.

The OP Stack fault-proof explanation separates the claim about execution results from the dispute process used to test that claim.

A challenger can initiate a dispute when a proposal conflicts with the chain’s execution rules.

For an application developer, this is not an API to call with every transaction. Its importance is structural:

• It allows proposed state claims to be checked.
• It reduces dependence on a single trusted proposer.
• It helps define the security of L2-to-L1 exits.
• It affects withdrawal timing.

A dispute over an invalid output proposal should not be confused with casually rewriting an already correctly derived L2 history. The chain’s derivation rules and the bridge’s acceptance of a proposed output are related but distinct mechanisms.

The existence of fault proofs also does not make every part of a network fully decentralized.

I would separately check:

• Who operates the sequencer.
• Who can upgrade system contracts.
• Whether a security council has emergency powers.
• Whether upgrades have a delay.
• Under what conditions users can submit transactions through L1.
• Who can participate in proposals and challenges.

The proof system is one part of the threat model, not a substitute for the whole threat model.

How the OP Standard Bridge Works

The OP Standard Bridge transfers ETH and supported ERC-20 tokens between Ethereum and OP Mainnet through a defined cross-domain messaging system.

The Standard Bridge design and token requirements explain how the L1 and L2 bridge contracts coordinate these transfers.

For an ERC-20 asset, the relationship between the local and remote token matters.

Depending on the transfer direction and the token’s origin, the process can involve:

• Locking the original token in a bridge contract.
• Minting or using its corresponding representation on the other network.
• Burning that representation on the return journey.
• Unlocking the original token.

A token symbol is not a sufficient identifier.

The backend needs a relationship such as:

chain ID + contract address + remote token address

Different representations of the same original asset can be separate tokens with separate contract addresses and risks.

Token behavior also matters. The Standard Bridge does not support every unusual ERC-20 implementation. Fee-on-transfer and rebasing tokens, for example, can break its accounting assumptions.

A standard OP Mainnet withdrawal to Ethereum is a multistage process.

Instead of displaying only “withdrawal sent,” an application should expose meaningful progress:

initiated -> ready to prove -> proven -> ready to finalize -> finalized

The user may need to submit more than one transaction.

If a relayer handles those steps, the operational responsibility and cost have moved to the backend. They have not disappeared.

Plan around the roughly seven-day canonical withdrawal waiting period, plus the practical time needed for proof availability, the required transactions, and any additional delays.

That waiting period is not the time every OP Mainnet transaction takes to reach Ethereum-backed finality.

When OP Mainnet Makes Sense for Developers

OP Mainnet is a practical choice for teams that want direct experience with the OP Stack’s production architecture and standards.

It can be especially useful for a team planning:

• Deployments across multiple OP Stack networks.
• Integration with Superchain standards.
• Its own OP Stack chain.
• Standardized cross-chain infrastructure.
• Use of shared OP Stack system interfaces.

However, portability is not automatic.

The same bytecode may be deployable on several compatible networks, while all of the following remain different:

• Chain ID.
• Contract addresses.
• State.
• Tokens.
• Liquidity.
• Bridge configuration.
• Fee parameters.
• Governance.
• Upgrade schedules.

Interoperability features also need to be checked on the actual networks involved. Shared software ancestry does not guarantee that a particular messaging mechanism is enabled between every pair of chains.

The OP Stack reduces some technical differences. It does not turn separate networks into one shared blockchain.

A Practical Optimism Use Case: Portable Escrow Contracts

An application can begin on OP Mainnet with ordinary EVM contracts and later deploy similar code elsewhere, provided it keeps chain-specific configuration outside the core contract.

Imagine an escrow-payment protocol that starts on OP Mainnet and eventually supports other compatible networks.

Its basic storage and funding logic can remain relatively neutral:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract Escrow {
    enum Status {
        None,
        Funded,
        Released,
        Refunded
    }

    struct Payment {
        address payer;
        address recipient;
        uint256 amount;
        Status status;
    }

    mapping(bytes32 => Payment) public payments;

    function fund(
        bytes32 paymentId,
        address recipient
    ) external payable {
        require(msg.value > 0, "zero value");
        require(
            payments[paymentId].status == Status.None,
            "payment exists"
        );

        payments[paymentId] = Payment({
            payer: msg.sender,
            recipient: recipient,
            amount: msg.value,
            status: Status.Funded
        });
    }
}

This example demonstrates portability, not a finished escrow product.

It only accepts and records ETH. It does not implement release or refund functions, despite defining those enum values. Deployed as shown, it provides no payout path.

A production escrow also needs appropriate authorization, recipient validation, events, complete release and refund logic, and security review.

The portability point is that this contract does not directly depend on OP Stack system contracts. Its ordinary EVM logic can be deployed across compatible networks.

The backend must still maintain each deployment separately:

type Deployment = {
    chainId: number;
    contractAddress: `0x${string}`;
    deploymentBlock: bigint;
};

const deployments: Deployment[] = [
    {
        chainId: 10,
        contractAddress: "0x...",
        deploymentBlock: 0n,
    },
    {
        chainId: 11155420,
        contractAddress: "0x...",
        deploymentBlock: 0n,
    },
];

The addresses and zero block numbers are placeholders.

In a real configuration, deploymentBlock should contain the actual deployment block. An indexer has no reason to scan from genesis when the contract did not exist yet.

Mainnet and testnet deployments must also remain separate environments, even when their contract code is identical.

If the protocol later adds direct cross-chain messaging, the application is no longer neutral in quite the same way. It needs an explicit coordination mechanism, such as:

• A supported OP Stack interoperability mechanism, where enabled.
• Canonical bridge messaging.
• An independent messaging protocol.
• Its own relayer.
• Off-chain coordination.

That is the dividing line between deploying the same application several times and building a genuinely coordinated multichain application.

The Optimism Trade-Off

OP Mainnet combines familiar EVM execution with a relatively clear path into the broader OP Stack architecture.

Its advantage is not simply a cheaper transaction. For some teams, the larger benefit is a coherent route from one L2 deployment toward a more extensive OP Stack-based system.

The additional complexity includes:

• The derivation pipeline.
• Unsafe, safe, and finalized statuses.
• L1 and L2 fee components, plus configured operator fees.
• Multistage withdrawals.
• Bridge token relationships.
• System predeploy contracts.
• The distinction between OP Mainnet as a network and the OP Stack as software.

Current client support also belongs on that operational checklist. An old guide can describe the architecture correctly while recommending binaries that no longer follow the chain.

If an application stays on one network and uses only standard EVM features, much of this complexity can remain behind infrastructure adapters.

If it adds cross-chain functionality, those details become central to the design.

How Base Works: OP Stack Roots and an Independent Upgrade Path

Base is a separate Ethereum L2 originally built on the OP Stack, with its own state, sequencer, ecosystem, and increasingly distinct protocol configuration.

Coinbase incubated Base. That does not make Base part of OP Mainnet’s state, and it does not make the network a private Coinbase database.

The Base chain ID reference identifies Base mainnet as 8453 and Base Sepolia as 84532.

Gas is paid in ETH. A user does not need a separate Base-branded token to send an ordinary transaction.

Base’s architectural roots make much of its structure recognizable to an OP Stack developer:

• An execution client performs EVM execution.
• A rollup or consensus component follows L1 and derives L2 state.
• A sequencer produces new L2 blocks.
• A batcher publishes transaction data to Ethereum.
• Independent nodes can reconstruct the chain from the required published data.
• Nodes distinguish unsafe, safe, and finalized views.

But shared origins do not mean permanent implementation identity.

The Base network upgrade schedule documents independent upgrades beginning with Azul in 2026, followed by changes including Beryl and Cobalt. Beryl changed canonical withdrawal timing, among other features.

The current Base protocol architecture also describes its Reth-based execution environment and current proof components.

I would therefore describe Base as OP Stack-derived, while checking its current clients, proof rules, and upgrades directly in Base’s documentation.

Why Base Has Separate State From OP Mainnet

A contract deployed on Base and a contract deployed on OP Mainnet are separate instances, even when their code and addresses match.

They have separate:

• Storage values.
• Balances.
• Account nonces.
• Events.
• Administrative roles.
• Upgrade paths.
• Liquidity.
• Users.

A contract executing on Base cannot synchronously read the storage of an OP Mainnet contract as though both existed in the same EVM state.

Even an identical contract address does not make them the same object.

A complete contract identifier includes the network:

chain_id + contract_address

The same principle applies to tokens.

An address without a chain ID is not a complete asset identifier. This is a basic database-design requirement for a multichain product, not an optional naming preference.

How Base Derives Its L2 Chain

Base uses Ethereum data and protocol rules to derive an independently verifiable L2 chain, rather than requiring every observer to accept the sequencer’s latest claim.

The Base derivation rules explain how the required L1 inputs produce L2 blocks.

The sequencer provides the fast view of the latest state.

An independent verifying node can also follow Ethereum and derive the chain from the published inputs. It does not have to accept the sequencer’s statements without checking them.

That creates two particularly important views:

• The state the sequencer has just produced.
• The state that can be derived from the relevant published L1 data.

The first is useful for a responsive interface. The second is important for a backend making settlement-sensitive decisions.

The later finalized view adds Ethereum’s finality guarantee to the underlying L1 history.

A Base application should not treat every receipt as an equally strong accounting signal.

What Base Flashblocks Do, and What They Do Not Do

Flashblocks provide fast preconfirmations while a Base block is being built; they are not Ethereum finality.

Base exposes transaction progress at approximately 200-millisecond intervals through Flashblocks-aware infrastructure.

That can improve responsiveness for:

• Trading interfaces.
• Games.
• Auctions.
• Payment interfaces.
• Applications with frequent state changes.
• Agents submitting sequences of transactions.

The distinction I would keep explicit is:

submitted
preconfirmed
included
safe
finalized

A frontend can use a preconfirmation to display an expected result sooner.

A backend changing a financial ledger needs to know whether the transaction has entered the ordinary L2 chain and whether it has reached the stronger confirmation threshold required by the business.

There is also a practical nonce-management issue.

If an application submits several transactions quickly, a provider’s ordinary pending-state view may not include every transaction visible through the Flashblocks stream.

The Base guidance on transaction counts and preconfirmed nonces explains how eth_getTransactionCount with pending can include preconfirmed transactions on the documented endpoint.

The requirement is not necessarily a special-looking URL. It is an endpoint with documented, Flashblocks-aware pending-state behavior.

I would not assume that every third-party provider implements that view identically.

High-frequency systems also need local nonce coordination. Repeatedly querying pending does not prevent two concurrent workers from selecting the same next nonce.

For an ordinary application that sends one transaction and waits for a receipt, these concerns may remain invisible.

For a relayer, market maker, or automated agent, they are part of the core transaction-submission design.

Base’s roadmap also distinguishes Flashblocks from the planned Denim move to native 200-millisecond blocks. At this review, the roadmap targets that mainnet transition for November 2026. A planned canonical block-time change should not be described as an already active feature, and neither model removes the separate requirement for L1-backed finality.

How Base Transaction Fees Work

Base fees reflect L2 execution, Ethereum data publication, and the active network’s pricing parameters.

The basic economic model includes:

• L2 execution cost.
• L1 data-publication cost.
• Additional fee settings in the current Base configuration.

The execution component depends on gas used and the effective Base gas price, including applicable priority fees.

The data component depends on the transaction’s published footprint and the relevant Ethereum execution or blob fee markets.

Base also exposes operator-fee parameters. That does not mean every transaction necessarily carries an additional nonzero operator charge. The published reference configuration lists standard operator-fee values of zero, but I would verify the active settings rather than treat that as a permanent guarantee.

Other parameters, including minimum base-fee settings and data-pricing rules, can also affect the economics.

An application should not assume the total fee is simply execution gas used multiplied by baseFeePerGas.

For a user, the most relevant estimate is usually the one shown by a compatible wallet immediately before signing.

For a developer sponsoring gas, historical operating data is more useful:

• Median cost by operation type.
• Higher cost percentiles.
• The relationship between L1 and L2 components.
• The cost of failed transactions.
• Contract-deployment costs.
• Costs during periods of elevated activity.

If the product pays users’ gas, “Base is cheap” is not a budget model.

How Base Bridging and Withdrawals Work

Base’s canonical withdrawal timing is now configuration- and proof-path-dependent, not a universal seven-day wait.

Base retains bridge interfaces and architectural concepts inherited from the OP Stack, but its independent upgrades mean an old OP Mainnet withdrawal assumption is no longer sufficient.

Deposits and withdrawals still follow different paths.

For an Ethereum-to-Base deposit, the user initiates an L1 transaction. The resulting deposit message is then included and processed under Base’s derivation rules.

A canonical Base-to-Ethereum withdrawal generally involves:

1. Initiating the withdrawal on Base.
2. Making the relevant L2 state and an acceptable proof or checkpoint available on L1.
3. Proving the withdrawal’s inclusion through the bridge system.
4. Satisfying the applicable proof-maturity, game-finalization, and other protocol conditions.
5. Finalizing the withdrawal on Ethereum.

The current Base proof-delay and withdrawal configuration documents game-finalization windows of five days for one proof or one day for two proofs.

Those are protocol windows, not a guarantee that every withdrawal finishes exactly one or five days after the initial L2 transaction.

End-to-end timing also depends on proof and checkpoint availability, the accepted game type, the relevant maturity conditions, and completion of the required L1 transactions.

Historically, Base’s canonical optimistic withdrawal path was commonly described as taking roughly seven days. That remains useful background, but it should not be hard-coded into a current Base integration.

If a user needs an exit faster than the applicable canonical path, a liquidity-based bridge may be an option.

The interface should make clear:

• Who supplies the liquidity.
• What fee the provider charges.
• Which token the user receives.
• Which network the user receives it on.
• What happens if the bridge or relayer is unavailable.

A bridge is not merely a button connecting two wallet balances. It is another financial and security system.

When Base Makes Practical Sense

Base can be attractive for consumer applications and payments when its users, assets, wallets, and distribution channels fit the product.

Its ecosystem has a strong end-user orientation, but that alone is not a reason to deploy there.

The useful questions are whether the customer already has:

• A wallet that supports Base.
• ETH for gas or access to sponsored transactions.
• The required tokens on Base.
• An appropriate fiat on-ramp.
• A reason to remain in the ecosystem after the first transaction.

Suppose a customer must acquire an asset on another chain, bridge it to Base, obtain ETH for gas, and only then complete the product’s basic action.

A low nominal transaction fee has not solved that onboarding problem.

When I assess a payments product, I look at the entire funding and settlement journey, not just the cheapest step in the middle.

A Practical Base Use Case: Stablecoin Checkout

A reliable stablecoin checkout verifies a specific token transfer on a specific chain, then credits the payment under an explicit confirmation policy.

Imagine a SaaS application issuing an invoice and accepting a stablecoin on Base.

The checkout displays:

Amount: 50 USDC
Network: Base
Recipient: 0x...
Payment deadline: 15 minutes

The backend should not search for any event associated with a token calling itself USDC.

It should verify:

• The chain ID is 8453.
• The event emitter is the exact allowlisted token contract.
• The event is the expected ERC-20 Transfer.
• The recipient is the expected address.
• The raw amount matches the invoice.
• The transaction succeeded.
• The log belongs to the canonical block being tracked.
• The payment has not already been processed.
• The required confirmation threshold has been reached.

The amount must be checked in raw token units, using the verified token’s decimals, not floating-point arithmetic or a token symbol.

For a verified six-decimal USDC contract, for example, 50 USDC corresponds to 50,000,000 raw units.

The application also needs an unambiguous way to match transfers to invoices. Two customers paying the same amount to the same address at the same time should not produce an accounting guessing game.

An event model might look like this:

type TokenPayment = {
    chainId: number;
    transactionHash: `0x${string}`;
    logIndex: number;
    blockNumber: bigint;
    blockHash: `0x${string}`;
    tokenAddress: `0x${string}`;
    sender: `0x${string}`;
    recipient: `0x${string}`;
    rawAmount: bigint;
};

The unique event key should include at least:

chain_id + transaction_hash + log_index

A transaction hash alone is not a complete global identifier for a system supporting multiple networks.

It also identifies a transaction, not necessarily one payment event within that transaction.

Ledger posting must be idempotent. If a worker receives the same event twice, the customer must not be credited twice.

A typical workflow is:

1. A WebSocket subscription reports a new event quickly.
2. A worker retrieves the transaction receipt through RPC.
3. It verifies the chain, token, recipient, and amount.
4. It stores the event under a unique identifier.
5. It waits for the confirmation threshold defined by business policy.
6. It updates the invoice status and internal ledger within the same database transaction.
7. A periodic reconciliation job checks the recorded payments against blockchain data.

The backend also needs a way to handle removed or orphaned events. Keeping the block hash is useful, but simply storing it does not make the payment reorganization-safe. The system must actually recheck canonicality and manage provisional records appropriately.

The invoice deadline needs a policy, too. A payment included before the deadline may reach the required finality level afterward. That should not accidentally become a late payment just because the reconciliation worker ran later.

WebSockets improve responsiveness. They are not the final source of accounting truth.

In banking, reconciliation is not optional. Moving the payment rail on-chain does not change that principle.

The Base Trade-Off

Base combines familiar EVM development with an end-user-oriented ecosystem and fast transaction feedback, but its current protocol needs to be evaluated on its own terms.

Flashblocks can make a meaningful difference to applications sensitive to perceived latency.

At the same time, developers need to distinguish:

• Flashblocks preconfirmation.
• Ordinary L2 inclusion.
• Safe state derived from L1 data.
• Finalized state.
• Base from OP Mainnet.
• Natively issued assets from bridged representations.
• Canonical exits from liquidity-based bridge transfers.
• Current proof and withdrawal rules from older seven-day assumptions.

Base is not a centralized database simply because Coinbase helped create it.

It is also not independent of the operational, upgrade, and governance decisions made by its key participants.

A useful threat model accounts for both facts.

Arbitrum vs. Optimism vs. Base: Side-by-Side Comparison

All three networks offer Ethereum-compatible execution, but their infrastructure and settlement differences matter more as an application moves beyond a basic contract deployment.

In many market conditions, all three can execute transactions at lower cost than performing the same activity directly on Ethereum L1.

That is their shared starting point, not their complete architecture.

Feature	Arbitrum One	OP Mainnet	Base
Mainnet chain ID	42161	10	8453
Testnet	Arbitrum Sepolia, 421614	OP Sepolia, 11155420	Base Sepolia, 84532
Native gas asset	ETH	ETH	ETH
Core architecture	Arbitrum Nitro	OP Stack	OP Stack-derived Base protocol with independent upgrades
L2 system layer	ArbOS and Nitro	OP Stack predeploys and derivation	Base-specific clients, configuration, and proof rules with OP Stack roots
Primary programming model	EVM and Solidity	EVM and Solidity	EVM and Solidity
Additional programming model	Stylus and Wasm languages; new activations paused at this review	No direct Stylus equivalent	No direct Stylus equivalent
Fast transaction signal	Sequencer confirmation	Subblock preconfirmation or unsafe L2 block	Flashblocks preconfirmation or ordinary L2 block
Stronger confirmation signal	L1-finalized batch data; separate assertion confirmation for L1 execution	Safe and finalized heads; separate bridge withdrawal requirements	Safe and finalized heads; separate current proof and withdrawal requirements
Canonical L2-to-L1 withdrawal	Optimistic flow, approximately seven days	Optimistic flow, approximately seven days	Proof-path-dependent; documented game windows of five days with one proof or one day with two
Main fee structure	L2 execution and L1 publication cost	L2 execution, L1 data, and configured operator fee	L2 execution, L1 data, and active network fee parameters
Distinctive developer topics	Nitro, ArbOS, retryable tickets, and Stylus	OP Stack, derivation, current client support, and Superchain standards	Base-specific upgrades, Flashblocks, proof configuration, and consumer infrastructure

The withdrawal entries are not guaranteed end-to-end completion times.

In particular, Base’s documented game windows should not be presented as a promise measured from the first L2 transaction. Arbitrum and OP Mainnet withdrawals can also take longer than their commonly quoted waiting periods.

Transaction-data finality and withdrawal eligibility are different milestones on all three networks.

Which Network Makes Sense for a DeFi Application?

For DeFi, start with the protocols, assets, and market depth the application needs, not the deployment fee.

A cheaper contract deployment offers little value if every user must bridge an asset or the target market lacks sufficient liquidity.

Arbitrum can be a logical choice when the application depends on existing Arbitrum DeFi protocols.

OP Mainnet may fit better when the required integrations are already there or when an OP Stack strategy matters.

Base may be the better fit when the relevant users and assets are already on Base.

I would evaluate actual dependencies rather than award one network a permanent “best for DeFi” label.

Which Network Makes Sense for a Consumer Application?

For a consumer application, onboarding and distribution may matter more than the differences between rollup implementations.

Important considerations include:

• Wallet onboarding.
• Gas sponsorship.
• Stablecoin availability.
• Fiat on-ramps.
• Application distribution.
• Interface responsiveness.
• Straightforward account recovery.

Base can be attractive because of its consumer ecosystem and Flashblocks infrastructure.

OP Mainnet also supports fast preconfirmation mechanisms, and other networks can deliver strong user experiences with the right wallet and account infrastructure.

None of those features removes the need to model finality correctly.

A smooth interface should hide unnecessary complexity, not erase the backend’s awareness of it.

Which Network Makes Sense for a Payment Backend?

For payments, the cheapest transfer is not necessarily the cheapest complete business workflow.

I would investigate:

• Which tokens customers actually hold.
• Whether the business accepts natively issued or bridged versions.
• The cost of treasury consolidation.
• How funds move to Ethereum or an exchange.
• RPC reliability.
• Reorganization handling.
• Which confirmation threshold triggers product delivery.
• Who pays gas.
• How the business handles payment on the wrong network.

Withdrawal timing matters because it affects working capital.

Bridge choice matters because it adds counterparties and operational dependencies.

Token identity matters because two assets with the same displayed symbol may not represent the same claim.

A payment backend needs to price the whole operation, not celebrate one inexpensive transaction.

What Changes If You Deploy on All Three Networks?

Multichain deployment expands reach, but it also creates separate production environments that can fail or diverge independently.

For every supported chain, a team needs to maintain:

• The deployment address.
• The deployment block.
• Administrative and upgrade configuration.
• A token allowlist.
• Oracle addresses.
• Primary RPC providers.
• Backup RPC providers.
• A block explorer.
• Bridge configuration.
• An indexer.
• Treasury balances.
• Alerts.
• Incident procedures.

I would also keep confirmation policies, fee-estimation adapters, and withdrawal-state handling explicitly chain-aware.

One Solidity repository does not mean one production application.

Three deployments create three sets of state that can diverge.

If business logic must remain consistent across them, the team needs an explicit cross-chain or off-chain coordination model. Deploying identical bytecode does not create shared storage, shared liquidity, or atomic execution across networks.

My Takeaway: Choose the System, Not Just the Gas Price

Arbitrum One, OP Mainnet, and Base address similar scaling problems, but they expose different operational and settlement models to an application.

Arbitrum One uses Nitro, ArbOS, retryable tickets, and its own rollup architecture. Stylus adds an interoperable Wasm programming environment, although new activations are restricted at this review.

OP Mainnet is a specific L2 running the OP Stack. Its defining developer concept is not merely EVM compatibility, but derivation: an independent node can reconstruct the chain from Ethereum data under the protocol’s rules.

Base has OP Stack roots but is a separate network with independent upgrades, its own state, its own operating infrastructure, and current proof and withdrawal rules that should not be copied from an older OP Mainnet explanation.

Flashblocks provide an early transaction signal. They do not make preconfirmation, L2 inclusion, L1-backed finality, and withdrawal eligibility the same event.

For a simple smart contract, changing networks may look straightforward. Update the chain configuration, RPC connection, and deployment address.

For a production application, the differences appear in:

• Fee accounting.
• Block and transaction statuses.
• Cross-chain messaging.
• Bridge workflows.
• Withdrawal waiting periods.
• System contracts.
• Event indexing.
• The backend’s risk decisions.

The most useful starting question is therefore not, “Which network has the lowest gas?”

I would begin with:

• Where are the users?
• Where are the required assets?
• Which protocols does the application depend on?
• How quickly must a result become usable?
• What level of finality does the business model require?
• How much network-specific infrastructure is the team prepared to maintain?

Once those answers are clear, the choice between Arbitrum One, OP Mainnet, and Base becomes much more practical.

The goal is not to select the cheapest-looking blockchain. It is to select the system whose costs, security assumptions, liquidity, and operating requirements fit the product.

---

Sponsored Partner: Volet.com

Looking for a simple, everyday way to buy, hold, and sell cryptocurrencies alongside your traditional currencies and payment cards?

• Read my full breakdown: Complete Volet Review on DoraMilen.com
• Get started right away: Open your free Volet account using my referral link