Using same Defender Relayer on multiple chains

Hi everyone!

I want to use a Defender Relayer account as the admin of two contracts residing on two different chains (one on Ethereum and the other on Polygon). Is it possible to have a Defender Relayer available on two different chains?

Thank you!

1 Like

Hey George! I’m afraid not, each Relayer is assigned to a single network. You’ll have to define one for Ethereum and one for Polygon.

1 Like

Are there any workarounds to this? Can the relay signer (from https://www.npmjs.com/package/defender-relay-client) be connected to a custom provider? If not, what about just signing the transaction via the relay provider but use a custom provider to relay it?

just signing the transaction via the relay provider but use a custom provider to relay it

Even if you did that, the tx would be invalid in the other chain due to EIP155 replay protection. Now, I understand that this is required for bridging from Ethereum to Polygon (I got a message from Peter on this). Let us see if there’s anything we can do about it.


Update: I’m going through Polygon’s docs, and it’d seem that it’s possible to deposit for a different address when bridging assets. The bridge contract exposes a depositEtherForUser method that accepts the address on the other side of the bridge, which seems like it can be different than the sender. Can you confirm this?

@spalladino Thank you for your reply! Yes, indeed, bridging tokens to Polygon doesn’t necessarily need to be performed to the same address. However, our main issue is that having separate addresses (eg. relayers) on Ethereum vs Polygon adds a layer of complexity (to my knowledge, most of the users that use an L2 are using the same accounts as they use on L1). We would like to use the same relayer secrets for interacting with both Ethereum and Polygon and not have to switch between the two (or at least have the option to connect the relay signer to our own provider).

Understood, let me discuss with the rest of the team and get back to you early next week.

I don’t expect this to work due to EIP155 protections, right? Otherwise, we could add a “sign but not send tx” method.

I was thinking in terms of being able to connect to a different provider, which works for regular signers (eg. https://github.com/ethers-io/ethers.js/blob/master/packages/abstract-signer/src.ts/index.ts#L81), though I’m not sure if it’s doable to have this implemented.

Thing is, as long as the relayer is associated to a network, the signatures it produces will only be valid for that network, even if they are broadcasted (via a different provider) to another network.

Hey @George_Roman, we’ve been discussing this with the rest of the team, and it makes sense to add support for reusing a private key from another relayer on the same team for another relayer in a different network. We’ll try to tackle this during June/July. We’ll keep you posted on our progress!

And since we’ll be tackling this: do you anticipate similar use cases for other parts of the system? For instance, do you think you’ll need to run the same autotask or sentinel on different networks?

Thank you @spalladino! This would still involve two different relayer secrets both pointing to the same underlying private key, right?

For our use cases I don’t think this is something we’ll need in the future. It would be nice to have but there are also some easy workarounds to it.

1 Like

Yes, that’s correct: you’d have two relayers, each with its own access key/secret, both which using the same account/privatekey, and running on different networks. It won’t be possible to create two relayers with the same key on the same network.