批量下发(Bulk Send)指一次性向多个收款地址批量转出加密货币,适用于工资发放、返佣奖励、合作方结算、电商/广告平台商家收益分发等场景。您只需提交包含多条批量下发条目(Bulk Send Item)的请求,Cobo 将为每个条目执行地址校验与合规验证(KYA),并根据执行模式(execution mode)决定是否继续链上转账。Documentation Index
Fetch the complete documentation index at: https://cobo.com/payments/llms.txt
Use this file to discover all available pages before exploring further.
前提条件
在开始前,请确保您已完成以下准备:- 确保 source_account(资金来源账户)有足够余额。
- (推荐)配置 Webhook Endpoint,用于接收 Bulk Send 的状态更新并驱动自动化重试流程。
1. 如何做批量下发
1.1 创建 Bulk Send
创建 Bulk Send 时,您需要提供:- source_account:资金来源账户 ID(例如 M1001)
- execution_mode:执行模式(Strict / Partial)
- payout_params:批量下发条目明细,每条包含:
- token_id
- receiving_address
- amount
- description(建议填写业务侧可追溯信息,如工资单号/用户ID/发放批次)
1.2 execution_mode(执行模式)如何选择
Cobo 在收到 Bulk Send 请求后,会先对 请求中所有地址进行校验与验证(包含格式校验与 KYA 等合规验证)。execution_mode 决定了当任意地址存在问题时,Cobo 是否继续对其他正常地址执行链上转账。Strict vs Partial 的行为差异
| execution_mode | 校验阶段发现任意地址有问题( KYA 不通过) | 链上转账结果 | 您需要做什么 |
|---|---|---|---|
| Strict | 只要 任意一条 条目地址有问题 | 不会发起任何链上转账(整单不执行) | 更换有问题的地址后,重新提交整单 Bulk Send(需要包含全部条目) |
| Partial | 允许存在部分地址有问题 | 会对 所有校验通过的地址 执行链上转账;有问题的地址 不会转 | 查询失败条目,更换地址后,仅补发失败条目(只提交需要补发的 item) |
场景建议
- 选择 Strict(强一致 / 要么全成要么全不成)
- 合作方结算(同批次必须一致生效)
- 供应商付款(财务侧要求整单一致)
- 任何“这批不允许部分成功”的场景
- 选择 Partial(高吞吐 / 允许部分失败,后续补发)
- 全球员工工资发放(大批量,少数地址异常不应阻塞整体)
- 返佣/奖励空投(地址质量参差)
- 内容平台打赏金分发、电商/广告平台商家收益发放(可补发)
- Strict 更利于财务一致性,但会增加“因个别地址问题导致整批重提”的操作成本;
- Partial 更利于规模化与自动化,但需要配套失败补发流程。
1.3 批量下发的智能合约机制
在进行批量下发时,Cobo 使用智能合约执行批量转账。了解该机制有助于您在 callback 回调处理中正确校验合约调用信息。Approve 操作(allowance 不足时触发)
当智能合约对某币种的 allowance 不足时,会先触发该币种合约的approve 操作:
- 调用函数:
approve - calldata 参数:
_spender:批量转账合约地址(见下方表格)_value:本次出金数额
转账操作
Approve 完成后,后续转账将调用批量转账合约的sendToken 函数:
- 调用函数:
sendToken - calldata 参数:
token:币种合约地址(见下方表格)recipients:收款地址列表values:对应的转账数额列表
合约地址参考
由于各币种的合约地址固定,建议您在 callback 回调处理中校验对应的合约地址及函数调用信息,以确保回调能够正常完成。| 链 | Token ID | 币种合约地址 | 批量转账合约地址 |
|---|---|---|---|
| Ethereum | ETH_USDT | 0xdac17f958d2ee523a2206206994597c13d831ec7 | 0x3d963e23a9229d2acd25e9ffc358be1a35460ecc |
| Ethereum | ETH_USDC | 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 | 0x3d963e23a9229d2acd25e9ffc358be1a35460ecc |
| Arbitrum | ARBITRUM_USDT | 0xfd086bc7cd5c481dcc9c85ebe478a1c0b69fcbb9 | 0x3d963e23a9229d2acd25e9ffc358be1a35460ecc |
| Arbitrum | ARBITRUM_USDCOIN | 0xaf88d065e77c8cc2239327c5edb3a432268e5831 | 0x3d963e23a9229d2acd25e9ffc358be1a35460ecc |
| Base | BASE_USDT | 0xfde4c96c8593536e31f229ea8f37b2ada2699bb2 | 0x3d963e23a9229d2acd25e9ffc358be1a35460ecc |
| Base | BASE_USDC | 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 | 0x3d963e23a9229d2acd25e9ffc358be1a35460ecc |
| Polygon | MATIC_USDT | 0xc2132d05d31c914a87c6611c10748aeb04b58e8f | 0x3d963e23a9229d2acd25e9ffc358be1a35460ecc |
| Polygon | MATIC_USDC2 | 0x3c499c542cef5e3811e1192ce70d8cc03d5c3359 | 0x3d963e23a9229d2acd25e9ffc358be1a35460ecc |
| BNB Smart Chain | BSC_USDT | 0x55d398326f99059ff775485246999027b3197955 | 0x3d963e23a9229d2acd25e9ffc358be1a35460ecc |
| BNB Smart Chain | BSC_USDC | 0x8ac76a51cc950d9822d68b83fe1ad97b32cd580d | 0x3d963e23a9229d2acd25e9ffc358be1a35460ecc |
| TRON | TRON_USDT | TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t | TEmDa9FY9YBCg1HPL41RUnJorXRRV3rX7A |
2. Webhook 驱动自动化工作流(失败通知 + 查询条目 + 批量补发)
2.1 订阅 Bulk Send 状态更新事件
当 Bulk Send 的状态切换到以下任一状态时,Cobo 会触发 webhook event:- Completed
- PartiallyCompleted
- Failed
- Pending
- Validating
- Transfering
- Completed
- PartiallyCompleted
- Failed
- 仅当状态进入 PartiallyCompleted / Failed 时启动补发流程;Validating / Transfering 阶段建议只做展示与监控。
- 对 webhook 进行签名校验与幂等处理(同一事件可能重放)。
2.2 收到失败通知后:查询 Bulk Send items 明细
当收到 PartiallyCompleted 或 Failed 的 webhook 后,使用 List bulk send items 接口查询该 bulk send 的每条 item 状态:- Path 参数:bulk_send_id
- Operation:list_bulk_send_items
- Summary:List bulk send items
- status(item 执行状态)
- validation_status(地址/合规验证状态)
- 若 status 为 Failed 或 NotExecuted → 该条目失败
- 若 validation_status 为 ValidationFailed → 该地址未通过 Cobo 的 KYA 验证
2.3 自动化重试:更换地址后批量补发
根据 execution_mode 的不同,补发策略不同:A) 前一次是 Strict 模式
- Strict 模式下:只要有一个地址有问题,整单不会发生任何链上转账
- 因此补发(重新提交)时:需要包含全部条目(不是只提交失败条目)
- 查询 items,定位 ValidationFailed 或 Failed/NotExecuted 的条目
- 更换这些条目的地址(或修正其它导致失败的参数)
- 重新提交整单 Bulk Send(包含所有条目)
B) 前一次是 Partial 模式
- Partial 模式下:已成功条目已转账完成
- 因此补发时:只需要提交失败条目(减少重复转账风险)
- 查询 items,筛选失败条目(status=Failed/NotExecuted 或 validation_status=ValidationFailed)
- 更换失败条目的地址
- 新建一个 Bulk Send,只提交这些失败条目
3. 参考实现:Webhook 处理 + 自动补发(示例)
下面示例展示一个典型工作流:- 接收 webhook
- 若状态为 PartiallyCompleted / Failed,则查询 items
- 筛选失败条目并更换地址(地址更换逻辑由您业务系统完成)
- 创建新的 Bulk Send 任务并执行补发
4. 最佳实践
- description 必填业务侧可追溯信息:例如 batch_id + user_id/employee_id + period,用于审计、对账、定位失败原因与换地址。
- 严格区分 Strict/Partial 的补发策略:
- Strict:重提必须包含全量条目
- Partial:只补发失败条目(避免重复发放)
- Webhook 幂等性:对 bulk_send_id + status + updated_timestamp 做幂等键,避免重复触发补发。
- 失败分类处理:
- validation_status=ValidationFailed:优先换地址
- status=Failed/NotExecuted:建议也换地址(按您给的规则),并保留失败原因用于风控/用户提示
