What is transaction queueing?
Argent X Multisig accounts allow users to queue and manage pending transactions. As shown in the screenshot below, the "Activity" tab now features two sections: "Queue" and "History." Those in the "Queue" are transactions that are pending but not yet executed. Those in "History" represents transactions that have already been executed (accepted on L2).
Queued transactions must be executed in the correct order due to each transaction’s unique nonce, which increments by 1 with each transaction. This ensures proper processing on the blockchain.
For instance, following the example in the above screenshot, you can see that the expected order for the transactions are as follows:
- #1 — First, “Send” 0.5 ETH
- #2 — Second, Add owners and set 2/3
- #3 — Then lastly, Remove mulsitig owner
Transactions in the queue must follow this order; otherwise, subsequent transactions cannot be executed.
How to reject a queued multisig transaction?
You may sometimes wish to cancel one of the transactions that are in the queue. In order to do this, you will need to “reject” this transaction on-chain. You can confirm your intent by selecting "Yes, reject this transaction" in the pop-up.
Rejecting a transaction on a multisig is an on-chain action. You’ll be required to sign a “onchain rejection” message, and collect signatures from the required signers.
Once all required signers approve the rejection, the transaction is rejected (the nonce is burned). The rejected transaction will be removed from the queue, as shown below; you can see that the first “Send” 0.5 ETH” is gone, and only the rest of the 2 are in the queue now.
Why is rejecting a transaction onchain and costs network fees?
While this may not be a common use case, this is crucial for security. It ensures that the transaction is permanently canceled, with on-chain proof, preventing any future tampering.
Since Argent Multisig supports off-chain confirmations, signatures are stored on our backend service. To prevent these signatures from being reused maliciously, the nonce of the rejected transaction must be burned. This on-chain rejection guarantees that the nonce cannot be used again, ensuring the transaction cannot be executed by unauthorised parties.