📢 This HIP is in the last call for review stage. The authors wish to finalize the HIP and appreciate feedback.

HIP-573: Blanket exemptions for custom fee collectors Source

AuthorMichael Tinker
Working GroupKen Anderson (@kenthejr), Richard Bair (@rbair23), Nick Poorman (@nickpoorman)
Discussions-Tohttps://github.com/hashgraph/hedera-improvement-proposal/discussions/571
StatusLast Call
Needs Council ApprovalYes
Review period endsTue, 27 Sep 2022 07:00:00 +0000
TypeStandards Track
CategoryService
Created2022-09-08
Updated2022-09-13
Requires 18
Replaces 18

Abstract

We propose to give token creators the option to exempt all of their token’s fee collectors from a custom fee. This differs from current network behavior, which only exempts a fee collector from fees for which it is the collector. The new option adds a single new protobuf field in the CustomFee message,

message CustomFee {
  ...
  AccountID fee_collector_account_id = 3;
  bool all_collectors_are_exempt = 4;
}

Motivation

The tokenomics of a fungible token with several fee collectors can be awkward when these collectors try to exchange units of the token. For example, suppose we create a fungible token 0.0.T with three fractional fees:

  • Fee #1 sends 1/100 of the transferred value to collector 0.0.A.
  • Fee #2 sends 2/100 of the transferred value to collector 0.0.B.
  • Fee #3 sends 3/100 of the transferred value to collector 0.0.C.

Say collector 0.0.B sends 10_000 units of the token to 0.0.A. Account 0.0.B is exempt from fee #2 (since it is the collector). And since 0.0.A collects fee #1, there is no observable impact of that fee either. But fee #3 diverts 300 units away from 0.0.A and gives them to 0.0.C.

We can try to “clean up” by sending those 300 units from 0.0.C to 0.0.A—but now fee #2 diverts 6 units back to 0.0.B! Clearly this is a hassle.

What we really want is to make all of 0.0.A, 0.0.B, and 0.0.C exempt from each of fees #1, #2, and #3. That is, we want an option to define our custom fees with all_collectors_are_exempt = true.

Rationale

By extending the definition of a custom fee via this all_collectors_are_exempt flag, we provide the most flexibility to token creators; and avoid surprising any users who may be depending on the current behavior.

User stories

  • As the creator of a fungible token whose tokenomics require three custom fees with three different collection accounts, I want my collectors to be able to exchange units of the token without paying custom fees.

Specification

The network needs to include the new all_collectors_are_exempt field in state when it appears in a CustomFee specification; and when deciding whether to assess a custom fee with all_collectors_are_exempt = true, needs to check if the potential payer is a collector for the token type of that custom fee.

Backwards Compatibility

This HIP does not propose any breaking changes. All existing custom fees will be unchanged. Any unchanged TokenCreate operation or TokenFeeScheduleUpdate operation will continue to have the same semantics.

Security Implications

This HIP does not change the precedent importance of securing fee collection accounts.

How to Teach This

If you don’t want your fee collectors to pay a custom fee, create it with all_collectors_are_exempt = true.

Reference Implementation

Please follow this issue to track progress of the reference implementation.

Rejected Ideas

Because HIP-18 did not stipulate any fee exemptions, and arguably it is surprising for fee collectors to ever pay custom fees for their token type, we considered just changing the default behavior to match this proposal. But we could not rule out the possibility of breaking current users, so opted for a backward-compatible approach.

Open Issues

We do not know of any open concerns with this proposal.

References

Copyright/license

This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

Citation

Please cite this document as: