Binance 签名端点 Percent-Encoding 迁移清单

决策矩阵

来源地图

• Binance Developer Documentation：Spot Block Matching Change Log（binance-spot-block-matching-changelog）
• Binance Developer Documentation：General REST API Information（binance-spot-rest-api）
• Binance Developer Documentation：Rebate Change Log（binance-rebate-changelog）

控制说明

1. Affected signing path

这一项要求读者先把公开来源翻译成操作规则。这里的含义是：the risk sits in payload construction before cryptographic signing。可执行动作是：inventory every internal client that builds signed Binance requests。仍然未知的是：undocumented third-party wrappers that reserialize payloads。因此本文不会把未知部分包装成收益承诺、牌照承诺、审批保证、恢复保证、结算保证、可用性保证、价格暗示或平台排名。

2. Fixture coverage

这里的含义是：ASCII-only examples can miss encoding defects。可执行动作是：test ASCII, non-ASCII, query-only and body-plus-query payloads。仍然未知的是：symbols or parameters not present in test fixtures。

操作测试也必须很窄。这就是本节保留边界的原因。

3. Timing controls

这里的含义是：timestamp and recvWindow still decide whether signed requests are accepted in time。可执行动作是：avoid changing time windows while changing encoding。仍然未知的是：clock skew during deployment。

操作测试也必须很窄。这就是本节保留边界的原因。

4. Product scope

这里的含义是：Binance product-family changelogs may surface the same signing requirement in different places。可执行动作是：verify every product family used by the bot before production rollout。仍然未知的是：private endpoints not covered by public examples。

操作测试也必须很窄。这就是本节保留边界的原因。

5. Failure evidence

这里的含义是：INVALID_SIGNATURE can come from multiple signing defects。可执行动作是：log non-secret payload-shape hashes and error labels, not secrets。仍然未知的是：whether support can distinguish encoding failure from key misuse。

操作测试也必须很窄。这就是本节保留边界的原因。

6. Rollback

这里的含义是：a signing migration should be reversible until all endpoints pass。可执行动作是：keep old and new signer paths behind a controlled release flag。仍然未知的是：whether historical orders need replay or only future requests change。

操作测试也必须很窄。这就是本节保留边界的原因。

7. Commercial boundary

这里的含义是：API compatibility does not prove better execution, lower fees or account eligibility。可执行动作是：report it as operational readiness only。仍然未知的是：future exchange-side changes after the documented date。

操作测试也必须很窄。这就是本节保留边界的原因。

仍需明确的未知项

• undocumented third-party wrappers that reserialize payloads
• symbols or parameters not present in test fixtures
• clock skew during deployment
• private endpoints not covered by public examples
• whether support can distinguish encoding failure from key misuse
• whether historical orders need replay or only future requests change
• future exchange-side changes after the documented date

实用结论

Binance 开发者文档已把 percent-encoding 纳入受影响 REST 示例的签名 payload 控制面，Spot Block Matching changelog 也提示：未按顺序处理的请求会在指定生效时间后以 INVALID_SIGNATURE 拒绝。实用结论是：用 ASCII 与 non-ASCII payload fixture 测试签名库，保持 timestamp 与 recvWindow 处理不被误改，并在轮换生产 key 或改变机器人下单流程前逐一验证受影响产品线。 本文停在证据边界内，帮助读者决定下一步核验什么，而不是把公开文档改写成私人账户、钱包、回调、政策框架、结算路径或流动性头寸在任何未来条件下都能成功的承诺。