The Optional Filter: Arbitrum's Elara Puts a Compliance Switch in the Chain Owner's Hand

With​‌​​​​‌‌​‌​​​​​‌​‌​​​​‌‌​‌​​‌​​​​‌​​​‌​‌​​‌‌​​‌​​​‌‌​‌​‌​​‌‌​‌‌​ ArbOS 61 — codenamed Elara, live on Arbitrum One and Nova since 20 August 2026 after a constitutional on-chain vote — Arbitrum shipped optional protocol-level compliance filtering for its dedicated chains, the app-specific networks operators stand up on the Arbitrum stack. New Sequencer and state-transition components can screen transactions that originate from, target, or otherwise involve restricted addresses. The relevant fact is not that it exists. It is where the control sits: on a dedicated chain, the screening is enabled and configured at the discretion of the chain owner — not ArbitrumDAO, and not the person transacting. The switch does not belong to the token, the vote, or the user. It belongs to whoever owns the chain.

This is not a leak or a rumor. It is documented in Arbitrum's own blog, in its chain-operator documentation, and in the constitutional proposal that shipped it. It is off by default, and explicitly not for Arbitrum One or Nova. What is not yet settled is reach — whether owner-held screening becomes the working default for dedicated chains that want regulated counterparties, or stays a rare and disclosed option. The mechanism is live. The open question is how far it travels.

• 20 Aug 2026, 17:00 UTC — ArbOS 61 "Elara" activates on Arbitrum One and Nova following a constitutional on-chain vote. The release adds optional protocol-level compliance filtering for dedicated chains built on the stack.
• The mechanism — a Sequencer filter simulates and rejects offending transactions before a block is built. The force-inclusion path, the Delayed Inbox, still runs — but for a listed address a Delayed Inbox Sentinel plus an on-chain Transaction Guardian precompile registers the restricted transaction so the state transition includes it and then fails it: gas spent, effect void. The usual "submit it yourself and wait out the sequencer" bypass stops producing a successful transaction for anyone on the list. Screening runs against salted sha256(salt || address) lists synced from S3, with event-level filters and burn-to-0x0 exceptions for protocols such as Aave, Paxos, and Morpho.
• The control — filtering is "at the discretion of the chain owner." The owner picks a screening provider (TRM, Chainalysis, and Elliptic are the cited examples), sets the address and event rules, and enables each component. On a dedicated chain this is not an ArbitrumDAO vote.
• What the DAO did keep — off by default; explicitly not for Arbitrum One or Nova; enablement is an ArbOwner action the owner schedules via a filtering-start timestamp (setTransactionFilteringFrom), with a recommended waiting period after the release. Token-holders voted to ship the switch into the shared stack and to keep it off the main chains. They did not keep the flip on dedicated chains.
• Governance backdrop — priority fees on Arbitrum One remain off; enabling them is a separate constitutional vote. The debate the public follows is about fees. The lever that decides who may transact on the app-chains shipped in the same release, on different terms.

One switch, and the question of who holds it. Trace the rungs on a dedicated chain running the filter.

• The user. Transacts on the chain. Does not hold the filter, cannot toggle it, and — if the chain screens — is rejected before inclusion. Route through force-inclusion and a listed address's transaction is included, then failed by the guardian: the bypass that normally survives a censoring sequencer does not survive for anyone on the list. The only refusal available is not to use the chain.
• ArbitrumDAO. Voted, through a constitutional proposal, to ship the switch into the shared stack and to keep it off on One and Nova. What it did not retain is the flip: on a dedicated chain, enabling the filter is defined as the owner's call, outside the DAO's remit. The DAO built the lever and disclaimed the hand on it.
• The chain owner. Holds the switch. An address — an EOA, a multisig, or a chain-level governance system — that selects the provider, writes the lists, and enables each component at its discretion. Not ArbitrumDAO; not the user. Whoever it is, the person transacting on that chain did not consent and cannot exit at sign-time.
• The stack. Arbitrum ships the capability, off by default, and hands every dedicated-chain owner the ability to flip it. It need not operate a single filter to have moved the ecosystem: screening is now a native, supported, provider-pluggable switch.

• Why "optional" is the mechanism, not the mitigation. A capability shipped as opt-in is a capability that exists. Optionality does not limit capture — it launders it. It moves the decision from a contested public mandate to a quiet per-chain toggle, and lets adoption follow incentives instead of votes. The operator who needs an institutional counterparty enables it; then the screened chain becomes the one that clears compliance; then screening is what a serious chain does. The toggle is opt-in exactly once.
• The layer, named — and the exception neutralized. Screening at the inclusion layer is not user choice, and Elara neutralizes the one path that looked like an escape. A screening chain's sequencer rejects the transaction before the block; and because a listed address's force-included transaction is included and then failed by the Transaction Guardian, the "submit it yourself" fallback produces no successful transaction for anyone on the list. If the chain you transact on screens, your consent was never in the loop. This is the sequencer / inclusion layer — the layer the decentralization narrative is built to keep you from looking at.
• The pattern, not the protocol. This desk mapped the issuer chokepoint: an issuer that can freeze a balance one rung up, whatever wrapper sits on top — on-chain dollars were never bearer. Elara is the same shape of off-switch, relocated: there the control point was redemption and the holder was the issuer; here it is inclusion and the holder is the chain owner. Not the same lever — the same architecture of one, pushed down from the asset to the transaction.
• What the DAO kept, and what it gave away. Governance theater usually works by directing attention; this is a subtler variant, because the DAO did vote. It voted to build the switch, to keep it off Arbitrum One and Nova, and to place the on/off for dedicated chains outside its own remit. The token-holders' say was exercised to ship the lever and disclaim it. A vote to build a switch you will not hold is still a vote — for the switch. The substrate is where the conditions get written — and this condition was written into the stack, then handed down.

• Sort chains by whether a screen sits above your transactions. A permissionless base layer includes what is valid. A dedicated chain with owner-controlled screening includes what the owner permits. Those are different assets wearing the same wallet UI. Know which one you are settling on.
• Price the capability, not the current toggle state. "Optional" and "off by default" describe today's setting, not tomorrow's. The relevant question is who can flip it, not who has. On a dedicated chain, that is the owner — unilaterally, on a schedule the owner sets, without a token-holder vote.
• The exit is chain choice, upstream of the transaction. Once you are on a screening chain, mitigation is not available at the transaction layer — Elara voids a listed address's force-included transaction. It was foreclosed at the chain-selection layer. Censorship-mitigation structures live in where you settle, not in how you sign.
• Read the toggle as a fork line. This is the compliance / sovereignty bifurcation arriving inside a single stack: the same technology, one switch apart, splitting into a permissioned surface and a permissionless one. The switch is where the line is drawn.

The mechanism is not the open question. It shipped, documented, on 20 August. The app-chain thesis Arbitrum champions now carries a second face: the proliferation of dedicated chains, sold as scaling and sovereignty, becomes a fleet of individually permissionable venues, each with a compliance switch its users do not hold and ArbitrumDAO does not control. The chokepoint does not need to be central if it is available everywhere, one toggle deep, off by default until an owner decides otherwise.

So the open question is reach, not existence. What would confirm the capture read: screening becomes the working default for dedicated chains onboarding regulated counterparties; TRM and Chainalysis integrations ship as standard; off-by-default erodes into on-by-expectation. What would refute it: screening stays rare and disclosed, permissionless dedicated chains remain first-class rather than second-tier, and owners that are themselves governance systems keep the switch under a vote rather than a single key. As of today the switch exists, it is live, and the dedicated-chain owner holds it. That the institution's chain will flip it is likely. That every chain must is not yet written.

Not the mandate. The toggle.