diff --git a/docs.json b/docs.json index d76c3113..3f4d8538 100644 --- 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 index 85df20ed..984af2a6 100644 --- 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 | | | + +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`. + + ## 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 index 8a266956..b58dada1 100644 --- 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 index e9792f44..c86a3e1e 100644 --- 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 new file mode 100644 index 00000000..8df9ebd5 --- /dev/null +++ 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'; + + + +## 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 index cc7b853b..33e65299 100644 --- 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 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. +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 index 7a32ac7a..363ab4e0 100644 --- 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 +## Status details + + +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. + + + +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. + + + +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. + + ## 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). \ No newline at end of file diff --git a/v2/guides/transactions/transaction-process-mpc.mdx b/v2/guides/transactions/transaction-process-mpc.mdx index 0d6346a1..3041a8c8 100644 --- 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 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. \ No newline at end of file +- 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. + + +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. + \ No newline at end of file diff --git a/v2/guides/transactions/transfer-routing.mdx b/v2/guides/transactions/transfer-routing.mdx new file mode 100644 index 00000000..95f897d4 --- /dev/null +++ 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'; + + + +## 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 index d729e1f6..c84ab8cd 100644 --- 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) | | 查询交易 | | | + +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` 遍历所有页。 + + ## 升级步骤 本节介绍从 WaaS 1.0 升级到 2.0 的详细步骤。 diff --git a/v2_cn/guides/transactions/estimate-fees.mdx b/v2_cn/guides/transactions/estimate-fees.mdx index cc04d624..8571f0e9 100644 --- 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 index 8582a3a9..7ceb13f5 100644 --- 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 new file mode 100644 index 00000000..98fc9c20 --- /dev/null +++ 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'; + + + +## 概述 + +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 index 03379cfd..29fd3ddf 100644 --- 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'; 如果您在 Cobo Portal 上的两个钱包之间转移代币，将记录两笔交易：一笔存入目的地钱包，一笔从来源钱包提取。 +如需控制转账是通过 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 | diff --git a/v2_cn/guides/transactions/status.mdx b/v2_cn/guides/transactions/status.mdx index b201f1be..50217d03 100644 --- a/v2_cn/guides/transactions/status.mdx +++ b/v2_cn/guides/transactions/status.mdx @@ -274,6 +274,20 @@ WaaS 2.0 定义了各种交易状态和子状态，以反映不同的处理阶 +## 状态详情 + + +`PendingAuthorization` 状态同时涵盖人工审批步骤和内部自动检查。人工步骤包括 `PendingApproverCheck`、`PendingSpenderCheck` 和 `PendingDoubleCheck`。自动检查包括 `PendingRiskControlCheck` 和 `PendingCoboCheck`。处于 `PendingAuthorization` 状态并不一定需要人工操作，因为交易可能正在进行自动风控或合规检查。 + + + +交易经审批通过后会进入 `PendingSignature` 状态，并且必须在有限的签名时间窗口内由 MPC 签名人组完成签名。如果未能在时间窗口内完成签名，交易将自动失败并转入 `Failed` 状态，子状态为 `FailedSignerTimeout`。如需确认交易失败原因，请查看 [List all transactions](/v2/api-references/transactions/list-all-transactions) 或 [Get transaction information](/v2/api-references/transactions/get-transaction-information) 返回的 `sub_status` 字段。如果遇到 `FailedSignerTimeout`，请重新发起该交易。 + + + +处于 `Confirming` 状态且子状态为 `PendingBlockConfirmations` 的交易，正在等待其所在链所需数量的区块确认。这是正常处理过程的一部分，并不表示交易卡住。所需的确认数量和预计确认时间因链而异。 + + ## 可用操作 您可以根据交易状态执行以下操作： @@ -286,4 +300,6 @@ WaaS 2.0 定义了各种交易状态和子状态，以反映不同的处理阶 - 如果交易状态是 `Failed`，您可以重发交易。 - 如果交易状态是 `Broadcasting`，您可以加速或放弃交易。 +有关被替换交易的状态如何变化的详细信息，请参阅 [RBF (Replace-By-Fee) transaction lifecycle](/v2_cn/guides/transactions/rbf-transaction-lifecycle)。 + 有关详细信息，请参阅[管理交易](/v2_cn/guides/transactions/manage-transactions)。 \ No newline at end of file diff --git a/v2_cn/guides/transactions/transaction-process-mpc.mdx b/v2_cn/guides/transactions/transaction-process-mpc.mdx index 9ab338c8..1cad22ea 100644 --- a/v2_cn/guides/transactions/transaction-process-mpc.mdx +++ b/v2_cn/guides/transactions/transaction-process-mpc.mdx @@ -34,4 +34,8 @@ import WaasSkillReminder from '/snippets/waas_skill_reminder_cn.mdx'; 提币流程 - 如果提币被拒绝或不成功，代币将返回到您的钱包，您的余额将保持不变。 -- 如果您的提币金额小于最低提币门槛，提币请求将收到错误。您可以调用 [获取代币信息](/v2/api-references/wallets/get-token-information) 操作来检索每种代币类型的最低提币金额。 \ No newline at end of file +- 如果您的提币金额小于最低提币门槛，提币请求将收到错误。您可以调用 [获取代币信息](/v2/api-references/wallets/get-token-information) 操作来检索每种代币类型的最低提币金额。 + + +提币交易经审批通过后会进入 `PendingSignature` 状态，并且必须在有限的签名时间窗口内由 MPC 签名人组完成签名。如果未能在时间窗口内完成签名，交易将自动失败并转入 `Failed` 状态，子状态为 `FailedSignerTimeout`。您可以通过 [Get transaction information](/v2/api-references/transactions/get-transaction-information) 返回的 `sub_status` 字段确认失败原因，然后重新发起该交易。 + \ No newline at end of file diff --git a/v2_cn/guides/transactions/transfer-routing.mdx b/v2_cn/guides/transactions/transfer-routing.mdx new file mode 100644 index 00000000..d5c4a184 --- /dev/null +++ b/v2_cn/guides/transactions/transfer-routing.mdx @@ -0,0 +1,38 @@ +--- +title: "转账路由" +lang: "zh-hans" +description: "了解代币转账如何通过 Cobo Loop 内部路由或链上外部路由，以及如何使用请求参数控制路由。" +--- + +import WaasSkillReminder from '/snippets/waas_skill_reminder_cn.mdx'; + + + +## 概述 + +每笔代币转账都会通过内部或外部路由： + +- **内部路由**：当目的地支持时，通过 Cobo Loop 转账网络在 Cobo Portal 账户之间以链下方式结算。 +- **外部路由**：将交易广播到区块链上。 + +## 使用请求参数控制路由 + +[Transfer token](/v2/api-references/transactions/transfer-token) 操作提供两个布尔参数来控制路由：`force_internal` 和 `force_external`。 + +| 设置 | 路由行为 | +|---------|------------------| +| `force_internal` = `true` | 强制通过 Cobo Loop 进行内部路由（链下）。 | +| `force_external` = `true` | 强制进行链上外部路由。 | +| 两者均为 `false`（默认） | 如果目的地支持，则通过 Cobo Loop 路由；否则进行链上路由。 | +| 两者均为 `true` | 请求将被拒绝。 | + +部分目的地不支持这些参数。 + +## 对生成交易的影响 + +内部路由生成链下的 Cobo Loop 转账。外部路由生成链上交易。 + +## 相关指南 + +- [Transaction sources and destinations](/v2_cn/guides/transactions/sources-and-destinations) +- [Cobo Loop](https://manuals.cobo.com/en/portal/custodial-wallets/cobo-loop)