What Is Hedera Settlement and How Does It Work?

Published on Sat Aug 22 2026 00:00:00 GMT+0000 (Coordinated Universal Time) by Jacob Cavazos

What Is Hedera

Hedera is a public distributed ledger. It is not an EVM chain. It does not use a blockchain in the traditional sense. It uses a hashgraph. The hashgraph is a data structure and consensus algorithm that was invented by Leemon Baird and introduced publicly in 2015. The Hedera mainnet launched in 2019. It is governed by a council of major corporations — Google, IBM, Boeing, Deutsche Telekom, and others — each of which runs a node and participates in governance decisions.

The network is public. Anyone can read the ledger. Anyone can submit transactions. Anyone can create accounts and transfer tokens. The consensus nodes are operated by the governing council members, and the network has a published roadmap for permissionless node operation. The transparency guarantees are the same as any public ledger: transactions are visible, verifiable, and immutable once finalized.

Hedera supports several native services that are relevant to settlement. The Hedera Token Service (HTS) allows the creation and management of fungible and non-fungible tokens directly on the ledger without deploying smart contracts. The Hedera Consensus Service (HCS) provides a decentralized messaging layer that can be used for audit trails, event ordering, and verifiable timestamps. The Hedera Smart Contract Service (HSCS) provides EVM-compatible smart contract execution. These three services form the foundation for settlement use cases on Hedera.

What Is the Hashgraph

The hashgraph is the consensus mechanism. It is not proof-of-work. It is not proof-of-stake in the Ethereum sense. It is an asynchronous Byzantine Fault Tolerant (aBFT) consensus algorithm based on a gossip-about-gossip protocol combined with virtual voting.

Here is how it works at a conceptual level. Each node in the network maintains a hashgraph — a directed acyclic graph of events. When a node learns new information, it gossips that information to other nodes. Each gossip event includes the hash of the sender’s last-known event and the hash of the receiver’s last-known event. This creates a graph of events where every event is cryptographically linked to its parent events.

The key innovation is virtual voting. Instead of nodes sending explicit votes to each other — which is how traditional BFT algorithms work — the hashgraph’s structure encodes enough information that every node can compute how every other node would have voted at any point in history. No additional messages are needed. The votes are implicit in the graph structure. This eliminates the voting round-trips that make traditional BFT algorithms slow at scale.

The result is a consensus algorithm that achieves asynchronous Byzantine fault tolerance with mathematical proof. Asynchronous means the algorithm guarantees finality even under conditions where message delivery times are unpredictable and network partitions occur. This is a stronger guarantee than the partial synchrony assumption that most blockchain consensus algorithms rely on.

Deterministic Finality

This is the most important concept for settlement. Deterministic finality means that once a transaction is confirmed, it is final. It cannot be reverted. It cannot be orphaned. It cannot be replaced by a longer chain. There is no probabilistic finality. There is no reorg risk.

On Ethereum and other EVM chains, finality is probabilistic. When a transaction is included in a block, there is a high probability it is final. But that probability approaches certainty only as more blocks are built on top. On Ethereum, this takes approximately 12.8 minutes (two epochs) under the merge’s Gasper consensus. On Base, which is an Optimistic Rollup, finality depends on the Ethereum L1 challenge window — meaning a transaction on Base is not truly final until the rollup batch is finalized on Ethereum L1, which can take up to 7 days if the sequencer fails and a fraud proof window must expire (see our guide on how to bridge to Base chain for more on this withdrawal window).

For settlement, this distinction is critical. If you are settling a payment, you need to know that the payment is final. You need to know that it will not be reverted. You need to know that the recipient can rely on it. Probabilistic finality introduces a window of uncertainty. Deterministic finality eliminates it.

On Hedera, transactions reach finality in approximately 3 to 5 seconds. Once the transaction is finalized, it is final. There is no reorg. There is no rollback. The transaction is part of the consensus state. This is the property that makes Hedera attractive for settlement use cases — particularly for institutional payments, treasury operations, and any scenario where finality guarantees matter.

Fixed and Predictable Fees

The second property that matters for settlement is fee predictability. On EVM chains, gas fees are variable. They depend on network congestion, block space demand, and the complexity of the transaction. A transaction that costs $0.01 in gas at one moment may cost $0.50 a few minutes later. This variability makes it difficult to predict the total cost of a settlement operation.

Hedera uses a fixed fee model. Each transaction type has a predetermined fee denominated in HBAR. The fee does not change based on network congestion. The fee does not change based on the size of the transaction (within defined limits). The fee does not auction for block space. This means the cost of a settlement transaction is known before it is submitted. It is the same cost regardless of when it is submitted.

For settlement use cases, this matters because it enables accurate cost accounting. If you are settling a batch of payments, you know the exact fee for each transaction before you submit it. You do not need to estimate gas. You do not need to set a gas price and hope it is sufficient. You do not need to worry about a transaction being stuck in the mempool because the gas price was too low. The fee is fixed. The transaction will be included. The cost is known.

The fee structure is published in the Hedera documentation. Transaction fees are denominated in USD and paid in HBAR at the current exchange rate. This means the dollar cost of a transaction is stable even if the HBAR price fluctuates. For settlement, this is another advantage: the cost is predictable in the denomination that matters for accounting.

EVM Compatibility

Hedera supports EVM-compatible smart contract execution through the Hedera Smart Contract Service. This means that smart contracts written in Solidity and compiled to EVM bytecode can be deployed on Hedera. The execution environment is EVM-equivalent. Contracts that work on Ethereum can work on Hedera with minimal modification.

This matters for settlement because the vast majority of DeFi infrastructure — token contracts, DEX routers, lending protocols, oracle contracts — is written in Solidity and deployed on EVM chains. EVM compatibility means that this infrastructure can be ported to Hedera. It means that developers familiar with Solidity can build on Hedera without learning a new language. It means that tooling — Hardhat, Foundry, Remix, ethers.js, viem — works with Hedera with minor configuration changes.

Hedera also supports Ethereum JSON-RPC relay endpoints. This means that standard Ethereum tooling can communicate with Hedera nodes using the same JSON-RPC calls that work on Ethereum. Wallets like MetaMask can be configured to connect to Hedera. Block explorers like HashScan provide EVM-equivalent transaction views. The developer experience is designed to be familiar to anyone who has built on Ethereum.

The EVM compatibility is not identical to Ethereum in every respect. There are differences in account models, transaction formats, and gas semantics. Hedera uses an account-based model where accounts have numeric IDs rather than hexadecimal addresses. The Hedera SDK and the JSON-RPC relay handle the mapping between these models. Developers need to be aware of these differences, but the core execution environment is EVM-compatible.

Hedera Token Service

The Hedera Token Service is a native service for creating and managing tokens. It does not require deploying a smart contract. You create a token by submitting a token creation transaction to the network. The network manages the token supply, transfers, and metadata natively.

This is different from EVM chains, where every token is a smart contract. On Ethereum, creating a token means deploying an ERC-20 contract. Transferring a token means calling the transfer function on that contract. The gas cost depends on the contract’s complexity and the network conditions.

On Hedera, token transfers are native transactions. They are cheaper and faster than smart contract calls. A token transfer on Hedera costs a fixed fee and finalizes in seconds. There is no contract execution. There is no gas estimation. The transfer is a first-class operation on the ledger.

For settlement, this matters because the settlement asset — typically a stablecoin — can be created and transferred with the efficiency and finality of a native ledger operation. The stablecoin can be configured with specific properties: supply keys for minting and burning, KYC keys for compliance, freeze keys for regulatory controls, and wipe keys for recovery. These are native features of the token service, not custom smart contract logic.

Hedera Consensus Service

The Hedera Consensus Service is a decentralized messaging layer. It allows applications to submit messages to the network and receive verifiable, ordered, and timestamped consensus on those messages. The messages are ordered by the hashgraph consensus algorithm. The ordering is final. The timestamps are consensus timestamps — they are not set by any single party.

For settlement, HCS provides an audit trail. Every settlement event — the submission of a payment, the verification of a condition, the execution of a transfer — can be recorded as a message on a Hedera topic. The topic is an immutable, ordered log of events. Anyone with access to the topic can verify the sequence of events. Anyone can verify the timestamps. The audit trail is on the public ledger. It is not stored in a private database. It is not controlled by a single party.

This is particularly relevant for institutional settlement, where ISO 20022 message mapping may be required for compliance. Regulators, auditors, and counterparties can independently verify the settlement history by reading the HCS topic. The consensus ordering guarantees that the events are in the correct sequence. The consensus timestamps guarantee that the timing is verifiable. This is a level of auditability that is difficult to achieve with traditional settlement infrastructure.

How Settlement Works on Hedera

Settlement on Hedera, at a conceptual level, involves several steps. These steps are the same regardless of the specific application.

First, the settlement asset is defined. This is typically a stablecoin created through the Hedera Token Service. The stablecoin has defined properties — supply controls, compliance controls, transfer rules. The asset is the unit of settlement.

Second, the settlement parties are identified. Each party has a Hedera account. The accounts are identified by numeric IDs. The accounts hold balances of the settlement asset. The account balances are part of the ledger state.

Third, the settlement transaction is constructed. The transaction specifies the sender account, the receiver account, the asset, and the amount. The transaction may include additional metadata — a reference number, a payment description, a link to an HCS topic. The transaction is signed by the sender’s key.

Fourth, the transaction is submitted to the network. The network nodes receive the transaction. The hashgraph consensus algorithm processes it. The transaction is ordered, timestamped, and finalized. This takes approximately 3 to 5 seconds.

Fifth, the transaction is final. The receiver’s account balance is updated. The update is immutable. The transaction is visible on the ledger. The transaction can be verified by anyone with access to the network. The settlement is complete.

If the settlement involves conditions — for example, a payment that should only execute when a specific event occurs — the conditions can be encoded using HCS topics and smart contracts. The event is recorded on an HCS topic. The smart contract monitors the topic. When the event is recorded, the smart contract executes the transfer. The entire flow is verifiable on the public ledger.

Why Hedera Differs from EVM Chains for Settlement

The differences between Hedera and EVM chains for settlement come down to three properties.

Finality. Hedera offers deterministic finality in 3 to 5 seconds. EVM chains offer probabilistic finality that varies by chain. Ethereum L1 finality takes approximately 12.8 minutes. Layer-2 rollups inherit L1 finality, which can extend to days in worst-case scenarios. For settlement, deterministic finality means the payment is final when the network says it is final. No waiting. No uncertainty.

Fees. Hedera offers fixed, predictable fees denominated in USD. EVM chains offer variable gas fees that fluctuate with network demand. For settlement, fixed fees mean the cost of each transaction is known in advance. No estimation. No variance. No risk of a transaction being stuck because gas prices spiked.

Native services. Hedera offers native token management and consensus messaging. EVM chains require smart contracts for both. For settlement, native services mean the core operations — token transfers, audit trails, compliance controls — are first-class ledger operations. They are faster, cheaper, and more reliable than smart contract equivalents.

These properties do not make Hedera universally better than EVM chains. EVM chains have deeper liquidity for DeFi trading. EVM chains have larger developer ecosystems. EVM chains have more mature tooling for complex smart contract applications. The choice of ledger depends on the use case, and understanding cross-chain bridge security models is essential when moving assets between them. For settlement — particularly institutional settlement, treasury operations, and payment processing — Hedera’s properties are well-suited, especially when paired with ISO 20022 messaging standards.

The Public Nature of Hedera

Hedera is a public network. The ledger is public. The transactions are public. The consensus is public. The governance is public — the council members are publicly known, and the governance decisions are publicly documented.

This public nature is important for settlement because it means the settlement history is verifiable by anyone. A regulator can verify that a payment was made. An auditor can verify the sequence of transactions. A counterparty can verify the finality of a transfer. The verification does not require access to a private system. It requires only access to the public ledger.

The public nature also means that the settlement infrastructure is not controlled by any single party. The consensus is decentralized. The ledger is replicated across all nodes. The governance is distributed across the council. No single entity can unilaterally alter the ledger, revert a transaction, or censor a payment. This is the same decentralization guarantee that public blockchains provide, implemented through a different consensus mechanism.

Practical Considerations

If you are evaluating Hedera for settlement, there are several practical considerations.

Account creation. Hedera accounts require an initial balance to be created. The minimum balance is small — currently 0.1 HBAR for a basic account. Accounts are created through the Hedera SDK or through wallet applications that support Hedera.

Token creation. Creating a token through HTS requires a token creation fee. The fee is fixed. The token creator specifies the token properties at creation time. Some properties — supply keys, KYC keys, freeze keys — can be updated after creation by the designated key holders.

Transaction submission. Transactions can be submitted through the Hedera SDK (available in JavaScript, Java, Go, and Swift) or through the JSON-RPC relay using standard Ethereum tooling. The SDK provides access to all native Hedera features. The JSON-RPC relay provides EVM-compatible access for smart contract interactions.

Compliance. Hedera’s token service supports KYC flags, freeze accounts, and supply controls. These features can be used to implement compliance workflows — verifying participant identity, freezing accounts under legal orders, controlling token supply. The compliance features are native to the token service. They do not require custom smart contract development.

Conclusion

Hedera settlement is the process of transferring value on the Hedera public network using the hashgraph consensus algorithm. The key properties that distinguish it from EVM chain settlement are deterministic finality, fixed fees, and native token and consensus services. These properties make Hedera suitable for settlement use cases where finality guarantees, cost predictability, and auditability matter.

The hashgraph is not a blockchain. It is a different approach to distributed consensus. It trades the open, permissionless validation model of proof-of-work and proof-of-stake blockchains for a council-governed, aBFT consensus model with stronger finality guarantees. Whether that tradeoff is appropriate depends on the use case. For settlement, the tradeoff favors Hedera.

Orkid is building infrastructure that involves Hedera settlement. You can learn more at orkidlabs.xyz. The concepts described in this article are public knowledge from Hedera’s official documentation and published research. The specifics of how any particular product implements settlement on Hedera are separate from the concepts explained here.

Frequently Asked Questions

What is Hedera?

Hedera is a public distributed ledger network that uses the Hashgraph consensus algorithm rather than a traditional blockchain structure. It is governed by a council of major global organizations and offers services for tokenization, smart contracts, and file storage. Hedera is designed for enterprise use cases requiring high throughput and finality.

How does Hedera settlement work?

Hedera settlement finalizes transactions in seconds with asynchronous Byzantine Fault Tolerance (aBFT) consensus. Once a transaction reaches consensus and is written to the ledger, it is considered final and cannot be reversed. This differs from probabilistic finality in some blockchains where transactions can theoretically be reorganized.

What is Hedera Hashgraph?

Hedera Hashgraph is the consensus algorithm that underlies the Hedera network. It uses a gossip-about-gossip protocol and virtual voting to achieve consensus without energy-intensive mining. The algorithm provides fair transaction ordering and fast finality, processing thousands of transactions per second with low fees.

Is Hedera a blockchain?

Hedera is a distributed ledger but not a traditional blockchain. Instead of linking blocks of transactions in a chain, it uses a directed acyclic graph (DAG) structure called a Hashgraph. While it shares properties with blockchains, such as immutability and decentralization, its underlying data structure and consensus mechanism are fundamentally different.