The Hedera mainnet was upgraded to v0.17.4 on September 2nd, 2021. It included the new functionality of HIP-18: Custom Hedera Token Service Fees — the ability for anyone issuing a token on Hedera using the Hedera Token Service to include programmatic custom fees.
Custom fees can be `fractional`, `fixed`, or `royalty`:
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 transfers a variable number of tokens, collected as a fee, every time a token transfer is initiated. 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 enabled on the fee schedule of an NFT and collected 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.
Fees are configured to be paid in the token being transacted, any other type of token created using Hedera Token Service, or hbar.
In this blog posting, we’re going to outline specific application use cases for custom token fees and code examples to help you get started. The official Hedera SDKs in Java, Javascript, and Go all support custom token fees; you can read the full documentation here.
Here are some JavaScript examples (below) of how you can use the new custom fee features. The features we will go over are creating the fee schedules either with CustomeFractionalFee(), or CustomFixedFee(), or CustomRoyaltyFee() and then the inclusion of these fee schedules in the TokenCreateTransaction().
The new fractional fee schedule is represented by the CustomFractionalFee() object. The object has a numerator attribute, a denominator attribute, and a collector account attribute. The numerator and denominator attributes make up the fraction for the fractional fee. The below snippet is an example of how to make a fractional fee schedule of 10% in JavaScript.
var fractionalFeeExample = new CustomFractionalFee() .setNumerator(1) // Numerator of fractional fee .setDenominator(10) // Denominator of fractional fee .setFeeCollectorAccountID(operatorID) // Collector account
The new fixed fee schedule is represented by the CustomFixedFee() object. The object has a
denominating token attribute, an amount attribute, and also collector account attribute. The denominating token attribute takes a tokenID and if left empty will default to hbar. The below snippet is an example of how to make a fixed fee schedule of 5 hbars in JavaScript.
var fixedFeeExample = new CustomFixedFee() .setDenominatingToken() // Empty for hbar .setAmount(5) // Fee amount .setFeeCollectorAccountID(operatorID) // Collector Account
Now that we have gone over how to create the new fee schedules, we will give an example of how to include them in your new token when using the TokenCreateTransaction object. All you have to do is include the .setCustomFees() passing in the fee schedule you have recently created. The below code snippet is an example of how to set the fee schedule to the fractional fee defined above for 10%.
The TokenCreateTransaction() can take up to 10 custom fee schedules.
var creaTokenTX = await new TokenCreateTransaction() .setTokenName(“Cookie”) // The public name of the token .setTokenSymbol(“CRUNCH”) // The public symbol of the token .setDecimals(4) // Amount of decimals for the token .setCustomFees([fractionalFeeExample])
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 third layer.
For more information visit the official Hedera documentation or reach out to me at @HogwoodWaylon if you have any specific questions on how to utilize the custom fee features in the SDK.
With the upcoming mainnet upgrade to v0.31 (November 10th, 2022) and the introduction of HIP-573, a token creator can exempt all fee collectors from paying custom fees when exchanging token units. Check out this article if you want to learn more.