CoboGlobal · rcsh1 · Jun 19, 2026
diff --git a/docs.json b/docs.json
@@ -53,6 +53,7 @@
                 "group": "Transactions",
                 "pages": [
                   "v2/guides/transactions/sources-and-destinations",
+                  "v2/guides/transactions/transfer-routing",
                   "v2/guides/transactions/estimate-fees",
                   {
                     "group": "Transaction statuses",
@@ -63,6 +64,7 @@
                     ]
                   },
                   "v2/guides/transactions/manage-transactions",
+                  "v2/guides/transactions/rbf-transaction-lifecycle",
                   {
                     "group": "Smart contract call samples",
                     "pages": [

diff --git a/v2/guides/overview/upgrade-guide.mdx b/v2/guides/overview/upgrade-guide.mdx
@@ -70,6 +70,10 @@ The following table lists the API operations needed for common wallet operations
 | Sign a message             | Not supported                                                | [Sign message](/v2/api-references/transactions/sign-message) |
 | Query a transaction        | <ul><li>**[Custodial Wallets]** [Transaction history](/v1/api-references/custody-wallet/transaction_history)</li><li>**[MPC Wallets]** [Get Transactions List](/v1/api-references/mpc-wallet/mpc_list_transactions)</li></ul> | <ul><li>[List all transactions](/v2/api-references/transactions/list-all-transactions)</li><li>[Get transaction information](/v2/api-references/transactions/get-transaction-information)</li></ul>|
 
+<Warning>
+WaaS 2.0 list endpoints, such as [List all transactions](/v2/api-references/transactions/list-all-transactions), return results in pages. By default each page returns 10 records, and the maximum page size is 50, set with the `limit` parameter. This differs from WaaS 1.0, where a single response could return all results. A single WaaS 2.0 page therefore omits later results. To retrieve every record, iterate through all pages using the cursor parameters `before` and `after`.
+</Warning>
+
 ## Upgrade to 2.0
 
 This section introduces the detailed steps to upgrade from WaaS 1.0 to 2.0.

diff --git a/v2/guides/transactions/estimate-fees.mdx b/v2/guides/transactions/estimate-fees.mdx
@@ -174,6 +174,10 @@ The logic for estimating RBF transaction fees is similar to that for normal tran
 - Fixed: Increase the fee amount.
 - Filecoin: It is recommended to increase both gas premium and gas fee cap by 25%.
 
+## Fees on Layer 2 chains
+
+On Layer 2 (L2) chains such as Arbitrum, network fees can change rapidly. If fees rise sharply after you submit a transaction, the transaction can remain in the `PendingSignature` or `Broadcasting` status longer than expected. To unblock such a transaction, use the Replace-By-Fee (RBF) speed-up operation to rebroadcast it with a higher fee. For how RBF works end to end, see [RBF (Replace-By-Fee) transaction lifecycle](/v2/guides/transactions/rbf-transaction-lifecycle). To raise the fee, use the [Speed up transaction](/v2/api-references/transactions/speed-up-transaction) operation.
+
 ## How Cobo estimate the fees
 
 Below is how Cobo calculates the fees for each model:

diff --git a/v2/guides/transactions/manage-transactions.mdx b/v2/guides/transactions/manage-transactions.mdx
@@ -37,6 +37,8 @@ Replace-By-Fee (RBF) is a feature that allows you to replace an unconfirmed tran
 
 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](/v2/guides/transactions/rbf-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.

diff --git a/v2/guides/transactions/rbf-transaction-lifecycle.mdx b/v2/guides/transactions/rbf-transaction-lifecycle.mdx
@@ -0,0 +1,43 @@
+---
+title: "RBF (Replace-By-Fee) transaction lifecycle"
+lang: "en"
+description: "Understand how Replace-By-Fee (RBF) replaces an unconfirmed transaction, how the original transaction's status changes, and the events you receive."
+---
+
+import WaasSkillReminder from '/snippets/waas_skill_reminder.mdx';
+
+<WaasSkillReminder />
+
+## Overview
+
+Replace-By-Fee (RBF) replaces an unconfirmed, already-broadcast transaction with a new version. This guide describes the full lifecycle of an RBF replacement: the replacement operations you can perform, how the original transaction's status changes, and the events you receive.
+
+For the step-by-step operations, see [Manage transactions](/v2/guides/transactions/manage-transactions). For the fee rules that apply to RBF transactions, see [Estimate transaction fees](/v2/guides/transactions/estimate-fees#replace-by-fee-rbf-transaction-fee).
+
+## Replacement operations
+
+WaaS 2.0 supports the following RBF operations:
+
+- **Speed up**: Replaces the original transaction with a higher-fee version so that it confirms faster. Use the [Speed up transaction](/v2/api-references/transactions/speed-up-transaction) operation.
+- **Drop**: Replaces the original transaction with a version that effectively cancels it. Use the [Drop transaction](/v2/api-references/transactions/drop-transaction) operation.
+
+Both operations apply only when the original transaction is in the `Broadcasting` status. They do not apply to transactions on the following chains: VET, TRON, TVET, SOL, and TON.
+
+## Original transaction status after replacement
+
+When a replacement transaction takes effect, the original transaction moves to the `Failed` status with the sub-status `ReplacedByNewTransaction`. For the complete list of statuses and sub-statuses, see [Transaction statuses and sub-statuses](/v2/guides/transactions/status).
+
+## Chained replacements
+
+Any subsequent drop or speed-up operations continue to apply to the original transaction. For example, if you create Transaction A, perform a drop operation on Transaction A using Transaction B, and then perform a speed-up operation on Transaction B using Transaction C, the speed-up operation still applies to Transaction A, not Transaction B.
+
+## Events
+
+RBF status changes are surfaced through the WaaS 2.0 transaction webhook events. To learn which events you receive, see [Webhook event types](/v2/guides/webhooks-callbacks/webhook-event-type).
+
+## Related guides
+
+- [Manage transactions](/v2/guides/transactions/manage-transactions)
+- [Estimate transaction fees](/v2/guides/transactions/estimate-fees)
+- [Transaction statuses and sub-statuses](/v2/guides/transactions/status)
+- [Transaction sources and destinations](/v2/guides/transactions/sources-and-destinations)
diff --git a/v2/guides/transactions/sources-and-destinations.mdx b/v2/guides/transactions/sources-and-destinations.mdx
@@ -16,6 +16,8 @@ Refer to the following table for the source and destination types corresponding
 
 <Note>If you transfer tokens between two wallets created on Cobo Portal, two transactions will be recorded: a deposit into the destination wallet and a withdrawal from the source wallet.</Note>
 
+To control whether a transfer is routed internally through Cobo Loop or on-chain, see [Transfer routing](/v2/guides/transactions/transfer-routing).
+
 | Transaction type                                   | Source Type                                                                                     | Destination Type              |
 |----------------------------------------------------|-------------------------------------------------------------------------------------------------|--------------------------|
 | Deposit - [Cobo Loop](https://manuals.cobo.com/en/portal/custodial-wallets/cobo-loop) transfers       | DepositFromLoop                                                                                | DepositToAddress         |

diff --git a/v2/guides/transactions/status.mdx b/v2/guides/transactions/status.mdx
@@ -274,6 +274,20 @@ The table below provides an overview of transaction statuses and sub-statuses re
   </tr>
 </table>
 
+## Status details
+
+<Note>
+The `PendingAuthorization` status aggregates both manual approval steps and internal automated checks. Manual steps include `PendingApproverCheck`, `PendingSpenderCheck`, and `PendingDoubleCheck`. Automated checks include `PendingRiskControlCheck` and `PendingCoboCheck`. A transaction in `PendingAuthorization` does not necessarily require a person to act, because it may be undergoing automated risk-control or compliance checks.
+</Note>
+
+<Warning>
+After a transaction is approved, it enters the `PendingSignature` status and must be signed by the MPC signer group within a limited signing window. If signing does not complete within this window, the transaction automatically fails and moves to the `Failed` status with the sub-status `FailedSignerTimeout`. To find out why a transaction failed, check the `sub_status` field returned by [List all transactions](/v2/api-references/transactions/list-all-transactions) or [Get transaction information](/v2/api-references/transactions/get-transaction-information). If you encounter `FailedSignerTimeout`, resend the transaction to try again.
+</Warning>
+
+<Note>
+A transaction in the `Confirming` status with the sub-status `PendingBlockConfirmations` is waiting for the required number of block confirmations on its chain. This is a normal part of processing and does not mean the transaction is stuck. The required number of confirmations and the expected confirmation time vary by chain.
+</Note>
+
 ## Available actions
 
 You can perform the following actions based on the transaction status:
@@ -286,4 +300,6 @@ You can perform the following actions based on the transaction status:
 - Resend a transaction if its status is `Failed`.
 - Speed up or drop a transaction if its status is `Broadcasting`.
 
+For details on how a replaced transaction's status changes, see [RBF (Replace-By-Fee) transaction lifecycle](/v2/guides/transactions/rbf-transaction-lifecycle).
+
 For more details, refer to [Manage transactions](/v2/guides/transactions/manage-transactions).
diff --git a/v2/guides/transactions/transaction-process-mpc.mdx b/v2/guides/transactions/transaction-process-mpc.mdx
@@ -33,4 +33,8 @@ The following diagram illustrates how a withdrawal is processed. Colors are used
 <img src="/v2/images/guides/mpc-withdrawal-en.png" className="diagram" alt="Withdrawal process" />
 
 - If a withdrawal is rejected or unsuccessful, the tokens will be returned to your wallet, and your balance will remain unchanged.
-- If your withdrawal amount is smaller than the minimum withdrawal threshold, the withdrawal request will receive an error. You can call the [Get token information](/v2/api-references/wallets/get-token-information) operation to retrieve the minimum withdrawal amount for each token type.
+- If your withdrawal amount is smaller than the minimum withdrawal threshold, the withdrawal request will receive an error. You can call the [Get token information](/v2/api-references/wallets/get-token-information) operation to retrieve the minimum withdrawal amount for each token type.
+
+<Warning>
+After a withdrawal is approved, it enters the `PendingSignature` status and must be signed by the MPC signer group within a limited signing window. If signing does not complete in time, the transaction automatically fails and moves to the `Failed` status with the sub-status `FailedSignerTimeout`. To confirm the reason, check the `sub_status` field returned by [Get transaction information](/v2/api-references/transactions/get-transaction-information), then resend the transaction to try again.
+</Warning>
diff --git a/v2/guides/transactions/transfer-routing.mdx b/v2/guides/transactions/transfer-routing.mdx
@@ -0,0 +1,38 @@
+---
+title: "Transfer routing"
+lang: "en"
+description: "Understand how token transfers are routed internally through Cobo Loop or externally on-chain, and how to control routing with request parameters."
+---
+
+import WaasSkillReminder from '/snippets/waas_skill_reminder.mdx';
+
+<WaasSkillReminder />
+
+## Overview
+
+Every token transfer is routed either internally or externally:
+
+- **Internal routing** settles off-chain between accounts on Cobo Portal through the Cobo Loop transfer network, when the destination supports it.
+- **External routing** broadcasts the transaction on the blockchain.
+
+## Control routing with request parameters
+
+The [Transfer token](/v2/api-references/transactions/transfer-token) operation provides two boolean parameters to control routing: `force_internal` and `force_external`.
+
+| Setting | Routing behavior |
+|---------|------------------|
+| `force_internal` = `true` | Forces internal routing through Cobo Loop (off-chain). |
+| `force_external` = `true` | Forces external on-chain routing. |
+| Both `false` (default) | Routes through Cobo Loop if the destination supports it; otherwise routes on-chain. |
+| Both `true` | The request is rejected. |
+
+Some destinations do not support these parameters.
+
+## Effect on the resulting transaction
+
+Internal routing produces an off-chain Cobo Loop transfer. External routing produces an on-chain transaction.
+
+## Related guides
+
+- [Transaction sources and destinations](/v2/guides/transactions/sources-and-destinations)
+- [Cobo Loop](https://manuals.cobo.com/en/portal/custodial-wallets/cobo-loop)
diff --git a/v2_cn/guides/overview/upgrade-guide.mdx b/v2_cn/guides/overview/upgrade-guide.mdx
@@ -72,6 +72,10 @@ WaaS 2.0 相较于 WaaS 1.0 进行了重大升级，面向支付、代币化、
 | 签名消息                   | 不支持                                                        | [签名消息](/v2/api-references/transactions/sign-message) |
 | 查询交易                   | <ul><li>**[全托管钱包]** [交易历史](/v1/api-references/custody-wallet/transaction_history)</li><li>**[MPC 钱包]** [获取交易列表](/v1/api-references/mpc-wallet/mpc_list_transactions)</li></ul> | <ul><li>[列出所有交易](/v2/api-references/transactions/list-all-transactions)</li><li>[获取交易信息](/v2/api-references/transactions/get-transaction-information)</li></ul>|
 
+<Warning>
+WaaS 2.0 的列表类接口（例如 [List all transactions](/v2/api-references/transactions/list-all-transactions)）会分页返回结果。默认情况下每页返回 10 条记录，最大每页为 50 条，通过 `limit` 参数设置。这与 WaaS 1.0 不同：在 1.0 中单次响应可返回全部结果。因此 WaaS 2.0 的单页会遗漏后续结果。如需获取全部记录，请使用游标参数 `before` 和 `after` 遍历所有页。
+</Warning>
+
 ## 升级步骤
 
 本节介绍从 WaaS 1.0 升级到 2.0 的详细步骤。

diff --git a/v2_cn/guides/transactions/estimate-fees.mdx b/v2_cn/guides/transactions/estimate-fees.mdx
@@ -176,6 +176,10 @@ Replace-By-Fee (RBF) 是一种允许您用新版本替换未确认交易的功
 - 固定模型：增加固定金额。
 - Filecoin 模型：Gas Premium 和 Gas Fee Cap 建议提升 25%。
 
+## Layer 2 链上的费用
+
+在 Arbitrum 等 Layer 2（L2）链上，网络费用可能快速变化。如果您提交交易后费用大幅上涨，交易可能会比预期更长时间地停留在 `PendingSignature` 或 `Broadcasting` 状态。如需解除此类交易的阻塞，可以使用 Replace-By-Fee（RBF）加速操作，以更高的费用重新广播交易。有关 RBF 的完整流程，请参阅 [RBF (Replace-By-Fee) transaction lifecycle](/v2_cn/guides/transactions/rbf-transaction-lifecycle)。如需提高费用，请使用 [Speed up transaction](/v2/api-references/transactions/speed-up-transaction) 操作。
+
 ## Cobo 如何估算费用
 
 下列表格展示了不同费用模型下的费用估算方法：

diff --git a/v2_cn/guides/transactions/manage-transactions.mdx b/v2_cn/guides/transactions/manage-transactions.mdx
@@ -36,6 +36,8 @@ Replace-By-Fee (RBF) 是一种允许您用新版本替换未确认交易的功
 
 RBF 的两个最常见用例是加速和放弃交易。
 
+有关被替换交易的状态变化及其触发的事件，请参阅 [RBF (Replace-By-Fee) transaction lifecycle](/v2_cn/guides/transactions/rbf-transaction-lifecycle)。
+
 ### 加速交易
 
 加速交易利用 RBF 用更高费用的版本替换原始交易，鼓励矿工优先处理以更快确认。

diff --git a/v2_cn/guides/transactions/rbf-transaction-lifecycle.mdx b/v2_cn/guides/transactions/rbf-transaction-lifecycle.mdx
@@ -0,0 +1,43 @@
+---
+title: "RBF (Replace-By-Fee) 交易生命周期"
+lang: "zh-hans"
+description: "了解 Replace-By-Fee (RBF) 如何替换未确认交易、原交易的状态如何变化，以及您会收到哪些事件。"
+---
+
+import WaasSkillReminder from '/snippets/waas_skill_reminder_cn.mdx';
+
+<WaasSkillReminder />
+
+## 概述
+
+Replace-By-Fee (RBF) 使用新版本替换已广播但尚未确认的交易。本指南介绍 RBF 替换的完整生命周期：您可以执行的替换操作、原交易的状态如何变化，以及您会收到哪些事件。
+
+有关分步操作，请参阅 [Manage transactions](/v2_cn/guides/transactions/manage-transactions)。有关适用于 RBF 交易的费用规则，请参阅 [Estimate transaction fees](/v2_cn/guides/transactions/estimate-fees#replace-by-fee-rbf-transaction-fee)。
+
+## 替换操作
+
+WaaS 2.0 支持以下 RBF 操作：
+
+- **Speed up**：用更高费用的版本替换原交易，使其更快确认。请使用 [Speed up transaction](/v2/api-references/transactions/speed-up-transaction) 操作。
+- **Drop**：用可有效取消原交易的版本替换原交易。请使用 [Drop transaction](/v2/api-references/transactions/drop-transaction) 操作。
+
+这两种操作仅在原交易处于 `Broadcasting` 状态时适用。它们不适用于以下链上的交易：VET、TRON、TVET、SOL 和 TON。
+
+## 替换后原交易的状态
+
+当替换交易生效时，原交易将转入 `Failed` 状态，子状态为 `ReplacedByNewTransaction`。有关状态和子状态的完整列表，请参阅 [Transaction statuses and sub-statuses](/v2_cn/guides/transactions/status)。
+
+## 链式替换
+
+任何后续的放弃或加速操作都将继续应用于原交易。例如，如果您创建交易 A，使用交易 B 对交易 A 执行放弃操作，然后使用交易 C 对交易 B 执行加速操作，则该加速操作仍将应用于交易 A，而不是交易 B。
+
+## 事件
+
+RBF 的状态变化通过 WaaS 2.0 交易 Webhook 事件呈现。如需了解您会收到哪些事件，请参阅 [Webhook event types](/v2_cn/guides/webhooks-callbacks/webhook-event-type)。
+
+## 相关指南
+
+- [Manage transactions](/v2_cn/guides/transactions/manage-transactions)
+- [Estimate transaction fees](/v2_cn/guides/transactions/estimate-fees)
+- [Transaction statuses and sub-statuses](/v2_cn/guides/transactions/status)
+- [Transaction sources and destinations](/v2_cn/guides/transactions/sources-and-destinations)
diff --git a/v2_cn/guides/transactions/sources-and-destinations.mdx b/v2_cn/guides/transactions/sources-and-destinations.mdx
@@ -16,6 +16,8 @@ import WaasSkillReminder from '/snippets/waas_skill_reminder_cn.mdx';
 
 <Note>如果您在 Cobo Portal 上的两个钱包之间转移代币，将记录两笔交易：一笔存入目的地钱包，一笔从来源钱包提取。</Note>
 
+如需控制转账是通过 Cobo Loop 内部路由还是链上路由，请参阅 [Transfer routing](/v2_cn/guides/transactions/transfer-routing)。
+
 | 交易类型                                   | 交易来源类型                                                                                     | 交易目的地类型            |
 |----------------------------------------------------|-------------------------------------------------------------------------------------------------|--------------------------|
 | Deposit - [Cobo Loop](https://manuals.cobo.com/cn/portal/custodial-wallets/cobo-loop) 转账       | DepositFromLoop                                                                                | DepositToAddress         |