HIP-18: Custom Hedera Token Service Fees

[donaldthibeau]

This discussion is for HIP-18 on the Custom Hedera Token Service Fees

https://github.com/hashgraph/hedera-improvement-proposal/blob/master/HIP/hip-18.md

[Cooper-Kunz]

Thanks @donaldthibeau!

Should I update the "discussions: " section in the actual HIP to point here rather than #90?

[donaldthibeau]

Yeah that'd be great, thanks!

[Cooper-Kunz]

Although I've asked individuals to share their thoughts within this discussions forum, it appears none have 😅

Thus I'm going to document different support/feedback I've received so far on other (publicly available) platforms. Hopefully, that is okay and could help start a discussion. If anyone I included in this post would like to be removed, please let me know via twitter or email.

image source

image source

image source

image source

image source

image source
note: paul's feedback was addressed via b128b90

[tkozzer]

The thing that really clicked for me with this HIP is it gives developers a more frictionless approach to creating royalties and custom fee schedules. I think this could really separate Hedera from the rest of the pack. These native services just make things so much easier and it's a no brainer to build on Hedera. 100% support this!

[Cooper-Kunz]

Reposting this question from @bugbytesinc in #90

"Thinking out loud: if one can modify an exchange schedule, should there be a time dimension added? In other words, would it be beneficial to enforce "this exchange ratio changes on XXX" when the feature allowing changes is enabled?"

Which I think is a fair and interesting thing to consider. I see one of the value propositions of Hedera's controlled mutability being that system administrators and/or network operators can enforce changes whenever they see fit, not necessarily at some predfined delay.

Situations of this include a key being compromised. An admin should be able to use Hedera's controlled mutability as soon as possible to rotate the keys to an account, topic, file, etc. Similarly there are reasons that a token administrator should be able to update a token immediately such as if a business/application network is under some type of spam/DDoS attack, and therefore could update their fees into an "attack mode" so-to-speak, to hopefully cost out the price of the attack to whatever it is they're doing, or if fees were being accumulated by an actor (DAO, or otherwise) that the rest of the community no longer deemed trustworthy.

Additionally I'd expect most developers choosing to implement custom fees are doing so because they see the value in decentralization and on-chain enforcement of the relationships between different tokens, not necessarily just application layer integrations or other situations where a centralized admin/coordinator can change things on the fly like they could with other aspects of controlled mutability. Thus I'd imagine these use cases are unlikely to sufficiently overlap with those that are taking full advantage of "more centralized enterprise things" available on the Hedera network (not to say there isn't interest, but it isn't the target end-user, in my eyes).

[Cooper-Kunz]

Another thing I didn't exactly consider regarding @bugbytesinc's question is that, if you wanted to, you could schedule the "update token fee schedule" transaction out later in the future, using scheduled transactions. So it'd be theoretically viewable on a network explorer and/or discoverable by some mechanism (I'll admit I'm not 100% sure how something like DragonGlass or Kabuto would expose "scheduled transactions" to an end-user yet? sidebar: is that something being worked on?), but I think something like that would solve the issue of "future changes" and wouldn't necessarily need to be implemented directly within HIP-18's proposed alterations.

[bugbytesinc]

Interesting. Thinking about it, if a feature like this did not exist, another option would be publishing the exchange schedule in HCS, but that would still require active action on a party to make the change at the allotted time. I guess its a measure of how much "automation" is to put into L1 vs what to keep out of it. Either way a system can monitor a mirror to catch new exchange rates.

[Cooper-Kunz]

Yeah.. If I'm understanding you correctly, I think that this would be kind of a dealbreaker for what we're suggesting.

require active action on a party to make the change at the allotted time.

If it wouldn't enable actual on-chain enforcement of the fees, and they'd be optionally implemented at each application layer, and that somewhat negates the purpose. I could certainly be misunderstanding you though, tbh.

[bugbytesinc]

In the context of a consumer/individual: I could see "Association" causing confusion. At the moment this notion is probably out of the scope of this HIP, but it might be good to consider special error codes for failures due to a 3rd party token association missing for a transaction with a custom fee?

[Cooper-Kunz]

It would be cool if the network, or a community defined standard/SDK implementation enabled a "one-click" association like experience - where if attempting to associate with token A and tokens B + C were defined to be required for custom fees, associating with Token A would automatically also associate with tokens B + C. Similarly if it was ever updated in the future.

However it is likely much easier and more realistic to just come up with dedicated & helpful error messages, I agree haha. Not sure if other's disagree, but I don't think that it's out of the scope of the HIP, and could fit nicely in this or a compatibility section.

Screenshot from the current "How to teach this" section.

[BreakawayGlenn]

This proposal has awesome implications for transforming multiple market verticals. In the abstract, it reads: "Additional implementations could even allow implementation of custom, and if desired, perpetual royalties (4), for any token issued on HTS, whether fungible or non-fungible."

For book publishing, which is a prototypical multiple-party ecosystem, this has the potential for placing ebooks or any other short-form or long-form digital publication on an even higher and more dynamic level than print, allowing the exchange of unique digital copies paying royalties to content creators and rights holders throughout the exchange process.

Inara is a Hedera use case designing a new category, Streaming Ebooks Micropayments. Since the launch of HTS, we have planned to mainline NFTs into our product roadmap aligned with the micropayments model. This HIP, once implemented, will put that on steroids.

Ultimately, Custom Hedera Token Service Fees will not make possible a billion-dollar economy. It will make possible a trillion-dollar economy.

[Cooper-Kunz]

Thanks for sharing your thoughts and use case, @BreakawayGlenn!

[BreakawayGlenn]

😀👍

…

On Mon, May 31, 2021 at 10:06 AM Cooper Kunz ***@***.***> wrote: Thanks for sharing your thoughts and use case, @BreakawayGlenn <https://github.com/BreakawayGlenn>! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#92 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIGPFH4BMZ5BESGVG2JFWPTTQO6Y3ANCNFSM45DIEGOA> .

[qnswirlds]

Hi @Cooper-Kunz and @rahul-kothari, the Hedera Services Team has come up with a proposed protobufs change for HIP-18
hashgraph/hedera-services#1481
Please help take a look to see if it reflects what was intended in HIP-18.

Also, we have some questions and clarifications seeking, as follows:

1. Are customFees for Hedera TokenTransfer only or for all operations involving tokens? If they are for all, do we anticipate different custom token fees for different operations?
2. What is the expectation for Hedera Services to charge for a TokenTransfer that involves customFees? Do Hedera Services charge (1 + the number of customFees) * the fee (in hbar) for each token transfer?
3. Should there be a time limitation at which customFees expire?
4. Who can update customFees? Is there a need of coordination between the original owner and the current owner in customFees update?
5. Do we really need to change customFees after token type creation? Allowing a change leaves it open for abuse by the token type owner.
6. Could you please provide clarification/elaboration on the CustomFeePercentage and the minimum token fees to be charged?
7. In the CustomFee of each token type, do we want to have a single feeCollector as in the HIP-18 and in the proposed protobufs change, or do we want a list of AccountAmounts where we have to guarantee only the zero sum for the whole transfer? The latter can lead to the case where the payer get paid instead of paying.
8. When creating a new token with customFees, is it required to guarantee all the associations of all token types in the customFees in advance for the payer account? If the answer is yes, do we return some status like INSUFFICIENT_TOKEN_FEE(tokenID) if we don’t have all the associations?
9. We think that we should limit the number of customFees for any token type (for example 5 to 10 customFees), instead of allowing a transaction to use up to 6Kb for this addition field. Can you justify this? Or please provide a scenario where you may need to use up to 6Kb.

Thank you!

[qnswirlds]

Thanks @rahul-kothari for your answers. We will wait for @Cooper-Kunz's and others' feedback as well.

[Cooper-Kunz]

Hey @qnswirlds really appreciate this & fantastic to see how quickly ya'll have jumped on this proposal.

I haven't yet reviewed the protobufs in-depth but let me try and address each of your questions here.

1. Yes, customFees are only applicable to TokenTransfer events. In the future if there are additional operations, such as staking/locking, collateralizing, etc., then we would like them to be associated with those transactions as well. Essentially anything that moves tokens from one entity on Hedera to another entity.

2. I would imagine the fee cost for customFees is determined by the pricing/fee committee within the Hedera Governing council, but something like a linear cost increase based on the number of customFees associated with the token would make sense. I would also suggest proportionately increasing "rent" to linearly reflect this storage burden, too (see HIP-16: Entity Auto-renewal #64?)

3. No, I think this should be immutable, unless defined with a feeAdmin key as @bugbytesinc mentioned here HIP-18: Custom Hedera Token Service Fees #92 (comment)

4. Updating custom fees would be dependent on defining a feeAdmin, again as @bugbytesinc mentioned here HIP-18: Custom Hedera Token Service Fees #92 (comment)

5. I think yes, we need to be able to update this functionality. Imagine a hyperledger fabric (or other permissioned blockchain) network that is utilizing an HTS token to reward the members of the network and a member drops off the network or leaves their consortium, thus requiring them to redistribute fees.

6. Rahul passed along some of the mathemtical/computational concerns with percentages when dealing with digital money but I think the general idea with minimum percentages was to prevent tokens being transferred with "0 balance" transfers at a network level but the application layer sneaking/bundling in token transfers and essentially cheating original authors/artists out of their royalties. So being able to define that {x tokens} need to be paid as a minimum as part of a percentage-based royalty provides an initial baseline price if someone wanted to execute that type of "attack".

7. As @rahul-kothari mentioned I'm not sure I understand what you're referring to as a "single fee collector" - I think if you're saying that if defining a customFee schedule of the following -

1 ABC token -> 0.0.1234
15% of transfer -> 0.0.789
min fee on transfer -> 10 ABC tokens

That the 15% and/or min fee can only go to a single entity on Hedera? If so, yes, I think that is correct. If there was additional fees that were desired I think that they would be added to the list of customFees, and not as a 'bundled parameter' so to speak. Does that make sense and checkout with where your question was coming from?

8. Yes, all payer accounts attempting to utilize HTS tokens with custom fees would be required to hold and therefore be associated with all tokens that are "attached" to a token in the form of custom fees. I think in the case that someone is attempting to transfer a token with custom fees that has been associated with but does not yet have a sufficient balance would throw an INSUFFICIENT_TOKEN_FEE(tokenID) error, but if the payer account had not yet been associated with a custom Fee that is required it would throw a ERROR_TOKEN_ASSOCIATION_CUSTOM_FEE(tokenID) error or something similar, to hopefully help indicate that it's missing an association rather than a balance. If falling back to an insufficient balance error is an easier option, that isn't the end of the world. Users would attempt to go attain a balance of that token and then be hit with a lack of association error.

9. I think that something around 6-12 custom fees would be more than sufficient for most use cases.

To be explicit, we're currently considering an implementation along the lines of the following:

1 token -> app
1 token -> community multi-sig
1 token -> community foundation
flexible % -> author/creator of an NFT 

Among other use cases for different types of tokens. It is unlikely to require up to 6kb or beyond 6-12 customFees.

To be fair: if anyone has use cases beyond ~10-12 custom fee relationships please document them within this thread.

Let me know if there are any other questions 😄

[qnswirlds]

Thank you @Cooper-Kunz!

[topshef]

This might be getting ahead a bit but exploring no.1 and 9 further:

No.1 If a token owner outsources KYC for example, they could manage this via a built-in fee model, if the HIP were to apply to such operations. Multi-sig would play a crucial role in balancing incentives and connecting roles eg KYC control vs token admin vs token fee admin etc

No.9 If there’s no strong technical reason to impose a limit, leaving it open might lead to interesting solutions. Most products have very many parties involved, so being able to reward or charge them directly and decentrally could be very powerful. Accounting and settlement is a huge business cost atm, so passing this to point 2 (Hedera fees) could be a huge saving for business.

[topshef]

Re no.6 in an ideal world an arbitrary fee function might be passed in, but something like ax + b where x is the amount would cover fixed plus linear sliding fees, or a combo of the two.

[bugbytesinc]

As a consumer token holder, if I obtain some value of token that is not immutable, but presently has NO token fees, should I assume that a token can have fees added to it in the future at the pleasure of the admin key holder?

In other words, should there be a separate tokenFeeAdmin key similar to mint/wipe/freeze?

[tinker-michaelj]

@bugbytesinc Sorry I missed this, need to sort out my GitHub notifications.

Your point makes perfect sense...do you think the separation of TokenUpdate/Delete from (conceptually) a new FeeScheduleUpdate operation is needed for the initial release of HIP-18?

We can add the FeeScheduleUpdate transaction later, of course.

[bugbytesinc]

I think I understand: a TX only requiring the CustomFeeKey to sign (without the admin key) would require a FeeScheduleUpdate operation......hmmm....well, I'd speculate yes since updating the fee is implied in the HIP itself, but that's just my interpretation. Whatever does get implemented: I'd recommend against adding protobuf that is deprecated immediately in the next iteration.

[tinker-michaelj]

a TX only requiring the CustomFeeKey to sign (without the admin key) would require a FeeScheduleUpdate operation...

Right, since a TokenUpdate that changes a non-expiry field must be signed with the admin key; and Product wants to avoid more special cases in signing requirements.

Whatever does get implemented: I'd recommend against adding protobuf that is deprecated immediately in the next iteration.

Got it...so that raises the question: Would a CustomFees.canUpdateWithAdminKey flag would still be useful after adding (1) a CustomFees.feeScheduleKey field and (2) a TokenFeeScheduleUpdate HAPI operation?

I guess it might be, as a way to signal that a particular choice of feeScheduleKey and customFees is going to be permanent?

[bugbytesinc]

For consistency, I'd chose not to have a canUpdateWithAdminKey flag if there's an customAdminScheduleKey (or whatever it turns out to be) - also, it might slightly more consistent to flatten out the design, CustomFees need not exist if there's an admin key and a repated CustomFee field. (well, that last might be complicated since repeated fields are not nullable, may still have to have a wrapper)

[tinker-michaelj]

That's true, if we make it legal to remove---but not add---the scheduleAdminKey via the adminKey, then a token owner can "lock in" the fee schedule by removing the feeScheduleAdminKey. No flag would be needed.

I think you're right...will see how this week goes, and if NFTs are well in-hand, I'll add the TokenFeeScheduleUpdate HAPI operation and a top-level feeScheduleAdminKey. 🤞

[anighanta]

Question : During A token create with custom fractionalFee, Should the fee Collector of this fractionalFee be automatically associated
to the created token? [in a fractionalFee the denominating token would the created token]

[bugbytesinc]

Only if they sign the TX, which I think is required for treasuries right?

[bugbytesinc]

Hey @kenthejr looking at the Hedera Roadmap website, it appears this is on the roadmap now. How does this hip get updated to reflect that it is approved?

[bugbytesinc]

It's come up in preliminary implementation, there is some ambiguity in the HIP and in just how fees are assessed for a transaction. This is my thoughts on a more detail psudocode:

Create list for variable fee charges: applied_fees
Create list for transfers generated by fixed fees: applied_xfers
for all token transfer groups: group 
  if group.token has fixed fees:
     for each fixed fee: ffee
        for each xfer in group.token where xfer.amount < 0 : xfer
           APPEND new xfer to additional_xfers such:
              token = ffee.token
              amount = ffee.amount
              from = xfer.account  (original sender account)
              to = ffee.treasury
   if group.token has variable fees:
      for each xfer in group.token where xfer.amount > 0 : xfer
         for each variable fee: vfee
            if xfer.account == vfee.treasury
               continue (sending to treasury already, no acction necessary)
            let applied_fee = vfee.fraction * xfer.amount  (with sanity checks)
            APPEND new xfer to applied_fees such:
               token = xfer.token
               ammount = applied_fee
               from = xfer.account (original receiving account)
               to = fee.treasury

THEN
  **recursively** apply above algorithm to applied_xfers until the algorithm produces an applied_xfers is an empty transfer list.  This is nessary to mitigate creating fake tokens with fees to avoid paying more expensive token fees.

[tinker-michaelj]

Awesome, thanks @bugbytesinc! This is clearly more aligned with HIP-18 as written; and I haven't been able to verify that our current charging strategy was ever officially accepted.

I will create an issue to implement your pseudocode and move in that direction. 👍

[cmdhema]

I wonder why FractionalFee always charge to receiver. If FractionalFee set to 10%, Sender send to 1000 amounts of token to Receiver. Receriver just 990 token.
But When I createToken with CustomixedFee and I transfer to other the token, the fee charged to sender.
How about give to setting when create CustomFractionalFee. Just like
const fee = new CustomFractionalFee()
.setFeeCollectorAccountId(env.operatorId)
.setNumerator(1)
.setDenominator(10)
.setMax(0)
.setMin(0)
.setFeeIncludeTransferAmount(true)

I don't know proper method name.. haha
But setFeeIncludeTransferAmount means that if parameter is true, FractionalFee is include 1000 amounts of transfer token(It is currently). but if false, Fee is chage to Sender. So. Sender must transfer 1010 amounts of the token.

Thanks.

[tinker-michaelj]

Hi @cmdhema, thanks for the idea! I don't think implementation would be too hard either. 👍

Do you have a use case in mind that requires the .setFeeIncludeTransferAmount() option? I can likely get this into 0.17.0 if it's important to you.

[cmdhema]

Hello @tinker-michaelj ! Thanks for your interest.

I think, for example, that marketplace operator can set sales/buy fees respectively. Without smart contracts.
This is a fee case, especially in these days, which is a typically in NFT marketplaces.

Depending on the parameters or apis, it would be better to be able to charge all fees to the seller, charge all fees to the buyer, or split them in a 5:5 ratio.

[gregscullard]

Wondering if the flag could be called "netTransfers(boolean)". If "true", the transfer amounts are net of fees (Alice receives 1000 as promised, Bob pays 10% separately), if false (default), the transfer amounts include the fees (alice receives 990 and the 10% is paid out of the 1000 Bob specified).

[tinker-michaelj]

Thanks @cmdhema and @gregscullard! Have created hashgraph/hedera-services#1926 to extend the FractionalFee definition with a netOfTransfers flag.

When netOfTransfers=true, the charging behavior switches to charging all fees to the sender.

What do you all think?

[gregscullard]

Thank you @tinker-michaelj, this is perfect.

[topshef]

Can anyone help with an example of the royalties use case that's being released on mainnet today? Fractional fee is denominated in the token itself, so only works for fungible tokens. Or is it planned to allow denominating_token_id for fractional fees as is allowed for fixed fees? This would enable the NFT royalty use case which some users have mentioned in this discussion. I feel i must be missing something ;-)

Tithe barns (example of 12th century fractional fee transfer) https://en.wikipedia.org/wiki/Tithe_barns_in_Europe
engineering insights https://www.youtube.com/watch?v=3iBza4XyoGc
case studies https://github.com/hashgraph/hedera-services/blob/master/docs/fees/custom-fees-characterization.md
docs https://docs.hedera.com/guides/docs/hedera-api/token-service/customfees