Zcash ist ein Proof-of-Work-Kryptowährungsnetzwerk, und ZEC ist sein nativer Vermögenswert. Es unterstützt transparente Aktivitäten und geschützte Transfers, die ausgewählte Transaktionsdetails verbergen können, wenn kompatible Wallets und Adresspools verwendet werden.
Nutzen Sie diese Seite, um zu beurteilen, ob Zcash für einen Zahlungs- oder Datenschutzbedarf geeignet ist, und prüfen Sie dann die Kompatibilität des Empfängers, das aktuelle Gebührenverhalten, die Bestätigungsrichtlinie und die Grenzen geschützter Aktivitäten.
Diese Seite ist eine pädagogische Netzwerk- und Marktreferenz. Sie garantiert keine Transaktionsprivatsphäre, Wallet-Kompatibilität, Börsenunterstützung oder Anlageergebnisse.
ZEC/USDT · Binance Spot · UTC
Lange Bereiche verwenden automatisch ein kompatibles Kerzenintervall.
Historische Binance-Spot-Kerzen sind verfügbar. JavaScript ist für Aktualisierungen der aktuellen Kerze erforderlich.
| Zeit (UTC) | Eröffnung (USDT) | Hoch (USDT) | Tief (USDT) | Schluss (USDT) | Volumen (ZEC) |
|---|---|---|---|---|---|
| 25. Aug. 2026 14:00:00 UTC | 818,33 USDT | 822,84 USDT | 816,32 USDT | 819,34 USDT | 1.918,62 ZEC |
| 25. Aug. 2026 13:00:00 UTC | 842,87 USDT | 844,64 USDT | 807,20 USDT | 818,26 USDT | 24.671,78 ZEC |
| 25. Aug. 2026 12:00:00 UTC | 836,70 USDT | 847,84 USDT | 828,26 USDT | 842,77 USDT | 13.021,00 ZEC |
| 25. Aug. 2026 11:00:00 UTC | 842,37 USDT | 843,75 USDT | 832,01 USDT | 836,80 USDT | 8.840,31 ZEC |
| 25. Aug. 2026 10:00:00 UTC | 839,73 USDT | 846,44 USDT | 835,81 USDT | 842,39 USDT | 8.168,63 ZEC |
Marktdaten: Binance Spot ZEC/USDT
Charting-Bibliothek: TradingView Lightweight Charts
Zcash unterstützt sowohl transparente als auch geschützte Transaktionsabläufe.
Ein geschütztes Protokoll macht nicht jede ZEC-Transaktion privat.
Zcash ist nur nützlich, wenn die gewählte Wallet, der Empfänger und der Transaktionspfad die Privatsphäre und Kompatibilität unterstützen, die Sie tatsächlich benötigen.
Optionale geschützte Transfers, datenschutzbewusste Zahlungen oder selektive Offenlegung relevant sind und jeder Teilnehmer kompatible Zcash-Software verwendet.
Der Besitz von ZEC oder die Nutzung des Zcash-Netzwerks verbirgt nicht automatisch eine Überweisung. Der Quellpool, der Ziel-Empfänger und der von der Wallet konstruierte Pfad bestimmen, was geschützt ist.
Wallets, Börsen und Zahlungsdienste unterstützen verschiedene Empfängertypen und Pools. Eine gültige Zcash-Adresse kann in einem bestimmten Dienstablauf dennoch unbrauchbar sein.
Überprüfen Sie den Empfängertyp, die Wallet-Unterstützung, den gewählten Transaktionspfad, die angezeigte Gebühr und die Bestätigungsrichtlinie des Empfängerdienstes, bevor Sie die Zahlung autorisieren.
Ein ZEC entspricht 100.000.000 Zatoshis; die Anzeigegenauigkeit der Wallet ändert nichts am zugrunde liegenden Betrag.
Wallet-seitige Basiseinheit
Kleinste ZEC-Buchungseinheit
Zatoshis stellen die ganzzahlige Buchungseinheit dar, die Software verwendet, wenn sie ZEC-Beträge und Gebühren darstellt. Die Einheit selbst gibt nicht preis, ob ein Wert in einem transparenten oder geschützten Pool gehalten wird.
0,01 ZEC entspricht 1.000.000 Zatoshis.
Die Betragseinheit ist getrennt davon, ob eine Überweisung einen transparenten oder geschützten Pool verwendet.
Zcash-Transaktionsgebühren werden in ZEC bezahlt und in Zatoshis dargestellt. Die aktuelle übliche Gebührenrichtlinie verwendet die logische Arbeit, die eine Transaktion leistet, anstatt eine universelle Pauschalgebühr für jede Überweisung zu erheben.
Gemäß der aktiven konventionellen Gebührenregel ZIP 317 zählen Wallets logische Aktionen, die von transparenten Eingaben und Ausgaben sowie von geschützten Spends und Outputs beigetragen werden. Eine marginale Gebühr von 5.000 Zatoshis wird mit zwei Freibetragsaktionen angewendet, was eine minimale konventionelle Transaktion bei 10.000 Zatoshis hält, während komplexere Konstruktionen mehr kosten können.
Die Konstruktion geschützter Transaktionen kann Auffüllungen umfassen, um Informationslecks durch ungewöhnliche Formen zu reduzieren. Diese Auffüllungen und Aktivitäten über Pools hinweg können die Aktionsanzahl beeinflussen, sodass zwei Zahlungen mit demselben ZEC-Betrag unterschiedliche von der Wallet berechnete Gebühren erhalten können. Die konventionelle Gebühr ist eine Richtlinie der Wallet, keine Behauptung, dass der Konsens von jeder Transaktion eine exakte Gebühr verlangt.
Eine minimale Transaktion innerhalb der zwei Freibetragsaktionen hat eine konventionelle Gebühr von 10.000 Zatoshis, was 0,0001 ZEC entspricht. Eine Transaktion mit mehr logischen Aktionen kann eine höhere Empfehlung haben.
Verwenden Sie die Gebühr, die eine aktuelle, vertrauenswürdige Wallet anzeigt. Hardcodieren Sie keine ältere Pauschalgebührenannahme und wählen Sie nicht manuell eine ungewöhnliche Gebühr, ohne deren Datenschutz- und Relay-Auswirkungen zu verstehen.
Eine Zcash-Transaktion kann transparente Eingaben oder Ausgaben mit geschützten Sapling- oder Orchard-Aktionen kombinieren. Die resultierende Privatsphäre hängt vom vollständigen Pfad ab, den die Wallet auswählt.
Transparente Aktivität legt ihre öffentlichen Adressen und Werte offen. Schützen bewegt Wert von einer transparenten Quelle in einen geschützten Pool; Entschützen legt die transparente Zielseite offen; und eine vollständig geschützte Überweisung schützt die relevanten geschützten Adressen und Betragsfelder vor gewöhnlicher öffentlicher Einsicht. Transaktionen über Pools hinweg können mehr als ein Übertragungsprotokoll umfassen, daher muss die Wallet erklären, was geschützt ist, anstatt jede beweistragende Transaktion als gleichwertig zu behandeln.
Quellnotizen, Zielempfänger, Wechselgeldbehandlung und Wallet-Unterstützung bestimmen, welche transparenten oder geschützten Komponenten konstruiert werden.
Ein Zero-Knowledge-Beweis validiert geschützte Komponenten, ohne deren geschützte Werte preiszugeben, verbirgt jedoch keine transparenten Komponenten oder Metadaten, die außerhalb des Protokolls gesammelt werden.
Zcash unterstützt transparente, Sapling- und Orchard-Empfänger. Eine Unified Address kann mehrere Empfänger kodieren, sodass eine sendende Wallet das beste unterstützte Übertragungsprotokoll wählen kann.
| Adresstyp | Häufiges Präfix | Pool | Typische Verwendung | Kompatibilitätshinweis |
|---|---|---|---|---|
| Transparenter Empfänger | t1 oder t3 | Transparent | Öffentliche Übertragungen und breite Legacy-Integration | Adressen und übertragene Werte sind öffentlich |
| Sapling-Empfänger | zs | Sapling-Shielded-Pool | Shielded-Zahlungen in kompatiblen Wallets | Direkte Sapling-Unterstützung variiert je nach Wallet und Dienst |
| Orchard-Empfänger | Innerhalb einer Unified Address | Orchard-Shielded-Pool | Aktuelle Shielded-Zahlungen über kompatible Wallets | Keine eigenständige benutzerorientierte Orchard-Adresskodierung |
| Einheitliche Adresse | u | Empfängercontainer | Eine Adresskodierung, die unterstützte Empfängertypen tragen kann | Die sendende Wallet wählt einen kompatiblen Empfänger aus; Datenschutz ist nicht garantiert |
Eine Unified Address ist ein Adresscontainer, kein Beweis dafür, dass die endgültige Transaktion shielded ist. Der Absender dekodiert die verfügbaren Empfänger und wählt einen unterstützten aus; Wallet-Richtlinie und Empfängerdienst bleiben daher Teil des Datenschutzergebnisses. Viewing Keys sind separate sensible Anmeldeinformationen, die shielded Aktivität für Buchhaltung oder selektive Offenlegung offenlegen können, ohne Ausgabeberechtigung zu erteilen.
Bestätigen Sie, welchen Empfänger die sendende Wallet verwenden wird, insbesondere wenn eine Unified Address mehr als eine Option enthält.
Eine Wallet oder Börse kann transparente Einzahlungen unterstützen, aber nicht Sapling, Orchard oder jede Unified-Address-Form.
Die erste Bestätigung erfasst eine Transaktion in einem akzeptierten Block. Zusätzliche Tiefe reduziert das Reorganisationsrisiko gemäß der Richtlinie der Wallet oder des Dienstes, ändert jedoch nicht die bereits durch ihren Pfad etablierte Transaktionsprivatsphäre.
Die Transaktion wird von der Wallet oder dem Dienst gesehen, ist aber noch nicht in einem akzeptierten Block enthalten.
Die Transaktion ist in einem akzeptierten Zcash-Block enthalten, während das Reorganisationsrisiko richtlinienabhängig bleibt.
Jeder weitere akzeptierte Block macht eine Reorganisation weniger wahrscheinlich; die erforderliche Tiefe variiert je nach Wallet, Händler und Börse.
Die Wallet kann auf ihre konfigurierten Bestätigungs- oder Vertrauensbedingungen warten, bevor sie zulässt, dass der empfangene Output ausgegeben wird.
Eine Wallet kann einen eingehenden Betrag anzeigen, bevor sie diesen Output als ausgabbar behandelt. Der Unterschied hängt von der Blockaufnahme, der Bestätigungstiefe, ob die Wallet die Quelle als vertrauenswürdig behandelt, und ihrer eigenen Risikorichtlinie ab. Offizielle Wallet-Anleitungen können eine Bestätigungsschwelle empfehlen, aber diese Empfehlung ist eine operative Richtlinie und keine einheitliche Konsensregel für jeden Händler, jede Börse und jede Wallet.
Schnittstellen sollten eine erkannte Zahlung von einem bestätigten, richtlinienkonformen Guthaben unterscheiden, das ausgegeben werden kann.
Die Bestätigungstiefe befasst sich mit dem Umkehrrisiko. Empfänger- und Transaktionspfadwahl befassen sich mit Offenlegung.
Das Zwei-Pfad-Design bewahrt vertrautes öffentliches Zahlungsverhalten, während es durch geschützte Protokolle stärkere On-Chain-Vertraulichkeit verfügbar macht.
Transparente Zcash-Aktivität verhält sich weitgehend wie eine herkömmliche UTXO-Zahlung: Adressen und übertragene Werte sind auf der öffentlichen Chain sichtbar. Das erleichtert grundlegende Inspektion, Börsen-Einzahlungen und Integrationen für Dienste, die auf öffentlichen Transaktionsdatensätzen aufbauen. Es bedeutet auch, dass diese Übertragungen nicht den Adress- und Betragsschutz eines vollständig geschützten Pfads erhalten.
Geschützte Pools ermöglichen es Knoten, zu verifizieren, dass eine Transaktion gültig ist, ohne den geschützten Absender, Empfänger und Betragsfelder auf dieselbe Weise zu veröffentlichen. Dies ändert, was ein gewöhnlicher Chain-Beobachter erfahren kann, löscht jedoch nicht die Existenz der Transaktion, ihre Gebühr oder jede Spur, die durch Timing, Gegenparteien und den umgebenden Arbeitsablauf entsteht.
Die Unterstützung beider Modelle hilft Zcash, mit Software zu interagieren, die unterschiedliche Fähigkeiten hat, verlagert jedoch eine wichtige Entscheidung in die Wallet. Die Wallet muss den Empfänger erkennen, ein unterstütztes Übertragungsprotokoll wählen und erklären, wenn Werte zwischen transparenten und geschützten Pools wechseln. Ein vertrauter Sendebildschirm reicht nicht aus, wenn er verbirgt, welcher Pfad verwendet wird.
Ein nützlicher Fit hängt von bewusster geschützter Unterstützung, einem funktionierenden Empfängerpfad und einer Betriebsrichtlinie ab, die Zcash-spezifische Kompatibilitätsprüfungen akzeptiert.
Zcash kann passen, wenn beide Seiten bewusst einen geschützten Empfänger unterstützen und der Absender den Pfad vor dem Signieren verifizieren kann.
Achten Sie auf: Bestätigen Sie Wallet-Version, Empfängertyp, Gebühr und Empfängerunterstützung; ein Fallback auf transparente Aktivität ändert das Offenlegungsmodell.
Anzeigefunktionen können Abgleich oder Berichterstattung unterstützen, ohne Ausgabeberechtigung zu übergeben, wenn der Workflow für diesen Zweck ausgelegt ist.
Achten Sie auf: Definieren Sie, wer Anzeigezugriff erhält, was er offenbart und wie das Schlüsselmaterial betrieblich gespeichert und widerrufen wird.
Eine Anwendung kann Zcash gut nutzen, wenn sie explizit Unified Addresses, geschützte Empfänger, Gebühren und Bestätigungszustände behandelt.
Achten Sie auf: Testen Sie jeden unterstützten Pool und Migrationspfad, anstatt anzunehmen, dass generische Kryptowährungs-Wallet-Unterstützung ausreicht.
Die Unterstützung für geschützte Empfänger und Unified-Address-Komponenten variiert zwischen Diensten, sodass ein datenschutzerhaltender Pfad möglicherweise nicht überall verfügbar ist.
Vergleichen Sie: Verwenden Sie ein Zahlungssystem, das explizit von jeder erforderlichen Gegenpartei unterstützt wird, und vergleichen Sie dann seine Offenlegungskompromisse.
Zcash erlaubt transparente Aktivität und gemischte Pool-Übergänge. Das Protokoll kann einen nicht unterstützten Empfänger oder ein transparentes Ziel nicht in eine vollständig geschützte Zahlung verwandeln.
Vergleichen Sie: Bewerten Sie Datenschutz-by-Design-Designs, wenn optionale Pfadauswahl inakzeptabel ist, und überprüfen Sie dabei deren eigene Kompatibilitätsgrenzen.
Diese Seite beschreibt Zcash als Zahlungs- und Privatsphärennetzwerk, nicht als Ersatz für eine allgemeine EVM-ähnliche Anwendungsumgebung.
Vergleichen Sie: Bewerten Sie eine Smart-Contract-Plattform, wenn programmierbarer Anwendungszustand die zentrale Anforderung ist.
Geschützte Protokolle schützen spezifische On-Chain-Felder; sie sind kein Versprechen vollständiger operativer Anonymität.
Bei einer geschützten Übertragung ist das Protokoll darauf ausgelegt, geschützte Adressen und Werte vor gewöhnlicher öffentlicher Inspektion zu bewahren, während das Netzwerk dennoch ungültige Ausgaben ablehnen kann. Transparente Eingaben oder Ausgaben bleiben öffentlich, und das Verschieben von Werten in oder aus einem geschützten Pool kann die transparente Seite dieses Pfads offenlegen. Datenschutz hängt daher von der vollständigen Transaktion ab, nicht einfach davon, ob ein geschützter Empfänger darin erscheint.
Das Wallet-Verhalten ist wichtig, weil das Wallet Notizen, Empfänger, Wechselgeldbehandlung und Übertragungsprotokolle wählt. Eine Unified Address kann mehr als einen Empfängertyp enthalten, und das sendende Wallet wählt einen, den es unterstützt. Das verbessert die Kompatibilität, garantiert jedoch nicht, dass die endgültige Zahlung einen Orchard- oder Sapling-geschützten Empfänger verwendet.
Viewing Keys bieten kontrollierten Lesezugriff, ohne Ausgabeberechtigung zu gewähren. Sie können Buchhaltung, Berichterstattung oder selektive Offenlegung unterstützen, wenn Wallet und Geschäftsprozess sie korrekt handhaben. Sie sollten dennoch als sensible Informationen geschützt werden, da der Inhaber Transaktionsdetails erfahren kann, die nicht öffentlich auf der Chain sind.
Netzwerkdatenschutz hört auch davor auf, Informationen zu verbergen, die anderswo gesammelt werden. Eine Börse, ein Händler oder eine Gegenpartei kann eine Kontenidentität, IP-Adresse, Lieferdetails oder Timing-Beziehung kennen. Mehr Bestätigungen können das Stornierungsrisiko verringern, verbergen jedoch nicht Informationen, die bereits in einem transparenten Pfad sichtbar oder bereits mit einem Dienst geteilt wurden.
Der nützliche Unterschied ist nicht, welches Netzwerk universell besser ist, sondern ob Transparenz, optionales Shielding oder Datenschutz-by-Design-Verhalten zum beabsichtigten Workflow passt.
| Netzwerk | Transaktionsmodell | Adressverhalten | Konsens | Typischer Fit | Betrieblicher Kompromiss |
|---|---|---|---|---|---|
| Zcash | Transparente, Shielding-, geschützte und Deshielding-Pfade koexistieren. | Transparent-, Sapling- und Orchard-Empfänger können durch kompatible Adressformate, einschließlich Unified Addresses, dargestellt werden. | Proof of Work. | Workflows, die bewusst abgeschirmte Unterstützung oder selektive Offenlegung wählen. | Die Kompatibilität von Empfänger, Pool und Dienst muss überprüft werden. |
| Bitcoin | Transaktionseingaben und -ausgaben sind öffentlich einsehbar. | Adressformate identifizieren unterstützte Skript-Ziele, nicht einen abgeschirmten Pool. | Proof of Work. | Breit unterstützte öffentliche UTXO-Zahlungen und -Abwicklung. | Der öffentliche Transaktionsgraph erfordert separate Datenschutzpraktiken. |
| Monero | Datenschutzfunktionen des Protokolls gelten standardmäßig für gewöhnliche Überweisungen. | Die Wallet-Adressierung ist auf privates Transaktionsverhalten ausgerichtet und nicht auf optionale transparente Empfänger. | Proof of Work. | Benutzer, die Datenschutzverhalten wünschen, ohne einen transparenten oder abgeschirmten Pfad zu wählen. | Service-Support, Prüfmethoden und operative Werkzeuge unterscheiden sich von transparenten UTXO-Systemen. |
Die meisten Fehler entstehen, wenn man eine Netzwerkfähigkeit als automatische Eigenschaft jeder Wallet, Adresse und Transaktion behandelt.
Korrektur: Zcash unterstützt transparente und abgeschirmte Pfade. Nur die Felder, die durch die gewählten abgeschirmten Übertragungsprotokolle geschützt sind, erhalten diese On-Chain-Vertraulichkeitseigenschaften.
Warum es wichtig ist: Ein transparenter Absender oder Empfänger kann Adressen und Werte offenlegen, die später nicht durch Warten auf weitere Blöcke verborgen werden können.
Korrektur: Eine Unified Address ist ein Container für kompatible Empfängertypen. Die sendende Wallet wählt einen Empfänger, den sie unterstützt, gemäß dem geltenden Standard und ihren Fähigkeiten.
Warum es wichtig ist: Der endgültige Pfad kann je nach Wallet variieren, daher muss der Absender den angezeigten Empfänger und das Datenschutzergebnis überprüfen.
Korrektur: Bestätigungen erhöhen nach der Blockaufnahme die Tiefe und verringern das Risiko einer Neuorganisation gemäß der Richtlinie. Sie schreiben zuvor offengelegte Transaktionsdaten nicht um.
Warum es wichtig ist: Sicherheit gegen Umkehrung und Vertraulichkeit sind getrennte Eigenschaften und erfordern getrennte Prüfungen.
Korrektur: Die Unterstützung variiert je nach Produkt, Version und Service-Richtlinie. Ein Empfänger, der unter dem Protokoll gültig ist, kann von einer bestimmten Oberfläche dennoch abgelehnt werden.
Warum es wichtig ist: Sende- oder Einzahlungsworkflows sollten vor einer zeitkritischen oder hochwertigen Überweisung getestet werden.
Korrektur: Die aktuelle übliche Gebührenrichtlinie berücksichtigt logische Aktionen und enthält Gnadenaktionen. Wallets können unterschiedliche übliche Gebühren für unterschiedlich konstruierte Transaktionen berechnen.
Warum es wichtig ist: Das Festcodieren eines alten Pauschalbetrags kann die von der Wallet gewählte Gebühr unterschätzen und ungewöhnliches Gebührenverhalten erzeugen.
Korrektur: Abgeschirmte Protokolle schützen definierte On-Chain-Felder, nicht Informationen, die von Geräten, Netzwerken, Börsen, Händlern oder Gegenparteien gesammelt werden.
Warum es wichtig ist: Operative Privatsphäre hängt weiterhin von Wallet-Verbindungen, Kontoidentität, Timing und dem ab, was außerhalb der Kette geteilt wird.
Die praktischen Prüfungen unterscheiden sich für jemanden, der eine Zahlung tätigt, ein Wallet-Team, einen Dienst, der Einzahlungen akzeptiert, oder eine Organisation, die selektive Offenlegung verwendet.
Überprüfen Sie vor dem Senden, ob das Ziel transparent, Sapling, Orchard oder eine Unified Address ist, und lesen Sie die Wallet-Vorschau für den tatsächlichen Übertragungspfad. Ein ZEC-Saldo allein sagt nichts über die Empfängerunterstützung oder darüber aus, was die Transaktion offenlegen wird.
Eine Wallet sollte aktuelle Adressformate parsen, Empfänger korrekt auswählen, die aktuelle konventionelle Gebühr berechnen und zwischen erhaltenen und ausgabefähigen Guthaben unterscheiden. Fehlermeldungen sollten nicht unterstützte Pfade erklären, anstatt stillschweigend zurückzufallen.
Dienste sollten angeben, welche Empfängertypen sie akzeptieren, ob sie Gelder an ein abgeschirmtes Ziel zurückgeben können und wie viele Bestätigungen ihre eigene Risikorichtlinie erfordert. Einzahlungsvorgänge benötigen auch einen Wiederherstellungspfad für nicht unterstützte Adressen oder verzögerte Ausgabefähigkeit.
Selektive Offenlegung kann Abstimmung oder Berichterstattung unterstützen, ohne Ausgabeberechtigung zu erteilen, aber das Viewing-Material kann dem Inhaber geschützte Aktivitäten offenbaren. Zugriff, Speicherung, Übergabe und Vorfallverfahren sollten definiert werden, bevor es geteilt wird.
Der Schnappschuss ist CoinGecko aggregierte ZEC/USD-Daten. Das Diagramm sind Binance-Spot-ZEC/USDT-Daten. USD und USDT sind unterschiedliche Kurswährungen, daher können die angezeigten Werte abweichen.
Primäre technische Standards, die zur Überprüfung der Transaktions-, Empfänger-, Gebühren- und Wallet-Erklärungen auf dieser Seite verwendet werden.
Zusätzliche betriebliche Fragen, die nicht durch die Hauptabschnitte zu Transaktionen und Empfängern beantwortet werden.
Anzeigeschlüssel können Lesezugriff auf unterstützte geschützte Aktivitäten gewähren, ohne die Möglichkeit zum Ausgeben zu erteilen. Die Organisation benötigt weiterhin eine Richtlinie für Zugriff, Speicherung und den genauen Offenlegungsumfang.
Eine Wallet kann eine eingehende Transaktion erkennen, bevor sie die für das Ausgeben erforderliche Bestätigungstiefe oder Vertrauensrichtlinie erreicht. Die Benutzeroberfläche sollte erkannte, bestätigte und ausgabefähige Guthaben unterscheiden.
Es hängt vom Inhalt der Unified Address und der sendenden Wallet ab. Die Wallet kann einen unterstützten transparenten Empfänger auswählen, wenn einer vorhanden ist, aber der Absender muss den angezeigten Pfad überprüfen, da diese Wahl ändert, was öffentlich ist.
Verifizierte technische Inhalte, überprüfte Quellen und Aktualisierungshistorie.