Validate typed-data domains before asking for a signature

Validate a typed-data request as an authorization document. Checking that it is valid JSON says nothing about which chain, contract, token or amount the user is being asked to authorize.

Compare the domain with execution context

EIP-712 defines domain fields including name, version, chainId and verifyingContract, with fields chosen by the protocol. Compare each expected field with the reviewed protocol deployment. In particular, the chain must match the active trade and the verifying contract must belong to the intended signing path.

Do not insert missing fields into a provider's payload simply to satisfy a generic schema. Altering the domain changes the signed digest. A protocol that omits a field needs its own validated schema, not a silently modified request.

The message needs equal attention

Inspect the primary type, owner or swapper, token addresses, maximum spend, output constraints, recipient, deadline and nonce according to that protocol. Preserve large integers as exact values. A familiar domain name does not make an unexpected spending amount acceptable.

The specification does not itself provide replay protection. Nonces and deadlines belong to the application protocol, so a generic EIP-712 validator cannot certify that an order is single-use.

Bind the signature to the reviewed snapshot

Compute or retain an identifier for the exact payload shown for approval. If a quote refresh changes its terms while the wallet is open, do not attach the resulting signature to the replacement quote. Store the signature only with the original payload and its account context.

Useful negative fixtures change one field at a time: chainId, verifyingContract, input amount, recipient and deadline. The application should reject a context mismatch before opening the wallet. This verifies the surrounding authorization boundary without claiming that the client has audited the settlement contract.