What to inspect in a typed-data signature before a swap

A typed-data request can display structured fields, but readable formatting does not make the authorization harmless. Review what the signature permits and which contract will interpret it.

Check the domain first

EIP-712 defines domain information such as name, version, chain identifier and verifying contract. Where those fields are present, compare them with the expected protocol and network. A familiar displayed name alone is not identity verification.

Read the actual authorization

• Token and amount: which asset can move, and what is the maximum?
• Spender or operator: who receives authority?
• Recipient: where can value go, when the scheme binds it?
• Deadline or expiration: how long can it be exercised?
• Nonce: how does the scheme prevent reuse?

Not every scheme uses these exact fields. Missing or unfamiliar fields require understanding the protocol’s semantics, not guessing from a generic checklist. EIP-712 itself does not supply replay protection for every message.

Compare with your intention

A request to authenticate a session should not silently become permission to transfer a large token balance. A swap for one amount should not be accepted merely because a broader authorization is described as “verification.”

If the wallet cannot show enough detail to verify the request, pause. Use official protocol documentation or a supported review flow. Never let a support message tell you to ignore all fields because the signature costs no gas. Economic authority can be created without paying a fee at the moment of signing.