Mantanetwork fast finality - state-root approval and withdrawal timing

Mantanetwork fast finality's published design uses stake-backed signatures on Manta Pacific state commitments to support shorter waits for native withdrawals to Ethereum. Providers validate proposed state roots; relayers check their attestations and forward aggregated approval to Ethereum-side contracts. The receiving contracts determine when the relevant withdrawal becomes eligible for finalization. Pacific block inclusion and Ethereum asset delivery mark different points in the process. The associated Manta Staking program stopped generating rewards on May 20, 2026.

Execution, data, and the Ethereum handoff

Pacific execution determines what a transaction changes, Celestia provides transaction-data availability, and Ethereum contracts govern acceptance of native withdrawal claims. Execution updates balances and application state. Available transaction data lets other participants reconstruct those changes. Settlement contracts apply the conditions under which Ethereum accepts the resulting commitment. Fast-finality validation adds attestations to that relationship, with the aim of making accepted state commitments usable sooner.

A state root is a cryptographic commitment to a particular network state. Providers approve that commitment by signing it. The signature identifies the state that they support; it doesn't carry every transaction or transfer assets between chains by itself. Publishing transaction data and approving the computed state remain distinct operations, even when the same system coordinates them.

What turns state-root signatures into fast-finality approval?

Approval requires eligible provider attestations, relayer verification, and acceptance by the Ethereum-side contract that governs the relevant state commitment. Providers follow proposed outputs and submit signatures for the state that they validate. The original architecture then hands those attestations to a Manager and relayer Nodes.

Open full-size image

The Manager coordinates voting requests for particular state roots. Nodes check the associated provider signatures and count attestations from providers with sufficient active stake. Provider eligibility and relayer agreement serve different purposes: stake determines which provider contributions qualify, while the relayer quorum determines whether enough Nodes approve the submission. A valid signature from an ineligible provider doesn't satisfy the whole approval process.

The Ethereum-facing aggregation uses BLS signatures to combine relayer approval for contract verification. The published registry checks registered-signer participation, verifies the aggregate signature, and requires an earlier reference block. It also accounts for non-signers when constructing the signing public key. These checks reject a submission whose aggregate signature doesn't verify against the applicable signing set.

The original roadmap separately listed Optimism fraud-proof integration and a later zero-knowledge dispute-resolution phase. Those mechanisms concern invalid-state disputes; BLS signatures encode signers' approval of a commitment. Fast-finality approval alone doesn't establish that a withdrawal passed a zero-knowledge proof.

The project operated the Manager and relayer Nodes in the audited 2025 setup.

MANTA and BTC backing after the staking sunset

The original design paired MANTA delegation through Symbiotic with a BTC-backed validation layer through Babylon, giving provider attestations economic backing. MANTA holders could delegate validation power to operators in the Symbiotic portion. The Babylon portion assigned state-root validation to BTC-backed Finality Providers.

Open full-size image

Babylon's provider attestations use Extractable One-Time Signatures, abbreviated EOTS. Relayer BLS aggregation performs a separate job when forwarding approval toward Ethereum. The BTC design allows native Bitcoin staking without bridging or wrapping BTC for delegation. BTC backing contributes to the validation mechanism while native Pacific withdrawals settle through Ethereum contracts.

Operators can stop their nodes under the sunset arrangements, and delegators can unstake their MANTA.

The initial MANTA staking layer left slashing inactive and withheld rewards from operators that failed to contribute proofs. Under that initial arrangement, missing proofs affected rewards without automatically confiscating delegated MANTA.

Does Pacific confirmation complete an Ethereum withdrawal?

A successful Pacific transaction confirms execution on Pacific; an Ethereum withdrawal also needs its withdrawal proof and Ethereum-side finalization. A transaction hash identifies the transaction, while its receipt reports the execution outcome. Neither alone establishes that Ethereum has released the withdrawn asset. The native withdrawal workflow distinguishes proof readiness, the challenge period, relay readiness, and relaying. Each state has a different meaning, so an application shouldn't display completed withdrawal delivery merely because the initiating Pacific transaction succeeded.

How does stake backing change the withdrawal waiting period?

The stake-ratio version of FinalityRelayerManager shortens its challenge period using counted MANTA backing, BTC backing, or both. Its formula starts from three days and subtracts contributions proportional to configurable staking targets. Each target-backed case in this comparison assumes that counted backing exactly matches the applicable target.

This stake-ratio implementation keeps a minimum challenge period of 43,200 seconds, or 12 hours.

Backing above the targets can reduce the calculated wait further, subject to that floor. The amounts needed to reach a target can change because the contract exposes target-setting functions.

These are implementation-specific waiting rules, not a confirmed schedule for every current native withdrawal. The broader fast-finality design describes minute-scale withdrawals, while this calculation retains an hours-long floor. Applying either duration requires the matching bridge implementation. Output publication, the proof transaction, and Ethereum execution also contribute to elapsed delivery time.

Proving and completing a native withdrawal

Native withdrawals move from an L2 request to an Ethereum proof, then to finalization after the bridge's waiting conditions allow completion. The documented SDK associates the proof and finalization operations with the initiating withdrawal transaction hash. This preserves the relationship between the Pacific request and its Ethereum-side processing. A new transaction identifier doesn't, by itself, show progress on an earlier withdrawal.

The SDK distinguishes WAIT_TO_PROVE, READY_TO_PROVE, IN_CHALLENGE_PERIOD, READY_FOR_RELAY, and RELAYED. Proof readiness permits the proof step; relay readiness permits the finalization step. Ethereum execution and the expected destination asset movement establish the delivery outcome. A finality update changes eligibility under the bridge rules, while the withdrawal still needs its applicable completion transaction.

Open full-size image

Integrations that track provider activity need consistent network and contract settings, persistent polling state, and functioning data connections. The operator setup separates Ethereum output monitoring from Celestia signature publication and offers health and metrics endpoints. Monitoring whether the relevant output reaches the receiving contract provides more useful progress information than repeatedly counting unrelated Pacific blocks.