Skip to main content

Why choose permissioned validators for your Arbitrum chain

Choosing permissioned validators refers to configuring the chain to use a legacy dispute resolution protocol where only an allowlisted set of entities (e.g., approved by the chain owner or DAO) can participate in validation activities, such as posting state assertions, opening challenges, and resolving disputes. This contrasts with enabling the Bounded Liquidity Delay (BoLD) protocol for permissionless validation. The choice is made during chain deployment or via upgrades, often through governance, and prioritizes controlled oversight over broad decentralization. It's suitable for chains where limiting participants reduces operational complexity or economic risks, but it introduces trust assumptions in the allowlist.

Chain owners add/remove validators from the allowlist using tools like the Orbit SDK or precompiles, ensuring only trusted parties (e.g., the project's team or selected partners) can validate. For validation, this limits who can defend against invalid assertions, requiring the allowlisted group to monitor and respond actively. Disputes follow the legacy protocol, potentially leading to sequential challenges without time bounds. Security is maintained through fraud proofs but depends on the allowlist's honesty and availability—e.g., if validators collude or go offline, the chain could stall or face unaddressed fraud.

This choice is configurable for all DA modes (Rollup, AnyTrust, Alt-DA) and gas tokens, but it's often retained for low-TVL chains to avoid the high bonds needed in permissionless setups, which could centralize around wealthy participants.

Key Concepts​

  • Validation in Arbitrum: Validators monitor and advance the chain's state by posting assertions (claims about block hashes, history commitments, and inbox messages) to the parent chain (e.g., Ethereum or an L2 like Arbitrum One). If an assertion is suspected of being invalid, challengers initiate interactive fraud proofs during a challenge window (typically ~6.4 days), bisecting disagreements down to verifiable one-step proofs executed on-chain. Security relies on economic incentives, where invalid claims lead to bond forfeitures.
  • Permissioned Validators: Participation is restricted to a whitelist managed by the chain owner (via the ArbOwner precompile or DAO governance). Only these entities can stake bonds, post assertions, or engage in disputes. This setup uses the pre-BoLD fraud proof system, where challenges are handled in a 1-vs-1 tournament style without parallel resolution.

Compatibility with Chain Types​

Works with L2/L3 Arbitrum chains settling to Ethereum or other L2s. For AnyTrust chains (e.g., like Arbitrum Nova), validation typically remains permissioned even post-BoLD upgrades, as the Data Availability Committee (DAC) already introduces trust assumptions, and permissionless bonds could invite griefing attacks.

Pros​

  • Enhanced control and security in trusted environments: Permissioned validators allow the chain owner to select and vet participants, reducing risks from unknown or malicious actors, which is ideal for enterprise or private chains where trust among validators is present, minimizing the chance of spam or uncoordinated attacks.
  • Regulatory compliance and privacy: Easier to implement access controls, such as restricting who can read chain data or participate, which helps with legal requirements (e.g., KYC for validators) in regulated industries like finance.
  • Simpler setup and lower operational overhead: Without needing to support open participation, the chain can operate with fewer nodes, potentially leading to faster consensus, reduced complexity in dispute resolution, and lower costs for maintaining the network. Permissioned validation is beneficial for smaller or specialized Arbitrum chains focused on specific use cases.
  • Established and proven model: Permissioned validation mirrors the initial setup of chains like Arbitrum One, providing a reliable baseline without requiring additional protocols like BoLD for permissionless features.

Cons​

  • Vulnerability to delay attacks: In permissioned systems, malicious validators can exploit the challenge window by repeatedly posting false claims, forcing honest validators to spend resources on defenses and delaying confirmations or withdrawals. This potential exploitation could raise costs and risks of liveness issues.
  • Centralization risks: The system relies on a limited set of trusted validators; if they collude, fail, or are compromised, the integrity of the chain could be at risk. This centralization could make the chain less appealing to users who value trustlessness.
  • Limited robustness against adversaries: Unlike permissionless models, where any honest party can defend the chain, permissioned validation depends on the availability and honesty of the approved set. A single point of failure (e.g., if validators go offline) could halt progress.
  • Potentially for reduced adoption: Developers or users seeking Ethereum-like decentralization might prefer permissionless options, limiting the chain's appeal in open ecosystems. Enabling permissionless later (via BoLD) requires upgrades and community/DAO approval, adding complexity.

Examples​

  • Arbitrum Nova: Retains permissioned validation post-BoLD due to its lower TVL and AnyTrust model, where the DAC members double as validators for controlled security.
  • Custom Orbit Chains: Early-stage gaming or enterprise L3s might choose permissioned to limit access to internal teams, avoiding the economic overhead of BoLD while testing.

This option balances security with practicality in Arbitrum's ecosystem, but for maximum trust-minimization, BoLD's permissionless model is recommended for mature chains. Consult the latest official docs, or your RaaS; a list of RaaSes is on the Third-party providers page.