Why crypto applications use layer 2: the Arbitrum example

Why do many crypto applications run not directly on Ethereum but on layer 2 (L2) networks such as Arbitrum? In short: an L2 executes transactions outside the main network and writes compressed data to it in batches. As a result, transactions are cheaper, more of them can be processed and confirmation arrives faster.

The price is a set of additional assumptions. A sequencer determines the order of transactions, finality is not immediate, withdrawing funds back to Ethereum takes about a week and the rules of the network itself can change through a governance mechanism. Below we explain how this works and what it means for an application that, like Variational, has deployed its contracts on Arbitrum.

What a rollup is

A rollup is a network that executes transactions itself but publishes data about them to the main network (L1) and relies on it to establish which state is correct. In this setup, Ethereum serves as archive and arbiter: anyone can reconstruct the rollup's state from the published data.

There is also another class of rollups that attach zero-knowledge cryptographic proofs to their batches. This article covers only the optimistic model on which Arbitrum is built.

What an application gets from L2

The main argument for L2 is cost: block space on Ethereum is limited, and a rollup spreads the cost of publishing one batch across many transactions. According to ethereum.org, optimistic rollups publish data to Ethereum as calldata or in blobs. Blobs are cheaper, but, as ethereum.org notes, they are stored only briefly: network clients can delete them after about 18 days.

For an application, this adds up to three effects:

• Cost. Gas per transaction is lower than when executing directly on Ethereum. This makes setups in which the application operator pays gas on the user's behalf realistic.
• Throughput. Execution is moved off L1, so the bottleneck becomes data publication rather than computation in Ethereum blocks.
• Latency. According to the Arbitrum documentation, the Arbitrum sequencer issues a preliminary confirmation in under a second.

For applications with frequent operations, such as trading protocols where opening a position involves a collateral transfer, latency matters as much as cost. Specific fees depend on network load and are not given here.

How an optimistic rollup ensures correctness

An optimistic rollup relies not on checking every batch but on the ability to challenge it. If someone believes a published result is wrong, they open a dispute, and a contract on Ethereum resolves it.

As ethereum.org describes it, modern designs use interactive bisection of the dispute: the parties narrow their disagreement down to a single computation step, which the L1 contract executes itself, and the losing party forfeits its bond. This means one honest participant who monitors the network and is ready to challenge an incorrect batch is enough for protection.

The cost of this model is the challenge period. Ethereum.org puts it at about seven days, and a user withdrawing funds from the rollup to Ethereum through the standard bridge waits just as long. For Arbitrum One, as of October 2026, L2BEAT lists a challenge period of 6 days and 8 hours; if a claim is challenged, the period is extended.

The week-long delay should not be confused with transfers within the L2. Moving funds between addresses or contracts on Arbitrum itself is an ordinary rollup transaction; the delay applies to exiting to L1.

The sequencer: who decides the order

The sequencer accepts transactions, orders them and publishes the result. According to the Arbitrum documentation, it is responsible for ordering but not for the outcome of execution: execution is deterministic, and any node can reproduce it.

As of October 2026, Arbitrum runs a single logical sequencer: in production, this is several nodes, of which one leader is active. The Arbitrum documentation calls this setup centralized and describes a move to committee-based ordering as a long-term goal.

Soft and hard finality

A transaction on Arbitrum has two points of confirmation. Soft finality is reached when the sequencer has ordered the transaction and broadcast it in its data feed; as the documentation puts it, this is a preliminary confirmation that depends on the sequencer behaving honestly. Hard finality is reached when the batch containing the transaction is finalized on Ethereum.

For an application, this is a choice between speed and guarantees: it can act on the soft confirmation and rely on the sequencer, or wait for the hard one and accept the delay.

If the sequencer does not include a transaction

A centralized sequencer can refuse service or fail. For this case there is a fallback: a transaction can be sent to a contract on Ethereum, the delayed inbox. If the sequencer does not include it, once the delay expires it can be forcibly added to the chain using the forceInclusion method. As of October 2026, L2BEAT estimates this delay for Arbitrum One at “up to 1 day.”

In other words, as the mechanism is described, the sequencer can delay a transaction but cannot block it permanently.

Who can change the network's rules

Arbitrum One's contracts on Ethereum are upgradeable, and this is a second source of assumptions besides the sequencer. According to the independent resource L2BEAT, control over them belongs to the Arbitrum DAO — a decentralized organization through which decisions about the network are made — and the Security Council it elects. As of October 2026, L2BEAT classifies Arbitrum One as Stage 1. In its framework, this means users can exit the system even if operators act maliciously, but the Security Council retains “training wheels” powers.

Key details from L2BEAT's assessment as of the same date:

• The Security Council has 12 members.
• Emergency actions by the council require 9 of 12 signatures and take effect immediately. For this path, L2BEAT notes that users have no exit window.
• Regular upgrades go through delays: 8 days on L2 and 3 days on L1. Taking into account the forced transaction delay, L2BEAT calculates that users have 10 days to exit.
• Two conditions are missing for Stage 2: at least 30 days to exit for upgrades unrelated to provable on-chain bugs, and limiting the council's powers to such bugs.

L2BEAT separately cautions that stages do not reflect a project's level of security, and its page warns that some information may be outdated. The project timeline on L2BEAT records a bridge emergency upgrade on May 24, 2026. We could not reliably determine the reason for or details of this upgrade from the page, but the entry itself shows that emergency changes are not just a theoretical possibility.

Example: what “deployed on Arbitrum” means for Variational

For an application on L2, the network's properties become part of the product's properties. According to the Mainnet Contracts page, the Variational protocol's mainnet contracts — the treasury, the main OLP vault, the settlement pool factory and the oracle contract — are deployed on Arbitrum. The Partners page states that the protocol interacts with Arbitrum through RPC nodes from the providers Alchemy and QuickNode.

What follows from this:

• Trade confirmation is inherited from Arbitrum. Transferring collateral into a settlement pool is a rollup transaction with the same stages of soft and hard finality. The protocol overview describes a watcher component that checks transaction finalization but does not specify what level of confirmation it waits for. How settlement itself works is covered in “What happens in on-chain settlement: a trade's path from quote to ledger”.
• Gas. In the Omni application, according to the same page, the transactor component pays gas for user deposits and withdrawals. Low gas costs on L2 are one of the conditions under which such a setup makes sense; this is our interpretation, not a claim by the project.
• Infrastructure dependency. RPC providers are intermediaries between the protocol's servers and the network. An outage at a provider does not change the state of the blockchain but can make it harder to send and read transactions. The documentation does not describe how the protocol acts in that case.
• Network risks — the sequencer, upgrades, the delay in exiting to L1 — are part of the risk profile of any application on Arbitrum, regardless of the quality of its own code. Risk classes are covered in more detail in “DeFi protocol risks: from smart contracts to counterparties”.

Conclusion: two layers of risk instead of one

L2 networks solve cost and speed for applications by moving execution off Ethereum while leaving it the role of data store and arbiter. An optimistic rollup adds three kinds of assumptions: about the sequencer (until hard finality), about time (the challenge period and exit to L1) and about governance (who can upgrade the contracts and how quickly).

For an application on Arbitrum, including Variational, this means its risk profile has two layers: the properties of the protocol itself and the properties of the network underneath it. Assessments of the second layer, such as the L2BEAT stage or the length of delays, change over time, so such a characterization is meaningful only together with the date it was checked. On the application side, something else matters: which network confirmation it relies on when it shows the user a result — and for Variational, the documentation does not specify this.