Hedera Technical Insights: Latency on Hedera | Hedera Hedera Network Services Token Service Mint and configure tokens and accounts. Consensus Service Verifiable timestamps and ordering of events. Smart Contracts Run Solidity smart contracts. HBAR The Hedera network's native cryptocurrency. Insights How It Works Learn about Hedera from end to end. Explorers View live and historical data on Hedera. Dashboards Analyze network activity and metrics. Network Nodes Understand networks and node types. Devs Start Building Get Started Learn core concepts and build the future. Documentation Review the API and build using your favorite language. Developer Resources Integrations Plugins and microservices for Hedera. Fee Estimator Understand and estimate transaction costs. Open Source Hedera is committed to open, transparent code. Learning Center Learn about web3 and blockchain technologies. Grants Grants & accelerators for your project. Bounties Find bugs. Submit a report. Earn rewards. Ecosystem ECOSYSTEM Hedera Ecosystem Applications, developer tools, network explorers, and more. NFT Ecosystem Metrics Analyze on-chain and market NFT ecosystem metrics. CATEGORIES Web3 Applications Connect into the innovative startups decentralizing the web on Hedera. Enterprise Applications Learn about the Fortune 500 companies decentralizing the web on Hedera. Wallets & Custodians Create a Hedera account to manage HBAR, fungible tokens, and NFTs. Network Explorers Hedera mainnet and testnet graphical network explorers. Developer Tooling Third-party APIs, integrations, and plugins to build apps on Hedera. Grants & Accelerators Boost your project with support from the Hedera ecosystem. Partner Program Explore our partners to bring your vision into reality. Hedera Council Over 30 highly diversified organizations govern Hedera. Use Cases Hedera Solutions Asset Tokenization Studio Open source toolkit for tokenizing assets securely. Stablecoin Studio All-in-one toolkit for stablecoin solutions. Hedera Guardian Auditable carbon markets and traceability. Functional Use Cases Data Integrity & AI Reliable, secure, and ethically governed insights. Sustainability Enabling fair carbon markets with trust. Real-World Asset Tokenization Seamless tokenization of real-world assets and digital at scale. Consumer Engagement & Loyalty Mint, distribute, and redeem loyalty rewards. Decentralized Identity Maintain the lifecycle of credentials. Decentralized Logs Scalable, real-time timestamped events. DeFi Dapps built for the next-generation of finance. NFTs Low, fixed fees. Immutable royalties. Payments Scalable, real-time, and affordable crypto-payments. HBAR Overview Learn about Hedera's token, HBAR. Treasury Management Hedera’s report of the HBAR supply. Governance Decentralized Governance Hedera Council See the world's leading organizations that own Hedera. About Meet Hedera's Board of Directors and team. Journey Watch Hedera's journey to build an empowered digital future for all. Transparent Governance Public Policy Hedera's mission is to inform policy and regulation that impact the industry. Meeting Minutes Immutably recorded on Hedera. Roadmap Follow Hedera's roadmap in its journey to build the future. Resources Company What's New Partners Papers Careers Media Blog Technical Press Podcast Community Events Meetups Store Brand Navigation QUICKSTART Hedera Technical Insights: Latency on Hedera technical Dec 16, 2019 by Paul Madsen Head of Identity, The HBAR Foundation On the Hedera mainnet we are currently seeing a latency of approximately 2.5 seconds for transactions. This post will break down that 2.5 seconds. Latency is the time from when a transaction is first sent out from one node, until a node has received it and calculated its consensus order and consensus timestamp, averaged over all nodes and all transactions. All else being equal, the shorter the latency the better, as applications submitting transactions to the public ledger will have to wait less before obtaining the necessary confidence that a given transaction has been processed into consensus and will not change. Lifecycle of a Hedera transaction Let’s consider the full lifecycle of a typical Hedera transaction. A client creates a transaction and submits it to a particular Hedera node – let's call it Alice. After performing a minimal validation check of the transaction, Alice adds it to an event along with other transactions that had been sent to her by both that same client and others. Alice adds her clock’s current timestamp to the event, two hashes of previous events, and signs the new event with her private key. The clock starts. Latency for the transaction will be measured from this point. Events are gossiped Alice gossips the newly created event (and the client’s transaction within) to another node Bob. Bob then gossips it to another node Carol. Alice, Bob, and Carol would continue to gossip that event in their subsequent gossip syncs with other nodes. Very quickly all nodes will have received the event – all at different times. Although the times at which each node receives the event will be different, the gossip about gossip component of the hashgraph algorithm allows all nodes to know those different times (to be precise, to know the time at which it finished the sync in which it received the event). Virtual voting and consensus timestamps To assign the new event a consensus timestamp and place in consensus order, nodes follow the virtual voting component of the hashgraph algorithm. The consensus timestamp of the event will be the median of a set of the times at which a subset of all nodes received the event. To determine which nodes are in that subset, an election is held on the ‘fame’ (a measure of the gossip activity of the node that created it) of events. But, to assign Alice’s event a timestamp, votes are cast not on the fame of Alice’s event, but rather on the fame of later events (that are descendants of Alice’s event). And the mechanism for counting up those votes requires even later events. Consequently, to assign Alice’s event a consensus timestamp, each node must wait a sufficient amount of time after receiving that event so that they can receive the later events that will allow the timestamp to be calculated. Logically, each node maintains a list of pre-consensus events and, as subsequent events are received, the node checks to see if that each newly received event will allow a consensus timestamp to be calculated for any older events in the list. If so, the timestamp is calculated and the event is removed from the pre-consensus list. Currently on Hedera, it takes between 2 and 3 seconds for a node to be able to collect those necessary later events that allow the fame elections to be decided. A key implication of the above is that each node will calculate the consensus timestamp for Alice’s event at a different time – this because they inevitably received the necessary subsequent events at different times. The consensus timestamp they conclude for a given event is of course all the same, but they come to that conclusion at different times. Reaching finality Critically, since hashgraph delivers finality of consensus, once a node calculates the consensus timestamp for Alice’s event (whether it is the first to do so or the last), they need not be concerned about that determination changing – it is final. Contrast this certainty with other distributed ledgers (such as Proof of Work blockchains) that do not provide finality, and instead provide to participants only a growing confidence that a transaction will not be rolled back as additional blocks are added to the chain. In such distributed ledgers, there is always a theoretical possibility that, should a longer chain be seen – all nodes will roll back any transactions in the shorter chain that had been thought as canonical. In practice, actors choose how many subsequent blocks to wait based on their assessment of the risk. On Hedera, one node’s assessment of the latency for Alice’s event will be (slightly) different than for others. They all agree on when the clock started as the event itself carries the time when Alice first created it. But, as each node determines the consensus timestamp at a different time (when the clock stops), each nodes’ sense of the interval between the creation and their own determination of consensus will vary. This is represented below: After each node has calculated a timestamp for Alice’s event via virtual voting, the transactions within that event are assigned their own timestamps simply based on their place within the event. Once the client’s transaction has been assigned a timestamp and placed in consensus order, nodes apply it to their local copy of state. For instance, if the transaction were an HBAR transfer, all nodes would decrement the payer’s balance, and increment the recipient’s. Or, if the transaction were a smart contract call, each node would execute the function. Confirming the transaction The original client can query for the consensus status of the transaction at that point by asking any node for either a receipt (free) or a record (not free). If they send the query too soon, for instance, 1 second after first submitting it to Alice, then the response code from the node will likely be `UNKNOWN`. At that point the node to which the query was sent may have received the transaction in question but will be unlikely to have been able to assign it a consensus timestamp as the necessary subsequent descendants will not have been collected. If the client instead waits longer before sending their query (long enough for whatever node they pick for the query to have calculated consensus) then the response code will be `SUCCESS`. Latency of a public ledger When Hedera cites 2.5 seconds or similar for latency, we mean that this value is equal to the time interval between when the event containing the transaction is initially created and subsequently assigned a consensus timestamp by another node, when averaged over other transactions and all nodes. Of course, any particular transaction will likely have a latency different than this average, some lower, some higher. This is clear in the chart below that shows the latencies for each node over a 12 hour span. The latency of a distributed ledger is a key metric of performance. A large latency implies applications must wait after submitting a transaction before proceeding, for instance, transferring some resource. Latency is critical for payment applications – the archetypal ‘buying a coffee’ use case is impractical if the customer must wait 10 minutes or longer for their purchase to be confirmed. Currently, with its 13 nodes distributed around the globe, Hedera delivers a latency of less than 3 seconds. Additionally, and critically, on average after this length of time, a transaction will have been assigned a consensus timestamp and placed within consensus order that will not change – that is, with finality. Share This Back to blog What is gRPC, gRPC-Web, and Proxies? Ed Marquez Pragmatic Blockchain Design Patterns – Integrating Blockchain into Business Processes Michiel Mulders Zero Cost EthereumTransaction on Success: Hedera's New Fee Model for Relay Operators Oliver Thorn Hedera Adopts Chainlink Standard for Cross-Chain Interoperability To Accelerate Ecosystem Adoption Hedera Team Hedera Developer Highlights March 2025 Michiel Mulders Hedera Release Cycle Overview Ed Marquez View All Posts Sign up for the newsletter CONNECT WITH US Transparency Open Source Audits & Standards Sustainability Commitment Carbon Offsets Governance Hedera Council Public Policy Treasury Management Meeting Minutes LLC Agreement Node Requirements Community Events Meetups HBAR Telegram Developer Discord Twitter Community Support FAQ Network Status Developer Discord StackOverflow Brand Brand Guidelines Built on Hedera Logo Hedera Store About Team Partners Journey Roadmap Careers Contact General Inquiry Public Relations © 2018-2025 Hedera Hashgraph, LLC. All trademarks and company names are the property of their respective owners. All rights in the Deutsche Telekom mark are protected by Deutsche Telekom AG. All rights reserved. Hedera uses the third party marks with permission. Terms of Use  |  Privacy Policy