What is EIP-712, and why do agents sign typed data?
Typed fields a program can inspect before signing, a domain that pins the signature to one contract on one chain, and no gas until settlement. The standard underneath every Ophis order.
Last updated:
The short version: EIP-712 turns a signature from an opaque blob into a typed, inspectable statement: this token, this amount, this floor price, this expiry, this receiver, on this contract, on this chain. For an autonomous agent that is the whole game: policy can check every field before the signature exists, and the typed payload kept with its signature is the audit record.
What is EIP-712?
EIP-712 is Ethereum's standard for signing typed, structured data. Instead of an opaque hex blob, the signer sees named, typed fields: for a trade, the sell token, buy token, amounts, limit, expiry, and receiver. Wallets can render those fields to a human, and programs can validate them before signing.
What is the domain separator?
The domain separator binds a signature to one verifying contract on one chain (plus a name and version). A signature produced for one domain is invalid everywhere else, which is what prevents a signed order from being replayed against a different contract or a different chain. It is also why getting the domain right is not optional: sign against the wrong one and the real contract rejects the result.
Why does EIP-712 matter for trading agents?
Because the signed order IS the agent's capability. Typed fields mean the agent's policy layer can inspect exactly what is about to be authorized (which tokens, what amount, what floor price, until when, and to whom the proceeds go) before the signature exists. For the audit trail, retain the full typed payload with its signature: together they prove exactly what the agent authorized, though not when it was signed, so record a timestamp as ordinary log metadata alongside. The signature bytes alone cannot be decoded back into the order, so log the payload, not just the signature.
Why must agents resolve the signing domain per chain on Ophis?
On Optimism, Unichain, and Robinhood Chain, settlement uses Ophis's own GPv2Settlement contract at a non-canonical address. An EIP-712 signature binds to the verifying contract, so signing against CoW's canonical address yields a domain the deployed contract rejects. Resolve the per-chain settlement domain and orderbook host via the @ophis/sdk helpers or the MCP list_chains tool before signing, never hardcode them.
Is an EIP-712 signature the same as a transaction?
No. For ERC-20 orders it is an off-chain message: signing it costs no gas and moves nothing. The signed order goes to an orderbook, solvers compete to settle it in a batch, the winning solver pays the gas, and an order nobody can fill within its limit simply lapses with nothing spent. Selling native ETH is the exception: EthFlow places an on-chain transaction that escrows the ETH and pays normal network gas, and expiry alone does not release the escrow: a separate on-chain refund transaction, submitted by a refunder service or by the user, returns the ETH.
Go deeper
How the signed order travels from message to settlement: what is an intent-based DEX aggregator. Why this beats standing exchange authority for agents: API keys vs wallet signatures. The per-chain domains and addresses are in the machine-readable policy shipped with the Ophis agent skill, and the chain list is on supported chains.