Pools protegidos, direcciones unificadas y claves de visualización de Zcash
Compara los pools transparentes, Sapling y Orchard; aprende cómo se elige un receptor de una dirección unificada y qué revelan las claves de visualización y los cruces entre pools.
En esta guíaUn pool es un estado del libro mayor, no un custodio
Resumen breve
Zcash no oculta automáticamente todas las transferencias. El pool transparente muestra públicamente direcciones y flujos de valor; Sapling y Orchard cifran los datos de las notas y usan compromisos y nullifiers públicos para verificar el consenso. Una Unified Address puede contener varios receptores; la privacidad depende del receptor que elija la billetera emisora y de los pools que atraviese el valor.
Un pool es un estado del libro mayor, no un custodio
En Zcash, un pool es un estado de valor sujeto a reglas de consenso, no una empresa que guarda depósitos. El pool transparente usa UTXO públicos cuyas direcciones, importes y relaciones de gasto pueden inspeccionarse. Los pools protegidos usan notas cifradas y árboles de compromisos; el consenso sigue comprobando conservación del valor y doble gasto.
Distingue Sapling y Orchard de los depósitos Sprout desactivados
Sapling y Orchard son pools separados con protocolos y árboles de notas distintos. Desde la activación de ZIP 211 ya no se puede añadir valor nuevo al pool Sprout. NU6.2 es la actualización Mainnet más reciente ya asentada, activa desde el 3 de junio de 2026; volvió a habilitar Orchard con una corrección. NU6.3 e Ironwood siguen en un borrador, no son reglas Mainnet vigentes.
Los datos cifrados de la nota y el compromiso público cumplen funciones distintas
Una nota representa valor para quien posee la clave de gasto correspondiente. Sus detalles se cifran; la cadena conserva el texto cifrado y un compromiso que permite verificar su validez sin revelar su contenido. Al gastarla aparece un nullifier único, que impide reutilizar la misma nota sin revelar qué compromiso anterior corresponde a ese gasto.
Una Unified Address reúne varios tipos de receptor
La Revision 0 activa de ZIP 316 suele usar el prefijo u y puede incluir receptores Orchard, Sapling y transparentes P2SH/P2PKH; debe incluir al menos uno protegido. El orden de preferencia es Orchard, Sapling, P2SH y P2PKH. La billetera emisora debe elegir el receptor mejor situado que admita. La cadena de la dirección es opaca: no se puede leer visualmente qué receptores contiene.
Cruzar el límite de un pool puede volver visible el flujo de valor
Un envío transparente a protegido puede mostrar los UTXO públicos de origen y el valor neto que entra al pool protegido, aunque no exponga el receptor de la nota como un UTXO público. Un retiro de protegido a transparente muestra la dirección y el importe de salida. Los cruces entre Sapling y Orchard también pueden revelar cambios por pool; esos datos no identifican por sí solos a una persona, pero se pueden combinar con importe, hora y registros externos.
Imagen conceptual sin palabras ni datos reales que compara outputs transparentes visibles con pools de notas cifradas y una ruta de consulta aparte. La visibilidad real depende del receptor elegido, los cruces de pool, la billetera y el alcance de la clave.
Las claves de visualización permiten leer, no gastar
ZIP 316 define una clave de visualización como información para ver pagos hacia una dirección; una Full Viewing Key también puede ver desde ella. Una Incoming Viewing Key puede derivarse de una completa. Estas claves no firman gastos: para mover valor hace falta una clave de gasto o un sistema de firma. Aun así, compartir una clave puede exponer un conjunto amplio de actividad y requiere revisar su alcance y retención.
Las transacciones protegidas no ocultan todas las conexiones
Las notas protegidas ocultan destinatarios e importes frente a un observador común, pero la cadena aún contiene compromisos, nullifiers, tiempos y datos del protocolo. Los límites entre pools, los registros de exchanges, la hora conocida por una contraparte y las claves compartidas pueden aportar pistas. Una Unified Address tampoco fuerza a todas las billeteras a usar Orchard; hay que mirar el receptor elegido en la vista previa.
Verifica juntos la dirección y el resultado de la transacción
Confirma Mainnet o Testnet, el tipo de dirección, el pool que eligió la billetera, el importe, el memo y la comisión. Para investigar un movimiento, usa su identificador y la red correcta; las salidas transparentes son visibles, pero un explorador sin soporte puede omitir detalles de notas protegidas. No concluyas que no hubo transacción solo porque una interfaz no muestre su nota.
Sigue una transferencia hipotética y lo que revela
Supón que Lee envía 1,25 ZEC desde un UTXO transparente a una UA Revision 0 con receptores Orchard, Sapling y transparente. La cifra es ilustrativa, no una comisión ni un ajuste predeterminado. Si su billetera admite Orchard, la prioridad de ZIP 316 selecciona ese receptor; la cadena muestra el UTXO público de origen y el límite del pool, pero no la dirección ni el importe de la nota protegida como una salida transparente. Una clave de visualización compartida podría revelar detalles adicionales a su destinatario autorizado.
This guide is current to 2026-09-27. The NU6.3 proposal is not treated as active Mainnet consensus.
Related reading: [Bitcoin address reuse](/learn/es/bitcoin-address-reuse-privacy-transaction-linkability-explained) · [Monero privacy](/learn/es/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained) · Custodial and non-custodial wallets
Preguntas frecuentes
Q1¿Se ocultan la dirección y el importe en todas las transacciones de Zcash?
No. El pool transparente publica UTXO, direcciones e importes. Una Unified Address puede contener varios receptores; comprueba cuál seleccionó la billetera emisora.
Q2Si una Unified Address incluye Orchard, ¿siempre se usa Orchard?
Si la billetera emisora admite Orchard y procesa una UA Revision 0 con ese receptor, ZIP 316 lo prioriza. Otra billetera puede admitir receptores diferentes; revisa la vista previa.
Q3¿Puedo mover fondos con una Viewing Key?
No. Permite leer transacciones dentro de su alcance. Para gastar hace falta una clave de gasto o autoridad de firma independiente; protege también la clave de visualización.
