Zcash Private Keys und Seed-Phrase erklärt

Eine Zcash-Seed-Phrase ist das eine Backup, aus dem eine moderne Zcash-Wallet alle ihre Schlüssel ableitet: Spending Keys, die ZEC bewegen können, Viewing Keys, die nur Aktivität sehen, und die Adressen, die du weitergibst. In Zodl besteht sie aus 24 Wörtern und einer optionalen Birthday Height. Wer die Wörter kennt, kontrolliert die Mittel, deshalb gehören sie nie auf eine Website.

Dieser Ratgeber verfolgt die Kette von diesen Wörtern bis zur Adresse, erklärt, was jeder Schlüssel darin kann, und endet mit den Sicherheitsregeln, die wichtiger sind als jede Kryptografie. Die ganze Geschichte zu Viewing Keys steht in unserem eigenen Ratgeber zum Zcash Viewing Key; dieser Artikel fasst sie nur zusammen.

Die Zcash-Schlüsselhierarchie im Überblick

Stell sie dir als Stammbaum vor, in dem jeder Zweig aus der Wurzel neu berechnet werden kann, aber kein Zweig den Weg nach oben zurück erlaubt:

1. Seed-Phrase. Wörter wie word01 word02 … word24 (Platzhalter), die den zufälligen Seed der Wallet kodieren.
2. Seed. Die Bytes, für die die Wörter stehen. Alles andere wird daraus berechnet.
3. Konto (Account). Ein nummerierter „Topf“ mit Mitteln unter einer Ausgabeberechtigung, abgeleitet entlang eines festen Pfads aus ZIP 32.
4. Spending Keys. Einer pro Konto und Protokoll: transparent, Sapling und Orchard. Sie autorisieren Ausgaben.
5. Full Viewing Key. Aus dem Spending Key abgeleitet. Sieht eingehende Zahlungen und Ausgaben, kann nichts ausgeben.
6. Incoming Viewing Key. Aus dem Full Viewing Key abgeleitet. Sieht nur eingehende Zahlungen.
7. Adressen. Aus den Viewing Keys abgeleitet. Zu einem Konto können sehr viele verschiedene Adressen gehören.

Jeder Schritt führt nur nach unten. Ein Viewing Key kann keinen Spending Key rekonstruieren, und eine Adresse verrät keinen von beiden. Deshalb ist es sicher, eine Adresse weiterzugeben, und nie sicher, den Seed weiterzugeben.

Die Seed-Phrase: 24 Wörter, die für alles stehen

Eine Seed-Phrase (Zodl nennt sie Recovery Phrase) ist eine lesbare Schreibweise für Zufallsdaten. Das übliche Format ist BIP 39: Zufällige Entropie plus eine kurze Prüfsumme wird in Gruppen zu 11 Bit geteilt, und jede Gruppe wählt ein Wort aus einer festen Liste von 2.048 Wörtern. Aus den Wörtern berechnet die Wallet dann den binären Seed.

Das Help Desk von Zodl beschreibt die Phrase als 24 Wörter in einer festen Reihenfolge, zusammen mit einer optionalen Blockhöhe (dem Wallet-Birthday). Es fügt hinzu, dass jeder mit Zugriff auf die Phrase das Zcash in deiner Wallet ausgeben und deine vergangenen und künftigen Transaktionen sehen kann.

Warum Zcash-Wallets 24 Wörter nutzen

ZIP 32, der finale Standard (Final) für die Schlüsselableitung in Zcash, verlangt, dass der Seed mindestens 256 Bit Entropie hat, und zwar ausdrücklich auch jede Mnemonic, aus der er entsteht. In der Tabelle von BIP 39 ergeben 128 Bit Entropie 12 Wörter und 256 Bit 24 Wörter. ZIP 315, ein Dokument mit Best Practices für Wallets, das noch als Draft (Entwurf) markiert ist, zieht den Schluss: Beim Erzeugen eines Seeds braucht es eine Mnemonic mit 24 Wörtern (bei SLIP-39-Secret-Sharing Anteile mit 33 Wörtern).

Eine Phrase mit 12 Wörtern ist also kein Zcash-Format. Sie ist bei anderen Coins verbreitet, hätte aber nur die Hälfte der Entropie, die ZIP 32 verlangt.

Der Wallet-Birthday

Der Birthday ist die Blockhöhe zum Zeitpunkt, an dem die Wallet erstellt wurde. Das Help Desk von Zodl nennt ihn als optionalen zweiten Teil des Backups, und die Anleitung zur Wiederherstellung fragt danach: Mit ihm überspringt die App alle Blöcke aus der Zeit vor deiner Wallet, die Synchronisierung geht schneller. Hast du ihn nicht notiert, bietet Zodl die Funktion „Estimate block height“ an, bei der du angibst, wann du die Wallet erstellt oder zuerst genutzt hast (die Anleitung nennt Jahr und Monat). Der Birthday ist nicht so geheim wie die Wörter und wird nicht gebraucht, um deine Mittel zu finden, nur um sie schneller zu finden. Unser Glossar-Eintrag zur Blockhöhe erklärt den Begriff.

Wiederherstellen aus einer kürzeren Phrase

ZIP 315 (Draft) sagt, eine Wallet DARF (MAY) beim Wiederherstellen eine BIP-39-Phrase mit weniger als 24 Wörtern annehmen, DARF aber keine erzeugen (MUST NOT). Sie SOLL (SHOULD) warnen, dass die wiederhergestellte Wallet schwächer ist als erwartet, und empfehlen, die Mittel nach der Synchronisierung in eine neue Wallet zu verschieben.

Konten und Ableitungspfade

ZIP 32 (Status: Final) überträgt die Idee hierarchischer Wallets aus Bitcoins BIP 32 auf die geschützten Pools von Zcash. Sapling und Orchard leiten aus demselben Seed jeweils einen eigenen Master Key ab und folgen dann denselben drei gehärteten Pfadebenen:

m / 32' / 133' / account'

• 32' ist der Zweck (purpose), eine Konstante, die den ZIP-32-Baum kennzeichnet.
• 133' ist der Coin-Typ. ZIP 32 übernimmt das Register aus SLIP 44, in dem 133 für ZEC steht.
• account' zählt ab 0 hoch. ZIP 32 beschreibt ein Konto als „Topf“ mit Mitteln (bucket of funds) unter der Kontrolle einer einzigen Ausgabeberechtigung.

Der Apostroph bedeutet gehärtete Ableitung: Schlüssel auf diesen Ebenen lassen sich nur aus dem geheimen Elternschlüssel ableiten, nie aus einem Viewing Key der Ebene darüber. Orchard unterstützt nur gehärtete Ableitung.

Deshalb kann ein Seed mehrere getrennte Konten enthalten, und deshalb können zwei Wallets, die aus denselben Wörtern wiederhergestellt wurden, unterschiedlich aussehen: Die eine zeigt vielleicht nur Konto 0, die andere durchsucht mehr Konten oder mehr Pools.

Spending Keys: die Berechtigung, ZEC zu bewegen

Ein Spending Key ist das, was eine Zahlung tatsächlich autorisiert. Zcash nutzt heute drei Arten, eine pro Protokoll (transparent, Sapling, Orchard), und eine ZIP-32-Wallet leitet alle für ein Konto aus demselben Seed ab.

Transparente Schlüssel

Transparente Adressen (t1…, t3…) funktionieren wie bei Bitcoin. Eine t1-Adresse ist ein Hash eines öffentlichen Schlüssels auf der Kurve secp256k1, und eine Ausgabe davon braucht eine ECDSA-Signatur mit dem passenden Private Key (Protokollspezifikation §4.1.7 und §5.6.1.1). Wallets, die diese Schlüssel aus dem Seed ableiten, nutzen den BIP-44-Pfad; ZIP 316 nennt für Empfangsadressen den Pfad m/44'/133'/account'/0/index. Transparente Mittel sind auf der Blockchain öffentlich, wie unser Ratgeber geschützte vs. transparente Transaktionen erklärt.

Sapling Spending Keys

Für Sapling definiert die Protokollspezifikation (§3.1, §4.2.2) einen Expanded Spending Key aus drei Teilen: einem Spend Authorizing Key (ask), einem Nullifier Private Key (nsk) und einem Outgoing Viewing Key (ovk). Ein erweiterter Spending Key nach ZIP 32 fügt einen Diversifier Key und einen Chain Code hinzu. Als Text im Mainnet beginnt er mit secret-extended-key-main1… (Platzhalter, gekürzt).

Orchard Spending Keys

Bei Orchard ist ein einzelner Spending Key (sk) der Ausgangspunkt. Daraus leitet eine Wallet den Spend Authorizing Key und einen Full Viewing Key aus ak, nk und rivk ab; Incoming und Outgoing Viewing Key entstehen aus diesem Full Viewing Key (Protokollspezifikation §3.1, §4.2.3). ZIP 32 definiert zwar auch eine Kodierung für erweiterte Orchard Spending Keys, secret-orchard-extsk-main1… (Platzhalter), erwartet aber, dass die meisten Wallets Nutzern nur die normale Orchard-Spending-Key-Kodierung zeigen.

Die Protokollspezifikation erinnert außerdem daran, dass der Aufbau dieser Schlüssel Nutzern normalerweise nicht gezeigt werden soll. In der Praxis erledigt deine Wallet all das, und die Seed-Phrase ist das eine Geheimnis, das du verwaltest.

Ironwood und der vorgeschlagene Quantum Spending Key

Ironwood, der mit dem Upgrade NU6.3 hinzugekommene geschützte Pool, bringt keine neue Art von Adresse oder Schlüssel. ZIP 229, Status Draft (Entwurf), definiert ihn als neuen Wertpool des Orchard-Protokolls und hält fest, dass Spending- und Viewing-Key-Material von Orchard berechtigt, Notes sowohl im Orchard- als auch im Ironwood-Pool auszugeben oder zu sehen. Adressstrukturen und Kodierungen ändert der Pool laut ZIP 229 nicht.

ZIP 2005, Ironwood Quantum Recoverability, hat den Status Proposed (vorgeschlagen). Unter anderem beschreibt er eine Option use_qsk mit einem alternativen „Quantum Spending Key“ (qsk), gedacht für Schlüssel aus einer verteilten FROST-Schlüsselerzeugung oder für Hardware-Wallets, bei denen der Orchard Spending Key das Gerät nicht verlassen soll. Für Backups ist der wichtigste Satz: Mit ZIP-32-Ableitung muss qsk nicht getrennt von der Seed-Phrase gesichert werden, weil er aus dem abgeleiteten Spending Key berechnet wird. Was ZIP 2005 leistet und was nicht, erklärt unser Ratgeber Ist Zcash quantenresistent?.

Viewing Keys in Kürze

Ein Viewing Key erlaubt seinem Inhaber, die geschützte Aktivität eines Kontos zu sehen, ohne ausgeben zu können:

• Ein Full Viewing Key sieht eingehende Zahlungen und Ausgaben und, bei Transaktionen nach Standardverhalten, auch ausgehende Details. Die kodierte Sapling-Form beginnt mit zxviews1… (Platzhalter).
• Ein Incoming Viewing Key sieht nur empfangene Zahlungen.
• Unified Viewing Keys bündeln diese pro Konto nach ZIP 316: uview1… für einen Unified Full Viewing Key und uivk1… für einen Unified Incoming Viewing Key (Revision 0, Active). Revision 1 ist zurückgezogen (Withdrawn), der Entwurf für Revision 2 schlägt die neuen Präfixe uvf und uvi vor.

Ein Viewing Key kann nichts ausgeben, ist aber eine dauerhafte Leseberechtigung, die sich nicht widerrufen lässt. Wer einen bekommen sollte und was er dann sieht, steht ausführlich in unserem Viewing-Key-Ratgeber und im Glossar-Eintrag zum Viewing Key.

ZIP 316 definiert nur Unified Addresses und Unified Viewing Keys. Einen „Unified Spending Key“ als Zeichenkette definiert er nicht, auf der Ausgabeseite bleibt die Seed-Phrase also das, was du sicherst.

Adressen werden abgeleitet, sie sind keine Schlüssel

Eine Adresse ist das Ende der Kette. Geschützte Adressen entstehen aus einem Incoming Viewing Key und einem Diversifier, deshalb kann ein Konto jedem Zahler eine neue Adresse geben, ohne dass jemand sie verknüpfen kann. ZIP 32 nennt als Grenze etwa 2^87 Adressen pro Konto für Sapling und 2^88 für Orchard. Eine Unified Address (u1…) bündelt Empfänger für mehrere Pools in einer Zeichenkette.

Unser Ratgeber zu den Zcash-Adresstypen erklärt t1, t3, zs1, u1 und tex1, und der Address Checker (englisch) sagt dir, welcher Typ eine Zeichenkette ist. Er prüft das Format in deinem Browser und nimmt immer nur eine Adresse entgegen, nie einen Schlüssel.

Was jeder Schlüssel kann

Ein Spending Key sieht alles, was seine Viewing Keys sehen, weil er sie ableiten kann. Eine Seed-Phrase kann alles, was jeder aus ihr abgeleitete Schlüssel kann.

Was ein Wallet-Backup wirklich braucht

Für eine Zodl-Wallet ist das Help Desk eindeutig: die 24 Wörter in der richtigen Reihenfolge und die optionale Birthday Height. Laut der Anleitung zur Wiederherstellung lassen sich alle Mittel einer Zodl-Wallet mit der Recovery Phrase wiederherstellen. Einzelne Schlüssel oder Adressen musst du nicht sichern, die Wallet berechnet sie neu.

Die Hinweise von Zodl zur Aufbewahrung:

• Schreibe die Wörter auf Papier und bewahre sie sicher und offline auf.
• Mache keinen Screenshot und kein Foto und speichere die Phrase nicht digital.
• Langlebigere Lösungen wie Backups aus Stahl sind eine Überlegung wert.
• Gib die Wörter bei einer Wiederherstellung nur dort ein, wo keine Menschen und keine Kameras sie sehen.

Sichere die Phrase, bevor du die App zurücksetzt oder deinstallierst. Zodl warnt, dass du sie zum Wiederherstellen brauchst und nach einem Zurücksetzen nicht mehr ansehen kannst. Wenn du eine zweite, unabhängige Wallet willst, erzeuge darin einen neuen Seed, statt den alten zu kopieren.

Niemals einen Seed oder Schlüssel in eine Website eingeben

Die Regel ist kurz und hat keine Ausnahmen: Keine Website, kein Formular, keine Browser-Erweiterung, kein Chat, keine E-Mail und kein Support braucht jemals deine Seed-Phrase oder einen Spending Key. Das gilt auch für diese Website. Zodl sagt es deutlich: Wer nach deiner Recovery Phrase fragt, versucht dich zu betrügen, und scheint die Anfrage von Zodl zu kommen, gibt sich jemand als Zodl aus.

Typische Fallen:

• Eine Seite zum „Validieren der Wallet“, zum „Reparieren der Synchronisierung“ oder für einen „Airdrop“, die nach den 24 Wörtern fragt.
• Ein Guthaben-Checker, der einen Schlüssel statt einer Adresse will. Für eine transparente Adresse brauchen unser Balance Checker (englisch) und der Explorer nur die Adresse. Geschützte Guthaben sind absichtlich privat, nur deine Wallet kann sie zeigen.
• Eine Direktnachricht vom „Support“, der eine hängende Wallet reparieren will. Unser Ratgeber zu Wallet-Problemen hilft bei Synchronisierungsproblemen ohne jeden Schlüssel.

Hast du deine Phrase jemals auf so einer Seite eingegeben, betrachte den Seed als kompromittiert: Erstelle auf einem Gerät, dem du vertraust, eine neue Wallet mit neuem Seed und verschiebe die Mittel dorthin. Ein neues Konto unter dem alten Seed hilft nicht, weil die alten Wörter es weiterhin kontrollieren.

Hardware-Wallets

Eine Hardware-Wallet soll den Seed auf einem eigenen Gerät halten und Transaktionen dort signieren, damit Handy oder Computer den Spending Key nie besitzen. Die Recovery Phrase des Geräts musst du trotzdem schützen. Wie das heute mit Zcash funktioniert, beschreiben unsere Anleitung zu Keystone und Zodl und unser Ledger-Ratgeber. Die Unterstützung hängt von Firmware- und App-Versionen ab, prüfe daher diese Ratgeber statt älterer Forenbeiträge.

Wenn die Seed-Phrase verloren ist

Solange die Wallet-App noch funktioniert, kannst du die Phrase in Zodl unter Menü „...“ > More > Advanced Settings > Zodl Recovery Phrase erneut ansehen und jetzt aufschreiben. Sind Handy und Phrase beide weg, sind die Mittel verloren. Zodl schreibt, dass es keinen Zugriff auf deine Phrase hat und dir nicht helfen kann, sie wiederherzustellen. Kein Wallet-Anbieter, keine Börse, keine Website und kein Support kann einen Seed neu erstellen. Wer das anbietet, betrügt.

Technische Details für Fortgeschrittene

• Von der Mnemonic zum Seed. BIP 39 macht aus den Wörtern mit PBKDF2 (HMAC-SHA512, 2.048 Runden) einen Seed mit 64 Byte. ZIP 32 akzeptiert Seeds mit 32 bis 252 Byte.
• Master Keys. ZIP 32 leitet aus demselben Seed getrennte Master Keys für Sapling und Orchard ab, mit unterschiedlichen BLAKE2b-Personalisierungen (ZcashIP32Sapling, ZcashIP32Orchard).
• Interne Schlüssel. Jedes Konto hat einen externen Schlüsselsatz für Adressen, die du weitergibst, und einen internen für Vorgänge in der Wallet wie Wechselgeld und Auto-Shielding; ZIP 32 spezifiziert beide für Sapling und Orchard.
• Kodierungen. Erweiterte Sapling Spending Keys nutzen das Bech32-Präfix secret-extended-key-main, erweiterte Sapling Full Viewing Keys zxviews, erweiterte Orchard Spending Keys secret-orchard-extsk-main. Unified Viewing Keys nutzen Bech32m mit einem Verwürfelungsschritt (Jumbling, ZIP 316).
• Sprout. Der ursprüngliche Sprout-Pool ist historisch. ZIP 32 führt seine früheren Ableitungskonstanten als reservierte Werte, die nicht wiederverwendet werden sollen, und Sprout ist nicht Teil der hier beschriebenen Ableitung.
• Veraltete Dokumente. Manche ältere Zcash-Dokumentation stammt aus der Zeit vor Orchard und Unified Addresses. Verlass dich lieber auf die ZIPs und die Protokollspezifikation.

Quellen und Methodik

Geprüft am 17. Oktober 2026 anhand von ZIP 32: Shielded Hierarchical Deterministic Wallets (Final; Abschnitte „Wallet seeds“, „Key path levels“, „Sapling key path“, „Orchard key path“ und die Schlüsselkodierungen), ZIP 315: Best Practices for Wallet Implementations (Draft; Abschnitt „Wallet seeds“), ZIP 316: Unified Addresses and Unified Viewing Keys (Revision 0 Active, Revision 1 Withdrawn, Revision 2 Draft), ZIP 229: Version 6 Transaction Format (Draft; Definitionen und „Ironwood pool“), ZIP 2005: Ironwood Quantum Recoverability (Proposed), der Zcash-Protokollspezifikation (Version v2026.7.0-318-ga34cfc vom 16. Oktober 2026; §3.1 „Payment Addresses and Keys“, §4.2.2 „Sapling Key Components“, §4.2.3 „Orchard Key Components“, §4.1.7 „Signature“, §5.6.1.1 „Transparent Addresses“), BIP 39, SLIP 44 sowie den Help-Desk-Artikeln von Zodl Backing up your Zodl recovery phrase (zuletzt aktualisiert am 24. Februar 2026) und Recovering your Zodl wallet (zuletzt aktualisiert am 28. September 2026). Schlüsselexport, Passphrase-Optionen und Wiederherstellungen zwischen verschiedenen Wallets haben wir nicht getestet, dieser Ratgeber macht dazu keine Aussage. Neue Artikel erscheinen zuerst im ZecZcash-Telegram-Kanal.