Clarification on Defender Relayer whitelist

Support Defender
1

Hi,

Quick question about Defender Relayer policies,

The whitelist it's only applied the to the TARGET of the tx, right?

Is there any way to apply this whitelists to the RECIPIENT of an ERC20 Transfer or the destination address when we are withdrawing funds from the relayer account?

Thx in advance

2

Hey @Marto

Indeed, the whitelist applies only to the to parameter of a transaction. In the case of whitelisting only recipients of an ERC20, we should implement a new type of Relayer policy to filter specific transaction data. This is not currently on our roadmap but definitely sounds interesting.

Curious to know, the only application you need is for ERC20s, right? What do you think it should look like if we implement a new policy?

Best

3

Hi @ernestognw,

Sad to hear that this little feature it's "missing", unfortunately it's kind of a deal breaker for the use case that we need to resolve. I think we will have to code some kind of relaying service in house.

About what I think this could look like is...

Taking the advantage that an ERC20 Tranfer recipient address it's not so hard to find in the received calldata of the tx, there are 2 kind of simple solutions:

  • Option A, simply run the same whitelist checks that are already done with the target address with this new found address. This is the simplest at the coding level because only require a backend extra verification and no frontend changes, but could bring some issues with some old users because you are effectively expanding the possible valid txs universe.

  • Option B, create a new whitelist of receivers at the policies section and make the same new verification checks as explained before.

Hope this helps... You can reach me if anything it's not clear enough.

Also, I think you should update the official Policies docs (https://docs.openzeppelin.com/defender/relay#policies) because it currently saying "receiver whitelist":

image
image742×100 9.84 KB

And could be some confusing, we could add some clarification explaining that it's applies only to the to parameter of a transaction.

Take care,

Marto

1 Like
4

Sad to hear that this little feature it's "missing", unfortunately it's kind of a deal breaker for the use case that we need to resolve. I think we will have to code some kind of relaying service in house.

Indeed is something that's interesting to implement but we never considered it, so we appreciate the feedback and it's already noted on the roadmap. We have to make an estimation for this before committing a release date since it's not an immediate priority.

  • Option A, simply run the same whitelist checks that are already done with the target address with this new found address. This is the simplest at the coding level because only require a backend extra verification and no frontend changes, but could bring some issues with some old users because you are effectively expanding the possible valid txs universe.
  • Option B, create a new whitelist of receivers at the policies section and make the same new verification checks as explained before.

This definitely helps since it is a pointer to look at whenever it's implemented. Thanks for the details. However, we still have to discuss if it's worth implementing the policy like this or a more general and long-term fix to filter calldata patterns (eg. only let txs that include 0x00... address in the second parameter, or only execute txs that are calling 0x123... function identifier).

Also, I think you should update the official Policies docs (https://docs.openzeppelin.com/defender/relay#policies) because it currently saying "receiver whitelist":

Thanks for flagging, I'm adding a note to our docs.

Best!