HTS: A New Paradigm for Smart Contract Applications

This article was originally published July 27, 2022 on SEVO's Medium blog.

—

In my article The Future of DeFi is Hashgraph, I outlined some key differences between the Hedera and competing smart contract platforms. My choice to join the Hedera community rather than Ethereum’s was no accident, and I hope to illustrate this further by examining the differences between ERC-20 and HTS.

For token development to be possible, a network requires templates or guidelines. These standards help ensure smart contracts remain composable. For instance, when a new project issues a token, it must be compatible with existing DeFi protocols.

Ethereum came to this realization soon after their 2015 launch and were quick to introduce the ERC-20 standard for fungible tokens, which implements an API for tokens within smart contracts. ERC-20 token contracts are smart contracts containing a map of account addresses and their token balances. Contract functionalities include transferring tokens from one account to another, getting the current token balance in an account or supply on the network, and approving whether a token (of specified amount) from an account can be spent by a third-party account.

Given that ERC-20 was developed in 2015, it is no surprise that this standard has significant shortcomings. For example, if tokens are sent to a contract and an error occurs, one would expect this transaction to be rejected such that no funds are lost. This is not the case for ERC-20 since a transfer requires one of two functions to be activated; the first being the transfer function, which allows you to send tokens to a specific address, and the second being a combination of functions approve + transferFrom, which is used to deposit tokens into a smart contract. If a user mistakenly deposits tokens into a smart contract using the transfer function, the contract will not see this transaction and the funds will be frozen. Moreover, if such contract does not implement the function of emergency token withdrawal, it is impossible to return the funds.

Another shortcoming of ERC-20 is the gas required to call a token contract’s transfer or approve + transferFrom function. Consider a user on Ethereum who wants to send 20,000,000 SHIB tokens to another address.

After selecting a recipient address and paying the gas fee, the transaction is sent directly to the SHIB token contract. Here, the transaction input data which is sent to the ERC-20 contract includes the destination address and the amount of SHIB tokens. This calls the transfer function on the SHIB contract, and soon after the destination address receives its tokens. Ethereum users may have noticed that gas fees are significantly higher when interacting with ERC-20 tokens than when interacting with ETH itself. Gas can be thought of as a representation of how much computation work the network needs to do to accomplish its task, and users are billed according to this metric. Since every token contract needs to report its state back to the entire network, interactions are generally much more costly than simple transfers of ETH tokens, which are not ERC-20.

Such a fee discrepancy makes sense from the perspective of Ethereum’s architecture, but feels counterintuitive from the perspective of the end user. “Why should I pay more to move less?”

Hedera released the Hedera Token Service (HTS) in 2019. HTS offers configuration and issuance of native fungible and non-fungible tokens. This means that — unlike ERC-20 and ETH — HTS tokens inherit the same attributes as HBAR; namely, 10,000+ tps (throttled) throughput, $0.0001 average transaction cost, 3–5 second confirmation time (with finality), and 0.00017 kWh per transaction. HTS achieves this by leveraging existing network primitives to allow users to define and interact with tokens as a native network entity. Furthermore, Hedera smart contracts can control tokens through HTS, enabling dApps to take advantage of the network’s high performance and predictable fee structures for token operations. HTS extends even further beyond the limitations of ERC with features such as built-in configurable compliance and programmability (e.g., custom token fees and scheduled transactions).

It is evident that HTS transactions are more efficient than smart contract calls required for ERC-20 tokens, so we must ask ourselves why a developer would choose the latter when building on Hedera. Given that HTS is the dominant standard on Hedera, using ERC-20 is sub-optimal from an ecosystem standpoint. If Hedera smart contract applications fail to adopt one standard, then the ecosystem is not as cohesive, and integrations become difficult. This fragmentation is precisely why Ethereum adopted the ERC-20 standard. Moreover, it is the reasoning behind standardization across all industries. There are several other problems that ERC-20 tokens pose; namely, where they come from and how they are obtained. There are only two potential sources: bridged tokens and other smart contract applications. As it currently stands, tokens ported through Hashport — the only bridge connecting Hedera to other chains — are wrapped as HTS. It is safe to assume other bridges will follow suit.

Supporting ERC-20 tokens is a bet against HTS being the dominant standard on Hedera, and with the power of HTS and the ecosystem that Hedera provides, this seems unlikely. If you are building a smart contract application on the Hedera network, it makes sense to support the HTS standard, as this is a natural evolutionary step forward.