Custom fee detector

[littletarzan]

Description:

Related issue(s):

Fixes #

Notes for reviewer:

Checklist

• Documented (Code comments, README, etc.)
• Tested (unit, integration, etc.)

[Neurone]

The system contract seems to provide info about the token keys already (see getTokenKey helper).

Is that enough for the use case you mention?

[mgh14]

Using booleans here, it seems like a contract might eagerly reject a token with a reasonable fee schedule. Better safe than sorry, but this might cause other issues for legitimate tokens.

That said, how much information is it appropriate to expose?

[littletarzan]

@mgh14 A major concern I have is that a legitimate token with a reasonable custom fee schedule can be changed by the fee schedule key to become arbitrarily unreasonable, hence why I am looking for a boolean hasCustomFeeScheduleKey.

IHederaTokenService.sol does return the custom fee schedule, but the boolean would be helpful if the goal is to reject all custom fee tokens (https://github.com/hashgraph/hedera-smart-contracts/blob/2e7c67fe3e0306e660a767028dc2f61379033580/contracts/system-contracts/hedera-token-service/IHederaTokenService.sol#L651)

[littletarzan]

The system contract seems to provide info about the token keys already (see getTokenKey helper).

Is that enough for the use case you mention?

@Neurone Unfortunately, here in the services codebase, contracts only "see" simple key types inside the EVM. This means if key is a threshold key or list, it would appear empty. I definitely should have included this in the PR and will update accordingly.

[Neurone]

The system contract seems to provide info about the token keys already (see getTokenKey helper).
Is that enough for the use case you mention?

@Neurone Unfortunately, here in the services codebase, contracts only "see" simple key types inside the EVM. This means if key is a threshold key or list, it would appear empty. I definitely should have included this in the PR and will update accordingly.

I see, right.

What if we propose extending getTokenKey to support complex keys? I assume there's no need to go into detail. Smart contracts can hardly manage those anyway. We can think about adding COMPLEX to the KeyValueType enum. The actual raw value can be 1 (true).

Also, I think you can get all the info about the current custom fees via the getTokenInfo method.
Does the hasCustomFeeSchedule method add anything in this regard?

[littletarzan]

The system contract seems to provide info about the token keys already (see getTokenKey helper).
Is that enough for the use case you mention?

@Neurone Unfortunately, here in the services codebase, contracts only "see" simple key types inside the EVM. This means if key is a threshold key or list, it would appear empty. I definitely should have included this in the PR and will update accordingly.

I see, right.

What if we propose extending getTokenKey to support complex keys? I assume there's no need to go into detail. Smart contracts can hardly manage those anyway. We can think about adding COMPLEX to the KeyValueType enum. The actual raw value can be 1 (true).

Also, I think you can get all the info about the current custom fees via the getTokenInfo method. Does the hasCustomFeeSchedule method add anything in this regard?

@Neurone Yes, I think extending getTokenKey would be sufficient, that way other keys like wipe/freeze/etc can be understood better in the EVM. For my use case, there is no need to go into detail wrt keys. If hasCustomFeeSchedule can be replaced by asking if FixedFee[] memory fixedFees, FractionalFee[] memory fractionalFees, RoyaltyFee[] memory royaltyFees all have length = 0, then I don't think it adds anything special.

[mgarbs]

@littletarzan may you DCO and GPG verify your commits? These checks are failing

[littletarzan]

@littletarzan may you DCO and GPG verify your commits? These checks are failing

It looks like we are going in a different direction than I anticipated so Ii will just close the PR and try again with this new idea of exposing visibility into comple key types