What blockchain confirmation actually confirms (October 2026)

1 Start with what happens after the transaction

Updating a screen, shipping a product and releasing an asset on another chain have different consequences. A screen can show a pending state and later correct it. A parcel cannot easily be recalled when a block is reorganized. Tokens minted by a bridge may already have passed to a third party. The harder the next action is to reverse, the more precisely the application must understand who confirmed the preceding result and which conditions remain open.

This report therefore separates five questions. Validity asks whether execution followed the rules. Ordering asks which sequence is used for conflicting transactions. Finality asks under which assumptions an accepted result will no longer be replaced. Data availability asks whether others can obtain the material needed to reconstruct or verify state. Settlement or exit asks whether the next action can actually be completed. These are conditions, not quantities that can usefully be averaged into a security score. More throughput cannot replace missing withdrawal data.

Consider a withdrawal from an L2. It executes on the L2, and its batch is later included in a finalized Ethereum block. That establishes the batch material's place in L1 history. The withdrawal contract may still require an acceptable state claim, a waiting period and a final execution transaction. Inclusion of the material, correctness of the state transition and eligibility to withdraw each have their own verification path.

Three research questions guide the comparison. How do state models constrain conflicts and produce deterministic results? Which networks, data and authorities stand between a receipt and a result the user can independently verify? How much can published throughput, latency and fee evidence support an application's promises? The unit of comparison is a concrete transaction path and its failure conditions. Theoretical thresholds, client optimizations and deployed network behavior remain separate.

This makes a preference falsifiable. An application that must recover state and exit while its operator is offline cannot meet that requirement through data available only to the operator. An application that frequently updates independent state on one chain may gain little from adding cross-layer proofs and withdrawals. Different requirements can produce different choices. A performance leaderboard cannot make that decision for the product.

2 A valid signature is only the beginning

A signature establishes that a key authorized a message. It does not establish that the claimed balance exists or that a recipient contract will behave as the user expects. Nodes still check inputs, sequence numbers, fees and execution rules against state. The wallet's send button points to quite different objects in UTXO, account and object-based systems.

A Bitcoin transaction spends existing unspent transaction outputs, or UTXOs. If an output contains 10 units and a transaction pays 6 with a fee of 1, the remaining 3 must be assigned to a change output. The protocol does not preserve the original output as a balance that can be debited repeatedly. Each input identifies a previous transaction and output index, while its spending conditions establish authorization. Acceptance consumes old outputs and creates new ones.

In Bitcoin Core 31.1, CheckTxInputs() rejects missing or spent inputs, checks coinbase maturity and amount ranges, and requires inputs to cover outputs. The relevant ConnectBlock() path handles sequence locks, script checks and UTXO updates. Miners can choose an order; validating nodes retain their own rules for validity. More accumulated work cannot make an arbitrary creation of value pass those checks.

The conflict between two spends is explicit: both refer to the same old output. Independent outputs can be checked separately, while only one of two conflicting spends can survive. More complex applications distribute conditions across outputs and scripts. That exposes dependencies, but it also gives wallets responsibility for coin selection, change and transaction graphs that a simple balance display tends to conceal.

Ethereum commonly starts with account state. An externally owned account uses a nonce to sequence transactions; a transaction carries a destination, value, call data and fee limits. Contract execution can touch many storage locations. A call to an exchange may call a token contract in turn, so the final balances depend on the whole call path. A familiar contract address or function name needs a specific chain, code version and execution state before it explains the result.

Failed transactions are particularly easy to misunderstand. Geth 1.17.7's state transition path handles the sender nonce before the virtual-machine call. EVM.Call() takes a state snapshot and restores the relevant state on an execution error. The application call can revert while the included transaction still consumes a nonce and fees. Treating a failed transfer as a transaction the network never processed leads to retry and accounting errors.

Move puts resource-use constraints into the language and verifier. Resources with the relevant ability restrictions cannot be freely copied or discarded, and modules control their creation and transfer. This constrains certain asset-handling mistakes. It does not automatically validate exchange pricing, access-control configuration or cross-chain messages. Aptos and Sui both use Move technology, yet their storage and transaction-processing designs differ substantially. Language guarantees need to be read alongside the chain's state model.

All three models must prevent repeated use of the same right. UTXOs reference old outputs, account systems check sequence and mutate storage, and object systems track identity, version and ownership. They expose different information to parallel execution. Knowing conflicts in advance permits earlier scheduling; executing without a complete access set requires checking whether a computation used a value that later became stale.

3 What more cores can actually accelerate

Suppose T1 changes account X's balance from 10 to 7, while T2 attempts to spend 8 from X. If two threads both read 10, approve their payments and independently write results, the ledger loses a coherent meaning. Before using more cores, an executor must ensure that parallel results match an order the protocol accepts. Transactions touching independent X and Y state may genuinely run at the same time.

Solana transaction messages declare account access, including which accounts are writable and which are read-only. The scheduler can identify conflicts before executing programs. The pinned Agave account-lock implementation makes writes exclusive against other reads and writes, while allowing shared read access. Program invocation privileges are also constrained by the accounts passed in and their writable flags. Explicit access sets remove guesswork; an application that directs every transaction to the same writable account still creates a hotspot.

This is the gap between a parallel chain and a parallel application. Recording every user's action in one global counter creates shared writes. Separating genuinely independent state gives the scheduler room to work. The application must preserve its invariants during that separation. If two accounts jointly enforce one supply constraint, consistency still needs to be checked; moving bytes into different accounts cannot remove the underlying dependency.

Aptos's Block-STM paper takes a different approach. It fixes an order for the block, then speculatively executes transactions in parallel. A thread reads the latest available version written by a preceding transaction and records its read set. Validation checks whether those reads remain valid. If earlier execution changes a value, dependent transactions run again. The committed result must match the predetermined serial order.

In the example, T2 may first calculate a successful payment against 10. T1 later publishes the value 7. Validation discovers that T2 read an obsolete version and re-executes it, now seeing insufficient funds. The first success was an internal speculative result, not a chain outcome the user could rely on. Block-STM also tracks estimates for withdrawn writes and waiting dependencies, so a temporarily unavailable version is not mistaken for a permanently absent value.

This lets programs benefit from low-conflict parallelism without always declaring a precise access set in advance. The cost changes with contention. Repeated writes to the same location cause invalidations, waits and re-execution. The paper also examines shared state such as fee accumulation and the use of commutative operations to avoid unnecessary serial dependencies. This is a genuine algorithmic gain; parallel execution itself need not delegate validation to another trusted organization.

Sui makes object dependencies more explicit. Objects carry identity, version and ownership, and transactions declare the objects they use. Operations on unrelated owned objects need not share a serial queue merely for one another's sake. Conflicting writes to shared objects still need a common order. The early Lutris paper explains this through an owned-object fast path and a consensus path for shared objects, including locks and epoch recovery when a user signs conflicting uses of the same object version.

Sui in 2026 has moved beyond that exact flow. Mysticeti v2 incorporates transaction validation into DAG dissemination and voting, removing a separate certification round from the older design. The current Transaction Driver then gathers sufficiently weighted matching execution effects. The pinned effects-certification code groups validator responses by effects digest and returns one when it reaches quorum. One validator finishing execution, sufficient certification and inclusion in a certified checkpoint remain distinct observations.

The object model has also evolved. Sui 1.72 introduced address balances with system-level settlement, and gas payment can mix an address balance with coin objects. The May 2026 incident report describes a canceled competing spend whose mixed gas handling still debited a balance, causing an underflow at later settlement. Resource rules, scheduling and fee settlement must work together. Object parallelism cannot validate that entire path on its own.

A useful high-performance-chain evaluation starts with the application's hottest state. Simple, dispersed transactions can exploit many cores. A crowded liquidity pool, order-book level or shared resource calls for measurements of waiting, re-execution, rejection and tail latency. An average transactions-per-second figure does not explain why the most contested transaction has not finished.

4 How the network chooses a history

An executor can be deterministic while the network sees two individually valid histories. Two Bitcoin miners may find blocks almost simultaneously, or two branches may contain conflicting spends that are valid within their own histories. Nodes must choose which branch to extend. Recipients must also decide how likely their observed result is to be replaced. These are fork-choice and finality questions.

The Bitcoin whitepaper places the competition in accumulated work. An attacker catching up with the honest chain must make up the work already lost. Under assumptions including a lower attacker hash rate, the probability of catching up falls as the deficit grows. Confirmation-count policies follow from this reasoning. Six confirmations are a risk choice; the sixth block does not trigger an absolute immutability rule.

The code's candidates are also constrained. Bitcoin Core's FindMostWorkChain() excludes candidates with missing required data or known-invalid ancestry. Majority hash power can affect inclusion, censorship and reorganizations. It cannot make a normally validating node accept arbitrary forged signatures. Treating a hash-power attack as permission to edit any ledger field confuses control over branch selection with control over validity rules.

Proof-of-stake systems assign proposal and voting influence by stake. Ethereum's Gasper combines LMD-GHOST fork choice with Casper FFG checkpoint finality. One selects the current branch; the other establishes checkpoint relationships through sufficiently weighted votes. Mainnet currently uses 12-second slots and 32-slot epochs. Normal finality still depends on timely votes, so a slot's duration is not a transaction's finality time.

A fixed validator set helps explain the two-thirds threshold. Two groups each representing at least two thirds of the weight must overlap by at least one third. If honest validators cannot cast votes satisfying conflicting conditions, conflicting final results imply a violation of those constraints. The Gasper paper defines slashable voting conditions and analyzes the resulting security. The argument belongs to a particular protocol, weighted set and voting rule; it is not a universal promise for every PoS chain.

Withholding votes and issuing conflicting votes are different failures. Enough offline weight can stop finality even while nodes continue producing or observing blocks. Ethereum's inactivity leak gradually reduces nonparticipants' balances until continuing participants regain sufficient weight. During a prolonged partition, both sides can undergo that process in their own views, making recovery a more difficult question of social coordination. Slashing supplies evidence and consequences for rule violations. It cannot give completely isolated groups information about which history the outside world accepts.

A node that has been offline for a long time faces another problem. Former validators' old keys may sign a self-consistent alternative history after their owners have exited. A new node cannot always identify the socially accepted starting point from a long signature chain alone. Ethereum's weak-subjectivity checkpoint supplies a recent trusted starting state. That external starting point can coexist with independent validation of subsequent blocks. A product should explain where it obtains it.

The surviving history also preserves the gains and losses caused by transaction order. In an automated market maker's pool, one purchase changes the reserves before the next purchase executes. Both transactions can satisfy the protocol rules while their order changes the amounts each buyer receives. Maximal extractable value, or MEV, covers additional value obtained through transaction inclusion, exclusion and ordering during block production. It includes arbitrage and liquidations as well as behavior that worsens other users' trades. Finality fixes an execution result; an application must separately enforce the user's acceptable trade conditions. Checking success and confirmation counts alone misses the price the user has accepted.

In Ethereum's current optional MEV-Boost path, a builder assembles transactions and bids, a relay validates the block and payment conditions, and the proposer signs a blinded block containing the payload header before receiving the full execution payload. Flashbots' description of relay duties explicitly includes validity checks, payment checks and data delivery. This lets proposers use externally built blocks while depending on relays to validate accurately and deliver on time. The complete payload must match the header committed to by the signature; the proposer needs that content to propagate the complete block. Voting thresholds, trade ordering and this delivery path answer separate questions.

Deployment also needs to be separated from the paper. At this report's cutoff, Ethereum had announced Glamsterdam for Sepolia on October 6, with mainnet timing still undetermined. The official announcement therefore does not make ePBS or Block-level Access Lists current mainnet capabilities. A paper establishes conditions for a design, client code prepares it for use, and network activation decides which path today's transactions follow.

5 Faster confirmations make different commitments

Solana exposes confirmation levels directly in its RPC. processed means a node has processed a block; confirmed means more than two thirds of active stake has voted directly for it; finalized corresponds to the cluster state that has reached maximum lockout. The interface documentation can be compared with Agave 4.3.0's selection logic. Changing the commitment and receiving a different height may be exactly the intended behavior.

Mainnet's current Tower vote lockouts strengthen a validator's commitment to a branch through subsequent votes. Proof of History supplies a verifiable timing and ordering structure. Acceptance of history still relies on stake-weighted voting and the associated rules. Calling PoH the entire consensus mechanism leaves out who votes, how forks are handled and why a client waits for a stronger commitment.

Alpenglow is an important change, but it is outside this observation's mainnet guarantees. The official status page lists testnet and devnet as active and mainnet as not activated. At 16:53 UTC on October 2, the official mainnet RPC reported Agave 4.3.0, returned null for getAgGenesisCert, and reported finalized slot 452,669,790. Those observations agree. Publication of a client release does not turn a paper's or roadmap's subsecond target into a measurement of all mainnet transactions.

Sui's Mysticeti disseminates blocks and voting relationships through a directed acyclic graph. References in the DAG supply voting information, allowing dissemination of transaction data to advance consensus as well. Protocol conditions determine which leader blocks are committed or skipped. The paper's static-committee model studies safety and liveness within a fixed epoch using n = 3f + 1 validators, at most f Byzantine validators and assumptions including partial synchrony. Production still needs execution, effects certification, checkpoints and epoch changes. Removing a communication round matters, but its measurement endpoint must be named.

A read of Sui's official GraphQL endpoint at 17:06 UTC on October 2 returned checkpoint 329,496,957, epoch 1268, protocol version 137 and mysticeti_fastpath=true. This is a reproducible configuration observation. It does not measure global latency or show that every transaction takes the same fast path. Shared state, error handling and reconfiguration can take different branches.

Aptos also separates execution from consensus. Block-STM computes a block in its assigned order; it cannot independently decide which block the network accepts. The official mainnet API response retrieved on October 2, 2026 at 17:06 UTC decodes to V5 / JolteonV2 using the pinned algorithm enum and configuration layout. That request did not specify a ledger version; it records the response at the stated time. A client release, a framework proposal and a new consensus paper describe different kinds of state.

That configuration also enables order votes. In the pinned implementation, a round's proposer supplies a block and its parent certificate. Recipients check the proposer, round, certificate and voting safety conditions. Signatures carrying sufficient stake form a quorum certificate, or QC. Receiving a new QC can trigger a separate ordering vote; safety checks and sufficient aggregated weight produce an ordered certificate. It passes the established block path to the executor. A subsequent commit vote binds execution results to the ordered block information. Ordering and execution-result certification therefore have separate steps, with Block-STM accelerating the computation.

If a proposer disappears, validators collect timeout votes into a timeout certificate and advance the round for its designated proposer to continue. Existing certificates and safe-round constraints still govern the next proposal. The safety rules persist voting state and prevent ordering votes in rounds already covered by a timeout. Those constraints separate replacing a stalled proposer from authorizing a conflicting history. They also explain why normal-path latency cannot describe all behavior during missing proposals, round changes and execution backlog.

BNB Smart Chain combines Parlia block production with fast-finality votes. The current source's GetFinalizedHeader() can use both recorded evidence and sufficiently numerous local vote-pool votes to recognize finality earlier. BEP-648 optimizes this observation path. The publisher reports finality in about 0.65 seconds under normal conditions. Applications using other RPCs or waiting for on-chain-verifiable evidence may observe the result later.

TRON's 27 active super representatives take turns producing blocks, with a default slot duration of three seconds. Solidification examines each representative's latest produced height. At least 19 distinct members of the active set must have produced at or beyond the relevant height for it to become solid. The implementation's sorting and index selection is more precise than an instruction to wait for 19 blocks. Repeated production by a smaller group cannot substitute for distinct representatives. Elections and maintenance cycles can change the representative set and some parameters.

These systems can provide fast feedback through different evidence: local processing, direct stake votes, vote lockouts, DAG commits, effects digests or representative-based solidification. A useful interface gives the application that state name, its height and any execution error. A single unexplained green success marker discards distinctions that the protocols themselves deliberately preserve.

6 Can you check the answer yourself?

Most users obtain balances through RPC. A JSON response is a service's report of a result. Independent checking depends on what else the user possesses. Three providers may reduce single-service failure and misreporting, yet shared upstreams, caches or client defects can make them less independent than their names suggest.

A Bitcoin full node maintains and validates the chain it accepts. A lightweight client can verify header work and use a Merkle proof to check inclusion in a block, without executing every transaction and checking every historical input. The whitepaper's simplified payment verification preserves this distinction. Starting from a recent snapshot, pruning old blocks, retaining full history and choosing startup validation assumptions create different operating and recovery costs. Saying that an organization runs a node does not identify those choices.

Ethereum light clients also need a starting point. The pinned initialization procedure aligns the bootstrap header with a trusted_block_root, then validates the sync committee's Merkle branch. Subsequent update checks cover time, committee period, finality branches and aggregate BLS signatures. This reduces download and verification work while introducing explicit dependencies on committee sampling, the starting checkpoint and update rules.

The proposition established by a proof matters. A Merkle proof places a value under a commitment root; it does not by itself establish that the root is the latest honestly executed state. A sync-committee signature supports a header, while execution validity follows the rest of the protocol's conditions. Using an optimistic header or forcing progress after a prolonged absence of finality has different consequences from using a normal finalized header. The specification maintains separate optimistic and finalized states so applications can make that choice.

Data availability poses another problem. A provider can publish a data hash and refuse to supply the underlying data. Once the data is obtained, the hash helps check it; the short hash cannot reconstruct the missing contents. Rollups need appropriate data for independent re-execution, challenges and state recovery. A correctness proof and downloadable data remove different obstacles.

Ethereum's PeerDAS uses erasure coding and distributed sampling to reduce each node's download burden. EIP-7594 and the Fulu availability specification extend blobs into verifiable data columns. Nodes custody and sample subsets; enough columns allow reconstruction. KZG proofs check retrieved cells against commitments, while sampling and propagation support availability. Forging a cell and withholding cells are different threats.

The probability and networking assumptions remain important. Sampling needs sufficiently distributed, communicating participants. Selective responses, partitions and concentrated hosting affect the ability to obtain data in practice. Current specifications also define retention and pruning windows: the mainnet value of 4,096 epochs is approximately 18 days. It does not promise permanent archives. Long-term auditing, disaster recovery and newly joining execution nodes need historical data sources of their own.

A system holding long-lived assets should therefore distinguish data shown to be available today from data it can use to reconstruct state six months later. Consensus and sampling can support the former. Archives, trusted snapshots, indexing and recovery exercises support the latter. A transaction hash alone often cannot reconstruct a complex call's inputs, code and historical state. Retention costs can exist outside the gas bill the user sees.

7 Who checks execution when it moves elsewhere?

On Ethereum L1, full nodes validating execution state process blocks under the rules. A rollup performs much of that execution in another system, then supplies Ethereum with data, state commitments or proofs. This can lower the cost of individual operations, while changing the work L1 performs. Follow one transaction and ask exactly what L1 receives and checks.

Consider the usual derivation path of a chain such as OP Mainnet. A sequencer receives a transaction, executes it and returns a quick result. A batch is later published to L1, allowing other nodes to derive L2 blocks from L1 data. Nodes distinguish unsafe, safe and finalized heads accordingly. A fresh sequencer-only result is easier to replace than one with the required L1 derivation material, and finality of the relevant L1 history further stabilizes its ordering. These labels describe progress of the derived chain. Acceptance of a withdrawal's state claim follows an additional path.

An optimistic proof system permits state claims and allows eligible challengers to dispute errors. If participants agree on starting state and inputs but disagree on the resulting root, they can narrow the disagreement until L1 can adjudicate a single step. L1 need not repeat the entire ordinary computation each time. This requires a real participant to obtain data, run a correct implementation and pay to initiate and continue the dispute within its deadlines.

Arbitrum BoLD organizes disputes so that competing challenges can be handled in parallel, bounding an adversary's ability to delay confirmation through repeated challenges. It retains the assumption of at least one honest participant, with data, capital and timely access to the parent chain. A normal challenge period and the worst-case dispute-resolution bound are different durations. The latter includes two challenge periods, a Security Council grace period and computation margin. Neither number alone describes every withdrawal's arrival time.

Sequencer refusal is a separate problem. Arbitrum's Delayed Inbox lets a user place a message on the parent chain. Once its waiting conditions hold, forceInclusion() checks delay, message position and accumulator commitments before advancing the sequence. The parent chain must be available, the user must pay and construct the message correctly, and execution and settlement must still follow. This is an alternative path during outage or censorship, with a different cost and experience from the normal sequencer channel.

The OP-family L1 deposit path similarly provides a forced entry point, while derivation rules handle sequencing windows and missing batches. Most users clicking withdraw in a frontend have never exercised that recovery route. A product promising exit after its operator disappears needs data access, message construction and proof capabilities beyond its usual interface. Address aliasing, message senders and destination checks also have to remain consistent. Identical hexadecimal addresses in two domains cannot automatically be treated as identical calling identities.

Validity proofs change the checking process. A prover produces evidence for a computation, and an L1 verifier checks it against a program and input/output commitments. Once accepted, the result does not need someone to challenge the same execution error. The proved program can still encode the wrong transition, a circuit or verifier can contain a bug, and upgrade authority can change the accepted program. The system reduces one online-challenger dependency while making the proof system, implementation and deployment configuration more important.

ZKsync Era distinguishes L1 batch commitment, proof and execution. Withdrawals need an acceptable executed state. Its security-delay documentation reduced the minimum execution delay from 21 hours to three, while explicitly retaining extra time for aggregation, proof generation and execution scheduling. The delay leaves room to detect anomalies and freeze the protocol through governance. A correct proof can already exist while the user is still unable to collect the asset.

The ZK label does not automatically imply privacy. Public inputs and state changes can reveal addresses, amounts and calls; confidentiality depends on the actual statement being proved and its public inputs. Similarly, a validium using off-chain data may carry a validity proof while users lack the material needed to reconstruct state or exit. Arbitrum One's Ethereum data-publication path and Nova's committee-based data path also need separate assessments. A shared brand does not merge their guarantees.

For a user trading within an L2, the next contract call often need not wait for every L1 withdrawal condition. Shipping goods, paying a debt elsewhere or releasing collateral in another domain requires stronger evidence. An application's irreversible actions should wait for the corresponding proof and settlement state. Waiting for the longest possible period for everything harms usability; treating every sequencer receipt as final takes additional risk.

8 A Base withdrawal has more than one clock

Base shows how quickly a mainstream-L2 comparison can become outdated. It activated its independent Azul upgrade in May 2026, reduced proof delays with Beryl in June, and changed TEE signer registration with Cobalt on September 30. The official upgrade history marks all three as live. Native 200-millisecond canonical blocks belong to the planned Denim upgrade. Current Flashblocks preconfirmations and future native blocks cannot share an unexplained speed label.

The current proof design accepts two types of evidence. A TEE path re-executes block ranges inside AWS Nitro Enclaves and signs results with registered keys. A ZK path uses SP1 programs to prove results. The first depends on protected execution, remote attestation, approved program images and signer registration. The second depends on the proved program, proof system and verifier. They can strengthen each other, but counting proofs alone does not establish independence: a common transition error or incorrect input commitment can affect both.

In the pinned source, TEEVerifier recovers the signer and checks conditions including registration and the expected image. Cobalt moved the attestation check used for registration on chain, making acceptance of the certificate, image and public key observable. The hardware provider's attestation chain remains a trust source. Moving its checking logic into a contract does not remove assumptions about the hardware and signing identity.

We read finalized Ethereum block 26,106,155, timestamped October 2, 2026 at 17:33:11 UTC. At that block, Base's respected game type was 621, mapped to implementation 0xef9ecea15265321753047ebf7d54c858d53cb94f. The single-proof-type delay was 432,000 seconds, the two-type delay was 86,400 seconds, and the proof threshold was 1: five days, one day and at least one valid proof type, consistent with the post-Beryl rules. These are read-only contract responses from a public node. The requests, responses and block hash are available in the observation appendix.

Those values govern when a state claim can resolve. The pinned resolve() also checks the parent claim, time and dispute outcome. Proof-state update functions adjust expected resolution when proofs arrive, are refuted or lose a working verifier. A second proof arriving later can shorten the remaining wait according to time already elapsed. Deployed parameters are supported by the chain observation; the pinned repository also contains future-upgrade branches and has not been treated as a byte-for-byte verification of the entire deployed implementation.

A user's withdrawal must also pass the Portal. The user initiates it on L2, proves on L1 that it belongs to a state root, and finally requests execution. The selected state claim must be acceptable, the proof must mature, and pause and replay checks must pass. At the same fixed block, the Portal's proof-maturity delay was 86,400 seconds, the AnchorStateRegistry's additional finality delay was zero, and the Portal was unpaused. Claim and proof clocks may overlap. Late proving, a replacement claim or a dispute may delay them, so mechanically adding the two durations gives the wrong model.

A conditional example makes the timing concrete. Suppose a state claim that includes the withdrawal receives its first proof type at t0, setting expected resolution to t0 + 5 days. The second proof type arrives two days later. The code takes min(now + 1 day, previous expected time), moving resolution to t0 + 3 days. If the user submits the withdrawal proof to the Portal at t0 + 2.5 days, that proof matures at t0 + 3.5 days. Both time conditions are satisfied only at the later point; parent acceptance, absence of pauses and disputes, and the other checks still matter. This calculates a parameterized example, not the measured duration of a real withdrawal.

Final execution deserves its own check. The Portal's destination call may fail, and final asset or message usability depends on the messenger, bridge and target contract above it. The withdrawal specification therefore retains separate initiation, proving and finalization actions. A third-party liquidity bridge can pay on the destination first and wait for protocol settlement itself. Faster access to funds then adds the bridge, liquidity provider and particular asset path to the user's risk.

Administrators can also intervene in emergencies. Safe reads at the fixed block show an outer management Safe requiring both of its two owners. Those owners are Coinbase's 3-of-6 Safe and the Security Council's 8-of-11 Safe. These are nested thresholds, with both groups required to satisfy their own conditions. The role description connects these actors to upgrades and emergency controls. Address counts describe a set of keys; institutional independence, custody and organizational correlation require separate investigation.

This changes how Base should be assessed. It has concrete proving and exit mechanisms, whose current parameters, hardware path and administrative control belong in the same trust model. Applications holding assets over time need data access, alternative submission paths and a clear account of who can pause or change exit conditions. Built on Ethereum and a one-day withdrawal are both incomplete descriptions of that system.

9 Crossing chains needs an answer on both sides

A native transfer needs one state machine to accept its outcome. A cross-chain transfer commonly locks or burns an asset on chain A, presents chain B with a message about A, and releases or mints a corresponding asset on B. The receiving chain must establish origin, occurrence, non-replay and sufficient stability of the source result. A bridge joins two previously separate sets of failure conditions into one user operation.

Cosmos/IBC provides a concrete implementation. Cosmos here denotes an ecosystem and protocols; its chains have their own validators and governance. It is not one chain sharing all security properties. A common Tendermint light-client path stores trusted source-chain state on the receiver and verifies later headers and validator-set changes. Relayers transport headers, packets and proofs. They can delay delivery, while a correctly functioning client still rejects evidence inconsistent with its trusted roots.

The client-update path checks trusted validator information, time and valid voting relationships. Client status distinguishes frozen and expired clients. The trusting period must be shorter than the unbonding period, allowing trust to be updated while the old validator set remains subject to the relevant constraints. An expired client cannot indefinitely accept fresh messages from its old root. Recovery depends on the chain's implementation and governance.

Packets have a state machine too. In ibc-go 11.2.0, RecvPacket() checks channel and connection state, counterparty identifiers, timeouts, membership proofs and duplicate receipt. A verified header establishes a root. The packet must still prove membership under that root and satisfy the channel's current conditions. The existence of arbitrary bytes on a source chain does not authorize the destination application to execute them.

The process is asynchronous. Successful receipt produces an acknowledgement that the sender later processes. If receipt has not occurred under provable timeout conditions, the corresponding timeout path applies. That normally still requires another transaction and a valid proof; closing the browser cannot undo an operation already performed on the source chain. Applications need to distinguish pending, acknowledged, refundable and refunded states so temporarily intermediate assets are neither counted twice nor reported as lost.

The light-client path concentrates risk in source consensus, trusted initialization, update rules, proofs and application code. A bridge using a signer group to attest messages adds that group's correct observation and authorization. A prepaid-liquidity bridge adds capital availability and settlement-failure exposure. Similar buttons and arrival times can therefore rely on quite different evidence for releasing value.

Asset names add another ambiguity. A destination token may be issued directly by its issuer, represent locked assets, wrap a multi-hop bridge claim or substitute an asset through liquidity. Chain consensus enforces the token contract's rules; it cannot independently guarantee off-chain reserves, redemption rights or the issuer's freeze policy. Asset identification needs to follow a specific contract through issuance, backing and redemption. A ticker does not provide that proof.

Cross-chain deployment should consequently have a specific benefit when the business mainly interacts within one chain. Where crossing domains is necessary, choose an explainable path for source confirmation, message verification, destination execution and failure recovery before comparing fees. Removing a hop can remove one verification and recovery stage, while the remaining bridge still needs its own justification.

10 Who can make progress resume?

Formal consensus models often bound malicious or offline participants. Production adds a different failure: most nodes run the same defective implementation and stall on the same input. More nodes then do not create sufficiently independent behavior. Distribution of stake and operators matters, alongside correlation in code, cloud services, builds and update paths.

Solana's February 6, 2024 postmortem documents this kind of failure. In LoadedPrograms, a legacy loader's special deployment-slot value conflicted with a real slot for an evicted program, producing repeated loading and compilation. More than 95% of active stake was then running the affected 1.17 series, so a common implementation defect stopped progress. Recovery used the temporary restriction in 1.17.20 and a coordinated restart. That is a historical repair boundary, not evidence that today's releases retain the bug.

Sui's January 2026 postmortem shows a different protective behavior. An interaction between consensus garbage collection and conflicting transactions produced different checkpoint digests. Enough weight could not certify a common result, so progress stopped at certification. RPC could still return previously certified state while new state failed to advance. Being able to query an old balance and having a progressing network are distinct properties. Monitoring only HTTP 200 responses misses the failure.

The May incidents show why repairing one execution branch may leave recovery state broken. After a mixed address-balance gas path failed, some canceled transactions still debited balances, causing underflow during later system settlement. A temporary patch skipped debits for one cancellation reason, but another branch overwrote that reason and exposed the problem again. A subsequent restart encountered a distributed-randomness failure state that had not been persisted. Pending transactions could neither complete normally nor be canceled under the original failed state, leaving epoch draining waiting. The three incidents connect execution, cancellation, persistence and reconfiguration.

These cases support a testable engineering judgment: recovery must include stopping midway and restarting. A successful-transaction test and a cleanly rejected input do not validate residual locks, uncertified effects, unsettled fees or epoch handover. The incidents also cannot directly rank today's chains by failure rate. Disclosure scope, observation periods and business-loss measurements differ.

Rollup recovery additionally involves actors who can change L1 contracts. OP Mainnet's current security arrangements distinguish Foundation and Security Council roles and retain controls over pausing, state claims and upgrades. Arbitrum's current constitution permits emergency action by a 9-of-12 Security Council, while routine governance follows voting and execution delays. Organizational commitments define when authority should be used; contract permissions define what it can technically do. Both matter.

Emergency powers have a practical benefit: a pause can prevent a proof-system flaw from turning an invalid result into a rapid loss of funds. The same authority can make legitimate exits wait for administrators or expose them to upgraded rules. An immediate emergency-upgrade path also limits what an ordinary timelock can promise about advance exit opportunities. Separating pause, upgrade, proof invalidation and asset-transfer authority explains more than one decentralization label.

Base-chain upgrades mainly rely on client implementation, validator adoption and broader coordination. Merging code is not network activation, and adoption by a minority does not establish a new rule. If an application's nodes and RPC providers use different rules or heights, their responses can disagree while each looks superficially healthy. Recovery needs a trusted chain head, state validation, a client-upgrade path and a decision about when irreversible business may resume.

One more failure exists outside the protocols: the chains and bridge can behave correctly while the application misaccounts. An indexer may fail to undo a reorganization, a retry may repeat an external payout, or a failed destination call may be recorded as completed cross-chain business. Protocol states and proofs belong in accounting and idempotency logic. Chain finality cannot repair a second bank payment already sent by mistake.

11 Put the work back into transactions per second

After following the processing paths, performance figures become easier to question. One paper measures executor transactions, another consensus messages, and a third counts 100 transfers inside one transaction as 100 operations. Each may accurately describe its experiment. Placing all three in a TPS column removes their common unit.

The Block-STM paper reports about 170,000 transactions per second in its Aptos execution environment under a particular low-contention workload, and about 110,000 in Diem. It uses an AWS c5a.16xlarge instance with 32 physical cores and 128 GiB of memory, varies accounts and block sizes for synthetic peer-to-peer transfers, and repeats runs. The endpoint is parallel execution. Result persistence is excluded from the throughput figure, and network dissemination and consensus are outside that endpoint. It supports the executor's ability to exploit parallelism, without establishing end-to-end settlement speed.

The counterexamples matter as much. Two highly contended accounts sharply limit parallel benefit, while scheduling and validation still cost work. More dispersed accounts leave threads greater independence. Serial controls and varying thread counts help explain the difference. An application with thousands of users competing for one liquidity pool should inspect contention and tail behavior before the low-conflict peak. Treating the best workload as typical avoids the question that selection needs to answer.

Mysticeti's raw consensus experiments use 512-byte messages across regions and measure ordered commitment, including implementation costs such as logging. That endpoint is not a production virtual machine, state persistence and user-effects certification combined. A separate private Sui integration uses 137 validators, an offered load of 5,000 transactions per second, and specified machines and regions, reporting approximately 650 milliseconds at p50 and 975 at p95. This is closer to an application path, yet remains a historical result for that controlled configuration.

Lutris's demonstration above 150,000 operations per second uses programmable transactions containing 100 transfers each. Roughly 1,500 such transactions therefore correspond to 150,000 transfer operations. It uses the historical Sui 1.4.3 implementation, 100 validators, dedicated load generators and specified persistent-storage conditions. Batching usefully amortizes signing and scheduling. A comparison still needs both transaction and operation denominators.

Three paper results with different questions and endpoints. These are the authors' measurements, not SOSEC reruns.

Production metrics have their own denominators. Consensus votes, system transactions, failed transactions, user transactions and internal calls cannot be exchanged freely. Counting only successes hides requests that never completed during congestion. Counting every included transaction as successful business hides failures and fees. At minimum, preserve submitted, included, successfully executed and target-confirmation counts, with an observation window and deduplication method.

Latency needs endpoints too. Submission to sequencer response measures ingress and preconfirmation. Submission to a globally verifiable final result also includes propagation, consensus or proving. The median describes the middle request; p95 and p99 come closer to the user's complaint that some operations take much longer. If a sustained workload makes the queue grow indefinitely, a brief throughput peak does not describe sustainable service.

Costs cannot be represented by the cheapest transfer alone. Ethereum L1 computation, storage and congestion pricing, rollup execution and data publication, batch amortization, and high-performance-chain resource constraints can dominate different workloads. Low transaction fees may coexist with subsidies, demanding node hardware or external proving costs. Compare the total cost of completing the same business operation to the same endpoint, including failures, retries, bridging and necessary data services.

A rigorous follow-up benchmark could start with dispersed-account transfers, transactions contending on one state item, and contract calls with realistic state growth. It would fix inputs and success criteria, report hardware, bandwidth, storage, client versions, duration and repetitions, and separately measure execution and final confirmation. This report has not performed that cross-chain experiment, so incompatible historical measurements cannot select a fastest mainnet. They can identify which claims apply to which work and where comparable evidence is still missing.

12 Choose around the application's consequences

An application primarily holding and transferring native bitcoin, and willing to manage reorganization risk through work-based confirmations, gets a relatively explicit verification object from Bitcoin's UTXOs and script rules. Wrapping the asset elsewhere to obtain different contract capabilities adds custody or verification relationships. A required capability must justify that added dependency; the destination's throughput figure leaves this relationship unexplained.

Complex composable contracts can benefit from Ethereum and the EVM ecosystem's existing tools, assets and audit experience. Executing directly on L1 avoids an additional external sequencer, proof and exit state machine, while facing L1 fees and throughput constraints more directly. Rollups make many routine operations cheaper for applications able to understand cross-layer state. A particular rollup should be selected using its current proving, data and upgrade arrangements. Ethereum consensus properties do not automatically describe every upper-layer component.

For frequent interactions within one chain, Solana's explicit account access, Aptos's speculative execution and Sui's object dependencies offer different opportunities. Implement the most contended application path first, observe conflicts and retries, and then assess the benefit of changing language or state model. Independent asset operations and shared matching logic may suit different layouts; even on one chain, they need not have the same scaling curve.

A system focused on existing stablecoin payments or established integrations may choose TRON, BNB Smart Chain or another ecosystem because that is where recipients operate. Representative sets, solidification or finality interfaces, resource fees, issuer policies and available custody then all matter. This report has not measured payment market shares, and market share cannot validate a permission design. Business compatibility is a real requirement that can be considered alongside explicitly accepted trust conditions.

A team needing control over execution and upgrades may consider an application chain and interoperability such as IBC. It also inherits responsibility for validators, client updates, bridges and operations. Dedicated blockspace can isolate unrelated demand, while a smaller validator economy, interchain dependencies and recovery coordination create other costs. More chains usually mean more state machines to maintain. Specific isolation, autonomy or workload requirements make that cost assessable.

Each option needs a failure scenario. Suppose the default RPC stops updating, the sequencer refuses transactions, a prover goes offline or one end of a bridge pauses. Which verified state can the application still see, what can its users submit, and who can restore progress? Dependence on a service with no usable alternative belongs in the product promise. It can be a rational engineering choice; users should not discover it for the first time during a failed withdrawal.

I favor systems that expose state clearly, preserve independently verifiable material and make recovery usable. Concrete evidence can change that preference. Publishing recoverable data, opening a previously restricted proving role or adding an effective exit delay to administrative changes improves the relevant assessment. A faster interface that takes away the user's ability to verify the result can make an earlier choice worse.

13 How to reproduce the comparison, and what remains open

This is a systematic evidence review and mechanism comparison of a representative protocol sample. Inclusion requires a continuing technical ecosystem or clear mainnet deployment, publicly checkable critical specifications and implementation, and a meaningful addition to the research questions. Bitcoin, Ethereum and representative rollups cover different settlement routes. Solana, Aptos and Sui expose different execution dependencies. BNB Smart Chain and TRON add representative-producer and confirmation interfaces, while IBC shows how heterogeneous chains verify messages. The sample covers important design differences without claiming to include every chain called mainstream.

Research and state checks run through October 3, 2026. Extraction follows transaction inputs, acceptance conditions, stopping points and actors able to change rules, comparing papers, official specifications, pinned source, activation records and postmortems. Performance evidence separately records units, workload, hardware, endpoints and exclusions; incompatible results receive no aggregate score. Historical papers explain a design's assumptions, while activation records and anchored observations identify the current path. Early Gasper parameters and the older Lutris certification flow are treated accordingly.

The JSON appendix preserves implementation versions, fixed sources, read-only queries and raw responses. Base parameters and Safe owners come from one finalized L1 block. Sui, Aptos and Solana observations retain endpoint, time and height. The Aptos API node build differs from the source tag; compatible configuration layout is used only to decode fields. Historical rechecking may require an archive service, and current state cannot replace an old snapshot. A single RPC response also cannot establish global agreement or long-term availability.

Cardano, XRP Ledger, Stellar, Avalanche, NEAR and Polkadot have not received equivalent treatment, limiting overall coverage. The study also lacks comparable validator-entity control maps, quantified infrastructure common-mode risk and long-running workload experiments. It does not independently replay every chain, verify all proxy bytecode and storage slots, or audit every proof system and asset-redemption arrangement. The Alpenglow assessment is limited to activation status, without independent review of its complete formal proof. Decisions relying on those properties need further evidence.

The conclusions apply to publicly implemented conditions for accepting, checking and releasing results, and to what the cited performance experiments support. Future incident probabilities and the best choice for each application require longer observation, more specific business inputs and comparable experiments.

14 Make completion fit the next action

Blockchains expose decisions that a conventional service often keeps inside its backend: who can write, how nodes check the result, which history survives a conflict, how errors are challenged and what authorizes release of an asset. That visibility has value when applications actually follow the rules to interpret results. The wallet's green check mark is one convenient display point along the path.

Sound selection aligns that point with what the user does next. An interface can respond early, fulfillment needs its own confirmation policy, and bridging or withdrawal continues through proof and destination execution. When users understand the wait, operators can locate a failure and independent participants can verify and recover state, confirmation becomes a promise that the system can meaningfully support.