Skip to main content
Try Cobo WaaS Skill in your AI coding assistant (Claude Code, Cursor, etc.). Describe your needs in natural language to auto-generate production-ready SDK code and debug faster ๐Ÿš€
This guide outlines the processes for canceling, speeding up, and dropping transactions. By mastering these techniques, you can ensure that your transactions are processed promptly and accurately.

โ€‹
Paginate the transaction list

The List all transactions operation returns results one page at a time. Pagination is controlled by two separate cursor parameters, before and after, which move the page window in opposite directions. The direction parameter is unrelated to paging and only controls sort order.
  • after: Pages forward to the next page. Pass the after value returned in the pagination object of the previous response.
  • before: Pages backward to the previous page. Pass the before value returned in the pagination object of the previous response.
On your first request, do not include either before or after. Cobo returns the first page together with a pagination object that contains the before and after cursor values you use to navigate from it. Use the limit parameter to set the number of records per page.
The direction parameter is a separate sort control and does not move the page window. It accepts ASC (ascending, the default) or DESC (descending), and only determines the order in which records are returned. Paging forward and backward is always controlled by after and before.

โ€‹
Pagination walkthrough

  1. Send the first request with no before and no after parameter. The response returns the first page and a pagination object containing before, after, and total_count.
  2. To move forward to the next page, send another request with after set to the after value from the previous response.
  3. To move backward to the previous page, send another request with before set to the before value from the previous response.
  4. When the response returns an empty after value, you have reached the end of the results. When the response returns an empty before value, you have reached the start of the results.

โ€‹
Cancel a transaction

Canceling a transaction stops it while it is still pending. You might want to cancel a transaction if it was initiated by mistake, if you need to modify its details, or if it no longer needs to be executed. Canceling prevents the transaction from being processed further.
This operation only applies to transactions from MPC Wallets and Smart Contract Wallets.
A transaction can be cancelled if its status is either of the following:
  • Submitted
  • PendingScreening
  • PendingAuthorization
  • PendingSignature (Only when the sub-status is Queue, InsufficientBalance, InsufficientBalanceFundLocked, PendingSignerApproval, PendingSystemProcessing, or Built)
To cancel a transaction via the WaaS 2.0 API, use the Cancel transaction operation. This requires the transaction ID of the transaction you wish to cancel.

โ€‹
Replace-By-Fee (RBF) transactions

Replace-By-Fee (RBF) is a feature that allows you to replace an unconfirmed transaction with a new version that typically pays a higher transaction fee. This functionality provides flexibility to modify transactions after they are broadcast but before they are confirmed by miners. The key benefits of RBF include the ability to:
  • Accelerate transaction confirmation by increasing the fee.
  • Cancel a pending transaction.
  • Modify transaction details such as the destination address or transfer amount.
The two most common use cases of RBF are speeding up and dropping transactions. For how a replaced transactionโ€™s status changes and the events it emits, see RBF (Replace-By-Fee) transaction lifecycle.

โ€‹
Speed up a transaction

Speeding up a transaction leverages RBF to replace the original transaction with a version with a higher fee, encouraging miners to prioritize it for faster confirmation. You might want to speed up a transaction if it is taking too long to be confirmed due to low fees. This is particularly useful in times of network congestion.
This operation only applies to transactions from Custodial Wallets (Web3 Wallets), MPC Wallets and Smart Contract Wallets. It does not apply to transactions on the following chains: VET, TRON, TVET, SOL, and TON.
A transaction can be sped up only if its status is Broadcasting. To speed up a transaction, use the Speed up transaction operation. This requires the transaction ID of the transaction you wish to speed up.
If you speed up a transaction from a Smart Contract Wallet, two RBF transactions will be triggered, one for the transaction from the Smart Contract Wallet, and the other for the transaction from the Delegate.

โ€‹
Drop a transaction

Dropping a transaction leverages RBF to replace the original transaction with a version that effectively cancels it.
  • For EVM chains, this RBF transaction has a transfer amount of 0 and the sending address is the same as the receiving address.
  • For UTXO chains, this RBF transaction has a transfer amount of 0 and the destination address is the same as the change address in the original transaction.
You might want to drop a transaction if it was initiated by mistake, if you need to modify its details, or if it no longer needs to be executed but it cannot be canceled.
This operation only applies to transactions from Custodial Wallets (Web3 Wallets), MPC Wallets and Smart Contract Wallets. It does not apply to transactions on the following chains: VET, TRON, TVET, SOL, and TON.
A transaction can be dropped only if its status is Broadcasting. To drop a transaction, use the Drop transaction operation. This requires the transaction ID of the transaction you wish to drop. When a transaction is being dropped, any subsequent drop or speed up operations will still apply to the original transaction. For example, if a user creates Transaction A and later performs a drop operation on Transaction A using Transaction B, followed by a speed up operation on Transaction B using Transaction C, the speed up operation will still apply to Transaction A, not Transaction B.
If you drop a transaction from a Smart Contract Wallet, two RBF transactions will be triggered, one for the transaction from the Smart Contract Wallet, and the other for the transaction from the Delegate.

โ€‹
Cobo-defined categories

This field cobo_category is defined by Cobo to indicate the logical category or purpose of a transaction, helping users identify what type of operation the transaction belongs to.
Fee Station transactions, including their categories, can be retrieved only through Get Fee Station transaction information and List all Fee Station transactions.

โ€‹
Other categories