Summary Value Secured Activity Onchain costs Liveness Risk summary Risk analysis Data availability State validation Operator Sequencing Withdrawals Other considerations Permissions Smart contracts

Powerloom

Badges

About

Powerloom Mainnet is the Layer-2 chain supporting Powerloom’s composable data network where devs, orgs, and end-users get access to ready-to-consume, affordable, and verifiable onchain datasets.

Total Value SecuredTVS

$14.18 K27.8%

Past day UOPSDaily UOPS

0.2327.2%

Gas token

POWER

Type

Other

Purposes

Universal, Information

Chain ID

7869

Tokens breakdown

Value secured breakdown

View TVS breakdown

Sequencer failureState validationData availabilityExit windowProposer failure

Explore more in Discovery UI

Badges

About

Powerloom Mainnet is the Layer-2 chain supporting Powerloom’s composable data network where devs, orgs, and end-users get access to ready-to-consume, affordable, and verifiable onchain datasets.

Why is the project listed in others?

There are less than 5 external actors that can submit challenges

Consequence: projects without a sufficiently decentralized set of challengers rely on few entities to safely update the state. A small set of challengers can collude with the proposer to finalize an invalid state, which can cause loss of funds.

There are less than 5 external actors that can attest data availability

Consequence: projects without a sufficiently decentralized data availability committee rely on few entities to safely attest data availability on Ethereum. A small set of entities can collude with the proposer to finalize an unavailable state, which can cause loss of funds.

Learn more about the recategorisation here.

Value Secured View TVS breakdown

Exclude restricted RWA tokens

Total

Canonically BridgedCanonically Bridged ValueCanonical

Natively MintedNatively Minted TokensNative

Externally BridgedExternally Bridged ValueExternal

ETH & derivatives

Stablecoins

BTC & derivatives

Other

View TVS breakdown

Activity

2025 Mar 12 — 2026 Feb 11

Past Day UOPS

0.23

Past Day Ops count

19.47 K

Max. UOPS

0.34

2026 Feb 07

Past day UOPS/TPS Ratio

1.00

Onchain costs

The section shows the operating costs that L2s pay to Ethereum.

2025 Mar 12 — 2026 Feb 11

Total cost

$826.93

Avg cost per L2 UOP

$0.000216

Avg cost per day

$2.45

Liveness

This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.

No ongoing anomalies detected

Avg. tx data subs. interval

Avg. state updates interval

Past 30 days anomalies

Risk summary

Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted.

Fraud proof system is fully deployed but is not yet permissionless as it requires Validators to be whitelisted.

Sequencer failureState validationData availabilityExit windowProposer failure

Sequencer failure

Self sequence

In the event of a sequencer failure, users can force transactions to be included in the project’s chain by sending them to L1. There can be up to a 1d delay on this operation.

State validation

Fraud proofs (INT)

No actor outside of the single Proposer can submit fraud proofs. Interactive proofs (INT) require multiple transactions over time to resolve. The challenge protocol can be subject to delay attacks. There is a 5d 14h challenge period.

Data availability

External (DAC)

Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC) with a threshold of 1/1 that is tasked with protecting and supplying the data.

Exit window

None

There is no window for users to exit in case of an unwanted regular upgrade since contracts are instantly upgradable.

Proposer failure

Cannot withdraw

Only the whitelisted proposers can publish state roots on L1, so in the event of failure the withdrawals are frozen.

Data availability

Data is not stored on chain

Users transactions are not published onchain, but rather sent to external trusted parties, also known as committee members (DAC). Members of the DAC collectively produce a Data Availability Certificate (comprising BLS signatures from a quorum) guaranteeing that the data behind the new transaction batch will be available until the expiry period elapses (currently a minimum of two weeks). This signature is not verified by L1, however external Validators will skip the batch if BLS signature is not valid resulting. This will result in a fraud proof challenge if this batch is included in a consecutive state update. It is assumed that at least one honest DAC member that signed the batch will reveal tx data to the Validators if Sequencer decides to act maliciously and withhold the data. If the Sequencer cannot gather enough signatures from the DAC, it will “fall back to rollup” mode and by posting the full data directly to the L1 chain. The current DAC threshold is 1 out of 1.

Funds can be lost if the external data becomes unavailable (CRITICAL).
Users can be censored if the committee restricts their access to the external data.

Inside AnyTrust - Arbitrum documentation

State validation

Updates to the system state can be proposed and challenged by a set of whitelisted validators. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.

State root proposals

Validators propose state roots as children of a previous state root. A state root can have multiple conflicting children. State roots are referred to as “assertions” within the contracts. Each chain of assertions only requires one stake, and validators staked on assertions with a child are considered inactive and can either move their stake to a new node or withdraw it. The function used to propose a new assertion is the stakeOnNewAssertion function. The stake is currently set to 0.1 ETH, and it can be slashed if the proposal is proven incorrect via a fraud proof. The protocol allows such funds to be trustlessly pooled together if necessary. New nodes cannot be created faster than the minimum assertion period, currently set to 15m. An assertion without “rivals” can be confirmed after the challenge period has passed, currently set to 5d 14h. If a rival is present, then it is checked that the assertion is the winner in the challenge protocol.

BoLD paper

Challenges

A challenge can be started between two siblings, i.e. two different state roots that share the same parent, by calling the createLayerZeroEdge function in the ChallengeManager contract. Edges represent assertions, or bisected assertions, within the challenge protocol. Challenges are played via a bisection game, where asserters and challengers play together to find the first instruction of disagreement. Such instruction is then executed onchain in the WASM OneStepProver contract to determine the winner. An edge can only be bisected when rivaled. The bisection process requires no new stake as their validity is checked against a parent “history root” that contains all intermediate states. An edge can also be confirmed if itself or its descendants spend enough time being unrivaled. Such time is set to 5d 14h. If both actors play as slow as possible, the maximum time to confirm an edge is double such value, i.e. 11d 4h. Due to the complexities of maintaining the history root, the challenge protocol is divided into 3 levels, where the lowest level represents assertions over blocks, the highest level represents assertions over single WASM instructions, and intermediate levels represent assertions over chunks of WASM instructions. When moving between levels, a new stake is required. Level 0 (block level) requires a stake of 0.0 ETH, level 1 requires a stake of 0.1 ETH, level 2 requires a stake of 0.1 ETH. The ratio between such stakes can be exploited to perform resource exhaustion attacks.

Funds can be stolen if an attacker successfully performs a resource exhaustion attack.

Fraud Proof Wars: Arbitrum BoLD

Program Hashes

Name	Hash	Repository	Verification	Used in

	0x8a75...a499	Github		Projects used in Search for projects used in

Operator

The system has a centralized sequencer

While forcing transaction is open to anyone the system employs a privileged sequencer that has priority for submitting transaction batches and ordering transactions.

MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.

Sequencer - Arbitrum documentation

Users can force any transaction

Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly. After a delay of 1d in which a Sequencer has failed to include a transaction that was directly posted to the smart contract, it can be forcefully included by anyone on the host chain, which finalizes its ordering.

Sequencing

Buffered forced transactions

To force transactions from the host chain, users must first enqueue “delayed” messages in the “delayed” inbox of the Bridge contract. Only authorized Inboxes are allowed to enqueue delayed messages, and the so-called Inbox contract is the one used as the entry point by calling the sendMessage or sendMessageFromOrigin functions. If the centralized sequencer doesn’t process the request within some time bound, users can call the forceInclusion function on the SequencerInbox contract to include the message in the canonical chain. The time bound is defined to be the minimum between 1d and the time left in the delay buffer. The delay buffer gets replenished over time and gets consumed every time the sequencer doesn’t timely process a message. Only messages processed with a delay greater than 428424622y 1mo consume the buffer. The buffer is capped at 428424622y 1mo. The replenish rate is currently set at 1m every 20m. Even if the buffer is fully consumed, messages are still allowed to be delayed up to 428424622y 1mo.

Sequencer and censorship resistance - Arbitrum documentation

Withdrawals

Regular messaging

The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization usually takes several days to complete.

Autonomous exit

Users can (eventually) exit the system by pushing the transaction on L1 and providing the corresponding state root. The only way to prevent such withdrawal is via an upgrade.

Other considerations

EVM compatible smart contracts are supported

Arbitrum One uses Nitro technology that allows running fraud proofs by executing EVM code on top of WASM.

Inside Arbitrum Nitro

Permissions

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

Ethereum

Roles:

Sequencer (9) EOA 1 EOA 2 EOA 4 EOA 5 EOA 6 EOA 7 EOA 8 EOA 9 EOA 10

Can submit transaction batches or commitments to the SequencerInbox contract on the host chain.

Validator EOA 3

Can propose new state roots (called nodes) and challenge state roots on the host chain.

Used in:

Actors:

Conduit Multisig 1 0x4a49…A746

A Multisig with 4/13 threshold.

Can upgrade with no delay
- RollupEventInbox UpgradeExecutor → ProxyAdmin
- L1OrbitUSDCGateway ProxyAdmin
- ERC20Gateway UpgradeExecutor → ProxyAdmin
- Bridge UpgradeExecutor → ProxyAdmin
- UpgradeExecutor UpgradeExecutor → ProxyAdmin
- Inbox UpgradeExecutor → ProxyAdmin
- GatewayRouter UpgradeExecutor → ProxyAdmin
- SequencerInbox UpgradeExecutor → ProxyAdmin
- Outbox UpgradeExecutor → ProxyAdmin
- RollupProxy UpgradeExecutor
- EdgeChallengeManager UpgradeExecutor → ProxyAdmin
Can interact with RollupProxy
- Pause and unpause and set important roles and parameters in the system contracts: Can delegate Sequencer management to a BatchPosterManager address, manage data availability and DACs, set the Sequencer-only window, introduce an allowList to the bridge and whitelist Inboxes/Outboxes UpgradeExecutor

Participants (13):

0xA9FC…8d09 0x3816…Cf07 0x6BB4…83A6 0x2103…911c 0x65D1…6007 0x8117…E7Ac 0xA073…bda2 0xF331…647D 0xa400…e6e4 0x3840…Fd5f 0xa0C6…9038 0xefCf…dD5C 0x4D80…5BAe

Used in:

GnosisSafeL2 0xA7A2…b68F

A Multisig with 1/1 threshold.

Participants (1):

EOA 3

EOA 1, EOA 2, EOA 4, EOA 5, EOA 6, EOA 7, EOA 8, EOA 9 and EOA 10 (9) 0x17F1…AD8b 0x2E8C…b1E2 0x4ed0…C228 0x74a0…Bf3C 0x85e7…A09D 0xA4f9…2CDe 0xb9B2…FD5e 0xc7ef…6D36 0xCEEA…Cd7e

A Sequencer - acting directly

EOA 3 0x401B…04Bf

Member of GnosisSafeL2.

A Validator - acting directly

Used in:

Smart contracts

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

A diagram of the smart contract architecture

Ethereum

Bridge 0x53b1…20DB Implementation (Upgradable)Admin

Escrow contract for the project’s gas token (can be different from ETH). Keeps a list of allowed Inboxes and Outboxes for canonical bridge messaging.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1
This contract stores the following tokens: POWER.

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

SequencerInbox 0x903A…bDeC Implementation (Upgradable)Admin

A sequencer (registered in this contract) can submit transaction batches or commitments here.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1
- batchPosters: EOA 1, EOA 10, EOA 2, EOA 4, EOA 5, EOA 6, EOA 7, EOA 8, EOA 9

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

RollupProxy 0xc319…2892 Implementation #1 (Upgradable)Implementation #2 (Upgradable)Admin

Central contract for the project’s configuration like its execution logic hash (wasmModuleRoot) and addresses of the other system contracts. Entry point for Proposers creating new assertions (state commitments) and Challengers submitting fraud proofs (In the Orbit stack, these two roles are both called Validators).

Roles:
- admin: UpgradeExecutor; ultimately Conduit Multisig 1
- getValidators: EOA 3
- owner: UpgradeExecutor; ultimately Conduit Multisig 1

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

EdgeChallengeManager 0xfFfE…1A76 Implementation (Upgradable)Admin

Contract that implements the main challenge protocol logic of the fraud proof system.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

UpgradeExecutor 0x6a23…805F Implementation (Upgradable)Admin

Central contract defining the access control permissions for upgrading the system contract implementations.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1
- executors: Conduit Multisig 1

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

ERC20Gateway 0x46D9…f81A Implementation (Upgradable)Admin

Escrows deposited ERC-20 assets for the canonical Bridge. Upon depositing, a generic token representation will be minted at the destination. Withdrawals are initiated by the Outbox contract.