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

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

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

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.

Yes that's what I meant!

1 Like