Zcash è una rete di criptovaluta proof-of-work e ZEC è il suo asset nativo. Supporta attività trasparenti e trasferimenti schermati che possono nascondere dettagli di transazione selezionati quando si utilizzano wallet e pool di indirizzi compatibili.
Usa questa pagina per valutare se Zcash soddisfa un'esigenza di pagamento o privacy, poi verifica la compatibilità del destinatario, il comportamento attuale delle commissioni, la politica di conferma e i limiti dell'attività schermata.
Questa pagina è un riferimento educativo di rete e di mercato. Non garantisce la privacy delle transazioni, la compatibilità dei wallet, il supporto degli exchange o i risultati degli investimenti.
ZEC/USDT · Binance Spot · UTC
Gli intervalli lunghi utilizzano automaticamente un intervallo di candele compatibile.
Le candele storiche di Binance Spot sono disponibili. JavaScript è necessario per gli aggiornamenti della candela corrente.
| Tempo (UTC) | Apertura (USDT) | Massimo (USDT) | Minimo (USDT) | Chiusura (USDT) | Volume (ZEC) |
|---|---|---|---|---|---|
| 25 ago 2026 18:00:00 UTC | 799,42 USDT | 801,84 USDT | 792,02 USDT | 798,12 USDT | 6.005,88 ZEC |
| 25 ago 2026 17:00:00 UTC | 799,91 USDT | 805,11 USDT | 793,39 USDT | 799,42 USDT | 9.846,01 ZEC |
| 25 ago 2026 16:00:00 UTC | 816,81 USDT | 823,77 USDT | 795,14 USDT | 799,90 USDT | 14.865,53 ZEC |
| 25 ago 2026 15:00:00 UTC | 818,71 USDT | 818,80 USDT | 803,35 USDT | 816,90 USDT | 14.268,89 ZEC |
| 25 ago 2026 14:00:00 UTC | 818,33 USDT | 831,36 USDT | 814,00 USDT | 818,71 USDT | 12.027,36 ZEC |
Dati di mercato: Binance Spot ZEC/USDT
Libreria grafici: TradingView Lightweight Charts
Zcash supporta sia flussi di transazione trasparenti che schermati.
Un protocollo con supporto schermato non rende privata ogni transazione ZEC.
Zcash è utile solo quando il wallet scelto, il destinatario e il percorso di transazione supportano la privacy e la compatibilità di cui hai effettivamente bisogno.
Trasferimenti schermati opzionali, pagamenti attenti alla privacy o divulgazione selettiva sono rilevanti, e ogni partecipante utilizza software Zcash compatibile.
Possedere ZEC o utilizzare la rete Zcash non nasconde automaticamente un trasferimento. Il pool di origine, il destinatario e il percorso costruito dal wallet determinano ciò che è protetto.
Wallet, exchange e servizi di pagamento supportano diversi tipi di destinatario e pool. Un indirizzo Zcash valido può comunque essere inutilizzabile in un particolare flusso di servizio.
Verifica il tipo di destinatario, il supporto del wallet, il percorso di transazione selezionato, la commissione visualizzata e la politica di conferma del servizio del destinatario prima di autorizzare il pagamento.
Un ZEC equivale a 100.000.000 zatoshis; la precisione di visualizzazione del portafoglio non modifica l'importo sottostante.
Denominazione di base visibile al portafoglio
Unità di conto minima di ZEC
Gli zatoshis forniscono l'unità di conto intera utilizzata quando il software rappresenta importi e commissioni in ZEC. La denominazione stessa non rivela se il valore è detenuto in un pool trasparente o schermato.
0,01 ZEC equivale a 1.000.000 di zatoshis.
La denominazione dell'importo è separata dal fatto che un trasferimento utilizzi un pool trasparente o schermato.
Le commissioni di transazione di Zcash sono pagate in ZEC e rappresentate in zatoshis. Le attuali linee guida convenzionali sulle commissioni utilizzano il lavoro logico svolto da una transazione piuttosto che una tariffa fissa universale per ogni trasferimento.
Secondo la regola convenzionale attiva ZIP 317, i portafogli contano le azioni logiche contribuite da input e output trasparenti e da spese e output schermati. Una commissione marginale di 5.000 zatoshis viene applicata con due azioni di grazia, che mantiene una transazione convenzionale minima a 10.000 zatoshis consentendo a costruzioni più complesse di costare di più.
La costruzione di transazioni schermate può includere padding per ridurre la perdita di informazioni da forme insolite. Tale padding e l'attività tra pool possono influenzare il conteggio delle azioni, quindi due pagamenti con lo stesso importo in ZEC possono ricevere commissioni calcolate dal portafoglio diverse. La commissione convenzionale è una linea guida di policy del portafoglio, non un'affermazione che il consenso richieda che ogni transazione utilizzi una commissione esatta.
Una transazione minima entro le due azioni di grazia ha una commissione convenzionale di 10.000 zatoshis, pari a 0,0001 ZEC. Una transazione con più azioni logiche può avere una raccomandazione più alta.
Utilizza la commissione mostrata da un portafoglio attuale e affidabile. Non codificare una vecchia tariffa fissa o scegliere manualmente una commissione insolita senza comprenderne gli effetti sulla privacy e sul relay.
Una transazione Zcash può combinare input o output trasparenti con azioni schermate Sapling o Orchard. La privacy risultante dipende dal percorso completo selezionato dal portafoglio.
L'attività trasparente espone i suoi indirizzi pubblici e i valori. Lo shielding sposta il valore da una fonte trasparente in un pool schermato; il deshielding espone il lato di destinazione trasparente; e un trasferimento completamente schermato protegge gli indirizzi schermati rilevanti e i campi di importo dall'ispezione pubblica ordinaria. Le transazioni tra pool possono includere più di un protocollo di trasferimento, quindi il portafoglio deve spiegare cosa è protetto piuttosto che trattare ogni transazione con prova come equivalente.
Note di origine, receiver di destinazione, gestione del resto e supporto del portafoglio determinano quali componenti trasparenti o schermati vengono costruiti.
Una prova a conoscenza zero valida i componenti protetti senza rivelare i loro valori protetti, ma non nasconde i componenti trasparenti o i metadati raccolti al di fuori del protocollo.
Zcash supporta ricevitori trasparenti, Sapling e Orchard. Un Indirizzo Unificato può codificare più ricevitori, così un portafoglio mittente può scegliere il protocollo di trasferimento supportato migliore.
| Tipo di indirizzo | Prefisso comune | Pool | Uso tipico | Nota di compatibilità |
|---|---|---|---|---|
| Ricevitore trasparente | t1 o t3 | Trasparente | Trasferimenti pubblici e ampia integrazione legacy | Indirizzi e valori trasferiti sono pubblici |
| Ricevitore Sapling | zs | Pool schermato Sapling | Pagamenti schermati in portafogli compatibili | Il supporto diretto a Sapling varia a seconda del portafoglio e del servizio |
| Ricevitore Orchard | All'interno di un indirizzo unificato | Pool schermato Orchard | Pagamenti schermati attuali tramite portafogli compatibili | Nessuna codifica autonoma di indirizzo Orchard rivolta all'utente |
| Indirizzo Unificato | u | Contenitore di ricevitori | Una codifica di indirizzo che può trasportare tipi di ricevitori supportati | Il portafoglio mittente seleziona un ricevitore compatibile; la privacy non è garantita |
Un Indirizzo Unificato è un contenitore di indirizzi, non una prova che la transazione finale sia schermata. Il mittente decodifica i ricevitori disponibili e ne seleziona uno che supporta; la politica del portafoglio e il servizio del destinatario rimangono quindi parte del risultato di privacy. Le chiavi di visualizzazione sono credenziali sensibili separate che possono rivelare l'attività schermata per contabilità o divulgazione selettiva senza concedere autorità di spesa.
Confermare quale ricevitore userà il portafoglio mittente, specialmente quando un Indirizzo Unificato include più di un'opzione.
Un portafoglio o exchange può supportare depositi trasparenti ma non Sapling, Orchard o ogni forma di Indirizzo Unificato.
La prima conferma registra una transazione in un blocco accettato. Ulteriore profondità riduce il rischio di riorganizzazione secondo la politica del portafoglio o del servizio, ma non cambia la privacy della transazione già stabilita dal suo percorso.
La transazione è vista dal portafoglio o dal servizio ma non è ancora inclusa in un blocco accettato.
La transazione è inclusa in un blocco Zcash accettato, mentre il rischio di riorganizzazione rimane dipendente dalla politica.
Ogni blocco accettato successivo rende meno probabile una riorganizzazione; la profondità richiesta varia a seconda del portafoglio, del commerciante e dell'exchange.
Il portafoglio può attendere le sue condizioni di conferma o fiducia configurate prima di consentire che l'output ricevuto venga speso.
Un portafoglio può mostrare un importo in entrata prima di trattare quell'output come spendibile. La distinzione dipende dall'inclusione nel blocco, dalla profondità di conferma, dal fatto che il portafoglio tratti la fonte come fidata e dalla sua politica di rischio. Le linee guida ufficiali del portafoglio possono raccomandare una soglia di conferma, ma quella raccomandazione è politica operativa piuttosto che una singola regola di consenso per ogni commerciante, exchange e portafoglio.
Le interfacce dovrebbero distinguere un pagamento rilevato da un saldo confermato e approvato dalla politica che può essere speso.
La profondità di conferma affronta il rischio di inversione. Le scelte del ricevitore e del percorso di transazione affrontano la divulgazione.
Il design a due percorsi preserva il comportamento familiare dei pagamenti pubblici rendendo disponibile una più forte riservatezza on-chain tramite protocolli schermati.
L'attività trasparente di Zcash si comporta in modo molto simile a un pagamento UTXO convenzionale: gli indirizzi e i valori trasferiti sono visibili sulla catena pubblica. Ciò rende più semplici l'ispezione di base, i depositi su exchange e le integrazioni per i servizi costruiti attorno ai registri di transazioni pubbliche. Significa anche che questi trasferimenti non ricevono le protezioni di indirizzo e importo di un percorso completamente schermato.
I pool schermati consentono ai nodi di verificare che una transazione sia valida senza pubblicare allo stesso modo i campi protetti di mittente, destinatario e importo. Questo cambia ciò che un osservatore ordinario della catena può apprendere, ma non cancella l'esistenza della transazione, la sua commissione o ogni indizio creato da tempi, controparti e flusso di lavoro circostante.
Supportare entrambi i modelli aiuta Zcash a interagire con software che hanno capacità diverse, ma sposta una decisione importante nel portafoglio. Il portafoglio deve riconoscere il destinatario, scegliere un protocollo di trasferimento supportato e spiegare quando il valore passa tra pool trasparenti e schermati. Una schermata di invio familiare non basta se nasconde quale percorso verrà utilizzato.
Un adattamento utile dipende da un supporto schermato deliberato, un percorso del destinatario funzionante e una politica operativa che accetta controlli di compatibilità specifici di Zcash.
Zcash può adattarsi quando entrambe le parti supportano deliberatamente un destinatario schermato e il mittente può verificare il percorso prima di firmare.
Attenzione a: Conferma la versione del portafoglio, il tipo di destinatario, la commissione e il supporto del destinatario; un fallback all'attività trasparente cambia il modello di divulgazione.
Le capacità di visualizzazione possono supportare riconciliazione o reporting senza cedere l'autorità di spesa quando il flusso di lavoro è progettato per questo scopo.
Attenzione a: Definisci chi riceve l'accesso di visualizzazione, cosa rivela e come il materiale chiave viene archiviato e revocato operativamente.
Un'applicazione può usare bene Zcash quando gestisce esplicitamente Indirizzi Unificati, destinatari schermati, commissioni e stati di conferma.
Attenzione a: Testa ogni pool supportato e percorso di migrazione invece di assumere che il supporto generico per portafogli di criptovalute sia sufficiente.
Il supporto per destinatari schermati e componenti di Indirizzi Unificati varia tra i servizi, quindi un percorso che preserva la privacy potrebbe non essere disponibile ovunque.
Confronta: Usa un binario di pagamento esplicitamente supportato da ogni controparte richiesta, quindi confronta i suoi compromessi di divulgazione.
Zcash consente attività trasparente e transizioni miste tra pool. Il protocollo non può trasformare un destinatario non supportato o una destinazione trasparente in un pagamento completamente schermato.
Confronta: Valuta progetti con privacy predefinita se la selezione opzionale del percorso è inaccettabile, rivedendo i loro stessi limiti di compatibilità.
Questa pagina descrive Zcash come rete di pagamento e privacy, non come sostituto di un ambiente applicativo generale stile EVM.
Confronta: Valuta una piattaforma di smart contract quando lo stato applicativo programmabile è il requisito centrale.
I protocolli schermati proteggono campi specifici sulla catena; non sono una promessa di completo anonimato operativo.
In un trasferimento schermato, il protocollo è progettato per mantenere indirizzi e valori protetti dall'ispezione pubblica ordinaria consentendo comunque alla rete di rifiutare spese non valide. Input o output trasparenti rimangono pubblici, e spostare valore dentro o fuori da un pool schermato può rivelare il lato trasparente di quel percorso. La privacy dipende quindi dall'intera transazione, non semplicemente dal fatto che un destinatario schermato appaia in essa.
Il comportamento del portafoglio è importante perché il portafoglio sceglie note, destinatari, gestione del resto e protocolli di trasferimento. Un Indirizzo Unificato può contenere più di un tipo di destinatario, e il portafoglio mittente seleziona uno che supporta. Questo migliora la compatibilità, ma non garantisce che il pagamento finale utilizzi un destinatario schermato Orchard o Sapling.
Le chiavi di visualizzazione forniscono accesso in lettura controllato senza concedere autorità di spesa. Possono supportare contabilità, reporting o divulgazione selettiva quando il portafoglio e il processo aziendale le gestiscono correttamente. Dovrebbero comunque essere protette come informazioni sensibili perché il detentore potrebbe apprendere dettagli di transazione che non sono pubblici sulla catena.
La privacy di rete si ferma anche prima di nascondere informazioni raccolte altrove. Un exchange, un commerciante o una controparte potrebbe conoscere un'identità dell'account, un indirizzo IP, dettagli di consegna o relazioni temporali. Più conferme possono ridurre il rischio di inversione, ma non nascondono informazioni già visibili in un percorso trasparente o già condivise con un servizio.
La distinzione utile non è quale rete sia universalmente migliore, ma se trasparenza, schermatura opzionale o comportamento con privacy predefinita corrispondano al flusso di lavoro previsto.
| Rete | Modello di transazione | Comportamento dell'indirizzo | Consenso | Adattamento tipico | Compromesso operativo |
|---|---|---|---|---|---|
| Zcash | Percorsi trasparenti, schermati, di schermatura e de-schermatura coesistono. | I destinatari trasparenti, Sapling e Orchard possono essere rappresentati tramite formati di indirizzo compatibili, inclusi gli Indirizzi Unificati. | Prova di lavoro. | Workflow che scelgono deliberatamente supporto schermato o divulgazione selettiva. | La compatibilità con ricevitore, pool e servizio deve essere verificata. |
| Bitcoin | Gli input e gli output delle transazioni sono pubblicamente ispezionabili. | I formati degli indirizzi identificano le destinazioni di script supportate, non un pool schermato. | Prova di lavoro. | Pagamenti e regolamento pubblici ampiamente supportati UTXO. | Il grafico delle transazioni pubbliche richiede pratiche di privacy separate. |
| Monero | Le caratteristiche di privacy del protocollo si applicano ai trasferimenti ordinari per impostazione predefinita. | L'indirizzamento del portafoglio è costruito attorno al comportamento delle transazioni private piuttosto che a ricevitori trasparenti opzionali. | Prova di lavoro. | Utenti che desiderano un comportamento di privacy senza scegliere un percorso trasparente o schermato. | Il supporto del servizio, i metodi di audit e gli strumenti operativi differiscono dai sistemi trasparenti UTXO. |
La maggior parte degli errori deriva dal trattare una capacità di rete come una proprietà automatica di ogni portafoglio, indirizzo e transazione.
Correzione: Zcash supporta percorsi trasparenti e schermati. Solo i campi protetti dai protocolli di trasferimento schermato scelti ricevono quelle proprietà di riservatezza on-chain.
Perché è importante: Un mittente o una destinazione trasparente può esporre indirizzi e valori che non possono essere nascosti in seguito aspettando più blocchi.
Correzione: Un Indirizzo Unificato è un contenitore per tipi di ricevitore compatibili. Il portafoglio mittente seleziona un ricevitore che supporta secondo lo standard applicabile e le sue capacità.
Perché è importante: Il percorso finale può differire tra portafogli, quindi il mittente deve verificare il ricevitore visualizzato e il risultato di privacy.
Correzione: Le conferme aumentano la profondità dopo l'inclusione nel blocco e riducono il rischio di riorganizzazione secondo la politica. Non riscrivono i dati di transazione precedentemente divulgati.
Perché è importante: La sicurezza contro l'inversione e la riservatezza sono proprietà separate e richiedono controlli separati.
Correzione: Il supporto varia in base a prodotto, versione e politica del servizio. Un ricevitore valido secondo il protocollo può essere comunque rifiutato da una particolare interfaccia.
Perché è importante: I flussi di invio o deposito dovrebbero essere testati prima di un trasferimento sensibile al tempo o di alto valore.
Correzione: L'attuale guida convenzionale sulle tariffe tiene conto delle azioni logiche e include azioni di grazia. I portafogli possono calcolare tariffe convenzionali diverse per transazioni costruite in modo diverso.
Perché è importante: Codificare una vecchia tariffa fissa può sottostimare la tariffa selezionata dal portafoglio e può creare un comportamento tariffario insolito.
Correzione: I protocolli schermati proteggono campi on-chain definiti, non informazioni raccolte da dispositivi, reti, exchange, commercianti o controparti.
Perché è importante: La privacy operativa dipende ancora dalle connessioni del portafoglio, dall'identità dell'account, dai tempi e da ciò che viene condiviso al di fuori della catena.
I controlli pratici differiscono per chi effettua un pagamento, un team di portafoglio, un servizio che accetta depositi o un'organizzazione che usa la divulgazione selettiva.
Prima di inviare, identifica se la destinazione è trasparente, Sapling, Orchard o un Indirizzo Unificato e leggi l'anteprima del portafoglio per il percorso di trasferimento effettivo. Un saldo ZEC da solo non dice nulla sul supporto del ricevitore o su cosa rivelerà la transazione.
Un wallet dovrebbe analizzare i formati di indirizzo attuali, selezionare correttamente i destinatari, calcolare la commissione convenzionale corrente e distinguere i saldi ricevuti da quelli spendibili. I messaggi di errore dovrebbero spiegare i percorsi non supportati invece di ripiegare silenziosamente.
I servizi dovrebbero dichiarare quali tipi di destinatario accettano, se possono restituire fondi a una destinazione schermata e quante conferme richiede la loro politica di rischio. Le operazioni di deposito necessitano anche di un percorso di recupero per indirizzi non supportati o spendibilità ritardata.
La divulgazione selettiva può supportare la riconciliazione o la rendicontazione senza concedere autorità di spesa, ma il materiale di visualizzazione può rivelare attività protette al suo detentore. Le procedure di accesso, archiviazione, trasferimento e gestione degli incidenti dovrebbero essere definite prima della sua condivisione.
Lo snapshot è CoinGecko dati aggregati ZEC/USD. Il grafico è dati Binance Spot ZEC/USDT. USD e USDT sono asset di quotazione diversi, quindi i valori visualizzati possono differire.
Standard tecnici primari utilizzati per esaminare le spiegazioni su transazione, destinatario, commissione e wallet in questa pagina.
Domande operative aggiuntive non coperte dalle sezioni principali su transazione e destinatario.
Le chiavi di visualizzazione possono fornire accesso in lettura all'attività schermata supportata senza concedere la possibilità di spendere. L'organizzazione ha comunque bisogno di una politica per l'accesso, la conservazione e l'esatto ambito di divulgazione.
Un wallet può rilevare una transazione in entrata prima che raggiunga la profondità di conferma o la policy di fiducia richiesta per la spesa. L'interfaccia deve distinguere i saldi rilevati, confermati e spendibili.
Dipende dal contenuto dell'indirizzo unificato e dal wallet del mittente. Il wallet può selezionare un destinatario trasparente supportato quando presente, ma il mittente deve verificare il percorso visualizzato perché questa scelta cambia ciò che è pubblico.
Contenuto tecnico verificato, fonti revisionate e cronologia degli aggiornamenti.