Hedera Improvement Proposals (HIPs) offer the developer community a voice to drive the direction of the Hedera codebase. These proposals range from core protocol changes, to applications, frameworks, and standards built on top of the Hedera public network and used by the community.
Over ten HIPs have been submitted by members of the Hedera developer community since the inception of the program this year. And as of today, HIP-17: NFT (Non-Fungible Token) Support and HIP-18: Custom Hedera Token Service Fees are available in Hedera Services Code v0.17.4 on testnet and mainnet. In addition, NFT metadata standards for the Hedera Token Service, found in HIP-10: Token Metadata JSON Schema, have become a recommended best practice.
These HIPs were submitted by Hedera developer community members, discussed in an open forum (HIP-10, HIP-17, HIP-18), and voted on by the Hedera Council’s technical steering committee.
HIP-10, HIP-17, and HIP-18 work in conjunction to bring a feature-rich experience to developers building NFT applications on Hedera. Let’s dive in to learn more about the Hedera Token Service’s custom fees, NFTs, and metadata.
If you're a developer and looking to get started using these features, check out the quick-start guides created by Hedera Developer Evangelist Waylon Jepsen (@0xjepsen):
• Developer Quick-Start: NFTs and Metadata
• Developer Quick-Start: Custom Token Fees
HIP-18: Custom Fees was submitted by Cooper Kunz and Jason Fabritz of the Hedera-powered creator economy application Calaxy and Rahul Kothari, a researcher at bluesky and Engineering Intern at the Ethereum Foundation.
Custom fees enable tokens on Hedera to be used for things like utility fees in applications that support their own fungible token or perpetual royalties for NFTs. This functionality is built directly into the Hedera Services Code (you don’t need to configure a smart contract), making it even easier to implement using the official Java, Javascript, and Go SDKs.
When creating a new token using the Hedera Token Service (HTS), you can create a custom fee schedule for that token. Up to 10 unique fees can be configured to be sent to a maximum of 10 accounts (fee collector accounts) within a token’s fee schedule. Fees are paid to their associated fee collector account every time a token is transferred. The fee can be configured to be deducted from either the sender or receiver of a token.
The fee schedule lets you define unique token IDs to express in which token(s) the fee(s) must be paid. This token ID can be the same as the token transferred, HBAR, or a different token entirely. There are two types of token fees, as described below, that can be used singularly in a fee schedule or mixed and matched up to 10 times for a single token type.
Three types of custom fees can be specified by the creator:
Fixed Fee: A fixed fee transfers a set number of tokens, collected as a fee, every time a token transfer is initiated.
Fractional Fee: A fractional fee can be configured that is enforced by any transaction in which the given token is transferred. The amount is configured by setting a numerator and denominator to determine a fractional (or percentage) fee. Fractional fees can be configured to impose minimum and maximum limits on the amount transferred.
Royalty Fee: A royalty fee can be configured on the fee schedule of an NFT and sent to the associated fee collector account during the transfer of ownership. This fee is defined as a fraction of the fungible token value used in exchange (HBAR or a custom fungible token) for the NFT, as defined by the fee schedule of the NFT. The fee is collected from the receiver of the NFT in a transaction and sent to the NFT’s fee collector account, as defined in the fee schedule.
A fungible token’s fee schedule can include a combination of both fractional and fixed fees.
Negative fixed or fractional fee values are not allowed.
The token’s treasury account and fee collector account(s) are exempt from paying fees to transfer said token.
A single transfer transaction cannot alter more than 20 account balances. A debit of tokens from one account and credit to another is equal to 2 account balance alterations.
In other words, a token being transferred may have a custom fee schedule (first layer) which requires you to pay fees in another token that has its own fee schedule (second layer). If that’s the case, a token paid as a fee within the second layer cannot have its own fee schedule — otherwise, that would create a very long chain or an infinite loop of successive fee calculations and transfers.
The following SDK versions support custom Hedera Token Service fees:
Java: 2.0.9/1.5.1
JavaScript: 2.0.26/1.4.11
Go: 2.1.11
.NET
Reminder: SDK v1 support will be deprecated in October 2021. Please read this blog for more information.
Custom Fees are added to a token during TokenCreate and costs an additional $2 USD at a fixed price, paid in HBAR.
Fees associated with Custom Fees are found below. For a full list of fees, please visit the documentation or check out the Hedera fee estimator tool.
Hedera API Call
Fee
TokenCreate (custom fees)
$2.00
CryptoTransfer (custom fees)
$0.002
TokenFeeScheduleUpdate*
$0.001
*There are two temporary limitations to HIP-18 in this release. First, the tokenFeeScheduleUpdate transaction is not currently available. Second, only one royalty fee can be charged for a non-fungible token type. Both limitations will be removed in release 0.18.0.
HIP-17: NFTs was submitted by Daniel Ivanov, Blockchain Solutions Architect at LimeChain.
The Hedera Token Service has adopted the most ubiquitous pattern for creating NFTs via HIP-17 as a “Whole Non-Fungible” token. In this pattern, a token class is defined and each instance (token) within that class shares certain properties but differs on others — these other properties could be, for example, the numbered edition of a series of cards or artwork. Each NFT is expected to not be equal in value between different instances. It’s encouraged that all developers creating NFTs on Hedera adopt this new standard.
While some have used the singleton feature of fungible tokens to implement NFTs, it is expensive. HIP-17 defines a native Non-fungble token service to enable true scalable NFTs.
Non-fungible token-related API calls have their own fees on Hedera, set in USD at a fixed price but paid in HBAR. As mentioned above, with NFTs on Hedera, a token class is created on the network for $1 and associated NFTs within that token class minted at only $0.05 per token. Although each token minted is within the same token class, each token can possess properties that differentiate it from others within the same class.
Fees associated with NFTs are found below. For a full list of fees, please visit the documentation or check out the Hedera fee estimator tool.
TokenCreate
$1.00
TokenMint (non-fungible)
$0.05
TokenGetNftInfo
$0.0001
HIP-10: Token Metadata JSON Schema was submitted by Sam Wood, CTO & Co-Founder, Susan Chan, Project Manager, Stephanie Yi, Software Engineer, and Khoa Luong, Software Engineer, at LutherSystems.
With the addition of HIP-10: Token Metadata JSON Schema, everyone can append metadata to any token by creating a JSON file using the schema outlined in the specification. It’s recommended that the JSON file be uploaded to an immutable and decentralized storage network, such as Filecoin, and the URI once uploaded be included in the NFT’s memo attribute.