IHederaTokenService precompile token create selectors are inconsistent with documentation

[Nana-EC]

Description

Currently the selectors utilizing token supply params as part of a token create do not correctly match the docs and proto.

• maxSupply is noted as an int64 but was implemented as uint32
• totalSupply is noted as uint64 but was implemented as uint

Steps to reproduce

Attempting to pass token supply params to precompile create functions outside of the ranges documented but within the ranges implemented results in contract reverts e.g.

• maxSupply where uint32.MAX < x < int64.MAX
• totalSupply where uint64.MAX < x < int256.MAX

Additional context

Current selectors where types differ are noted here

• createFungibleToken(HederaToken memory token, uint initialTotalSupply, uint decimals)
• createFungibleTokenWithCustomFees(HederaToken memory token, uint initialTotalSupply, uint decimals, FixedFee[] memory fixedFees, FractionalFee[] memory fractionalFees)
• getApproved(address token, uint256 tokenId)

No response

Hedera network

other

Version

v0.30.0

Operating system

No response

[lbaird]

Should it be int64 rather than uint64?

…

On Tue, Sep 6, 2022 at 4:21 PM Nana Essilfie-Conduah < ***@***.***> wrote: Description Currently the selectors utilizing token supply params do not use uint64 but instead a mixture of uint32 and uint Steps to reproduce Attempt to pass token supply params with non uint64 Additional context *No response* Hedera network other Version v0.30.0 Operating system *No response* — Reply to this email directly, view it on GitHub <#3902>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDBYW3FYXWRY6FGGEOCZBTV46YXJANCNFSM6AAAAAAQGGKH3I> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[shemnon]

Protobufs have mixed uint64 (for initial supply) and int64 (for total supply). My experience with recent EVM issues are that java and unsigned integers are bugs waiting to happen.

[Nana-EC]

Should it be int64 rather than uint64?

@lbaird the issue is a bit more detailed as Danno noted.
We're updating the code to match the description on docs.hedera and the token create protobuf where maxSupply is a uint64 and initialTotalSupply is an int64
To answer your question maxSupply should be int64 and totalSupply should be uint64 as documented.

I've updated the title and description to align with the intention.
Initial form was to ensure we were tracking it.

[lbaird]

I agree. We should avoid unsigned integers in our protobufs and code.

…

On Tue, Sep 6, 2022 at 5:54 PM Danno Ferrin ***@***.***> wrote: Protobufs have mixed uint64 (for initial supply) and int64 (for total supply). My experience with recent EVM issues are that java and unsigned integers are bugs waiting to happen. — Reply to this email directly, view it on GitHub <#3902 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDBYW5NFQRHG3WGNSNBWALV47DRBANCNFSM6AAAAAAQGGKH3I> . You are receiving this because you commented.Message ID: ***@***.***>

[lbaird]

It sounds like the documentation should be fixed. Unless there’s a logical reason to do it that way. In general, everything should be signed, to match what’s available in Java.

…

On Tue, Sep 6, 2022 at 6:15 PM Nana Essilfie-Conduah < ***@***.***> wrote: Should it be int64 rather than uint64? @lbaird <https://github.com/lbaird> the issue is a bit more detailed as Danno noted. We're updating the code to match the description on docs.hedera <https://docs.hedera.com/guides/docs/hedera-api/token-service/tokencreate> and the protobuf where maxSupply is a uint64 and initialTotalSupply is an int64 To answer your question maxSupply should be int64 and totalSupply should be uint64 as documented. I've updated the title and description to align with the intention. Initial form was to ensure we were tracking it. — Reply to this email directly, view it on GitHub <#3902 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDBYWZSGVRMS2ZN2MECRKTV47GBVANCNFSM6AAAAAAQGGKH3I> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Nana-EC]

It sounds like the documentation should be fixed. Unless there’s a logical reason to do it that way. In general, everything should be signed, to match what’s available in Java.

@lbaird circling back.
Given the progress of 0.30 we decided it wasn't worth the risk to pursue protobuf changes.
The approach utilized by the precompile allows us to version and support different selectors.
As such we decided to unblock the customer issue first and will circle back with #3916 to address the issue in all occurrences