Zcash est un réseau de cryptomonnaie à preuve de travail, et ZEC est son actif natif. Il prend en charge les activités transparentes et les transferts protégés qui peuvent masquer certains détails de transaction lorsque des portefeuilles et des pools d'adresses compatibles sont utilisés.
Utilisez cette page pour évaluer si Zcash répond à un besoin de paiement ou de confidentialité, puis examinez la compatibilité du destinataire, le comportement actuel des frais, la politique de confirmation et les limites de l'activité protégée.
Cette page est une référence pédagogique sur le réseau et le marché. Elle ne garantit pas la confidentialité des transactions, la compatibilité des portefeuilles, le support des échanges ou les résultats d'investissement.
ZEC/USDT · Binance Spot · UTC
Les longues plages utilisent automatiquement un intervalle de bougies compatible.
Les chandeliers historiques au comptant de Binance sont disponibles. JavaScript est requis pour les mises à jour du chandelier actuel.
| Heure (UTC) | Ouverture (USDT) | Haut (USDT) | Bas (USDT) | Clôture (USDT) | Volume (ZEC) |
|---|---|---|---|---|---|
| 26 août 2026 13:00:00 UTC | 781,08 USDT | 783,81 USDT | 770,91 USDT | 771,49 USDT | 3 698,06 ZEC |
| 26 août 2026 12:00:00 UTC | 783,54 USDT | 792,22 USDT | 779,25 USDT | 781,08 USDT | 4 795,17 ZEC |
| 26 août 2026 11:00:00 UTC | 792,35 USDT | 795,76 USDT | 781,38 USDT | 783,51 USDT | 3 855,39 ZEC |
| 26 août 2026 10:00:00 UTC | 785,07 USDT | 795,46 USDT | 783,78 USDT | 792,30 USDT | 4 234,71 ZEC |
| 26 août 2026 09:00:00 UTC | 782,40 USDT | 791,30 USDT | 779,89 USDT | 785,14 USDT | 6 816,13 ZEC |
Données de marché : Binance Spot ZEC/USDT
Bibliothèque de graphiques : TradingView Lightweight Charts
Zcash prend en charge à la fois les flux de transactions transparents et protégés.
Un protocole capable de protéger ne rend pas chaque transaction ZEC privée.
Zcash n'est utile que lorsque le portefeuille, le destinataire et le chemin de transaction choisis prennent en charge la confidentialité et la compatibilité dont vous avez réellement besoin.
Les transferts protégés optionnels, les paiements soucieux de la confidentialité ou la divulgation sélective sont pertinents, et que chaque participant utilise un logiciel Zcash compatible.
Posséder ZEC ou utiliser le réseau Zcash ne masque pas automatiquement un transfert. Le pool source, le destinataire et le chemin de transaction construit par le portefeuille déterminent ce qui est protégé.
Les portefeuilles, les échanges et les services de paiement prennent en charge différents types de destinataires et de pools. Une adresse Zcash valide peut toujours être inutilisable dans un flux de service particulier.
Vérifiez le type de destinataire, le support du portefeuille, le chemin de transaction sélectionné, les frais affichés et la politique de confirmation du service du destinataire avant d'autoriser le paiement.
Un ZEC équivaut à 100 000 000 zatoshis ; la précision d'affichage du portefeuille ne change pas le montant sous-jacent.
Dénomination de base côté portefeuille
Plus petite unité de comptabilité ZEC
Les zatoshis fournissent l'unité de comptabilité entière utilisée lorsque les logiciels représentent les montants et les frais en ZEC. La dénomination elle-même ne révèle pas si la valeur est détenue dans un pool transparent ou protégé.
0,01 ZEC équivaut à 1 000 000 zatoshis.
La dénomination du montant est distincte du fait qu'un transfert utilise un pool transparent ou protégé.
Les frais de transaction Zcash sont payés en ZEC et représentés en zatoshis. Les recommandations conventionnelles actuelles sur les frais utilisent le travail logique effectué par une transaction plutôt qu'un frais forfaitaire universel pour chaque transfert.
Selon la règle de frais conventionnelle ZIP 317 en vigueur, les portefeuilles comptent les actions logiques contribuées par les entrées et sorties transparentes et par les dépenses et sorties protégées. Un frais marginal de 5 000 zatoshis est appliqué avec deux actions de grâce, ce qui maintient une transaction conventionnelle minimale à 10 000 zatoshis tout en permettant aux constructions plus complexes de coûter plus cher.
La construction de transactions protégées peut inclure un rembourrage pour réduire les fuites d'informations provenant de formes inhabituelles. Ce rembourrage et l'activité inter-pools peuvent affecter le nombre d'actions, donc deux paiements avec le même montant en ZEC peuvent recevoir des frais calculés par le portefeuille différents. Les frais conventionnels sont une directive de politique du portefeuille, pas une affirmation que le consensus exige que chaque transaction utilise un frais exact.
Une transaction minimale dans les deux actions de grâce a des frais conventionnels de 10 000 zatoshis, soit 0,0001 ZEC. Une transaction avec plus d'actions logiques peut avoir une recommandation plus élevée.
Utilisez les frais affichés par un portefeuille actuel et fiable. Ne codez pas en dur une ancienne hypothèse de frais forfaitaires ou ne choisissez pas manuellement des frais inhabituels sans comprendre leurs effets sur la confidentialité et le relais.
Une transaction Zcash peut combiner des entrées ou sorties transparentes avec des actions protégées Sapling ou Orchard. La confidentialité résultante dépend du chemin complet sélectionné par le portefeuille.
L'activité transparente expose ses adresses et valeurs publiques. Le blindage déplace la valeur d'une source transparente vers un pool protégé ; le déblindage expose le côté de destination transparent ; et un transfert entièrement protégé protège les adresses et champs de montant protégés concernés de l'inspection publique ordinaire. Les transactions inter-pools peuvent inclure plus d'un protocole de transfert, donc le portefeuille doit expliquer ce qui est protégé plutôt que de traiter chaque transaction avec preuve comme équivalente.
Les notes sources, les récepteurs de destination, la gestion de la monnaie et le support du portefeuille déterminent quels composants transparents ou protégés sont construits.
Une preuve à connaissance nulle valide les composants protégés sans révéler leurs valeurs protégées, mais elle ne cache pas les composants transparents ni les métadonnées collectées en dehors du protocole.
Zcash prend en charge les récepteurs transparents, Sapling et Orchard. Une adresse unifiée peut encoder plusieurs récepteurs afin qu'un portefeuille d'envoi puisse choisir le meilleur protocole de transfert pris en charge.
| Type d'adresse | Préfixe courant | Pool | Utilisation typique | Note de compatibilité |
|---|---|---|---|---|
| Récepteur transparent | t1 ou t3 | Transparent | Transferts publics et intégration héritée large | Les adresses et les valeurs transférées sont publiques |
| Récepteur Sapling | zs | Pool protégé Sapling | Paiements protégés dans les portefeuilles compatibles | La prise en charge directe de Sapling varie selon le portefeuille et le service |
| Récepteur Orchard | Dans une adresse unifiée | Pool protégé Orchard | Paiements protégés actuels via des portefeuilles compatibles | Aucun encodage d'adresse Orchard autonome destiné à l'utilisateur |
| Adresse unifiée | u | Conteneur de récepteurs | Un encodage d'adresse qui peut transporter les types de récepteurs pris en charge | Le portefeuille d'envoi sélectionne un récepteur compatible ; la confidentialité n'est pas garantie |
Une adresse unifiée est un conteneur d'adresses, pas une preuve que la transaction finale est protégée. L'expéditeur décode les destinataires disponibles et sélectionne celui qu'il prend en charge ; la politique du portefeuille et le service du destinataire restent donc partie intégrante du résultat de confidentialité. Les clés de visualisation sont des informations d'identification sensibles distinctes qui peuvent révéler une activité protégée pour la comptabilité ou la divulgation sélective sans accorder l'autorité de dépense.
Confirmez quel récepteur le portefeuille d'envoi utilisera, surtout lorsqu'une adresse unifiée inclut plus d'une option.
Un portefeuille ou un échange peut prendre en charge les dépôts transparents mais pas Sapling, Orchard ou chaque forme d'adresse unifiée.
La première confirmation enregistre une transaction dans un bloc accepté. Une profondeur supplémentaire réduit le risque de réorganisation selon la politique du portefeuille ou du service, mais ne modifie pas la confidentialité de la transaction déjà établie par son chemin.
La transaction est vue par le portefeuille ou le service mais n'est pas encore incluse dans un bloc accepté.
La transaction est incluse dans un bloc Zcash accepté, tandis que le risque de réorganisation reste dépendant de la politique.
Chaque bloc accepté ultérieur rend une réorganisation moins probable ; la profondeur requise varie selon le portefeuille, le commerçant et la bourse.
Le portefeuille peut attendre sa confirmation configurée ou ses conditions de confiance avant de permettre que la sortie reçue soit dépensée.
Un portefeuille peut afficher un montant entrant avant de traiter cette sortie comme dépensable. La distinction dépend de l'inclusion dans un bloc, de la profondeur de confirmation, de savoir si le portefeuille traite la source comme fiable, et de sa propre politique de risque. Les directives officielles du portefeuille peuvent recommander un seuil de confirmation, mais cette recommandation est une politique opérationnelle plutôt qu'une règle de consensus unique pour chaque commerçant, échange et portefeuille.
Les interfaces doivent distinguer un paiement détecté d'un solde confirmé et approuvé par la politique qui peut être dépensé.
La profondeur de confirmation traite le risque de réversion. Les choix de récepteur et de chemin de transaction traitent la divulgation.
La conception à deux voies préserve le comportement de paiement public familier tout en offrant une confidentialité en chaîne plus forte grâce aux protocoles protégés.
L'activité transparente de Zcash se comporte comme un paiement UTXO conventionnel : les adresses et les valeurs transférées sont visibles sur la chaîne publique. Cela facilite l'inspection de base, les dépôts sur les échanges et les intégrations pour les services construits autour des enregistrements de transactions publiques. Cela signifie également que ces transferts ne bénéficient pas des protections d'adresse et de montant d'un chemin entièrement protégé.
Les pools protégés permettent aux nœuds de vérifier qu'une transaction est valide sans publier de la même manière les champs protégés de l'expéditeur, du destinataire et du montant. Cela change ce qu'un observateur ordinaire de la chaîne peut apprendre, mais cela n'efface pas l'existence de la transaction, ses frais ou chaque indice créé par le timing, les contreparties et le flux de travail environnant.
Le support des deux modèles aide Zcash à interagir avec des logiciels ayant des capacités différentes, mais cela déplace une décision importante vers le portefeuille. Le portefeuille doit reconnaître le destinataire, choisir un protocole de transfert pris en charge et expliquer quand la valeur passe entre les pools transparents et protégés. Un écran d'envoi familier ne suffit pas s'il cache quel chemin sera utilisé.
Une intégration utile dépend d'un support délibéré des protocoles protégés, d'un chemin de réception viable et d'une politique opérationnelle qui accepte les vérifications de compatibilité spécifiques à Zcash.
Zcash peut convenir lorsque les deux parties prennent en charge délibérément un destinataire protégé et que l'expéditeur peut vérifier le chemin avant de signer.
Attention à : Confirmez la version du portefeuille, le type de destinataire, les frais et le support du destinataire ; un repli vers une activité transparente change le modèle de divulgation.
Les capacités de visualisation peuvent prendre en charge le rapprochement ou le reporting sans céder l'autorité de dépense lorsque le flux de travail est conçu à cette fin.
Attention à : Définissez qui reçoit l'accès en visualisation, ce qu'il révèle et comment le matériel de clé est stocké et révoqué sur le plan opérationnel.
Une application peut bien utiliser Zcash lorsqu'elle gère explicitement les adresses unifiées, les destinataires protégés, les frais et les états de confirmation.
Attention à : Testez chaque pool pris en charge et chaque chemin de migration au lieu de supposer que le support générique des portefeuilles de cryptomonnaies est suffisant.
Le support des destinataires protégés et des composants d'adresses unifiées varie selon les services, donc un chemin préservant la confidentialité peut ne pas être disponible partout.
Comparer : Utilisez un rail de paiement explicitement pris en charge par chaque contrepartie requise, puis comparez ses compromis de divulgation.
Zcash permet une activité transparente et des transitions entre pools mixtes. Le protocole ne peut pas transformer un destinataire non pris en charge ou une destination transparente en un paiement entièrement protégé.
Comparer : Évaluez les conceptions de confidentialité par défaut si la sélection optionnelle du chemin est inacceptable, tout en examinant leurs propres limites de compatibilité.
Cette page décrit Zcash comme un réseau de paiement et de confidentialité, et non comme un substitut à un environnement d'application général de type EVM.
Comparer : Évaluez une plateforme de contrats intelligents lorsque l'état applicatif programmable est l'exigence centrale.
Les protocoles protégés protègent des champs spécifiques en chaîne ; ils ne sont pas une promesse d'anonymat opérationnel complet.
Dans un transfert protégé, le protocole est conçu pour garder les adresses et les valeurs protégées à l'abri de l'inspection publique ordinaire tout en permettant au réseau de rejeter les dépenses invalides. Les entrées ou sorties transparentes restent publiques, et le déplacement de valeur vers ou hors d'un pool protégé peut révéler le côté transparent de ce chemin. La confidentialité dépend donc de la transaction complète, pas simplement de la présence d'un destinataire protégé dans celle-ci.
Le comportement du portefeuille est important car le portefeuille choisit les notes, les destinataires, la gestion de la monnaie et les protocoles de transfert. Une adresse unifiée peut contenir plus d'un type de destinataire, et le portefeuille envoyeur sélectionne celui qu'il prend en charge. Cela améliore la compatibilité, mais ne garantit pas que le paiement final utilise un destinataire protégé Orchard ou Sapling.
Les clés de visualisation fournissent un accès en lecture contrôlé sans accorder l'autorité de dépense. Elles peuvent prendre en charge la comptabilité, le reporting ou la divulgation sélective lorsque le portefeuille et le processus métier les gèrent correctement. Elles doivent toujours être protégées comme des informations sensibles car le détenteur peut apprendre des détails de transaction qui ne sont pas publics sur la chaîne.
La confidentialité du réseau ne va pas non plus jusqu'à cacher les informations collectées ailleurs. Un échange, un commerçant ou une contrepartie peut connaître une identité de compte, une adresse IP, des détails de livraison ou une relation de timing. Plus de confirmations peuvent réduire le risque de reversement, mais elles ne cachent pas les informations déjà visibles dans un chemin transparent ou déjà partagées avec un service.
La distinction utile n'est pas de savoir quel réseau est universellement meilleur, mais si la transparence, la protection optionnelle ou la confidentialité par défaut correspond au flux de travail prévu.
| Réseau | Modèle de transaction | Comportement de l'adresse | Consensus | Intégration typique | Compromis opérationnel |
|---|---|---|---|---|---|
| Zcash | Les chemins transparents, de blindage, blindés et non blindés coexistent. | Les récepteurs transparents, Sapling et Orchard peuvent être représentés via des formats d'adresse compatibles, y compris les adresses unifiées. | Preuve de travail. | Flux de travail qui choisissent délibérément le support blindé ou la divulgation sélective. | La compatibilité des récepteurs, des pools et des services doit être vérifiée. |
| Bitcoin | Les entrées et sorties de transaction sont publiquement inspectables. | Les formats d'adresse identifient les destinations de script prises en charge, pas un pool blindé. | Preuve de travail. | Paiements et règlements publics UTXO largement pris en charge. | Le graphe de transaction public nécessite des pratiques de confidentialité distinctes. |
| Monero | Les fonctionnalités de confidentialité du protocole s'appliquent par défaut aux transferts ordinaires. | L'adressage du portefeuille est construit autour d'un comportement de transaction privé plutôt que de récepteurs transparents optionnels. | Preuve de travail. | Utilisateurs qui souhaitent un comportement de confidentialité sans choisir un chemin transparent ou protégé. | Le support des services, les méthodes d'audit et les outils opérationnels diffèrent des systèmes transparents UTXO. |
La plupart des erreurs viennent du fait de traiter une capacité du réseau comme une propriété automatique de chaque portefeuille, adresse et transaction.
Correction : Zcash prend en charge les chemins transparents et blindés. Seuls les champs protégés par les protocoles de transfert blindés choisis reçoivent ces propriétés de confidentialité sur la chaîne.
Pourquoi c'est important : Un expéditeur ou une destination transparent peut exposer des adresses et des valeurs qui ne peuvent pas être cachées plus tard en attendant plus de blocs.
Correction : Une adresse unifiée est un conteneur pour des types de récepteurs compatibles. Le portefeuille d'envoi sélectionne un récepteur qu'il prend en charge selon la norme applicable et ses capacités.
Pourquoi c'est important : Le chemin final peut différer selon les portefeuilles, donc l'expéditeur doit vérifier le récepteur affiché et le résultat de confidentialité.
Correction : Les confirmations augmentent la profondeur après l'inclusion du bloc et réduisent le risque de réorganisation selon la politique. Elles ne réécrivent pas les données de transaction précédemment divulguées.
Pourquoi c'est important : La sécurité contre l'inversion et la confidentialité sont des propriétés distinctes et nécessitent des vérifications distinctes.
Correction : Le support varie selon le produit, la version et la politique de service. Un récepteur valide selon le protocole peut toujours être rejeté par une interface particulière.
Pourquoi c'est important : Les flux d'envoi ou de dépôt doivent être testés avant un transfert urgent ou de grande valeur.
Correction : Les directives actuelles sur les frais conventionnels tiennent compte des actions logiques et incluent des actions de grâce. Les portefeuilles peuvent calculer des frais conventionnels différents pour des transactions construites différemment.
Pourquoi c'est important : Coder en dur un ancien montant fixe peut sous-estimer les frais sélectionnés par le portefeuille et peut créer un comportement de frais inhabituel.
Correction : Les protocoles blindés protègent les champs définis sur la chaîne, pas les informations collectées par les appareils, les réseaux, les échanges, les commerçants ou les contreparties.
Pourquoi c'est important : La confidentialité opérationnelle dépend toujours des connexions du portefeuille, de l'identité du compte, du calendrier et de ce qui est partagé en dehors de la chaîne.
Les vérifications pratiques diffèrent pour quelqu'un qui effectue un paiement, une équipe de portefeuille, un service acceptant des dépôts ou une organisation utilisant la divulgation sélective.
Avant d'envoyer, identifiez si la destination est transparente, Sapling, Orchard ou une adresse unifiée et lisez l'aperçu du portefeuille pour le chemin de transfert réel. Un solde ZEC seul ne dit rien sur le support du récepteur ou ce que la transaction révélera.
Un portefeuille doit analyser les formats d'adresse actuels, sélectionner correctement les destinataires, calculer les frais conventionnels actuels et distinguer les soldes reçus des soldes dépensables. Les messages d'erreur doivent expliquer les chemins non pris en charge au lieu de revenir silencieusement à une option par défaut.
Les services doivent indiquer les types de destinataires qu'ils acceptent, s'ils peuvent retourner des fonds vers une destination blindée et combien de confirmations leur propre politique de risque exige. Les opérations de dépôt nécessitent également un chemin de récupération pour les adresses non prises en charge ou la dépensabilité retardée.
La divulgation sélective peut soutenir le rapprochement ou le reporting sans accorder d'autorité de dépense, mais le matériel de visualisation peut révéler une activité protégée à son détenteur. Les procédures d'accès, de stockage, de transfert et d'incident doivent être définies avant qu'il ne soit partagé.
L'instantané est un agrégat de données CoinGecko ZEC/USD. Le graphique est constitué de données Binance Spot ZEC/USDT. USD et USDT sont des actifs de cotation différents, donc les valeurs affichées peuvent différer.
Normes techniques principales utilisées pour examiner les explications sur la transaction, le destinataire, les frais et le portefeuille sur cette page.
Questions opérationnelles supplémentaires non traitées dans les sections principales sur la transaction et le destinataire.
Les clés de visualisation peuvent fournir un accès en lecture à l'activité protégée prise en charge sans accorder la possibilité de dépenser. L'organisation a toujours besoin d'une politique pour l'accès, le stockage et la portée exacte de la divulgation.
Un portefeuille peut détecter une transaction entrante avant qu'elle n'atteigne la profondeur de confirmation ou la politique de confiance requise pour la dépense. L'interface doit distinguer les soldes détectés, confirmés et dépensables.
Cela dépend du contenu de l'adresse unifiée et du portefeuille d'envoi. Le portefeuille peut sélectionner un récepteur transparent pris en charge lorsqu'il est présent, mais l'expéditeur doit vérifier le chemin affiché car ce choix modifie ce qui est public.
Contenu technique vérifié, sources examinées et historique des mises à jour.