彭鱼宴啊

#dusk $DUSK @Dusk En el mecanismo de castigo de Dusk hay un ajuste que quiero comentar por separado con mi punto de vista: desconexión de nodos, casos en los que no se produce el bloque que correspondía, este tipo de conductas no se considera maliciosa, pero sí entorpece. El modo de tratamiento es primero una advertencia y luego mover una parte del depósito en un estado temporal en el que no entra en vigor. El principal no se quema ni un solo centavo; simplemente no se pueden obtener recompensas de forma temporal y se queda excluido del consenso durante un período. Los únicos que realmente queman dinero son las conductas maliciosas que quedan plenamente comprobadas, como la doble firma y la falsificación de bloques.
Entiendo el propósito con el que se diseñó así: el umbral mínimo de depósito es de mil monedas; si por una sola desconexión se descontara el principal directamente, espantaría a muchos nodos pequeños que quieren participar en serio pero cuyas condiciones técnicas son más bien generales. Al final, la red tendería a concentrarse en manos de unas pocas instituciones profesionales. El equilibrio de usar sanciones blandas de "dolor leve" para lograr una participación más amplia tiene sentido por sí mismo.
Pero, a mi juicio, esta lógica tiene un supuesto oculto que no se ha declarado explícitamente: asume que en la red hay suficientes personas dispuestas a ejecutar nodos en serio. Las sanciones blandas entonces no dañarían la eficiencia real del funcionamiento de la red. Si algún día una gran cantidad de nodos empieza a depender de un mismo proveedor de servicios en la nube o del mismo centro de datos, y de repente ese grupo de infraestructura falla, entonces una gran cantidad de nodos activará las sanciones blandas al mismo tiempo y también quedará excluida temporalmente del consenso. En ese momento, el hecho de que "no se queme el principal" se convierte, en vez de en una protección, en un factor que tolera que todos no se preocupen demasiado por la estabilidad de sus nodos: total, si se desconectan, no duele. ¿Quién realmente se esforzaría por invertir en asegurar una tasa de disponibilidad extrema? En redes con castigo duro, el costo se siente con claridad y obliga a los operadores a tratar su infraestructura con más seriedad. La pregunta es si, en el largo plazo, la tolerancia conseguida a través de sanciones blandas no terminará reduciendo en silencio el nivel de importancia que toda la red otorga a "el mantenimiento serio". Creo que esto es algo que merece una observación continua, y no un tema que se pueda resolver de forma definitiva con solo mirar una tabla de parámetros.

#dusk $DUSK @Dusk Siempre me quedé con la duda sobre un escenario concreto: si le toca a alguien proponer un bloque, pero el nodo de esa persona se queda trabado o se desconecta, ¿la red se queda esperando en vano o existe algún mecanismo automático para cambiar a otra opción? Esta vez me puse a revisar específicamente cómo se diseña esta parte en el flujo de consenso de Dusk.
La creación de bloques en Dusk pasa por tres pasos: primero, el nodo seleccionado propone un bloque; después, un grupo de nodos confirma que ese bloque es válido mediante votación con firmas; por último, otro grupo de nodos realiza una segunda ronda de votación, recopila los resultados anteriores y se llega de forma oficial a un consenso. Estas tres etapas completan una ronda. Si el nodo que fue seleccionado para proponer el bloque no logra enviarlo correctamente dentro del tiempo establecido, o si durante la votación no se alcanza el número mínimo de participantes, entonces esa ronda termina por exceder el tiempo y falla. Luego se entra en la siguiente iteración: se vuelve a seleccionar a un nuevo grupo de nodos y se intenta otra vez, repitiendo el ciclo hasta que se logre el consenso real.
Yo pensaba originalmente que el mecanismo de “volver a intentar después de un timeout” era rígido: que en cada caso se espera siempre un tiempo fijo y se repite. Pero revisando sus registros de desarrollo descubrí que no es así. Hay una modificación descrita específicamente como “implementar un timeout adaptativo”; además, otra apunta a “permitir volver a bloques de una ronda más baja”. Esto deja claro que la mecánica no utiliza, de principio a fin, el mismo tiempo de espera fijo: más bien, ajusta la ventana de espera según las condiciones reales de la red, y también maneja casos como “si anteriormente ya se aceptó un bloque de una ronda más temprana, entonces en la ronda posterior ya no hace falta seguir haciendo experimentos sin sentido”. Me di cuenta de este detalle solo al revisar una actualización de su ciclo de desarrollo; solo con el nombre del protocolo y la descripción de los pasos no se aprecia esa capa adicional de ajuste dinámico.
Para mí, este mecanismo resuelve un problema bastante real: cuando en la red hay muchos nodos, siempre habrá alguien con fluctuaciones en la conexión o que se desconecta. Si no existiera este mecanismo automático de reelección y de ajuste dinámico del timeout, la red podría quedar bloqueada en cualquier momento si un nodo desafortunado no responde. Sin embargo, no encontré datos históricos concretos: por ejemplo, hasta ahora, cuántas veces se ha activado en la red principal el mecanismo de reelección por timeout, y cuánto tiempo adicional tarda en promedio en volver a funcionar el bloqueado normal. Por el momento no he encontrado información de ejecución que permita validarlo.

#dusk $DUSK @Dusk En Dusk hay dos sistemas de cuentas: uno es el que se puede consultar públicamente, cuentas normales; y el otro es un conjunto de cuentas de privacidad ocultas cifradas. Antes solía oír que entre ambos lados se podían convertir, así que esta vez fui a probar específicamente cómo funciona esa función de conversión y cómo se opera. Por ahora no miraré otras cosas.
El proceso concreto es así: en la capa subyacente de Dusk hay un contrato especializado que se encarga de la lógica de las transferencias. Para que un mismo token pase de estado oculto a estado público, o al revés, todo se hace mediante una operación de conversión de ese contrato. No es algo brusco como “primero sacar el dinero oculto y luego volver a depositarlo en la cuenta pública”, sino que una misma cantidad de activos completa el cambio de estado directamente en una sola operación; entre medias no existe un paso intermedio que pueda ser observado de forma independiente por un tercero externo.
Cuando yo lo probé en la red de pruebas, la primera vez di clic en la dirección equivocada. Quería convertir desde la cuenta oculta a la cuenta pública, pero lo rellené al revés: puse la operación de “público hacia oculto”. El dinero se transfirió con éxito, pero el resultado no era el que quería. Me tomó un rato darme cuenta de que el problema no era la función de conversión en sí, sino que yo mismo había confundido las dos direcciones en la interfaz de operación.
Después de probarlo, mi sensación es que la función de conversión en sí está bastante fluida: es de un solo paso, sin rodeos. No se parece a algunas soluciones que primero necesitan pasar por una dirección intermedia para completar un cambio de estado similar. Pero también encontré un punto que se puede pasar por alto con facilidad: esta conversión solo gestiona el cambio de estado del dinero en sí. Si se trata de activos tipo valores que vienen vinculados a reglas de cumplimiento normativo (por ejemplo, activos que requieren pasar por una revisión de lista, o que deben seguir reglas de transferencia específicas), entonces se ejecuta un mecanismo completamente distinto e independiente. No se puede aplicar directamente esta función de conversión para gestionarlos; están diseñados por separado. Al principio, por reflejo, asumí que todos los activos se podían convertir así, pero luego confirmé que me había equivocado.

#dusk $DUSK @Dusk Escucho hablar siempre de “privacidad programable” que menciona Dusk, pero cada vez que se refiere a ello mezcla varios rasgos a la vez. Esta vez, sin embargo, me quiero quedar solo con “divulgación selectiva” para ver a qué se refiere exactamente; lo demás, por ahora, no me importa.
Por lo que entiendo, la divulgación selectiva resuelve un escenario así: en una transacción, normalmente, el mundo exterior no puede ver el monto ni las partes involucradas; esa es la parte de privacidad. Pero si un organismo regulador o un auditor necesita comprobarlo, el usuario o la institución deberían tener un modo de hacer que una parte autorizada vea la información que corresponde, sin tener que publicarla para todos. Esto no es lo de la idea antigua de “o se revela todo o se oculta todo”; es como si, entre esos dos extremos, abrieran a la fuerza un canal controlable.
Al principio pensé que esa “selectividad” se lograba mediante operaciones manuales fuera de la cadena (off-chain), por ejemplo, si ocurría algún problema, entonces se seguía un proceso fuera de línea para exportar los registros de la transacción y mostrárselos al regulador. Consultando material, me di cuenta de que no era así. La postura oficial es que esa capacidad se implementa directamente en el protocolo mediante herramientas criptográficas: el usuario o la institución decide por sí mismo si genera un comprobante que se pueda consultar por objetos específicos, y no hay que rogar después a alguien para que ajuste el backend y lo consulte en una base de datos.
Ese malentendido lo tuve que corregir después de leer dos veces la explicación; al principio, ciertamente lo había pensado demasiado simple.
Pero también tengo que decir la verdad: en la documentación oficial, los detalles operativos sobre “quién tiene el derecho de iniciar esa solicitud de divulgación” y “qué tan precisa y detallada es la información que esa credencial permite ver” se explican de manera bastante genérica. No hay una guía concreta paso a paso que uno pueda seguir. Esto significa que, por ahora, “divulgación selectiva” se parece más a una capacidad que ya existe a nivel de protocolo, pero en un escenario real específico quizá dependamos de los detalles del producto que se materialicen luego con socios como NPEX: en esta ocasión no pude encontrar un caso concreto que ya esté en funcionamiento. Por lo pronto solo puedo confirmar que la capacidad existe; no puedo valorar si es fácil o conveniente de usar.

#dusk $DUSK @Dusk Siempre he sentido curiosidad por el fondo de desarrollo dentro del ecosistema Dusk: ¿cómo funciona exactamente? — ¿lo decide el equipo por sí mismo o hay un conjunto de procesos para que personas externas también puedan solicitar ese dinero? Después de revisar una serie de explicaciones sobre la gobernanza, descubrí que este proceso es más formal de lo que yo imaginaba al principio.
La fuente de fondos de este fondo es bastante directa: por cada bloque producido en la red principal, una parte fija de la recompensa se separa y se acumula a largo plazo en este fondo, destinado específicamente a apoyar el desarrollo del ecosistema y el trabajo de investigación posterior. No depende de recaudaciones temporales ni de que el equipo ponga dinero de su propio bolsillo.
La verdadera descentralización está en el proceso de aprobación. — Las modificaciones relacionadas directamente con el protocolo, como una propuesta técnica concreta de mejora, siguen una línea que incluye la presentación, la revisión y la decisión sobre si se adopta esa propuesta. En cuanto al formato, se exige que esté bastante bien redactada, como un documento formal de propuesta técnica, y no cuenta con que alguien publique un post cualquiera. En cambio, los gastos que no guardan relación directa con el código del protocolo, como el desarrollo de una herramienta de billetera o los fondos para la investigación de algún tema específico, siguen otra línea de aprobación: una que evalúa y decide un grupo de gobernanza encargado específicamente de la distribución de esos fondos. En teoría, los miembros de la comunidad externa también pueden participar en el proceso de aprobación a través de la participación en los procesos electorales de ese grupo.
Yo inicialmente pensé que esto era un proceso de caja negra de “aprobación interna del equipo”, pero al revisar la documentación descubrí que, al menos a nivel de documentos, estas dos líneas están bastante claramente separadas. Además, ambas conservan puertas de entrada para que personas externas puedan presentar solicitudes e incluso participar en la evaluación, y no es completamente cerrado. Pero la documentación y la ejecución real son dos cosas distintas. Concretamente, en estos años: qué proyectos se aprobaron, cuál ha sido aproximadamente la tasa de aprobación, y qué porcentaje de solicitudes provino de envíos externos; por ahora no he encontrado datos de ejecución específicos en mi poder. En esta parte, solo puedo decir que el diseño del proceso es abierto; si en la práctica funciona de manera transparente o no, todavía requiere más registros históricos para validarlo, y por el momento no puedo dar un juicio definitivo.

#dusk $DUSK @Dusk Al principio, imaginé de forma bastante simple lo de “apostar DUSK como provisioner”: enviar las monedas, ejecutar un nodo y esperar los premios. Hasta que leí con seriedad las guías oficiales de buenas prácticas de seguridad y seguí el flujo paso a paso para prepararlo en la práctica, y entonces descubrí que el umbral es mucho más alto de lo que pensaba.
Según la guía, la recomendación es generar directamente en un dispositivo USB cifrado con LUKS la owner key que tiene permisos de gestión de la apuesta, en lugar de dejarla en el disco duro habitual del ordenador conectado a internet. Los pasos concretos son: primero usar cryptsetup para cifrar todo el U-盘 con LUKS, establecer una contraseña sólida y, después, generar la clave del propietario directamente dentro de esta partición cifrada. En el día a día no se conecta: solo se inserta cuando de verdad se necesita deshacer la apuesta o extraer las recompensas para usarla una vez. La lógica es que, incluso si ese USB se pierde o lo roban, sin la contraseña no se puede leer ni acceder a nada; mientras tanto, para operar el nodo diario se utiliza otro juego de claves con permisos más bajos, separado de la owner key que realmente puede mover el capital apostado.
Al completar este proceso, mi impresión más grande fue: esto ya no es una operación de “un par de clics”, sino que te exige entender conocimientos operativos como el cifrado del disco y la gestión de claves en modo sin conexión. Para alguien como yo, que suele escribir código pero no es un profesional del mantenimiento y la operación, solo entender qué poner en /dev/sdX —y asegurarte de no formatear por error la partición equivocada— me llevó bastante tiempo, con confirmaciones repetidas.
Esto me hizo replantearme el tema de la participación en la apuesta de Dusk: aunque el umbral mínimo de apuesta es solo 1000 DUSK, parece muy bajo, pero si se siguen de verdad los estándares de seguridad recomendados por la guía oficial, el umbral operativo real va mucho más allá de “tener 1000 monedas”. También hace falta cierta capacidad técnica y paciencia para completar el flujo de seguridad hasta el final. Esto probablemente filtra de manera natural a un grupo de usuarios comunes que solo quieren “apostar rápido para salir del paso”; el resto suele ser gente dispuesta a tomarse en serio la seguridad del nodo. Para la seguridad de la red, es algo positivo; pero para el objetivo de “alcanzar suficiente descentralización en la participación de la apuesta”, el propio umbral operativo también puede ser un filtro fácil de pasar por alto.

#termmax @TermMax En realidad yo iba a consultar el Libro Blanco de TermMax buscando la tasa de interés de los préstamos, pero cuando llegué a esa parte sobre la visión casi me salto el texto sin más: «Construir un mercado de crédito completo para cada par de tokens, como en el mundo real». Este tipo de frases en los libros blancos es demasiado común; sin pensarlo lo di por hecho. Pero al seguir leyendo un par de líneas más, me di cuenta de que en la misma lista en realidad también incluía «hacer long y short sobre activos spot». Ahí me detuve y lo releí.
Mi primera reacción fue que esas dos cosas juntas son un poco raras: el préstamo a tasa fija es un instrumento financiero, mientras que hacer long y short sobre spot es otra cuestión distinta. ¿Por qué aparecerían en la misma visión de producto? Lo pensé junto con la mecánica de GT de “apalancamiento en un clic” y el ciclo de préstamos anteriores, y entonces lo entendí: en este caso, la tasa fija no es el objetivo en sí; es la base. Cambiar el préstamo “A” por vender A para comprar B y hacer long en B —o hacer short— siempre que el costo de financiación pueda fijarse de antemano, el rendimiento de la estrategia no quedará absorbido silenciosamente por las fluctuaciones de la tasa variable. Así que el préstamo a tasa fija está ahí para sentar las bases de la capa de estrategia que está arriba.
Después pensé otra vez si me estaba imaginando cosas, así que volví a verificar la profundidad del Range Order y del Limit Order en la actualidad. Descubrí que, aparentemente, se concentra sobre todo en algunos mercados principales. Eso me dejó en duda: para que la estrategia de «pedir prestado A y hacer long en B» funcione, ambos lados —tanto el colateral como el activo de deuda— tendrían que tener cotizaciones suficientemente profundas. Para los pares de activos periféricos, es posible que la curva ni siquiera se sostenga. Es decir, ahora «construir un mercado de crédito completo como en el mundo real» me suena más a que en la arquitectura dejaron preparado un “conector”, pero todavía no se ha materializado de verdad.
A partir de aquí no voy a seguir fijándome en cuántos mercados de préstamos soportan, sino en si alguien realmente está usando «pedir prestado A y hacer long en B» como una operación puramente direccional, en vez de volver al viejo ciclo del apalancamiento en un clic. El hueco entre la visión y el producto es la clave para saber en qué etapa real va este relato.

#dusk $DUSK @Dusk Hace un tiempo, mientras explicaba a un amigo el mecanismo de consenso de Dusk, de manera instintiva saqué a relucir una explicación que había visto antes: que Dusk usa Proof of Blind Bid, que la identidad del productor del bloque es anónima y que, mediante pruebas de conocimiento cero, oculta el monto de su apuesta para competir por el derecho a producir bloques. Después de terminar, me quedé con la duda en la cabeza: ¿esa afirmación sigue siendo un mecanismo que Dusk utiliza hoy en día, o es que recordaba una información de hace mucho tiempo y estoy mezclando? Volví y lo comprobé, y efectivamente me equivoqué.
En las primeras versiones del whitepaper de Dusk, Proof of Blind Bid sí era un diseño muy ingenioso: el candidato a producir bloques (Block Generator) envía una “Bid Transaction”, almacena el monto apostado en un árbol Poseidon, genera la prueba de conocimiento cero correspondiente y, durante todo el proceso de competencia, desde fuera no se puede saber quién participa ni cuánto apuesta. La intención original era bastante realista: si la identidad del productor de bloques y su monto apostado fueran públicos, sería como elaborar para el atacante una “lista de objetivos prioritarios”, atacando de forma dirigida a los productores de bloques ya conocidos y con grandes apuestas. La postulación anónima fue el esquema criptográfico que Dusk introdujo al inicio para contrarrestar ese tipo de ataque dirigido.
Pero ahora, según la documentación oficial de Dusk, el consenso de la red principal, llamado Succinct Attestation, es un diseño de prueba de participación basado en comités. Se apoya en que el provisioner genere de forma determinista los candidatos a producir bloques y el comité de votación; en todo el flujo ya no se menciona el concepto de “competencia anónima”. En otras palabras, durante la transición desde el diseño temprano hasta su despliegue en la red principal, Dusk silenciosamente cambió la característica de “identidad anónima del productor de bloques”, reemplazándola por un mecanismo de comité que pone más énfasis en la eficiencia y en la finalización determinista.
Este cambio no se anunció a bombo y platillos, pero su importancia no es poca. El problema que intentaba resolver Proof of Blind Bid —“evitar ataques dirigidos”— se abordó de manera distinta en Succinct Attestation: se recurre más al tamaño del comité y a la impredecibilidad de la elección, en lugar de dejar que la identidad desaparezca por completo. Para mí, esto me recuerda algo: al evaluar el diseño técnico de un proyecto, no basta con tomar como base artículos escritos hace varios años. El mecanismo central de Dusk también está en continua iteración; es posible que aquel esquema de competencia anónima que sonaba tan atractivo en el pasado ya no sea exactamente cómo funciona hoy en la práctica.

Por fin llegó $ALIGN TGE

Hoy, a las 23:00 (hora de Pekín), Aligned va a activar el TGE.

Como proyecto enfocado en la verificación de pruebas ZK y en infraestructura de cómputo verificable para Ethereum, el trabajo de construcción de productos de Aligned a lo largo de este camino ha sido bastante sólido.

Esperamos el desempeño de hoy y también esperamos que el ecosistema de Aligned siga expandiéndose.

Además, considerando que plataformas de intercambio como Coinbase tienen planes de listar, ¡esperamos poder aprovechar la oportunidad!
$ALIGN 🚀

#dusk $DUSK @Dusk Siempre he entendido Phoenix así: "es la versión de Dusk de Zcash/Monero", un modelo de transacciones de privacidad que busca el anonimato total, donde ninguna de las partes de la transferencia puede ver a la otra. Hasta hace poco, al comparar con las explicaciones oficiales del white paper actualizado de 2024, me di cuenta de que esta comprensión ya está desactualizada.
En las notas de actualización, lo dicen de forma muy directa: añadieron a Phoenix la capacidad de "permitir que el receptor identifique la identidad del remitente", y aclaran explícitamente que esta etapa convierte a Phoenix de un protocolo de anonimato (anonymity protocol) en un protocolo de preservación de la privacidad (privacy-preserving protocol), con el objetivo de cumplir con la normativa vigente de la Unión Europea. En el mismo documento también se menciona que la motivación directa para incorporar Moonlight (un modelo de cuentas transparentes) es que el equipo reconoció que, para integrarse fluidamente con exchanges e instituciones, un modelo de cuenta puramente anónimo no es suficiente; incluso escriben de manera bastante clara que lo hacen para "mantener el cumplimiento y eliminar el riesgo de que lo retiren".
Creo que este punto de inflexión es mayor de lo que la mayoría imagina. "Anonimato" y "privacidad" no son sinónimos en el ámbito de la criptografía: los protocolos de anonimato buscan que ningún tercero (incluido el receptor) pueda determinar quién es el remitente; los protocolos de preservación de la privacidad solo garantizan que los actores externos ajenos no vean los detalles, pero la capacidad de identificar a las partes involucradas puede mantenerse e incluso diseñarse de forma intencional. Dusk renuncia activamente a lo primero y elige lo segundo. Esto no es un compromiso técnico, sino un ajuste de posicionamiento de producto muy consciente: en los white papers tempranos, la ambición de Phoenix se acercaba más a una moneda de privacidad pura, pero más tarde se la llevó por delante la realidad regulatoria.
Antes pensaba que "el anonimato" era el atributo de venta más central de Phoenix; ahora, mirando hacia atrás, esa idea en sí misma es como evaluar un protocolo que ya evolucionó usando un white paper antiguo y desactualizado. Para quienes siguen usando el marco de "¿Dusk es una moneda anónima?" para juzgarlo, quizá el problema es que la pregunta ya está mal planteada: la verdadera cuestión es, bajo el supuesto de que el receptor puede identificar al remitente, dónde está exactamente el límite de privacidad que conserva Phoenix y si ese límite es suficiente para sostener los escenarios de cumplimiento institucional que pretende atender.

#termmax @TermMax TermMax Convierte cada posición apalancada en un GT, o sea, un ERC-721. La primera vez que vi este diseño no pensé mucho, hasta que me di cuenta de que un NFT puede transferirse: esto significa una "posición con deuda" que, en teoría, puede venderse a otra persona.

En una posición apalancada convencional, el riesgo y el rendimiento van atados a la persona que abre la operación: si pierde, lo asume ella; si gana, ella se lo queda. GT separa esto. Si un GT puede circular en el mercado secundario, el comprador no adquiere una "activos determinados", sino una "situación actual del ratio de colateralización + el riesgo de liquidación futuro". Quien esté dispuesto a hacerse cargo en última instancia, en esencia, está poniendo precio a la salud actual de esa posición; no es muy diferente de comprar un bono con descuento, solo que el colateral y la estructura del apalancamiento son mucho más complejos que en el caso de un bono.

Si el diseño de TermMax realmente llegara a funcionar, crearía una nueva conducta de trading: habrá personas que compren a un precio bajo esos GT cuyo LTV ya está relativamente alto, pero que todavía no han activado el LLTV, apostando a que podrán encontrar un comprador antes de la línea de liquidación, o apostando a que son capaces de gestionarlo mejor que el tenedor original. Suena a que el riesgo se está derivando hacia un intermediario más profesional, pero también podría ser simplemente que el riesgo de liquidación se mueva de manos de una persona no profesional a las de otra igual de no profesional, solo que se atreve a apostar más.

Lo que más me gustaría aclarar es esto: en el mercado secundario de GT, ¿existen realmente registros de traspasos? Cuando se transfieren, ¿la información sobre el estado actual del colateral es simétrica entre comprador y vendedor, o es que esta "transferibilidad" actualmente solo existe a nivel de contrato y, en la práctica, nadie lo usa así? Que una posición de TermMax pueda negociarse y que efectivamente se haya negociado son dos cosas completamente distintas.

#dusk $DUSK @Dusk Siempre que veo una introducción a la economía de los tokens de Dusk, aparece repetidamente una frase: "500 millones de DUSK se liberarán gradualmente a los stakers durante 36 años". La frase suena como si describiera una curva de liberación extremadamente gradual, casi imperceptible en cuanto a presión inflacionaria. Yo antes lo entendía así también, hasta que calculé por mi cuenta los parámetros de la documentación oficial y descubrí que no es tan sencillo.
El suministro máximo total de Dusk es de 1.000 millones de monedas; de esos, 500 millones ya entraron en circulación antes del lanzamiento en la red principal. Los otros 500 millones se liberan a los stakers durante 36 años siguiendo un modelo de decaimiento en progresión geométrica, con una tasa de decaimiento que se reduce a la mitad cada 4 años. Ese "cada 4 años se reduce a la mitad" es la información clave: si expandes toda la secuencia de decaimiento como una progresión geométrica, la cantidad liberada en el primer ciclo de 4 años es aproximadamente la mitad de los 500 millones restantes, es decir, alrededor de 250 millones. Con una conversión aproximada, el promedio de liberación por año durante los primeros 4 años sería aproximadamente más de 4 veces la "tasa de inflación promedio" que saldría de repartir los 500 millones en 36 años.
Dicho de otra manera, "liberación lenta durante 36 años" no miente por sí sola, pero puede llevar a asociar de forma automática la idea de que "la velocidad de acuñación anual es casi la misma y muy suave". En la realidad, la presión de emisión se concentra mucho más en los primeros años; luego, cada vez que se cumple un nuevo período de 4 años, la velocidad de liberación se reduce a la mitad. La curva es una caída pronunciada, no una línea horizontal. Para las expectativas reales sobre el rendimiento de las recompensas por staking, esta diferencia no es un detalle sin importancia: quienes participan al principio reciben recompensas del tramo que libera más rápido; cuanto más tarde se entra, más delgado se vuelve el componente de nueva emisión del que se puede participar.
No creo que sea un defecto de diseño. El decaimiento en progresión geométrica es una práctica común en muchas redes PoS: se usa para dar suficientes incentivos al inicio y hacer crecer la red de validadores; después, se va reduciendo gradualmente la inflación. Pero si solo miras el número "36 años" y das por hecho que la presión inflacionaria se distribuye de manera uniforme, podrías pasar por alto la realidad. El siguiente punto que voy a observar es alrededor del primer nodo de decaimiento de 4 años contando desde 2026 hacia adelante: voy a verificar los datos reales de pago de recompensas por staking en la cadena para ver si coinciden con la curva teórica de este modelo geométrico. Si coincide, significará que el equipo ejecuta de forma estable el modelo económico del whitepaper; si hay desviaciones, será otra señal que habrá que reevaluar.

#termmax @TermMax Al principio, tomé el sistema de puntos de TermMaxFi como una mecánica de “airdrop” convencional: a más uso, más puntos. Hasta que vi una publicación oficial en la que se enfatizaba que XP y MP no son lo mismo; entonces me di cuenta de que en este diseño hay una cuestión más valiosa para analizar: a quién quiere premiar el protocolo.
XP corresponde a qué tan profundo usas el protocolo: cuánto has depositado, cuánto has pedido prestado y cuánto tiempo has mantenido tus posiciones; son datos puramente de uso. MP corresponde a cuánta influencia generas fuera del protocolo: se parece más a la contribución de difusión y captación. Al calcular ambas curvas por separado, un usuario que solo pide prestado en silencio sin hacer publicaciones obtiene una lógica de distribución de airdrop totalmente distinta a la de otro que publica todos los días, pero con un tamaño de posiciones on-chain muy pequeño.
Este diseño me parece bastante honesto: al menos no empaqueta directamente el ruido de marketing como “actividad del protocolo” para engañar. Pero también trae un problema nuevo: si el peso de MP es demasiado alto, la plataforma puede acumular fácilmente el volumen social antes de que exista un aumento real de préstamos correspondiente; así, el número de TVL se ve bien, mientras que el volumen de préstamos on-chain que realmente se empareja, con la tasa fija correspondiente, quizá no crezca al mismo ritmo. TermMaxFi logró este año un TVL de casi 35 millones de dólares: la cifra, en sí, ¿la empujó más el XP, o la atención impulsada por MP elevó el conjunto? Merece analizarlo por separado.
A continuación voy a fijarme en dos cosas: qué tan alta es la coincidencia entre los usuarios del top de XP y los del top de MP, y después de que termine el ciclo del sistema de puntos y caiga el airdrop, si el volumen de préstamos on-chain baja de forma notable. Los airdrops pueden activar la actividad, pero no necesariamente aumentan la retención.

#dusk $DUSK @Dusk Cuando vi por primera vez la noticia sobre la colaboración entre Dusk y 21X el año pasado, mi reacción inmediata fue: "Dusk también recibió la licencia del régimen piloto de DLT (DLT Pilot Regime) de la Unión Europea". Para confirmarlo, volví a ordenar la línea de tiempo y descubrí que había entendido mal la mitad.

Primero, pongamos el contexto: el régimen piloto de DLT es una ventana regulatoria temporal que la UE abre para infraestructuras de liquidación y negociación basadas en DLT (DLT). Permite que una institución haga a la vez dos cosas: el emparejamiento/ejecución de operaciones y la liquidación, sin tener que buscar por separado un depósito central de valores, como en el modelo tradicional. 21X es una empresa alemana que a finales de 2024 se convirtió en la primera institución en obtener una licencia de este tipo de "sistema de liquidación y negociación DLT" (DLT-TSS), operando sobre Polygon.

Y la colaboración entre Dusk y 21X, en palabras oficiales, dice: "Dusk se incorporará como participante en las operaciones (trade participant)" y, al mismo tiempo, "obtenemos el derecho de exención regulatoria para utilizar su infraestructura a nivel institucional de blockchain". Es decir, la licencia la mantiene en todo momento 21X; Dusk se apoya en esa exención regulatoria mediante la colaboración, en vez de que también haya obtenido por su cuenta una licencia de DLT-TSS. Esto es completamente distinto a mi impresión inicial.

Si nos vamos aún más atrás: en marzo de 2024, Dusk y NPEX ya estaban preparando una solicitud conjunta para la elegibilidad del régimen piloto de DLT, lo que indica que esta ruta regulatoria, al menos, la han pensado durante más de dos años y no fue improvisada. Sin embargo, según la información pública más reciente que pude consultar, en el nombre propio de Dusk no aparece ningún registro de una licencia independiente de DLT-TSS. En el sitio web oficial de 21X, además, se indica de forma explícita que, por ahora, en toda la UE solo 21X y la CSD Prague de Praga (ambas instituciones) tienen esa licencia.

Los criterios que me puse para juzgarlo son: si dentro de un año Dusk (o NPEX, con el que está profundamente vinculado) logra que aparezca en su propio nombre una licencia independiente de DLT-TSS —o una licencia equivalente—, entonces significa que la ruta regulatoria realmente está funcionando; si en cambio permanece siempre en la fase de "acceder a la licencia de otro como participante", entonces esta narrativa pierde fuerza y se parece más a estar en cola para conseguir una licencia propia, en lugar de ser algo que ya se tiene en la mano.

Al revisar los acuerdos de préstamo con interés fijo, antes solo me fijaba en el número de APY, hasta que desentrañé la lógica de liquidación de @TermMax y descubrí que lo realmente digno de analizar no es la tasa, sino cómo maneja el asunto de "no poder pagar al vencimiento".

La lógica de liquidación en los acuerdos tradicionales es bastante brusca: si el valor del colateral cae por debajo de un umbral, se vende directamente para obtener stablecoins; cuanto mayor sea la volatilidad, más duro es el deslizamiento. En ese escenario, el prestatario y el liquidador pueden salir perjudicados por igual. TermMax adopta la idea de la entrega física (physical delivery): en condiciones de mercado extremas o cuando falta liquidez, el colateral se entrega directamente al prestamista, en lugar de pasar primero por un "golpe" al mercado y recién después liquidar. La lógica detrás es que, en vez de malvender activos en medio del pánico y causar un daño adicional, es mejor convertir la liquidación en una entrega de activos perfectamente definida.

Su estructura de tres tokens también gira en torno a este enfoque: el prestatario deposita el activo para acuñar GT (un ERC-721 que empaqueta el colateral y la deuda en una sola posición), y al mismo tiempo emite FT para representar el principal e intereses que se deben pagar al vencimiento. El FT se descompone en dos partes: el principal y la parte de intereses. La porción de intereses se vende al prestamista para convertirse en XT, mientras que la porción de principal se deja para el prestatario. Lo que antes era un ciclo de préstamos repetidos que se movía entre varios protocolos, ahora queda reducido a una sola operación.

Esta arquitectura también se está integrando hoy en escenarios de colateralización con acciones tokenizadas: en la cadena BNB se han hecho pruebas con opciones y estrategias de covered call (compras cubiertas) para parte de los activos, lo que indica que no pretende atender solo a activos nativos de cripto.

Aun así, tengo que ser claro: el mecanismo de physical delivery funciona principalmente bajo volatilidad normal en la actualidad. La prueba real está en un escenario extremo: si el colateral puede entregarse de manera fluida y puntual al prestamista; y si, bajo un despliegue entre cadenas, la liquidez alcanza para sostener ese eslabón. Todavía no he visto datos suficientes para un ciclo largo.

A continuación voy a vigilar dos indicadores: el historial real de entregas de posiciones GT bajo condiciones de mercado extremas, y si la liquidez de liquidación on-chain en cada cadena acompaña al mismo ritmo. El compromiso de tasa fija se puede escribir con facilidad; la capacidad de entrega es la verdadera prueba. #TermMax

Tengo un hábito: cuando veo un proyecto, no miro primero lo que dicen los KOL. Primero voy a la web oficial para encontrar cifras que se puedan verificar. La semana pasada revisé con detenimiento la web oficial de Dusk y vi varios números; después de comprobarlos, la sensación es bastante compleja.
En la web dicen que la cantidad confirmada de emisión es de 300 millones de euros o más, que el alcance a inversores es de 50.000 o más, y que la cantidad de DUSK pignorado es de 210 millones o más.
Mi primera reacción no fue emoción, sino duda. ¿Qué criterio es ese para el número de 300 millones de euros? ¿La “emisión confirmada” se refiere a activos que ya se han emitido efectivamente on-chain, o a que se ha firmado una carta de intención pero aún no se ha subido a la cadena? Estas dos cosas se diferencian muchísimo: la primera es un hecho real; la segunda, solo es un número en el “pipeline”.
Pero lo comparé con otros proyectos del mercado que no paran de gritar “entrada de RWA a escala de billones”, y lo interesante de ese dato de 300 millones de euros no es lo grande que sea, sino que es un número que puede ser cuestionado. Puedes preguntar cuál es el criterio, qué componentes de activos forman esos 300 millones, y si después de la emisión hubo actividad en el mercado secundario. Un número que puede someterse a preguntas aporta más información que una narrativa grandiosa pero vaga.
Lo que de verdad cambió mi forma de juzgarlo fue otra cosa. La hoja de ruta de Dusk en estos años no consiste en cambiar una narrativa cada pocos meses, sino en ir construyendo capa por capa: la capa de consenso, la capa de ejecución, la emisión de activos, las operaciones y las interfaces de regulación. El ritmo es lento, pero en cada paso se pueden encontrar registros correspondientes en las actualizaciones de ingeniería.@Dusk
Si un proyecto, en años sin mucho “hype”, sigue masticando cosas poco atractivas como licencias, reglas de activos y detalles de liquidación, lo más probable es que su función objetivo no sea la atención a corto plazo. A este tipo de proyectos estoy dispuesto a darles más tiempo: no porque tenga que salir bien, sino porque lo que están haciendo, si llega a buen puerto, es algo que de verdad es difícil de replicar.
#dusk $DUSK

Esa actualización de Aegis, la de $DUSK : yo estuve pendiente del panel de nodos hasta quedarme despierto esa misma jornada. Según lo dicho por la oficina, es muy directo: "una actualización obligatoria para todos los operadores de nodos". Si no te actualizas, el nodo sale directamente de la red cuando se active el hard fork, sin periodo de transición opcional.
Revisé el registro de cambios de Rusk v1.7.0 y encontré que en esta actualización se esconde una corrección discreta pero bastante clave: en dusk-wallet-core, "evitar que la agregación de saldos de Phoenix ocurra con un overflow en u64". En otras palabras: el código anterior del monedero, al sumar los saldos de Phoenix (el modelo de cuentas cifradas UTXO de Dusk), en teoría podía sufrir un desbordamiento numérico y "volver" a un número muy pequeño o incluso incorrecto. Esta actualización elimina ese riesgo. Dentro del mismo lote de cambios también se incluye el cambio de la verificación de pruebas PLONK a la versión V3, se añadió un límite de tamaño al cuerpo de las solicitudes HTTP para prevenir un DoS por falta de memoria, y en el flujo de recuperación se cerró una vulnerabilidad de escritura por cruce de rutas ZIP inseguras. Todo eso son acciones típicas de "refuerzo de seguridad para un sistema de nivel producción": no son mejoras funcionales, sino labores de despeje.
Como operador de nodos, lo que más me preocupa en realidad es el riesgo que supone la propia ventana de actualización: la altura de activación de Aegis en la red principal es 3.590.904, y en la red de pruebas es 2.773.727; está fijada por altura de bloque, no es una ventana blanda tipo "cuando termines de actualizar, entonces entra en vigor". Si una parte de los nodos no alcanza a completar la actualización antes de esa altura de bloque, ¿podría la red mostrar por un momento una inconsistencia de consenso por la bifurcación? La versión oficial dice que "es una actualización de infraestructura para allanar el camino de DuskEVM y no involucra economía de tokens"; suena a que el impacto es controlable, pero una hard fork obligatoria, por sí misma, siempre es una prueba real de riesgo de coordinación para una red que no es muy descentralizada y en la que aún no hay demasiados nodos. #dusk
Esta actualización se desplegó sin problemas; en cierto sentido, antes de que @Dusk empiece a correr oficialmente DuskEVM, ya hicimos una prueba de carga para someter a prueba el consenso subyacente y la capa de almacenamiento. La actualización en sí no tuvo fallos, pero esas cuatro palabras: "hard fork forzado", merecen que cada persona que vaya a operar un nodo o que dependa de la determinación del procesamiento de Dusk en la liquidación le eche un vistazo extra.

#dusk La primera vez que mucha gente se topa con el término RWA, suele asumir que solo existe una forma de hacerlo: empaquetar un activo del mundo real en forma de token, y luego negociarlo en la cadena. Yo también lo entendía así, hasta que vi cómo @Dusk separa la “tokenización” y la “emisión nativa” como dos cosas distintas, y entonces me di cuenta de un detalle que se suele pasar por alto.

Tokenización, dicho sin rodeos, es poner una capa de espejo digital sobre un activo que ya existe: un edificio, un bono, un fondo. Primero existe dentro del sistema tradicional, y luego algún intermediario se encarga de empaquetarlo para convertirlo en un comprobante en cadena. En medio de todo esto hay un salto natural de confianza: en realidad, no es el código de la cadena lo que estás confiando, sino si ese intermediario encargado de “empaquetar” es honesto al cumplir, si de verdad mantiene en su poder el activo subyacente correspondiente. Aunque la cadena esté “limpia”, esa dependencia no se puede eliminar.

La emisión nativa es otro camino: hacer que el ciclo de vida del activo ocurra desde el principio dentro de la cadena. La emisión, la circulación, la liquidación y la asignación de derechos, procurando volver lo menos posible a los sistemas tradicionales con pasos intermedios poco transparentes. Esto no significa que las instituciones tradicionales vayan a desaparecer, sino que cuando dichas instituciones tienen las calificaciones correspondientes y la capacidad de diseño de productos, la infraestructura on-chain puede asumir más procesos que deberían pertenecer al activo en sí, y no solo funcionar como una capa de espejo posterior.

La infraestructura que ofrece Dusk está pensada para soportar simultáneamente estas dos rutas: puede gestionar la tokenización como una forma de transición, y también asumir, cuando las condiciones estén maduras, los flujos de trabajo de la emisión nativa. Me parece bastante honesta esa postura de “no asumir una única respuesta”, porque el ritmo de cumplimiento de las instituciones, el diseño de productos y las autorizaciones regulatorias no son iguales, y es imposible que una sola plantilla encaje en todos los escenarios.

La emisión nativa suena como un objetivo más lejano, pero en realidad apunta a una pregunta muy sencilla: ¿quién debe probar la “verdad” de un activo? $DUSK plantea una apuesta en la red: que el proceso de verificación ocurra, en la medida de lo posible, directamente en la cadena, y no dependa de una promesa de un intermediario.

#dusk $DUSK La verdad es que, al principio, me cansaron un poco esas cuatro palabras de “RWA en la cadena”: en estos años ya he escuchado demasiados proyectos gritar ese eslogan y, al final, muchas veces solo se materializa en una captura de pantalla y un par de frases sobre visión; no resiste un examen detallado, y mucho menos el escrutinio de los reguladores. Pero esta vez, cuando leí los detalles de la colaboración entre @dusk y el exchange holandés NPEX, mi postura cambió.
NPEX no es un término inventado. Es un exchange con licencia regulado por la Autoridad de Mercados Financieros de los Países Bajos (AFM), y además cuenta con licencias de MTF, bróker y ECSP. Detrás de esas siglas hay un sistema real de regulación financiera europea que existe desde hace años y que ha sido comprobado repetidamente; no son conceptos armados a la ligera ni cualificaciones que se autoproclamen con un simple whitepaper. Este plan de colaboración irá moviendo gradualmente más de 300 millones de euros de activos a la cadena de Dusk, y la capa de aplicación que gestionará esos activos es Dusk Trade.
Dusk Trade se posiciona como un “nuevo tipo de bróker”, operando sobre DuskEVM. Su objetivo es convertir activos tradicionales como fondos del mercado monetario, ETF y bonos en activos on-chain que puedan poseerse de verdad, liquidarse de forma inmediata y además permitir combinaciones y estrategias de DeFi. También está siendo construido con una arquitectura de cumplimiento normativo acorde con la normativa de la UE aplicable, hacia un enfoque de MTF regulado y plataformas de inversión, en lugar de lanzarlo primero y completar la documentación después. Esa elección en el orden de los pasos por sí sola ya muestra cierta actitud.
Me di cuenta de que este relato no tiene nada que ver con “emitir tokens por parte de algún equipo anónimo”. Se parece más a cómo las instituciones financieras tradicionales prueban con cuidado una nueva puerta: y al otro lado de esa puerta tiene que haber licencias, auditorías y un camino de cumplimiento trazable; @Dusk quiere ser parte de esa ruta, no atajarlo. Por eso estoy dispuesto a invertir tiempo para entenderlo.
No es una historia que se haga realidad de la noche a la mañana. La regulación financiera en Europa nunca ha sido un juego de ritmo rápido: licencias, auditorías y coordinación transfronteriza requieren tiempo, y cualquier promesa que se salte esos pasos merece dudar un poco más. Pero cuando vi que “exchange con licencia” y “liquidación on-chain” se escriben por primera vez en el mismo comunicado de colaboración, vale la pena seguir de cerca cómo se materializa después, especialmente el día en que esos 300 millones de euros de activos se migren de verdad.

$BABY 的 período de des-encolado (desvinculación) que diseñé/estudié a fondo: después descubrí que hace una elección bastante intencional entre proteger la seguridad de la red y la liquidez de los usuarios.
En los protocolos de staking, el diseño del período de des-encolado suele discutirse como un problema de experiencia de usuario: esperar demasiado es molesto y se quisiera que fuera más rápido. Pero revisé en serio la lógica del período de des-encolado de @BabylonLabs_io desde la perspectiva del diseño de seguridad, y encontré que las razones para que exista son mucho más profundas que solo limitar la liquidez; además, en ese diseño hay una compensación que creo que vale la pena explicar con cuidado.
El papel más central del período de des-encolado es reservar tiempo para que se ejecute el mecanismo de slashing (penalización). Si un proveedor de pruebas definitivo firma con doble firma, es necesario detectar la evidencia, publicarla en la cadena y, luego, activar la transacción de slashing. Toda esta secuencia tarda en completarse en la cadena. Si no existiera el período de des-encolado, un validador malicioso podría retirar todo el BTC en staking antes de que la evidencia se presente; en ese caso, el slashing sería prácticamente ineficaz. En esencia, el período de des-encolado dice: tu BTC puede salir, pero tendrás que esperar ese tiempo; durante ese tiempo, si se descubre que el validador al que delegaste se comportó mal, todavía hay oportunidad de ejecutar la sanción.#baby
Desde este punto de vista, el período de des-encolado no es una concesión para la experiencia de usuario, sino un requisito previo para que todo el mecanismo de seguridad pueda funcionar. Sin período de des-encolado, el slashing no tiene dientes; sin dientes, la amenaza del slashing no es real y las restricciones sobre la conducta de los validadores se debilitan de forma considerable.
Pero aquí hay una compensación que creo que debe explicarse. Cuanto más largo sea el período de des-encolado, más amplio será el “ventana de seguridad” y más confiable será el slashing. Cuanto más corto, mejor será la liquidez del usuario y menor fricción habrá para participar. Babylon fija el período de des-encolado mínimo en alrededor de 7 días; ese número surge de buscar un equilibrio entre dos objetivos, no de una restricción técnica puramente.
Para quienes mantienen BTC a largo plazo, esos 7 días casi no tienen efecto. Para los traders de corto plazo, en cambio, sí representan un costo real de liquidez. Esto significa que el staking de Babylon, en términos de composición de usuarios, se auto-filtra: favorece a los tenedores a largo plazo más que a fondos de corto plazo. Desde la perspectiva de la estabilidad del protocolo, esta selección de usuarios es beneficiosa, porque los tenedores a largo plazo no des-encolan masivamente cuando hay volatilidad del mercado; por tanto, la estabilidad del TVL es mayor.