源头核验研究

Backpack API ED25519 与批量订单准备清单

4 分鐘

本文正文暫以英文原文展示,翻譯版本需完成來源複核後再發布。

已验证事实边界

1. Backpack's API documentation says endpoints that mutate state require signed requests using an ED25519 keypair unless documented otherwise. 2. Backpack signed requests include X-Timestamp, X-Window, X-API-Key and X-Signature headers, with the default window documented as 5000 milliseconds and a maximum of 60000 milliseconds. 3. Backpack documents instruction-prefixed signing strings for order execution and cancel workflows, including batch order execution. 4. Backpack's order query and cancel documentation says one of orderId or clientId should be specified and warns that orderId takes precedence when both are provided. 5. Backpack's API-key support page says API key creation is web-only and the Read Only button restricts a key to view-only access. 6. The safe readiness record separates key custody, request signing, time window, batch item identity, cancel evidence, accepted-but-not-executed states and non-secret reconciliation logs.

收起完整分析

决策矩阵

文章表格:可橫向滑動,或聚焦表格區域後使用方向鍵。

CheckWhat it meansPractical actionUnknown to keep explicit
Key scopeAPI keys can be created and permissioned before code sends orderscreate the minimum needed key and record whether it is read-onlywhether sub-account selection matches the intended trading account
Signing stringinstruction-specific canonical strings determine whether a request is acceptedunit-test the exact ordered parameters and header fieldswhether a library silently reorders or omits a parameter
Timestamp windowsigned requests are valid only within a bounded time windowmonitor local clock drift and reject stale submissions locallywhether network delay pushes a request outside the window
Batch mappingbatch order execution contains multiple item-level intentspersist each item, clientId and expected response separatelywhich item should be retried after a partial failure
Cancel evidenceorderId and clientId have precedence rules during query or canceluse one identifier per lookup and reconcile final statewhether an accepted cancel is already executed
Non-secret loggingdebuggability must not expose secretslog instruction, timestamp, window, clientId and result class but never private key or signature seedwhether support evidence requires additional private account context

来源地图

  • Backpack Exchange:Backpack Exchange API(backpack-api)
  • Backpack Exchange Support:Generate API keys for Backpack Exchange(backpack-api-keys)
  • Backpack Exchange Support:API and developer docs FAQs(backpack-api-faq)

控制说明

1. Key scope

这一项要求读者把公开来源翻译成操作规则。这里的含义是:API keys can be created and permissioned before code sends orders。可执行动作是:create the minimum needed key and record whether it is read-only。仍然未知的是:whether sub-account selection matches the intended trading account。因此本文不会把未知部分包装成收益承诺、牌照承诺、审批保证、安全保证、恢复保证、平台排名或价格暗示。

2. Signing string

这里的含义是:instruction-specific canonical strings determine whether a request is accepted。可执行动作是:unit-test the exact ordered parameters and header fields。仍然未知的是:whether a library silently reorders or omits a parameter。

操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。

3. Timestamp window

这里的含义是:signed requests are valid only within a bounded time window。可执行动作是:monitor local clock drift and reject stale submissions locally。仍然未知的是:whether network delay pushes a request outside the window。

操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。

4. Batch mapping

这里的含义是:batch order execution contains multiple item-level intents。可执行动作是:persist each item, clientId and expected response separately。仍然未知的是:which item should be retried after a partial failure。

操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。

5. Cancel evidence

这里的含义是:orderId and clientId have precedence rules during query or cancel。可执行动作是:use one identifier per lookup and reconcile final state。仍然未知的是:whether an accepted cancel is already executed。

操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。

6. Non-secret logging

这里的含义是:debuggability must not expose secrets。可执行动作是:log instruction, timestamp, window, clientId and result class but never private key or signature seed。仍然未知的是:whether support evidence requires additional private account context。

操作测试也必须很窄。这就是本文坚持以清单形式呈现的原因。

仍需明确的未知项

  • whether sub-account selection matches the intended trading account
  • whether a library silently reorders or omits a parameter
  • whether network delay pushes a request outside the window
  • which item should be retried after a partial failure
  • whether an accepted cancel is already executed
  • whether support evidence requires additional private account context

实用结论

Backpack Exchange API 集成应被视为签名订单控制流程,而不是复制 REST endpoint。Backpack 官方 API 文档说明,改变状态的调用需要 ED25519 签名、timestamp/window header,以及按 instruction 类型构造的签名字符串;文档还说明 order execution、batch order execution、order query 与 cancel 行为,包括 clientId 和 orderId 边界。实用结论是:生产自动化下单前,应先测试 key creation、timestamp window、canonical signing string、batch-item mapping、cancel acknowledgement、202 accepted state 与非秘密日志。 本文停在证据边界内,帮助读者决定下一步核验什么,而不是把公开文档改写成私人账户、钱包、API key、池子路径、稳定币余额、代币化资产或政策框架在任何未来条件下都能成功的承诺。

來源與證據

03
  1. Backpack ExchangeBackpack Exchange API · docs.backpack.exchange
  2. Backpack Exchange SupportGenerate API keys for Backpack Exchange · support.backpack.exchange
  3. Backpack Exchange SupportAPI and developer docs FAQs · support.backpack.exchange