Arbitrum's getting-started and overview pages describe a rollup: execution happens on Arbitrum, and Ethereum is the settlement layer the rollup argues with. Nitro is the name of the stack that makes that execution look like a compressed, compatible environment rather than a from-scratch virtual machine story. Why Nitro exists as its own page because the design changed from earlier Arbitrum versions and the change is part of the history.

ETH pays for gas on Arbitrum One and Nova, while ARB serves governance. Holding ARB alone does not supply a wallet's ordinary transaction fees there. Independently configured Arbitrum chains can make different choices, so the network and fee asset should be named together.

The deep dive and the why-Nitro page are the mechanism. They describe how Arbitrum batches transactions and how a node follows the chain. The node guide is the practical counterpart: someone outside the company can run software and see the chain, which is a different standard from trusting a status page.

Running a node does not let the operator rewrite Ethereum's record of the rollup. It lets them observe and, depending on the role, participate in the software the docs describe. A node is not a vote, and a vote is not a node. The docs keep those powers in different manuals.

Stylus is documented as a way to run other languages beside the EVM. That widens who can write contracts and can improve some workloads. It also widens the set of compilers and runtimes that can be wrong. A Rust program on Stylus is not safer than Solidity because it is Rust. It is safer only if this program, this compiler, and this bridge are actually sound.

The gentle introduction is the right tone. Stylus is an extension of Arbitrum, not a new settlement layer. Ethereum still sits where the overview says it sits. A new execution format does not move the bridge.

ARB supports voting within the DAO's documented scope, including treasury and protocol decisions. Those powers differ from ETH's use for transaction fees. Governance participation is not by itself a dividend or an ownership claim on Ethereum.

The forum is where proposals and objections live in public. A forum thread is evidence of a debate. A passed proposal is evidence of a decision under the DAO's rules. A blog post hoping the token will accrue fees is neither, until a proposal actually turns it into a rule.

Getting started is a user and developer path onto the rollup. Deposits and withdrawals are bridge operations with delays and failure modes written into rollup design. A centralized exchange that lists ARB, or that lets a customer hold 'Arbitrum ETH' inside the exchange, has not performed those operations on the user's behalf in any way the user can see.

The node overview matters for the same reason. If the only way to know the chain's state is a company's interface, the rollup's promise is unfinished. The docs claim a path to run software. Whether that path is usable is something a reader can try, which is better than taking the adjective decentralized at face value.

The DAO can fund programs, change parameters, and argue about upgrade power. Those actions are visible on the forum and in the foundation docs. Visibility is not wisdom. A passed vote can spend a treasury badly, and a rejected vote can block a repair. The point of citing the forum is to show the argument, not to bless its outcomes.

Nitro's design and the DAO's politics are different layers. A technical deep dive does not pass a proposal. A proposal does not rewrite the deep dive until an upgrade ships. This edition keeps the two citations in different sections on purpose.

Arbitrum One opened in 2021 and migrated to Nitro in 2022. The DAO transition added another task: deciding how to fund an operating foundation and scrutinize its authority.

During the April 2023 AIP-1 debate, Blockchain at Michigan criticized unclear disclosure around a 750 million ARB transfer and described the vote as retroactive ratification. The objection was about authority and process, not just the size of a grant. Public delegation creates a place to raise that objection, but an active forum by itself cannot establish whether a transfer was authorized or how a contract can be changed.

AIP-1.1 proposed a four-year lockup for the remaining allocation, a budget, and periodic reporting. Replies still disagreed: DisruptionJoe welcomed the disclosure, while others remained distrustful. The record shows a dispute and a response, not proof that every later governance problem was solved.

Builder culture has its own participation paths. The September 2024 Stylus launch invited developers using Rust and other WebAssembly-compatible languages, with showcases, workshops, and a proposed incentive program. Such activities can broaden who contributes software. They do not make ARB the fee asset on every Arbitrum-derived chain, and One, Nova, and independently configured Orbit chains should not be collapsed into one security profile.

The September 2026 L2BEAT assessment describes Arbitrum One as an optimistic rollup with Ethereum data availability and permissionless state proposals. It separately records centralized sequencing and an emergency Security Council path that can bypass ordinary upgrade delays. These are different dimensions of control. A user may be able to force inclusion through Ethereum while still depending on the correctness of upgrade authorities and proof contracts.

L2BEAT's Stage 1 designation recognizes specified protections, including its walkaway criterion; it is not a guarantee against bugs or a claim that every authority has disappeared. The assessment also identifies resource-exhaustion risk in the dispute system, making sufficient challenger resources an important qualification to permissionless access.

BoLD organizes disputes around competing claims about deterministic execution. Participants bond claims, divide disagreements into smaller segments and eventually isolate an instruction that can be checked on the parent chain. Parallel challenges are intended to prevent an adversary from extending uncertainty indefinitely by forcing a sequence of separate contests. This is a concrete answer to a protocol problem, not a promise that every ordinary user will personally run a challenger.

The protocol still needs an honest party with the capital, software and operational capacity to act within its rules. Running a full node to inspect state and posting a bonded assertion are therefore related but distinct forms of participation.

The current PGA documentation describes priority bidding through the ordinary EIP-1559 transaction field rather than a separate express-lane auction. The sequencer compares transactions in short rounds and increases the queue position of transactions left waiting, without increasing what those transactions are charged. On Arbitrum One the documented nominal block interval is 250 milliseconds, divided into two ordering rounds. This mechanism tries to combine paid priority with continued inclusion for lower-fee users. It remains a policy followed by a sequencer.

Opening the bidding mechanism does not create a decentralized committee or eliminate the need to trust the operator's handling of ordering.

L2BEAT records PGA replacing Timeboost on Arbitrum One on September 23, 2026, including the introduction of a paid Fast Feed. This dated observation is separate from the documentation's earlier activation plan.

The June 2026 governance discussion records why the old mechanism became contentious. Leyiang said the capital scale of dominant express-lane bidders made competition uneconomic and welcomed a change that might make returning worthwhile. MconnectDAO raised a different concern about ordering risks. Offchain's response emphasized that the sequencer mempool would remain private, so the proposal should not be equated with exposing every pending transaction publicly. These are participants' positions in a design debate, not an independently measured verdict on every trade.

The discussion makes accessibility, operator behavior and revenue capture separate questions rather than assuming that an auction automatically resolves all three.

The August 20 Elara announcement distinguishes platform options from changes enabled on Arbitrum One. Dedicated chains receive configurable compliance filtering and additional data-availability interfaces; those capabilities should not be read as evidence that One adopted each chain owner's preferred restrictions. On One, the announcement describes bounded base-fee adjustment authority and larger Stylus contract capacity. It also warns that contracts using the removed WebAssembly multi-value extension cannot be activated or reactivated.

That compatibility detail matters more to a builder than a generic throughput slogan. Elara supplied a prerequisite for later priority-fee collection, while enabling that collection on One required a separate governance process. Software capability and network activation remain distinct events.

Daniel Lumi's August ZK update is an engineering progress report rather than an announcement that One has abandoned optimistic settlement. It describes proving real blocks and Stylus execution, a standalone Rust validator, and integration work intended to add faster confirmation alongside BoLD. It also names unfinished work on cost, inbox verification and node configuration, and says upgrading One would require a DAO proposal. That distinction prevents a roadmap from becoming a false withdrawal promise.

A proof generated during development demonstrates a capability under its tested conditions; it does not establish that the deployed bridge accepts that proof as its final settlement rule or that every user can already withdraw on the proposed faster schedule.

The Security Council's May 24, 2026 report describes an emergency mitigation for a governance denial-of-service vulnerability. A cross-chain message could make the bridge renounce a role needed to submit constitutional upgrades to the L1 timelock. The published response blocked the specific payload and linked the executed Ethereum transaction. The Council states that funds were not at risk; this should not be retold as a theft or a compromise of user balances. It is nevertheless a meaningful control event.

The same institution entrusted to bypass ordinary delays intervened to preserve the DAO's ability to execute upgrades, demonstrating both the purpose of emergency authority and the importance of a public account of its use.

The February pricing explanation separates an implemented fee-control change from the broader ambition of resource-aware pricing. Dia introduced multiple gas targets and adjustment windows, together with accounting for categories such as computation and state growth. At that checkpoint, the complete dynamic model had not been switched on. The design aims to let prices reflect actual bottlenecks without overwhelming node operators. This is a more precise scaling objective than an unconditional claim that cheaper fees always mean more usable capacity.

Measuring resources, benchmarking clients and choosing limits are operating tasks. The article's expected benefits should be tested against observed workloads, and its staged roadmap should not be read as proof that all later constraints were already active in January.

Entropy's DRIP retrospective reports the first season ending on February 18, 2026 and describes how the program tried to distinguish Arbitrum-specific lending growth from broader market movements. Its adjusted cost-effectiveness metric is a method chosen by the program's operators, not an experiment that independently proves every observed dollar was caused by an incentive. The report also identifies compressed timing and protocol constraints as weaknesses. These admissions matter to a community deciding whether grants create lasting activity.

Historical reward windows and allocations do not establish that a campaign is still open. The stated goal was to accelerate viable markets, while leveraged participants could still lose money despite receiving ARB rewards.

Camelot's March 2025 voting explanation brings the application builder's interest into that treasury debate. The delegate wanted risk-conscious allocations to include more native Arbitrum protocols and explicitly disclosed its own position as a selected participant. It also abstained on Timeboost while requesting better evidence about effects on protocols, rather than evaluating DAO income alone. That is a recognizable form of ecosystem loyalty with a commercial stake: the chain's financial decisions should account for the applications contributing to its use.

Disclosure helps readers assess the argument, but it does not establish that any favored protocol deserves an allocation regardless of risk.

The 2024 staking discussion contains a substantive disagreement over participation. Entropy questioned whether subsidized liquid staking would improve governance or encourage concentrated and leveraged voting positions. Tally contributors, including dennison, countered that simply assigning treasury votes to existing delegates could entrench unaccountable power. Both positions sought a stronger DAO, but they disagreed about the route. This historical exchange does not create a current entitlement to staking income.

It shows why a token holder's hope for rewards must be separated from an adopted funding source, functioning contracts and the governance consequences of whatever receipt token or delegation mechanism is proposed.

In the maintenance working-group thread, vijaym1 described a small application's difficulty securing a custom gateway integration, while cupojoseph volunteered technical help and argued that routine changes should not consume full constitutional procedures. JoJo wanted clearer security checks rather than simply faster approvals. These original accounts reveal a builder motive that is easy to miss in price discussion: dependable processes can matter as much as low transaction fees. The working group was an attempt to reconcile speed with DAO oversight.

Its proposed councils, veto rules and timelines are design proposals within that discussion, not evidence that every suggested shortcut became the network's current administrative procedure.