Última comprobación: 21 de octubre de 2026.\n\nLa próxima actualización de red NU7 de Zcash está especificada para deshabilitar las transacciones de versión 4 (v4). Los mineros con saldos en Sprout deben verificar con urgencia si su wallet original tiene una ruta de migración viable antes de la activación. El resto de mineros de pool deben revisar su destino de pago en ZEC y su wallet receptora, mientras que los operadores de nodos y los servicios que construyen transacciones deben verificar la compatibilidad de su software con NU7.\n\nEl riesgo depende de los fondos y del software de transacciones, no simplemente de la antigüedad de una wallet. La prohibición cubre todas las transacciones v4; Sprout enfrenta la consecuencia más grave porque no cuenta con ningún otro formato de transacción compatible. Actualizar la configuración de conexión de un ASIC no resuelve ninguno de los dos problemas (ZIP 2003).\n\n## NU7 deshabilita las transacciones v4, no las "direcciones antiguas"\n\nHay cuatro conceptos que es fácil confundir y que vale la pena separar antes de realizar cualquier cambio en una configuración de minería o de pago:\n\n1. Un tipo de wallet o dirección — por ejemplo, una dirección transparente, una dirección blindada Sapling o una dirección Sprout heredada.\n2. Una versión de transacción — el formato de serialización (v4, v5 o v6) que utiliza una transacción al difundirse en la red.\n3. Una configuración de pago de la cuenta del pool — el destino de retiro configurado en una cuenta de pool de minería.\n4. La conectividad de minería — el endpoint Stratum y el identificador de worker que utiliza un ASIC para enviar shares.\n\nUna dirección no lleva por sí misma una versión de transacción. La versión de la transacción la determina el software que construye el gasto —una wallet, un procesador de pagos o un software de nodo— en el momento en que construye la transacción. Según la propuesta de despliegue de NU7, la actualización no introduce un nuevo formato de transacción; deshabilita v4 dejando v5 y v6 como los formatos válidos en adelante (ZIP 259). Esto significa que una transacción transparente o Sapling construida en v4 se vuelve inválida tras la activación exactamente de la misma manera que una transacción v4 de Sprout: la prohibición se aplica a la versión de serialización, no a un pool de valor específico.\n\n## Por qué las wallets de Sprout necesitan atención urgente\n\nSprout es el pool blindado original de Zcash, y los gastos de Sprout solo pueden representarse dentro de una transacción v4. Actualmente no existe en el protocolo ningún formato de transacción alternativo para Sprout. Como consecuencia directa, cualquier Zcash que permanezca en el pool de Sprout y no se traslade antes de la activación de NU7 quedará imposible de gastar bajo las reglas de consenso actualmente especificadas, a menos que se produzca un futuro cambio de protocolo (ZIP 2003).\n\nUna dirección histórica con prefijo zc... es una señal útil de detección: las direcciones blindadas de Sprout suelen usar ese prefijo, distinto de las direcciones Sapling (habitualmente zs...) y de las direcciones transparentes (habitualmente t...). Sin embargo, el prefijo debe tratarse como un punto de partida para la investigación, no como prueba definitiva de riesgo; debe usarse el software de wallet real para confirmar el tipo de dirección y comprobar si queda algún saldo.\n\nLos mineros que recibieron pagos tempranos de ZEC —incluidos pagos históricos de pool enviados a destinos blindados antes de que Sapling se convirtiera en el pool blindado dominante— deben revisar sus wallets de autocustodia, copias de seguridad archivadas y registros antiguos de retiros en busca de cualquier saldo que aún permanezca en una dirección Sprout.\n\nExiste una limitación práctica importante: el ZIP 2003 indica que la obsolescencia de zcashd eliminó el único software mantenido que todavía ofrecía funcionalidad de wallet para Sprout. Que las reglas de consenso permitan una transferencia antes de NU7 no significa que exista disponible una herramienta de migración mantenida. Los titulares de fondos deben verificar una ruta de recuperación y transferencia viable para su wallet original; no debe asumirse que simplemente actualizar a una wallet actual proporcione soporte para Sprout (ZIP 2003).\n\nSi existe una ruta viable disponible, la transferencia debe confirmarse antes de la activación. Volver a firmar una transacción v4 no cambia su versión, y las transferencias de Sprout no pueden reconstruirse como transacciones v5 o v6.\n\n## Qué deben verificar los mineros de pool\n\nDeshabilitar las transacciones v4 no suele requerir, por sí mismo, que los mineros de pool cambien la configuración del ASIC. Siga cualquier instrucción específica de compatibilidad proporcionada por el pool de minería o por el proveedor del hardware. La conexión Stratum y el nombre de worker utilizados para enviar shares no están relacionados con la forma en que el pool de minería construye las transacciones de pago de ZEC en nombre del minero.\n\nLa configuración de minería de ZEC de ViaBTC, por ejemplo, utiliza un endpoint Stratum combinado con un nombre de worker en el formato userID.workerID para el envío de shares (documentación de ViaBTC sobre minería de ZEC). El destino de retiro de ZEC se configura por separado en los ajustes de activos de la cuenta.\n\nLa lista de verificación práctica para un minero de pool es, por tanto:\n\n- Confirmar la dirección de retiro de ZEC configurada actualmente en la cuenta del pool, en lugar de asumir que no ha cambiado desde que se configuró por primera vez.\n- Confirmar que la wallet o cuenta de exchange de destino sigue aceptando depósitos a esa dirección y tipo de dirección específicos en su interfaz de depósito actual, ya que el soporte de un determinado formato de dirección puede variar según el servicio y puede cambiar con el tiempo.\n\nLa función de auto-retiro de ViaBTC, documentada por separado de la conectividad de minería, permite que una cuenta envíe el ZEC acumulado a una dirección configurada una vez que alcanza un mínimo publicado de 0.001 ZEC, procesado con una periodicidad diaria (documentación de Auto-retiro de ViaBTC). Este umbral y esta periodicidad son ajustes propios de la plataforma, no reglas de la red Zcash, y revisarlos es un paso razonable al confirmar que un destino de pago está actualizado y correctamente tipado.\n\n## Qué deben verificar los mineros solo y los operadores de infraestructura
Los mineros que operan su propio nodo completo, o los servicios que construyen transacciones de Zcash en nombre de los usuarios, se enfrentan a un conjunto de requisitos más amplio que un minero de pool típico. NU7 cambia la compatibilidad a nivel de red, no solo la validez de las transacciones: los nodos que anuncian una versión de protocolo de red anterior a NU7 pueden ser desconectados por pares actualizados, y los bloques producidos bajo las reglas de consenso antiguas no serán aceptados una vez que las nuevas reglas estén activas (ZIP 259).
Esto es directamente relevante para:
- Mineros solitarios que ejecutan un nodo y construyen sus propias plantillas de bloque o transacciones coinbase.
- Operadores de pools responsables del procesamiento de pagos.
- Proveedores de billeteras, custodios y servicios de difusión de transacciones.
- Exploradores de bloques e indexadores de cadena que analizan datos de transacciones.
Cualquier transacción no confirmada preparada antes de la activación debe revisarse para determinar si se construyó en formato v4. Si es así, y los fondos no son fondos Sprout, generalmente debe recrearse utilizando software compatible con NU7 en lugar de simplemente reenviarse; la especificación de despliegue es explícita en que el software debe dejar de construir transacciones v4 destinadas a inclusión después de la activación.
El cronograma de NU7 publicado el 17 de septiembre de 2026 apunta al 5 de noviembre de 2026 para la activación en la red principal (mainnet) y programó la decisión final de activación para el 20 de octubre. Al verificarse el 21 de octubre de 2026, ZIP 259 aún mostraba el estado de Borrador (Draft) y una altura de activación de mainnet por determinar (TBD), mientras que la tarea de implementación de la altura de mainnet de Zebra permanecía abierta. Estas son observaciones sobre los documentos publicados, no una prueba de que los desarrolladores no hayan tomado una decisión posterior.
Una decisión de los desarrolladores, una especificación de despliegue actualizada y una implementación de nodo lanzada son hitos separados. Los operadores deben verificar la altura de mainnet acordada y una versión que la implemente antes del despliegue. Las actualizaciones de Zcash se activan en una altura de bloque específica, por lo que el 5 de noviembre no debe tratarse como una fecha límite garantizada en tiempo real para mover fondos.
Lista de verificación de NU7 para mineros
- Busque en billeteras, copias de seguridad y registros históricos de pagos los saldos de Sprout. Si los encuentra, verifique una ruta de migración viable para la billetera original y complete cualquier transferencia antes de la activación; el soporte mantenido de billeteras Sprout ya no está disponible según ZIP 2003.
- Confirme si el software de billetera en uso puede construir transacciones válidas posteriores a NU7, en lugar de asumir la compatibilidad solo por su antigüedad.
- Revise el destino de retiro de ZEC configurado en la cuenta del pool de minería, por separado de la configuración de conexión de minería.
- Confirme que la billetera o el exchange receptor actualmente acepta depósitos a la dirección específica y al tipo de dirección que se está utilizando.
- Verifique las transacciones no confirmadas o firmadas sin conexión preparadas antes de la activación. Para transacciones v4 que no sean Sprout, use software compatible para recrearlas en un formato admitido cuando sea posible. Las transacciones Sprout no se pueden convertir a v5 o v6; sus fondos deben moverse antes de la activación.
- Si opera un nodo completo, infraestructura de pool o un servicio de construcción de transacciones, actualice a software compatible con NU7 antes de la altura de activación finalizada.
Conclusión
Los poseedores de Sprout enfrentan tanto un plazo del protocolo como un desafío práctico de recuperación: sus fondos dependen de v4, y el soporte mantenido de billeteras Sprout ha terminado. Los mineros de pool deben verificar su billetera receptora y destino de pago, mientras que los operadores de infraestructura deben preparar software compatible. Use la documentación de despliegue actual y las notas de versión del nodo para verificar la altura de activación y el estado de implementación.
¿NU7 requiere una actualización de firmware de ASIC?
Deshabilitar las transacciones v4 en sí mismo normalmente no requiere una actualización de firmware de ASIC para la minería en pool. Cambia qué versiones de transacciones acepta la red e introduce ningún formato de transacción nuevo. Verifique cualquier orientación específica de firmware o configuración de su pool y proveedor de hardware.
¿Mi saldo protegido (shielded) de ZEC dejará de funcionar después de NU7?
Depende del pool protegido (shielded pool), no del hecho de que una dirección sea antigua. Las transacciones protegidas Sapling y otras que no sean Sprout aún se pueden representar en los formatos v5 o v6 que siguen siendo válidos después de NU7. Solo las transferencias Sprout dependen exclusivamente del formato v4 que NU7 deshabilita.
¿Necesito cambiar la configuración de mi worker de ViaBTC debido a NU7?
Generalmente no. El endpoint de Stratum y el nombre del worker utilizados para enviar shares son independientes de la dirección de retiro de ZEC configurada en los ajustes de pago de la cuenta; NU7 afecta la construcción de transacciones, no el envío de shares.
¿Es el 5 de noviembre de 2026 una fecha de activación confirmada?
El 5 de noviembre es el objetivo en el cronograma comunitario del 17 de septiembre. El 21 de octubre de 2026, la página de ZIP 259 verificada para este artículo aún mostraba una altura de mainnet por determinar (TBD). El estado de esa página por sí solo no establece si existe una decisión más reciente de los desarrolladores. Verifique la última altura acordada, la especificación de despliegue y la versión de nodo que la respalda; la activación real sigue la altura de bloque en lugar de una hora de calendario fija.