How to choose an Arbitrum development company in 2026

On July 1, 2026, Robinhood took Robinhood Chain into production, a dedicated chain built with Arbitrum technology. It did not start there: its Stock Tokens launched in 2025 on Arbitrum One, Arbitrum's public network, and the Arbitrum blog presents that path as the one it proposes to other projects: validate the product on Arbitrum One and move to a dedicated chain when it needs finer control. For a company considering Arbitrum development, the example is useful because it forces the question of which stage its project has reached.

The stage decides who you hire. A product team builds the application on Arbitrum One; an infrastructure provider configures and operates the dedicated chain, under a license that, outside Arbitrum One and Nova, gives the Arbitrum Foundation 10% of the protocol's net revenue, a cost a development quote does not include. This guide explains what changes at each stage, which criteria separate a complete proposal from one that leaves gaps and what to put in writing before signing. It is published by Metlabs, which also provides Arbitrum development services, so the publisher's commercial interest is direct; the technical data comes from Arbitrum's and Caldera's documentation, reviewed on November 8, 2026.

Two stages on Arbitrum: Arbitrum One and the dedicated chain

In the first stage, the application is deployed on Arbitrum One, a rollup that settles on Ethereum. The engagement resembles that of other products on an EVM-compatible network: contracts, wallet connections, backend and systems that consume transaction data. What is specific is cross-network movement, because the product has to represent deposits, withdrawals and pending operations that do not complete at the same pace. Our Arbitrum technology page covers the technical context.

In the second stage, a chain built with Arbitrum technology runs on the Nitro codebase and lets the team choose its data availability model (Rollup, AnyTrust or Alt-DA, each balancing cost and transparency differently) and use its own ERC-20 token for gas. The documentation now simply calls these Arbitrum chains; the Orbit brand name remains on provider pages. Each option adds a service someone has to provide: sequencing, nodes, bridges, upgrades and recovery.

Then there is the license. According to the Arbitrum Expansion Program documentation (AEP), chains deployed outside Arbitrum One and Arbitrum Nova pay the Arbitrum Foundation 10% of their Protocol Net Revenue, equivalent to the chain's profit (revenue minus costs). Robinhood Chain, which settles on Ethereum, falls under that arrangement, as the Arbitrum DAO factsheet records. For a budget, the consequence is direct: a dedicated chain carries a recurring cost tied to its revenue, on top of the cost of running it.

What sets a strong Arbitrum development team apart

Deploying contracts on Arbitrum One takes the same skills as on any other EVM-compatible network, so command of Solidity says little. The difference shows up in cross-network movement. A deposit from Ethereum and a withdrawal to Ethereum progress at different speeds, and the product has to show the user, support and accounting the same state at every moment. A team with real experience on the network describes those states without being asked and proposes how to test retries, interruptions and data recovery; one without it quotes contracts and interface and treats reconciliation as an integration detail.

The second criterion is whether the design anticipates the next stage. An application whose contracts do not hard-code the network and whose backend can rebuild its data off-chain reaches a dedicated chain with less work. When the product also runs on several EVM-compatible networks, each integration needs an owner and defined failure behavior, because a shared interface does not remove network differences or settle balance reconciliation. Specific experience is checked through authorized references from the people assigned to the project, not through a list of networks on the provider's website.

If the engagement includes the chain, the criterion changes in kind: the service continues after launch, and the proposal has to state who controls upgrade keys, who operates sequencing, what happens if a component stops responding and how the network recovers. It also has to include the AEP license in the chain's economic model where it applies. An offer to launch an Orbit chain that never mentions that 10% share has not yet done the calculation that matters to the client.

Metlabs: the application on Arbitrum One and its states

Metlabs is a blockchain development studio with offices in A Coruña and Madrid, Spain, that develops contracts and integrations for applications on Arbitrum One and other EVM-compatible networks, for companies whose operations depend on deposits, withdrawals and balances matching between the chain and their systems. Our in-house technical team connects product definition, architecture, smart contracts, backend and interface; the proposal identifies the components, people and responsibilities required for the chosen network.

Product decisions and integration scope

Our blockchain development approach starts with product rules and their relationship to existing systems. On Arbitrum One, that means specifying which actions need a signature, which data the backend interprets and which permissions administrators need, and stating from the outset whether the product might later move to a dedicated chain, because that possibility changes how contracts are configured and which data should be reconstructible outside the network.

Take a hypothetical business-to-business payments platform that receives stablecoins on Arbitrum One from Ethereum and other networks. Its users need to know when a deposit has started, when their balance becomes available and what to do if the process is interrupted; a withdrawal to Ethereum, moreover, does not complete instantly and has to appear as pending. Internal accounting and the application represent the same states, and testing covers retries and data recovery.

Acceptance scope brings together contracts, interface, integrations, transaction monitoring and deployment documentation. If the project anticipates a dedicated chain, its infrastructure provider and operational responsibilities are defined in a separate contract: commissioning the application does not make that team responsible for maintaining a chain.

When comparing our proposal, ask for named responsibilities, code access, verifiable milestones and maintenance terms, the same requirements that help assess another product team without confusing its work with that of an infrastructure provider.

What to include in the Metlabs proposal

• A deposit and withdrawal map defining the states shared by the app, backend and accounting system.
• A prototype for wallet connection, signing and pending transactions, including interruptions along the user journey.
• The contracts and integrations included in the quote, with retry and administrative permission tests.
• A production release plan naming network access providers, the owner of each dependency and the conditions for a possible move to a dedicated chain.

The work follows the phases described in our blockchain development service: discovery, architecture and design, iterative development, and validation before release. We agree on the first journey to build and its acceptance criteria at the start, so progress can be checked against a working delivery. External audits, specialist integrations and ongoing support are scoped in the proposal.

To discuss the scope with Metlabs, share the asset or process, its users, existing systems and the operations the first release must support. This gives the team a basis for identifying dependencies and preparing a proposal you can compare with those of other candidates.

Caldera: ecosystem infrastructure for the dedicated chain

Through its Rollup Engine, Caldera deploys and hosts dedicated rollups on Arbitrum Nitro, OP Bedrock or ZK Stack, on Ethereum or other networks. Its documentation lists options such as a custom gas token, alternative data availability, decentralized sequencing, guardian nodes and bridged USDC, and the company describes itself as a network of interconnected chains settling on Ethereum, with Metalayer as its interoperability layer. It is a managed infrastructure reference that complements the team building the application.

Because it is a managed service, assessment centers on what the client retains: agreed availability, access to data and nodes, ownership of keys and an exit procedure if it decides to change provider. Caldera's support for several stacks makes it possible to compare Nitro with other options within one provider. Its service covers the chain, not the application, so the budget also has to assign who adapts the product when chain conditions or external providers change.

Choosing an Arbitrum development company: you contract a stage, not a network

Asking a product team and an infrastructure provider for the same quote produces figures that cannot be compared, because the first builds the application and the second builds and operates a chain. What decides the choice is the stage the project has reached. If the product still has to prove usage, an application on Arbitrum One avoids the fixed cost of running a chain and the AEP license. If it already needs control over the gas token, transaction ordering or network access, a dedicated chain is justified and the infrastructure provider becomes a long-term relationship.

Robinhood's path also shows that the two stages connect. An application designed with a possible move in mind (configuration that does not hard-code the network, data the backend can reconstruct, user accounts that do not depend on one network) reaches the second stage with less work than one that did not plan for it. That foresight is what to ask the product team for in the first quote.

What to put in writing before commissioning Arbitrum work

A useful comparison separates the product from its supporting infrastructure. Each candidate identifies its deliverables and what it needs from other teams, with milestones that can be verified in the intended environment; assessing the team itself follows our general blockchain development company guide.

• Application: contracts, signing, deposit and withdrawal states, reconciliation and failure behavior.
• Dedicated chain, where required: stack, data availability, sequencing, bridges, gas token and upgrade permissions.
• Operations: monitoring, incidents, recovery, maintenance and responsibilities across providers.
• Budget: initial development, recurring infrastructure, the AEP license if the chain is deployed outside Arbitrum One and Nova, external reviews and handover terms.

On Arbitrum, the first document worth sending candidates is the answer to a question that comes before the technical specification: whether the product already needs its own chain.