Bitcoin's about 7 transactions per second ceiling helped define the blockchain scalability problem. A separate comparison places Visa at roughly 2,000 transactions per second, a gap that explains why the industry spent the next decade pursuing faster consensus, parallel execution, and better network propagation rather than treating the original architecture as sufficient (Scalable Blockchains Survey).
That history matters, but the usual response is still too shallow. Vendor decks lead with peak TPS, while production teams need to know whether deposits arrive reliably, whether settlements become final within the liability window, whether RPC failover creates duplicates, and whether finance can reconcile every state change. A high performance blockchain is useful only when its speed survives realistic workloads and connects cleanly to wallets, signing, broadcast, events, and accounting.
Table of Contents
- Why Peak TPS Is the Wrong Question
- The Four Metrics That Actually Define Performance
- Consensus and Execution Approaches Compared
- The Hidden Relationship Between Throughput, Latency, and Finality
- Matching Architecture to Workload in Practice
- Operational Requirements Beyond the Chain
- Risks, Controls, and What to Verify Before Go-Live
Why Peak TPS Is the Wrong Question
Peak TPS is a laboratory result, not a production SLA. A benchmark may use simple transfers, controlled hardware, favorable geography, empty mempools, and no competing smart-contract execution. Your application has users, retries, fee pressure, state growth, validator distribution, wallet policies, and operational exceptions.
The historical comparison matters for one reason: it shows why a lab maximum does not predict production behavior. Use the roughly 7 TPS versus 1,273 TPS gap to frame workload replay, not to rank vendors. The Blockbench study measured controlled conditions, while a payments operator must test p95 inclusion during congestion, retries across RPC providers, and competing transaction traffic.
Measure the workload, not the slogan
Define performance across four dimensions:
- Sustained throughput: Transactions per second maintained with representative payloads, contract paths, signatures, and contention.
- Inclusion latency: Time from submission to inclusion, reported at p50, p95, and p99 rather than as an average.
- Settlement finality: Time until the accounting system can treat a state transition as safe.
- Scalability under change: How throughput, latency, and finality degrade as validator count, geographic spread, state size, and concurrent users increase.
Ask the vendor to replay your workload. A simple transfer test does not represent a betting payout, a stablecoin payment with policy checks, or a trading transaction competing for ordering. It also says little about an embedded wallet that must coordinate signing, nonce management, broadcast retries, event delivery, and ledger reconciliation.
That bridge from consensus to product operations is the practical evaluation point. Faster block production helps only if wallet requests reach the network reliably, broadcasts do not create duplicates, events arrive in an auditable sequence, and ledger state remains consistent under failure.
Practical rule: Treat peak TPS as a capacity ceiling. Use sustained workload throughput, p95 latency, finality, and degradation curves as buying criteria.
Avoid headline-speed procurement. Select the architecture that meets the workload, then verify its consensus, execution, wallet, broadcast, and accounting behavior under production-like pressure. Chain performance matters, but it does not operate a financial product by itself.
The Four Metrics That Actually Define Performance
Each metric answers a different operational question. Combining them into one speed number hides the failure mode that matters most to customers.
Throughput
Throughput is the number of successfully processed, relevant transactions per second. Measure it as sustained TPS over a defined workload, with transaction type, payload size, execution path, and concurrency recorded. A network that handles a high peak for a short test but queues ordinary production actions under load hasn't met the requirement.
Latency
Latency measures elapsed time, usually in milliseconds or seconds, from submission to inclusion. Break it into broadcast propagation, mempool admission, ordering, block production, and execution. Report p50 for the typical user and p95 or p99 for the tail, because a payment product can feel unreliable when the median is fast but a meaningful tail waits.
Finality
Finality is the point at which a transaction can be treated as settled under the chain's consensus model. Measure it in milliseconds or seconds from submission or inclusion, and document whether it is deterministic or probabilistic. Probabilistic confirmation may be adequate for some low-risk actions, while treasury movement and liability accounting may require a stronger settlement rule.
Scalability
Scalability describes how the other metrics behave as the system grows. Measure throughput, latency, and finality while increasing validator count, geographic distance, state size, transaction complexity, and concurrent workload. Consensus research shows why this matters. In one empirical comparison, PBFT throughput fell from about 1,200 TPS at 4 nodes to about 218 TPS at 100 nodes, while PoW, PoS, and DPoS remained comparatively steadier as node count increased (consensus and sharding study).
| Metric | Unit of measurement | What it actually measures |
|---|---|---|
| Throughput | Sustained transactions per second | Completed workload capacity |
| Latency | Milliseconds or seconds, reported by percentile | Time to inclusion and user-visible response |
| Finality | Milliseconds or seconds to deterministic or accepted settlement | Time until accounting can safely recognize the outcome |
| Scalability | Metric curves as nodes, state, and load increase | Whether performance survives production growth |
These dimensions conflict. Larger blocks can raise nominal throughput but take longer to propagate. Shorter production intervals can reduce waiting time but leave less room for validators to receive, verify, and vote on data. Faster execution doesn't compensate for a slow or uncertain settlement rule.
A vendor SLA should name the workload, percentile, finality condition, validator environment, and congestion profile. Without those terms, “fast” is a product adjective, not an engineering commitment.
Consensus and Execution Approaches Compared
Consensus sets the settlement rules, but production performance also depends on mempool design, execution parallelism, sequencer behavior, data availability, and fee markets. Those choices determine whether an embedded wallet can submit reliably, whether broadcast services receive predictable confirmation signals, and when ledger operations can book a transaction.
Nakamoto-style longest-chain consensus, associated with Bitcoin and pre-merge Ethereum, supports open participation and probabilistic settlement. For these chains, the approximately 7 TPS figure reflects the cost of open participation and probabilistic settlement, which extends the finality window a ledger must wait before booking settlement. The trade-off is clear: broad participation and neutrality come with slower effective settlement and exposure to reorganizations.
BFT finality gadgets, including Tendermint and HotStuff variants, coordinate a validator set toward faster agreement. They can provide deterministic or near-deterministic settlement, but validator communication and quorum requirements add network and processing costs as the set grows. The PBFT measurements discussed earlier illustrate how validator count can affect throughput, so a vendor's node-count assumptions deserve scrutiny.
DAG-based mempools, including Narwhal, Bullshark, and AptosDAG designs, separate data dissemination from ordering. This separation can reduce bottlenecks between transaction arrival and consensus ordering. It also increases implementation complexity, and the chain still needs a defined finality model before wallet balances or financial ledgers can treat a result as settled.
Optimistic and ZK rollups move execution away from a base layer while using that layer for settlement, dispute handling, or proof verification. They may raise application capacity, but evaluation must include sequencer dependence, withdrawal timing, data availability, proof costs, and MEV exposure. A faster execution path does not automatically provide immediate settlement or reliable broadcast behavior.
Published figures show why benchmark context matters. One comparison reported Solana at around 65,000 TPS on its published mainnet benchmark, with finality around 400 milliseconds. A separate industry comparison summary reported average figures of about 1,053.7 TPS for Solana, 854.1 for Sui, and 378.3 for BNB Chain (industry comparison summary). These measurements describe different conditions, so peak capability cannot stand in for sustained production capacity.
Ethereum L1, Arbitrum, and Optimism can suit different security, liquidity, composability, and settlement requirements. A lower-throughput environment may be the sound choice when decentralization, ecosystem access, or base-layer settlement outweighs immediate execution capacity. The decision is which combination of consensus, mempool, sequencer, execution environment, and settlement layer fits the application's risk and ledger requirements.
The Hidden Relationship Between Throughput, Latency, and Finality
A chain can be fast in one dimension and slow in another. A 400 millisecond slot time doesn't mean a transaction has deterministic finality in 400 milliseconds, because the chain may require additional blocks, votes, or settlement conditions before downstream systems can rely on it.
Propagation is the first constraint. Every block must reach validators, and pushing data toward network capacity increases the time available for inclusion and voting. Research on permissionless consensus describes this relationship directly, noting that block propagation delays reduce throughput and that higher data rates increase waiting time (permissionless consensus paper).
Read the tail, not the average
Mempool congestion often inflates latency before the chain reaches a visible throughput ceiling. Users submit transactions, fees change, ordering queues lengthen, and replacement or retry logic adds more pressure. A system can appear healthy at the median while its p95 and p99 experience becomes unacceptable for withdrawals, game outcomes, or payment authorizations.
Track at least these signals:
- p50 inclusion latency: The normal path for a typical request.
- p95 inclusion latency: The experience that exposes routine congestion and infrastructure variance.
- p99 inclusion latency: The operational tail that drives support tickets and manual intervention.
- Finality delay: The time from inclusion to the settlement threshold your product uses.
- Reorg depth: The number of replaced blocks or state transitions your downstream logic must unwind.
Reorganization depth is the silent variable. A probabilistically confirmed transaction may look fast to a wallet interface, yet a finance system must account for the possibility that the observed state changes. That makes the effective settlement rail slower than the first confirmation suggests.
For payment and trading teams, the right benchmark introduces controlled congestion, geographic distribution, realistic state, retries, and competing transaction types. A workload-specific benchmark study argues for repeatable scenarios and quantifiable metrics rather than undifferentiated marketing claims (benchmark guidance). The practical question is not whether a chain can move quickly in a quiet test. It's whether the full stack can preserve acceptable tail latency and safe finality when the network is busy.
For a broader application of these principles to stablecoin flows, see stablecoin payment infrastructure.
Matching Architecture to Workload in Practice
Consider an iGaming operator accepting stablecoin deposits and issuing payouts. The visible product event is a bet, but the infrastructure path includes a player wallet, broadcast service, chain confirmation, settlement logic, and an internal balance update.
A player submits a transaction from an embedded wallet. The application signs according to the wallet policy, sends the transaction through a broadcast layer, and receives an event when the network observes it. The operator shouldn't treat “broadcast accepted” as “funds settled.” It needs separate states for observed, included, sufficiently confirmed, and final according to its risk policy.
One bet, several infrastructure decisions
Chain selection affects player experience, liquidity, fee behavior, and settlement confidence. A team might use one chain for player-funded wallets and another for treasury settlement if the first offers better user access while the second provides the desired institutional settlement properties.
Broadcast redundancy matters more than a peak benchmark when a player is waiting for a deposit or payout. The service should manage multiple RPC routes, monitor health, preserve the transaction identity, and avoid creating a second business action merely because the first submission response timed out.
Settlement confirmation determines when the operator books a liability, releases a withdrawal, or updates an available balance. The chain's finality model must map to the operator's accounting policy, not to a generic wallet screen.
Embedded MPC wallets determine how player and treasury keys are controlled. Per-player or per-agent wallets can separate balances and permissions, while a client-controlled co-signer can preserve operational approval outside a single service boundary.
Design the state machine explicitly
The application should model each transaction as a state transition with an event trail:
- Submitted: The business action creates a signed transaction request.
- Broadcast: The network gateway accepts the transaction for propagation.
- Observed or included: The chain reports the transaction and later places it in a block.
- Settled: The confirmation policy or deterministic finality rule is satisfied.
- Reconciled: The operating ledger records the external event against the internal balance and liability.
This separation prevents a common failure. If the wallet UI updates on submission but the ledger updates only after settlement, product, operations, and finance can see different balances for the same player. Real-time WebSocket events help deliver deposit, confirmation, withdrawal, and policy outcomes, but the ledger remains the system of record for business state.
The workload therefore selects the architecture. Raw TPS influences capacity planning, while broadcast reliability, finality, signing policy, and reconciliation determine whether users and finance teams experience a dependable product.
Operational Requirements Beyond the Chain
A fast chain doesn't manage your keys, prevent duplicate business actions, or reconcile external state with internal books. Those controls belong in the application and settlement layer.
MPC threshold signing lets a quorum of key shares authorize a transaction without reconstructing the full private key on one device. For production operations, signing sessions should retain a session ID, participant IDs, approval IDs, the message hash, and the final signature hash so auditors and incident responders can reconstruct what happened (web3 MPC operational guidance).
Scoped API keys and role-based permissions should restrict which service can create wallets, request signatures, broadcast transactions, or initiate payouts. A hot operational path needs policy boundaries, spend limits, approval rules, and a client-controlled Co-Signer, not one unrestricted credential.
Make retries safe
High-volume APIs commonly use signed timestamps and nonces to reject stale or replayed requests. Freshness windows often fall between 30 and 120 seconds, and a nonce should not be accepted twice inside that window (replay protection guidance).
Payment-style endpoints also need idempotency keys. If an RPC route times out after accepting a transaction, a retry should return the original stored result rather than execute the payout again. One documented platform uses a 30-minute cache window for idempotent retries, demonstrating the need to define the retention period rather than leave it ambiguous (idempotency documentation).
| Workload Concern | Required Control |
|---|---|
| Key compromise or excessive authority | MPC threshold signing, scoped keys, policy approvals, and per-key spend limits |
| RPC timeout and failover | Idempotency keys, transaction identity tracking, and duplicate detection |
| Replayed requests | Signed timestamps, nonces, freshness validation, and replay logs |
| Congested fee markets | Gas estimation, replacement rules, stuck-transaction queues, and dead-letter handling |
| Uncertain settlement | Confirmation policies, reorg handling, and dual-ledger state |
| Audit and finance review | Append-only records, signed transaction trails, and reconciliation reports |
| Operational blind spots | WebSocket events and metrics for mempool depth, confirmations, failures, and reorgs |
An append-only operating ledger turns blockchain activity into traceable internal state transitions. Ledger guidance recommends cryptographically attested append-only records, while stablecoin payment infrastructure commonly pairs double-entry postings with bi-temporal history so external events can be reconciled against internal books (append-only ledger documentation).
BroLabel provides one implementation option for this operating layer, combining embedded MPC wallets, network broadcast, WebSocket events, an append-only ledger, and settlement APIs across supported networks. The important point isn't the vendor name. It's that these controls must be designed together, whether the underlying network advertises 1,000 TPS or 100,000 TPS.
For custody architecture and signing boundaries, compare the operational model with digital asset custody.
Risks, Controls, and What to Verify Before Go-Live
A vendor decision should end with evidence, not a benchmark slide. Group the risks into consensus, application, and operations, then require a control and an observable signal for each.
Consensus-level risks include reorg depth, uncertain finality, and validator concentration. Require documented finality assumptions, measured reorg history, and a validator distribution review. Infrastructure-level risks include RPC outages, mempool behavior, propagation delays, and congestion failures. Test failover with latency health checks and confirm that retries preserve transaction identity.
Operational risks include key custody, authorization errors, duplicate broadcasts, and reconciliation gaps. Require MPC key-share attestation, scoped permissions, replay-safe nonces, idempotency records, and a dual-ledger confirmation process. A structured set of decision criteria for risk frameworks can help teams document ownership, tolerance, evidence, and escalation before launch.
Require day-one observability
A serious buyer should see:
- Workload throughput: Per-second results on the actual transaction mix.
- Tail latency: p95 and p99 confirmation latency, not only averages.
- Consensus health: Reorg alerts, finality delays, and validator-related incidents.
- Signing health: Signer failures, policy denials, and the available error budget.
- Accounting alignment: Settlement-versus-broadcast divergence counters and unresolved ledger items.
Before go-live, decide whether the product needs single-chain execution, multi-chain broadcast, or wrapped-asset settlement. Let the evidence decide. If failover tests expose duplicate risk, fix idempotency before adding capacity. If finality doesn't match liability accounting, change the settlement policy or architecture. If the wallet layer can't provide auditable signing and ledger events, a faster chain won't make the system production-ready.
For a focused review of signing architecture, see MPC wallets.
BroLabel provides API-first infrastructure for embedded MPC wallets, network broadcast, settlement workflows, WebSocket events, and an append-only operating ledger. Visit BroLabel to evaluate a modular path from workload testing and sandbox integration to controlled production operations.
