Overview of Arbitrum chains
An Arbitrum chain gives you the flexibility and control enterprises actually want—without the burden of running your own Layer 1. Instead of bootstrapping and subsidizing a validator set (a fixed cost that runs into the billions annually across major L1s), your chain anchors its security and finality to Ethereum's nearly 1 million validators and $78B in staked ETH, turning security into a variable, usage-based expense.
That economic model is the core reason to choose Arbitrum: your business captures the fee revenue and priority-access value that L1s hand off to validators, achieving 90–98% operating margins because costs scale with usage rather than perpetual subsidies. You also control the economics directly—custom gas tokens, fee policy, and revenue capture—while getting institution-grade settlement: sub-second soft finality for a responsive user experience, configurable hard finality on Ethereum in minutes, and native withdrawals in as little as 15 minutes, backed by a clean, externally legible counterparty-risk story for your risk, audit, and compliance stakeholders.
Beyond economics, an Arbitrum chain lets you launch fast and customize deeply while offloading the operational complexity of running blockchain infrastructure. You get day-one configuration over high, fully tunable throughput and block times (as low as 100ms), data availability (Rollup, AnyTrust, or external DA), sequencing and MEV rules, KYC/AML and permissioning, privacy, precompiles, governance, and multi-prover settlement—and you automatically inherit every future Ethereum and Arbitrum upgrade, including Stylus, without custom engineering.
Critically, your chain isn't siloed: it plugs directly into Ethereum's deep liquidity and the Arbitrum ecosystem (Arbitrum One alone secures over $16B with 1,000+ apps and millions of users). And you can de-risk your go-to-market with a phased "launch-and-migrate" path—prove your product on the shared, liquid Arbitrum One, then graduate to your own dedicated Arbitrum chain as a seamless continuation on the same stack, not a costly replatforming.
Customization
Speed and finality
Set confirmation speed and settlement behavior for products where timing and certainty matter—payments, trading, treasury, and internal asset movement.
| Feature | Your benefit | User benefit | Guide |
|---|---|---|---|
| Tune block time | You own the speed-versus-cost tradeoff. Faster blocks let you position the chain as a premium, low-latency venue (trading, gaming, payments) without waiting on a third party to change infrastructure. | Near-instant confirmations make the app feel like a familiar web experience rather than a slow onchain one, reducing the “did my transaction go through?” hesitation. | Configure chain finality |
| Configure delayed inbox and finality for deposits/withdrawals | You match certainty guarantees to your actual risk profile instead of over-provisioning, so you avoid paying for stronger finality than your product needs. | Predictable, well-defined settlement means users know exactly when funds and actions are final—important for anyone moving real value. | Configure chain finality |
| Enable fast withdrawals to reduce withdrawal finality time | Fewer support tickets and complaints about locked-up capital, and a more competitive bridging story when users compare your chain to alternatives. | Users get their funds in minutes instead of waiting the full challenge window, dramatically lowering the friction of exiting the chain. | Fast withdrawals |
Transaction pricing model
Align costs with your business model, including the option to use a custom gas token that fits customer experience, treasury strategy, or internal accounting needs.
| Feature | Your benefit | User benefit | Guide |
|---|---|---|---|
| Use a custom ERC-20 as the native gas token | You can drive utility to your own token, align fee revenue with your treasury strategy, and simplify internal accounting by denominating gas in the unit you already track. | Users pay fees in a familiar or branded token rather than acquiring a separate asset, removing a common onboarding hurdle. | - Custom gas token (Rollup) - Custom gas token (AnyTrust) |
| Manage the fee parameters that govern what uses pay and fee distribution | Direct control over cost recovery and revenue, so you can tune the chain's economics to be self-sustaining or subsidized as your business model requires. | Transparent, deliberately set fees rather than opaque or volatile costs, which builds trust in the pricing. | Fee management |
| Configure native mint/burn behavior for the gas token, and tune dynamic pricing | Automating supply and fee handling protects your margins during demand swings and reduces manual treasury operations. | More stable, predictable costs even when the network is busy, so users aren't surprised by fee spikes. | - Native mint and burn - Dynamic pricing |
Throughput and latency
Handle higher volumes and faster response times for products that cannot degrade during periods of peak demand.
| Feature | Your benefit | User benefit | Guide |
|---|---|---|---|
| Reserve dedicated throughput so your chain does not compete for computation and storage resources | Guaranteed capacity means you can make performance commitments (effectively an SLA) to partners and customers without worrying about noisy-neighbor contention. | Consistent performance during peak events—launches, drops, market volatility—instead of degraded speed exactly when demand is highest. | Launch overview (dedicated throughput) |
| Set the gas target and block gas limit to match your expected load | You right-size capacity to your cost budget and build in headroom for growth, avoiding both overspend and under-provisioning. | Fewer failed or delayed transactions at peak, because the chain has enough room to absorb bursts. | Gas target guidance |
| Tune the block time and gas trade-offs for your performance profile | You optimize the cost-versus-speed balance for your specific workload rather than accepting a one-size-fits-all default. | A responsive app that stays fast without passing along unnecessary fee increases. | Dynamic pricing |
Compliance and privacy
Create participation rules and data access controls that align with regulated workflows and protect sensitive information.
| Feature | Your benefit | User benefit | Guide |
|---|---|---|---|
| Run permissioned validators to vet and restrict who participates in validation—useful for enterprise or regulated environments (for example, KYC for validators) | You can meet regulatory and legal requirements, reduce compliance risk, and make the chain viable for enterprise and institutional partners who can't operate on a fully open infrastructure. | Assurance that the chain operates within a vetted, accountable set of participants — a prerequisite for many regulated financial and enterprise products. | Validation and BoLD |
| Restrict who can read chain data by keeping data off the public L1 with an AnyTrust data availability committee | You keep sensitive business and user data out of a fully public ledger, satisfying privacy obligations and protecting competitive information. | Greater confidentiality around their activity and data than a fully public chain would offer. | Configure data availability |
| Move to permissionless validation later via BoLD when you are ready to decentralize | You can launch with tight control and decentralize on your own timeline — no re-platforming required as your product and risk tolerance mature. | A credible path to stronger trustlessness and censorship resistance over time, rather than being locked into a permissioned model forever. | Validation and BoLD |
Transaction sequencing
Customize transaction ordering to match your product, whether the priority is wider access, lower MEV exposure, or tighter handling of transaction flow.
| Feature | Your benefit | User benefit | Guide |
|---|---|---|---|
| Keep the default First-Come, First-Serve (FCFS) ordering, which protects users from front-running and sandwich MEV | Fair, simple ordering keeps fast block times and avoids the reputational cost of a chain seen as hostile to ordinary users. | Built-in protection from front-running and sandwich attacks, so users aren't quietly taxed by MEV extractors on every trade. | How the Sequencer works |
| Enable Timeboost to auction an express lane, letting the chain owner capture MEV while preserving fair ordering for everyone else | You capture MEV as a revenue stream for the chain rather than leaking it to external searchers. | Non-express transactions keep their fair-ordering protections, while users who genuinely need priority have a transparent way to pay for it. | Timeboost configuration |
Governance and data availability
Choose how the chain is upgraded, administered, and backed by data availability based on the balance of cost, transparency, and resilience you need.
| Feature | Your benefit | User benefit | Guide |
|---|---|---|---|
| Define the chain-owner role and access controls that govern upgrades and administration, and plan a path toward progressive decentralization | You retain the control needed for upgrades and incident response early on, then deliberately decentralize as the chain matures—balancing agility with credibility. | Clear accountability for who can change the chain, plus a visible path toward stronger, more decentralized guarantees. | Ownership and access control |
| Choose your data availability model—Rollup, AnyTrust, Alt-DA—to trade off cost against transparency and resilience | You dial the cost-versus-security balance directly; AnyTrust can cut data costs substantially, while Rollup maximizes security and transparency. | Lower fees when you choose AnyTrust, or maximum security and Ethereum-grade transparency when you choose Rollup—matched to what your product actually needs. | Configure data availability |
Performance
On an Arbitrum chain, performance isn’t a single parameter—it’s the combined result of a few independent levers. Each trades one property against another (speed vs. infrastructure load, throughput vs. node stability, settlement speed vs. security), and you tune them to fit your product’s risk tolerance and demand profile. There are four primary parameters to configure, and language support capability is automatically included (no configuration needed).
Latency
How fast blocks are produced. Set the block time (250ms default, 100ms opt-in). Lower is snappier for users but heavier on nodes, indexers, and providers.
| Feature | Your benefit | User benefit | Guides |
|---|---|---|---|
| Block time | Dial block time down to 100ms for a snappier chain, or keep the 250ms default to reduce load on node runners, indexers, and third-party providers — a direct throughput/infra trade-off you control. | Near-instant feedback on payments, transfers, and redemptions, with confirmations landing in a fraction of a second. | Sequencer timing adjustments |
Throughput
How much the chain can process. Set the gas target and block gas limit to raise the TPS ceiling, weighed against the risk of node lag or halting.
| Feature | Your benefit | User benefit | Guides |
|---|---|---|---|
| - Gas target - Block gas limit | Raise the gas target and block gas limit to lift the chain’s throughput ceiling for high-volume workflows—weighed against the documented risk of node lag or halting if demand outruns validator resources. | Headroom to keep transactions moving during busy periods, so apps stay responsive under peak demand instead of congesting. | - Gas target - Gas optimization |
Finality and settlement
How quickly transactions become final and withdrawable. Set the Delayed Inbox finality, the challenge period, and fast withdrawals to balance settlement speed against re-org and security risk.
| Feature | Your benefit | User benefit | Guides |
|---|---|---|---|
| Delayed inbox, fast withdrawals, challenge period | Delayed Inbox finality, challenge period, and fast withdrawals — to balance settlement speed against re-org and security risk for your risk, audit, and compliance stakeholders. | Faster, more predictable settlement: sub-second soft finality for responsiveness and quicker withdrawals back to the parent chain. | - Delayed inbox - Fast withdrawals - Challenge period |
Cost and fee stability
How predictable prices stay under load. Use Dynamic Pricing, fee management (base/surplus minimums), a gas price floor, and batch-poster fee tuning to smooth spikes and capture revenue.
| Feature | Your benefit | User benefit | Guides |
|---|---|---|---|
| - Dynamic pricing - Fee management - Gas price floor - Batch poster fee tuning | Shape fee economics directly — Dynamic Pricing (multiple gas targets), base/surplus fee minimums, a gas price floor, and batch-poster fee tuning — to smooth price spikes and capture revenue while costs scale with usage. | More stable, predictable transaction costs under load, avoiding sudden fee spikes during large payout runs or volatile periods. | - Dynamic pricing - Fee management - Gas optimization - Batch poster fee tuning |
Language support
Stylus is inherited by every Arbitrum chain. It allows developing smart contracts in languages your team may already be familiar with—instead of having to learn Solidity. Out of the box it will allow you to write performant contracts in Rust, C, C++ (and community-tier AssemblyScript) alongside Solidity, reusing mature libraries and keeping full EVM compatibility.
Compliance
Sanctioned-address screening at the protocol level
Protocol-level transaction filtering added to the Sequencer and STF, at the chain owner’s discretion.
| Owner benefit | User benefit | Guide |
|---|---|---|
| Enables filtering as a first-class protocol capability to opt into, rather than building and maintaining bespoke tooling, while retaining full discretion over whether to enable it. | Transactions are screened by the network itself, so protection doesn’t depend on any single app behaving correctly. | Compliance filtering |
Choose your screening provider (TRM Labs / Chainalysis)
| Owner benefit | User benefit | Guide |
|---|---|---|
| Can reuse an existing provider relationship and risk methodology rather than build screening in-house. | Screening reflects industry-standard sanctions data rather than ad hoc lists. | Compliance filtering |
Define restriction lists (address-level and event-level rules)
| Owner benefit | User benefit | Guide |
|---|---|---|
| Can tailor enforcement granularity to policy—addresses, events, or both. | Only the activity that the policy actually targets is blocked, reducing false positives. | Compliance filtering |
Restriction rules
| Owner benefit | User benefit | Guide |
|---|---|---|
| A ready-made menu of enforcement actions covering transfers, tokens, and opcodes. | Clearly scoped restrictions keep permitted activity available. | Compliance filtering |
Continuous monitoring (synchronization pipeline)
| Feature | Owner benefit | User benefit | Guide |
|---|---|---|---|
| Compliance filtering | The restricted set remains up to date without manual redeployment. | Newly sanctioned addresses are enforced promptly, improving protection. | Compliance filtering |
| CLI flags | Can tune update frequency and storage to their operational needs. | Timely list updates mean less exposure to recently restricted addresses. | CLI flags reference |
What problem do Arbitrum chains solve?
Arbitrum chains are dedicated chains built with Arbitrum technology. Teams can configure execution, fee models, governance, data availability, validation, and other chain parameters for their application or business requirements.
The Ethereum ecosystem is supported by a decentralized network of nodes that each run Ethereum's Layer 1 (L1) client software. Ethereum's block space is in high demand, so users are often stuck waiting for the network to become less congested (and thus, less expensive).
Arbitrum's protocols address this challenge by offloading some of the Ethereum network's heavy lifting to another decentralized network of nodes that support the Arbitrum stack (Arbitrum chains).
How do Arbitrum chains help the Ethereum ecosystem?
Arbitrum helps Ethereum move towards a multi-chain future. This is valuable for the following reasons:
| Value add | Description |
|---|---|
| Scalability | Multiple chains help overcome scaling bottlenecks by dividing activity into opt-in environments with separate resource management. |
| Flexible security models | Different chains can experiment with different security models, allowing for tradeoffs. For example: Arbitrum One and Arbitrum Nova are both L2 chains, with Arbitrum Nova giving developers the ability to optimize for lower fees. With Arbitrum chains, extending the technology and experimenting is easier than ever. |
| Flexible execution environments | Different chains can experiment with more-or-less restrictive execution environments. For example, although Arbitrum chains are fully EVM compatible, Arbitrum chains can restrict smart contract functionality to optimize for your project's needs. |
| Flexible governance | Arbitrum chains let you define your own governance protocols. |
Are Arbitrum chains the same thing as "app chains"?
It depends on your definition of "app chain". Arbitrum chains can be used as application-specific chains (often referred to as "app chains" or "appchains"). But they aren't just for apps. They're for hosting EVM-compatible smart contracts using self-managed infrastructure that isolates compute resources away from Arbitrum's public L2 chains based on your unique needs.
- You can use your Arbitrum chain to host the smart contracts that support one app, two apps, an ecosystem of apps, or no apps at all.
- You can use your Arbitrum chain to host a private, centralized service.
- Your Arbitrum chain can be special-purpose, general-purpose, and everything in-between.
- You could even build an app that uses multiple Arbitrum chains to support strange new forms of redundancy, high availability, and trustlessness.