Warum manche Blockchains verbergen, was du unterschreibst

Warum du bei Chains wie Ethereum und Solana oft einen Blankoscheck unterschreibst – und wie die Branche das Problem angeht.

Dieser Artikel ist in folgenden Sprachen verfügbar:

Author logo
Patrick Dike-Ndulue
Post image

Wenn du eine Krypto-Transaktion auf einer Hardware-Wallet bestätigst, tust du meist eines von zwei Dingen: Entweder liest du eine verständliche Zusammenfassung dessen, was gleich passiert – oder du unterschreibst einen Haufen rohen Hex-Codes und hoffst, dass alles stimmt. Blind Signing bedeutet, eine digitale Transaktion zu genehmigen, ohne alle Details in menschenlesbarer Form prüfen zu können.
 

  Im Februar 2025 trug Blind Signing maßgeblich zum $1,5 Milliarden Bybit Hack bei – dem größten Krypto-Diebstahl der Geschichte. Die Angreifer haben keine Kryptografie geknackt, sondern ausgenutzt, dass Menschen nicht erkennen konnten, ob sie eine normale Überweisung oder ein bösartiges Vertrags-Upgrade unterschreiben.
 

Ob deine Wallet dir vor dem Signieren eine klare, verständliche Zusammenfassung anzeigt, ist keine Frage der Softwarequalität. Es hängt davon ab, wie die jeweilige Blockchain auf Protokollebene gebaut ist. Manche Chains sind so konzipiert, dass Transaktionen sich selbst beschreiben. Andere verstecken wichtige Details in binären Daten, die nur mit externen Informationen entschlüsselt werden können. Dieser Artikel erklärt, wie diese Designentscheidungen die großen Blockchains prägen – und was das für deine Sicherheit bedeutet.

 

image.png

Das Drei-Stufen-Modell

Clear Signing ist ein Sicherheitsprozess, bei dem du alle Details einer digitalen Transaktion auf einem sicheren Bildschirm in menschenlesbarer Form prüfen kannst, bevor du sie genehmigst. 


Unter den 13 wichtigsten Blockchain-Ökosystemen lässt sich die Unterstützung für Clear Signing in drei Stufen einteilen – je nach Protokollarchitektur. Es geht nicht darum, welche Chains „besser“ oder „schlechter“ sind, sondern um Designentscheidungen, die oft lange vor den heutigen Sicherheitsanforderungen getroffen wurden.

 

image.png

 

Tier 1: Für Transparenz gebaut

Diese Blockchains sorgen dafür, dass Signieren ein natürlicher Bestandteil ihres Designs ist. Der Grund: Sie verwenden eine endliche Menge typisierter Transaktionsstrukturen, bei denen jedes Feld einen Namen, einen Typ und ein festgelegtes Schema hat. Eine Hardware-Wallet benötigt keine externen Informationen, um sie zu interpretieren – die Transaktion sagt dir, was sie ist.

 

Der XRP Ledger bietet vermutlich das klarste und konsequenteste Clear Signing unter allen großen Chains. Sein binäres Format enthält ein TransactionType-Feld, das die eindeutige Interpretation von über 50 Transaktionstypen ermöglicht: Payment, OfferCreate, TrustSet, EscrowCreate und viele mehr. Jedes Feld hat ein festes Schema. Eine Hardware-Wallet kann Empfänger, Betrag, Gebühr, Memo und alle spezifischen Parameter anzeigen, ohne etwas nachschlagen zu müssen. Nahezu 100 % aller Mainnet-Transaktionen lassen sich vollständig klar signieren.

 

Polkadot hat mit seinem  Runtime-Metadata-System (MetadataV14/V15) die technisch ausgereifteste Clear-Signing-Lösung der Branche entwickelt. Jede Transaktion verweist auf Pallet- und Call-Indizes, und die Metadaten beschreiben exakt, was diese bedeuten und wie die Argumente zu interpretieren sind. Die Herausforderung: Der vollständige Metadatensatz ist mit über 200 KB zu groß für Hardware-Wallets mit begrenztem Speicher. 

Die Lösung,  RFC-0078 (Merkleized Metadata), bildet daraus einen kryptografischen Baum, überträgt nur den relevanten Teil und prüft den Einschlussbeweis on-chain. Das Ergebnis: Eine einzige Ledger-App funktioniert für alle Polkadot-Parachains – ohne individuelle Updates.
 

Cosmos setzt auf eine typisierte Nachrichtenarchitektur und den  SIGN_MODE_TEXTUAL-Standard (ADR-050), eingeführt im Cosmos SDK v0.50. Damit werden Transaktionen auf kleine Bildschirme als Klartext gerendert. Coin-Beträge erscheinen als „2 ATOM“ statt „2000000uatom“. NEAR Protocol geht noch weiter und bietet  menschenlesbare Account-Namen wie „alice.near“ sowie JSON-serialisierte Funktionsargumente, die eine Wallet direkt als Text anzeigen kann.
 

Tier 2: Für Standardfälle solide, bei Smart Contracts problematisch

Sechs Ökosysteme bieten für native Transaktionen gutes Clear Signing, stoßen aber bei Smart Contracts an Grenzen. Bitcoin ist das beste Beispiel: Das UTXO-Modell bedeutet, dass Rohtransaktionen keine Input-Beträge enthalten; eine Hardware-Wallet kann die Gebühr nicht berechnen, ohne zusätzliche Infos zu den vorherigen Outputs. PSBT (BIP 174) löst das für Standardzahlungen (ca. 90 % aller Fälle), aber Taproot-Script-Path-Spends und komplexe Multisig-Setups bleiben undurchsichtig.
 

Stellar zeigt diese Zweiteilung besonders deutlich: Die 26 klassischen Operationstypen (Payment, ManageSellOffer, ChangeTrust) haben feste Schemata und lassen sich auf Hardware-Wallets klar anzeigen. Mit den 2024 eingeführten Soroban-Smart-Contracts kommt aber wieder EVM-ähnliche Intransparenz ins Spiel: Parameter werden als kodierte Binärdaten übergeben, die nur mit spezifischem Vertragswissen entschlüsselt werden können. Die Abdeckung fällt von ca. 95 % bei klassischen Operationen auf nahezu null bei rohen Soroban-Interaktionen. Algorand, Cardano, Aptos und Tezos folgen ähnlichen Mustern: starke Unterstützung für Standardtransaktionen, große Lücken bei komplexer Logik.
 

Tier 3: Intransparenz ist eingebaut

Drei Ökosysteme haben Architekturen, die Clear Signing grundsätzlich schwierig machen – unabhängig davon, wie gut die Wallet-Software ist. Das erklärt, warum Blind-Signing-Warnungen in fast allen großen DeFi-Oberflächen erscheinen.
 

Ethereum und alle EVM-kompatiblen Chains teilen das Kernproblem: ABI-Encoding ist nicht selbsterklärend. Bei Interaktionen mit Smart Contracts enthält das Transaktionsdatenfeld einen 4-Byte-Function-Selector (die ersten vier Bytes des Hashs des Funktionsnamens), gefolgt von Parametern in 32-Byte-Blöcken. Ohne das ABI-JSON des Vertrags bleibt das reine Hex-Rauschen. Dieses ABI ist nicht on-chain gespeichert. Eine Hardware-Wallet weiß nicht, dass 0xa9059cbb... „1.000 USDC an 0xABC... senden“ bedeutet – es sei denn, sie hat externe Metadaten. 
Proxy Contracts, die Ausführung an Implementierungsverträge weiterleiten, deren Adressen sich ändern können, verschärfen das Problem – genau so lief auch der Bybit-Hack ab.
 

Die Antwort der Branche ist  ERC-7730, ein 2024 eingeführter Metadaten-Standard. Er liefert JSON-Dateien, die erklären, wie bestimmte Vertragsinteraktionen entschlüsselt und angezeigt werden. Das funktioniert – aber nur, wenn jemand diese Metadaten für jeden einzelnen Vertrag schreibt und pflegt. Im Kern ist es ein nachträglicher Patch für eine Architektur, die nicht für Transparenz gebaut wurde.
 

Solana ist sogar noch herausfordernder: Transaktionsanweisungen enthalten eine Program-ID und ein undurchsichtiges Byte-Array mit Instruktionsdaten ohne standardisiertes ABI. Jedes Programm definiert sein eigenes Serialisierungsformat. Das Anchor-Framework bietet einen halbstandardisierten Ansatz mit 8-Byte-Discriminators, aber viele Programme nutzen Anchor nicht und veröffentlichen keine Schnittstellen öffentlich. Für DeFi-Transaktionen bedeutet das: Die Mehrheit der Solana-Transaktionen muss blind signiert werden. 

TON bringt zusätzliche Komplexität durch asynchrone Ausführung: Du signierst nur die Anfangsnachricht, alles, was danach in späteren Blöcken passiert, bleibt beim Signieren unsichtbar.

 

 Fazit

Die wichtigste Empfehlung: Kenne die Stufe deiner Chain, bevor du eine Hardware-Wallet für DeFi verwendest. Bei Tier 1 funktioniert Clear Signing wie gewünscht. Bei Tier 2 kannst du einfache Transfers sicher unterschreiben, solltest aber bei komplexen Smart-Contract-Interaktionen immer recherchieren. Bei Tier 3 gilt: Jede Transaktion auf einem DeFi-Protokoll mit besonderer Vorsicht behandeln – und prüfen, ob dApp und Wallet ERC-7730-Metadaten unterstützen, bevor du etwas Wichtiges signierst.
 

Hersteller von Hardware-Wallets arbeiten aktiv an Lösungen. Ledgers Generic Parser liest ERC-7730-Metadaten und zeigt die Transaktionsdetails auf dem sicheren Display an. 

Polkadots Merkleized-Metadata-Ansatz ist wahrscheinlich die eleganteste Lösung der Branche: vertrauenslos, kryptografisch geprüft und protokoll-nativ. Die Branche bewegt sich in Richtung besserer Standards – aber die grundlegenden Einschränkungen von Tier-3-Protokollen bleiben bestehen.
 

Die einfachste Regel: Zeigt dir deine Wallet einen Hash oder einen Hex-Stream zum Signieren an, ist das ein Warnsignal.

 

Die folgenden Ressourcen bieten technischen Hintergrund zu den im Artikel besprochenen Protokollen und Standards.

ERC-7730 Specification (Ethereum Foundation)

EVM-Metadatenstandard für Clear Signing

BIP 174 — PSBT (Bitcoin Improvement Proposals)

Bitcoin: Teiltransaktionssignierung

Polkadot RFC-0078: Merkleized Metadata

Polkadot: Vertrauensloses Clear Signing

Cosmos ADR-050: SIGN_MODE_TEXTUAL

Cosmos: Menschenlesbares Signing

NEAR Protocol: Account Model

Menschenlesbare Account-Bezeichner

XRP Ledger: Transaction Types

XRP: Typisierte Transaktionsschemata

Ethereum: EIP-712 Typed Structured Data Signing

Off-Chain-Standard für typisierte Daten

Substrate Runtime Metadata Documentation

Polkadot/Substrate-Metadatensystem

Ledger ERC-7730 Registry (GitHub)

Community-Metadaten für ERC-7730

Algorand ARC-4: ABI Standard

Algorand: Smart-Contract-ABI

Häufig gestellte Fragen

  • Beim Clear Signing zeigt dir deine Hardware-Wallet vor der Freigabe alle Details in Klartext: Empfängeradresse, Token-Betrag, Netzwerkgebühr und die Aktion, die du bestätigst. Blind Signing bedeutet, dass die Wallet nur kodierte Binärdaten (meist eine Hex-Zeichenkette) anzeigt, die du nicht interpretieren kannst – du signierst also im Vertrauen. Das Risiko: Eine kompromittierte Anwendung könnte dir etwas anderes anzeigen, als du tatsächlich unterschreibst.

  • Nicht immer, aber das Risiko ist real. Bei einfachen ETH-Transfers zwischen Standard-Wallets kann deine Hardware-Wallet in der Regel Empfänger und Betrag klar anzeigen. Das Problem der Intransparenz entsteht, sobald du mit Smart Contracts interagierst – etwa beim Token-Tausch, beim Bereitstellen von Liquidität oder beim Freigeben von Berechtigungen. Ob du dann eine klare Anzeige bekommst, hängt davon ab, ob die jeweilige dApp und Wallet ERC-7730-Metadaten implementiert haben. Falls nicht, signierst du blind.

  • Protokolldesign ist immer ein Kompromiss. Ethereums flexibles ABI-System ermöglicht die Vielfalt der DeFi-Anwendungen, die auf restriktiveren Chains wie dem XRP Ledger nicht möglich wären. Diese Flexibilität geht aber auf Kosten selbsterklärender Transaktionen. Eine nachträgliche Änderung würde die Kompatibilität mit tausenden bestehenden Smart Contracts brechen. Ansätze wie ERC-7730 und EIP-712 bringen praktische Verbesserungen innerhalb der bestehenden Architektur – ein vollständiges Redesign ist kaum umsetzbar.

  • ERC-7730 ist ein 2024 eingeführter JSON-Metadatenstandard, der Hardware-Wallets erklärt, wie sie bestimmte Smart-Contract-Interaktionen entschlüsseln und anzeigen können. Ein Protokollteam kann eine Metadatendatei bereitstellen, die die rohe ABI-Codierung der Vertragsfunktionen in verständliche Labels und Formate übersetzt.

  • Ja, deutlich. Auch wenn eine Hardware-Wallet nur kodierte Daten statt einer Klartext-Zusammenfassung anzeigt, verlässt der private Schlüssel nie das sichere Element und die Signaturentscheidung erfolgt auf isolierter Hardware. Ein kompromittierter Computer kann deinen Schlüssel nicht auslesen. Das Risiko beim Blind Signing auf Hardware-Wallets ist, dass du vielleicht eine Transaktion genehmigst, die du sonst abgelehnt hättest – aber dein Schlüssel bleibt geschützt. Bei Software-Wallets ist sowohl die Entscheidung als auch der Schlüssel selbst im Zweifel angreifbar.

Author logo
Autor Patrick Dike-Ndulue

Senior editor covering crypto, onchain equities, and technology.

Author logo
Rezension von Rukkayah Jigam

Writer & editor covering digital assets and product updates.