EIP-712 integration: what breaks without typed signatures
Signing a raw hash looks reliable right up until the first incident. The wallet shows the user an unreadable string of bytes, the user confirms without looking — and signs an arbitrary contract call.
EIP-712 integration closes this gap: instead of a hash, the screen displays a structure with the domain name, the address of the verifying contract, and parameters broken down by field — the amount, the recipient's address, the expiration date.
The second class of failures is payload substitution.
If the signature is assembled from manually concatenated data without delimiters, two different operations produce the same digest, and an attacker rearranges the fields: a signed transfer to one address is executed as a transfer to another.
Typed signatures fix the type of each field and their serialization order, so the structure either matches entirely or the signature verification fails.
The third failure is transaction rejection at the signature verification stage. The contract recovers the signer's address via ecrecover, but the domain in the application and in the contract have diverged: a different chainId, a different name, a different verifier address.
The signature is formally valid, but verification returns someone else's address — the transaction reverts, and the user re-signs blindly. Separately, a mismatch of nonce and deadline surfaces: without an explicit expiration, a signed authorization can be replayed.
Practice shows: most such incidents are not a cryptography error but a desynchronization of the structure description between the frontend, the backend, and the contract. Below we break down how this is closed at the integration level.
What a typed signature delivers in product operation
When a user signs an operation "blind" — seeing a hash of random characters instead of the amount, address, and purpose — the share of rejected and erroneous confirmations grows.
A person either cancels the operation out of caution or confirms without looking and later disputes the result. A typed signature removes the root cause: the wallet displays structured fields — exactly what, to whom, and under what conditions is being signed.
The effect is measurable on three levels. On the confirmation screen, instead of an unreadable string there is a clear operation card, so the share of rejected operations drops: the user sees the meaning and confirms with confidence.
Inside the product, a single signature format is used by the web interface, service calls, and background tasks alike — there are no longer any discrepancies between them.
On the contract side, verification runs against a pre-defined structure rather than an arbitrary set of bytes, so field substitution or signature reuse in another context is cut off at the entry point.
A separate value is the reduction of user errors on operations with multiple parameters: a transfer, setting a limit, confirming a deal.
When every field is signed explicitly and the signature is bound to a specific contract and network, accidentally confirming someone else's operation or an operation from another environment is technically impossible. This is the class of failures that previously surfaced only after funds had already been debited.
For the team, it also means support predictability: a unified signature format means incident triage comes down to reconciling fields rather than reconstructing exactly what the user signed.
New contract methods are added by describing the structure, without rebuilding the verification logic on the client.
We break down how this is handled at the integration level: structure descriptions, the signature domain, contract-side verification, and compatibility with wallets that are already in use.
Integration approaches: comparison of methods
EIP-712 integration is rarely done "from scratch": more often there is a working contract, wallet, and frontend that cannot be stopped.
Therefore, the choice comes down to where to place the typed signature logic — inside the existing contract, as a separate layer on top of it, or moved out into a standalone service.
| Option | When it fits | Limitations of the approach |
|---|---|---|
| Manual scheme in the contract | One contract, few message types, signatures verified in one place | The domain and types are duplicated in the code and on the client — a mismatch is only caught in production; edits require redeployment |
| Wrapper over the contract | The contract is already in production and cannot be changed, compatibility with current calls is needed | The wrapper adds a delegation layer: gas costs grow, and some methods have to be proxied manually |
| Separate signing service | Multiple contracts, a single domain, signatures needed off-chain | The service becomes a point of failure and requires its own authorization; if the domain is misconfigured, the signature fails verification |
The key difference is where the definition of the domain and types lives. In the manual scheme it is spread between the contract and the client, in the wrapper it is tied to the original contract, in the service it is moved into one place and reused by all consumers.
The more contracts and clients there are, the more costly an error in this definition becomes: a mismatch in the name, version, or chainId makes the signature invalid without a clear error.
In practice, the choice is not binary. The wrapper is often put in place as a transitional solution to avoid touching production, and the signing service is introduced later — when a second or third contract appears and type duplication becomes noticeable. Let's break down how this is handled in each option and what exactly we check during acceptance.
How implementation works: stages of engineering work
Implementing EIP-712 starts not with code, but with analyzing what is being signed now.
If the project already has transaction or message signing, we first document: which fields go into the signature, where its validity is checked, who owns the keys, and what will happen when the format changes.
This is a signature audit — it shows where the current scheme allows data substitution or signature reuse.
Next, we design the type schema: we describe the message structure, the domain (name, version, chainId, verifier contract address), and the rules by which fields are linked to each other.
The type schema is a contract between the client and the contract: if it is described incompletely, verification on the contract side will accept a signature it should not have.
- Audit of the current signature: we collect all places where the signature is generated and verified, and document the risks of reuse and field substitution.
- Designing the type schema: we describe the domain and message structure, and align it with the contract logic and the client side.
- Setting up verification on the contract side: we implement signer recovery and domain matching so that the signature is accepted only for the required network and contract.
- Test scenarios: we cover a valid signature, an expired deadline, a foreign domain, reuse, and field substitution.
- Handover of the solution: we deliver the code, the type schema description, and instructions for adding new fields without breaking compatibility.
Separately, we check backward compatibility: if the project already has signatures in the old format, a decision is needed on whether to support them in parallel or migrate.
Test scenarios matter more than speed here — they lock in the contract's behavior before the solution goes to production.
Handover of the solution includes not only the code but also documentation on the type schema: how to add a field, how to update the domain, and what will happen to old signatures.
This way the client's team can develop the integration without us, while we stay in touch for complex cases.
What the client receives upon completion of the implementation
Implementing EIP-712 is not just code in the contract, but also a set of artifacts that the team will continue to work with without us. Below is exactly what we hand over.
- Type schema description. A formalized list of the
EIP712Domain,Mail,Orderstructures and nested types with fields, ordering, and hashing rules — a single source of truth for the contract and the client. - Signature verification module. A ready-made component that recovers the signer's address from
v, r, sand compares it against the expected one, including verification of thechainIdand the address of the verifier contract. - Procedure for issuing new types. A step-by-step process: how to add a structure, update the domain, agree on a version, and avoid breaking already-issued signatures.
- Integration documentation. Client-side call examples, test signature vectors, and a breakdown of common errors — so the team can integrate without us.
- Test suite. Coverage of scenarios: valid signature, expired deadline, wrong
chainId, type substitution — regressions are caught before release. - Deployment scheme. The order of deploying the verifier contract, domain migration, and rollback to the previous version of the types.
- Acceptance checklist. Formal criteria: the signature passes on the test network, the rollback is reproducible, and the documentation is up to date.
Each artifact addresses its own class of risks: the type schema — desynchronization between the client and the contract, the verification module — signature forgery, the procedure — breakage when adding fields. Describe your task — we will get back to you with an estimate and a plan for your stack.
Case study: how we reduced the share of rejected operations
What it was like before the changes
The project is a non-custodial service with client-side operation signatures. The signature was assembled "by hand": the hash was formed by concatenating fields, whose order and types the frontend and the contract interpreted in their own way.
As long as releases went out synchronously, there were no discrepancies. As soon as the backend and the contract started rolling out independently, rejections poured in: invalid signature on operations that were valid from the user's point of view.
The share of rejected operations held at around 7% of all signed actions. Investigating each incident took an average of 3-4 hours: it was necessary to reproduce the field order, verify the types, and find exactly where the serialization diverged. Support received 40-60 requests per week phrased as "I signed it — it didn't go through."
What was changed
EIP-712 was introduced: every signed message got a strict typed structure — a domain with name, version, chainId, and verifyingContract, plus a field schema with explicit types.
The hash is now computed deterministically according to the standard, rather than assembled by hand on both sides.
The domain was tied to the contract address and the network — a signature assembled for one environment physically does not pass in another. The type schema was moved into a shared artifact that the frontend, the backend, and the contract tests all import.
Wallets show the user a readable representation of the fields instead of an incomprehensible hex string — some of the rejections disappeared already at this step.
What it became
The share of rejected operations dropped to 0.4% — the remainder comes from expired deadlines and insufficient funds, that is, from legitimate reasons rather than format desynchronization.
Incident investigation time shrank from hours to 15-20 minutes: the discrepancy is now visible from a mismatch in the domain or field type, rather than being hunted down by brute force.
Support requests on the topic of signatures decreased by roughly six times. A separate effect is predictability when adding new operation types: the schema is extended in one place, and both sides get a consistent change without manual synchronization.
We worked this out on the OpenZeppelin stack — the library provides ready-made primitives for the domain and hashing, which eliminates a whole class of errors already at the code-writing stage.
How a typed signature differs from a regular one
A regular signature works with a raw hash: the contract receives 32 bytes and must reconstruct on its own what exactly the user signed.
The problem is that this cannot be extracted from the hash — the data is irreversibly collapsed, and verification boils down to comparing numbers.
If an attacker substitutes the call context, the signature remains valid: it confirms the fact of consent, but says nothing about its content.
EIP-712 adds a structured description: a domain (contract name, version, network, verifier address) and a typed message schema. Before signing, the wallet assembles a deterministic representation from this and hashes it according to fixed rules.
The output is the same cryptographic signature, but bound to a specific contract, network, and set of fields. A signature issued for one protocol will not pass verification in another.
The difference between the approaches shows up in three places. First — data readability: the user sees in the wallet not a hex string, but understandable fields with types and values, and consciously confirms the action.
Second — protection against reuse: the domain and nonce cut off transferring the signature to another contract or repeating the same operation.
Third — parsing on the contract side: instead of manually assembling bytes, the engineer describes the structure once, and verification proceeds according to it.
For integration, this means that the type schema must be fixed before the audit and not changed after release: any renaming of a field or change of order breaks already issued signatures.
We move the description into a separate module, synchronize it with the frontend, and cover it with tests for address recovery — then a discrepancy between the client and the contract is caught before rollout, not in production.
Common technical doubts before starting
Before starting integration, the same questions almost always come up: will we break what already works, what will current users experience, and how much code will have to be rewritten. Below is a breakdown of each.
Is this compatible with contracts already in production?
Yes, if you add signature verification as a separate method rather than rewriting the existing ones. Old calls continue to work under the previous scheme, and the new signature path is enabled in parallel.
The contract receives a domain and structure type, while the verification logic remains isolated — rollback amounts to disabling a single method without state migration.
What will existing users experience?
For those who don't use the new scenario, nothing changes — their transactions follow the same path. Those who switch to signatures stop paying for extra confirmations: one signature instead of several transactions.
It's important to design clear error messages, otherwise the user won't understand why the signature was rejected.
How large is the scope of rework?
The main work is to describe the data structure and domain, synchronize them between the contract and the client, add verification on the contract side, and add tests for signature forgery. If the interface is already split into layers, the changes are local. The more the logic is mixed with checks, the more you'll have to untangle.
What are the migration risks and how do we close them?
The main risk is domain desynchronization between the contract and the client: the signature stops passing. We close it by pinning the domain in tests and verifying at the build stage. The second risk is signature reuse, which is eliminated by a nonce. The third is a mismatch of field types, caught by boundary-value tests.
Describe your current contracts and scenario — we'll come back with an estimate of the rework scope and a migration plan.
Let's discuss your task and come back with a plan
To come back with an estimate for the EIP-712 implementation, we need to understand your current signing scheme: where exactly the signature is formed, what goes into the signed data, and how the contract verifies it.
Describe the task in free form — the type of action being signed, the chain you're working with, and what's already implemented. That's enough to estimate the scope of work and propose a plan.
What's worth specifying so the estimate is accurate:
- the current signing scheme:
eth_sign,personal_sign,eth_signTypedData, or a custom hash assembly; - which parameters participate in the signature and how they're passed to the contract;
- the domain structure:
name,version,chainId,verifyingContract— whether they're set or still need to be introduced; - where the signature is verified: on-chain, in a relayer, or on the backend;
- the supported wallets and clients you've already tested with;
- whether multi-chain or contract upgrades are planned;
- timeline constraints and what's critical not to break in the current flow.
Based on this data, we'll come back with a work plan: migration stages, a rollout order without downtime, a rollback scheme, and checkpoints. If part of the scheme isn't defined yet, we'll propose options and justify the choice.
Describe the task — we'll come back with an estimate and a plan.