Sign authenticated swap API requests from exact bytes

HMAC authentication signs a sequence of bytes, not the abstract meaning of a JSON object. Two requests that look equivalent in a debugger can produce different signatures because their path, encoding or body differs.

RFC 2104 defines keyed message authentication. A particular API supplies the message-construction rules. Follow those rules exactly; do not invent a universal canonicalization scheme and assume every swap provider accepts it.

Serialize once

Construct the final query string and body string, then use the same values for signing and transmission. If one function signs a JSON object and another serializes it differently, whitespace or key-order changes can invalidate the request. Query escaping and parameter order deserve the same attention.

As a concrete example, OKX authentication documentation combines timestamp, uppercase method, request path and applicable body before HMAC-SHA256 and Base64 encoding. Its examples include the query in the request path. This is service authentication, not the wallet's blockchain signature.

Keep time and retry behavior consistent

Use the same timestamp in the signed message and header. On a retry, generate a fresh authentication envelope when required, while preserving the application operation's identity. Keep host clock synchronization observable; a clock issue can resemble a bad key.

For diagnosis, compare a digest of the serialized request and safe metadata such as method, path shape and timestamp. Do not log the secret, passphrase or complete authentication headers.

Use fixed synthetic credentials in a deterministic fixture to test the signing pipeline. Include spaces, encoded query characters, an empty body and an explicitly serialized JSON body. A live production key is unnecessary for those checks.