Why relay worker not checking revert beforehand?

I’m connecting to gsn’s relay worker on Ropsten network, and it seems like it relayed all the transaction even they will revert onchain, like this one: Ropsten Transaction Hash (Txhash) Details | Etherscan.

I’ve tried multiple times but still the same result, so I’m guess it’s not a node syncing issue.

The relayer works for profit… If the paymaster agrees to pay, then the relayer will attempt to send the tx, and collect the fees (btw, the same is true for eth in general)

So either the client or the paymaster had to check if the (inner) transaction falls before submitting the request.

In the valent, you can estimateGas your tx to see if it reverts.

The paymaster can return "rejectIfRecipientRevert=true " which means it won’t pay for rejected transactions.

Note that in the latter case, the paymaster can STILL pay for tx, if it takes too much gas (about 100k, including the paymaster itself), so such a paymaster should not blindly trust any recipient contract, but only contracts that it knows to “reject early”

Thank you! I’ll try estimateGas

When you say “reject early” do you mean reject during the “inner transaction”? Is there a solution for when the reject can happens in the postRelayHook (selling tokens, ext)?

The paymaster is supposed to perform all checks in preRelayedCall, and return only if it agrees to pay for the gas.
In the postRelayedCall, it can’t change its mind… So it keeps paying even if it reverts.
To help it keep consistency, if the post reverts, we revert everything (the preRelayedCall and the actual transaction) - but still, it’s the paymaster to pay.
The moral is to write your postRelayedCall carefully, and make sure it didn’t revert…

1 Like