Pensé que, al estar Moonlight y Phoenix en paralelo en la página de arquitectura, los usuarios de la red principal aún podían elegir libremente entre cuentas públicas y operaciones enmascaradas. Tras seguir verificando las actualizaciones de Boreas de @Dusk , descubrí que lo que de verdad determina si una institución puede desplegarse no es el diagrama de arquitectura, sino qué tipo de transacciones acepta la red en la actualidad.
La actualización oficial es muy clara: la red principal, con el reinicio de Boreas el 10 de junio de 2026, dejó de aceptar nuevas transacciones de Phoenix en el bloque `4,414,095`; la testnet también las desactivó el 7 de agosto, tras el bloque `4,000,000`. Moonlight es el modelo de transacción que está soportado en este momento.
Al incorporarlo al proceso de tesorería de una institución para comprar un bono restringido, la diferencia aparece de inmediato. El equipo de producto quizá quiera ocultar el importe del pago y su vinculación con la cuenta, mientras aporta evidencia a la sede o al auditor según los permisos. Si la lista de despliegue solo escribe “Dusk soporta Phoenix”, los sistemas de wallet, custodia y liquidación se darán cuenta al final: ya cambió el límite de acceso en la red principal y la familia de transacciones prevista no puede enviarse.
Esto no significa que la orientación de privacidad de Dusk haya desaparecido. El sitio web oficial sigue enumerando privacidad, divulgación selectiva y contratos nativos ZK como capacidades clave; además, Hedger en DuskEVM ofrece otra ruta de ejecución confidencial. Pero ese mismo día, el sitio web marcó tanto DuskEVM como Hedger como `Testnet`. Por ello, el Phoenix histórico, las capacidades nativas ZK, el Hedger de la testnet y el flujo de producción disponible para instituciones deben mantener el estado de marcado separado; no pueden sustituirse entre sí dentro de una sola frase como “soporta privacidad”.
Los materiales oficiales no pueden demostrar que el flujo de privacidad en red principal ya esté funcionando a gran escala, ni pueden probar que la capacidad de Hedger en testnet ya tenga un SLA a nivel institucional. Aquí no existe la ruta de “más nombres de funcionalidades = adopción más fuerte”.
La observación posterior solo deja cuatro recibos: rutas de transacciones confidenciales nuevas que se pueden crear en la red principal, número de wallets y soporte de custodia en producción, volumen real de ejecución de contratos confidenciales y tasa de éxito de divulgación autorizada. En la capa de tokens no ampliaré la narrativa de utilidad: el punto de apoyo documental de $DUSK sigue siendo la ejecución de comisiones de pago y la pignoración de red; cuando las rutas disponibles puedan sostener la ejecución continua, entonces podremos hablar de necesidades observables.
¿Crees que el siguiente paso más importante es A restaurar las transacciones nativas enmascaradas, B impulsar Hedger hacia la producción, o C primero publicar una matriz de disponibilidad exacta?#dusk
La actualización oficial es muy clara: la red principal, con el reinicio de Boreas el 10 de junio de 2026, dejó de aceptar nuevas transacciones de Phoenix en el bloque `4,414,095`; la testnet también las desactivó el 7 de agosto, tras el bloque `4,000,000`. Moonlight es el modelo de transacción que está soportado en este momento.
Al incorporarlo al proceso de tesorería de una institución para comprar un bono restringido, la diferencia aparece de inmediato. El equipo de producto quizá quiera ocultar el importe del pago y su vinculación con la cuenta, mientras aporta evidencia a la sede o al auditor según los permisos. Si la lista de despliegue solo escribe “Dusk soporta Phoenix”, los sistemas de wallet, custodia y liquidación se darán cuenta al final: ya cambió el límite de acceso en la red principal y la familia de transacciones prevista no puede enviarse.
Esto no significa que la orientación de privacidad de Dusk haya desaparecido. El sitio web oficial sigue enumerando privacidad, divulgación selectiva y contratos nativos ZK como capacidades clave; además, Hedger en DuskEVM ofrece otra ruta de ejecución confidencial. Pero ese mismo día, el sitio web marcó tanto DuskEVM como Hedger como `Testnet`. Por ello, el Phoenix histórico, las capacidades nativas ZK, el Hedger de la testnet y el flujo de producción disponible para instituciones deben mantener el estado de marcado separado; no pueden sustituirse entre sí dentro de una sola frase como “soporta privacidad”.
Los materiales oficiales no pueden demostrar que el flujo de privacidad en red principal ya esté funcionando a gran escala, ni pueden probar que la capacidad de Hedger en testnet ya tenga un SLA a nivel institucional. Aquí no existe la ruta de “más nombres de funcionalidades = adopción más fuerte”.
La observación posterior solo deja cuatro recibos: rutas de transacciones confidenciales nuevas que se pueden crear en la red principal, número de wallets y soporte de custodia en producción, volumen real de ejecución de contratos confidenciales y tasa de éxito de divulgación autorizada. En la capa de tokens no ampliaré la narrativa de utilidad: el punto de apoyo documental de $DUSK sigue siendo la ejecución de comisiones de pago y la pignoración de red; cuando las rutas disponibles puedan sostener la ejecución continua, entonces podremos hablar de necesidades observables.
¿Crees que el siguiente paso más importante es A restaurar las transacciones nativas enmascaradas, B impulsar Hedger hacia la producción, o C primero publicar una matriz de disponibilidad exacta?#dusk
