Zum Inhalt springen
Financial Context Wiki

Risiko einer Permit2-Signatur

Permit2 trennt wiederverwendbare Allowances von einmaligen Signaturübertragungen; sicheres Signieren erfordert die genaue Prüfung von Deployment, Domain, spender, Empfänger, Betrag, Nonce, Frist, Witness und Ausführungs-Calldata.

Aktualisiert

Nur zu Bildungszwecken; keine Anlageberatung oder Anlageempfehlung. Anlagen können zu Verlusten führen.

Direkte Antwort

Permit2 verbindet zwei getrennte Autorisierungssysteme. AllowanceTransfer speichert eine wiederverwendbare Owner-Token-spender-Allowance mit Betrag, Ablauf und geordneter Nonce. SignatureTransfer verbraucht einen einmal signierten Höchstbetrag mit ungeordneter Bitmap-Nonce und erzeugt keine dauerhafte spender-Allowance. Beide hängen weiterhin von der ERC-20-Allowance des Owners für Permit2 ab.

Eine gaslose Signatur kann Vermögenswerte bewegen, wenn spender oder Relayer die Ausführung bezahlt. Exakte Chain, bereitgestellten Permit2-Code, EIP-712-Domain, Modul, Token, spender, signierten Höchstbetrag, Empfänger-Calldata, Nonce und Uhren prüfen. Der echte Permit2-Vertrag macht bösartige spender, Empfänger, Router oder Witness nicht sicher.

Risiko einer Permit2-Signatur
0 / 5
0 Artikel überprüft; 5 noch ungelöste Punkte

Der Abschluss dieser Überprüfung beweist nicht, dass ein Vermögenswert, eine Transaktion oder ein System sicher ist.

Funktionsweise

  1. chainId, Netzwerk, Permit2-verifyingContract, bereitgestellten Runtime-Code, Token-Adresse und Dezimalstellen, Owner-Wallet-Typ und beabsichtigte Anwendung festlegen. Einen offiziellen Deployment-Eintrag verwenden; bekannte Adresse oder Bezeichnung genügt nicht.
  2. Vorgelagerte ERC-20-Allowance und Saldo des Owners für Permit2 lesen. Endliche oder unbegrenzte Genehmigung und tokenspezifisches Übertragungsverhalten erkennen; dieses Buch überlebt den Ablauf einer Permit2-Signatur oder gespeicherten nachgelagerten Allowance.
  3. Exakten Pfad und signierten Primary Type erkennen: AllowanceTransfer PermitSingle oder PermitBatch, beziehungsweise SignatureTransfer PermitTransferFrom oder dessen Batch- und Witness-Varianten. transferFrom nicht als signierten Typ behandeln.
  4. EIP-712-Domain und jeden Nachrichteneintrag decodieren. Bei AllowanceTransfer Token, uint160 amount, expiration, geordnete Nonce, spender und sigDeadline prüfen. Bei SignatureTransfer erlaubten Token und Betrag, ungeordnete Nonce, Deadline sowie den über den Caller-Kontext gebundenen spender prüfen.
  5. Ausführungs-Calldata getrennt decodieren. Bei einfachem SignatureTransfer sind SignatureTransferDetails.to und requestedAmount Ausführungsparameter, keine Felder des signierten Basis-Permits; der angeforderte Betrag muss lediglich unter dem signierten Maximum bleiben. Jeden Batch-Index sowie exakten Witness-Hash und Type String prüfen.
  6. Aktuelle geordnete Allowance-Nonce oder ungeordnetes Bitmap-Wort und Bit abfragen und exakten Caller, Calldata, Chain und Zustand simulieren. Empfänger, Router-Aktionen, Token-Eigenheiten, Saldo und beide Allowance-Bücher abstimmen; Simulation kann sich durch Zustand, Reihenfolge oder Reorganisation ändern.
  7. Beträge und Laufzeiten minimieren. Bei Verdacht Typed Data aufbewahren und korrekten vorgelagerten Revoke, nachgelagerten Allowance-Revoke oder Nonce-Invalidierung über vertrauenswürdigen Pfad einreichen, als Mempool-Rennen behandeln; Bestätigung abwarten und Übertragungen, Salden, Allowances und Bits abstimmen.

Das sigDeadline von AllowanceTransfer begrenzt, wann das signierte Permit gespeicherte Autorität anlegen oder ändern darf; expiration begrenzt deren Nutzung. Die Deadline von SignatureTransfer begrenzt die einmalige Ausführung. EIP-712 liefert typisierten Hash und Domain-Trennung, nicht Replay-Schutz oder Absichtssicherheit; Permit2-Nonce und -Frist setzen diese Grenzen.

Bei einer Vertrags-Wallet hängt ERC-1271-Gültigkeit von aktueller isValidSignature-Policy, Modulen, Schwellen und Code ab. Labels, abgeschnittene Hardware-Wallet-Anzeigen und erfolgreiche Simulationen sind Indizien, keine Garantien. Das Trennen eines Frontends widerruft weder Genehmigung noch Signatur.

Beispiele

  • Zwei Allowance-Bücher. Die endliche Token-Allowance für Permit2 beginnt bei 1,000 USDC; ein PermitSingle speichert 600 USDC für spender S. Nach einer Übertragung von 225 USDC durch S verbleiben 600 - 225 = 375 USDC; eine standardmäßige endliche vorgelagerte Token-Allowance wird zu 1,000 - 225 = 775 USDC. Ablauf oder Widerruf von 375 beseitigt 775 nicht; nicht standardmäßige Token können abweichen.
  • Einmaliger Empfänger und Betrag. SignatureTransfer signiert maximal 250 USDC; Calldata fordert 180 USDC für einen Händler. Bei ausreichendem Saldo und vorgelagerter Allowance kann die Ausführung 180 übertragen. Die Nonce wird verbraucht, also sind die ungenutzten 70 USDC nicht wiederverwendbar. Nennt die Calldata einen Angreifer, verhindert das Basis-Permit diese Umleitung durch den gebundenen spender nicht.
  • Ungeordnete Nonce-Bitmap. Für Nonce 513 gelten wordPos = 513 >> 8 = 2, bitPos = 513 & 255 = 1 und mask = 1 << 1 = 2. Die Ausführung setzt Bit 1 in Wort 2; Wiederholung von 513 scheitert, während Nonce 512 an Bit 0 unabhängig bleibt.
  • Widerrufsrennen. Eine gespeicherte Allowance beträgt 400 USDC. Der Owner sendet Widerruf auf null, aber zuerst wird eine Übertragung von 300 USDC ausgeführt, sodass 100 USDC verbleiben; der spätere Widerruf setzt den Rest auf 0. Endgültige Allowance null macht den realisierten Verlust von 300 USDC nicht rückgängig; Reihenfolge und Salden sind abzustimmen.

Risiken

  • Falsche Chain ID, Deployment oder Runtime-Code.
  • Gefälschter oder unerwarteter Verifying Contract.
  • Verwechslung von AllowanceTransfer und SignatureTransfer.
  • Bösartiger oder irrtümlicher spender und Caller.
  • Durch Ausführungs-Calldata gewählter Empfänger.
  • Angeforderter Betrag nahe dem signierten Maximum.
  • Falsche Token-Adresse, Symbol, Dezimalstellen oder Raw-Einheiten.
  • Dauerhafte oder unbegrenzte vorgelagerte ERC-20-Genehmigung.
  • Übermäßiger nachgelagerter Betrag oder Ablauf.
  • Verwechslung von Deadline, Signature Deadline und Expiration.
  • Veraltete oder in einem Rennen befindliche geordnete Nonce.
  • Wiederverwendetes Bitmap-Bit oder zu breite Invalidierungsmaske.
  • Abweichender Witness-Hash oder exakter Type String.
  • Versteckter, doppelter oder falsch indexierter Batch-Eintrag.
  • Frontend-Anzeige oder Calldata weicht von der Absicht ab.
  • Widerruf verliert Mempool- oder MEV-Rennen.
  • Änderung von ERC-1271-Modul, Signer, Schwelle oder Upgrade.
  • Fee-on-Transfer-, Rebasing-, pausierter, blockierter oder Callback-Token.
  • Zustandsdrift, Fehlschlag oder Reorganisation nach Simulation.
  • Hardware-Wallet-Bestätigung oder Trennung wird mit Sicherheit verwechselt.

Häufige Irrtümer

  • Eine Signatur ohne Gas-Abfrage kann keine Token bewegen. Eine andere Partei kann das Ausführungs-Gas bezahlen.
  • Die offizielle Permit2-Adresse beweist, dass spender und Empfänger sicher sind. Permit2 kann bösartige Autorität korrekt ausführen.
  • SignatureTransfer und AllowanceTransfer erzeugen dieselbe dauerhafte Berechtigung. Eines wird einmalig genutzt, das andere speichert wiederverwendbare Allowance.
  • Trennen oder Widerrufen einer Ebene beendet alle Pfade und ausstehenden Signaturen. Vorgelagerter, nachgelagerter und Nonce-Zustand sind getrennt; Rennen bleiben.
  • EIP-712, Hardware-Wallet oder erfolgreiche Simulation beweist Absicht und Finalität. Sie verbessern Sichtbarkeit oder Tests, ersetzen aber keine Prüfung von Feldern, Calldata und bestätigtem Zustand.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...