---
title: "Hedera Technical Insights: Finality of Consensus – you can take it to the bank (or maybe you are the bank?)"
id: "16120"
type: "post"
slug: "finality-of-consensus-you-can-take-it-to-the-bank-or-maybe-you-are-the-bank"
published_at: "2021-02-05T00:00:00+00:00"
modified_at: "2025-12-10T04:54:17+00:00"
url: "https://hedera.com/blog/finality-of-consensus-you-can-take-it-to-the-bank-or-maybe-you-are-the-bank/"
markdown_url: "https://hedera.com/blog/finality-of-consensus-you-can-take-it-to-the-bank-or-maybe-you-are-the-bank.md"
excerpt: "For individuals, being willing to change your mind is generally seen as a good thing – it suggests flexibility and a willingness to accept new data or evidence, even if it contradicts a previously held belief. Not so for a..."
taxonomy_category:
  - "Uncategorized"
taxonomy_post_tag:
  - "technical"
---

[Skip to content](#content)
blog

# Hedera Technical Insights: Finality of Consensus – you can take it to the bank (or maybe you are the bank?)

February 5, 2021

Hedera

Hedera provides secure, scalable infrastructure for real-world decentralized applications in finance, AI, and sustainability, governed by global enterprises.

For  
 individuals, being willing to change your mind is generally seen as a  
 good thing – it suggests flexibility and a willingness to accept new  
 data or evidence, even if it contradicts a previously held belief.

Not so for a consensus node in a distributed ledger.  
 Once a consensus node decides on the proposition under consideration –  
 for it to later change its mind complicates the goal of the network as a whole agreeing on that proposition.

In  
 blockchains, the proposition under question is generally “what block  
 should go on the end of the chain?” Blockchains differentiate  
 themselves by the mechanism by which this question is decided. Some  
 blockchains simply have different nodes take turns proposing a block  
 and, as all nodes know whose turn it is, there is no uncertainty over  
 the decision. If the decision process is not so deterministic, it may be  
 possible for there be two valid blocks at a moment in time, and so no  
 immediate answer. In Proof-of-Work (PoW) chains, the miners  
 race to complete the hash puzzle and so win the right to have their  
 block picked as next. As it is possible for two miners to both solve the  
 puzzle around the same time, both proposed blocks are valid candidates  
 to be chosen to be placed at the end of the chain. With both blocks then  
 sent out to the rest of the network by the miners that created them  
 (eager for the associated reward), the network must reconcile the  
 disagreement. Both blocks *deserve* to be placed at the end of the chain, but only one can be. Which to choose? The chain, until the uncertainty is resolved, has split or forked. PoW  
 chains typically resolve the issue by waiting until another hash puzzle  
 race is completed – the winning block will have necessarily chosen one  
 or the other of the earlier competing blocks. Whichever earlier block  
 was chosen by this new block is retroactively blessed and the other  
 discarded (or orphaned). This is the so-called “longest chain” rule for  
 resolving chain forks – participants agree to build on the longest chain  
 if there is a choice to be made.

The  
 two earlier candidate blocks inevitably contained different sets of  
 transactions – as the miners that created those blocks would have had a  
 different set of transactions waiting in their different mempools. It’s possible that a particular transaction was in one block but not the other. Consequently, it’s  
 possible that a given transaction is in the block that is orphaned but  
 not in the block that is part of the longer chain. If so, then that  
 transaction won’t be processed by the network. For instance, a BTC transfer won’t  
 be made or a smart contract call on Ethereum won’t happen. For whoever  
 sent the transaction, sorry about that. It will still be sitting in the  
 miner’s mempools  
 so it will hopefully be added to a later block. But critically, if  
 there had been any exchange of value based on the assumption that the  
 transaction in question was going to go through because it was in a  
 block that had satisfied the hash puzzle, then someone will be  
 disappointed. Using the archetypical coffee shop example – if the barista  
 served the latte based solely on the payment being added to a confirmed  
 block, then the customer may get the latte for free if the payment  
 transaction is orphaned and never gets into a subsequent block.

A more nefarious scenario has an attacker attempt to manipulate the above temporary uncertainty – if they can send two different transactions spending the same coin into two winning blocks, then it’s  
 possible that they can obtain value for each payment – effectively “double-spending” the coins. As explained above, the network will  
 eventually resolve the discrepancy and only one transaction will be  
 deemed valid, but that will likely be little consolation to whoever gave  
 up something of value in exchange for the transaction that was deemed  
 invalid.

It is for this reason that PoW  
 chains recommend that those parties who rely on a payment being  
 successfully processed wait a certain number of blocks to be added to  
 the chain beyond the block the transaction in question is in. In  
 Bitcoin, the recommended best practice is to wait for a total of six confirmations before assuming that the transaction won’t be in a block that gets orphaned – or the chain to be *reorganized*.  
 As each block takes ten minutes on average, the best practice is to wait  
 an hour before being fully confident that a BTC transaction is “good”.  
 Ultimately, however, it’s  
 a personal decision. For a latte, the coffee shop might be okay with one additional block. For someone selling a house, they would likely choose  
 to wait the full hour or more before handing over the keys.

As  
 additional blocks are added to the chain, the chances of a  
 transaction in an earlier block being orphaned decrease quickly. After six block  
 confirmations, the chances of a reorganization are very small, but not zero.  
 There is always the theoretical chance that another chain, longer than  
 that which a miner thought  
 was the longest, will be discovered. If so, then the rules require that  
 everyone switch – discarding the erstwhile longest chain (and unfortunately effectively throwing away the electricity spent on its creation).

In PoW  
 chains, miners are required to be willing to change their minds about  
 what chain to build on, and so there is always a chance that  
 transactions previously assumed to be “locked-in” will be retroactively  
 thrown out. Participants must account for this uncertainty.

In the hashgraph algorithm, the proposition under question that nodes must collectively establish agreement on is “is this particular witness famous?” The hashgraph data structure connects together groupings of transactions called “events”. Certain events have a special place in that structure and are called “witnesses”.  
 Some witnesses are even more special – they are deemed “famous”. You  
 can think of famous witnesses as those that are deeply woven into the hashgraph – like human celebrities, everybody “knows” them. All nodes look at the same hashgraph, identify the same set of witnesses for a certain portion of the hashgraph, and use the [same algorithm](https://docs.hedera.com/hedera/core-concepts/hashgraph-consensus-algorithms/virtual-voting)
 to determine the famous witnesses within that set. Once the famous witnesses are determined, then it’s a straightforward process to calculate timestamps for earlier events within the hashgraph. All nodes  
 identify the famous witnesses and perform the timestamp calculation  
 separately, without any additional confirmations or receipts beyond the  
 gossiped events themselves – but nevertheless come to the same  
 conclusion.

And critically, once a node determines which witnesses are famous in a given section of the hashgraph, they won’t change their mind. If a node determines that a particular witness is *not* famous, then there is no possibility that it will receive additional information that will cause the node to reevaluate and instead determine that the same witness *is* famous. Nodes make a choice, and then stick with it. Of course, nodes don’t decide lightly, a node won’t decide on the fame of a witness until it receives sufficient evidence to support the choice – famous or not. The algorithm requires that nodes see agreement from [more than 2/3 of the network](https://hedera.com/blog/counting-votes-why-a-2-3-threshold)
 before making the decision. With such a hard threshold, once a node is able to [count enough votes](https://docs.hedera.com/hedera/core-concepts/hashgraph-consensus-algorithms/virtual-voting)
  
 and decide on fame of a particular witness, then hearing from any more  
 of the network, whether that additional information affirms the choice  
 or otherwise, is pointless. In fact it’s more than pointless, it’s wasteful and inefficient. Once nodes reach the threshold, they move on to the next decision – determining the fame  
 of more recent witnesses. Another voting system that has a similar  
 threshold and so similar finality is the US electoral college – once a  
 presidential candidate receives 270 electoral votes, they are the  
 winner. The states keep counting beyond that, but technically they don’t need to.

The above stubborn certainty for hashgraph  
 nodes on the fame of witnesses is called “finality” of consensus. And  
 finality in determination of the fame of witnesses translates into  
 finality of the consensus timestamps and order of all events within the hashgraph (not just witnesses or famous witnesses). Once an event is assigned a timestamp and place in the full order, it won’t change. It can’t change; that would require that a set of famous witnesses changed and, as we saw above, nodes will not entertain that possibility.

Without  
 finality of consensus, you must always to a certain extent “hedge your  
 bets” – anticipating the possibility of a transaction being rolled back.  
 It’s complicated. With finality, things are simpler. A dapp that sends a transaction into the Hedera mainnet and receives a receipt three seconds later with the consensus timestamp for that transaction doesn’t need to ask again three seconds later. Or six seconds. Or nine seconds. The answer will never change. And,  
 with confidence that neither the consensus timestamp nor order of a  
 transaction will ever change, the barista (or exchange, or supply chain  
 partner, or vaccination clinic) can be equally confident that the  
 transaction can be processed immediately with no risk of subsequently  
 needing to be rolled back. Finality becomes particularly important when dealing with sharding or cross-chain interoperability.

There is no equivalent risk of double-spend in hashgraph as described above for PoW. If an attacker simultaneously sends two transactions into the network that together spend more hbars than in the balance of the account – both will receive a consensus timestamp and order. One will be deemed to have occurred earlier than the other. The later transaction will be rejected by all nodes as spending hbars that the account doesn’t have. The timestamps for the two transactions won’t change, and so neither will the determination of which transaction was earlier and valid.

With hashgraph’s finality, a transaction’s timestamp, order, and validity will not change – you can take it to the bank (or maybe you are the bank?)

[Back to Blog](/blog)

discover

See more articles

[View All](/blog)

October 19, 2026

### Meet the Scaffold HBAR Template Bounty winners

Announcing the Scaffold-HBAR Template Bounty winners: templates for multisig governance, limit orders, scheduled keepers and recurring buys, each a command away.

[Read More](https://hedera.com/blog/meet-the-scaffold-hbar-template-bounty-winners/)

October 8, 2026

### Introducing Hedera Agent Accounts

Hedera Agent Accounts give AI agents programmable, non-custodial spending accounts on Hedera. Set limits and approved merchants on-chain, and your private keys never leave your wallet. This new approach measures

[Read More](https://hedera.com/blog/introducing-hedera-agent-accounts/)

October 1, 2026

### Introducing MirrorNodeAccountBalanceQuery: The SDK-Native Migration Path for AccountBalanceQuery

MirrorNodeAccountBalanceQuery is available now in the JavaScript, Java, and Go Hiero SDKs, giving developers a native way to read an account’s HBAR balance from the Mirror Node REST API without

[Read More](https://hedera.com/blog/mirrornodeaccountbalancequery-the-sdk-native-migration-path-for-accountbalancequery/)

## Ready to get started?

Discover why Hedera is the trusted institutional-grade network powering the new digital economy.

[Start Building](/start-building)

[Contact](/contact)

We use cookies to deliver the best experience on our website and to analyze traffic. By continuing to use this site, you consent to our cookie policy.

Review our [Privacy Policy](/privacy)
 to understand how Hedera collects and uses information.

Accept All CookiesAccept Necessary Cookies