Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

encodeType of typed data does not encode preset types correctly #1002

Closed
DelevoXDG opened this issue Mar 9, 2024 · 3 comments · Fixed by #1005 or #1019
Closed

encodeType of typed data does not encode preset types correctly #1002

DelevoXDG opened this issue Mar 9, 2024 · 3 comments · Fixed by #1005 or #1019
Assignees
Labels
released on @next Type: bug Something isn't working

Comments

@DelevoXDG
Copy link

DelevoXDG commented Mar 9, 2024

Describe the bug
encodeType of type data does not encode preset types correctly.

You can verify this from the SNIP:

Where for every preset type, it says:

It will be encoded as the following object.

And per the X is an object, every object should encoded as follows:

escape(name) || "(" || escape(param1_name) || ":" || escape(param1_type) || "," || ... || escape(paramN_name) || ":"|| escape(paramN_type) || ")"
If the object references other objects/enum which can also reference other objects/enums, the set of referenced objects/enums is collected, sorted by name, and appended to the encoding.

The spec also refers to this repo for examples, where preset type u256 is included along with its properties.

To Reproduce
Run this test:

`"\\"Example\\"(\\"n0\\":\\"TokenAmount\\",\\"n1\\":\\"NftId\\")"`

Expected behavior
All preset types are encoded as objects:

"Example"("n0":"TokenAmount","n1":"NftId")"NftId"("collection_address":"ContractAddress","token_id":"u256")"TokenAmount"("token_address":"ContractAddress","amount":"u256")"u256"("low":"u128","high":"u128")

Actual behavior
All preset types are encoded as basic types:

"Example"("n0":"TokenAmount","n1":"NftId")

Desktop (please complete the following information):

@DelevoXDG DelevoXDG added the Type: bug Something isn't working label Mar 9, 2024
@penovicp penovicp self-assigned this Mar 11, 2024
@penovicp
Copy link
Collaborator

Note that in the current code, following the SNIP notation, encode_type is treated as a simple type but encoding is applied as for a custom type/object.

@sgc-code Could you confirm that encode_type should be applied the same as for a custom type? I recall being conflicted about this while working on #920 since either approach is essentially a constant but it seems I didn't remember to explicitly ask about it.

Copy link

🎉 This issue has been resolved in version 6.4.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Copy link

github-actions bot commented Jul 3, 2024

🎉 This issue has been resolved in version 7.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
released on @next Type: bug Something isn't working
Projects
None yet
2 participants