Research · 22 min read

When is a blockchain payment final? Probabilistic and deterministic finality, from Bitcoin to TRON

Every exchange, wallet and payment service has to decide when an incoming transfer is safe to credit. This article examines what “final” means on a blockchain, how the probabilistic finality of Bitcoin differs from the deterministic finality of Byzantine fault-tolerant systems, what the numbers in Nakamoto’s whitepaper actually say, and how these ideas shape the confirmation policies of custodial platforms.

1. Introduction

A payment is only useful if the person receiving it can rely on it. A shop that hands over goods, an exchange that lets a customer trade a deposit, or a custodian that credits a balance all have to answer the same question: from which moment can this transfer no longer disappear?

For card payments and bank transfers, the answer is written down in contracts and law. For blockchains, there is no central operator who can declare a payment final. Thousands of independent computers must agree on a single history of transactions, and the rules by which they reach that agreement — the consensus protocol — determine when, and how firmly, a transaction becomes part of that history.

This article explains the main models of blockchain finality, the mathematics behind them and the incidents that show where they break down. It ends with principles that custodial platforms can apply when they decide how many confirmations to wait for.

2. Finality in traditional finance

The international standards for payment and settlement systems, the Principles for Financial Market Infrastructures published by the Committee on Payments and Market Infrastructures and IOSCO, require that a system provide clear and certain final settlement, at a minimum by the end of the value date [1]. In the European Union, the Settlement Finality Directive protects transfers in designated systems from being unwound, even if a participant becomes insolvent [2].

Two features of this model matter for what follows. First, finality is defined by rules: a transfer is final because the rule book and the law say so, not because reversing it is technically impossible. Second, there is an operator who is responsible for enforcing those rules. Public blockchains have neither. Their finality has to come from the protocol itself.

3. Three kinds of blockchain finality

The literature distinguishes three related ideas, which are often mixed up in practice:

• Probabilistic finality. The probability that a transaction is reversed decreases as more blocks are built on top of it, but it never becomes exactly zero. This is the model of Bitcoin and other chains that use Nakamoto consensus.
• Deterministic finality. A transaction is final once a defined quorum of validators has agreed to it. Under the protocol’s assumptions, a final block can never be reverted. This is the model of Byzantine fault-tolerant protocols.
• Economic finality. Reversing a transaction would cost an attacker more than it could gain — for example because the attacker would have to buy enormous computing power, or because validators who sign conflicting blocks lose their stake.

Real systems combine these ideas. Bitcoin’s probabilistic guarantee rests on the economic cost of computing power; Ethereum adds deterministic checkpoints whose safety is backed by the threat of losing staked ether.

4. Probabilistic finality in Nakamoto consensus

4.1 Forks and the most-work rule

In Bitcoin, any miner may propose the next block by solving a proof-of-work puzzle. Because blocks spread across a global network with some delay, two miners occasionally find valid blocks at almost the same time. The chain then forks briefly: different nodes see different latest blocks. Nakamoto’s rule resolves this: every node follows the chain with the most accumulated work [3]. As soon as one branch becomes longer, the network switches to it, and the blocks on the shorter branch are abandoned.

This switch is called a reorganisation. Transactions that were confirmed only on the abandoned branch lose their confirmations. Most return to the pool of unconfirmed transactions and are mined again; but if an attacker has meanwhile published a conflicting transaction that spends the same coins, the original payment may disappear for good. That is a double spend.

4.2 What the whitepaper calculates

Section 11 of the Bitcoin whitepaper models a double-spend attack as a race between an honest chain and an attacker who controls a share q of the total computing power, while honest miners control p = 1 − q [3]. Nakamoto treats the race as a gambler’s ruin problem. If the attacker is z blocks behind, the probability of ever catching up is:

P(catch up) = (q / p)^z if q < p, and 1 if q ≥ p

Two conclusions follow directly. If an attacker controls half or more of the computing power, it will eventually overtake the honest chain no matter how many confirmations a merchant waits for. And if it controls less than half, its chance of success falls exponentially with every additional block.

Nakamoto then accounts for the progress the attacker makes in secret while the merchant waits, and tabulates how many confirmations are needed to push the attacker’s probability of success below 0.1% [3]. For an attacker with 10% of the computing power, five confirmations are enough. At 30% it takes 24 confirmations; at 40%, 89; at 45%, 340.

The widespread rule of waiting for six confirmations — about an hour on Bitcoin — corresponds to the 10% case with a margin of one block. It is a convention, not a law of nature: it assumes an attacker with roughly a tenth of the network’s computing power and accepts a residual risk of about one in a thousand.

4.3 Corrections and refinements

Later work showed that Nakamoto’s estimate is somewhat optimistic. Rosenfeld modelled the attacker’s progress more precisely and found that the probabilities in the whitepaper understate the risk, especially for small numbers of confirmations [4]. Grunspan and Pérez-Marco derived a closed-form expression for the exact probability and confirmed that more confirmations are needed than the original table suggests [5]. The qualitative picture remains: the risk falls exponentially, but the constants matter.

The analysis also assumes that honest miners follow the protocol. Eyal and Sirer showed that a mining pool can earn more than its fair share of rewards by withholding blocks and publishing them strategically, a strategy known as selfish mining, and that under some network conditions this pays off with far less than half of the computing power [6]. Selfish mining does not directly reverse payments, but it increases the frequency of orphaned blocks and weakens the assumption that a majority of hash power behaves honestly.

Garay, Kiayias and Leonardos gave the first formal analysis of the Bitcoin backbone protocol and proved two properties that underpin probabilistic finality: common prefix — honest nodes agree on all but the last few blocks — and chain quality — a sufficient share of blocks comes from honest miners [7]. Their results hold as long as the adversary’s computing power stays below a threshold that depends on network delay.

4.4 The economics of attack

Probabilistic finality is ultimately an economic guarantee. Budish argued that the security of proof of work requires the ongoing cost of mining to be large relative to the value that an attacker could gain from a single attack, which makes very large transfers on a single chain inherently costly to secure [8]. Where computing power can be rented, smaller proof-of-work chains are especially exposed. Ethereum Classic, for example, suffered several majority attacks in 2019 and 2020, including reorganisations of thousands of blocks in August 2020. Such events show that “six confirmations” is meaningful only relative to the computing power that protects a particular chain.

4.5 When the rules themselves fail

Software bugs can undermine finality as well. In March 2013, a Bitcoin software upgrade accidentally produced blocks that older versions rejected, and the network split into two chains for several hours. It was resolved when miners coordinated to return to the older software and abandon the longer, newer branch. The episode illustrates that, beyond the mathematics, finality also depends on the people who write and run the software.

5. Deterministic finality in Byzantine fault-tolerant protocols

5.1 Quorums and the one-third bound

The second family of protocols descends from the Byzantine Generals Problem, formulated by Lamport, Shostak and Pease in 1982: how can a group of parties agree on a decision when some of them may lie or behave arbitrarily [9]? A central result is that agreement is possible only if fewer than a third of the participants are faulty. With n participants, the protocol tolerates f faulty ones when n ≥ 3f + 1, and a decision requires the votes of at least 2f + 1 participants.

Practical Byzantine Fault Tolerance, introduced by Castro and Liskov in 1999, showed that such protocols can run efficiently in real networks [10]. Validators propose a block, exchange signed votes in several rounds, and treat the block as committed once a quorum of more than two thirds has voted for it. Two conflicting blocks cannot both gather such a quorum unless more than a third of the validators sign both — which is exactly what the protocol assumes does not happen.

5.2 Safety versus liveness

Fischer, Lynch and Paterson proved that no deterministic protocol can guarantee agreement in a fully asynchronous network if even one participant may fail [11]. Practical systems therefore assume partial synchrony, a model introduced by Dwork, Lynch and Stockmeyer, in which messages are eventually delivered within some unknown time bound [12]. Under this assumption, Byzantine fault-tolerant protocols guarantee safety — no two honest nodes ever finalise conflicting blocks — at all times, and liveness — the chain keeps making progress — once the network behaves well.

The two families make opposite choices when the network misbehaves. A Nakamoto chain always keeps producing blocks, but may later reorganise them: it favours liveness. A Byzantine fault-tolerant chain stops finalising blocks rather than risk a conflict: it favours safety. For a custodian, these failure modes call for different responses — waiting longer in the first case, pausing credits in the second.

5.3 Hybrid designs: Ethereum

Ethereum’s proof-of-stake consensus combines both ideas. A fork-choice rule called LMD-GHOST lets the chain grow block by block, like a Nakamoto chain, while a finality gadget called Casper FFG periodically finalises checkpoints [13, 14]. A checkpoint becomes final when validators holding at least two thirds of the staked ether have voted for it in two consecutive epochs. With 32 slots of 12 seconds per epoch, this typically takes about 12.8 minutes.

Casper FFG adds accountable safety: if two conflicting checkpoints were ever finalised, at least one third of the total stake must have broken a protocol rule in a way that can be proven on-chain, and those validators can be penalised by losing part of their stake [13]. Finality here is deterministic under the protocol’s assumptions and economic in its enforcement. In May 2023, Ethereum’s mainnet temporarily stopped finalising checkpoints on two occasions, for roughly 25 minutes and roughly an hour, while blocks continued to be produced — a practical example of a hybrid chain falling back to probabilistic behaviour.

6. Finality on TRON

TRON uses delegated proof of stake. Holders of TRX stake their coins and vote for candidates; the 27 candidates with the most votes become Super Representatives, and votes are counted again at regular intervals. The Super Representatives take turns producing blocks in three-second slots.

A TRON block becomes irreversible — in TRON’s terminology, solidified — once blocks from more than two thirds of the Super Representatives, that is at least 19 of the 27, have been built on top of it. With three-second slots, that takes roughly a minute under normal conditions. Wallets and services can query the solidified state of the chain separately from the latest blocks; TRON’s public interfaces offer distinct endpoints for it.

This design gives TRON fast and predictable finality. The trade-off lies in the size and concentration of the validator set: the guarantee holds as long as more than two thirds of a small group of elected producers behave honestly, and the election itself depends on how voting power is distributed among TRX holders. As with every Byzantine fault-tolerant system, the protocol is designed to keep the solidified history safe even if it has to stop solidifying new blocks.

7. Implications for custodial platforms

A custodial platform receives deposits on chains with very different finality models and records them in its own internal ledger. Every deposit therefore involves a decision about when the on-chain transfer is final enough to become a usable balance. The research above suggests several principles.

1. Use each chain’s own notion of finality. On chains with deterministic finality, credit deposits from the finalised or solidified state rather than from the latest block. On proof-of-work chains, choose a confirmation count based on an explicit risk model.
2. Scale waiting times with value. Because an attack costs roughly the same whatever it targets, a large deposit is a more attractive target than a small one. Requiring more confirmations for larger amounts aligns the attacker’s cost with the potential gain.
3. Never treat unconfirmed transactions as payments. Transactions in the mempool can be replaced or dropped. On Bitcoin, mechanisms such as replace-by-fee make it straightforward for a sender to replace an unconfirmed transaction with a conflicting one.
4. Separate “seen” from “credited” and “withdrawable”. Showing a pending deposit early is useful for customers; allowing the funds to be withdrawn or moved on-chain before finality is what creates exposure.
5. Design the ledger for reversals. A double-entry ledger that records a deposit in stages — detected, confirmed, credited — can reverse an entry cleanly if a reorganisation removes the underlying transaction.
6. Monitor the chains themselves. Reorganisations deeper than usual, sudden changes in hash rate or validator participation, and stalled finality are signals to pause crediting until the cause is understood.

8. Conclusion

Blockchain finality is not one property but a family of guarantees with different foundations. Bitcoin’s probabilistic finality is robust and simple, but it is measured in probabilities and depends on the cost of computing power. Byzantine fault-tolerant protocols, including TRON’s delegated proof of stake, provide fast deterministic finality under explicit assumptions about how many validators are honest. Hybrid designs such as Ethereum combine both and add economic penalties.

For anyone who holds assets on behalf of others, the practical lesson is to treat finality as a risk decision: understand the model of each chain, credit from its strongest available guarantee, scale caution with value, and build systems that can respond when the assumptions behind those guarantees are violated.

This article is for general information and education. It isn’t investment, legal or tax advice, and it doesn’t describe Striblo’s internal systems.

Research · 20 min read

Proof of reserves: what a custodial platform can prove — and what it can’t

Since the collapse of FTX in November 2022, “proof of reserves” has become the industry’s standard answer to a simple question: are customers’ assets really there? This article explains the cryptography behind proofs of assets and proofs of liabilities, works through a Merkle sum tree step by step, and sets out the limits that no single snapshot can overcome.

1. Introduction: the trust problem in custody

Public blockchains let anyone verify every transaction. Yet many people hold their crypto-assets through custodial platforms — exchanges, wallets and payment services that keep the private keys and maintain an account for each customer. On such platforms, customers no longer see their assets on-chain. They see a number in an app.

History shows why this matters. In 2014 the exchange Mt. Gox stopped withdrawals and reported that around 850,000 bitcoin were missing; about 200,000 were later found. In 2019 the Canadian exchange QuadrigaCX collapsed after the death of its founder, owing its customers more than 200 million Canadian dollars, and the Ontario Securities Commission later concluded that its failure was the result of fraud by the founder [1]. In November 2022, FTX filed for bankruptcy after customer deposits had been used by an affiliated trading firm, leaving a shortfall of billions of dollars; its founder was convicted of fraud in 2023 [2]. Earlier, Moore and Christin had found that nearly half of the 40 bitcoin exchanges they studied had closed, often with customers’ funds lost [3].

After FTX, many platforms began publishing proofs of reserves. This article explains how these proofs work, what they can establish and where their limits lie.

2. How custodial platforms hold assets

Most custodial platforms do not create a separate on-chain address for every customer balance. They hold assets in a small number of shared wallets — often called omnibus wallets — and keep track of each customer’s claim in an internal ledger. A deposit moves coins into the platform’s wallets and creates a ledger entry; a transfer between two customers on the same platform changes only ledger entries; a withdrawal sends coins from a platform wallet and reduces the customer’s entry. Striblo is built this way too: assets are held in platform wallets, and each balance is an entry in Striblo’s internal ledger.

The model is efficient: it saves network fees and allows instant internal transfers. But it separates two things that customers care about. The ledger says how much the platform owes; the blockchain shows how much the platform holds. A platform is solvent in a given asset only when the second is at least as large as the first.

Assets_asset ≥ Liabilities_asset for every asset held

The condition has to hold asset by asset. A surplus of stablecoins does not cover a shortfall in bitcoin, because customers who own bitcoin are entitled to bitcoin.

3. Proof of assets

The first half of a proof of reserves shows what the platform holds. On a public blockchain, the balance of any address at a given block height is visible to everyone. What has to be proven is control: that the platform, and not someone else, holds the private keys to those addresses.

The simplest method is to sign a chosen message with the key of each address, or to move a small amount from each address at an agreed time. Both demonstrate control at that moment. They have drawbacks: publishing every address reveals the platform’s full holdings and its customers’ activity to competitors and attackers, and keys stored in deep cold storage may be difficult to use safely just for a proof.

Dagher, Bünz, Bonneau, Clark and Boneh proposed Provisions, a protocol that lets an exchange prove it controls a certain amount of bitcoin among a larger set of addresses without revealing which ones, using zero-knowledge proofs [4]. Whatever method is used, a proof of assets shows control at a point in time; it does not show that the assets are free of other claims, or that they weren’t borrowed for the occasion.

4. Proof of liabilities

4.1 The Merkle sum tree

The second half — proving what the platform owes — is harder, because liabilities exist only in the platform’s own database. The most widely used construction is the Merkle sum tree, an extension of the hash tree introduced by Merkle [5] and adapted for this purpose by the Bitcoin developer Gregory Maxwell; Dagher et al. describe the scheme and its weaknesses in detail [4].

Each customer becomes a leaf of the tree. A leaf contains the customer’s balance and a hash of an identifier combined with a secret random value, so that leaves don’t reveal who they belong to. Each node above combines its two children: it stores the sum of their balances and a hash of both children, including their balances. The root therefore commits to every leaf and to the total of all balances. The platform publishes the root and the total.

4.2 How a customer checks it

To verify that her balance was counted, a customer asks the platform for her inclusion proof: the sibling nodes on the path from her leaf to the root. In Figure 1, Bob receives Alice’s leaf and the node that holds 12,000. He recomputes his own leaf from his balance and his identifier, combines it with Alice’s leaf to get the 8,000 node, combines that with the 12,000 node, and checks that the result equals the published root of 20,000.

If the platform had left Bob out, or recorded a smaller balance for him, the recomputed root would not match. Each customer who checks verifies one path; together, customers who check audit the tree from the inside.

4.3 Known weaknesses

• Negative balances. A dishonest platform could add a fake account with a negative balance to shrink the total. Nodes must therefore be checked for negative sums, and privacy-preserving designs use range proofs to show that every balance is non-negative without revealing it [4, 6].
• Customers who never check. The tree only catches omissions that someone notices. A platform that knows which customers are inactive could leave exactly those out.
• Information leakage. Sibling nodes reveal partial sums, which can leak information about other customers’ balances and about the number of customers. Designs such as DAPOL hide balances in commitments and pad the tree with dummy leaves [6, 7].
• Different trees for different people. Customers must be sure they are checking against the same published root as everyone else; otherwise a platform could show each customer a different tree.

5. Putting the two halves together

A complete proof of reserves combines both halves for each asset at the same moment: the proof of assets gives the amount the platform controls, the proof of liabilities gives the amount it owes, and their ratio — often called the reserve ratio — should be at least 100%. Decker, Guthrie, Seidel and Wattenhofer showed how trusted hardware could be used to compute such a comparison without revealing the underlying data [8]; later schemes aim to do the same with cryptography alone [4, 7].

6. The limits of a snapshot

6.1 Window dressing

A proof of reserves describes one moment. A platform with a hole in its balance sheet could borrow assets shortly before the snapshot, include them in its proof of assets, and return them afterwards. The proof would be technically correct and practically misleading. More frequent proofs, unannounced timing and proofs that cover several block heights make this harder, but cannot rule it out entirely.

6.2 Liabilities outside the tree

A proof of liabilities covers customer balances that the platform chooses to put in the tree. It says nothing about loans the platform has taken out, obligations to other creditors, guarantees, or derivatives positions. A platform can show 100% coverage of customer balances and still be insolvent overall if its other debts exceed its other assets.

6.3 Assets that are not free

Controlling a key does not mean owning the coins free and clear. Assets may be pledged as collateral, lent out, or held on behalf of someone else who is not a customer in the tree. A proof of assets cannot distinguish between these situations.

6.4 The level of assurance

Many proofs of reserves are accompanied by a report from an accounting firm. These reports vary widely: some are limited engagements in which the firm performs agreed procedures and reports what it found, without expressing an opinion on the platform’s finances. In December 2022, the accounting firm Mazars paused its proof-of-reserves work for crypto clients, and in March 2023 the US Public Company Accounting Oversight Board warned investors that such reports provide limited assurance and are not audits [9].

6.5 Proof is not ownership

Finally, cryptography cannot settle legal questions. Whether customers own the assets held for them, or are merely unsecured creditors of the platform, depends on the platform’s terms and on insolvency law. In January 2023, the US bankruptcy court overseeing the lender Celsius Network ruled that assets deposited in its Earn programme had become the property of the bankrupt estate under the terms customers had accepted [10]. A perfect proof of reserves would not have changed that outcome.

7. Beyond proof of reserves

Because of these limits, proofs of reserves work best as one control among several. The literature and recent regulation point to complementary measures:

• Segregation of client assets. Keeping customers’ assets legally and operationally separate from the platform’s own makes it clearer who owns what if the platform fails. The EU’s Markets in Crypto-Assets Regulation, for example, requires crypto-asset service providers that hold client assets to keep them separate from their own and to maintain a register of each client’s positions [11].
• Full financial audits. An audit of the complete balance sheet, including liabilities outside the customer tree, addresses what a proof of reserves leaves out.
• Continuous or frequent attestation. Proofs that are repeated often, or computed continuously from on-chain data and ledger entries, shrink the window for dressing up a snapshot.
• Privacy-preserving designs. Schemes based on commitments and zero-knowledge proofs, such as Provisions and generalised proofs of liabilities, allow more frequent proofs without exposing customers or the platform’s wallets [4, 7].

8. What to look for as a customer

1. Liabilities, not just assets. A list of wallet addresses alone proves nothing about what the platform owes.
2. Your own inclusion proof. Check that your balance is in the tree and that the root you checked against is the published one.
3. Coverage per asset. Look for a ratio for each asset you hold, not one total across all assets.
4. Frequency and timing. A single proof after a crisis says little about the months before and after it.
5. The type of report. Read what the accounting firm actually did, and whether it expresses an opinion or only reports agreed procedures.
6. The terms of service. Check whether the platform holds your assets for you or owns them and owes you a balance.

9. Conclusion

Proofs of reserves turn a question of trust into a question that can partly be checked. A well-designed proof of liabilities lets every customer confirm that their balance was counted; a proof of assets shows that matching funds were under the platform’s control at that moment. Together they can reveal some of the most common failures of custody.

They cannot, on their own, show that a platform is solvent overall, that its reserves were not borrowed for the occasion, or that customers will be first in line if it fails. Proofs of reserves reduce the trust that customers have to place in a custodian. They do not remove it. Their value depends on how often they are produced, how completely they cover liabilities, and how independently they are checked.

This article is for general information and education. It isn’t investment, legal or tax advice. It describes industry methods in general and does not describe Striblo’s own controls or audits.