Skip to main content

Arbitrum glossary

Active Validator​

A bonded Validator that makes disputable assertions to advance the state of an Arbitrum chain or to challenge the validity of others' assertions. (Not to be confused with the Sequencer.)

Address Alias​

An address deterministically generated from a parent chain contract address used on child chain to safely identify the source of an parent to child chain message.

Adjustment window​

Window during which the gas pricing algorithm measures the transaction backlog. For example, there can be a gas target of 10Mgas/s over 10 minutes. That means the price will only increase if the average demand is over 10Mgas/s for that 10 minute window.

Decentralized application​

A decentralized application typically consists of smart contracts as well as a user-interface for interacting with them. Note: In our documentation, "apps" and "decentralized applications" are used interchangeably.

Arb Token Bridge​

A series of contracts on an Arbitrum chain and its underlying chain that facilitate trustless movement of ERC-20 tokens between the two layers.

Arbified Token List​

A token list that conforms to Uniswap's token list specification; Arbified lists are generated by inputting externally maintained list (i.e., coinmarketcap's list) and outputting a list that includes all of the instances of token contracts on the Arbitrum chain bridged via the canonical Arb Token Bridge from tokens on the input list. (See code here.)

Arbitrum​

A suite of Ethereum child chain scaling technologies built with the Arbitrum Nitro tech stack that includes Arbitrum One (a live implementation of the Arbitrum Rollup Protocol) and Arbitrum Nova (a live implementation of the Arbitrum AnyTrust Protocol).

Arbitrum AnyTrust Chain​

An Arbitrum chain that implements the Arbitrum AnyTrust Protocol.

Arbitrum AnyTrust Protocol​

An Arbitrum protocol that manages data availability with a permissioned set of parties known as the Data Availability Committee (DAC). This protocol reduces transaction fees by introducing an additional trust assumption for data availability in lieu of Ethereum's Trustless data availability mechanism. Arbitrum Nova is an example of an AnyTrust chain; Arbitrum One is an alternative chain that implements the purely trustless (and more L1-gas intensive) Arbitrum Rollup Protocol.

Arbitrum Bridge UI​

Web application built and maintained by Offchain Labs for user-interactions with the Arb Token Bridge; visit it here.

Arbitrum chain​

A blockchain that runs on the Arbitrum protocol. Arbitrum chains are EVM compatible, and use an underlying EVM chain (e.g., Ethereum) for settlement and for succinct fraud-proofs (as needed). Arbitrum chains come in two forms: Arbitrum Rollup Chains and Arbitrum AnyTrust Chains.

Arbitrum Chains​

An Arbitrum chain is any chain that is built using the Arbitrum stack. Anyone can deploy an Arbitrum chain permissionlessly.

Arbitrum Classic​

Old Arbitrum stack that used custom virtual machine ("AVM"); no public Arbitrum chain uses the classic stack as of 8/31/2022 (they instead use Arbitrum Nitro.)

Arbitrum Full Node​

A party who keeps track of the state of an Arbitrum chain and receives remote procedure calls (RPCs) from clients. Analogous to a non-staking parent Ethereum node.

Arbitrum Nitro​

Current Arbitrum tech stack; runs a fork of Geth and uses WebAssembly as its underlying VM for fraud proofs.

Arbitrum Nova​

The first Arbitrum AnyTrust Chain running on Ethereum mainnet. Introduces cheaper transactions; great for gaming and social use-cases. Implements the Arbitrum AnyTrust Protocol, not the Arbitrum Rollup Protocol protocol. Governed by the Arbitrum DAO.

Arbitrum One​

The first Arbitrum Rollup Chain running on Ethereum mainnet. Great for decentralized finance and other use-cases that demand strong security guarantees. Governed by the Arbitrum DAO.

Arbitrum Rollup Chain​

An Arbitrum chain that implements the Arbitrum Rollup Protocol.

Arbitrum Rollup Protocol​

A trustless, permissionless Arbitrum protocol that uses its underlying base layer for data availability and inherits its security. This protocol is implemented by our Arbitrum One chain.

ArbOS​

Arbitrum's "operating system" that trustlessly handles system-level operations; includes the ability to emulate the EVM.

Assertion​

A bonded claim made by an Arbitrum Validator representing a claim about an Arbitrum chain's state. An Assertion may, e.g., propose a new assertion, or may be a step in a Challenge.

Assertions can have different states:

  • Proposed: When a validator submits an assertion
  • Challenged: If another validator disputes the assertion, an interactive fraud-proof initiates.
  • Confirmed: An assertion becomes final if no one challenges it within the dispute window (6.4 days).

Auction Contract​

A smart contract that handles the state, accounting of funds for bids, and various operations of the Timeboost auction. The contract is deployed on the target chain for which Timeboost is enabled.

Autonomous Auctioneer​

Offchain software that receives bids from Timeboost participants, processes and validates bids, and then posts the top valid bid (or top two valid bids in the case of a tie) to the Auction Contract to resolve the on going Timeboost auction. The autonomous auctioneer, for a given chain, is provisioned and deployed by an entity designated by the chain's owner.

Batch​

A group of Arbitrum transactions posted in a single transaction on the Underlying Chain into the Sequencer Inbox by the Sequencer.

Batch Poster​

The batch poster is an Externally Owned Account (EOA) controlled by the Sequencer. It is responsible for submitting the compressed transaction batches to the Sequencer Inbox contract on the parent chain.

Blockchain​

A distributed digital ledger that is used to record transactions and store data in a secure, transparent, and tamper-resistant way, notably in cryptocurrency protocols.

BLS Signature​

A cryptographic scheme that allows multiple signatures to be aggregated and compacted into one efficiently verifiable, constant-sized signature. Used in the Arbitrum AnyTrust Protocol for the Data Availability Committee (DAC)'s signatures.

BoLD​

Short for "Bounded Liquidity Delay"; latest version of the Arbitrum Challenge protocol designed to eliminate delay attack vectors (see here for more).

Bonder​

A Validator who deposits a bond (in Ether on Arbitrum One and Arbitrum Nova ) to vouch for a particular assertion in an Arbitrum Chain. A validator who bonds on a false assertion can expect to lose their bond. An honest bonder can recover their bond once the assertion they are bonded on has been confirmed. Also known as: staker

Bridge​

A set of smart contracts for sending Cross-chain messages between blockchains. Every Arbitrum chain includes a bridge to/from its Parent chain.

Chain Owner​

An entity (i.e., a smart contract) with affordance to carry out critical upgrades to an Arbitrum chain's core protocol; this includes upgrading protocol contracts, setting core system parameters, and adding and removing other chain owners.

Chain state​

A particular point in the history of an Arbitrum chain. A chain's state is determined by applying Arbitrum state-transition function to sequence of transactions (i.e., the chain's history).

Challenge​

When two bonders disagree about the correct verdict on an assertion, those bonders can be put in a challenge. The challenge is refereed by the contracts on the underlying chain. Eventually one bonder wins the challenge. The protocol guarantees that an honest party will always win a challenge; the loser forfeits their bond.

Challenge Period​

Window of time (one week on Arbitrum One) over which an Assertion can be challenged, and after which the assertion can be confirmed.

Challenge protocol​

The protocol by which assertions are submitted, disputed, and ultimately confirmed. The Challenge Protocol guarantees that only valid assertions will be confirmed provided that there is at least one honest active validator.

Child chain​

An Arbitrum Chain that settles to a Parent chain. For example, Arbitrum One and Arbitrum Nova are child chains of Ethereum.

Client​

A program running on a user's machine, often in the user's browser, that interacts with contracts on an Arbitrum chain and provides a user interface.

Commitment​

In the context of Arbitrum, commitments represents a part of a chain's history. Commitments are used during the fraud proof dispute resolution process, where validators create a Merkle commitment to the history between two assertions. This allows them to efficiently narrow down disagreements about the chain state by using Merkle proofs to specific blocks or states within that range(1).

Confirmation​

The decision by an Arbitrum chain to finalize an assertion as part of the chain's history. Once an assertion is confirmed its Child to parent chain Messages (e.g., withdrawals) can be executed.

Cross-chain message​

An action taken on some chain A which asynchronously initiates an additional action on chain B.

Custom Arb-Token​

Any child chain token contract registered to the Arb Token Bridge that isn't a standard arb-token (i.e., a token that uses any gateway other than the StandardERC20 gateway ).

Custom gateway​

Any Token Gateway that isn't the StandardERC20 gateway.

Data Availability Certificate​

Signed promise from a Data Availability Committee (DAC) attesting to the availability of a batch of data for an Arbitrum AnyTrust Chain.

Data Availability Committee (DAC)​

A permissioned set of parties responsible for enforcing data availability on a chain using the Arbitrum AnyTrust Protocol.

See Introducing AnyTrust Chains: Cheaper, Faster L2 Chains with Minimal Trust Assumptions to learn more.

Defensive Validator​

A Validator that watches an Arbitrum chain and takes action (i.e., bonds and challenges) only when and if an invalid Assertion occurs.

Delayed Inbox​

A contract that holds Parent chain initiated messages to be eventually included in the Sequencer Inbox. Inclusion of messages doesn't depend on the Sequencer.

Deterministic proving​

If challenged, state transitions are replayable and verified onchain.

To achieve this, Arbitrum compiles the State Transition Function (STF) into different formats:

  • Execution mode: Uses Go's native compiler for high-performance execution on validator nodes.

  • Proving mode: Compiles to WebAssembly (WASM), which transforms into WebAssembly for Arbitrum Virtual Machine (WAVM) for fraud-proof verification.

Dev-Tools Dashboard​

Web application built and maintained by Offchain Labs for developers and users to debug Arbitrum transactions; i.e., executing or checking the status of Cross-chain messages; visit it here.

Dissection​

A step in the Challenge protocol in which two challenging parties interactively narrow down their disagreement until they reach a One Step Proof.

Ethereum Wallet​

A software application used for transacting with the Ethereum Blockchain.

Execution claim​

A cryptographic commitment to the computed state.

Express Lane​

A component of Timeboost, the express lane is a special endpoint on the Sequencer that immediately sequences incoming, valid transactions signed by the current express lane controller.

Express Lane Controller​

An address, defined in the Auction Contract, that is granted the privilege to use the Express Lane. These privileges are granted after verifying that the incoming transactions were properly signed by the express lane controller, among other checks.

Externally Owned Accounts​

An externally owned account (EOA) is the account (public/private key pairs) that has a physical address location. Commonly referred to as a wallet, however, we distinguish an EOA from the user client software wallet.

Fast Exit / Liquidity Exit​

A means by which a user can bypass an Arbitrum chain's Challenge Period when withdrawing fungible assets (or more generally, executing some "fungible" child chain to parent chain operation); for trustless fast exits, a liquidity provider facilitates an atomic swap of the asset on a child chain directly to a parent chain.

First Come First Serve (FCFS)​

A type of Transaction Ordering Policy used by the sequencer in Arbitrum chains whereby incoming transactions are sequenced into a block in the order that the transactions arrived.

Force-Inclusion​

Censorship resistant path for including a message into an Arbitrum chain via the Delayed Inbox on its Parent chain; bypasses any Sequencer involvement.

Fraud proof​

The means by which an Active Validator proves to its underlying chain that an invalid state transition has taken place.

Gas Price Floor​

Protocol-enforced minimum gas price on an Arbitrum chain. These values can be found on the chain info page.

Gas target​

The target consumption rate for an Arbitrum chain. Arbitrum One and Arbitrum Nova. When gas usage exceeds this limit, fees rise. Read more in the gas and fees article.

Gateway Router​

Contracts in the Arb Token Bridge responsible for mapping tokens to their appropriate Token Gateway.

Generic-Custom Gateway​

A particular Custom gateway via which a parent chain token contract can be registered to a token contract deployed to a child chain. A useful alternative to the StandardERC20 gateway for projects that wish to control the address of their child chain token contract, maintain the child chain token contract upgradability, and for various other use-cases.

Geth​

An execution-layer client that defines the Ethereum state transition function and handles network-layer logic like transaction memory pooling. Arbitrum Nitro utilizes a fork of Geth to implement Arbitrum's state transition function.

Ink​

The equivalent of gas in the Stylus vm. Ink is introduced for finer granularity than gas offers since Stylus's operations are considerably cheaper than their EVM analogs.

L1​

L1, or Layer 1, refers to the underlying blockchain responsible for maintaining the integrity of the distributed ledger. In the context of Arbitrum One and Nova, L1 is the main Ethereum blockchain (Mainnet), and Arbitrum operates as a Layer 2 scaling solution built on top of this base layer. However, any EVM-compatible blockchain can be an L1 to an Arbitrum chain.

L2​

An L2, or Layer 2, is a trustless scaling solution built on top of Ethereum's Layer 1 (L1) base protocol. Arbitrum is a Layer 2 protocol that increases scalability and reduces the cost of transactions on Ethereum's Layer 1 without introducing additional trust assumptions. It does that by executing some computation offchain and batch-posting transactions on the underlying Layer 1.

L2 Block​

Data structure that represents a group of L2 transactions (analogous to L1 blocks).

L2 to L1 Message​

A message initiated from within an Arbitrum chain to be eventually executed on Layer 1 (parent chain) (e.g., token or Ether withdrawals). On Rollup chains like Arbitrum One, the Challenge Period must pass before a child to parent chain message is executed.

Layer 1 (L1)​

The base protocol and underlying blockchain of the Ethereum network. Responsible for maintaining the integrity of the distributed ledger and executing smart contracts. Contains both Ethereum's execution layer and consensus layer.

Layer 2 (L2)​

Trustless scaling solutions built on top of Ethereum's Layer 1 (L1) base protocol, such as state channels, plasma chains, optimistic rollups, and ZK-rollups. Layer 2 solutions aim to increase scalability and reduce the cost of transactions on Ethereum's Layer 1 without introducing additional trust assumptions.

Layer 3 (L3)​

An Arbitrum chain whose core contract reside on an Arbitrum Layer 2 (L2) chain.

MultiVM​

MultiVM refers Arbitrum's ability to support multiple virtual machines (VMs). Specifically, Arbitrum Stylus introduces a WebAssembly (WASM)-based virtual machine alongside the traditional Ethereum Virtual Machine (EVM). This means developers can write smart contracts in languages like Rust, C, or C++ (compiled to WASM) or continue using Solidity for the EVM, and both types of contracts can interact seamlessly on the same chain. This approach preserves EVM compatibility while enabling more efficient execution and access to a broader set of programming languages and libraries(1)(2).

Native Fee Token​

An ERC-20 token used as the native currency for gas fees on an Arbitrum chain (i.e., as opposed to using Ether). Arbitrum chains introduced the option for chains to use native fee tokens.

Offchain Labs​

The initial builders Arbitrum; current contributors to the Arbitrum ecosystem and service providers to the Arbitrum DAO. Offchain also runs and maintains the Sequencers for Arbitrum One and Arbitrum Nova.

One Step Proof​

Final step in a challenge; a single operation of the Arbitrum VM (WASM ) is executed on the underlying chain, and the validity of its state transition is verified.

Oracle​

Oracles are third-party services that provide smart contracts with external information. They act as a bridge between blockchains and the outside world, which expands their functionality by enabling smart contracts to access data beyond their native networks.

Outbox​

A parent chain contract responsible for tracking Child to parent chain Messages, including withdrawals, which can be executed once they are confirmed. The outbox stores a Merkle Root of all outgoing messages.

Parent chain​

EVM compatible chain that acts as the settlement layer for one or more Arbitrum Chains (aka Child chain ). E.g., Ethereum is the parent chain of both Arbitrum One and Arbitrum Nova. Parent chain is synonymous with "underlying chain."

Permissionless validation​

Anyone can become a validator by running an Arbitrum node, without permission.

Portal​

A web application maintained by Offchain Labs showcasing the Arbitrum ecosystem; visit it here.

Precompile​

A precompile is a predefined smart contract with a special address that provides specific functionality executed natively by the Arbitrum client, rather than at the EVM bytecode level. Precompiles are used to introduce functions that would be computationally expensive if run in EVM bytecode, or to facilitate interactions between the parent and child chains. Arbitrum supports all Ethereum precompiles and also provides additional precompiles specific to Arbitrum chains, which can be called from smart contracts like regular Solidity functions(1).

Predecessor Assertion​

The last confirmed valid state of the chain.

raas​

RaaS (Rollup as a Service) is a platform that provides the necessary infrastructure and tools to deploy and operate blockchain Rollups, eliminating the need for teams to build the underlying technical infrastructure themselves. It typically includes pre-built Rollup software, node hosting, data availability solutions, and monitoring tools, allowing developers to focus on their application logic rather than the complex technical implementation of Rollup technology.

RBlock​

Refer to Assertion

Reorg​

A situation in which transactions on a chain that were at some point considered accepted then get rejected. In the context of an Arbitrum chain, once transactions are posted in the chain's Sequencer Inbox, the only way the chain can experience a reorg is if its Underlying Chain itself reorgs. Of note, Fraud proofs do not cause reorgs.

Retryable Autoredeem​

The "automatic" (i.e., requiring no additional user action) execution of a Retryable Ticket on an Arbitrum chain.

Retryable Redeem​

The execution of a Retryable Ticket on a child chain; can be automatic (see Retryable Autoredeem) or manual via a user-initiated child chain transaction.

Retryable Ticket​

A parent to child cross chain message initiated by a parent chain transaction sent to an Arbitrum chain for execution (e.g., a token deposit).

Reverse Token Gateway​

A Token Gateway in which the Child chain gateway contract escrows and releases tokens, which the Parent chain Gateway contract mints and burns tokens. This in the inverse to how "typical" gateways work.

Sequencer​

An entity (currently a single-party on Arbitrum One) given rights to reorder transactions in the Sequencer Inbox over a fixed window of time, who can thus give clients sub-blocktime Soft Confirmations. (Not to be confused with a Validator).

Sequencer Feed​

Offchain data feed published by the Sequencer which clients can subscribe to for Soft Confirmations of transactions before they are posted in batches.

Sequencer Inbox​

Contract that holds a sequence of messages sent by clients to an Arbitrum Chain; a message can be put into the Sequencer Inbox directly by the Sequencer or indirectly through the Delayed Inbox.

Shared Sequencing​

A protocol design space in which multiple rollups use the same entity as their Sequencer; potential benefits include enhanced interoperability and credible neutrality.

Smart Contract​

A computer program whose operations are defined and executed within a blockchain consensus protocol.

Soft Confirmation​

A semi-trusted promise from the Sequencer to post a user's transaction in the near future; soft-confirmations happen prior to posting on the Parent chain, and thus can be given near-instantaneously (i.e., faster than the parent chain's block times)

Standard Arb-Token​

An token contract on an Arbitrum chain deployed via the StandardERC20 gateway; offers basic ERC-20 functionality in addition to deposit / withdrawal affordances.

StandardERC20 gateway​

Token Gateway via which any underlying chain's ERC-20 token can permissionlessly bridge; the StandardERC20 gateway contracts deploy a Standard Arb-Token on the Child chain for each bridged token.

State Transition Function​

The STF (State Transition Function) defines how new blocks are produced from input messages (i.e., transactions) in an Arbitrum chain. The State Transition Function's output is the result of applying those input messages (transactions).

Stylus​

Upgrade to the Arbitrum Nitro virtual machine that allows smart contract support for languages like Rust and C++ by taking advantage of Nitro's use of WASM. Currently on testnet (read more).

Timeboost​

A transaction ordering policy in which entities can bid for the right to access an express lane on the Sequencer for faster transaction inclusion. See the research specification to learn more.

Token Gateway​

A pair of contracts in the token bridge — one on the Parent chain , one on the Child chain — that provide a particular mechanism for handling the transfer of tokens between layers. Token gateways currently active in the bridge include the StandardERC20 gateway , the Generic-Custom Gateway , and the WETH Gateway.

Transaction​

A user-initiated interaction with a Blockchain. Transactions are typically signed by users via wallets and are paid for via transaction fees.

Transaction Ordering Policy​

The rules and logic employed by a chain to order incoming transactions into a block.

Trustless​

In the context of Ethereum, trustless refers to the ability of a system to operate without reliance on a central authority or intermediary. Instead, users place their trust in math and protocols.

This is achieved through the use of cryptographic techniques and decentralized consensus mechanisms that let users verify the integrity of network transactions using open-source software. Trustless systems are considered to be more secure and resistant to fraud or tampering because they don't rely on a single point of failure that can be exploited by attackers.

Trustless verification​

Trustless verification​

Validators confirm assertions, ensuring transactions adhere to the protocol rules.

Underlying Chain​

Synonymous with Parent chain.

Validator​

An Arbitrum Full Node that tracks the status of the chains' Assertions. A validator may be a Watchtower Validator, a Defensive Validator, or an Active Validator.

Wallet​

When referring to a wallet, we mean the user client software enabling user actions. Often, client software is a browser extension, mobile, or desktop app. Also refer to Externally Owned Accounts.

WASM​

Widely supported binary code format for executable programs. Used by Arbitrum Nitro for Fraud proofs , and more broadly used by Stylus to support performant smart contracts in a wide variety of languages.

WASMer​

A popular WebAssembly runtime for executing WASM binaries. A fork of WASMer is used for executing Stylus programs. WASMer executes considerably faster than Geth executes EVM code, contributing to Stylus's lower fees.

Watchtower Validator​

A Validator that never bonds / never takes on chain action, who raises the alarm (by whatever offchain means it chooses) if it witnesses an invalid assertion.

WETH Gateway​

Token Gateway for handing the bridging of wrapped Ether (WETH). WETH is unwrapped on the parent chain and rewrapped on the parent chain upon depositing (and vice-versa upon withdrawing), ensuring WETH on the child chain always remains collateralized.