Skip to main content
简而言之
Blockradar 签名 API 允许您使用钱包的私钥对纯文本消息、结构化数据(类型化数据)和原始交易进行加密签名。签名消息可以证明钱包所有权。签名外部构建的交易(例如 Solana 上的 Jupiter 兑换)无需暴露私钥,还可以选择将交易广播到链上。

前提条件

在使用签名 API 之前,请确保您已完成以下准备:
1

API 密钥

Blockradar 控制台 获取您的 API 密钥。导航至 Developers 生成密钥。
2

已创建钱包

Blockradar 控制台 创建主钱包。导航至 Wallets 并为目标区块链创建钱包。签名操作需要使用 walletId
3

环境选择

选择 Testnet(测试网,用于开发)或 Mainnet(主网,用于生产)。钱包按环境隔离。

工作原理

签名 API 生成加密签名,证明您控制着特定的钱包地址。签名输出可以被任何第三方验证,而无需访问您的私钥。

消息签名

签署纯文本消息以证明钱包所有权。支持所有区块链:EVM、Tron、Solana 和 Stellar。

类型化数据签名

按照 EIP-712 标准签署结构化数据。用于无 Gas 授权(EIP-2612 Permit)和委托转账(EIP-3009)。仅限 EVM。

交易签名

签署外部构建的原始交易。在 Jupiter 上构建兑换、通过 ethers.js 进行合约调用或 TronWeb 转账,然后发送未签名的交易进行签名,无需暴露私钥。

交易广播

一步完成原始交易的签名和广播。Blockradar 签名交易并通过可靠队列将其提交到链上,支持自动重试。

常见使用场景

  • 第三方服务注册:在接入 Iron、Circle 或其他 DeFi 协议等服务时,证明您拥有某个地址
  • 无 Gas 代币授权:签署 EIP-2612 Permit 消息以授权代币支出,无需链上交易
  • 委托转账:签署 EIP-3009 TransferWithAuthorization 消息以进行委托转账
  • 链下证明:创建与钱包地址关联的可验证意向或协议证明
  • 外部兑换执行:在 Solana 上构建 Jupiter 兑换,使用 Blockradar 签名,然后广播到链上
  • 自定义合约交互:在外部构建任意交易,由 Blockradar 签名和/或提交

主钱包与子地址

签名 API 可在两个层级使用:

主钱包

使用主钱包的密钥进行签名。适用于资金管理级别的操作和服务商集成。

子地址

使用特定子地址的密钥进行签名。当第三方要求使用充值地址进行签名时使用。

接口端点


消息签名

使用钱包的私钥签署纯文本消息。API 会签署消息、验证签名与钱包地址匹配,并返回签名和交易记录。

支持的区块链

Stellar 消息签名遵循 SEP-53,这是 Stellar 用于签署任意消息的标准。签名的载荷为 SHA-256("Stellar Signed Message:\n" + message),使用账户的 Ed25519 密钥签名,签名结果经过 base64 编码。要验证签名,请先应用相同的前缀和哈希,再用签名者的公钥核对签名。Stellar CLI 的 stellar message 命令以及 Stellar SDK 中的 SEP-53 辅助函数会为您完成这些操作。对未加前缀的消息进行的原始 Ed25519 签名将无法通过验证。

请求参数

消息签名示例

EVM 响应

Tron / Solana / Stellar 响应

对于 Tron、Solana 和 Stellar,signedTransaction 对象仅包含 signature 字段(没有 rsv 组件):

响应字段


类型化数据签名(仅限 EVM)

按照 EIP-712 标准签署结构化数据。用于无 Gas 授权、委托转账以及其他需要结构化签名的链上授权流程。
类型化数据签名仅适用于 EVM 兼容的区块链(Ethereum、Polygon、BSC、Base、Arbitrum、Optimism、Celo)。Tron、Solana 和 Stellar 不支持 EIP-712。

支持的标准

请求参数

EIP-2612 Permit 示例

类型化数据响应

Domain 对象字段

链 ID 验证
域对象中的 chainId 必须与钱包所在区块链网络的链 ID 匹配。如果不匹配,API 将返回 400 Chain ID mismatch 错误。

子地址签名

使用特定子地址(而非主钱包)签署消息、类型化数据、交易或进行广播。所有四种签名操作均可用于子地址:
子地址签名遵循与主钱包签名相同的请求和响应格式。唯一的区别是端点 URL 中包含了 addressId

Webhook 事件

签名操作会触发一个包含交易记录的 Webhook:

Webhook 载荷(消息或类型化数据签名)

Webhook 载荷(交易签名)

对于交易签名,signedTransaction 字段是字符串(而非对象)。格式取决于链。

Webhook 载荷(广播成功)

广播队列在链上确认交易后,您会收到此 Webhook。hash 字段更新为链上交易哈希,confirmed 变为 true

Webhook 载荷(广播失败)

如果广播在所有重试耗尽后永久失败,您会收到此 Webhook。statusFAILEDconfirmed 保持 false

交易签名

签署外部构建的原始未签名交易。您可以使用任何 SDK(ethers.js、TronWeb、Solana web3.js、Jupiter API)构建交易,然后将序列化的未签名交易发送给 Blockradar 进行签名和/或广播,无需构建或管理自己的基础设施或区块链节点。

支持的区块链和格式

请求参数

交易签名示例(Solana + Jupiter)

交易签名示例(EVM)

仅签名响应(EVM)

仅签名响应(Solana)

仅签名响应(Tron)

对于交易签名,signedTransaction字符串而非对象。这与消息签名不同,消息签名返回包含 rsv 等签名组件的对象。

各链 signedTransaction 格式

各链 hash 字段


交易广播

一步完成原始交易的签名广播。Blockradar 签名交易,然后通过可靠队列将其提交到链上,支持自动重试。API 立即返回 PENDING 状态。链上结果确认后,您会收到 signed.successsigned.failed Webhook。
广播需要钱包中有测试网/主网资金以支付 Gas 费用。交易必须有效且未过期(Solana blockhash 约在 90 秒后过期)。

Stellar Soroban 交易

签名端点除经典交易外,还接受 Stellar Soroban 交易——即 Stellar Asset Contract 转账或自定义合约调用。传入相同的 base64 交易信封 XDR 格式即可;Blockradar 会自动检测 Soroban 交易,并通过 Soroban RPC(而非 Horizon)提交。 需要遵循两条 Stellar 规则:
  1. 签名前先模拟并组装。 Soroban 交易在签名之前,必须先通过 Soroban RPC 进行模拟,并使用模拟结果(资源占用和费用)进行组装。提交未组装的交易会在链上失败。
  2. 序列号过期时重新构建。 如果提交时钱包的序列号已发生变化,API 会返回错误,提示交易已过期(tx_bad_seq),必须重新构建并重新签名。请使用当前序列号构建新交易后重试。
JavaScript
如果 Soroban 交易已提交到链上,但确认轮询超时,响应中会包含交易哈希以及消息 Soroban transaction submitted but not yet confirmed。请通过查询该哈希来核对交易结果——不要重新构建并重新提交,因为原始交易仍可能被确认,从而导致双重支付。

请求参数

与交易签名相同的参数:

广播示例

广播响应(Solana 示例,即时返回)

广播生命周期

交易会经历以下状态:
广播队列最多重试 10 次,间隔 5 分钟。对于 Solana,如果 blockhash 过期,重试不会有效。您需要使用新的 blockhash 重新构建交易。对于 Stellar,序列号过期(tx_bad_seq)同样需要重新构建并重新签名交易。

完整流程示例

以下是一个完整的实现示例,演示如何签署消息并将签名提交给第三方服务商:

错误响应

walletId 不存在或不属于您的业务。
addressId 不存在或未与指定钱包关联。
类型化数据签名(EIP-712)仅适用于 EVM 兼容链。Tron、Solana 和 Stellar 请使用消息签名。
类型化数据域对象中的 chainId 与钱包的区块链网络不匹配。
内部往返验证失败,表明系统出现错误。请联系技术支持。
transaction 字段不是有效的 Base64,或解码后的字节不是有效的 Solana VersionedTransaction。
transaction 字段不是有效的 JSON。EVM 和 Tron 交易必须是 JSON 字符串化的对象。
transaction 字段不是有效的 base64 编码 Stellar 交易信封 XDR。请使用 @stellar/stellar-sdk 构建交易,并传入 transaction.toXDR()

最佳实践

安全性

  • 使用 reference:使用唯一的 reference ID 追踪签名操作,用于审计跟踪和幂等性
  • 验证消息内容:签名前,确认消息内容与第三方服务预期的内容一致
  • 限制消息长度:消息上限为 4,096 个字符。保持消息简洁明确

集成

  • 无 Gas 费用:签名操作在链下进行,不需要原生代币余额
  • 即时响应:签名是同步生成的。签名本身不需要轮询或等待 Webhook
  • 监听 Webhook:使用 Webhook 维护所有签名事件的审计记录

类型化数据

  • 匹配链 ID:域中的 chainId 必须与钱包的网络匹配。测试使用沙盒(测试网)链 ID,生产使用正式(主网)链 ID
  • 检查合约verifyingContract 必须是将在链上验证签名的合约

交易签名

  • 使用正确的发送方构建交易:未签名交易必须使用钱包或子地址的公钥作为费用支付方(Solana)或发送方(EVM/Tron)。如果密钥不匹配,签名将失败。
  • Solana blockhash 过期很快:Solana blockhash 约在 60 到 90 秒内有效。构建交易后应尽快调用签名端点。如果使用广播,blockhash 过期后重试不会有效。
  • EVM nonce 管理:正确设置 nonce。如果 nonce 已被使用,广播将失败。在构建交易前从链上查询最新 nonce。
  • Tron 过期时间:Tron 交易在构建时设置 24 小时过期窗口,有充足的签名和广播时间。
  • Stellar 序列号和时间边界:使用钱包当前账户的序列号和有效的时间边界构建交易。过期的序列号(tx_bad_seq)或过期的时间边界会导致提交失败。请及时构建并签名,如果计划稍后广播,请将时间边界设置得宽松一些。
  • Stellar Soroban 交易:在提交签名之前先模拟并组装交易——未组装的 Soroban 交易会在链上失败。如果返回序列号过期错误,请使用新的序列号重新构建并重新提交。如果广播在等待确认时超时,请使用返回的交易哈希核对结果,而不要重新构建交易,以避免双重支付。
  • 仅签名 vs 广播:如果您希望自行或通过其他服务广播交易,使用 /signing/transaction。如果希望 Blockradar 处理提交并自动重试,使用 /signing/broadcast

API 参考

主钱包端点

子地址端点