Summary Value Secured Onchain costs Liveness Milestones & Incidents Risk summary Risk analysis Data availability State validation Upgrades & Governance Operator Withdrawals Permissions Smart contracts

Fluent

Badges

About

Fluent is an Ethereum L2 that blends Wasm and EVM smart contracts into a unified execution environment (with SVM planned). Batches are preconfirmed by an AWS Nitro Enclave and finalize after a delay; challenges are resolved by SP1 ZK proofs.

Total Value SecuredTVS

$924.13 K10.1%

Past day UOPSDaily UOPS

No data

Gas token

ETH

Type

Other

Purpose

Universal

Chain ID

25363

Tokens breakdown

Value secured breakdown

0.00% with additional trust assumptions

View TVS breakdown

Sequencer failureState validationData availabilityExit windowProposer failure

Explore more in Discovery UI

Badges

About

Why is the project listed in others?

The proof system isn't fully functional

Consequence: projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid 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

Onchain costs

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

2026 Apr 19 — May 11

Total cost

$1.50 K

Avg cost per L2 UOP

No data

Avg cost per day

$65.31

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. proof subs. interval

Avg. state updates interval

Past 30 days anomalies

100% normal uptime

Milestones & Incidents

Fluent mainnet launch

2026 Apr 24th

Fluent activates its Ethereum L2 mainnet alongside the BLEND token launch.

Learn more

Risk summary

The project relies on program hashes that could not be successfully reproduced from their published sources.

(CRITICAL)

Sequencer failureState validationData availabilityExit windowProposer failure

Sequencer failure

No mechanism

There is no mechanism to have transactions be included if the sequencer is down or censoring.

State validation

TEE attestations

State roots are accepted on the basis of an AWS Nitro Enclave preconfirmation and a 2d time delay; the SP1 ZK proof system exists in the contracts but is currently unreachable because CHALLENGER_ROLE has no holders. Effective security reduces to trust the TEE and wait the delay. See the State Validation section below for details.

Data availability

Onchain

All of the data needed for proof construction is published on Ethereum L1.

Exit window

None

There is no window for users to exit in case of an unwanted 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

All data required for proofs is published on chain

All the data that is used to construct the system state is published on chain in the form of cheap blobs or calldata. This ensures that it will be available for enough time. Fluent posts transaction data to Ethereum L1 as EIP-4844 blobs. Blob hashes are pinned on the Rollup contract via submitBlobs and SP1 proofs verify that block data matches both the pinned hashes and the EIP-4844 commitments.

Fluent Rollup Architecture - Blob Publication

Learn more about the DA layer here:

Ethereum

State validation

Challenges

Fluent runs an optimistic batch lifecycle backed by SP1 ZK proofs for dispute resolution. (1) the sequencer commits a batch root via commitBatch; (2) EIP-4844 blob hashes are pinned via submitBlobs; (3) an AWS Nitro Enclave preconfirms the batch with an ECDSA signature whose key was admitted onchain only after an SP1 proof verified AWS’s attestation document for that key and that the document’s PCR0 (a fingerprint of the enclave image) matches the expected (audited) value; (4) within 1d 12h of acceptance, addresses with the CHALLENGER_ROLE can dispute via challengeBatchRoot or challengeBlock and the prover must resolve each challenge with an SP1 proof before the same window closes; (5) batches finalize either after a 2d L1 delay (finalizeBatches, no proof needed in the happy path) or immediately once all challenged blocks are proven (finalizeWithProofs).

Currently CHALLENGER_ROLE has no holders, so challengeBatchRoot and challengeBlock cannot be invoked. Because _provenBlocks is only populated inside resolveBlockChallenge (which itself requires an active challenge), no SP1 proof can be submitted onchain in this state and finalizeWithProofs reverts. Every batch therefore finalizes purely through the time-based path, and effective security reduces to trust the TEE plus the 2d delay until the admin grants the role.

The PROVER, EMERGENCY, and CHALLENGER roles on the Rollup are gated by access control; see the Permissions section for the current holders.

Funds can be stolen if an invalid batch is preconfirmed by a compromised AWS Nitro Enclave and no permissioned challenger disputes it before the challenge window closes.

PROVER

SP1 Turbo

Trusted Setups

Onchain verifier

SP1Verifier

Used in

Onchain verifier

SP1Verifier

Used in

Program Hashes

Name	Hash	Repository	Verification	Used in

	0x00e3...7334	Code unknown
	0x0085...311b	Github

Upgrades & Governance

Past upgrades

The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.

Count of upgrades

Last upgrade

19d 16h ago

Avg upgrade interval

7d 5h

Operator

The system has a centralized operator

The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system. Sequencing and proof submission are also permissioned at launch: only allowlisted addresses can submit batches and SP1 proofs to the Rollup. See the Permissions section for current role holders.

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

Fluent Security Invariants

Users can't force any transaction

There is no general mechanism to force the sequencer to include the transaction.

Users can be censored if the operator refuses to include their transactions.

Withdrawals

Regular exit

The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is settled the funds become available for withdrawal on L1. ZK proofs are required to settle blocks. Finally the user submits an L1 transaction to claim the funds. On Fluent, the message hash enters the block’s withdrawal root which becomes part of the next batch root; once the batch is finalized, an address with RELAYER_ROLE delivers the message on L1 via receiveMessageWithProof with two Merkle proofs (block-against-batch and message-against-block). First delivery is permissioned, so withdrawals progress only when the relayer acts; if a delivered message’s L1-side execution reverts, anyone can retry via the permissionless receiveFailedMessage.

Funds can be frozen if the RELAYER_ROLE holder stops delivering L2->L1 messages on L1, since first delivery is permissioned and there is no user-initiated bypass.

Fluent Bridge Architecture

Optimistic (preconfirmed) fast withdrawals

After a batch is preconfirmed by the AWS Nitro Enclave, withdrawals can be released without waiting for finalization, subject to per-token hourly and daily caps enforced by the FastWithdrawalList registry. ETH and WETH share a bucket to prevent cap evasion.

Funds can be stolen if the AWS Nitro Enclave attestation key is compromised and the operator preconfirms an invalid batch within the rate-limited window.

Permissions

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

Ethereum

Roles:

ProposerFluentAdminEOA

schedule operations on the timelock; the configured min-delay must elapse before they can be executed.

SequencerFluentSequencerEOA

commit batches and submit EIP-4844 blob hashes to the Rollup.

ValidatorFluentProverEOA

submit SP1 ZK proofs that resolve challenged batches and accelerate finalization via finalizeWithProofs.

AnyTrust FastConfirmerFluentEnclaveAttesterEOA

AWS Nitro Enclave attestation key admitted to preconfirm batches; binds the optimistic fast-withdrawal path.

RelayerEOA 1

deliver L2->L1 messages on L1 via receiveMessageWithProof; this is the only entry point for first-time delivery, so user withdrawals progress only when a holder of this role acts (failed-execution retries via receiveFailedMessage are permissionless once a message has been delivered at least once).

Actors:

FluentMultisig0x33C0…ff11

A Multisig with 4/5 threshold.

Can upgrade with no delay
- Blacklist
- FluentRollup
- NativeGateway
- L1FluentBridge
- ERC20TokenFactory
- ERC20Gateway
Can interact with FluentRollup
- grant / revoke all access control roles on the Rollup contract and configure its core parameters
- revert non-finalized (committed or preconfirmed) batches via revertBatches; cannot revert finalized batches
Can interact with FluentTimeLock
- execute scheduled timelock operations once the min-delay has elapsed
Can interact with L1FluentBridge
- configure the rollup binding, oracles, gas parameters and gateway whitelist on the L1 bridge core, and grant / revoke its other roles
- pause / unpause the L1 bridge core and clear expired L1->L2 deposits via skipExpiredDeposits (no user-initiated refund path exists; rollbackMessageWithProof reverts with NOT_IMPLEMENTED)

Participants (5):

0x1C07…2523 FluentAdminEOA 0x6845…f99b 0x624C…0C9B 0x9CDF…9Fa0

SP1VerifierGatewayMultisig0xCafE…6878

A Multisig with 2/3 threshold.

Can interact with SP1VerifierGateway
- affect the liveness and safety of the gateway - can transfer ownership, add and freeze verifier routes

Participants (3):

0xBaB2…1126 0x72Ff…4f54 0x9395…8885

Used in:

FluentAdminEOA0x9ec3…518D

Member of FluentMultisig.

Can interact with FluentTimeLock
- cancel scheduled timelock operations before they are executed
A Proposer - acting directly

EOA 10x4A0e…3A48

A Relayer - acting directly

FluentProverEOA0xB9E6…255C

A Validator - acting directly

FluentEnclaveAttesterEOA0xef9D…2012

A FastConfirmer - acting directly

FluentSequencerEOA0xFd58…1c26

A Sequencer - acting directly

Smart contracts

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

Ethereum

FastWithdrawalList0x3eFc…D30E Implementation (Upgradable)Admin

Per-token rate-limit registry for the optimistic (preconfirmed) fast-withdrawal path. Enforces hourly and daily caps using rolling windows keyed by block timestamp; related tokens (e.g. ETH and WETH) can be aliased to a shared bucket to prevent cap evasion.

NativeGateway0x8976…56dd Implementation (Upgradable)Admin

L1 entry point for ETH deposits into Fluent. Forwards ETH to L1FluentBridge for actual escrow custody and emits the corresponding bridge message. UUPS-upgradeable; upgrades are gated by the contract owner.

Roles:
- admin: FluentMultisig

Can be upgraded by:

FluentMultisig with no delay

L1FluentBridge

Escrow

0x9CAc…8Ddc Implementation (Upgradable)Admin

Bridge core for Fluent. Routes deposits from L1 gateways into a FIFO queue consumed by the sequencer, and lets relayers process L2->L1 messages with two Merkle proofs against the latest preconfirmed or finalized batch root. Custodies bridged ETH on L1 (gateways forward ETH here on deposit). UUPS-upgradeable; upgrades and gateway-whitelist / oracle / pause changes are gated by DEFAULT_ADMIN_ROLE.

Roles:
- defaultAdmin: FluentMultisig
- pauser: FluentMultisig
- relayer: EOA 1

The following tokens are included in the value secured calculation:

Can be upgraded by:

FluentMultisig with no delay

ERC20Gateway

Escrow

0xFD4C…3B61 Implementation (Upgradable)Admin

L1 entry point for ERC-20 deposits into Fluent. Custodies ERC-20 tokens directly on L1 and emits the corresponding bridge message; on the L2 side the canonical pegged token is minted via the ERC20TokenFactory. UUPS-upgradeable; upgrades are gated by the contract owner.

Roles:
- admin: FluentMultisig

All supported tokens in this escrow are included in the value secured calculation.

Can be upgraded by:

FluentMultisig with no delay

FluentTimeLock0x7846…3bF4

OpenZeppelin TimelockController used to delay privileged operations. PROPOSER_ROLE schedules calls; the configured minimum delay must elapse before EXECUTOR_ROLE can execute them; CANCELLER_ROLE can drop scheduled calls.

Roles:
- canceller: FluentAdminEOA
- executor: FluentMultisig
- proposer: FluentAdminEOA

ERC20PeggedToken0x056f…b090

Blacklist0x05C5…1484 Implementation (Upgradable)Admin

Roles:
- admin: FluentMultisig

Can be upgraded by:

FluentMultisig with no delay

FluentRollup0x1cF5…727f Implementation (Upgradable)Admin

Core Fluent rollup contract. Sequencers commit batch roots and EIP-4844 blob hashes; an AWS Nitro Enclave preconfirms each batch via a signature whose key is bound to a PCR0 measurement verified by SP1; participants holding CHALLENGER_ROLE can dispute and the prover resolves disputes with SP1 ZK proofs; batches finalize after a block-count delay or immediately once all blocks are proven.

Roles:
- defaultAdmin: FluentMultisig
- emergency: FluentMultisig
- preconfirmation: FluentEnclaveAttesterEOA
- prover: FluentProverEOA
- sequencer: FluentSequencerEOA

Can be upgraded by:

FluentMultisig with no delay

NitroVerifier0x207F…AC5B

Verifies AWS Nitro Enclave attestations onchain. The enclave’s signing key is admitted only after an SP1 proof confirms its attestation matches the expected PCR0 measurement, binding preconfirmation authority to audited enclave code.

SP1VerifierGateway0x397A…dA9B

This contract is the router for zk proof verification. It stores the mapping between identifiers and the address of onchain verifier contracts, routing each identifier to the corresponding verifier contract.