Zcash é uma rede de criptomoeda proof-of-work, e ZEC é seu ativo nativo. Ela suporta atividade transparente e transferências protegidas que podem ocultar detalhes selecionados de transações quando carteiras e pools de endereços compatíveis são usados.
Use esta página para avaliar se Zcash atende a uma necessidade de pagamento ou privacidade, depois revise a compatibilidade do receptor, o comportamento atual de taxas, a política de confirmação e os limites da atividade protegida.
Esta página é uma referência educacional de rede e mercado. Ela não garante privacidade de transações, compatibilidade de carteiras, suporte de exchanges ou resultados de investimento.
ZEC/USDT · Binance Spot · UTC
Intervalos longos usam automaticamente um intervalo de vela compatível.
Velas históricas do Binance Spot estão disponíveis. JavaScript é necessário para atualizações da vela atual.
| Hora (UTC) | Abertura (USDT) | Máxima (USDT) | Mínima (USDT) | Fechamento (USDT) | Volume (ZEC) |
|---|---|---|---|---|---|
| 25 de ago. de 2026 18:00:00 UTC | 799,42 USDT | 801,84 USDT | 792,02 USDT | 798,12 USDT | 6.005,88 ZEC |
| 25 de ago. de 2026 17:00:00 UTC | 799,91 USDT | 805,11 USDT | 793,39 USDT | 799,42 USDT | 9.846,01 ZEC |
| 25 de ago. de 2026 16:00:00 UTC | 816,81 USDT | 823,77 USDT | 795,14 USDT | 799,90 USDT | 14.865,53 ZEC |
| 25 de ago de 2026 15:00:00 UTC | 818,71 USDT | 818,80 USDT | 803,35 USDT | 816,90 USDT | 14.268,89 ZEC |
| 25 de ago. de 2026 14:00:00 UTC | 818,33 USDT | 831,36 USDT | 814,00 USDT | 818,71 USDT | 12.027,36 ZEC |
Dados de mercado: Binance Spot ZEC/USDT
Biblioteca de gráficos: TradingView Lightweight Charts
Zcash suporta fluxos de transação transparentes e protegidos.
Um protocolo com capacidade de proteção não torna toda transação ZEC privada.
Zcash é útil apenas quando a carteira escolhida, o receptor e o caminho de transação suportam a privacidade e a compatibilidade que você realmente precisa.
Transferências protegidas opcionais, pagamentos com consciência de privacidade ou divulgação seletiva são relevantes, e todos os participantes usam software Zcash compatível.
Possuir ZEC ou usar a rede Zcash não oculta automaticamente uma transferência. O pool de origem, o receptor de destino e o caminho construído pela carteira determinam o que é protegido.
Carteiras, exchanges e serviços de pagamento suportam diferentes tipos de receptor e pools. Um endereço Zcash válido ainda pode ser inutilizável em um fluxo de serviço específico.
Verifique o tipo de receptor, o suporte da carteira, o caminho de transação selecionado, a taxa exibida e a política de confirmação do serviço do destinatário antes de autorizar o pagamento.
Um ZEC equivale a 100.000.000 zatoshis; a precisão de exibição da carteira não altera o valor subjacente.
Denominação base voltada para carteira
Menor unidade de contabilidade ZEC
Zatoshis fornecem a unidade de contabilidade inteira usada quando o software representa valores e taxas em ZEC. A denominação em si não revela se o valor é mantido em um pool transparente ou protegido.
0,01 ZEC equivale a 1.000.000 zatoshis.
A denominação do valor é separada de se uma transferência usa um pool transparente ou protegido.
As taxas de transação da Zcash são pagas em ZEC e representadas em zatoshis. A orientação convencional atual de taxas usa o trabalho lógico realizado por uma transação em vez de uma taxa fixa universal para cada transferência.
Sob a regra de taxa convencional ativa ZIP 317, as carteiras contam ações lógicas contribuídas por entradas e saídas transparentes e por gastos e saídas protegidos. Uma taxa marginal de 5.000 zatoshis é aplicada com duas ações de graça, o que mantém uma transação convencional mínima em 10.000 zatoshis, permitindo que construções mais complexas custem mais.
A construção de transações protegidas pode incluir preenchimento para reduzir o vazamento de informações de formas incomuns. Esse preenchimento e a atividade entre pools podem afetar a contagem de ações, então dois pagamentos com o mesmo valor em ZEC podem receber taxas calculadas pela carteira diferentes. A taxa convencional é uma orientação de política da carteira, não uma afirmação de que o consenso exige que cada transação use uma taxa exata.
Uma transação mínima dentro das duas ações de graça tem uma taxa convencional de 10.000 zatoshis, igual a 0,0001 ZEC. Uma transação com mais ações lógicas pode ter uma recomendação mais alta.
Use a taxa mostrada por uma carteira atual e confiável. Não codifique uma suposição de taxa fixa antiga ou escolha manualmente uma taxa incomum sem entender seus efeitos de privacidade e retransmissão.
Uma transação Zcash pode combinar entradas ou saídas transparentes com ações protegidas Sapling ou Orchard. A privacidade resultante depende do caminho completo selecionado pela carteira.
Atividade transparente expõe seus endereços públicos e valores. A proteção move valor de uma fonte transparente para um pool protegido; a desproteção expõe o lado de destino transparente; e uma transferência totalmente protegida protege os endereços protegidos relevantes e campos de valor da inspeção pública comum. Transações entre pools podem incluir mais de um protocolo de transferência, então a carteira deve explicar o que é protegido em vez de tratar cada transação com prova como equivalente.
Notas de origem, receptores de destino, tratamento de troco e suporte da carteira determinam quais componentes transparentes ou protegidos são construídos.
Uma prova de conhecimento zero valida componentes protegidos sem revelar seus valores protegidos, mas não esconde componentes transparentes ou metadados coletados fora do protocolo.
A Zcash suporta receptores transparentes, Sapling e Orchard. Um Endereço Unificado pode codificar vários receptores para que uma carteira remetente possa escolher o melhor protocolo de transferência suportado.
| Tipo de Endereço | Prefixo Comum | Pool | Uso Típico | Nota de Compatibilidade |
|---|---|---|---|---|
| Receptor transparente | t1 ou t3 | Transparente | Transferências públicas e integração ampla com legado | Endereços e valores transferidos são públicos |
| Receptor Sapling | zs | Pool protegido Sapling | Pagamentos protegidos em carteiras compatíveis | Suporte direto a Sapling varia conforme carteira e serviço |
| Receptor Orchard | Dentro de um Endereço Unificado | Pool protegido Orchard | Pagamentos protegidos atuais através de carteiras compatíveis | Sem codificação de endereço Orchard autônoma para o usuário |
| Endereço Unificado | u | Contêiner de receptores | Uma codificação de endereço que pode carregar tipos de receptores suportados | A carteira remetente seleciona um receptor compatível; a privacidade não é garantida |
Um Endereço Unificado é um contêiner de endereço, não uma prova de que a transação final é protegida. O remetente decodifica os receptores disponíveis e seleciona um que suporte; a política da carteira e o serviço do destinatário, portanto, permanecem parte do resultado de privacidade. Chaves de visualização são credenciais sensíveis separadas que podem revelar atividade protegida para contabilidade ou divulgação seletiva sem conceder autoridade de gasto.
Confirme qual receptor a carteira remetente usará, especialmente quando um Endereço Unificado incluir mais de uma opção.
Uma carteira ou exchange pode suportar depósitos transparentes, mas não Sapling, Orchard ou todas as formas de Endereço Unificado.
A primeira confirmação registra uma transação em um bloco aceito. Profundidade adicional reduz o risco de reorganização de acordo com a política da carteira ou serviço, mas não altera a privacidade da transação já estabelecida pelo seu caminho.
A transação é vista pela carteira ou serviço, mas ainda não está incluída em um bloco aceito.
A transação é incluída em um bloco Zcash aceito, enquanto o risco de reorganização permanece dependente da política.
Cada bloco aceito posterior torna uma reorganização menos provável; a profundidade exigida varia conforme carteira, comerciante e exchange.
A carteira pode aguardar suas condições de confirmação ou confiança configuradas antes de permitir que a saída recebida seja gasta.
Uma carteira pode exibir um valor recebido antes de tratar essa saída como gastável. A distinção depende da inclusão no bloco, da profundidade de confirmação, se a carteira trata a fonte como confiável e de sua própria política de risco. A orientação oficial da carteira pode recomendar um limite de confirmação, mas essa recomendação é política operacional, não uma regra de consenso única para cada comerciante, exchange e carteira.
As interfaces devem distinguir um pagamento detectado de um saldo confirmado e aprovado pela política que pode ser gasto.
A profundidade de confirmação aborda o risco de reversão. As escolhas de receptor e caminho de transação abordam a divulgação.
O design de dois caminhos preserva o comportamento familiar de pagamento público, ao mesmo tempo que torna disponível confidencialidade on-chain mais forte através de protocolos protegidos.
A atividade transparente do Zcash se comporta muito como um pagamento convencional UTXO: endereços e valores transferidos são visíveis na cadeia pública. Isso torna inspeção básica, depósitos em exchanges e integrações mais fáceis para serviços construídos em torno de registros públicos de transações. Também significa que essas transferências não recebem as proteções de endereço e valor de um caminho totalmente protegido.
Os pools protegidos permitem que os nós verifiquem que uma transação é válida sem publicar os campos protegidos de remetente, destinatário e valor da mesma forma. Isso muda o que um observador comum da cadeia pode aprender, mas não apaga a existência da transação, sua taxa ou cada pista criada pelo tempo, contrapartes e o fluxo de trabalho ao redor.
Suportar ambos os modelos ajuda a Zcash a interagir com software que tem capacidades diferentes, mas move uma decisão importante para a carteira. A carteira deve reconhecer o destinatário, escolher um protocolo de transferência suportado e explicar quando o valor cruza entre pools transparentes e protegidos. Uma tela de envio familiar não é suficiente se ela esconde qual caminho será usado.
Um encaixe útil depende de suporte deliberado a pools protegidos, um caminho de destinatário viável e uma política operacional que aceite verificações de compatibilidade específicas da Zcash.
A Zcash pode se encaixar quando ambos os lados suportam deliberadamente um destinatário protegido e o remetente pode verificar o caminho antes de assinar.
Atenção para: Confirme a versão da carteira, o tipo de destinatário, a taxa e o suporte do destinatário; um fallback para atividade transparente muda o modelo de divulgação.
As capacidades de visualização podem suportar conciliação ou relatórios sem entregar autoridade de gasto quando o fluxo de trabalho é projetado para esse propósito.
Atenção para: Defina quem recebe acesso de visualização, o que isso revela e como o material da chave é armazenado e revogado operacionalmente.
Uma aplicação pode usar bem a Zcash quando ela lida explicitamente com Endereços Unificados, destinatários protegidos, taxas e estados de confirmação.
Atenção para: Teste cada pool suportado e caminho de migração em vez de assumir que o suporte genérico de carteira de criptomoeda é suficiente.
O suporte para destinatários protegidos e componentes de Endereço Unificado varia entre serviços, então um caminho que preserva a privacidade pode não estar disponível em todos os lugares.
Comparar: Use um trilho de pagamento explicitamente suportado por cada contraparte necessária e depois compare suas compensações de divulgação.
A Zcash permite atividade transparente e transições mistas entre pools. O protocolo não pode transformar um destinatário não suportado ou destino transparente em um pagamento totalmente protegido.
Comparar: Avalie designs de privacidade por padrão se a seleção opcional de caminho for inaceitável, revisando seus próprios limites de compatibilidade.
Esta página descreve a Zcash como uma rede de pagamento e privacidade, não como um substituto para um ambiente de aplicação estilo EVM geral.
Comparar: Avalie uma plataforma de contratos inteligentes quando o estado de aplicação programável é o requisito central.
Os protocolos protegidos protegem campos específicos na cadeia; eles não são uma promessa de anonimato operacional completo.
Em uma transferência protegida, o protocolo é projetado para manter endereços e valores protegidos longe da inspeção pública comum, enquanto ainda permite que a rede rejeite gastos inválidos. Entradas ou saídas transparentes permanecem públicas, e mover valor para dentro ou para fora de um pool protegido pode revelar o lado transparente desse caminho. A privacidade, portanto, depende da transação completa, não simplesmente de se um destinatário protegido aparece nela.
O comportamento da carteira importa porque a carteira escolhe notas, destinatários, tratamento de troco e protocolos de transferência. Um Endereço Unificado pode conter mais de um tipo de destinatário, e a carteira remetente seleciona um que ela suporta. Isso melhora a compatibilidade, mas não garante que o pagamento final use um destinatário protegido Orchard ou Sapling.
As chaves de visualização fornecem acesso de leitura controlado sem conceder autoridade de gasto. Elas podem suportar contabilidade, relatórios ou divulgação seletiva quando a carteira e o processo de negócios as tratam corretamente. Elas ainda devem ser protegidas como informação sensível porque o detentor pode aprender detalhes de transação que não são públicos na cadeia.
A privacidade da rede também não esconde informações coletadas em outros lugares. Uma exchange, comerciante ou contraparte pode saber uma identidade de conta, endereço IP, detalhes de entrega ou relação de tempo. Mais confirmações podem reduzir o risco de reversão, mas não ocultam informações já visíveis em um caminho transparente ou já compartilhadas com um serviço.
A distinção útil não é qual rede é universalmente melhor, mas se transparência, proteção opcional ou comportamento de privacidade por padrão corresponde ao fluxo de trabalho pretendido.
| Rede | Modelo de transação | Comportamento de endereço | Consenso | Encaixe típico | Compensação operacional |
|---|---|---|---|---|---|
| Zcash | Caminhos transparentes, de proteção, protegidos e de desproteção coexistem. | Destinatários transparentes, Sapling e Orchard podem ser representados através de formatos de endereço compatíveis, incluindo Endereços Unificados. | Prova de Trabalho. | Fluxos de trabalho que deliberadamente escolhem suporte protegido ou divulgação seletiva. | A compatibilidade do receptor, do pool e do serviço deve ser verificada. |
| Bitcoin | As entradas e saídas de transações são publicamente inspecionáveis. | Os formatos de endereço identificam destinos de script suportados, não um pool protegido. | Prova de Trabalho. | Pagamentos e liquidação públicos amplamente suportados UTXO. | O gráfico de transações públicas requer práticas de privacidade separadas. |
| Monero | Os recursos de privacidade do protocolo se aplicam a transferências comuns por padrão. | A endereçamento da carteira é construído em torno do comportamento de transação privada, em vez de receptores transparentes opcionais. | Prova de Trabalho. | Usuários que desejam comportamento de privacidade sem escolher um caminho transparente ou protegido. | O suporte do serviço, os métodos de auditoria e as ferramentas operacionais diferem dos sistemas transparentes UTXO. |
A maioria dos erros vem de tratar um recurso de rede como uma propriedade automática de cada carteira, endereço e transação.
Correção: Zcash suporta caminhos transparentes e protegidos. Somente os campos protegidos pelos protocolos de transferência protegida escolhidos recebem essas propriedades de confidencialidade on-chain.
Por que isso importa: Um remetente ou destino transparente pode expor endereços e valores que não podem ser ocultados posteriormente esperando por mais blocos.
Correção: Um Endereço Unificado é um contêiner para tipos de receptor compatíveis. A carteira remetente seleciona um receptor que ela suporta de acordo com o padrão aplicável e suas capacidades.
Por que isso importa: O caminho final pode diferir entre carteiras, portanto, o remetente deve verificar o receptor exibido e o resultado de privacidade.
Correção: As confirmações aumentam a profundidade após a inclusão do bloco e reduzem o risco de reorganização de acordo com a política. Elas não reescrevem dados de transação previamente divulgados.
Por que isso importa: Segurança contra reversão e confidencialidade são propriedades separadas e precisam de verificações separadas.
Correção: O suporte varia por produto, versão e política de serviço. Um receptor válido sob o protocolo pode ainda ser rejeitado por uma interface específica.
Por que isso importa: Os fluxos de envio ou depósito devem ser testados antes de uma transferência sensível ao tempo ou de alto valor.
Correção: A orientação convencional de taxas atual leva em conta ações lógicas e inclui ações de graça. As carteiras podem calcular taxas convencionais diferentes para transações construídas de forma diferente.
Por que isso importa: Codificar um valor fixo antigo pode subestimar a taxa selecionada pela carteira e pode criar comportamento de taxa incomum.
Correção: Os protocolos protegidos protegem campos on-chain definidos, não informações coletadas por dispositivos, redes, exchanges, comerciantes ou contrapartes.
Por que isso importa: A privacidade operacional ainda depende de conexões de carteira, identidade de conta, tempo e o que é compartilhado fora da cadeia.
As verificações práticas diferem para alguém fazendo um pagamento, uma equipe de carteira, um serviço aceitando depósitos ou uma organização usando divulgação seletiva.
Antes de enviar, identifique se o destino é transparente, Sapling, Orchard ou um Endereço Unificado e leia a pré-visualização da carteira para o caminho de transferência real. Um saldo ZEC sozinho não diz nada sobre o suporte do receptor ou o que a transação revelará.
Uma carteira deve analisar os formatos de endereço atuais, selecionar os destinatários corretamente, calcular a taxa convencional atual e distinguir saldos recebidos de saldos gastáveis. Mensagens de erro devem explicar caminhos não suportados em vez de cair silenciosamente em fallback.
Os serviços devem declarar quais tipos de destinatário aceitam, se podem devolver fundos para um destino blindado e quantas confirmações sua própria política de risco exige. Operações de depósito também precisam de um caminho de recuperação para endereços não suportados ou gastabilidade atrasada.
A divulgação seletiva pode apoiar a conciliação ou relatórios sem conceder autoridade de gasto, mas o material de visualização pode revelar atividade protegida ao seu detentor. Procedimentos de acesso, armazenamento, transferência e incidentes devem ser definidos antes de ser compartilhado.
O snapshot são dados agregados CoinGecko ZEC/USD. O gráfico são dados Binance Spot ZEC/USDT. USD e USDT são ativos de cotação diferentes, então os valores exibidos podem diferir.
Padrões técnicos primários usados para revisar as explicações de transação, destinatário, taxa e carteira nesta página.
Perguntas operacionais adicionais não respondidas pelas seções principais de transação e destinatário.
As chaves de visualização podem fornecer acesso de leitura à atividade protegida suportada sem conceder a capacidade de gastar. A organização ainda precisa de uma política para acesso, armazenamento e o escopo exato de divulgação.
Uma carteira pode detectar uma transação recebida antes que ela atinja a profundidade de confirmação ou a política de confiança necessária para gastos. A interface deve distinguir saldos detectados, confirmados e disponíveis para gasto.
Depende do conteúdo do Unified Address e da carteira de envio. A carteira pode selecionar um receiver transparente suportado quando um estiver presente, mas o remetente deve verificar o caminho exibido porque essa escolha altera o que é público.
Conteúdo técnico verificado, fontes revisadas e histórico de atualizações.