Closed bugbytesinc closed 3 years ago
Hi @bugbytesinc, excellent point...we should have made the default tokens.maxCustomFeeDepth=2
instead of 1. I've updated that setting in file 0.0.121
on previewnet, and your test should pass now.
On a related note, the one part of your pseudocode we haven't yet implemented is custom fee exemptions.
I've created https://github.com/hashgraph/hedera-services/issues/1830 to exempt both (1) fee collection accounts and (2) token treasury accounts from being charged custom fees for the tokens they serve. Does that make sense to you?
A qualified yes makes sense to me.
Outbound from the Treasury, it makes sense to me to not charge fees (I'm curious as to what the rest of the community thinks), particularly if the treasury is the fee collector itself.
Inbound to Fee Collectors - yes for variable fees since they'd receive the token anyway. Not sure it applies easily to fixed fees?
One alternative for the treasury fee problem would be if a token could be directly minted to an account holder, but that would be a separate HIP I think. :-)
A qualified yes makes sense to me.
Outbound from the Treasury, it makes sense to me to not charge fees (I'm curious as to what the rest of the community thinks), particularly if the treasury is the fee collector itself.
Inbound to Fee Collectors - yes for variable fees since they'd receive the token anyway. Not sure it applies easily to fixed fees?
One alternative for the treasury fee problem would be if a token could be directly minted to an account holder, but that would be a separate HIP I think. :-)
True, a "targeted mint" would be interesting!
If token T
has fee collector X
for a fixed fee, then X
is automatically "exempt" from these outbound fees when using T
(since it pays itself).
For the treasury of T
, fee exemption does seem the most reasonable default (in analogy to how the Hedera treasury 0.0.2
is exempt from network fees). If desired, we can add a chargeCustomFeesToTreasury=false
flag that can be toggled via the TokenFeeScheduleUpdate
operation.
Description
The protobuf documentation leads the developer to believe that custom fees can nest at least once, meaning a token can have a custom fee that causes additional custom fees to be triggered:
A token having a custom fee of 50 $A is "reference chain length of 1" and Token $A having a custom fee of 25 of $B would be considered "reference chain length of 2".
However previewnet at this time throws the CustomFeeChargingExceededMaxRecursionDepth while attempting to implement this scenario.
Steps to reproduce
Transfer Fails with
CustomFeeChargingExceededMaxRecursionDepth
Additional context
.NET integration test code to point of failure:
Corresponding preview network test log:
Hedera network
previewnet
Version
v0.16.0-alpha? (presumably July 16 build deployed on previewnet)
Operating system
Windows