Zcash es una red de criptomonedas de prueba de trabajo, y ZEC es su activo nativo. Admite actividad transparente y transferencias blindadas que pueden ocultar detalles seleccionados de la transacción cuando se utilizan carteras y grupos de direcciones compatibles.
Use esta página para evaluar si Zcash se ajusta a una necesidad de pago o privacidad, luego revise la compatibilidad del receptor, el comportamiento actual de tarifas, la política de confirmación y los límites de la actividad blindada.
Esta página es una referencia educativa de red y mercado. No garantiza la privacidad de las transacciones, la compatibilidad de carteras, el soporte de intercambio ni los resultados de inversión.
ZEC/USDT · Binance Spot · UTC
Los rangos largos usan automáticamente un intervalo de velas compatible.
Las velas históricas de Binance Spot están disponibles. Se requiere JavaScript para las actualizaciones de la vela actual.
| Hora (UTC) | Apertura (USDT) | Máximo (USDT) | Mínimo (USDT) | Cierre (USDT) | Volumen (ZEC) |
|---|---|---|---|---|---|
| 25 ago 2026 17:00:00 UTC | 799.91 USDT | 805.11 USDT | 793.39 USDT | 796.27 USDT | 6,814.49 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 |
| 25 ago 2026 13:00:00 UTC | 842.87 USDT | 844.64 USDT | 807.20 USDT | 818.26 USDT | 24,671.78 ZEC |
Datos de mercado: Binance Spot ZEC/USDT
Biblioteca de gráficos: TradingView Lightweight Charts
Zcash admite flujos de transacciones transparentes y blindados.
Un protocolo con capacidad de blindaje no hace que cada transacción ZEC sea privada.
Zcash es útil solo cuando la billetera, el receptor y la ruta de transacción elegidos admiten la privacidad y compatibilidad que realmente necesitas.
Son relevantes las transferencias blindadas opcionales, los pagos con conciencia de privacidad o la divulgación selectiva, y cada participante utiliza software Zcash compatible.
Poseer ZEC o usar la red Zcash no oculta automáticamente una transferencia. El pool de origen, el receptor de destino y la ruta construida por la billetera determinan qué está protegido.
Las billeteras, los exchanges y los servicios de pago admiten diferentes tipos de receptores y pools. Una dirección Zcash válida puede seguir siendo inutilizable en un flujo de servicio particular.
Verifica el tipo de receptor, el soporte de la billetera, la ruta de transacción seleccionada, la tarifa mostrada y la política de confirmación del servicio receptor antes de autorizar el pago.
Un ZEC equivale a 100,000,000 zatoshis; la precisión de visualización de la billetera no cambia la cantidad subyacente.
Denominación base orientada a carteras
Unidad contable más pequeña de ZEC
Los zatoshis proporcionan la unidad contable entera utilizada cuando el software representa cantidades y tarifas de ZEC. La denominación en sí no revela si el valor se mantiene en un pool transparente o blindado.
0.01 ZEC equivale a 1,000,000 zatoshis.
La denominación de la cantidad es independiente de si una transferencia utiliza un pool transparente o blindado.
Las tarifas de transacción de Zcash se pagan en ZEC y se representan en zatoshis. La guía de tarifas convencional actual utiliza el trabajo lógico realizado por una transacción en lugar de una tarifa plana universal para cada transferencia.
Bajo la regla de tarifa convencional ZIP 317 activa, las billeteras cuentan las acciones lógicas contribuidas por entradas y salidas transparentes y por gastos y salidas blindados. Se aplica una tarifa marginal de 5,000 zatoshis con dos acciones de gracia, lo que mantiene una transacción convencional mínima en 10,000 zatoshis mientras permite que construcciones más complejas cuesten más.
La construcción de transacciones blindadas puede incluir relleno para reducir la fuga de información de formas inusuales. Ese relleno y la actividad entre pools pueden afectar el recuento de acciones, por lo que dos pagos con la misma cantidad de ZEC pueden recibir tarifas calculadas por la billetera diferentes. La tarifa convencional es una guía de política de la billetera, no una afirmación de que el consenso requiera que cada transacción use una tarifa exacta.
Una transacción mínima dentro de las dos acciones de gracia tiene una tarifa convencional de 10,000 zatoshis, igual a 0.0001 ZEC. Una transacción con más acciones lógicas puede tener una recomendación más alta.
Usa la tarifa mostrada por una billetera actual y confiable. No codifiques una suposición de tarifa plana más antigua ni elijas manualmente una tarifa inusual sin comprender sus efectos de privacidad y retransmisión.
Una transacción de Zcash puede combinar entradas o salidas transparentes con acciones blindadas Sapling u Orchard. La privacidad resultante depende de la ruta completa seleccionada por la billetera.
La actividad transparente expone sus direcciones y valores públicos. El blindaje mueve valor desde una fuente transparente a un pool blindado; el desblindaje expone el lado de destino transparente; y una transferencia totalmente blindada protege las direcciones blindadas relevantes y los campos de cantidad de la inspección pública ordinaria. Las transacciones entre pools pueden incluir más de un protocolo de transferencia, por lo que la billetera debe explicar qué está protegido en lugar de tratar cada transacción con prueba como equivalente.
Las notas de origen, los receptores de destino, el manejo del cambio y el soporte de la billetera determinan qué componentes transparentes o blindados se construyen.
Una prueba de conocimiento cero valida los componentes protegidos sin revelar sus valores protegidos, pero no oculta los componentes transparentes ni los metadatos recopilados fuera del protocolo.
Zcash admite receptores transparentes, Sapling y Orchard. Una dirección unificada puede codificar múltiples receptores para que una billetera emisora pueda elegir el mejor protocolo de transferencia compatible.
| Tipo de dirección | Prefijo común | Pool | Uso típico | Nota de compatibilidad |
|---|---|---|---|---|
| Receptor transparente | t1 o t3 | Transparente | Transferencias públicas e integración heredada amplia | Las direcciones y los valores transferidos son públicos |
| Receptor Sapling | zs | Pool blindado Sapling | Pagos blindados en billeteras compatibles | El soporte directo de Sapling varía según la billetera y el servicio |
| Receptor Orchard | Dentro de una Dirección Unificada | Pool blindado Orchard | Pagos blindados actuales a través de billeteras compatibles | No hay codificación de dirección Orchard independiente para el usuario |
| Dirección unificada | u | Contenedor de receptores | Una codificación de dirección que puede llevar tipos de receptor compatibles | La billetera emisora selecciona un receptor compatible; la privacidad no está garantizada |
Una dirección unificada es un contenedor de direcciones, no una prueba de que la transacción final esté blindada. El remitente decodifica los receptores disponibles y selecciona uno que soporte; la política de la billetera y el servicio receptor siguen siendo parte del resultado de privacidad. Las claves de visualización son credenciales sensibles separadas que pueden revelar actividad blindada para contabilidad o divulgación selectiva sin otorgar autoridad de gasto.
Confirma qué receptor utilizará la billetera emisora, especialmente cuando una Dirección Unificada incluye más de una opción.
Una billetera o exchange puede admitir depósitos transparentes pero no Sapling, Orchard o cada forma de Dirección Unificada.
La primera confirmación registra una transacción en un bloque aceptado. La profundidad adicional reduce el riesgo de reorganización según la política de la billetera o servicio, pero no cambia la privacidad de la transacción ya establecida por su ruta.
La transacción es vista por la billetera o servicio pero aún no está incluida en un bloque aceptado.
La transacción está incluida en un bloque Zcash aceptado, mientras que el riesgo de reorganización sigue dependiendo de la política.
Cada bloque aceptado posterior hace menos probable una reorganización; la profundidad requerida varía según la billetera, comerciante y exchange.
La billetera puede esperar su confirmación configurada o condiciones de confianza antes de permitir que la salida recibida se gaste.
Una billetera puede mostrar un monto entrante antes de tratar esa salida como disponible para gastar. La distinción depende de la inclusión en bloque, la profundidad de confirmación, si la billetera trata la fuente como confiable y su propia política de riesgo. La guía oficial de la billetera puede recomendar un umbral de confirmación, pero esa recomendación es política operativa más que una regla de consenso única para cada comerciante, exchange y billetera.
Las interfaces deben distinguir un pago detectado de un saldo confirmado y aprobado por política que se puede gastar.
La profundidad de confirmación aborda el riesgo de reversión. Las elecciones de receptor y ruta de transacción abordan la divulgación.
El diseño de dos rutas preserva el comportamiento de pago público familiar mientras hace disponible una confidencialidad en cadena más fuerte a través de protocolos blindados.
La actividad transparente de Zcash se comporta en gran medida como un pago UTXO convencional: las direcciones y los valores transferidos son visibles en la cadena pública. Esto hace que la inspección básica, los depósitos de exchange y las integraciones sean más fáciles para servicios construidos en torno a registros de transacciones públicas. También significa que esas transferencias no reciben las protecciones de dirección y monto de una ruta totalmente blindada.
Los pools blindados permiten a los nodos verificar que una transacción es válida sin publicar los campos protegidos de remitente, receptor y monto de la misma manera. Esto cambia lo que un observador ordinario de la cadena puede aprender, pero no borra la existencia de la transacción, su tarifa o cada pista creada por el tiempo, las contrapartes y el flujo de trabajo circundante.
Admitir ambos modelos ayuda a Zcash a interactuar con software que tiene diferentes capacidades, pero mueve una decisión importante a la billetera. La billetera debe reconocer el receptor, elegir un protocolo de transferencia compatible y explicar cuándo el valor cruza entre pools transparentes y blindados. Una pantalla de envío familiar no es suficiente si oculta qué ruta se usará.
Un ajuste útil depende de un soporte blindado deliberado, una ruta de receptor viable y una política operativa que acepte comprobaciones de compatibilidad específicas de Zcash.
Zcash puede encajar cuando ambos lados admiten deliberadamente un receptor blindado y el remitente puede verificar la ruta antes de firmar.
Tenga en cuenta: Confirme la versión de la billetera, el tipo de receptor, la tarifa y el soporte del destinatario; una alternativa a la actividad transparente cambia el modelo de divulgación.
Las capacidades de visualización pueden apoyar la conciliación o informes sin ceder la autoridad de gasto cuando el flujo de trabajo está diseñado para ese propósito.
Tenga en cuenta: Defina quién recibe acceso de visualización, qué revela y cómo se almacena y revoca el material de clave operativamente.
Una aplicación puede usar Zcash bien cuando maneja explícitamente Direcciones Unificadas, receptores blindados, tarifas y estados de confirmación.
Tenga en cuenta: Pruebe cada pool y ruta de migración compatible en lugar de asumir que el soporte genérico de billetera de criptomonedas es suficiente.
El soporte para receptores blindados y componentes de Dirección Unificada varía entre servicios, por lo que una ruta que preserva la privacidad puede no estar disponible en todas partes.
Comparar: Use un rail de pago explícitamente soportado por cada contraparte requerida, luego compare sus compensaciones de divulgación.
Zcash permite actividad transparente y transiciones de pool mixto. El protocolo no puede convertir un receptor no compatible o un destino transparente en un pago totalmente blindado.
Comparar: Evalúe diseños de privacidad por defecto si la selección opcional de ruta es inaceptable, revisando sus propios límites de compatibilidad.
Esta página describe Zcash como una red de pagos y privacidad, no como un sustituto de un entorno de aplicación general estilo EVM.
Comparar: Evalúe una plataforma de contratos inteligentes cuando el estado de aplicación programable sea el requisito central.
Los protocolos blindados protegen campos específicos en cadena; no son una promesa de anonimato operativo completo.
En una transferencia blindada, el protocolo está diseñado para mantener direcciones y valores protegidos fuera de la inspección pública ordinaria, mientras permite que la red rechace gastos inválidos. Las entradas o salidas transparentes permanecen públicas, y mover valor hacia o desde un pool blindado puede revelar el lado transparente de esa ruta. La privacidad depende por lo tanto de la transacción completa, no simplemente de si aparece un receptor blindado en ella.
El comportamiento de la billetera importa porque la billetera elige notas, receptores, manejo de cambio y protocolos de transferencia. Una Dirección Unificada puede contener más de un tipo de receptor, y la billetera emisora selecciona uno que soporte. Esto mejora la compatibilidad, pero no garantiza que el pago final use un receptor blindado Orchard o Sapling.
Las claves de visualización proporcionan acceso de lectura controlado sin otorgar autoridad de gasto. Pueden apoyar contabilidad, informes o divulgación selectiva cuando la billetera y el proceso de negocio las manejan correctamente. Aún deben protegerse como información sensible porque el titular puede aprender detalles de transacción que no son públicos en la cadena.
La privacidad de la red también se queda corta para ocultar información recopilada en otros lugares. Un intercambio, comerciante o contraparte puede conocer una identidad de cuenta, dirección IP, detalles de entrega o relación de tiempo. Más confirmaciones pueden reducir el riesgo de reversión, pero no ocultan información ya visible en una ruta transparente o ya compartida con un servicio.
La distinción útil no es qué red es universalmente mejor, sino si la transparencia, el blindaje opcional o el comportamiento de privacidad por defecto coinciden con el flujo de trabajo previsto.
| Red | Modelo de transacción | Comportamiento de direcciones | Consenso | Ajuste típico | Compensación operativa |
|---|---|---|---|---|---|
| Zcash | Las rutas transparentes, blindadas, de blindaje y de desblindaje coexisten. | Los receptores transparentes, Sapling y Orchard pueden representarse mediante formatos de dirección compatibles, incluidas las Direcciones Unificadas. | Prueba de trabajo. | Flujos de trabajo que eligen deliberadamente soporte blindado o divulgación selectiva. | Se debe verificar la compatibilidad de receptor, pool y servicio. |
| Bitcoin | Las entradas y salidas de transacción son públicamente inspeccionables. | Los formatos de dirección identifican destinos de script compatibles, no un pool blindado. | Prueba de trabajo. | Pagos y liquidación pública UTXO ampliamente soportados. | El gráfico de transacción pública requiere prácticas de privacidad separadas. |
| Monero | Las características de privacidad del protocolo se aplican a transferencias ordinarias por defecto. | El direccionamiento de la billetera se basa en el comportamiento de transacción privada en lugar de receptores transparentes opcionales. | Prueba de trabajo. | Usuarios que quieren comportamiento de privacidad sin elegir una ruta transparente o blindada. | El soporte de servicios, los métodos de auditoría y las herramientas operativas difieren de los sistemas transparentes UTXO. |
La mayoría de los errores provienen de tratar una capacidad de red como una propiedad automática de cada billetera, dirección y transacción.
Corrección: Zcash soporta rutas transparentes y blindadas. Solo los campos protegidos por los protocolos de transferencia blindada elegidos reciben esas propiedades de confidencialidad en cadena.
Por qué importa: Un remitente o destino transparente puede exponer direcciones y valores que no pueden ocultarse después esperando más bloques.
Corrección: Una Dirección Unificada es un contenedor para tipos de receptor compatibles. La billetera emisora selecciona un receptor que soporte según el estándar aplicable y sus capacidades.
Por qué importa: La ruta final puede diferir entre billeteras, por lo que el remitente debe verificar el receptor mostrado y el resultado de privacidad.
Corrección: Las confirmaciones aumentan la profundidad después de la inclusión del bloque y reducen el riesgo de reorganización según la política. No reescriben datos de transacciones previamente divulgados.
Por qué importa: La seguridad contra la reversión y la confidencialidad son propiedades separadas y requieren verificaciones separadas.
Corrección: El soporte varía según el producto, la versión y la política de servicio. Un receptor válido según el protocolo puede ser rechazado por una interfaz particular.
Por qué importa: Los flujos de envío o depósito deben probarse antes de una transferencia sensible al tiempo o de alto valor.
Corrección: La guía de tarifas convencional actual tiene en cuenta las acciones lógicas e incluye acciones de gracia. Las billeteras pueden calcular tarifas convencionales diferentes para transacciones construidas de manera diferente.
Por qué importa: Codificar una cantidad fija antigua puede subestimar la tarifa seleccionada por la billetera y puede crear un comportamiento de tarifa inusual.
Corrección: Los protocolos blindados protegen los campos definidos en la cadena, no la información recopilada por dispositivos, redes, exchanges, comerciantes o contrapartes.
Por qué importa: La privacidad operativa aún depende de las conexiones de la billetera, la identidad de la cuenta, el momento y lo que se comparte fuera de la cadena.
Las verificaciones prácticas difieren para alguien que realiza un pago, un equipo de billetera, un servicio que acepta depósitos o una organización que utiliza divulgación selectiva.
Antes de enviar, identifica si el destino es transparente, Sapling, Orchard o una Dirección Unificada y lee la vista previa de la billetera para la ruta de transferencia real. Un saldo de ZEC por sí solo no dice nada sobre el soporte del receptor o lo que la transacción revelará.
Una billetera debe analizar los formatos de dirección actuales, seleccionar los receptores correctamente, calcular la tarifa convencional actual y distinguir los saldos recibidos de los gastables. Los mensajes de error deben explicar las rutas no admitidas en lugar de recurrir silenciosamente a una opción alternativa.
Los servicios deben indicar qué tipos de receptores aceptan, si pueden devolver fondos a un destino blindado y cuántas confirmaciones requiere su propia política de riesgo. Las operaciones de depósito también necesitan una ruta de recuperación para direcciones no admitidas o gastabilidad retrasada.
La divulgación selectiva puede respaldar la conciliación o la presentación de informes sin otorgar autoridad de gasto, pero el material de visualización puede revelar actividad protegida a su titular. Los procedimientos de acceso, almacenamiento, transferencia e incidentes deben definirse antes de compartirlo.
La instantánea son datos agregados CoinGecko ZEC/USD. El gráfico son datos de Binance Spot ZEC/USDT. USD y USDT son diferentes activos de cotización, por lo que los valores mostrados pueden diferir.
Estándares técnicos principales utilizados para revisar las explicaciones de transacción, receptor, tarifa y billetera en esta página.
Preguntas operativas adicionales no respondidas por las secciones principales de transacción y receptor.
Las claves de visualización pueden proporcionar acceso de lectura a la actividad blindada compatible sin otorgar la capacidad de gastar. La organización aún necesita una política para el acceso, el almacenamiento y el alcance exacto de la divulgación.
Una billetera puede detectar una transacción entrante antes de que alcance la profundidad de confirmación o la política de confianza requerida para gastar. La interfaz debe distinguir entre saldos detectados, confirmados y disponibles para gastar.
Depende del contenido de la Dirección Unificada y de la wallet que envía. La wallet puede seleccionar un receptor transparente compatible cuando está presente, pero el remitente debe verificar la ruta mostrada porque esa elección cambia lo que es público.
Contenido técnico verificado, fuentes revisadas e historial de actualizaciones.