1

One annoying thing about working with gnosis safes is the generic "GS013" error code when the transaction from the gnosis safe fails; it makes it difficult to debug why the underlying transaction failed. Why doesn't the contract bubble up the underlying error in the contract call to make issues easier to debug? The call and delegateCall in execute should also return a return value that includes the error message with why the underlying transaction failed.

1 Answer 1

1

It was done primarily for gas optimization. It's not worth putting the logic into the contract to be executed on-chain when you can run it off-chain where it's cheaper.

Debugging the transaction is relatively easy with Tenderly, you just need to input the transaction hash or simulate the transaction.

You can also use SimulateTxAcessor to simulate the transaction, this method always reverts and returns data in success:bool || response.length:uint256 || response:bytes format and you can decode the error from the response.

1
  • I was wondering this same thing a while ago. While this makes sense, it would also make sense to include a message to devs in the GS013 error that this could be (/likely is?) masking other errors that can be discovered by simulating on tenderly. Even better: generate a tenderly link that will run that simulation for the user to click on.
    – Kyle Baker
    Feb 19, 2022 at 0:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.