Implement could-be-standard token receiver hook in account and multisig #555
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
anorth
force-pushed
the
anorth/receiverhook
branch
from
88a2e61 to
f39374c
Compare
ZenGround0
approved these changes
Aug 17, 2022
Kubuxu
approved these changes
Aug 17, 2022
anorth
added a commit
that referenced
this pull request
Aug 25, 2022
anorth
added a commit
that referenced
this pull request
Aug 25, 2022
anorth
added a commit
that referenced
this pull request
Aug 28, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implements a token receiver hook that always succeeds. The receivers don't deserialise parameters because they don't inspect them.
I've avoided adding a dependency on the fungible token library from runtime/shared by copying the method number, and avoiding the hook parameter type. I don't think it would be a big deal to add the dep, but it's painful while we depend on a github hash[*].
Even if the calling convention or receiver hook is not standardised, this is a reasonable way for the data cap token specifically to interact with account-type actors, and opens it up to user contracts. But hopefully this standard will be adopted.
*: We depend on a hash because no crates yet, because name will depend on FIP number, which we have't allocated yet).
Closes #538