Eman098

ENA acaba de tener un movimiento monstruoso al alza de un 25% hasta 0.1854, rebotando con fuerza desde ese mínimo de 0.1349 de hace un par de días. Esto es una reversión en “V” perfecta después de una tendencia bajista agotadora.

Pero el volumen cuenta la historia real: esa enorme barra verde justo cuando el precio rompió confirma que no fue un falso movimiento; apareció una compra real. El RSI(6) en 87 está gritando sobrecompra a corto plazo, y el RSI(14) en 74 lo respalda, así que un retroceso o una consolidación aquí no sería para nada sorprendente. El MACD acaba de cruzar a bullish y el histograma se está volviendo verde, lo que apoya el movimiento, pero aún es fresco, no maduro.

Honestamente, esto parece una ruptura fuerte por impulso que está lista para tomarse un respiro. Perseguirla en 0.1854 es riesgoso; esperar un retroceso hacia 0.165 0.170 para entrar se ve más inteligente que comprar la parte alta de esta vela.
$ENA

#dusk $DUSK @Dusk
Lo que me llamó la atención al revisar la documentación de Dusk: solo existen dos contratos. En el génesis están el contrato de stake y el contrato de transferencia. Todo lo demás, incluido DuskVM y DuskEVM, se apoya sobre ellos.

Eso es una concentración extraña para una cadena diseñada para liquidar activos regulados. Así que quise comprobar qué hacen realmente esos dos y si se pueden modificar más adelante.

El contrato de stake lleva el seguimiento de los proveedores de servicios (provisioners): cuánto tienen apostado, cuándo maduran las recompensas y cuándo se aplica el slashing. El contrato de transferencia gestiona tanto los saldos públicos (Moonlight) como los saldos protegidos (Phoenix), y es el único lugar en el que el movimiento de fondos de un contrato a otro realmente ocurre. Todos los entornos de ejecución pasan por él para la liquidación y la disponibilidad de datos, según la documentación actual.

Por qué importa: si estás construyendo sobre DuskEVM o emitiendo activos a través de Dusk Trade, no solo estás confiando en la lógica de tu propio contrato. Estás confiando en que esos dos contratos del génesis se comporten correctamente de forma indefinida, ya que son el sustrato de liquidación sobre el cual descansa todo lo demás.

Esto es lo que no pude precisar. La documentación describe que estos contratos se han refactorizado con el tiempo: el contrato de stake se reconstruyó para corregir un problema de almacenamiento y, posteriormente, las actualizaciones de ingeniería cambiaron su estructura de eventos. Así que claramente no están congelados en el sentido de inmutables desde el génesis.

Lo que no me queda claro es la ruta de actualización real: ¿es discrecional (el equipo del protocolo publica una actualización de red) o existe un paso formal de gobernanza on-chain en el que los provisioners votan antes de que cambie la lógica de los contratos del génesis? La documentación que encontré describe lo que hacen los contratos, no cómo se autoriza cualquier modificación a los mismos.

Para una cadena que se posiciona para la liquidación institucional, esa distinción entre una actualización autorizada por el equipo vs. una actualización ratificada por los provisioners parece que debería documentarse explícitamente en algún lugar.

¿Alguien ha visto dónde @Dusk especifica el proceso de Autorización real para los cambios en los contratos del génesis?

$DUSK #dusk

#dusk $DUSK @Dusk
Lo que llamó mi atención no fue el mensaje de cumplimiento de Dusk, sino lo que encontró una firma de auditoría independiente dentro del sistema de pruebas de Dusk: el sistema de pruebas que asegura el modelo de transacciones blindadas de Phoenix @Dusk en DuskDS.

El mecanismo: Phoenix usa pruebas PLONK para que un gasto pueda verificarse sin revelar saldos. El verificador debe comprobar un lote de compromisos de polinomios contra una clave de verificación confiable antes de aceptar cualquier prueba como válida.

La parte que quería verificar: según un informe de una firma de seguridad, cuatro de esas evaluaciones de selectores nunca se comprobaron realmente contra sus compromisos; el verificador las consumió sin validarlas. En teoría, esa brecha podría permitir que una prueba falsificada se considerara legítima.

Por qué importa: esto se encuentra directamente debajo del pool blindado del que se supone que los flujos de activos regulados hereden privacidad. Una prueba falsificada en un sistema de notas opaco es difícil de detectar a posteriori; esa es precisamente la razón de blindar.

El detalle que la mayoría no notaría: la corrección se implementó a mediados de febrero de 2026, antes de la divulgación pública en abril, así que se parcheó y no se explotó con base en lo que se ha publicado. Lo que no tengo claro es si esto lo detectó una revisión interna de Dusk o primero una parte externa, y cómo se comunicó esa línea de tiempo a los socios que dependen de esta capa.

¿Significa mucho “Auditado” si la corrección precede a la divulgación por dos meses?

$DUSK #dusk

#dusk $DUSK @Dusk
Lo que me llamó la atención sobre NPEX no fue la cifra de 300 millones de euros; fue que NPEX ya tiene una licencia MTF, una licencia de bróker y una licencia ECSP bajo las normas neerlandesas/ de la UE, y Dusk está construyendo directamente sobre esa pila regulatoria existente en lugar de pedir a los reguladores un marco nuevo específico para cripto. Así que la parte que quería verificar era: ¿cómo se mantiene una operación onchain cumpliendo las reglas de elegibilidad de inversores de un MTF sin un verificador centralizado que revise cada transacción?

El mecanismo, según describen los documentos actuales, funciona mediante la divulgación selectiva de Citadel.
Un inversor presenta un reclamo específico sobre su condición de acreditación de residencia, finalización de KYC como una prueba de conocimiento cero vinculada a su billetera sin exponer el documento subyacente ni los datos personales. La contraparte o la lógica del protocolo verifica la prueba, no los datos en sí.

Por qué esto importa específicamente para un centro regulado: NPEX no puede legalmente permitir que cualquiera negocie ciertos instrumentos. Históricamente eso significaba que un bróker centralizado verificaba las identificaciones antes de cada orden. Aquí la elegibilidad se convierte en un credencial criptográfico reutilizable en lugar de una comprobación manual repetida, que es lo que realmente hace plausible la liquidación instantánea para activos regulados, y no solo una afirmación de marketing.

Lo que no he podido confirmar con la documentación actual es cómo funciona la revocación de credenciales en la práctica: si cambia el estado de elegibilidad de alguien (un cambio de residencia, una bandera de sanciones), ¿con qué rapidez se propaga a las billeteras que tienen pruebas emitidas con el estado anterior? ¿Se requiere que el inversor vuelva a demostrar o el emisor puede invalidar las pruebas de manera unilateral?

Ese vacío: la vigencia de una prueba de divulgación en relación con las expectativas en tiempo real de un regulador, parece ser la prueba real de si esto escala más allá de un único piloto de exchange. Cualquiera que conozca la especificación de Citadel, ¿sabe cómo se gestiona actualmente la revocación?

$DUSK #dusk @Dusk

#dusk $DUSK @Dusk
Lo que llamó mi atención no fue la parte de conocimiento cero de Dusk que suele acaparar la mayor atención, sino un detalle más pequeño sobre cómo un bloque realmente se vuelve final.

Quería comprobar cómo Succinct Attestation, el protocolo de consenso de prueba de participación sin permisos basado en comités de DuskDS, confirma una transacción, ya que en este espacio se habla de liquidación instantánea de forma algo laxa.

Cada ronda pasa por tres pasos: un proponente propone y difunde un bloque candidato, un comité lo valida y, después, un segundo comité ratifica esa validación y finaliza el bloque. Solo después de que ambos comités estén de acuerdo, el bloque avanza.

Lo interesante es que @Dusk no trata la finalización como un único evento binario. Un bloque se acepta una vez que supera los tres pasos; se confirma una vez que los bloques posteriores se construyen sobre él; se vuelve estable cuando está lo suficientemente enterrado y, finalmente, final cuando es determinista y criptográficamente garantizado, lo que significa que no puede revertirse.

Para una liquidación regulada, esa distinción por etapas importa más que la velocidad bruta. Un custodio no solo necesita que una transacción sea rápida; necesita un punto definido en el que lo irreversible sea demostrable, no asumido.

Lo que me gustaría que se aclarara es el comportamiento bajo carga sostenida. Que dos comités distintos estén de acuerdo agrega un paso de coordinación que las cadenas con un único proponente se saltan. A medida que crecen el conjunto de proponentes y la distribución de participación, ¿la ratificación se mantiene rápida o la coordinación entre comités se convierte en el cuello de botella?

Los documentos describen las fases y la división de recompensas: 70% para el proponente y 5%/5% para los comités de validación y ratificación. Lo que no queda claro es el límite de rendimiento bajo congestión real de la red, solo se prueba el comportamiento en testnet.

¿Alguien ha visto datos de selección de comités o de tiempos de finalización de Dusk bajo una carga real sostenida de transacciones, en lugar de números de red inactiva?

$DUSK #Dusk

#dusk $DUSK @Dusk
He estado yendo y viniendo entre dos documentos de Dusk que describen la privacidad de maneras completamente diferentes y la brecha entre ellos es la historia real.

Zedger, el protocolo original de activos regulados de Dusk, se ejecuta de forma nativa en DuskDS y se basa en UTXO, con el mismo modelo contable que usa Bitcoin. l
extendido para cumplir con la normativa. Su sucesor, Hedger, se ejecuta en DuskEVM y toma una ruta distinta: combina cifrado homomórfico (ElGamal sobre curvas elípticas) con pruebas de conocimiento cero por encima de un modelo híbrido UTXO/cuentas.

Lo que captó mi atención es lo que esa combinación realmente te aporta. Con HE, los cálculos ocurren directamente sobre saldos cifrados, sin que nadie tenga que descifrar un valor para sumarlo o restarlo. Luego, las pruebas ZK verifican que la computación se realizó correctamente sin revelar las entradas. Los saldos y las cantidades transferidas permanecen cifrados de extremo a extremo, mientras que la red aún puede confirmar que no se falsificó nada.

La parte que quería verificar: ¿esto te cuesta algo frente a Zedger? Según los materiales de @Dusk , sí: el modelo basado en cuentas de la EVM no puede ofrecer la anonimidad total que proporciona una capa UTXO como Zedger. Hedger te da saldos confidenciales y auditabilidad, pero no vinculabilidad cero (unlinkability).

Así que el intercambio es nOt privacidad vs. cumplimiento: es privacidad vs. superficie para desarrolladores. Zedger mantiene una anonimidad más sólida, pero sigue siendo nativo de UTXO. Hedger sacrifica parte de eso a cambio de herramientas EVM listas para usar.

Lo que aún me gustaría saber: en un instrumento regulado que toca tanto Zedger en DuskDS como Hedger en DuskEVM, ¿qué garantía de privacidad realmente rige en el momento del settlement?

$DUSK #dusk

#dusk $DUSK @Dusk
Phoenix mantiene pruebas de doble gasto en un árbol de Merkle de notas, en lugar de un libro mayor de cuentas. Todavía no hay balances visibles, pero nadie puede gastar la misma salida dos veces. Quería ver cómo se sostiene eso en la práctica.

Phoenix trata cada unidad de @Dusk como un UTXO llamado nota. Cada nota vive como un hash dentro de un árbol de Merkle. Gastar una nota no la borra; eso no es así como funcionan estos árboles. En su lugar, gastarla produce un anulador (nullifier): un valor derivado de la clave secreta de la nota que aparece públicamente una vez que se usa. La red nunca aprende de qué nota proviene el anulador, solo que ahora es inválido. Intenta reutilizar la misma nota y el anulador duplicado la delata al instante.

Ese diseño es lo que permite que Phoenix se mantenga protegido y aun así sea verificable. Las finanzas reguladas no pueden tolerar una liquidación ambigua, y los anuladores dan una finalidad determinista sin exponer al emisor, al receptor ni el monto. Una clave de vista permite que un propietario pruebe selectivamente qué contenía una nota, de modo que la auditabilidad no se pierde por completo: se pospone para el titular de la clave.

Lo que no pude resolver del todo a partir de la documentación: cómo se gestiona a largo plazo el crecimiento del conjunto de anuladores y cuál es el costo de generación/verificación (proving) a medida que el árbol de notas escala bajo un volumen institucional sostenido, en vez de condiciones de prueba.

Realmente curioso: ¿alguien ha visto números de rendimiento para la generación de pruebas de Phoenix bajo carga real de liquidación, no solo los puntos de referencia de testnet?

$DUSK #dusk

#dusk $DUSK @Dusk

Mantengo dos perfiles de navegador diferentes para el trabajo y para cosas personales, la misma persona, pero las cuentas nunca se tocan entre sí. Algo similar está ocurriendo bajo el capó en la capa de privacidad de DuskEVM, y es un diseño más extraño de lo que esperaba.

Lo que me llamó la atención mientras leía la especificación de Hedger: en este sistema un usuario @Dusk no tiene una sola dirección, tienen dos. Una dirección EVM regular para llamadas normales a contratos y una dirección separada de Hedger que mantiene un saldo cifrado. Lo interesante es por qué no es solo para aparentar.

El mecanismo, paso a paso: el saldo de tu Hedger se cifra usando ElGamal sobre curvas elípticas (un esquema homomórfico) para que la red pueda sumar y restar montos cifrados sin necesidad de descifrarlos. Cuando envías una transferencia privada, adjuntas una prueba de conocimiento cero que demuestra que las matemáticas son correctas: que las entradas coinciden con las salidas y que no hay saldos negativos, sin revelar los números reales. La conformidad se gestiona mediante allowlisting en lugar de transparencia total, de modo que un auditor pueda acceder sin que toda la cadena lo vea.

Por qué importa: es un verdadero equilibrio distinto al de la mayoría de configuraciones DeFi privadas, que normalmente ocultan la transacción pero te dejan trabajando dentro de una sola identidad. Separar la identidad pública de ejecución de la identidad del saldo confidencial significa que una aplicación puede integrarse con herramientas EVM normales para la lógica y solo canalizar el lado del dinero a través de la ruta cifrada.

Lo que no pude resolver del todo con la documentación: cómo se supone que las dos direcciones se vinculan o no se vinculan en la capa de UX; ¿el enlace ocurre una vez durante la configuración de la billetera, por sesión o por contrato?

Parece ser el detalle que decide si esto se siente fluido o como gestionar dos cuentas separadas para siempre.

¿Alguien que haya probado Hedger en Sepolia en la práctica? ¿Cómo funciona ese enlace en realidad?

$DUSK #dusk