What Sub-Second Finality Means for BSC Settlement

TL;DR

• BSC blocks can now reach deterministic finality in about 0.65 seconds under normal conditions, a 70x improvement since 2022.
• The old 15-confirmation rule comes from BSC’s previous probabilistic finality model.
• Exchanges, bridges, and payment processors should use the finalized JSON-RPC block tag where possible.
• Faster blocks plus BEP-126, BEP-590, and BEP-648 brought finality down from roughly 45 seconds.

Many BSC integrations still wait around 15 confirmations before treating a transaction as safe.

That rule dates back to when BSC had three-second blocks and probabilistic finality. Fifteen confirmations meant waiting roughly 45 seconds for enough blocks to build on top of a transaction.

However, BSC works differently today.

With Fast Finality, blocks can become cryptographically final in about 0.65 seconds under normal conditions.

Why 15 confirmations became the rule

Before Fast Finality, BSC used probabilistic finality.

Each new block reduced the chance of a reorganization, but there was no exact point where the protocol could prove a block was irreversible. Services therefore waited for additional confirmations as a safety margin. With three-second blocks, around 15 confirmations meant roughly 45 seconds.

It worked for that version of BSC, but not today.

What changed

BEP-126 introduced deterministic Fast Finality in 2023. Validators vote on blocks. Once at least two-thirds support a block and its direct child, the earlier block becomes finalized.

BSC then shortened block times through upgrades including Maxwell and Fermi, bringing block intervals down to 0.45 seconds.

Two further changes improved finality at those speeds:

• BEP-590 made validator voting more reliable as blocks became faster.
• BEP-648, shipped through the Osaka/Mendel upgrade, allowed nodes to recognize a voting quorum already held in memory instead of waiting for another block.

Together, these changes reduced BSC finality from roughly 45 seconds to about 0.65 seconds, a 70x leap.

What builders should be asking now

For most integrations, the better question is no longer asking how many confirmations they should wait for, but rather “has this block been finalized?”

BSC exposes finalized state through JSON-RPC: eth_getBlockByNumber("finalized", true)

Exchanges, bridges, custodians, and payment processors can use this signal when deciding when a transaction is safe to credit.

What this means for the ecosystem

For most smart contracts, nothing changes. The impact is mainly on infrastructure that waits before acting on deposits or transfers.

Integrations still hard-coding 15 confirmations can review whether that delay is necessary. Using finalized state can reduce waiting time while giving applications a stronger settlement signal.

If Fast Finality temporarily stops progressing, applications that require deterministic settlement can simply wait until the block is reported as finalized.

What’s Next

BNB Chain continues to study how finality should work as block times become shorter, as outlined in the BNB Chain Tech Roadmap 2026.

BEP-667 is one draft proposal exploring how voting cadence could be separated from block cadence. It remains research, not a deployed change.