Does DefenderRelayProvider share Relay's retry policy?

Support Defender
1

Then, the transaction is broadcasted through both Infura and Alchemy for redundancy and retried up to three times in case both APIs are down.

Every five minutes, all in-flight transactions are checked by the system. If they have not been mined and more than a certain time has passed (which depends on the transaction speed), they are resubmitted with a 10% increase in their gas price (or the latest gas price for their speed, if it’s greater), which could be up to a 150% of the reported gas price for their speed . This process causes the transaction hash to change, but their ID is preserved. On the other hand, if the transaction has been mined, it is still monitored for several blocks until we consider it to be confirmed.

This policy clearly applies to sending a transaction via a Relayer using the defender-relay-client package, because that's the default method for sending transactions. But does this policy also apply to sending transactions via ethers.js using a DefenderRelayProvider (and DefenderRelaySigner)?

2

Hey @dtp5! The DefenderRelaySigner is just an ethers-compatible wrapper around the defender-relay-client, so yes.

The only case where that policy doesn’t apply is if you sign a tx with a local key (ie your own signer, instead of using the relayer) and submit it manually via the DefenderRelayProvider using an eth_sendRawTransaction call; since in that scenario you’re bypassing the Relayer transaction engine altogether.

1 Like