小王炒币随笔

#dusk $DUSK He repasado los tipos de saldo que podrían aparecer en la billetera Dusk y encontré al menos cuatro “saldos” diferentes operando al mismo tiempo, pero la mayoría de las interfaces solo muestran un número. El primero es el saldo total: la cantidad de DUSK registrada en la cadena asociada a tu dirección; el segundo es el saldo disponible, después de descontar la parte que está en staking; el tercero es el active stake, el que realmente participa en el consenso; y el cuarto es el locked stake, la parte que has apostado pero que no participa en el consenso.
El problema es este: muchas billeteras tratan el “saldo total” como si fuera el dinero que puedes usar. Pero en realidad, si has hecho staking con 5000 DUSK, de los cuales 4500 son active y 500 locked, entonces tu saldo disponible ya es menor que 5000, pero esos 500 locked no participan en el consenso ni se pueden transferir. Los usuarios de ETH están acostumbrados a mirar “saldo - en staking = disponible”, pero en Dusk hay una capa extra de distinción entre active/locked, y la lógica que viene de ETH no alcanza.
Visto desde BTC, bajo el modelo UTXO, el saldo es el saldo: no existe ese estado intermedio de “está bloqueado pero no trabaja”. El locked stake de Dusk es un caso muy particular: las monedas son tuyas y también están en el contrato de staking, pero no generan recompensas y no participan en las elecciones. Si un usuario añade más staking sin saber la regla 90/10, es fácil que termine con locked stake, y luego se pregunta por qué el rendimiento no se calcula como si fuera sobre todo el staking.
Para el ecosistema de @Dusk , este es un problema que se puede resolver mejor a nivel de UI, pero también es lo más fácil de pasar por alto. Lo que el poseedor de $DUSK realmente necesita es que la billetera muestre por separado cinco números: saldo total, saldo disponible, active stake, locked stake y recompensas pendientes por reclamar. Ahora, si solo se da un número, el usuario cree que está ganando recompensas, pero en realidad puede que haya una parte de las monedas “parada” todo el tiempo. En mi siguiente paso voy a comparar específicamente las formas de mostrar el saldo en varias billeteras populares para ver quién deja esto claramente explicado. @Dusk

#dusk $DUSK Al revisar los documentos técnicos de Dusk, presté especial atención al proceso de generación y verificación de pruebas de conocimiento cero (ZKP) en el protocolo Phoenix. El whitepaper describe de manera muy completa el protocolo Plonk, pero lo que realmente me hizo detenerme fue esto: en el documento casi no se proporcionan puntos de referencia (benchmarks) sobre el tiempo de generación de pruebas en el entorno de la red principal.
Y ese es precisamente el cuello de botella clave para materializar las transacciones de privacidad. Phoenix representa los fondos como notas cifradas (encrypted notes); cada vez que se transfiere, se debe generar localmente una prueba: la prueba demuestra que el remitente tiene derecho a consumir la nota, que el monto no es negativo, que la entrada y la salida están equilibradas y que no hay doble gasto. Este proceso de generación de la prueba ocurre en el dispositivo del usuario; no depende de la red, pero sí requiere recursos de cómputo.
La pregunta es: si generar la prueba de una transacción shielded en el teléfono tarda 30 segundos o incluso más, entonces el pago por privacidad no puede convertirse en una experiencia cotidiana. Si la generación de pruebas requiere mucha memoria, los dispositivos de gama baja simplemente no pueden usarlo. Para empeorarlo, Dusk cuenta con dos modelos: Phoenix y Moonlight. Cuando el usuario necesita volver de shielded a public, también debe generar una prueba.
Revisé el repositorio de GitHub de Dusk y las discusiones en la comunidad, y actualmente los datos de rendimiento que más se pueden encontrar provienen de entornos de prueba o de hardware específico. No he visto informes de benchmarks dirigidos a móviles, al navegador o a portátiles comunes. Y las optimizaciones de la generación de pruebas ZKP —desde la elección de algoritmos hasta el diseño del circuito, pasando por la aceleración por hardware— pueden reducir la latencia de niveles de segundos a milisegundos paso a paso, o, al contrario, descontrolarse por el aumento de complejidad.
Otro aspecto que se suele pasar por alto es el costo de verificación. Aunque la generación de la prueba se realice en el lado del usuario, la verificación en la cadena sigue consumiendo Gas. Si el costo de verificación crece linealmente con la complejidad de la transacción, en escenarios de alta carga las transacciones privadas podrían costar varias veces más que las transacciones públicas; en la práctica, esto expulsa a los usuarios de vuelta a Moonlight mediante el precio.@Dusk
Por eso, al evaluar la usabilidad de la privacidad en Dusk, no me fijo en qué sistemas de pruebas admite, sino en la latencia de generación de pruebas en hardware común, en la curva de consumo de Gas para la verificación en la cadena y en si la proporción de transacciones Phoenix dentro del total crece de manera natural. Las matemáticas del whitepaper son el punto de partida; el cronómetro del dispositivo es el final. $DUSK

#dusk $DUSK al traducir la documentación de DuskEVM $DUSK , me di cuenta de un punto que la mayoría pasa por alto: DuskEVM no es una "capa de compatibilidad con Ethereum", sino una reimplementación de un conjunto de instrucciones EVM sobre una máquina virtual WASM. @Dusk eligió este camino, lo que significa que tendrá que pagar el costo de ambos lados al mismo tiempo.
La ventaja de ser compatible con EVM es que está “a la vista”: los desarrolladores de Solidity pueden migrar sin problemas, Metamask puede conectarse directamente y los protocolos DeFi existentes pueden desplegarse en #dusk con solo unas pocas líneas de código. Pero el EVM sobre WASM, en esencia, es una “traducción”: cada opcode de EVM debe reinterpretarse y ejecutarse de nuevo dentro del runtime de WASM. Esta sobrecarga adicional de la capa de traducción es imperceptible en escenarios de baja concurrencia, pero en los picos de liquidación batch de NPEX se amplifica como una prima implícita en gas.
Más sutil aún es el costo de interacción entre el modelo de transacciones privadas de DuskEVM y Phoenix. EVM es un modelo de cuentas, mientras que Phoenix es un modelo híbrido UTXO; el puente entre ambos requiere conversiones de pruebas ZK adicionales. Cuando los protocolos DeFi cambian con frecuencia entre el estado público de EVM y las UTXO de privacidad, cada cambio implica generar una prueba, y las demoras se van sumando en cadena. Los market makers calculan el arbitraje en términos de milisegundos; con varias capas de conversión, la ganancia podría terminar comiéndose por el costo de fricción.
Estoy de acuerdo con la estrategia de DuskEVM: bajar la barrera de entrada para desarrolladores usando compatibilidad con EVM, y conservar la extensibilidad futura con WASM. Pero la aplicabilidad real de este camino no depende de cuántos contratos Solidity soporte, sino de si la latencia de las pruebas para el puente EVM-Phoenix puede reducirse a un nivel “imperceptible” en escenarios DeFi reales.
El ciclo cerrado de RWA de DUSK necesita a DeFi como lubricante de liquidez, y DeFi necesita compatibilidad con EVM para atraer a los desarrolladores. Pero esas tres capas superpuestas—traducción WASM, ejecución EVM y pruebas de Phoenix—¿harán que este enlace se convierta en “se puede hacer, pero no se puede costear” bajo alta presión?
#dusk @Dusk

#dusk $DUSK Últimamente he estado siguiendo de cerca la parte que más me entusiasma del roadmap después del lanzamiento de la red principal de Dusk: Lightspeed, una capa 2 compatible con EVM. Para ser honesto, el mayor dolor de las blockchains de privacidad nunca ha sido que la tecnología no sea lo suficientemente “a la altura” en términos técnicos, sino que el ecosistema de desarrolladores es demasiado delgado. Sin suficientes DApps y una cadena de herramientas que las respalde, incluso la arquitectura subyacente más elegante solo puede ser una ilusión. @Dusk
La estrategia de Lightspeed es bastante pragmática: no intenta construir desde cero un ecosistema completo de desarrolladores, sino que elige compatibilidad con EVM, una ruta madura que ya ha sido validada por Ethereum. Esto significa que, en teoría, los protocolos DeFi existentes en Ethereum, los mercados de NFT y todo tipo de herramientas podrían migrarse a la capa de liquidación con privacidad de Dusk con un coste relativamente bajo. $DUSK
Pero al ordenar esta arquitectura, encontré una brecha técnica que es fácil pasar por alto. La compatibilidad con EVM resuelve la interoperabilidad de la capa de ejecución, pero las características de privacidad fundamentales de Dusk —pruebas de conocimiento cero, divulgación selectiva y control de acceso conforme— no tienen soporte nativo en un entorno EVM estándar. Si los desarrolladores simplemente copian los contratos de Ethereum sin más, esas capacidades de protección de la privacidad no se activarán en absoluto: equivale a inutilizarse.
El problema más realista es que, como solución L2, Lightspeed necesita que su secuenciador, su puente entre cadenas y su modelo de seguridad sean verificados de forma independiente. He visto demasiadas L2 que, durante su fase inicial de lanzamiento, sufrieron pérdidas masivas de activos debido a vulnerabilidades en los contratos puente o a conductas maliciosas por parte del secuenciador. No dudo de la solidez técnica del equipo de Dusk, pero cualquier componente nuevo que se incorpore debe pasar por el “filtro” de ataques reales.
Creo que la dirección de Lightspeed es correcta, pero la clave para decidir el éxito o el fracaso no está en los indicadores técnicos, sino en si puede atraer a los primeros desarrolladores que realmente entiendan el valor de la privacidad y estén dispuestos a adaptarse en profundidad.
#dusk @Dusk

#dusk $DUSK DuskEVM ya se ha puesto en marcha; los desarrolladores ya pueden desplegar contratos de Solidity—esto me ha tenido bajo observación durante cuatro meses completos, porque es el punto de inflexión más crucial de DUSK en su transición de "narrativa" a "uso real".$SPCXB
Me tomó medio día revisar, de principio a fin, la documentación oficial y el historial de commits del repositorio de GitHub. La orientación de DuskEVM es muy clara: no se trata de crear desde cero un nuevo lenguaje, sino de ser compatible con EVM para que los desarrolladores existentes de Solidity puedan migrar directamente. Esta estrategia es inteligente: el costo de aprendizaje es cero, y la barrera para los desarrolladores es mucho más baja que la de aquellas cadenas que obligan a aprender un lenguaje nuevo. Según los commits más recientes del repositorio de rusk, durante los últimos meses se han iterado de forma intensa módulos como la optimización de UX para el puente, las consultas al host de la VM y la gestión del estado de las transacciones; no es un estado de "prometer sin cumplir".
Pero mi atención no está en el "se pueden desplegar contratos", sino en el "¿qué sucede después de desplegarlos?". El punto diferencial de DuskEVM es la capa de privacidad—Hedger hace que los importes de las transacciones no sean visibles en la cadena, pero sean auditable; esa es la diferencia esencial frente a una cadena EVM ordinaria. El problema es este: si un desarrollador despliega un protocolo DeFi en DuskEVM, y no llama de forma proactiva a los módulos de privacidad, entonces es simplemente una aplicación EVM normal. La privacidad no es una opción predeterminada; es una "opción que requiere configuración adicional".$SNDKB
Esto significa que el despegue del ecosistema de DuskEVM depende de cuántos desarrolladores estén dispuestos a dar un paso extra para habilitar la funcionalidad de privacidad. Mi indicador de observación es muy sencillo: dentro de los tres meses posteriores al lanzamiento en mainnet, ver cuántos contratos desplegados en DuskEVM integran de verdad la función de privacidad de Hedger. Si la proporción supera el 30%, significa que la privacidad es una necesidad y no un reclamo vacío; si es inferior al 10%, significa que DuskEVM solo agrega una cadena EVM más.
@Dusk

#dusk 研究 Dusk 质押机制时，我卡在一个反常识的设计上：它没有传统意义的罚没。节点掉线或违规，主网不会直接烧掉你的本金，而是走"软惩罚"路线——扣减的是奖励积累部分，外加暂停出块资格，情节严重的进入冷却期，本金基本安全。
第一反应是这会不会削弱安全性。传统 PoS 的逻辑是拿本金当人质，攻击成本约等于质押量；Dusk 把人质换成了未来收益流和参与资格，威慑力看起来打了折扣。@Dusk
但换到 RWA 链的语境重新算这笔账，逻辑就通了。Dusk 想吸引的节点运营者不是匿名农场，而是托管行、券商这类受监管实体。这类机构的风控部门根本不会批准一个"运维事故可能导致本金蒸发"的质押方案——密钥轮换失误、机房断电都可能触发罚没的链，机构连尽调第一关都过不去。软惩罚等于把操作风险和恶意风险分开定价：掉线扣收益，作恶断资格，本金层面的风险交给法律和牌照去约束。$SNDKB
代价也很直白：对不受监管约束的匿名大户，攻击的经济成本确实变低了。Dusk 实际上是在赌自己的验证者集合会逐渐机构化，声誉与牌照的约束力最终大于烧钱的约束力。$SPCXB
所以我评估 $DUSK 的质押安全，不看名义质押率，看两个数：一是被暂停节点的重复违规率，软惩罚够不够疼，这个数据不会说谎；二是验证者集合里可识别机构实体的占比。前者验证威慑有效性，后者验证这套设计到底赌没赌对。
如果两年后验证者仍由匿名大户主导，软惩罚就是留给攻击者的后门；如果机构占比持续上升，它就是第一套真正为受监管节点设计的质押模型。你会把这个设计算作加分项还是风险项？
#dusk

#termmax 前天 por la noche no compré FT a precio de mercado, sino que puse una orden Range en TermMax, quería probar si “cotizo mi propio interés” y de verdad se ejecuta.
Primero, hablemos de en qué se diferencia esto de un AMM común. La liquidez de TermMax no está repartida sobre el precio de la moneda, sino sobre un rango de tipos de interés. Cuando yo como prestamista coloco la orden, básicamente estoy diciendo “solo acepto un 8.6% anual o más; si es menos, no vengan a buscarme”. Comprar FT a precio de mercado significa aceptar el descuento del libro de órdenes en ese momento; en cambio, una Range Order coloca mi precio dentro de la curva, para que el lado que solicita el préstamo venga y la consuma.
$SPCXB
Proceso práctico. Para el tramo de USDC a 90 días, el precio de compra implícito correspondía a un APY de 8.1% en ese momento; lo vi poco, así que colgué 300 U entre 8.6% y 9.0%. Las primeras cuatro horas no se movió nada: la página seguía mostrando “sin ejecutar”. Ya de madrugada, entró una apertura con bastante volumen de GT, empujó ese tramo de interés hacia arriba y mi orden se ejecutó: 186 U, con un precio medio que equivale a 8.7% de APY. Las 114 U restantes no se llegaron a comer; por la mañana las cancelé yo mismo.
Comparémoslo para que tenga sentido. Si en ese momento hubiera tomado directamente los 300 U a precio de mercado, habría sido 8.1% bloqueado por 90 días. Con la orden por 186 U ejecutadas a 8.7%, por 90 días ganaría aproximadamente 0.28 U más. Son números pequeños (como “piernas de mosquito”), pero en términos de rentabilidad es un aumento de alrededor del 7%. El costo es que otras 114 U quedaron esperando toda la noche: no ganaron nada y además ocuparon el plan. Esa es la esencia de poner una orden: intercambiar un tiempo de espera determinado por un precio potencialmente mejor e incierto.
Me puse este criterio de decisión: si el dinero es urgente para desplegarlo y solo quieres asegurar un nivel “aprobado”, el precio de mercado es más cómodo. Si entiendes el rango del tipo de interés para este plazo y aceptas que se ejecute parcialmente, entonces una orden pendiente es más rentable. Además, no cuelgues el precio demasiado lejos del libro: si el libro marca 8.1% y tú pones 12%, básicamente equivale a no haber puesto orden.$SNDKB
Tengo guardada una captura de la orden pendiente de esas 114 U que no se ejecutaron; me parece bastante interesante.
#TermMax @TermMax

#termmax cualquiera que haya trabajado en el departamento de pasivos y activos de un banco tiene una reacción fisiológica a la palabra «flotante». No porque el tipo flotante sea necesariamente más caro, sino porque no puede entrar en el presupuesto. Un número que no cabe en la tabla del próximo trimestre, en contabilidad de gestión, equivale a no existir.
Eso es lo que no dejaba de pensar al ver @TermMax .
Durante mucho tiempo, el préstamo en cadena solo ha ofrecido un tipo de pasivo: el tipo de interés se mueve con la tasa de utilización, sin límite, sin compromiso. Ese pasivo es perfectamente suficiente para los traders: al fin y al cabo, ellos viven a escala de minutos. Pero para cualquier entidad que necesite planificar por trimestres, no puede registrarse en el balance. $SPCXB
Lo que hace el tipo fijo es corregir precisamente eso. Al pedir prestado, el coste queda bloqueado, la fecha de vencimiento es clara y el flujo de caja puede programarse de antemano en el calendario. En las finanzas tradicionales, a esto se le llama casar activos y pasivos; en cadena, por primera vez se vuelve ejecutable.
Pero hay que dejar claro cuál es el coste. $SNDKB
Primero, la certeza tiene precio. La mayor parte del tiempo, el mercado cobra una prima por lo «predecible»; el tipo fijo normalmente no es la opción más barata, sino la más fácil de calcular. Si se usa como herramienta para ahorrar, decepcionará.
Segundo, el riesgo de reinversión no desaparece. El día del vencimiento recuperas el principal, pero nadie garantiza cuál será el tipo para el siguiente tramo. Lo que el tipo fijo elimina es la incertidumbre durante el período de tenencia, no la incertidumbre a lo largo de toda la línea temporal.
Tercero, la renovación requiere un proceso. Al vencimiento hay que tomar una decisión; esa acción necesita a alguien responsable, una ventana de tiempo y un plan de contingencia si falla. Es una carga operativa adicional que no ocurrirá automáticamente.
Por eso, lo que TermMax realmente vende no es un coste más bajo, sino un coste que puede escribirse en una tabla. Los compradores de esas dos cosas no son en absoluto el mismo grupo.
Una pregunta: si el coste total de dos opciones acaba siendo el mismo, una predecible y otra impredecible, ¿cuánto pagarías de más por que sea «fácil de calcular»?
#TermMax @TermMax

#dusk Mucha gente le pone la etiqueta de "moneda de privacidad" a $DUSK , pero creo que están justo al revés: leyendo el documento de posicionamiento de @Dusk , lo que realmente quiere hacer no es permitir transferencias anónimas, sino llevar a la cadena activos financieros regulados: valores, bonos, participaciones de fondos, cosas que requieren cumplimiento y que, además, no pueden tenerse en custodia con divulgación total de posiciones. $SNDKB
Esta vía tiene un umbral totalmente distinto al de las cadenas meme. Emitir un token de valor negociable implica tratar con KYC, idoneidad de los inversores, restricciones de transferencias, distribución de dividendos, informes regulatorios. Una cadena pública común o es totalmente transparente o es completamente anónima; en ambos extremos no se puede satisfacer todo. Dusk quiere combinar un esquema de identidad autosoberana como Citadel con privacidad configurable para lograr "que solo el lado que cumple pueda ver lo que debe, y los demás no puedan ver lo que no deben". Si esta idea funciona, efectivamente se mete en un nicho que otros casi no tocan.
Pero la vía regulatoria tiene la mayor característica: es lenta. Si la tecnología puede o no implementarse es una cosa; si las licencias, si los emisores realmente quieren usarlo, y si el mercado secundario tiene liquidez es otra, y esta última suele medirse en años. Marcos como MiCA le dieron a Europa una ventana, pero entre un "el marco lo permite" y un "de verdad hay instituciones que emiten y liquidan" hay una distancia atravesada por opiniones legales, arreglos de custodia, auditorías y el primer grupo de emisores valientes que se atreva a comerse el primer bocado. $SPCXB
Así que, al evaluar el valor de #dusk , no me dejaré desviar por las dos palabras "privacidad": vigilaré la cantidad real de activos de cumplimiento llevados a la cadena. Si hay emisiones reales de tokens de valores, si hay inversores reales que los poseen, y si hay alguna vez un flujo de dividendos o un rescate que funcione en la cadena y cierre el circuito. La narrativa tecnológica se puede contar muy rápido; el cumplimiento regulatorio solo se logra paso a paso, a fuego lento. Lo que se apuesta es una dirección más difícil y que menos gente puede copiar, pero que sea difícil por sí solo no constituye realización. Llevar finanzas reguladas a la cadena es una maratón de resistencia: ahora la pregunta que más importa no es si puede hacerse, sino cuándo aparecerá el primer cliente real. @Dusk

#termmax Mira si un acuerdo es fiable o no. Hoy en día a la gente le gusta fijarse en el rendimiento anualizado, pero los veteranos hacen lo contrario: primero miran quién tiene en sus manos la “palanca” que lo controla, y luego si cada vez que esa palanca se mueve te deja tiempo para reaccionar. El diseño de gobernanza de TermMax me hace pensar que al menos reconoce la seriedad de esto.
@TermMax Al dividir los permisos en tres roles —Curator, Guardian y Allocator— cada uno se encarga de la selección del mercado, la supervisión del riesgo y la asignación de fondos. En estos roles, a mí lo que más me importa no es lo que puede hacer Curator —eso cae dentro del ámbito de la estrategia— sino la “cadena de seguridad” que se le coloca a Guardian cuando se trata de “ampliar el riesgo”: acciones como añadir mercados, subir las comisiones de desempeño y acortar el tiempo de bloqueo tienen que pasar por una traba temporal; mientras tanto, Guardian aún puede detenerlas en la ventana correspondiente.$SPCXB
La sutileza de este diseño está en que asume: ¿la persona que cambia las reglas y la persona que vigila no pueden ser la misma? No entendí bien esta vuelta de tuerca. Dicho de una forma más fluida: lo más fino de este diseño es que reconoce que quien gestiona el dinero puede cometer errores, así que inserta un “cinturón amortiguador” de forma forzada. Las acciones para reducir el riesgo se pueden ejecutar al instante; las acciones para ampliar el riesgo deben esperar medio paso. Esta asimetría en sí misma es una forma de proteger al usuario.
Pero también debo decirlo: la traba temporal protege frente a cambios bruscos de permisos, pero no evita errores crónicos en la estrategia. Si un Curator tercamente mete todo el capital en un mismo mercado, incluso si todo el proceso se hace de forma correcta paso a paso, el resultado aun así podría ser que el dinero quede inmovilizado durante mucho tiempo y que el retiro se acumule en cola. Las barandillas solo garantizan que el procedimiento sea válido; no aseguran que el resultado sea el correcto.$SNDKB
Por eso, al mirar TermMax, no solo veo si tiene esa “cadena”, sino también si, más allá de la cadena, las decisiones de estrategia resisten el escrutinio. Que las reglas se modifiquen despacio no significa que la dirección sea necesariamente la correcta.
¿Confiarías más en un protocolo con reglas más detalladas pero prudentes, o en uno que ejecuta rápido pero concentra los permisos?@TermMax

#dusk $DUSK 翻了下几个做隐私/RWA叙事的项目做个横向对比，记录一下思路。Aleo走的是通用零知识虚拟机路线，什么都能证明但落地场景比较发散；Aztec是在以太坊上做隐私rollup，靠的是ETH生态的网络效应，但本质是别人的执行层上加一层许可；Polymesh走的是纯许可链，机构友好但流动性和开发者生态明显薄弱。Dusk卡的位置比较特殊，它是原生L1加内置合规隐私，既不完全依附以太坊，也不是纯联盟链，这个中间态是它的差异化，但中间态往往也意味着两头都要自己啃。
Si de verdad se comparan datos on-chain, la actividad actual de Dusk y su TVL, en comparación con Aleo y Aztec (proyectos que han conseguido grandes rondas de financiación y que cuentan con fondos de ecosistema), siguen mostrando una brecha de escala bastante clara. Pero visto desde otro ángulo, el sector que eligió Dusk es más estrecho y más vertical: se ancla directamente en marcos de titulización en Europa y en la conformidad con MiCA; no es un relato de DeFi generalista. Esta estrategia tiene la ventaja de tener objetivos muy claros, y el inconveniente de que el techo de crecimiento también queda limitado por el ritmo de la regulación y por la intención de las instituciones financieras tradicionales de llevarse su actividad a la cadena. Ir despacio no es el problema; lo que se teme es que, si el “viento regulatorio” (ventana de regulación) pasa, otras soluciones compatibles (por ejemplo, la capa de permisos sobre Ethereum) terminen captando primero la demanda de las instituciones.
Lo que a mí me preocupa más es la profundidad del ecosistema de desarrolladores. Si una cadena es “compliant” y aun así los desarrolladores externos no quieren construir aplicaciones encima, al final solo quedarán el equipo oficial y unos pocos socios haciendo su trabajo en solitario. En la actualidad, el número de proyectos dentro del ecosistema de Dusk aún no es muy grande. Si podrán atraer a desarrolladores de Ethereum para que migren gracias a la capa de compatibilidad DuskEVM, es un indicador clave que hay que observar en los próximos seis a doce meses; es más tangible que cualquier anuncio de colaboración. ¿Vosotros qué pensáis: a largo plazo, qué modelo será más aceptado por las instituciones, un L1 nativo compatible o una capa de permisos sobre Ethereum?
#dusk @Dusk

#termmax Creo que el problema real al que se enfrenta TermMax es este: el tipo de interés fijo resulta muy atractivo para fondos profesionales, pero para los usuarios habituales en la cadena no necesariamente es más fácil de entender que los préstamos tradicionales.$SNDKB
Muchos usuarios ya están acostumbrados a depositar activos, ver el rendimiento anual variable y, cuando lo necesitan, retirarlos. Pero en cuanto intervienen una fecha de vencimiento, la rentabilidad fija, el precio de salida anticipada y la liquidez según el plazo, la dificultad de decisión aumenta de forma notable. Los usuarios no solo tienen que valorar si el tipo es alto o no, sino también si están dispuestos a mantener hasta el vencimiento y qué coste podrían asumir si salen a mitad de camino.
No es que el diseño del producto de @TermMax sea demasiado complejo, sino que el tipo de interés fijo, por naturaleza, añade una dimensión temporal extra frente a los préstamos y depósitos habituales. Si el protocolo solo enfatiza “rendimiento garantizado” pero no ayuda a los usuarios a entender plenamente las diferencias antes y después del vencimiento, algunas personas podrían malinterpretar el tipo fijo como un producto de ahorro que se puede retirar en cualquier momento y cuyo rendimiento no cambia.
Yo preferiría que #TermMax, al ampliar su base de usuarios, haga que la información se muestre de forma más clara que el discurso promocional de los rendimientos. Por ejemplo, antes de que los usuarios entren al mercado, deberían poder ver de manera directa el rendimiento estimado al vencimiento, el tipo de interés real de ejecución, el plazo restante, la variación de precio que podría producirse al salir de forma anticipada y la liquidez del mercado correspondiente. Solo si estos datos son lo bastante transparentes, la “certeza” del tipo fijo no se quedará en un eslogan.
Un problema común en los productos DeFi es que el diseño de las funciones se hace desde la perspectiva del protocolo, mientras que el riesgo lo entiende el usuario poco a poco después de operar. Las actividades de corto plazo pueden lograr que el usuario complete su primera interacción rápidamente, pero si puede completar una segunda y una tercera operación depende más de si el producto es lo suficientemente intuitivo, y no de si la recompensa es lo bastante alta.$SPCXB
Si TermMax quiere atraer no solo a usuarios profesionales familiarizados con el comercio de tipos de interés en cadena, debe bajar el umbral de comprensión, en lugar de ocultar los mecanismos del producto. Un verdadero protocolo de tipo fijo de calidad debería dejar la lógica compleja en la capa subyacente, de modo que el usuario entienda claramente cuánto aporta, cuánto tiempo queda bloqueado, qué obtiene al vencimiento y qué ocurrirá al salir antes. La escala puede impulsarse con incentivos de arranque, @TermMax

#dusk $DUSK investigación @Dusk : cuando pienso en qué palabra es más fácil malinterpretar, la que viene a la mente es “privacidad”. Mucha gente entiende la cadena de privacidad como si fuera algo que oculta todo, pero el escenario que Dusk quiere resolver está mucho más cerca de las finanzas reguladas: los datos de las transacciones no deben exponerse por completo a todo el mundo, pero aun así hay que conservar interfaces para la verificación de identidad, las reglas de activos y los controles necesarios. Esto no es la misma ruta que simplemente perseguir el anonimato, y también significa que Dusk debe hacer un diseño más preciso entre privacidad y cumplimiento.
El problema de las cadenas públicas tradicionales es que el libro mayor es demasiado transparente. Si las instituciones trasladan directamente valores, participaciones de fondos u otros activos del mundo real a una cadena pública, la estructura de tenencias, el tamaño de las operaciones y las relaciones comerciales pueden ser rastreadas de forma continua por competidores. Pero si toda la información no es verificable, el emisor y los participantes regulatorios tienen dificultades para confirmar la elegibilidad del inversor. El valor de las pruebas de conocimiento cero está aquí: los usuarios pueden demostrar que cumplen una condición sin tener que publicar datos completos de identidad ni todos los registros de transacciones.
Sin embargo, el hecho de que técnicamente se pueda hacer divulgación selectiva no significa que el negocio real la adopte automáticamente. Los requisitos en distintas regiones sobre registro de valores, conservación de datos, custodia de activos y admisión de inversores no son los mismos. Aunque Dusk proporcione herramientas de base adecuadas, todavía se necesita que el emisor, los proveedores de servicios legales y los sistemas de cumplimiento se integren conjuntamente. De lo contrario, la privacidad solo se quedará como capacidad del protocolo y no se convertirá en una escala real de activos.$SPCXB
Por eso, mi evaluación de DUSK no se basará únicamente en si “la narrativa de privacidad” está de moda; observaré si aparecen emisores que usan de manera continua estas capacidades en la cadena. Indicadores que vale la pena seguir incluyen la cantidad de cuentas con cumplimiento, la escala de emisión de activos restringidos, el uso real de la divulgación selectiva y si las instituciones están dispuestas a mantener a largo plazo el proceso de liquidación sobre Dusk. Si estos datos crecen, la privacidad dejará de ser solo un argumento de venta y se convertirá en una infraestructura para que los participantes financieros reduzcan el costo de exponer información.#dusk @Dusk $SNDKB

#termmax Si solo entendemos @TermMax como un mercado de préstamos que ofrece un tipo de interés fijo, es fácil pasar por alto la parte más distintiva: no se limita a etiquetar un depósito con un vencimiento, sino que descompone distintos derechos dentro de una misma deuda en FT, XT y GT, permitiendo que el principal, el valor temporal y las responsabilidades asociadas a la garantía que antes estaban mezclados en la misma posición puedan identificarse y negociarse por separado.$SPCXB
FT corresponde al derecho de reembolso al vencimiento. Normalmente se forma con descuento; al vencimiento, se canjea por el activo de deuda según las reglas del acuerdo. Por ello, quienes lo poseen se concentran en el costo de compra, el valor nominal al vencimiento y si la deuda puede liquidarse correctamente. XT asume la diferencia de valor entre FT y el activo de deuda relacionado; se vincula más estrechamente con el tiempo y la fijación de precios del mercado, y va perdiendo gradualmente espacio restante a medida que se aproxima la fecha de vencimiento. GT es el $aERC-721 que representa la posición de préstamo: en su interior se registra la relación entre garantía y obligaciones, y asume las responsabilidades de gestión, reembolso y, potencialmente, la liquidación.
El sentido de esta descomposición es que los participantes del mercado no tengan que aceptar un paquete completo de riesgos que no pueden elegir. Quien prefiere flujos de efectivo definidos puede enfocarse en FT; quien quiera expresar y juzgar el valor asociado al plazo mirará XT; y quien necesite fondos y esté dispuesto a aportar garantías se enfrentará a la posición de préstamo representada por GT. #TermMax no crea ganancias de la nada, sino que organiza las fuentes de rendimiento dentro de la misma relación de préstamo.
Pero la tokenización no equivale a que el riesgo quede completamente aislado. Si FT finalmente puede canjearse y reembolsarse sin problemas, aún depende del cumplimiento del lado del prestatario, del valor de la garantía, de la eficiencia de la liquidación y de los resultados de la entrega; el valor de XT es extremadamente sensible al tiempo, y un juicio erróneo puede enfrentarse a una degradación continua; y los tenedores de GT, si no gestionan oportunamente el ratio de garantía, también pueden verse arrastrados al proceso de liquidación cuando el mercado se vuelve especialmente volátil.
Los tres tipos de activos pueden negociarse por separado, pero provienen de la misma cadena económica. $SPCXB
Creo que la forma más efectiva de entender TermMax no es memorizar por separado las definiciones de los tres tokens, sino preguntarse tres cosas: ¿a quién pertenece el principal al vencimiento?, ¿a quién pertenece el valor del plazo?, ¿quién asume el riesgo de garantía? Luego, al incorporar la liquidez del mercado, las condiciones de liquidación y los activos de liquidación en ese diagrama de relaciones, la estructura del protocolo se vuelve mucho más clara. Solo entendiendo cómo se separan los derechos es posible evaluar de dónde proviene realmente el rendimiento y quién asume el riesgo del otro lado de esa misma ganancia.
¿Qué capa de @TermMax te gustaría estudiar más?

#dusk $DUSK Al revisar las secciones relacionadas con la gobernanza de @Dusk , encontré un hecho que suele pasarse por alto: en las recompensas por bloques, los roles de gobernanza no reciben simplemente “intereses”, sino una remuneración diseñada para participación continua en la seguridad del protocolo. El comité de validación y el comité de aprobación reciben 5% cada uno, y el fondo de desarrollo 10%. Estas proporciones parecen pequeñas, pero desplazan el poder de gobernanza de un simple “voto de tenedores de tokens” a un “voto de operación y mantenimiento”.
Esto significa que los poseedores de DUSK no son las únicas personas que influyen en el rumbo del protocolo. Los validadores se encargan de confirmar los bloques; los comités de aprobación podrían tener funciones específicas en actualizaciones del protocolo, decisiones de confiscación o ajustes de parámetros críticos; y el fondo de desarrollo tiene la capacidad de mantener y avanzar el código. Si entre estos tres existe un desacuerdo de intereses, no es algo que se resuelva solo con el voto de la comunidad.
Intenté comparar esta estructura con un sistema de mantenimiento de un vecindario: el voto de los propietarios es una capa, el gerente de guardia de la propiedad es otra, y el comité de propietarios y el fondo de mantenimiento son otra. Cada capa puede influir en si el ascensor se puede reparar o si se reemplaza el control de acceso, pero la información no es completamente simétrica. Si la gobernanza on-chain solo contabiliza “estar de acuerdo o en contra”, pero ignora quién es responsable de ejecutar, quién puede pausar y quién tiene capacidad para escribir parches, es fácil confundir la concentración de poder con un consenso amplio.
En los documentos, las atribuciones concretas de los roles de gobernanza, los umbrales de propuestas y los mecanismos de congelación de emergencia; no encontré datos especialmente completos de casos consecutivos. Esto trae un problema muy real: cuando el protocolo enfrenta controversias de parámetros o propuestas emocionalmente cargadas, la ruta de decisión real puede estar más concentrada que el diagrama de flujo dibujado en el libro blanco.
Por eso, tomaré como una línea oculta la pregunta de si “el poder de gobernanza es proporcional a la participación on-chain”. Si el fondo de desarrollo y los comités ocupan durante mucho tiempo la voz interpretativa, mientras que los tenedores solo aceptan pasivamente las actualizaciones, la narrativa de la descentralización se verá mermada. En cambio, si los cambios clave pueden revisarse de manera efectiva por la comunidad, la gobernanza de DUSK tendrá un valor a largo plazo. Ahora que observo #dusk , me interesa más el iniciador real de las propuestas, la distribución de los votos y los resultados de la ejecución, en lugar de solo ver qué tan animada está la página de gobernanza. #dusk @Dusk $DUSK

#dusk $DUSK Hay un amigo que escribe Solidity; cada vez que ve una nueva cadena pública, lo primero que dice es: “¿Qué lenguaje tengo que aprender ahora? ¿Esta cadena tiene herramientas listas?” Si la respuesta no es amable, básicamente no vuelve a mirarla ni una segunda vez. En esta ocasión usé la compatibilidad EVM de Dusk para preguntarle, y su reacción fue claramente diferente.
DuskEVM no te pide rehacerlo todo desde cero como con Ethereum, sino migrar contratos Solidity existentes con un costo de modificación muy bajo. Esa sensación no es como cambiar de coche, sino como si de pronto el coche tuviera un botón de modo privacidad: el volante sigue siendo el mismo, el tablero sigue siendo el mismo, solo que ahora vas por una cadena que trae por defecto lógica de privacidad y cumplimiento.
No subestimes esa compatibilidad. El mayor “pool” de desarrolladores de la industria cripto está del lado de Ethereum. Si le pides a los proyectos que vuelvan a contratar gente para escribir contratos, el costo es altísimo; pero si les dices que el código original solo necesita ajustar unas pocas líneas de configuración para tener una versión de privacidad con cumplimiento, entonces sí están dispuestos a probar. Si Dusk logra que las herramientas de migración, la red de pruebas y los paquetes de auditoría queden lo bastante fluidos, la velocidad de arranque del ecosistema puede ser de un orden de magnitud superior a la de las cadenas con un lenguaje nuevo.
Aquí, la privacidad no es que los desarrolladores tengan que “comerse” por su cuenta las pruebas de conocimiento cero, sino que viene empaquetada a nivel de protocolo. No necesitan entender en profundidad la criptografía: solo deben saber qué escenario de contrato requiere ocultar montos. Por ejemplo, en protocolos de préstamos y empréstitos, los préstamos y reembolsos de gran cuantía, o el volumen de órdenes en un libro de órdenes on-chain, pueden implementarse como una versión privada con DuskEVM. Para muchos equipos DeFi, esto ahorra muchísimo tiempo comparado con tener que ensamblar circuitos ZK por su cuenta.
Pero con compatibilidad sola no alcanza: los desarrolladores también tienen que ver beneficios tangibles. Si DUSK puede mantener durante un tiempo subsidios de gas o recompensas por despliegue, y traer a los primeros desarrolladores del ecosistema de Ethereum para que hagan demos, sería más efectivo que un simple “airdrop”. El ecosistema se construye juntando gente, no esperando a que salga.
Si fueras desarrollador, y ahora existe un conmutador que permite que los contratos antiguos incluyan privacidad y cumplimiento, ¿estarías dispuesto a probarlo un día?
#dusk @Dusk $DUSK

Al revés: construye toda tu arquitectura tecnológica alineándola con los requisitos del marco regulatorio de la UE para MiCA y el DLT Pilot Regime. En el sector, durante un tiempo se llegó a ridiculizar como “arrodillarse ante el regulador” y “no tener espíritu Web3”. Pero últimamente he estado observando el ritmo real de implementación en el mercado de valores europeo, y cuanto más lo miro, más siento que ese “arrodillarse” podría ser el foso impenetrable (el castillo) menos replicable de Dusk.
Primero, los hechos: MiCA de la UE ya se implementó. El DLT Pilot Regime permite que las entidades reguladas emitan, negocien y liquiden valores directamente en una cadena de bloques; durante el periodo piloto, se otorgaron exenciones a las reglas tradicionales de compensación y liquidación. Esta fue la primera vez que el regulador europeo abrió, con sus propias manos, una puerta “oficial” para los valores en cadena. $AKE
El problema es que, si la puerta se abre, la cadena también tiene que poder entrar.
El piloto DLT impone un montón de requisitos estrictos a las partes que participen en la cadena: la identidad de los inversores debe ser identificable, las operaciones anómalas deben ser trazables, debe poder cooperarse con las consultas regulatorias, los comportamientos del contrato deben ser auditables… En la capa base de la red principal de Ethereum, no se cumple ni uno solo. Para ejecutar valores regulados allí, tendrías que apilar una serie de capas por encima—KYC fuera de la cadena, empaquetado con permisos, contratos inteligentes con listas blancas—y el costo de fricción es tan alto que las instituciones directamente se rinden.
Dusk va en la dirección contraria. Citadel gestiona la identidad, Phoenix gestiona la privacidad seleccionable, Zedger gestiona las reglas de transferencia de valores y Rusk VM proporciona ejecución determinista. No son “módulos añadidos temporalmente para encajar con el relato”, sino que desde el punto de partida de la arquitectura están diseñados para cumplir los requisitos regulatorios.
Así se forma un volante:
El regulador se atreve a aprobar → las instituciones se atreven a emitir → activos reales se tokenizan en cadena → TVL es dinero real y no es “dinero inflado” → más instituciones siguen.
Para que otras cadenas repliquen esa ruta, tendrían que tirar todo y volver a empezar.
Si lo llevamos a la valoración: el mercado actualmente le pone el precio dado para $DUSK , y todavía básicamente lo calcula como “un L1 minoritario más”. Pero si algún broker en Europa realmente emite la primera acción o bono tokenizado conforme a regulación en Dusk, el cambio del relato será extremadamente rápido. Estos eventos no son lineales: si esperas a subirte cuando salga la noticia, el costo de oportunidad es enorme.
Mis dudas también están claras:
Se obtienen las licencias de cumplimiento, pero aún no se ha verificado qué tamaño real de negocio de valores puede soportar;
Que la regulación europea sea amistosa no significa que EE. UU. o Asia vayan a seguirle el paso;
Las instituciones tradicionales deciden lento; del “señal” al “dinero” podrían pasar todavía uno o dos años.
Pero la cantidad de blockchains públicas que van por la ruta de “cumplimiento primero” es muy reducida. La mayoría de proyectos siguen liados en el campo de batalla de los memecoins; Dusk ya cambió la mesa a la habitación de al lado.
#dusk @Dusk Dusk $DUSK

#dusk Cuando volví a investigar la divulgación selectiva de Dusk, la atención se fue desplazando lentamente de la “prueba” a la “clave”.
Cuando se habla de privacidad, casi todo el mundo se centra en si la prueba de conocimiento cero puede ocultar el importe y las relaciones.
Pero en el Phoenix de @Dusk , lo que realmente controla “quién puede ver” es la viewing key.
La nota cifrada oculta los detalles de la transacción, mientras que la viewing key funciona como una llave de observación que se puede distribuir de forma dirigida: se la entregas al auditor y él puede ver ese tramo del registro.
El diseño es muy elegante.$BTC
La otra cara de la elegancia es que la propia llave se convierte en un nuevo punto de riesgo.
Una vez que entregas una viewing key, es difícil recuperarla.
Después de que el auditor termine, la llave sigue en manos de la otra parte: ¿acaso obtiene de forma permanente el derecho a ver el historial?
Si la clave se filtra, el atacante no obtiene un activo, sino algo aún más sensible que los activos: el historial completo de transacciones.
Si se concede demasiado permiso, la privacidad solo cambia de puerta de entrada para filtrarse; si se concede demasiado poco, los procesos de cumplimiento se traban.
Por eso, al mirar la privacidad de #dusk , ya no me limito a preguntar si el sistema de pruebas es seguro.
Me importan más tres cosas a nivel de operación y mantenimiento: si la viewing key se puede autorizar con el mínimo alcance por intervalos de tiempo o por registros, si la clave se puede revocar o rotar, y si la propia acción de divulgación deja registros trazables.
La verdadera madurez de la tecnología de privacidad no consiste en ocultar lo más profundo posible.
Sino en que, cuando te obligan a entregar parte de la visibilidad, esa parte pueda controlarse con precisión y recuperarse después.
$DUSK Si se busca servir a las instituciones, lo que más temen las instituciones no es no poder ver, sino que “las personas adecuadas miren demasiado y durante demasiado tiempo”.
¿Se ha diseñado en serio el límite de gestión de esa llave?
#dusk @Dusk $DUSK

Mucha gente cree que la tokenización de valores es simplemente “emitir un ERC20 en la cadena”, pero el protocolo Zedger de DUSK me dice que los valores tokenizados reales deben resolver la “finalidad de la liquidación”. El mercado bursátil tradicional es T+2, porque la entrega requiere tiempo para comprobar fondos, valores e identidad. En cambio, la “liquidación atómica” de DUSK significa que el dinero y los valores se transfieren simultáneamente en la misma transacción, sin estados intermedios.
La grandeza de esta tecnología es que convierte la “confianza” en algo trasladado desde la verificación humana hacia el algoritmo. Por ejemplo: A emite un bono por 10 millones de dólares, B lo compra con USDC y, en condiciones normales, B debe pagar primero y luego esperar la confirmación de A. En el intervalo, podría haber un ataque de hackers o una anulación manual. Pero en DUSK, esos dos pasos se comprimen en una operación atómica de “contrato inteligente de bloqueo-verificación-liberación”. Si falla la verificación (por ejemplo, B no es un usuario en la lista blanca), ni el dinero ni los valores se mueven; todo se devuelve a las cuentas originales.
He pensado que esto puede resolver un problema enorme: el “riesgo de contraparte” del mercado privado. En el capital privado tradicional, el ciclo de liquidación puede durar hasta varias semanas; durante ese tiempo, si cualquiera de las partes quiebra, la otra se queda sin nada. La liquidación atómica reduce el tiempo de entrega de “días” a “segundos”, y el riesgo de exposición se vuelve casi nulo.
Pero la liquidación atómica de DUSK también tiene un costo: exige que ambas partes estén en línea y firmen al mismo tiempo. Si B está desconectado, los valores de A no se pueden enviar. Suena menos cómodo que “emitir y luego confirmar”, pero la solución de DUSK es “representación por delegación”: puedes autorizar a un contrato inteligente para que firme en tu nombre, siempre que se cumplan las condiciones (por ejemplo, que la cuenta de B tenga fondos suficientes). El contrato se ejecuta automáticamente. Esto equivale a convertir la “firma manual” en un “disparo automático”: conservas la determinación de la liquidación y a la vez mejoras la eficiencia.$BTC
Cada vez creo más que DUSK no está creando una “cadena pública”, sino un “microservicio de infraestructura financiera”. Solo hace una cosa: hacer que la transferencia de activos sea imposible de equivocarse. El valor de $DUSK proviene de una prima por confianza que “no se puede fallar”.
#dusk @Dusk $DUSK

#TradFi晒单 Hoy cerré en ganancias el SNDKB que había comprado ayer, pero no llegué a la ventana del after-hours. La cotización de NAND de SanDisk viene subiendo dos veces seguidas esta semana, pero los comentarios de los canales indican que fue “reposición pasiva”, no una explosión real de demanda. En un escenario donde se empuja con fuerza el precio, si el SPOT ajusta a la baja y se estrecha el diferencial, es fácil que se produzca una estampida. SNDKB es un certificado 1:1 bajo custodia de ADGM, sin derecho a voto; como en EE. UU. no hay mercado y no se puede hacer cobertura por el cierre, yo solo tomo operaciones cortas con el colchón de utilidad. En la sesión nocturna, el rebote con poca liquidez lo aproveché para salir; esperaré a que se publiquen los resultados del 8/6 para ver si vale la pena volver a entrar. Ustedes, cuando compran $SNDKB , ¿lo hacen por creer en la transmisión del alza de precios de Flash, o por miedo a que la sobreexistencia de los canales les pase factura y prefieren asegurar ganancias primero?