Zcash is een proof-of-work cryptocurrency-netwerk, en ZEC is het native activum. Het ondersteunt transparante activiteiten en afgeschermde overdrachten die geselecteerde transactiedetails kunnen verbergen wanneer compatibele wallets en adresgroepen worden gebruikt.
Gebruik deze pagina om te beoordelen of Zcash past bij een betalings- of privacybehoefte, en bekijk vervolgens de compatibiliteit van de ontvanger, het huidige vergoedingsgedrag, het bevestigingsbeleid en de beperkingen van afgeschermde activiteiten.
Deze pagina is een educatieve netwerk- en marktreferentie. Het garandeert geen transactieprivacy, walletcompatibiliteit, exchange-ondersteuning of investeringsresultaten.
ZEC/USDT · Binance Spot · UTC
Lange reeksen gebruiken automatisch een compatibel kaarsinterval.
Historische Binance Spot-kaarsen zijn beschikbaar. JavaScript is vereist voor updates van de huidige kaars.
| Tijd (UTC) | Openen (USDT) | Hoog (USDT) | Laag (USDT) | Sluit (USDT) | Volume (ZEC) |
|---|---|---|---|---|---|
| 26 aug 2026 14:00:00 UTC | 773,53 USDT | 778,44 USDT | 767,16 USDT | 768,20 USDT | 3.122,50 ZEC |
| 26 aug 2026 13:00:00 UTC | 781,08 USDT | 783,81 USDT | 759,60 USDT | 773,53 USDT | 14.138,19 ZEC |
| 26 aug 2026 12:00:00 UTC | 783,54 USDT | 792,22 USDT | 779,25 USDT | 781,08 USDT | 4.795,17 ZEC |
| 26 aug 2026 11:00:00 UTC | 792,35 USDT | 795,76 USDT | 781,38 USDT | 783,51 USDT | 3.855,39 ZEC |
| 26 aug 2026 10:00:00 UTC | 785,07 USDT | 795,46 USDT | 783,78 USDT | 792,30 USDT | 4.234,71 ZEC |
Marktgegevens: Binance Spot ZEC/USDT
Grafiekbibliotheek: TradingView Lightweight Charts
Zcash ondersteunt zowel transparante als afgeschermde transactiestromen.
Een protocol dat afgeschermde transacties ondersteunt, maakt niet elke ZEC-transactie privé.
Zcash is alleen nuttig wanneer de gekozen wallet, ontvanger en transactiepad de privacy en compatibiliteit ondersteunen die u daadwerkelijk nodig heeft.
Optionele afgeschermde overdrachten, privacybewuste betalingen of selectieve openbaarmaking relevant zijn, en elke deelnemer compatibele Zcash-software gebruikt.
Het bezitten van ZEC of het gebruik van het Zcash-netwerk verbergt niet automatisch een overdracht. De bronpool, de bestemmingsontvanger en het door de wallet geconstrueerde pad bepalen wat wordt beschermd.
Wallets, beurzen en betaaldiensten ondersteunen verschillende ontvangertypen en pools. Een geldig Zcash-adres kan toch onbruikbaar zijn in een specifieke serviceflow.
Controleer het ontvangertype, de walletondersteuning, het geselecteerde transactiepad, de weergegeven vergoeding en het bevestigingsbeleid van de ontvangende service voordat u de betaling autoriseert.
Eén ZEC is gelijk aan 100.000.000 zatoshis; de weergaveprecisie van de wallet verandert het onderliggende bedrag niet.
Basisdenominatie voor wallets
Kleinste ZEC-rekeneenheid
Zatoshis vormen de gehele rekeneenheid die software gebruikt om ZEC-bedragen en -vergoedingen weer te geven. De denominatie zelf onthult niet of waarde in een transparante of afgeschermde pool wordt aangehouden.
0,01 ZEC is gelijk aan 1.000.000 zatoshis.
De bedragsdenominatie staat los van de vraag of een overdracht gebruikmaakt van een transparante of afgeschermde pool.
Zcash-transactiekosten worden betaald in ZEC en weergegeven in zatoshis. De huidige gangbare kostenrichtlijn gebruikt het logische werk dat door een transactie wordt verricht in plaats van één universeel vast tarief voor elke overdracht.
Onder de actieve ZIP 317 conventionele kostenregel tellen wallets de logische acties die worden bijgedragen door transparante inputs en outputs en door afgeschermde spends en outputs. Een marginale vergoeding van 5.000 zatoshis wordt toegepast met twee genadeacties, waardoor een minimale conventionele transactie op 10.000 zatoshis blijft, terwijl complexere constructies meer kunnen kosten.
De constructie van afgeschermde transacties kan opvulling bevatten om informatielekken door ongebruikelijke vormen te verminderen. Die opvulling en activiteit tussen pools kunnen het aantal acties beïnvloeden, dus twee betalingen met hetzelfde ZEC-bedrag kunnen verschillende door de wallet berekende vergoedingen krijgen. De conventionele vergoeding is een richtlijn voor walletbeleid, geen claim dat consensus vereist dat elke transactie één exacte vergoeding gebruikt.
Een minimale transactie binnen de twee genadeacties heeft een conventionele vergoeding van 10.000 zatoshis, gelijk aan 0,0001 ZEC. Een transactie met meer logische acties kan een hogere aanbeveling krijgen.
Gebruik de vergoeding die wordt weergegeven door een actuele, vertrouwde wallet. Hardcode geen oudere vaste vergoedingsaanname en kies niet handmatig een ongebruikelijke vergoeding zonder de privacy- en relay-effecten ervan te begrijpen.
Een Zcash-transactie kan transparante inputs of outputs combineren met Sapling- of Orchard-afgeschermde acties. De resulterende privacy hangt af van het volledige pad dat door de wallet is geselecteerd.
Transparante activiteit stelt de openbare adressen en waarden bloot. Afschermen verplaatst waarde van een transparante bron naar een afgeschermde pool; ontschermen stelt de transparante ontvangende kant bloot; en een volledig afgeschermde overdracht beschermt de relevante afgeschermde adressen en bedragen tegen gewone publieke inspectie. Transacties tussen pools kunnen meer dan één overdrachtsprotocol bevatten, dus de wallet moet uitleggen wat beschermd is in plaats van elke transactie met een bewijs als gelijkwaardig te behandelen.
Bronnotities, ontvangende receivers, wisselgeldafhandeling en walletondersteuning bepalen welke transparante of afgeschermde componenten worden geconstrueerd.
Een zero-knowledge-bewijs valideert beschermde componenten zonder hun beschermde waarden te onthullen, maar het verbergt geen transparante componenten of metadata die buiten het protocol worden verzameld.
Zcash ondersteunt transparante, Sapling- en Orchard-receivers. Een Unified Address kan meerdere receivers coderen, zodat een verzendende wallet het best ondersteunde overdrachtsprotocol kan kiezen.
| Adrestype | Gemeenschappelijk prefix | Pool | Typisch gebruik | Compatibiliteitsopmerking |
|---|---|---|---|---|
| Transparante receiver | t1 of t3 | Transparant | Publieke overdrachten en brede legacy-integratie | Adressen en overgedragen waarden zijn openbaar |
| Sapling-receiver | zs | Sapling afgeschermde pool | Afgeschermde betalingen in compatibele wallets | Directe Sapling-ondersteuning varieert per wallet en dienst |
| Orchard-receiver | Binnen een Unified Address | Orchard afgeschermde pool | Huidige afgeschermde betalingen via compatibele wallets | Geen zelfstandige gebruikersgerichte Orchard-adrescodering |
| Unified Address | u | Receivercontainer | Eén adrescodering die ondersteunde receivertypen kan dragen | De verzendende wallet selecteert een compatibele receiver; privacy is niet gegarandeerd |
Een Unified Address is een adrescontainer, geen bewijs dat de uiteindelijke transactie afgeschermd is. De afzender decodeert de beschikbare receivers en selecteert er één die hij ondersteunt; walletbeleid en de ontvangende dienst blijven daarom deel uitmaken van het privacyresultaat. Viewing keys zijn afzonderlijke gevoelige referenties die afgeschermde activiteit kunnen onthullen voor boekhouding of selectieve openbaarmaking zonder uitgavemacht te verlenen.
Bevestig welke receiver de verzendende wallet zal gebruiken, vooral wanneer een Unified Address meer dan één optie bevat.
Een wallet of exchange kan transparante stortingen ondersteunen, maar niet Sapling, Orchard of elke Unified Address-vorm.
De eerste bevestiging registreert een transactie in een geaccepteerd blok. Extra diepte vermindert het reorganisatierisico volgens het beleid van de wallet of dienst, maar verandert niet de privacy van de transactie die al door het pad is vastgesteld.
De transactie wordt gezien door de wallet of dienst, maar is nog niet opgenomen in een geaccepteerd blok.
De transactie is opgenomen in één geaccepteerd Zcash-blok, terwijl het reorganisatierisico beleidsafhankelijk blijft.
Elk volgend geaccepteerd blok maakt een reorganisatie minder waarschijnlijk; de vereiste diepte varieert per wallet, handelaar en exchange.
De wallet kan wachten op zijn geconfigureerde bevestiging of vertrouwensvoorwaarden voordat hij de ontvangen output als besteedbaar beschouwt.
Een wallet kan een binnenkomend bedrag weergeven voordat hij die output als besteedbaar behandelt. Het onderscheid hangt af van blokopname, bevestigingsdiepte, of de wallet de bron als vertrouwd behandelt, en zijn eigen risicobeleid. Officiële walletrichtlijnen kunnen een bevestigingsdrempel aanbevelen, maar die aanbeveling is operationeel beleid in plaats van een enkele consensusregel voor elke handelaar, exchange en wallet.
Interfaces moeten een gedetecteerde betaling onderscheiden van een bevestigd, door beleid goedgekeurd saldo dat kan worden uitgegeven.
Bevestigingsdiepte adresseert het risico van terugdraaiing. Keuzes voor ontvanger en transactiepad adresseren openbaarmaking.
Het tweepadontwerp behoudt vertrouwd openbaar betalingsgedrag terwijl het sterkere on-chain vertrouwelijkheid mogelijk maakt via afgeschermde protocollen.
Transparante Zcash-activiteit gedraagt zich grotendeels als een conventionele UTXO-betaling: adressen en overgedragen waarden zijn zichtbaar op de openbare chain. Dat maakt basisinspectie, exchange-stortingen en integraties eenvoudiger voor diensten die zijn gebouwd rond openbare transactierecords. Het betekent ook dat die overdrachten niet de adres- en bedragbescherming krijgen van een volledig afgeschermd pad.
Afgeschermde pools laten nodes verifiëren dat een transactie geldig is zonder de beschermde afzender, ontvanger en bedragvelden op dezelfde manier te publiceren. Dit verandert wat een gewone chain-waarnemer kan leren, maar het wist niet het bestaan van de transactie, de vergoeding of elk spoor dat wordt gecreëerd door timing, tegenpartijen en de omringende workflow.
Het ondersteunen van beide modellen helpt Zcash om te interageren met software die verschillende mogelijkheden heeft, maar het verplaatst een belangrijke beslissing naar de wallet. De wallet moet de ontvanger herkennen, een ondersteund overdrachtsprotocol kiezen en uitleggen wanneer waarde tussen transparante en afgeschermde pools beweegt. Een vertrouwd verzendscherm is niet genoeg als het verbergt welk pad zal worden gebruikt.
Een nuttige pasvorm hangt af van opzettelijke afgeschermde ondersteuning, een werkbaar ontvangerpad en een operationeel beleid dat Zcash-specifieke compatibiliteitscontroles accepteert.
Zcash kan passen wanneer beide partijen opzettelijk een afgeschermde ontvanger ondersteunen en de afzender het pad vóór ondertekening kan verifiëren.
Let op: Bevestig de walletversie, ontvangertype, vergoeding en ondersteuning van de ontvanger; een terugval naar transparante activiteit verandert het openbaarmakingsmodel.
Bekijkingsmogelijkheden kunnen afstemming of rapportage ondersteunen zonder uitgavemacht over te dragen wanneer de workflow daarvoor is ontworpen.
Let op: Definieer wie bekijkings toegang krijgt, wat het onthult en hoe het sleutelmateriaal operationeel wordt opgeslagen en ingetrokken.
Een toepassing kan Zcash goed gebruiken wanneer het expliciet Unified Addresses, afgeschermde ontvangers, vergoedingen en bevestigingsstatussen afhandelt.
Let op: Test elke ondersteunde pool en migratiepad in plaats van aan te nemen dat generieke cryptocurrency-walletondersteuning voldoende is.
Ondersteuning voor afgeschermde ontvangers en Unified Address-componenten varieert per dienst, dus een privacybehoudend pad is mogelijk niet overal beschikbaar.
Vergelijk: Gebruik een betalingsrail die expliciet wordt ondersteund door elke vereiste tegenpartij en vergelijk vervolgens de openbaarmakingsafwegingen.
Zcash staat transparante activiteit en gemengde poolovergangen toe. Het protocol kan een niet-ondersteunde ontvanger of transparante bestemming niet omzetten in een volledig afgeschermde betaling.
Vergelijk: Evalueer privacy-by-default-ontwerpen als optionele padselectie onacceptabel is, terwijl u hun eigen compatibiliteitslimieten beoordeelt.
Deze pagina beschrijft Zcash als een betalings- en privacynetwerk, niet als vervanging voor een algemene EVM-achtige toepassingsomgeving.
Vergelijk: Evalueer een smart-contract-platform wanneer programmeerbare toepassingsstatus de centrale vereiste is.
Afgeschermde protocollen beschermen specifieke on-chain velden; ze zijn geen belofte van volledige operationele anonimiteit.
Bij een afgeschermde overdracht is het protocol ontworpen om beschermde adressen en waarden te verbergen voor gewone openbare inspectie terwijl het netwerk toch ongeldige uitgaven kan afwijzen. Transparante inputs of outputs blijven openbaar, en het verplaatsen van waarde naar of uit een afgeschermde pool kan de transparante kant van dat pad onthullen. Privacy hangt daarom af van de volledige transactie, niet simpelweg van of er een afgeschermde ontvanger in voorkomt.
Walletgedrag is belangrijk omdat de wallet noten, ontvangers, wisselgeldafhandeling en overdrachtsprotocollen kiest. Een Unified Address kan meer dan één ontvangertype bevatten, en de verzendende wallet selecteert er een die het ondersteunt. Dat verbetert compatibiliteit, maar het garandeert niet dat de uiteindelijke betaling een Orchard- of Sapling-afgeschermde ontvanger gebruikt.
Bekijkingssleutels bieden gecontroleerde leestoegang zonder uitgavemacht te verlenen. Ze kunnen boekhouding, rapportage of selectieve openbaarmaking ondersteunen wanneer de wallet en het bedrijfsproces ze correct afhandelen. Ze moeten nog steeds als gevoelige informatie worden beschermd omdat de houder transactiedetails kan leren die niet openbaar op de chain staan.
Netwerkprivacy schiet ook tekort in het verbergen van informatie die elders wordt verzameld. Een exchange, handelaar of tegenpartij kan een accountidentiteit, IP-adres, leveringsdetails of timingrelatie kennen. Meer bevestigingen kunnen het risico van terugdraaiing verminderen, maar ze verbergen geen informatie die al zichtbaar is in een transparant pad of al is gedeeld met een dienst.
Het nuttige onderscheid is niet welk netwerk universeel beter is, maar of transparantie, optionele afscherming of privacy-by-default-gedrag past bij de beoogde workflow.
| Netwerk | Transactiemodel | Adresgedrag | Consensus | Typische pasvorm | Operationele afweging |
|---|---|---|---|---|---|
| Zcash | Transparante, afgeschermde, afgeschermde en de-afgeschermde paden bestaan naast elkaar. | Transparante, Sapling- en Orchard-ontvangers kunnen worden weergegeven via compatibele adresformaten, waaronder Unified Addresses. | Bewijs van werk. | Workflows die bewust kiezen voor afgeschermde ondersteuning of selectieve openbaarmaking. | Compatibiliteit van ontvanger, pool en service moet worden gecontroleerd. |
| Bitcoin | Transactie-ingangen en -uitgangen zijn openbaar controleerbaar. | Adresformaten identificeren ondersteunde scriptbestemmingen, niet een afgeschermde pool. | Bewijs van werk. | Breed ondersteunde openbare UTXO-betalingen en -afwikkeling. | De openbare transactiegrafiek vereist afzonderlijke privacypraktijken. |
| Monero | Protocolprivacyfuncties zijn standaard van toepassing op gewone overschrijvingen. | Wallet-adressering is gebouwd rond privétransactiegedrag in plaats van optionele transparante ontvangers. | Bewijs van werk. | Gebruikers die privacygedrag willen zonder een transparant of afgeschermd pad te kiezen. | Serviceondersteuning, auditmethoden en operationele tools verschillen van transparante UTXO-systemen. |
De meeste fouten komen voort uit het behandelen van een netwerkmogelijkheid als een automatische eigenschap van elke wallet, elk adres en elke transactie.
Correctie: Zcash ondersteunt transparante en afgeschermde paden. Alleen de velden die worden beschermd door de gekozen afgeschermde overdrachtsprotocollen krijgen die on-chain vertrouwelijkheidseigenschappen.
Waarom het ertoe doet: Een transparante afzender of bestemming kan adressen en waarden blootleggen die later niet kunnen worden verborgen door te wachten op meer blokken.
Correctie: Een Unified Address is een container voor compatibele ontvangertypen. De verzendende wallet selecteert een ontvanger die het ondersteunt volgens de toepasselijke standaard en zijn mogelijkheden.
Waarom het ertoe doet: Het uiteindelijke pad kan per wallet verschillen, dus de afzender moet de weergegeven ontvanger en het privacyresultaat verifiëren.
Correctie: Bevestigingen vergroten de diepte na opname in een blok en verminderen het reorganisatierisico volgens het beleid. Ze herschrijven geen eerder bekendgemaakte transactiegegevens.
Waarom het ertoe doet: Beveiliging tegen omkering en vertrouwelijkheid zijn afzonderlijke eigenschappen en vereisen afzonderlijke controles.
Correctie: Ondersteuning varieert per product, versie en servicebeleid. Een ontvanger die geldig is onder het protocol kan nog steeds worden afgewezen door een bepaalde interface.
Waarom het ertoe doet: Verzend- of stortingsworkflows moeten worden getest vóór een tijdgevoelige of hoogwaardige overdracht.
Correctie: De huidige conventionele richtlijn voor vergoedingen houdt rekening met logische acties en omvat genadeacties. Wallets kunnen verschillende conventionele vergoedingen berekenen voor anders geconstrueerde transacties.
Waarom het ertoe doet: Het hardcoderen van een oud vast bedrag kan de door de wallet geselecteerde vergoeding onderschatten en kan ongebruikelijk vergoedingsgedrag veroorzaken.
Correctie: Afgeschermde protocollen beschermen gedefinieerde on-chain velden, niet informatie die wordt verzameld door apparaten, netwerken, exchanges, handelaren of tegenpartijen.
Waarom het ertoe doet: Operationele privacy hangt nog steeds af van walletverbindingen, accountidentiteit, timing en wat buiten de keten wordt gedeeld.
De praktische controles verschillen voor iemand die één betaling doet, een walletteam, een dienst die stortingen accepteert of een organisatie die selectieve openbaarmaking gebruikt.
Voordat u verzendt, identificeer of de bestemming transparant, Sapling, Orchard of een Unified Address is en lees de wallet-preview voor het daadwerkelijke overdrachtspad. Een ZEC-saldo alleen zegt niets over ontvangerondersteuning of wat de transactie zal onthullen.
Een wallet moet huidige adresformaten parseren, ontvangers correct selecteren, de huidige conventionele vergoeding berekenen en onderscheid maken tussen ontvangen en besteedbare saldi. Foutmeldingen moeten niet-ondersteunde paden uitleggen in plaats van stil terug te vallen.
Diensten moeten vermelden welke ontvangertypen ze accepteren, of ze geld kunnen terugstorten naar een shielded bestemming en hoeveel bevestigingen hun eigen risicobeleid vereist. Stortingsoperaties hebben ook een herstelpad nodig voor niet-ondersteunde adressen of vertraagde besteedbaarheid.
Selectieve openbaarmaking kan afstemming of rapportage ondersteunen zonder uitgavemachtiging te verlenen, maar het viewing-materiaal kan beschermde activiteit onthullen aan de houder ervan. Toegang, opslag, overdracht en incidentprocedures moeten worden gedefinieerd voordat het wordt gedeeld.
De snapshot is CoinGecko geaggregeerde ZEC/USD gegevens. De grafiek is Binance Spot ZEC/USDT gegevens. USD en USDT zijn verschillende quote-activa, dus weergegeven waarden kunnen verschillen.
Primaire technische standaarden die worden gebruikt om de transactie-, ontvanger-, vergoeding- en wallet-uitleg op deze pagina te beoordelen.
Aanvullende operationele vragen die niet worden beantwoord door de hoofdtransactie- en ontvangersecties.
Bekijkingssleutels kunnen leestoegang bieden tot ondersteunde shielded-activiteit zonder de mogelijkheid om uit te geven. De organisatie heeft nog steeds een beleid nodig voor toegang, opslag en de exacte openbaarmakingsomvang.
Een wallet kan een inkomende transactie detecteren voordat deze de bevestigingsdiepte of het vertrouwensbeleid bereikt dat vereist is voor uitgaven. De interface moet onderscheid maken tussen gedetecteerde, bevestigde en uitgevenbare saldi.
Het hangt af van de inhoud van de Unified Address en de verzendende wallet. De wallet kan een ondersteunde transparante receiver selecteren wanneer deze aanwezig is, maar de afzender moet het weergegeven pad verifiëren omdat die keuze verandert wat openbaar is.
Geverifieerde technische inhoud, beoordeelde bronnen en updategeschiedenis.