林木森Woody

#币安夏令营 ¡Vamos!

Esta semana volví a revisar la tokenómica de @Dusk . Yo solo recordaba “límite de 1.000 millones, reducción a la mitad cada cuatro años”. Al seguir la distribución de recompensas, descubrí que quienes proponen el bloque no se llevan toda la emisión de cada bloque. El primer período actual, según lo planeado, emite aproximadamente 19.8574 DUSK por bloque, y además la comisión por transacciones del bloque. El productor del bloque base recibe el 70%; según los créditos del certificado, como máximo puede sumar otro 10%. El fondo de desarrollo es 10%. El comité de verificación y el comité de aprobación reciben 5% cada uno. La parte que no se distribuye se quema.

Este diseño no busca resolver un APR único, sino hacer que las tres acciones de consenso—proponer, verificar y aprobar—tengan ingresos. Pero el problema cambia: si las comisiones de las transacciones on-chain son muy bajas, el presupuesto de seguridad depende principalmente de la emisión continua; y si la calidad de participación de los nodos es insuficiente, las recompensas adicionales no se completan y la nueva oferta real queda por debajo de la curva nominal. Por eso, al mirar $DUSK , no puedes multiplicar “cada bloque 19.8574” directamente por la cantidad de bloques, como si todos pudieran recibir una producción fija.

El modelo de largo plazo publicado es: una emisión inicial de 500 millones, y luego otros 500 millones en aproximadamente 36 años, con una oferta máxima de 1.000 millones; cada cuatro años se reduce a la mitad la tasa de emisión por bloque. Este tope es claro, pero “tener un límite” no significa que no haya dilución en el corto plazo: los primeros cuatro años son justamente la etapa con la emisión más concentrada. Por otro lado, la emisión temprana también sirve de verdad para comprar seguridad para nodos y comités; no debería borrarse solo con la etiqueta “inflación”.

Yo veo que la oferta que presenta #dusk debe observar tres cosas a la vez: la acuñación real, el porcentaje de staking activo y la proporción de las comisiones dentro de las recompensas. Solo cuando las comisiones y el uso real vayan tomando poco a poco el relevo del presupuesto de seguridad de la emisión, la reducción a la mitad no será simplemente un recorte de los ingresos de los nodos. ¿A ustedes les importa más tener fijada la oferta máxima por escrito, o que la red pueda seguir pagando los costos de seguridad después de que baje la emisión?

He desglosado el anuncio de colaboración entre @Dusk , NPEX y Chainlink y descubrí que lo que realmente va a aterrizar no es una frase de “RWA cross-chain”, sino tres tipos completamente distintos de canales de datos y de activos. CCIP se encarga de los mensajes entre cadenas y del movimiento de activos; CCT proporciona un camino controlado de burn/mint para tokens como $DUSK ; y DataLink envía a la cadena los datos oficiales del exchange de NPEX, mientras que Data Streams procesa actualizaciones de precios con menor latencia.

¿Por qué esta capa de datos es más complicada que “convertir bonos en tokens”? Los activos regulados no pueden limitarse a demostrar que en un contrato existe una cadena de participaciones. El mercado secundario necesita saber de dónde proviene el precio, si el emisor aún conserva control, a quién pertenecen las limitaciones de tasa cuando hay cross-chain y los permisos de actualización, y cómo se detienen los datos anómalos. El anuncio subraya que Dusk y NPEX conservan la propiedad del contrato del token y pueden configurar rate limit y una ruta de actualización; esto es capacidad de control para las instituciones, y también es algo que los usuarios comunes deben vigilar: permisos de gobernanza.

Viéndolo por el lado positivo, NPEX ofrece un escenario real de emisión y de trading; Chainlink aporta la interoperabilidad y la entrada a cotizaciones oficiales; y Dusk solo tiene oportunidad de conectar emisión, trading, liquidación y divulgación en una sola cadena. Por el lado negativo, también queda claro: colaboración, adopción de estándares y que el activo esté verdaderamente activo son tres cosas distintas. Si no hay cantidades de emisión verificables, operaciones, titulares y registros de rescate, cualquier “gran onboarding institucional on-chain” todavía es solo una fase de construcción.

Así que a partir de ahora voy a vigilar #dusk : no me limitaré a contar los logos de partners, sino que esperaré tres tipos de evidencias: un contrato de activos real, datos de mercado continuos y flujos de liquidación verificables. ¿Ustedes creen que lo más difícil de RWA es el cross-chain del activo, o es mantener que el precio on-chain, los derechos legales y el reembolso fuera de la cadena se correspondan siempre?

Estos días he redibujado los Core Components de @Dusk y recién así logré separar los tres nombres: DuskVM, DuskEVM y DuskDS. Al principio yo también creía que era simplemente “una cadena compatible con dos tipos de máquinas virtuales”, pero en realidad el reparto se parece más a tres capas: DuskDS se encarga del consenso, la finalidad y la disponibilidad de datos; DuskVM permite que los contratos Rust/WASM se ejecuten directamente en L1; y DuskEVM es un entorno de ejecución equivalente a EVM basado en OP Stack, delegando la liquidación y la publicación de datos en DuskDS.

Esto significa que los desarrolladores no tienen que elegir “a ciegas” entre dos opciones. Si ya existen contratos Solidity, y se cuenta con carteras y toolchains basadas en EVM, ir por DuskEVM reduce los costos; pero si se quiere tocar directamente activos de L1, el modelo de privacidad de Phoenix, capacidades de conocimiento cero o un control de protocolo más de bajo nivel, entonces DuskVM es la vía nativa. Las dos rutas comparten la base de liquidación, pero eso no implica que las funcionalidades y las suposiciones de seguridad sean idénticas.

Me preocupa bastante la idea de que “compatible con EVM = la ecología se trae automáticamente”. La compatibilidad solo reduce el umbral de despliegue; no sustituye la conexión de la wallet, un RPC estable, indexadores, liquidez y usuarios reales. Y al revés: enfocarse solo en lo nativo de Rust/ZK tampoco alcanza; las herramientas pueden resultar demasiado ásperas, y los desarrolladores no van a reescribir todos sus productos por pureza técnica.

Por eso observo los avances técnicos de $DUSK y veo que van a desglosar las métricas: si DuskEVM tiene aplicaciones Solidity de terceros; si DuskVM tiene contratos no oficiales; y si las rutas que llevan la liquidación a DuskDS son estables. Si la barrera de #dusk se sostiene, debería ser “quienes conocen las herramientas pueden entrar, y cuando se necesita privacidad aún se puede bajar más”, no tres nombres nuevos apilados juntos. ¿Ustedes elegirán primero la compatibilidad o las capacidades nativas?

Antes veía @Dusk hablando a la vez de Moonlight y Phoenix y pensaba que era como si hicieran dos sistemas: “transferencia normal” y “transferencia privada”, con funciones duplicadas. Pero al leer juntos la documentación del modelo de transacciones y las instrucciones de integración del exchange, descubrí que no era para presumir con dos modelos, sino una aceptación activa dentro de la misma capa de liquidación: algunos flujos de fondos deben ser públicos y otros no deberían exponer a todos ni el importe ni la relación.

Moonlight es un modelo de cuentas públicas: el saldo, el remitente, el destinatario y el importe se ven. Se adapta mejor a recargas del exchange, a tesorerías y a escenarios en los que es necesario realizar conciliaciones que deben ser públicas. Phoenix, en cambio, coloca los fondos en un note cifrado: mediante pruebas de conocimiento cero confirma que no hay doble gasto y que el saldo es suficiente, sin divulgar al espectador el importe concreto ni el note correspondiente; cuando se requiere auditoría, se puede revelar de forma selectiva mediante una viewing key.

Aquí está la confusión principal: “como hay privacidad, el navegador no puede ver nada”. El navegador oficial aún puede ver metadatos públicos como el bloque, el tipo de transacción, la comisión y el gas; el alcance exacto depende del modelo de transacciones y del contrato. Al revés, el exchange tampoco puede tratar Phoenix como Moonlight para hacer un barrido directo: la documentación oficial de integración sugiere explícitamente que la recarga se realice usando Moonlight; los saldos privados deben convertirse primero en cuentas públicas. La lógica de custodia y de barrido es completamente distinta.

Por eso, el verdadero reto de $DUSK no es demostrar que la privacidad se puede hacer, sino lograr que el usuario, al alternar entre lo público y lo privado, no tome el camino equivocado. Si #dusk va a entrar en flujos de fondos regulados, deben cumplirse simultáneamente: privacidad por defecto, divulgación bajo demanda y custodia predecible. ¿Qué os preocupa más: que la transparencia total filtre posiciones, o que los dos modelos eleven demasiado la complejidad del producto?

Esta semana revisé en orden toda la documentación del staking de @Dusk , desde activación hasta salida, y recién entonces me di cuenta de que las dos frases “mínimo 1000 DUSK, sin período de espera por acuerdo” son las que más fácilmente pueden malinterpretarse. No es que hagas staking simplemente tocando el token para recibir una tasa fija; en realidad hay que ejecutar un provisioner que esté en línea de forma continua y funcione correctamente. El rendimiento depende de si se te selecciona para participar en el consenso y de la proporción efectiva de stake, y no es una rentabilidad fija prometida por el protocolo.

La línea de tiempo también tiene matices. Un nuevo stake solo empieza a surtir efecto en el “límite del siguiente epoch y más allá”. Según las estimaciones oficiales basadas en el tiempo objetivo de producción de bloques, suele ser de unas 6–12 horas, pero lo más preciso es lo que muestra la wallet como “active from block”. La salida en sí no tiene un período de bloqueo del protocolo, pero no se te llevan automáticamente las recompensas acumuladas al mismo tiempo; retirar recompensas es otra operación.

Lo más contraintuitivo es el top-up adicional: después de que la posición original ya está activa, la parte añadida solo entra al estado active en un 90% de inmediato; el 10% restante se registra como locked stake. Lo bloqueado sigue siendo tuyo, pero no participa en el consenso. Si quieres recuperar esa cola, quizá necesites hacer unstake de toda la posición restante. Este diseño no está mal, pero hace que quienes solo miran el APR de la interfaz calculen mal la eficiencia del capital.

Los pools de terceros pueden eliminar la barrera operativa, pero el custodiado, los contratos, el operador y las reglas de salida pasan a ser otro conjunto de riesgos. Por eso, al considerar el staking de $DUSK , yo no solo preguntaría “¿cuánto rinde?”, sino también “¿quién controla el nodo, cómo se reparten las recompensas y cómo se maneja la parte locked?”. En cambio, los usuarios como #dusk quizá encajen mejor ejecutando su propio nodo, o aceptando el riesgo de una capa de pool para tener operaciones más simples.

Puse juntos el libro blanco de TMX y los documentos de incentivos del @TermMax , y encontré una pregunta que vale más la pena hacer primero que “¿cuánto cayó/voló en el airdrop?”: el tiempo durante el cual se escribió en el roadmap, ¿se puede considerar directamente como si el TGE ya hubiera ocurrido?

La respuesta, al menos con los documentos públicos actuales, no permite equipararlo.

El libro blanco de marzo de 2026 define TMX como un token de gobernanza y utilidad, con un suministro total fijo de 1.000 millones; se estima que la circulación inicial será de aproximadamente 20%. La tabla de asignación indica: ecosistema 29%, inversores 28%, equipo 15%, comunidad 15%, y el resto para liquidez, fundación y asesores. El roadmap coloca TGE, la liquidez en exchanges, la distribución y el pool de staking en el segundo trimestre de 2026.

Pero en la sección de parámetros de ese mismo libro blanco, la fecha de TGE sigue como “Por anunciar” (To Be Announced). El documento de preventa solo dice que lo acumulado por los usuarios es un monto no transferible todavía, y que después del TGE se reclamará en una proporción 1:1. La entidad oficial ya ha publicado direcciones de tokens en Ethereum y BNB Chain; esto sugiere que el contrato está preparado y hecho público, pero no prueba por sí solo que la generación, la reclamación y la circulación completa ya se hayan completado.

Esta diferencia es crucial. El despliegue del contrato es un evento técnico; el TGE es un evento de distribución; la apertura de depósitos/retiros y las operaciones en exchanges son eventos de mercado. Las tres cosas pueden suceder seguidas o con mucha distancia entre sí. Mezclar “la existencia de direcciones”, “caducidad del roadmap” y “hay números en la página” en una sola frase de “ya salió al aire” distorsiona la información.

Yo evalúo el progreso de TMX solo con cuatro señales: una hora de TGE claramente definida; una página y reglas oficiales de reclamación; la circulación que coincida con lo descrito en los términos dentro del explorador de bloques; y los anuncios propios del exchange sobre listado y depósitos/retiros. Si falta cualquiera de estos elementos, debe describirse según la fase real, sin completar los pasos posteriores “por el bien” del proyecto.

Los riesgos no se reducen solo a la fecha. El libro blanco especifica que el equipo tiene un cliff de 12 meses antes de liberar linealmente; los inversores también tienen un cliff de 12 meses y, después, una adjudicación durante 24 meses. Lo que realmente afecta al mercado no es solo el total de 1.000 millones, sino cuánta cantidad se libera en cada ventana, qué direcciones la reciben y si coincide con la tabla pública.

Por eso no voy a asumir, solo porque el trimestre del roadmap ya pasó, que el TMX de #TermMax “debería haber sido completado”. El roadmap es un plan; la distribución on-chain y los anuncios oficiales son el estado. Adivinar menos días de progreso que suponer más por una valoración imaginada es más útil.

Puse @Dusk , un nuevo monedero, y las instrucciones de Dusk Connect lado a lado, y recién así entendí que lo que han añadido no es “otra piel más de un monedero”, sino la capa de conexión que el dApp llevaba tiempo echando de menos. El antiguo Web Wallet puede hacer transferencias y apostar por separado, pero la aplicación no puede descubrir el monedero, solicitar cuentas, firmar y enviar transacciones mediante una interfaz unificada; los desarrolladores solo pueden adaptarse rodeando cada monedero en concreto.

Lo que hace Dusk Connect se parece mucho a estandarizar esa especie de “pegamento”: el descubrimiento del monedero toma como referencia la idea de EIP-6963; el RPC gestiona las cuentas, firmas, transacciones y solicitudes de red por espacio de nombres; y además prepara pruebas de consistencia para quienes implementan el monedero. El nuevo monedero oficial ya, desde el principio, sigue esta interfaz de provider para cubrir extensiones del navegador, escritorio y móvil; las transferencias públicas y privadas, shield/unshield, staking, cobro de recompensas, DRC-20 y DRC-721 se incluyen en una misma ruta de interacción.

El punto más fácil de que te desvíen los textos promocionales es equiparar “repositorio abierto” directamente con “producto maduro”. Por ahora, la posición oficial sigue siendo developer preview. La clave se guarda localmente; el lado de la extensión usa PBKDF2 y AES-GCM; el lado nativo usa Stronghold y Argon2. Todo eso es una base de seguridad correcta, pero lo que realmente determina la experiencia es la recuperación ante desconexiones, los avisos de permisos, la retroalimentación de transacciones fallidas y la consistencia del estado entre múltiples plataformas.

Esa es también la razón por la que últimamente miré #dusk sin quedarme solo en los términos del protocolo: sin una capa estable de conexión del monedero, por muy bonitos que sean los contratos de privacidad, solo sirven como demostraciones para desarrolladores. $DUSK necesita el siguiente paso no en forma de otra captura de interfaz, sino que un dApp de terceros pueda conectarse de manera realmente transparente. Cuando evalúan si un nuevo monedero sirve, ¿primero miran la tabla de funciones o primero ven cómo se comporta en escenarios de fallo?

Después de leer las notas de lanzamiento de la V2 de @TermMax , primero revisé la retrospectiva de su V1. Los “problemas” de los contratos de tasa fija quizá no sean que no haya cotizaciones, sino que el dinero se divide entre diferentes órdenes, mercados y páginas de la cadena: ver una tasa no significa que el importe completo pueda ejecutarse a esa tasa.

En la V1, las range orders del curador y las limit orders del usuario se muestran por separado. Si quieres tomar prestado una cantidad un poco mayor, tienes que comparar pedido por pedido y además asumir los cambios de precio que introduce cada tramo de profundidad. La tasa puede llamarse “fija”, pero el costo de entrar no necesariamente se ve claro de inmediato.

Lo que cambia en la V2 es justamente ese nivel. Las órdenes unificadas leen las órdenes por rango de la zona del curador y las limit orders individuales, y las combinan en una sola ruta de ejecución; el usuario ve una cotización, firma una vez y el sistema completa la combinación dentro de la liquidez del mismo mercado. Las limit orders también se habilitan para cada mercado: el prestamista publica la tasa mínima aceptable y el prestatario publica la tasa máxima que está dispuesto a pagar; no hace falta “comerse” el precio vigente en un libro poco profundo.

No es que haga la tasa aún más “fija”, sino que expone la fricción que existe en el order book. Por ejemplo, el mostrador muestra un precio, pero lo verdaderamente importante es si la cantidad que quieres puede comprarse a un precio cercano a ese. La V2 se encarga de armar las órdenes y luego entrega una ruta ejecutable.

Pero hay un límite que no se puede borrar de un plumazo. Lo que dice la versión oficial es que los mercados cross-chain y la tesorería (vault) se muestran, filtran y comparan en una misma interfaz; no se menciona que el capital de distintas cadenas se combine físicamente en un solo pool. La profundidad en Ethereum no va a “cruzar automáticamente” solo porque la página de Base también se pueda ver, para que te ejecuten la operación. La liquidez on-chain, el Gas, el tiempo de espera de las limit orders y el volumen realmente ejecutable siguen calculándose por separado.

Otro punto a observar es el desempeño con operaciones grandes. Que la ruta sea más fluida no significa que cualquier tamaño puedas conseguir el precio de la portada. Vale la pena vigilar las diferencias de cotización entre montos distintos, el tiempo de espera de las limit orders y cuántas fuentes se combinan en una sola operación; todo eso explica mejor la calidad de la ejecución que “cuántas cadenas soporta”.

Así que el valor de la V2 de #TermMax no es que la página se vuelva más simple, sino que separa “tasa determinada” y “ejecución determinada”. La primera la define el FT y el vencimiento; la segunda aún debe ser demostrada por la profundidad. La interfaz puede dibujarte el camino con claridad, pero si hay suficientes “autos” en la ruta, eso depende de la ejecución real.
$BOME $BTC

Estos días he revisado el análisis de seguridad de AEGIS de @Dusk . Al principio solo me quedó grabado: “39 correcciones, 7 críticas”. Después de leer los detalles, me di cuenta de que los números, cuanto más altos, no son lo importante. Los 7 problemas graves finalmente convergieron en 4 categorías de causa raíz: problemas de alias en el sandbox de la VM, deserialización insegura del lado del host, que los cargos y reembolsos de Phoenix no están completamente vinculados, y también una ruta de falsificación de firmas BLS.

¿Por qué hay que mirar las causas raíz, y no solo la cantidad de vulnerabilidades? Porque si el mismo límite de confianza no se dibuja bien, los problemas pueden “reaparecer” una y otra vez en módulos distintos. Por ejemplo: si la entrada no se valida y luego se deserializa, a simple vista parece un error de análisis; en realidad, podría acabar chocando con la seguridad de la memoria del host. El bloque de problemas de Phoenix tampoco es “solo un error pequeño en el cálculo de la comisión”: es que la demostración, las firmas y la ejecución de los reembolsos no comparten la misma semántica; en el peor de los casos, puede afectar la integridad del suministro y la seguridad de los fondos.

Oficialmente se dice que, por el momento, no se han detectado estos críticos aprovechados antes de que se corrigieran. Quiero tomarlo como conclusión de investigación, y no lo convertiré en “no ocurrió absolutamente”. Para $DUSK , la señal positiva de AEGIS es que el equipo hizo público lo que detectó internamente, junto con las causas raíz y la lógica de la reparación. La señal negativa también es clara: tras el lanzamiento en mainnet, el stack central realmente tuvo brechas de alto riesgo que podían afectar la ejecución, la autenticación de consenso y la disponibilidad de la cadena.

Así que no usaré “muchas auditorías” para ponerle a #dusk un sello de seguridad directamente. Lo más útil es observar esto: ¿en la siguiente ronda se seguirá divulgando?, ¿hay pruebas de regresión para los límites del mismo tipo?, ¿la auditoría externa puede cubrir el código después de AEGIS? ¿A ustedes les importa más que nunca se hayan filtrado problemas grandes, o que, después de que se filtren, se puedan explicar bien las causas raíz, el impacto y la cadena de la reparación?
$USELESS $BOME

He revisado de nuevo el documento de tipo de interés fijo del @TermMax . Lo primero que me detuvo no fue cómo se calcula el tipo, sino un problema más básico: el coste de los fondos de un préstamo on-chain cambia cada día; entonces, ¿por qué fija por adelantado la tasa de una deuda a la fecha de vencimiento?

Si la respuesta fuera solo “el acuerdo no se modifica”, entonces no habría mucho que investigar sobre este interés fijo. Sigue leyendo y verás la relación entre FT, XT y GT, y ahí la lógica queda completa.

FT es el comprobante que permite canjear el activo de deuda al vencimiento por su valor nominal. El prestamista compra FT con descuento; al vencimiento, lo canjea por el valor nominal, y la diferencia es el rendimiento que se bloquea anticipadamente. XT es la parte complementaria. La relación que da el documento es: en cualquier momento, 1 FT + 1 XT equivalen a 1 unidad del activo de deuda. El prestatario convierte el importe que tendrá que devolver en el futuro en FT, y luego vende la parte de intereses a través de una orden: hoy recibe liquidez y el coste queda determinado en el momento de la operación.

GT se parece más a una “envoltura” de posición. Es un ERC-721 que registra el colateral y la deuda, en lugar de recrear una “moneda de rendimiento” que pueda circular libremente. Todo lo necesario para una posición apalancada —cuánto colateral se requiere, cuántos FT se deben y cuándo vence— queda empaquetado dentro del mismo estado en la cadena.

Dicho de forma más intuitiva: el pool de tipo flotante tradicional sigue recalificando la deuda después de pedir el préstamo. TermMax, en cambio, primero convierte “cuánto habrá que devolver al vencimiento” en un crédito negociable, y después el mercado decide con cuánto dinero está dispuesto a comprarlo hoy. Lo fijo no es el precio del activo ni que el colateral vaya a estar siempre a salvo; lo fijo es el tiempo y el coste de esa deuda después de la operación.

También hay un límite que es fácil que quede oculto por la publicidad. El tipo fijo no significa que no haya liquidaciones. Los documentos oficiales del Market aún fijan MLTV y LLTV; si el precio del colateral cae o el activo de deuda aumenta de valor, y el LTV llega al LLTV, la posición igual entra en liquidación. Lo que elimina es la incertidumbre de un salto brusco en el tipo de interés, no elimina la volatilidad del colateral, ni los riesgos del oráculo, ni el riesgo de pago al vencimiento.

Así que cuando ahora miro el #TermMax , no pregunto primero si el APY es alto o no; primero observo la fecha de vencimiento del FT, la profundidad de la operación y qué tan lejos está GT de la línea de liquidación. Si entiendes “tipo fijo” como “no pasará nada”, te estás desviando. Lo que fija es solo una de las partes del precio de la deuda que es más difícil de presupuestar.
$CLO $ETH

Revisé otra vez, este año, el informe de la re-ejecución del puente entre cadenas, con el número de revisión @Dusk . Lo más valioso que se puede ver no son las dos palabras “fue robado”, sino en qué capa ocurrió exactamente la falla. El 16 de enero el problema estuvo en la wallet de firmas usada por el servicio del puente: el atacante, después de obtener permisos para liberar préstamos, transfirió los activos desde el lado de Dusk y luego envió una parte hacia BSC. La versión oficial es clara: esto no fue un fallo de consenso ni una brecha del protocolo de la capa L1.

Pero eso no significa que la capa base esté bien y que los usuarios deban ignorar el riesgo del puente. La arquitectura antigua concentraba la recepción de eventos, las firmas y la liberación de fondos en una sola ruta: es rápida, sí, pero si el lado de las firmas cae, los permisos quedan demasiado centralizados. El rediseño posterior separó esas tres cosas: primero el evento se guarda como una tarea y el worker la procesa según la máquina de estados; las transacciones originales firmadas se guardan primero y, si falla, se reejecuta la misma; la wallet caliente solo conserva el saldo necesario para el periodo reciente, si baja del umbral se pausa, y la wallet fría se completa manualmente.

Antes yo también era fácil caer en la frase de “el puente no es un protocolo” como si fuera una excusa. Ahora prefiero verlo al revés: siempre que el usuario lo trate como una puerta de liquidez, el puente ya está entrando en el límite real de seguridad $DUSK . La seguridad del consenso on-chain y la seguridad de las entradas/salidas de activos son dos exámenes que deben aprobarse al mismo tiempo.

La dirección de la mitigación en esta ocasión es correcta, pero el punto de riesgo no desaparece: hay que seguir vigilando si el aislamiento de claves se ejecuta a largo plazo, si el umbral es razonable, y si el apagado y el reabastecimiento pueden auditarse. #dusk En la comunidad, la pregunta que más deberían hacer no es “¿la cadena fue hackeada?”, sino “¿cuál de esas llaves todavía tiene un poder que excede lo necesario?”. Ustedes, cuando miren un puente entre cadenas: ¿primero miran la auditoría del código o primero miran cómo se recortan los permisos operativos?
$TREE $ETH

我今天顺着 @TermMax 文档里的FT、XT、GT画了一遍资金流，画到第三个箭头时就想笑：一笔固定期限借贷，怎么被拆成了三套代币？设计确实精巧，可普通用户到底该盯哪一个？

我先把逻辑捋直。FT像零息债券，到期能按面值换回债务资产；XT补上FT折价的那部分，协议定义里始终是1 FT加1 XT对应1份债务资产；GT则是ERC-721，装着抵押物和债务头寸。借款人锁抵押物、铸FT，再把FT拆成本金部分和利息部分去换XT，最后拼回想借的资产。纸面上闭环挺漂亮，我承认这比“利率凭空写在页面上”更可验证。

可我越往下看越犯嘀咕。FT价格会随剩余期限和市场曲线变化，XT到期价值归零，GT又承担清算风险。三个代币分别记期限、利息和抵押债务，TermMax把一笔贷款拆得很透明，也把用户需要理解的状态拆得更碎了。页面上一键成交，不代表链下脑子也能一键理解吧？

更关键的是，借款人可以直接拿债务资产还，也可以买折价FT还。听着灵活，可这意味着提前退出的成本不只看最初锁定的利率，还要看FT市场有没有深度、当时曲线给什么价格。固定利率解决的是合同确定性，退出价格仍然得跟市场谈。

我又对照了一下到期端。FT正常情况下按面值赎回，可借款人逾期、清算又没在窗口里处理干净，赎回池就可能混入抵押物。也就是说，FT像债券不假，信用保护却不是某个机构承诺兑付，而是抵押率、预言机、清算人和市场流动性一起接力。少看一棒，结论都可能跑偏。

所以我研究 #TermMax 后最想看的，不是再来一张“固定APY”海报，而是每个仓位把FT、XT、GT的变化和最差退出路径讲人话。复杂机制可以藏在一次点击后面，风险要是也跟着藏进去，那这层简化到底是在服务用户，还是只服务成交？
$PRL $CLO

Hablemos de algo que no es tan “sexy”, pero que en realidad determina si la red puede funcionar a largo plazo: la emisión y el staking de $DUSK . Después de revisar el documento más reciente de @Dusk , vi que muchas discusiones solo se fijan en “la oferta máxima de 1.000 millones”, pero ignoran que esos 1.000 millones no entran al mercado de una sola vez.

El modelo de Dusk es de 500 millones como oferta inicial, y libera otros 500 millones durante 36 años como recompensas de la red; la emisión sigue una cadencia geométrica decreciente, con la reducción a la mitad cada cuatro años. El uso del token, por ahora, es bastante directo: pagar Gas, participar en el staking y proteger el consenso. Convertirse directamente en Provisioner requiere al menos 1000 DUSK en staking, además de mantener el nodo en línea y sincronizado de forma continua. La configuración base que da la autoridad no es exagerada, pero las recompensas se generan según la participación en el consenso y la probabilidad de staking efectiva; no es “depositar y cobrar intereses fijos”.

Lo razonable de este diseño es que vincula el uso de la red con el presupuesto de seguridad. Las recompensas del bloque se componen de la emisión por nuevos tokens y de las comisiones de transacción. En las primeras etapas se incentivan nodos con subsidio por emisión; más adelante, dependerán cada vez más de comisiones reales. Si el uso de la cadena crece, el presupuesto de seguridad puede pasar gradualmente de “emitir monedas nuevas” a “los usuarios pagan por el servicio”, y ahí es donde la lógica cierra.

Pero el riesgo también es claro. Que se emitan durante 36 años significa que la dilución a largo plazo no puede evaluarse solo con eslóganes sobre el total; además, el requisito de mínimo 1000 unidades más las exigencias operativas dejará a fuera a parte de los tenedores pequeños. Y como las recompensas son probabilísticas, también se puede malinterpretar fácilmente como un rendimiento anual estable. Lo más importante es que, si no despegan los ingresos de transacciones y aplicaciones on-chain, entonces las comisiones no podrán “relevar” a la emisión, y la seguridad de la red seguirá dependiendo principalmente de los subsidios.

Por eso, al observar a #dusk , no miraré solo si la proporción de staking es alta, sino que pondré tres indicadores juntos: si los Provisioner activos están dispersos o concentrados, la proporción de las comisiones de transacción reales dentro de las recompensas, y si los nodos pueden permanecer en línea de forma estable después de la actualización. Mirar únicamente el volumen bloqueado puede verse muy bien, pero si se bloquea mucho y nadie lo usa, solo se esconde liquidez y no se demuestra demanda.

¿Crees que en la etapa temprana de una red nueva se debería priorizar aumentar la participación en el staking, o primero impulsar que existan comisiones reales? Deja tu orden. $ETH $RED

Revisé de nuevo el mecanismo de tasa fija de @TermMax , y cuanto más lo miro, más siento que las palabras “tasa fija” pueden relajar la vigilancia. Sí, la tasa se puede fijar en el momento del cierre, pero ¿mi resultado final también quedó “fijado” de verdad?

Primero, hablemos del préstamo. TermMax fija, en cada mercado, el activo de deuda, la garantía y la fecha de vencimiento. El prestatario bloquea la garantía en GT y luego acuña FT que representa la deuda con vencimiento. Los costos no saltan al azar según la utilización, eso lo acepto: al menos no tengo que vigilar a medianoche las tasas variables de préstamo. Pero en cuanto el LTV toca el LLTV, la posición igual entra en el proceso de liquidación. Lo “fijo” es el precio del capital, no el precio de la garantía, y tampoco la seguridad del principal; si se mezclan estas tres cosas en la publicidad, me parece que puede inducir a error.

Luego, la fecha de vencimiento. El documento lo explica con total claridad: si la deuda no se paga antes del vencimiento, se activa la liquidación y se abre una ventana de liquidación de dos horas. Si la deuda todavía no se ha gestionado por completo, se pasa a la physical delivery, y el pool de recompra que recibe el tenedor de FT puede incluir tanto el activo subyacente como la garantía. Yo pensaba que comprar FT era simplemente esperar al vencimiento para recibir el mismo activo de deuda, pero en un escenario extremo, podría terminar con una cesta de garantías que necesitaré gestionar por mi cuenta. ¿Eso sigue siendo un “rendimiento fijo” como lo entiende la gente común?

En el tema del oráculo, tampoco hay escapatoria. TermMax lista por sí mismo los orígenes de precios de Chainlink y RedStone como puntos de riesgo. Un precio anómalo puede causar una liquidación incorrecta o falta de garantías. La tasa fija no puede impedir que falle la fuente de precios: este riesgo simplemente se trasladó de la curva de tasas a la valoración y al flujo de liquidación.

El costo de liquidación tampoco se puede despachar con una sola frase de “sobrecolateralización”. En las reglas públicas, hay una penalización del 10% según el valor de la deuda liquidada: la mitad para los liquidadores y la mitad para las reservas del protocolo. Y cuando la deuda supera 10.000 dólares, por lo general, en una sola ocasión el procesamiento máximo es del 50%. Esto puede evitar que una posición grande se recorte de golpe. Pero si el mercado realmente cae de forma continua, ¿las liquidaciones por tandas llegan a tiempo? Eso dependerá de la ejecución on-chain y de la liquidez.

Así que cuando veo #TermMax , no basta con preguntarse si el APY de la página está bloqueado o no. Lo que hay que preguntar es: ¿qué es la garantía?, ¿dónde está el LLTV?, ¿quién se encarga del pago al vencimiento?, y después de la entrega física, ¿qué es lo que realmente recibiré? La tasa puede quedar clavada, pero el riesgo no está clavado en el mismo sitio, ¿no es así?
$GPS $ETH

我重新看了一遍 @Dusk 的主网迁移指南，有个很容易被忽略的细节：钱包里点了Approve，并不代表$DUSK 已经迁到Dusk主网。真正触发迁移的是后面的Execute transaction，两步之间任何一次中断，都可能让用户误以为资产“卡住了”。

官方流程是把以太坊上的ERC-20或BNB Chain上的BEP-20 DUSK锁进迁移合约，再向指定的Dusk主网账户发放对应原生币。用户要准备自托管EVM钱包、Dusk账户，以及支付源链费用的ETH或BNB；执行交易确认后，通常还要等待处理。交易所账户一般不能直接通过WalletConnect完成这套操作，需要先提到自己控制的钱包。

机制本身不难，真正的坑全在操作边界。第一，授权只是在给合约额度，不会自动转币；第二，源链代币是18位小数，主网DUSK是9位小数，迁移金额会向下取整到最小单位LUX，小于1 LUX的尾数留在原钱包；第三，看到余额没到账时，应该先核对Execute交易是否成功，而不是重复授权。

这套单向锁定再发放的设计，比让用户自己找跨链池子更清楚，但它仍然把两条链、两个钱包和两次确认塞进同一流程。对老用户只是多看一眼，对新人却可能把“授权成功”理解成“迁移完成”。安全机制如果无法被界面讲明白，最后还是会变成人为错误。

所以我看 #dusk 的主网迁移，不只看合约有没有审计，更看钱包是否把当前步骤、源链哈希、预计处理状态和接收地址同时展示。官方文档明确给出了核验路径，这是加分项；下一步应当把这些提醒做进每个关键按钮，而不是等用户失败后再翻帮助中心。

你迁移资产时最怕哪一步：授权、选错网络，还是到账状态不透明？说说你踩过的操作坑。
$ACE $BTC

在完整对照 @Dusk 的开发文档后，我才发现它现在最值得看的并不是某个 TPS 口号，而是把开发入口拆成 DuskVM 和 DuskEVM 两套环境。这看起来像重复造轮子，背后其实是在解决“原生隐私能力”和“现成开发生态”无法同时一步到位的问题。

DuskVM 让 Rust/WASM 合约直接跑在 L1，更靠近 Phoenix，屏蔽交易、零知识能力和原生资产模型；DuskEVM 则基于 OP Stack，开发者能继续用 Solidity、Hardhat、Foundry 和熟悉的钱包工具，执行结果再通过 DuskDS 完成结算与数据可用性。简单说，前者像专用实验室，能力深但学习门槛高；后者像标准接口，接入快，却要处理跨层协同。

这条路线确实务实。很多隐私链技术做得很重，最后卡在没人会开发；普通 EVM 链工具齐全，又很难原生处理受监管资产需要的保密和选择性披露。Dusk 把两类开发者都留下，至少避免了“技术正确、生态空白”的老问题。

但双环境不是白送的红利。合约放在哪层、资产怎么跨层、故障时由哪层负责，都会增加工程复杂度。尤其 DuskEVM 依赖 DuskDS 结算和数据可用性，用户看到的是熟悉的 EVM 界面，底下却不是一条普通以太坊侧链。如果文档、浏览器和跨层状态提示跟不上，兼容性反而会制造新的理解成本。

我现在不会仅凭“支持 Solidity”就给 #dusk 的开发者增长下结论。接下来更值得盯的是：主网上真实合约数量、跨层资产路径是否顺畅、Hedger 这类保密能力何时形成可复用组件。$DUSK 作为两套环境里的 Gas 与安全资产，价值最终也要靠实际调用量证明，不靠架构图自我循环。

你觉得双执行环境是聪明分工，还是把维护难度放大了？欢迎留下判断。
$BTW $ETH

Releí el análisis del puente entre cadenas de marzo de este año vinculado a @Dusk y, en vez de recordar que “la coherencia del nodo principal no tuvo problemas”, lo más importante (y más doloroso) es otra frase: los permisos de una wallet de firma única llegaron a ser tan grandes como para hundir toda la cadena del puente a la vez.

El 16 de enero, el atacante obtuvo los permisos de la wallet firmante de Dusk asociada al servicio del puente. Primero movió los fondos en el lado de Dusk y, después, envió una parte hacia BSC. En la secuencia divulgada por la parte oficial, se robaron 9,000, 89,700, 2,743,310 y 8,068,000 monedas de $DUSK ; además, hubo dos intentos que cruzaron con éxito. El último intento—de 8,910,000 monedas—falló después del apagado.

Esto no es que la coherencia de DuskDS se hubiera roto, ni que fallara la criptografía de Phoenix en el momento. El problema estuvo en el recorrido operativo del puente: la firma, el manejo de eventos y la conexión de red estaban apretados en la misma línea. Como si un banco no hubiera sido forzado, pero el conductor del camión de traslado llevara a la vez la llave de la caja, el plan de ruta y el sello de autorización; si el conductor pierde sus credenciales, por más sólida que sea la bóveda, el camión toma el rumbo equivocado.

La reconstrucción después del análisis sí fue a lo que dolía: separar la firma del manejo de eventos; los eventos primero se registran como tareas y luego un worker independiente las ejecuta. El estado de la transacción se separa en seen, submitted, completed, failed y stuck. La wallet caliente se deja solo con el saldo mínimo operativo; si cae por debajo de un umbral, se pausa automáticamente y luego una wallet fría se repone manualmente. En pocas palabras, “una sola carretera hasta el final” se corta en varias puertas de control.

Pero no voy a fingir que, con el cambio, ya se pasó la historia. Lo más problemático del puente es que la seguridad del protocolo y la seguridad operativa suelen empaquetarse en la misma comprensión por parte de los usuarios. Tú usas el mismo DUSK, ves la misma marca, pero lo que realmente gestionas puede ser un modelo de confianza totalmente distinto. Dentro de la cadena se confía en la coherencia; el paso entre cadenas dependía entonces de la ruta de firma. Cuando los activos cruzan el límite, la suposición de seguridad cambia de coche.

Mi conclusión: una línea temporal pública y el análisis de la causa raíz son mucho más fuertes que una frase vaga de “ya está restablecido”; pero un repaso transparente es solo el punto de partida para volver a puntuar, no un sello de “no inspeccionar”. #dusk Después, lo verdaderamente útil es vigilar a largo plazo si el puente consigue operar según el diseño en cuanto a exposición de la wallet caliente, mecanismo de pausa, aislamiento de firmas y manejo de anomalías.

Así que no sigas preguntando cosas grandes y vacías como “¿Dusk es seguro?”. La pregunta correcta es: ¿en qué capa está tu activo ahora mismo, quién lo firma, y qué puerta de control, si falla, mueve el dinero? El puente es más complejo ahora; ¿también la confianza está realmente fragmentada? Sigamos desmontándolo en la sección de comentarios.
$BTC

Leí la página de tokenomics de @Dusk , y lo que de verdad me hizo detenerme no fue el tope de mil millones, sino una regla poco llamativa: el nodo requiere un mínimo de 1,000 $DUSK en garantía, pero no hay límite máximo.

Primero, pongamos las cuentas en claro. La oferta inicial de Dusk es de 500 millones; el plan es liberar otros 500 millones en 36 años. Durante los primeros cuatro años, cada bloque añade aproximadamente 19.8574 tokens, y después, se reduce aproximadamente a la mitad cada cuatro años. En la recompensa por bloque, el productor se queda con el 70% y, además, puede obtener hasta un 10% extra según los credits de los certificados. El fondo de desarrollo recibe 10%, y la comisión de verificación 5%, y la comisión de aprobación 5%; lo que no se reparta se quema.

Esta distribución es como una empresa que desglosa las bonificaciones para ventas en el frente, revisión de control de riesgos y el presupuesto de la sede. La ventaja es que cada rol puede cobrar, y la verificación y la aprobación ya no dependen solo del entusiasmo. Más importante aún: las comisiones también se incorporan a la recompensa por bloque; en teoría, cuanto más se use la cadena, el presupuesto de seguridad no dependerá únicamente de la emisión.

Pero “sin límite de garantía máxima” son las cinco palabras difíciles. En el consenso, el provisioner es elegido aleatoriamente para proponer, verificar y aprobar bloques; el rendimiento también se relaciona con la garantía efectiva y el nivel de participación. Cuanto más fondos tenga un nodo grande, mayor será su expectativa económica cuando sea seleccionado. La recompensa vuelve a la garantía, y la bola de nieve puede volverse cada vez más sólida. La regla no dice explícitamente que favorezca a los grandes tenedores, pero el interés compuesto se encarga de ensuciar el trabajo.

Por supuesto, Dusk también tiene sanciones blandas y duras: si te desconectas, podrías ser suspendido y parte de tu garantía efectiva se convierte en garantía bloqueada; votos inválidos o conductas maliciosas demostrables como dobles firmas podrían quemar directamente una parte del capital. Es como poner un botón de autodestrucción en la caja fuerte de los grandes tiburones: el botón puede restringir las malas acciones, pero no resuelve por sí solo la concentración de poder.

Mi opinión es bastante ambivalente: la emisión decreciente durante 36 años deja muy claro el presupuesto de seguridad a largo plazo, algo mejor que confiar en subir la inflación “a ojo”; pero a quién se le asigna ese presupuesto importa más que la curva total de cantidades. #dusk no debería fijarse en el gran título de “tope de mil millones”, sino en la concentración de la garantía activa, la tasa de nodos en línea y si las recompensas siguen refluirm hacia la parte alta.

No traduzcas el tope de oferta directamente como escasez, y tampoco traduzcas el rendimiento de la garantía directamente como seguridad. Con el peso de los nodos sin límite máximo, ¿se está premiando la inversión a largo plazo, o poco a poco la comisión aleatoria se está convirtiendo en la sala habitual de clientes ricos? Ven a la plaza y aclaremos todo.
$VELVET $SNXXB

Leí dos veces el documento del modelo de transacciones para @Dusk . Lo más llamativo no son las dos palabras “privacidad”, sino que en la misma cadena hay dos libros contables: Moonlight en público y Phoenix en modo invisible.

Dicho en lenguaje sencillo: Moonlight es como una caja de cristal; la dirección y las transferencias se pueden ver. Phoenix, en cambio, mete el dinero en billetes cifrados y, mediante pruebas de conocimiento cero, le dice a la red que ese dinero es legítimo y que no hay doble gasto, pero sin exponer completamente al mismo tiempo el remitente, el destinatario y los importes. Incluso en un mismo perfil de cuenta se pueden gestionar ambos tipos de cuentas. Suena como si una misma billetera llevara tarjetas transparentes y tarjetas con compartimento secreto, y al pagar tú eligieras cuál entregar.

Este diseño sí es inteligente. Las instituciones financieras no pueden publicar todos los datos, y la regulación tampoco aceptaría que no se pudiera ver nada. Dusk mete la capacidad de elegir dentro del modelo de transacciones: la liquidación normal va con libro público; las posiciones sensibles van con libro de privacidad. Cuando haga falta auditoría, se usa una clave de visualización para hacer divulgación selectiva. No es “pelear” a privacidad y cumplimiento hasta romperse, sino hacer que se sienten a comer en mesas separadas.

Pero el problema también está escondido en el “doble carril”. La documentación integrada de la bolsa recomienda recargar usando Moonlight, porque los billetes cifrados de Phoenix requieren otra lógica de custodia y de escaneo. O sea: el protocolo ofrece una salida de privacidad, pero el ingreso del mundo real quizá, por compatibilidad, empuje a todo el mundo de vuelta al canal transparente. Es como si un hotel tuviera una puerta VIP oculta arreglada, pero el sistema de recepción solo reconociera la identificación de la puerta principal: la puerta existe, pero no significa que el huésped realmente pueda entrar.

Entonces, ¿qué es $DUSK aquí? Ambos tipos de transferencias lo usan para pagar, y la ejecución del contrato también depende de él. No es solo un símbolo pegado al relato de privacidad: es el combustible que comparten entre dos libros contables. Si ese combustible tiene demanda, al final depende de si la billetera, la bolsa y la aplicación están dispuestas a “sacar” de verdad a Phoenix, y no solo a escribirlo bonito en el documento.

Mi valoración actual: el modelo doble se parece más a la realidad financiera que el “todo en público” a una sola regla, pero la complejidad se ha trasladado del lado de la cadena al lado de quien conecta. #dusk de verdad no es si existe o no la función de privacidad, sino cuántos puntos de acceso están dispuestos a asumir ese costo extra de escaneo, custodia y divulgación.

Así que no te dejes engañar solo por las cuatro palabras “privacidad seleccionable”. Con Moonlight y Phoenix como este dúo de carriles, al final los usuarios podrán elegir la ruta, ¿o la mayoría de los puntos de acceso solo abrirán el carril transparente que es más fácil? El hilo de comentarios sigue desmenuzando.
$AKE $ACU