Attach a Permit2 signature to a 0x quote correctly

A 0x Permit2 quote can require a typed-data signature before its transaction payload is complete. Sending the original calldata without the required suffix is a different operation from sending the signed quote.

The encoding boundary

The official Permit2 integration guide specifies signing the returned permit2.eip712 object, then appending a 32-byte unsigned big-endian signature length followed by the signature bytes to transaction.data. The length counts bytes, not hexadecimal characters.

Keep the original quote immutable. Store the completed transaction separately with the quote identifier, signer and account generation. Otherwise, a repeated button handler can append a second signature to already modified calldata.

Validate before and after signing

Inspect the typed-data domain, chain, token, amount, spender and validity conditions against the intended operation. Use the exact returned data for signing rather than reconstructing it from rounded screen values. If the account, chain or quote changes while the wallet is open, discard the resulting signature from the active flow.

A response that does not contain a Permit2 signing object needs its own documented branch. Do not manufacture a permit or attach a previous trade's signature. Native-asset and ERC-20 paths should be represented explicitly in the adapter.

After assembly, validate the transaction envelope and simulate the completed payload where supported. Approving the token for Permit2 and signing a particular Permit2 authorization are separate steps; one does not establish the other.

Useful byte-level checks

Test a suffix created once, a duplicated suffix, a character-count length and a signature from a superseded quote. Compare the original calldata prefix byte for byte. These checks isolate assembly errors from token allowance or liquidity failures without claiming that correct encoding alone guarantees settlement.