Speed up pending transactions

[lukasschor]

What is this feature about? (1 sentence)

This allows users to speed up pending transactions by submitting them again with a higher gas price.

Why is it needed? What is the value? For whom do we build it?

• If an on-chain transaction (confirm, reject, execute) is initiated with a low gas-fee, these transactions can get stuck.
• Some wallets allow to speed up transactions (e.g. Metamask) but others do not (e.g. Ledger). We should have a way to re-trigger these actions from the interface.

High-level overview of the feature

• There is a button to "Resend" / "Speed up" transaction executions that are in pending state.
• No need to implement this for confirmations/rejections yet, as most confirmations/rejections are assumed to be off-chain signatures in the mid-term anyways.
• The user should be able to select the gas price manually.

Open questions

• Should this work together with #838?

Updates

• Nov 5, Tobi: Add more details

[fernandomg]

What I understand is: we need to have the txHash from the wallet (MM, Ledger, etc), get the object of that tx and modify it's gasPrice, sign it and send it. Always making sure that the originator of the stuck tx is the connected user.

If that's correct: is it right we handle this in the Safe? This doesn't look as a Safe's responsibility.

[zdexter]

Agree this should be a feature of Gnosis Safe itself. Currently if one of the multisig addresses, let's call it X, is connected to MetaMask and you sign a transaction through Gnosis Safe, MetaMask will not display the pending transaction in the activity tab for X. Thus there is not a convenient/obvious way to speed up the transaction. But you shouldn't have to use two different UIs to speed up a pending txn anyway.

[johannesmoormann]

With the introduction of EIP-1559 on Ethereum and other networks speeding up transactions is less relevant and we will close the issue for the moment.

[rcmurphy]

I would argue it's still highly relevant because even though speed is increasing, gas is still quite volatile. If I submit a transaction with 45 gwei gas, and gas immediately spikes to 60 gwei, I either have to wait for it to fail or reject it. This is a problem I am facing pretty routinely.

[perhamgirl]

I'd agree, we face this problem too and would love to see this feature implemented.

[johannesmoormann]

Thanks for the feedback @rcmurphy and @perhamgirl, I'll reopen the issue then and we will take another look. As a workaround for the time being (requires new signatures though): instead of rejecting the tx you could also create the tx again and use the same SafeNonce for it (in advanced parameters settings during tx creation). Just make sure that you update your connected wallet nonce as well when executing the new tx.

Or reload the interface to get rid of the pending state, which is local, and execute the tx again with the same wallet nonce of the original and stuck tx.

[adam-hurwitz]

Thanks for the feedback @rcmurphy and @perhamgirl, I'll reopen the issue then and we will take another look. As a workaround for the time being (requires new signatures though): instead of rejecting the tx you could also create the tx again and use the same SafeNonce for it (in advanced parameters settings during tx creation). Just make sure that you update your connected wallet nonce as well when executing the new tx.

Or reload the interface to get rid of the pending state, which is local, and execute the tx again with the same wallet nonce of the original and stuck tx.

Thank you for the workaround @johannesmoormann!

For the Safe Desktop app this means restarting the app to clear the pending transaction from the app's local memory. Also, it's important to ensure that the nonce of the signer's address is the same as the signer's address original transaction that is still pending.

Go to the Safe app > Transactions > Queue > Confirm > Advanced options > Edit Owner Transaction (Execution) > Nonce: Use the same nonce on the signer's address as originally used if overwriting or canceling a pending transaction.