Warum manche Blockchains verbergen, was du wirklich signierst

Wenn du eine Krypto-Transaktion auf einer Hardware-Wallet freigibst, tust du meist eines von zwei Dingen: Entweder liest du eine verständliche Zusammenfassung dessen, was gleich passiert – oder du bestätigst blind eine Wand aus rohem Hex-Code 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 zur $1,5-Milliarden-Bybit-Hack bei – dem größten Krypto-Diebstahl der Geschichte. Die Angreifer mussten keine Kryptografie knacken. Sie nutzten aus, dass Menschen nicht zwischen einer gewöhnlichen Überweisung und einem bösartigen Vertrags-Upgrade unterscheiden konnten.
 

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 jede Blockchain auf Protokollebene entworfen wurde. Manche Chains sind so gebaut, dass Transaktionen sich selbst beschreiben. Andere verstecken kritische Details in Binärdaten, die externe Informationen zum Entschlüsseln benötigen. Dieser Artikel zeigt, wie sich diese Designentscheidungen auf die wichtigsten Blockchains auswirken – und was das für deine Sicherheit bedeutet.

Das Drei-Stufen-Modell

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

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 hier nicht um „gut“ oder „schlecht“, sondern um Designentscheidungen, die oft Jahre vor der vollen Erkenntnis der Sicherheitsfolgen getroffen wurden.

Stufe 1: Gebaut für Transparenz

Diese Blockchains sorgen dafür, dass verständliches Signieren ein natürlicher Teil ihres Designs ist. Der Kern: Sie verwenden eine begrenzte Menge typisierter Transaktionsstrukturen, bei denen jedes Feld einen Namen, einen Typ und ein festes Schema hat. Eine Hardware-Wallet benötigt keine externen Infos zum Parsen – die Transaktion sagt selbst, was sie ist.

Der XRP Ledger bietet vielleicht das klarste und konsequenteste Signiererlebnis aller großen Chains. Sein Binärformat enthält ein TransactionType-Feld, das eine eindeutige Zuordnung zu über 50 Transaktionstypen ermöglicht: Payment, OfferCreate, TrustSet, EscrowCreate und mehr. Jedes Feld hat ein festes Schema. Eine Hardware-Wallet kann Empfänger, Betrag, Gebühr, Memo und alle weiteren Parameter anzeigen, ohne etwas nachschlagen zu müssen. Nahezu alle Mainnet-Transaktionen lassen sich so vollständig klar signieren.

Polkadot hat mit seinem Runtime-Metadaten-System (MetadataV14/V15) die technisch ausgereifteste Lösung für Clear Signing entwickelt. Jede Transaktion verweist auf Pallet- und Call-Indizes, und die Metadaten erklären exakt, was diese bedeuten und wie die Argumente zu dekodieren sind. Die Herausforderung: Das vollständige Metadatenpaket ist mit über 200 KB zu groß für viele Hardware-Wallets.
 

Die Lösung, RFC-0078 (Merkleized Metadata), baut einen kryptografischen Baum aus den Metadaten, überträgt nur den relevanten Teil und prüft den Nachweis on-chain. So kann eine einzige Ledger-App alle Polkadot-Parachains unterstützen – ohne individuelle Updates.
 

Cosmos setzt auf eine typisierte Nachrichtenarchitektur und den SIGN_MODE_TEXTUAL-Standard (ADR-050), eingeführt mit Cosmos SDK v0.50. Dadurch werden Transaktionen als menschenlesbare Bildschirme für kleine Displays dargestellt. Coin-Beträge erscheinen als „2 ATOM“ statt „2000000uatom“. NEAR Protocol geht noch weiter und nutzt lesbare Kontonamen wie „alice.near“ sowie JSON-serialisierte Funktionsargumente, die als Klartext angezeigt werden können.
 

Stufe 2: Gut für Standardfälle, problematisch bei komplexen Vorgängen

Sechs Ökosysteme bieten für ihre nativen Vorgänge solides Clear Signing, werden aber bei Smart Contracts deutlich undurchsichtiger. Bitcoin ist das Paradebeispiel: 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 vorherigen Outputs. PSBT (BIP 174) löst das für Standardzahlungen (ca. 90 % der Fälle), aber Taproot-Script-Path-Ausgaben und komplexe Multisig-Setups bleiben undurchsichtig.
 

Stellar zeigt diese Zweiteilung besonders deutlich. Seine 26 klassischen Operationstypen (Payment, ManageSellOffer, ChangeTrust) haben feste Schemata und lassen sich auf Hardware-Wallets gut anzeigen. Mit Soroban Smart Contracts (seit 2024) kehrt jedoch EVM-typische Undurchsichtigkeit zurück: Parameter werden als kodierte Binärdaten übertragen, die spezielles Vertragswissen erfordern – die Abdeckung sinkt von etwa 95 % bei klassischen Operationen auf nahezu null bei Soroban-Interaktionen. Algorand, Cardano, Aptos und Tezos folgen ähnlichen Mustern: starke Abdeckung für native Vorgänge, große Lücken bei komplexer Logik.
 

Stufe 3: Undurchsichtigkeit ist Teil des Designs

Drei Ökosysteme haben architektonische Entscheidungen getroffen, die Clear Signing grundsätzlich erschweren – unabhängig davon, wie gut die Wallet-Software ist. Das erklärt, warum Blind-Signing-Warnungen auf fast allen großen DeFi-Plattformen auftauchen.
 

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 in 32-Byte-Blöcken kodierten Parametern. Ohne das ABI-JSON des Vertrags bleibt das reine Hex-Daten. Dieses ABI liegt nicht on-chain vor. Eine Hardware-Wallet kann nicht wissen, dass 0xa9059cbb... „1.000 USDC an 0xABC... übertragen“ bedeutet, sofern keine externen Metadaten vorhanden sind.
Proxy Contracts, die die Ausführung an wechselnde Implementierungsverträge weiterleiten, verschärfen das Problem – genau so lief der Bybit-Hack ab.
 

Die Antwort der Branche darauf ist ERC-7730, ein 2024 eingeführter Metadaten-Standard, der JSON-Dateien bereitstellt, um spezifische Vertragsinteraktionen zu dekodieren und darzustellen. Das funktioniert, erfordert aber, dass für jeden Contract Metadaten gepflegt werden. Im Kern ist es ein nachträglicher Patch für eine Architektur, die nicht auf Transparenz ausgelegt war.
 

Solana ist sogar noch anspruchsvoller: Transaktionsanweisungen enthalten eine Programm-ID und ein undurchsichtiges Byte-Array mit Instruktionsdaten ohne standardisiertes ABI – jedes Programm definiert sein eigenes Serialisierungsformat. Das Anchor-Framework bietet einen teilweisen Standard mit 8-Byte-Discriminators, aber viele Programme nutzen Anchor nicht und veröffentlichen keine Schnittstellen öffentlich. Bei DeFi-Transaktionen erfordert der Großteil des Solana-Volumens Blind Signing.

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

 Fazit

Das Wichtigste: Überprüfe, zu welcher Stufe deine Chain gehört, bevor du eine Hardware-Wallet für DeFi nutzt. Bei Stufe 1 funktioniert Clear Signing wie vorgesehen. Bei Stufe 2 sind einfache Transfers meist sicher, bei komplexeren Smart Contracts solltest du jedoch genau prüfen. Bei Stufe 3 gilt: Sei bei jeder DeFi-Transaktion besonders skeptisch und prüfe, 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 Transaktionsdetails auf dem sicheren Display an. 

Polkadots Merkleized-Metadata-Ansatz ist wohl die eleganteste Lösung der Branche: vertrauenslos, kryptografisch geprüft und nativ im Protokoll verankert. Die Branche bewegt sich in Richtung besserer Standards, aber die grundlegenden Protokollgrenzen der Stufe-3-Chains bleiben bestehen.
 

Die einfachste Regel: Wenn deine Wallet dir einen Hash oder eine Hex-Zeichenkette anzeigt und dich zum Signieren auffordert, ist das ein Warnsignal.

Ressourcen und weiterführende Links

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