EIP-712 is de Ethereum-standaard voor het ondertekenen van getypeerde, gestructureerde data. In plaats van een gebruiker een onleesbare hexadecimale reeks te laten ondertekenen, toont de wallet de echte velden: de token, het bedrag, de ontvanger, de deadline. De handtekening kan daarna worden gecontroleerd door een smart contract of een backend. EIP-712 is de basis voor gasloze approvals, off-chain orderboeken, meta-transacties en off-chain stemmen.
Hoe EIP-712 werkt
- Types: het bericht wordt beschreven als een struct met benoemde, getypeerde velden, zoals
Order(address maker, uint256 amount, uint256 nonce, uint256 deadline). - Domain separator: een hash van de naam, versie, chain-ID en het controlerende contract van de applicatie. Die koppelt de handtekening aan één contract op één chain, zodat hij niet elders opnieuw te gebruiken is.
- Hashing: de struct wordt volgens vaste regels gehasht (type-hash, gecodeerde velden, geneste structs en arrays apart gehasht) en gecombineerd met de domain separator.
- Ondertekenen en controleren: de wallet ondertekent met
eth_signTypedData_v4; het contract herleidt de ondertekenaar met ECDSA, of roept EIP-1271 aan als de ondertekenaar een smart contract wallet is.
Waar EIP-712 wordt gebruikt
- Permit-handtekeningen (EIP-2612, Permit2): token-approvals zonder aparte transactie.
- Off-chain orders voor exchanges en NFT-marktplaatsen, die pas on-chain worden afgerekend bij een match.
- Meta-transacties en gasloze transacties, waarbij een relayer het gas betaalt.
- Off-chain governance-stemmen, inlogberichten en ondertekende verklaringen.
Veelgemaakte fouten
De meeste EIP-712-fouten komen voort uit kleine verschillen: een type-string die één teken afwijkt van het contract, dynamische types (strings, bytes, arrays) die worden gecodeerd in plaats van gehasht, een ontbrekende chain-ID, of geen nonce en deadline, waardoor een handtekening opnieuw te gebruiken is. Aan de kant van de gebruiker zijn handtekeningverzoeken een geliefd phishingmiddel, dus de weergave in de wallet telt; zie voorkomen van blind signing.
Hoe wij het implementeren
Wij definiëren de types één keer en genereren daaruit zowel de contractcode als de ondertekeningscode in de front-end, gebruiken beproefde bibliotheken (EIP712 en ECDSA van OpenZeppelin in Solidity, ethers of viem in TypeScript), voegen standaard nonces en deadlines toe, en testen dat handtekeningen uit de browser in het contract worden geaccepteerd, ook voor smart contract wallets.
Veelgestelde vragen
Wat is het verschil tussen EIP-712 en personal_sign?
personal_sign ondertekent een platte tekst die de gebruiker alleen als tekst kan lezen. EIP-712 ondertekent gestructureerde velden die wallets één voor één tonen en die contracts per veld kunnen controleren.
Werken EIP-712-handtekeningen op meerdere chains?
Niet als ze goed zijn opgebouwd: de chain-ID in de domain separator koppelt elke handtekening aan één chain.
Ondersteunen smart contract wallets EIP-712?
Ja, via EIP-1271: het contract controleert de handtekening door de wallet aan te roepen, die bepaalt of hij geldig is.
Wie is eigenaar van de code?
Het eigendom van de broncode wordt in het contract vastgelegd, en de code kan volledig van u zijn, inclusief documentatie en tests.
Onderdeel van ons werk aan handtekeningen en ondertekening en smart contract ontwikkeling.
EIP-712 laten implementeren
Vertel ons wat uw gebruikers moeten ondertekenen en waar dat wordt gecontroleerd. Wij ontwerpen de types, het domein en de controles, zodat handtekeningen duidelijk zijn en niet opnieuw te gebruiken.