Skip to main content

交易结果封装

两个 REST 端点都返回 TransactionResult 对象。

解析的交易

原生转账

nativeTransfers 包含以 lamports 计的 SOL 动作。 原生转账包括系统程序 transfer 和 create_account 指令,以及合成 SPL 令牌 close_account SOL 转账。

令牌转账

tokenTransfers 包含 SPL 令牌和 Token-2022 动作。 令牌转账包括 transfer、transfer_checked、transfer_checked_with_fee、burn、burn_checked、mint_to 和 mint_to_checked。不包括零金额的令牌转账。

摘要

summary 在其出现的所有地方都有一个统一的结构——交易和每个识别的指令上:
parsedData 是摘要背后的结构化负载(如果可用)——例如具有协议、类型、金额、铸币以及沿路径的任何内部交换的交换元数据。其结构因摘要类型和协议而异。 parsedData 中的兑换金额(例如 in_amount、actual_out_amount,以及每个内部兑换的 input_amount 和 output_amount)是交易场所报告的金额。这些金额并非用户钱包实际发送或接收的金额,因此未计入 Token-2022 转账费用或在兑换之外应用的其他扣减项。要获取用户收到的确切金额,请比较交易前后用户的代币账户余额。 当前的摘要类型包括:
  • add_liquidity
  • create_account
  • create_token_account
  • remove_liquidity
  • swap
  • transfer

已解析的指令

解码后的指令账户具有以下结构:
解码后的 args 键和账户名称采用 snake_case(source_account、in_amount),与程序 IDL 中发布的格式一致。整数参数通常以字符串形式返回("1500000000000"),因为 u64 值无法用 JavaScript 数字表示。

已解码的错误

当交易因自定义程序错误而失败,并且 API 可以识别导致失败的程序错误时,decodedError 可包含:

完整示例

Jupiter SOL 到 PUMP 兑换的完整交易解析结果,其中展示了封装结构、转账、摘要和每条指令: