Tokenization is the proposition that ownership of a variety of assets can be tracked in the shared consensus state of a Distributed Ledger Technology (DLT).

With Hedera Token Service (HTS), Hedera supports the ability to issue tokens on a globally distributed public network without compromising performance. Developers define and issue tokens directly to the Hedera mainnet. Tokens inherit many of the characteristics of Hedera’s native cryptocurrency hbar, including asynchronous byzantine fault tolerant (ABFT) consensus, thousands of transactions per second, and settlement in a matter of seconds, without the risk of forking or double-spends. Also, assets tokenized using HTS can easily integrate into the Hedera ecosystem — this includes wallets, exchanges, custody solutions, and more.

As for other Hedera transaction types, clients sending transactions creating, managing, and transferring tokens will pay fees to reflect the burden that transaction places on the nodes of the Hedera mainnet.

This post examines the fee model for HTS transactions.

Hedera Stable fees

If a public DLT denominates their fees in that DLT's native token, then, as the price of that token varies, so will the fee's real cost. The issue is amplified in blockchains where a client must persuade a miner to add their transaction to a block with suitable fee inducement, effectively bidding on a spot within a block.

This fee volatility and consequent uncertainty might be acceptable, if the value being exchanged was a few high-value transactions – the volatility of the fee would perhaps be small relative to the value of the transaction itself. But many enterprise use cases require a high throughput of transactions, each with a low intrinsic value.

Hedera believes that such uncertainty in how much a transaction will cost is impractical for widespread adoption amongst enterprises, such as those that compose our Governing Council, and so designed a fee model that eliminates such uncertainty.

Clients submitting transactions to the Hedera mainnet for processing into consensus pay fees for that service. The fees serve to prevent certain attacks and to generate revenue that funds network operations, such as future node and staking rewards.

Critically, the fees are denominated in US dollars (USD), giving dapps (decentralized applications) the desired fee stability and predictability, but charged in HBAR. As the USD price of HBAR goes up, the number of hbars charged as a fee for a given transaction decreases accordingly, ensuring a stable fee.

The fee for a given transaction is calculated by all nodes based on a fee schedule created and published by Hedera via a gossiped transaction. All nodes will use the same fee schedule in effect at a given time and so stay in sync when incrementing and decrementing accounts to reflect fees.

The fee schedule changes infrequently, such as when a new transaction type (such as HTS) is added, or when a bug is identified, or when market conditions change.

The fee schedule consists of many coefficients, in units of USD per resource consumed, for each transaction and query type.

Nodes analyze the amount of bandwidth, compute, and storage that a particular transaction consumes, multiply by the appropriate coefficients from the fee schedule, and determine a fee for that transaction in USD.

In addition to the fee schedule, Hedera also publishes a file that indicates the exchange rate between USD and HBAR that the nodes should use in converting from the above USD fee to an equivalent amount of HBAR. The calculated transaction fees will consequently be charged in hbars (actually tinybars – which are hundred-millionths of an hbar) and this is the amount that is subtracted from the balance of the account paying the fee for the transaction.

The exchange rate is updated frequently, currently every hour.

When calculating the fee for a given transaction, nodes use the fee schedule to determine the fee in USD, then the current exchange rate to convert to tinybars. As the price of HBARs varies, the amount of tinybars charged for a transactions using the same amount of network resources will vary accordingly such that the equivalent USD fee stays the same.

If the price of HBAR increases, then fewer tinybars are charged. If the price of HBAR decreases, then more tinybars are charged.

HTS Fees

We show below the typical fees for the HTS transactions, sorted by the different categories of transactions. The fee for a specific transaction can vary above or below the typical fee, depending on the particulars of the transaction. For instance, a token transfer with multiple signatures will be more expensive than a transfer with a single signature and creating a token with multiple keys will be more expensive than creating a key with only the treasury key.

The Hedera Fee Estimator allows you to estimate how the specifics of the above transaction types will cause the price to vary from the above typical prices and to predict aggregate cost over time for a use case depending on anticipated transaction volumes for the different transactions.

Let’s consider an example:

1. A user, Alice, wants to transfer a number of XYZ tokens from her account to that of Bob. Necessarily, the token had been previously created, and both Alice’s and Bob’s accounts have previously associated themselves to that token. Alice’s wallet creates the transaction, specifying the relevant token identifier and Bob’s account identifier

2. Alice’s wallet signs the transaction with her private key and submits it to a node

3. The node:

   1. Checks to see whether Alice has sufficient hbars to pay the associated fee

   2. Adds Alice’s transaction to an event and gossips the event out to the rest of the network

4. The network establishes a consensus timestamp and order for the transaction

5. All nodes examine the transaction and:

   1. Validate the signature as authentic

   2. Determine whether the XYZ token exists at the consensus timestamp

   3. Determine whether Alice’s account has sufficient XYZ tokens for the specified transfer amount at the consensus timestamp

   4. Determine the fee for the transaction as above, using:

      1. The particulars of the transaction, for instance, how many signatures, whether there is a memo, etc

      2. The relevant coefficients from the current fee schedule

      3. The current exchange rate

   5. Determine whether Alice’s account has sufficient hbars to cover the calculated fee

6. In the consensus order, nodes update all relevant account balances appropriately:

   1. Reduce Alice’s account’s hbar balance by the calculated transaction fee

   2. Reduce Alice’s account’s XYZ token balance by the transfer amount

   3. Increase Bob’s account’s XYZ token balance by the transfer amount

7. Create a transaction receipt and record for the transaction

The fee for the above transaction will be approximately $0.001, and this fee will be stable even as the price of hbar varies against USD.

It is possible for a single transaction to transfer amounts of multiple different tokens and hbars. Such a transaction is atomic – all transfers succeed, or none do. The fee for such a transaction is slightly higher than the typical $0.001 reflecting the small amount of additional work the nodes perform in validating and processing the transaction.

Summary

For tokenization to reach its potential, fees must be both small relative to the value transfer and predictable. The Hedera Token Service provides both.