---
title: "EIP-712-Signaturen: Domains, Digests und sichere Prüfung"
description: "EIP-712 macht strukturierte Ethereum-Nachrichten deterministisch und darstellbar; sicheres Signieren verlangt dennoch die genaue Prüfung von Domain, Typ, Wert, Nonce, Frist, Ausführung und Signaturrichtlinie."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# EIP-712-Signaturen: Domains, Digests und sichere Prüfung
> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.
## Direkte Antwort
EIP-712 standardisiert, wie Ethereum-Anwendungen Signaturen über typisierte strukturierte Daten beschreiben, hashen und anfordern. Eine Anfrage enthält `types`, `primaryType`, `domain` und `message`; ihr Digest lautet `keccak256("\x19\x01" || domainSeparator || hashStruct(message))`. Die Codierung wird dadurch deterministisch, und eine geeignete Wallet kann Felder verständlicher als einen undurchsichtigen Hash anzeigen.
Der Standard macht eine Nachricht aber **nicht** wahr, harmlos, widerrufbar oder wiederholungssicher. Die Anwendung muss die Befugnis an Chain und Prüfer binden, jedes Feld eindeutig definieren, Nonces und Zeitgrenzen durchsetzen, den richtigen Signatär prüfen und die Ausführung beschränken. Eine gültige Signatur belegt nur die Zustimmung zu einem exakten Digest unter einer Prüfregel, nicht Identität, informierte Absicht oder Sicherheit von Website und Vertrag.
## Funktionsweise
### 1. Aktion und Prüfpfad bestimmen
Klären Sie, ob die Anfrage Anmeldung, Auftrag, Abstimmung, Token-Allowance, Übertragung, Relay-Aufruf oder etwas anderes autorisiert. Suchen Sie den Code, der Digest und Verbrauch der Signatur bestimmt. Bei einem extern kontrollierten Konto wird meist eine Adresse aus einer ECDSA-Signatur wiederhergestellt; bei einem Vertragskonto kann ERC-1271 `isValidSignature(hash, signature)` mit dem Erfolgswert `0x1626ba7e` nötig sein.
### 2. Domain festlegen
Prüfen Sie den exakten Typ `EIP712Domain` und seine Werte. Standardfelder sind `name`, `version`, `chainId`, `verifyingContract` und `salt`; nur vorhandene Felder werden gehasht. Bestätigen Sie aktive Chain, bereitgestellten Code und vorgesehenen Prüfer unabhängig. Ein vertrauter Name, Symbol, Proxy-Label oder eine Prüfsummenadresse genügt nicht. ERC-5267 `eip712Domain()` kann die Domain offenlegen, ist aber optional; Proxy- und Upgrade-Verhalten bleibt zu prüfen.
### 3. Typgraph rekonstruieren
Beginnen Sie bei `primaryType`, erhalten Sie die Mitgliederreihenfolge und sammeln Sie referenzierte Structs rekursiv. `encodeType` hängt deren Definitionen nach Typnamen sortiert an. EIP-712 unterstützt Ganzzahlen fester Breite, `address`, `bool`, `bytes1` bis `bytes32`, dynamische `bytes` und `string`, Arrays und Structs. Die Aliase `uint` und `int`, Festkommatypen und zyklische Werte sind nicht definiert.
### 4. Jeden Wert und jede Einheit decodieren
Ordnen Sie jeden Wert seinem deklarierten Typ und seiner Anwendungsbedeutung zu. Prüfen Sie vollständige Adressen, Rohinteger, Vorzeichen, Array-Reihenfolge, Empfänger, Spender, Assets, Beträge, Gebühren, Grenzen, Ziele, Calldata-Hashes und lesbare Strings. Dynamische `bytes` und `string` erscheinen in `encodeData` als Keccak-256-Hash ihres Inhalts; Arrays hashen verkettete Elementcodierungen, verschachtelte Structs ihr eigenes `hashStruct`.
### 5. Digest unabhängig neu berechnen
Berechnen Sie `typeHash = keccak256(encodeType(primaryType))` und anschließend `hashStruct(message) = keccak256(typeHash || encodeData(message))`. Berechnen Sie ebenso den Domain-Separator und verbinden Sie ihn mit den ERC-191-Versionsbytes `0x19 0x01`. Vergleichen Sie Frontend, Signaturbibliothek, Prüfervertrag und eine unabhängige Implementierung; gleich aussehendes JSON beweist keine gleiche typisierte Codierung.
### 6. Replay-, Zeit- und Ausführungsschutz prüfen
EIP-712 enthält selbst keinen Replay-Schutz. Der Prüfer muss den vorgesehenen Signatär prüfen, die richtige Nonce verbrauchen oder sperren, `deadline` oder Gültigkeitsfenster erzwingen, alle sicherheitskritischen Parameter binden und bei früher Einreichung durch Relayer oder Frontrunner dasselbe beabsichtigte Ergebnis erzeugen. Domain-Trennung schützt nur zwischen tatsächlich codierten Domains; fehlende oder falsche Felder können Wiederverwendung zwischen Verträgen oder Chains erlauben.
### 7. Minimal signieren und Ergebnis abstimmen
Lehnen Sie verborgene Felder, unerklärte Typen, unbegrenzte Werte, ferne Fristen, unbekannte Verträge, abweichende Chain-IDs, Blind-Signing-Anzeigen oder unvollständigen Ausführungskontext ab. Bewahren Sie exaktes JSON und Digest auf, nutzen Sie möglichst ein zweckgebundenes Konto und prüfen Sie Transaktion, Receipt, Events, Salden, Allowances, Nonces, Auftragsstatus und Finalität. Das Trennen einer Website widerruft weder eine nutzbare Signatur noch bereits erteilte Befugnis.
## Rechenbeispiele
### Beispiel 1: Typ- und Digest-Aufbau
Für `Order(address maker,address token,uint256 amount,uint256 nonce,uint256 deadline)` ist `typeHash` der Keccak-256-Hash dieser exakten Zeichenfolge einschließlich Feldreihenfolge. Der Nachrichtenhash ist `keccak256(typeHash || maker || token || amount || nonce || deadline)`; jedes codierte Mitglied belegt 32 Bytes. Der finale Digest ergänzt `0x1901`, Domain-Separator und Nachrichtenhash. Eine Änderung von `amount` von `250000000` auf `250000001` ändert den Digest und macht die alte Signatur ungültig.
### Beispiel 2: Einheiten und Frist
`250 USDC` eines Tokens mit sechs Dezimalstellen werden als Rohwert `250000000`, nicht `250`, codiert. Bei Zeitstempel `1727000000` und Frist `1727000900` beträgt das Fenster `900 seconds = 15 minutes`. Dezimalanzeige und lokale Uhr helfen nur; der Prüfer nutzt Rohinteger und seine gewählte On-Chain-Zeitregel.
### Beispiel 3: Replay-Kontrolle
Ein Auftrag trägt Nonce `41` und maximal `5 ETH`. Nachdem der Prüfer Nonce 41 als verbraucht markiert, muss eine zweite Einreichung trotz kryptografisch gültiger Signatur scheitern. Verbraucht der Vertrag die Nonce nicht und ist die Ausführung nicht idempotent, kann dieselbe Signatur weitere `5 ETH` autorisieren; der Domain-Separator allein verhindert das nicht.
### Beispiel 4: Gültigkeit einer Vertrags-Wallet
Eine 2-von-3-Vertrags-Wallet genehmigt einen Digest mit A, B und C als Signatären. A und B können ERC-1271 heute `0x1626ba7e` zurückgeben lassen. Ersetzt ein Modul-Upgrade B durch D, können dieselben Signaturbytes ungültig werden: ERC-1271 darf von aktuellem Zustand, Richtlinie, Zeit und externen Aufrufen abhängen; Adresswiederherstellung allein entscheidet keine Vertragskontogültigkeit.
## Risiken
- Falsche oder fehlende `chainId`
- Gefälschter oder unerwarteter `verifyingContract`
- Irreführender Domain-`name` oder falsche `version`
- Nach Upgrade geänderte Proxy-Implementierung oder Domain
- Falscher `primaryType` oder ähnlich benannter Schattentyp
- Abweichende Mitglieder-, Abhängigkeits- oder Encoder-Reihenfolge
- Gekürzte, ersetzte oder irreführend beschriftete Adresse
- Fehler bei Token-Dezimalstellen oder vorzeichenbehafteten Ganzzahlen
- Verdeckter Array-Eintrag, verschachteltes Struct oder `bytes`-Payload
- Unbegrenzter Betrag, weiter Umfang oder angreifergesteuerter Empfänger
- Fehlende, alte, geteilte oder falsch verbrauchte Nonce
- Fehlende, ferne, übergelaufene oder mehrdeutige Frist
- Replay zwischen Chains, Verträgen, Konten oder Aktionen
- Zurückhalten, Zensur, Frontrunning oder Umleitung durch Relayer
- Signaturmalleabilität oder zu tolerante ECDSA-Wiederherstellung
- Änderung von ERC-1271-Signatär, Modul, Schwelle, Zustand oder Code
- Wallet-Darstellung, Blind Signing oder nicht unterstützter Typ
- Frontend-JSON weicht vom Digest des Prüfers ab
- Widerruf oder Stornierung verliert Ordnungsrennen
- Signaturdialog mit Receipt, Zustandsänderung oder Finalität verwechselt
## Häufige Missverständnisse
### Irrtum 1: EIP-712-Signaturen sind Transaktionen
Es sind Off-Chain signierte Nachrichten. Ein Relayer kann sie später an einen Vertrag übermitteln; die resultierende Transaktion kann Gas verbrauchen und Zustand ändern, ohne vom Signatär gesendet zu werden.
### Irrtum 2: Strukturierte Anzeige bedeutet Sicherheit
Typisierte Felder verbessern die Prüfbarkeit, doch bösartige Schemata, Werte, Verträge, Labels, versteckte Verschachtelung und unvollständige Wallet-Darstellung können täuschen.
### Irrtum 3: Der Domain-Separator verhindert jedes Replay
Er trennt nur die codierte Domain. Replay innerhalb derselben Domain braucht Nonce, Frist, Stornierung, Füllstandsführung oder Idempotenz; ausgelassene Domain-Felder schaffen keine Grenze.
### Irrtum 4: Die erwartete Adresse beweist die Autorisierung
Wiederherstellung belegt eine EOA-Signatur über den Digest, nicht die Anwendungssemantik. Vertragskonten erfordern ihre ERC-1271-Richtlinie statt gewöhnlicher Adresswiederherstellung.
### Irrtum 5: Seite schließen oder Wallet trennen storniert die Signatur
Eine kopierte Signatur bleibt nutzbar, bis Nonce, Frist, Stornierung, Zustand oder Richtlinie des Prüfers sie ungültig macht. Entscheidend ist der relevante On-Chain-Zustand.
## Verwandte Themen
- [Chain-ID](/de/crypto/chain-id/)
- [ERC-2612-Permit: Nonce und Frist](/de/crypto/erc2612-permit-nonce-deadline/)
- [Risiko von Permit2-Signaturen](/de/crypto/permit2-signature-risk/)
- [Wallet-Autorisierung](/de/crypto/wallet-approval/)
- [Wallet-Signatur](/de/crypto/wallet-signature/)
## Quellen
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (abgerufen: 2026-08-19)
- [ERC-191: Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191) - Ethereum Improvement Proposals (abgerufen: 2026-08-19)
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals (abgerufen: 2026-08-19)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (abgerufen: 2026-08-19)
- [ERC-5267: Retrieval of EIP-712 domain](https://eips.ethereum.org/EIPS/eip-5267) - Ethereum Improvement Proposals (abgerufen: 2026-08-19)
- [EIP-2: Homestead Hard-fork Changes](https://eips.ethereum.org/EIPS/eip-2) - Ethereum Improvement Proposals (abgerufen: 2026-08-19)
- [Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html) - Solidity Documentation (abgerufen: 2026-08-19)
- [ERC-7730: Structured Data Clear Signing Format](https://eips.ethereum.org/EIPS/eip-7730) - Ethereum Improvement Proposals (abgerufen: 2026-08-19)
Source: https://wiki.fcontext.com/de/crypto/eip712-typed-signature/index.mdx