Skip to main content
批量下发(Bulk Send)指一次性向多个收款地址批量转出加密货币,适用于工资发放、返佣奖励、合作方结算、电商/广告平台商家收益分发等场景。您只需提交包含多条批量下发条目(Bulk Send Item)的请求,Cobo 将为每个条目执行地址校验与合规验证(KYA),并根据执行模式(execution mode)决定是否继续链上转账。

前提条件

在开始前,请确保您已完成以下准备:
  • 确保 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 决定了以下两种情况下的处理方式:当任意条目未通过校验时,以及——仅针对 Strict 批次——当链上转账(归集)环节仅部分完成时(归集仅部分完成)。execution_mode 并不保证校验通过后所有条目都会成功,也不提供超出这两种情况的整单事务原子性。请始终以每个条目自身的 statusvalidation_status 为准,不要假设整批只有单一结果。

Strict vs Partial 的行为差异

execution_mode 仅涵盖上述两类失败路径。它不保证 Partial 批次中通过校验的条目一定全部链上成功,也不保证 Strict 批次在这两类情况之外具备整单事务原子性——请始终单独检查每个条目的 status 与 validation_status,并在决定是否补发前查看批次的 status(PartiallyCompleted 或 Failed)。

场景建议

  • 选择 Strict(强一致 / 要么全成要么全不成)
    • 合作方结算(同批次必须一致生效)
    • 供应商付款(财务侧要求整单一致)
    • 任何“这批不允许部分成功”的场景
  • 选择 Partial(高吞吐 / 允许部分失败,后续补发)——当单个条目的校验失败不应阻塞批次中其余有效条目时,推荐使用:
    • 全球员工工资发放(大批量,少数地址异常不应阻塞整体)
    • 返佣/奖励空投(地址质量参差)
    • 内容平台打赏金分发、电商/广告平台商家收益发放(可补发)
影响总结:
  • Strict 通过在任意条目校验失败时使整批失败并将所有条目标记为 NotExecuted,或在归集仅部分完成时使批次状态变为 Failed,来提升财务一致性;但会增加操作成本——一个地址问题会导致整单重新提交,而归集仅部分完成时,您需要先逐条检查条目的 status,再决定是否以及如何重新提交;
  • Partial 将校验失败隔离到受影响的条目,使批次其余部分得以继续,因而更利于规模化与自动化,但需要配套失败条目的补发流程。

1.3 批量下发的智能合约机制

在 Ethereum 上进行批量下发时,Cobo 使用智能合约执行批量转账;其他链则使用普通交易。无论哪种方式,Cobo 都会对每笔操作向您注册的 Callback Endpoint 发送 Callback 消息,以便您检查详情并批准或拒绝执行。具体机制也可能因您的团队配置而有所不同,如需了解详情,请联系 Cobo 支持团队。要了解如何设置和注册 Callback Endpoint,请参阅 Callback 介绍

Approve 操作(allowance 不足时触发)

当智能合约对某币种的 allowance 不足时,会先触发该币种合约的 approve 操作:
  • 调用函数approve
  • calldata 参数
    • _spender:批量转账合约地址(见下方表格)
    • _value:本次出金数额

转账操作

Approve 完成后,后续转账将调用批量转账合约的 sendToken 函数:
  • 调用函数sendToken
  • calldata 参数
    • token:币种合约地址(见下方表格)
    • recipients:收款地址列表
    • values:对应的转账数额列表

合约地址参考

由于各币种的合约地址固定,建议您在 callback 回调处理中校验对应的合约地址及函数调用信息,以确保回调能够正常完成。

2. Webhook 驱动自动化工作流(失败通知 + 查询条目 + 批量补发)

2.1 订阅 Bulk Send 状态更新事件

当 Bulk Send 的状态切换到以下任一状态时,Cobo 会触发 webhook event:
  • Completed
  • PartiallyCompleted
  • Failed
Webhook 通知数据结构如下(Bulk Send Notification):
其中 status 枚举为:
  • 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
(这里用伪路径示例表示)
每个 item 包含两个关键状态字段:
  • status(item 执行状态)
  • validation_status(地址/合规验证状态)
您提供的规则要求重点关注:
  • 若 status 为 FailedNotExecuted → 该条目失败
  • 若 validation_status 为 ValidationFailed → 该地址未通过 Cobo 的 KYA 验证
对这两类情况,都建议更换地址。

2.3 自动化重试:更换地址后批量补发

根据 execution_mode 的不同,补发策略不同:

A) 前一次是 Strict 模式

  • Strict 模式下:若任意条目未通过校验,批次会失败,且所有条目都会被标记为 NotExecuted
  • Strict 模式下:若链上转账(归集)环节仅部分完成,批次状态会变为 Failed
  • 对于校验失败的情况,补发(重新提交)时需要包含全部条目(不是只提交失败条目);对于归集仅部分完成的情况,请先逐条查看每个条目的 status,再决定是否以及如何重新提交,不要默认需要重提全部条目。
补发步骤(校验失败路径):
  1. 查询 items,定位 validation_statusValidationFailed 的条目。
  2. 更换这些条目的地址(或修正其它导致失败的参数)。
  3. 重新提交整单 Bulk Send(包含所有条目)。
对于归集仅部分完成的情况,请逐条查询每个条目的 status,据此判断需要补发哪些条目(如有),不要默认整批重提。

B) 前一次是 Partial 模式

  • Partial 模式下:已成功条目已转账完成
  • 因此补发时:只需要提交失败条目(减少重复转账风险)
补发步骤:
  1. 查询 items,筛选失败条目(status=Failed/NotExecuted 或 validation_status=ValidationFailed)
  2. 更换失败条目的地址
  3. 新建一个 Bulk Send,只提交这些失败条目

3. 参考实现:Webhook 处理 + 自动补发(示例)

下面示例展示一个典型工作流:
  1. 接收 webhook
  2. 若状态为 PartiallyCompleted / Failed,则查询 items
  3. 筛选失败条目并更换地址(地址更换逻辑由您业务系统完成)
  4. 创建新的 Bulk Send 任务并执行补发
说明:以下是示意代码(Node.js 风格), 您可按实际 SDK/签名方式改写。

4. 最佳实践

  • description 必填业务侧可追溯信息:例如 batch_id + user_id/employee_id + period,用于审计、对账、定位失败原因与换地址。
  • 严格区分 Strict/Partial 的补发策略
    • Strict:校验失败时,重提必须包含全量条目;归集仅部分完成时,请先逐条检查条目的 status,再决定如何重新提交
    • Partial:只补发失败条目(避免重复发放)
  • Webhook 幂等性:对 bulk_send_id + status + updated_timestamp 做幂等键,避免重复触发补发。
  • 失败分类处理
    • validation_status=ValidationFailed:优先换地址
    • status=Failed/NotExecuted:建议也换地址(按您给的规则),并保留失败原因用于风控/用户提示