Using single ERC1820 registry for multiple ERC777 hooks - ERC777 contract question

Support Contracts
1

I have been learning about ERC777 and ERC1820 registries, and there something that has been bugging me related to using a single ERC1820 registry for multiple ERC777 tokens, as the OZ ERC777 contract does;

Can an address register different hooks for multiple ERC777 tokens, using the same ERC1820 registry?

I currently think not. Here is why:

According to EIP777, implementation contracts (those implementing hooks for ERC777 token holders) must implement the IERC777Sender and IERC777Recipient interface, to register the tokensToSend() and tokensReceived() received hooks for an account.

These hooks are registered by calling setInterfaceImplementer(), defined on an ERC1820 registry.

The function has the following signature:
setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer)

  • When registering tokensToSend, you pass KECC(ERC777TokensSender) as the _interfaceHash .
  • When registering tokensToSend, you pass KECC(ERC777TokensRecipient) as the _interfaceHash .

Notice how the setInterfaceImplementer function does not allow you to set the hook for a specific token contract && address. Instead hooks are set on a per address basis.

So therefore:
If an address wants to register a hook H for ERC777 token A and another hook H' for ERC777 token B, and both ERC777 tokens use the same ERC1820 registry (as all OZ contracts do), the latter hook will overwrite the initial hook.

I feel like this should be possible, and Iā€™m probably missing something obvious.
Any help or guidance would be much appreciated.

PS:
For anyone looking for a clear guide, these are the resources I used:
OZ ERC777
OZ ERC777-API
EIP777
EIP1820

2

The hook function can behave differently based on msg.sender, which will correspond to the token address. It can still only be a single contract, but it can behave in different ways for each token.

1 Like
3

Thanks for the reply.
Just one quick clarification question.

  1. Could you please elaborate on what you mean by "It can still only be a single contract, but it can behave in different ways for each token."? Does "it" mean the hook?

If yes is the idea that for a given account, you can define a single hook contract for an interface hash e.g. ERC777TokensSender .
Then this contract can react different based on msg.sender, which will be the token address.

4

Yes that's what I meant!

1 Like
5

Thank you for the response.

I'm a little concerned that this could lead to potential issues for token developers and users, as it requires the end user to manually manage hooks.

It is unlikely that multiple token developers will take care and coordinate with each other when using setInterfaceImplementer(address _addr, bytes32 _interfaceHash, address _implementer), to set some _implementer contract for an address.

Hence each hook call will overwrite each other.

@frangio Should OZ be hardcoding the ERC1820 registry if such overwrites are more than likely ?

Granted ERC777 tokens are not that popular atm, but the current design does not seem future proof.

6

The single ERC1820 registry is non-negotiable, it's defined like that by the EIP.

It's not the token developers that would set implementers for users' addresses. It's the users themselves doing that.

7

Thank you for the response, I think I get it now.
Sorry also that was a bit sloppy on my part.

8

Not at all! All good.