Retsu玄
3.8k Publicaciones
Retsu玄
I write about crypto as systems, not stories
Abrir operación
Trader frecuente
1.1 años
478 Siguiendo
18.3K+ Seguidores
5.6K+ Me gusta
Publicaciones
Cartera
Todo
Cotizaciones
Directo
#dusk $DUSK @Dusk
Después de revisar los materiales de staking de Dusk, noté que la verdadera limitación nunca ha sido tanto el tamaño absoluto de un stake, sino la carga operativa de mantener un provisioner en línea y sincronizado. Hyperstaking simplemente traslada esa carga de un operador individual a una capa de smart contract que puede mantener posiciones, recolectar recompensas y asignarlas según reglas programables.
En la práctica, el mecanismo funciona permitiendo primero que el capital entre en un pool; luego, el pool llama a la función stake_from_contract del Transfer Contract para crear la posición. Más tarde, el Stake Contract notifica al mismo pool cuando las recompensas se vuelven reclamables o cuando se solicita un unstake, de modo que el propio contrato se convierte en el gestor activo del stake. El mínimo de 1000 DUSK y la ventana de maduración de aproximadamente 4320 bloques siguen aplicando, tanto si quien llama es un humano como si es un contrato.
La dificultad aparece cuando el pool se interpone entre el protocolo y el usuario final. La liquidez de salida puede verse limitada por la cola propia del pool, el calendario de comisiones o la contabilidad interna, incluso aunque la cadena base en sí no imponga ningún retraso de des-captación. Los usuarios también heredan exposición a errores en el cálculo de participaciones, fallos en callbacks, lógica de distribución de recompensas y cualquier clave de actualización que pueda tener el contrato. Lo que parece la eliminación de un nodo custodial es, por lo tanto, solo un cambio del plano de control a una capa superior.
Aun así, el diseño vale la pena observarlo porque abre una ruta para estrategias de capital que funcionen de manera continua en lugar de como acciones discretas del usuario. Si los contratos del pool demuestran estar abiertos, ser auditables y capaces de reconciliar cada movimiento de tokens on-chain, la misma maquinaria que actualmente se siente opaca podría convertirse en un primitivo duradero para la participación coordinada.
Después de revisar los materiales de staking de Dusk, noté que la verdadera limitación nunca ha sido tanto el tamaño absoluto de un stake, sino la carga operativa de mantener un provisioner en línea y sincronizado. Hyperstaking simplemente traslada esa carga de un operador individual a una capa de smart contract que puede mantener posiciones, recolectar recompensas y asignarlas según reglas programables.
En la práctica, el mecanismo funciona permitiendo primero que el capital entre en un pool; luego, el pool llama a la función stake_from_contract del Transfer Contract para crear la posición. Más tarde, el Stake Contract notifica al mismo pool cuando las recompensas se vuelven reclamables o cuando se solicita un unstake, de modo que el propio contrato se convierte en el gestor activo del stake. El mínimo de 1000 DUSK y la ventana de maduración de aproximadamente 4320 bloques siguen aplicando, tanto si quien llama es un humano como si es un contrato.
La dificultad aparece cuando el pool se interpone entre el protocolo y el usuario final. La liquidez de salida puede verse limitada por la cola propia del pool, el calendario de comisiones o la contabilidad interna, incluso aunque la cadena base en sí no imponga ningún retraso de des-captación. Los usuarios también heredan exposición a errores en el cálculo de participaciones, fallos en callbacks, lógica de distribución de recompensas y cualquier clave de actualización que pueda tener el contrato. Lo que parece la eliminación de un nodo custodial es, por lo tanto, solo un cambio del plano de control a una capa superior.
Aun así, el diseño vale la pena observarlo porque abre una ruta para estrategias de capital que funcionen de manera continua en lugar de como acciones discretas del usuario. Si los contratos del pool demuestran estar abiertos, ser auditables y capaces de reconciliar cada movimiento de tokens on-chain, la misma maquinaria que actualmente se siente opaca podría convertirse en un primitivo duradero para la participación coordinada.
Con verificación
Volví a revisar las páginas de productos actuales de Dusk y me sorprendí haciendo una única suposición amplia: como mainnet está en marcha, traté toda la pila financiera como si hubiera alcanzado la misma etapa. Las etiquetas de estado cambiaron esa perspectiva.
Dusk L1 está en funcionamiento, proporcionando consenso, liquidación, disponibilidad de datos, transacciones públicas y protegidas, y la ejecución de DuskVM. DuskEVM sigue en testnet, donde las apps de Solidity usan herramientas EVM familiares y DUSK para el gas, mientras se liquidan a través de DuskDS. El hedger también está en testnet, añadiendo flujos EVM confidenciales. Dusk Trade aún se está construyendo como la capa de producto para el onboarding, el acceso controlado, el trading, la coordinación de pagos y la liquidación.
Eso me hizo verlo de otra manera.
Mi interpretación: Dusk tiene una base en vivo, pero su tesis financiera más amplia depende de que varias capas en movimiento se vuelvan listas para producción al mismo tiempo. Un L1 seguro no prueba automáticamente que la capa EVM, el motor de privacidad, el puente y la app del usuario vayan a comportarse como un solo flujo de trabajo confiable de mercado.
Mi incertidumbre es el riesgo de integración. ¿Qué condiciones de lanzamiento y auditoría moverán DuskEVM y Hedger de testnet a mainnet? Si Dusk Trade depende de esas capas, ¿cómo se coordinarán las actualizaciones o los fallos sin interrumpir la elegibilidad, el trading o la liquidación?
Quiero verlo en la práctica.
#dusk $DUSK @Dusk
Dusk L1 está en funcionamiento, proporcionando consenso, liquidación, disponibilidad de datos, transacciones públicas y protegidas, y la ejecución de DuskVM. DuskEVM sigue en testnet, donde las apps de Solidity usan herramientas EVM familiares y DUSK para el gas, mientras se liquidan a través de DuskDS. El hedger también está en testnet, añadiendo flujos EVM confidenciales. Dusk Trade aún se está construyendo como la capa de producto para el onboarding, el acceso controlado, el trading, la coordinación de pagos y la liquidación.
Eso me hizo verlo de otra manera.
Mi interpretación: Dusk tiene una base en vivo, pero su tesis financiera más amplia depende de que varias capas en movimiento se vuelvan listas para producción al mismo tiempo. Un L1 seguro no prueba automáticamente que la capa EVM, el motor de privacidad, el puente y la app del usuario vayan a comportarse como un solo flujo de trabajo confiable de mercado.
Mi incertidumbre es el riesgo de integración. ¿Qué condiciones de lanzamiento y auditoría moverán DuskEVM y Hedger de testnet a mainnet? Si Dusk Trade depende de esas capas, ¿cómo se coordinarán las actualizaciones o los fallos sin interrumpir la elegibilidad, el trading o la liquidación?
Quiero verlo en la práctica.
#dusk $DUSK @Dusk
Con verificación
Lo diré con honestidad aquí: lo que me llamó la atención sobre DuskEVM no fue la compatibilidad con EVM por sí sola, sino cómo esa compatibilidad podría ampliar la utilidad real para Dusk.
DuskEVM está actualmente en testnet. Ofrece a los desarrolladores de Solidity carteras, librerías, Foundry y Hardhat familiares, con DUSK usado como el token de gas nativo. Las transacciones se ejecutan en DuskEVM, mientras que los lotes (batches) y los compromisos de estado se publican en DuskDS para disponibilidad de datos y liquidación. En términos prácticos, una menor fricción en las herramientas puede atraer a más creadores; aplicaciones útiles pueden generar más transacciones; y esas transacciones requieren DUSK para la ejecución. Por separado, hacer staking con DUSK ayuda a asegurar la red más amplia de Dusk.
Pero la compatibilidad no crea automáticamente liquidez para DEX, demanda de préstamos, TVL ni ingresos. Los creadores aún necesitan infraestructura confiable y productos a los que las personas vuelvan. Ahí es donde encaja Dusk Trade en la estrategia: se está construyendo como la capa de aplicación para activos financieros tokenizados, conectando onboarding, trading, coordinación de pagos y liquidación.
Mi opinión es sencilla: la utilidad de DUSK se vuelve significativa cuando el desarrollo en testnet se convierte en un uso repetido en mainnet. El mecanismo puede respaldar la demanda, pero la adopción todavía debe ganarse.
#dusk $DUSK @Dusk
DuskEVM está actualmente en testnet. Ofrece a los desarrolladores de Solidity carteras, librerías, Foundry y Hardhat familiares, con DUSK usado como el token de gas nativo. Las transacciones se ejecutan en DuskEVM, mientras que los lotes (batches) y los compromisos de estado se publican en DuskDS para disponibilidad de datos y liquidación. En términos prácticos, una menor fricción en las herramientas puede atraer a más creadores; aplicaciones útiles pueden generar más transacciones; y esas transacciones requieren DUSK para la ejecución. Por separado, hacer staking con DUSK ayuda a asegurar la red más amplia de Dusk.
Pero la compatibilidad no crea automáticamente liquidez para DEX, demanda de préstamos, TVL ni ingresos. Los creadores aún necesitan infraestructura confiable y productos a los que las personas vuelvan. Ahí es donde encaja Dusk Trade en la estrategia: se está construyendo como la capa de aplicación para activos financieros tokenizados, conectando onboarding, trading, coordinación de pagos y liquidación.
Mi opinión es sencilla: la utilidad de DUSK se vuelve significativa cuando el desarrollo en testnet se convierte en un uso repetido en mainnet. El mecanismo puede respaldar la demanda, pero la adopción todavía debe ganarse.
#dusk $DUSK @Dusk
#dusk $DUSK
Ayer por la noche volví a revisar la documentación del @Dusk y me sorprendí tratanto “finalized” como un solo instante. Asumí que, una vez que una transacción de Dusk estaba finalizada, los fondos deberían existir inmediatamente en DuskEVM. La documentación también hizo que esa suposición fuera demasiado sencilla.
En DuskEVM Testnet, un depósito se envía y se finaliza en Dusk L1, luego se procesa antes de que el saldo esté disponible en DuskEVM. Una retirada tiene más etapas: se inicia en DuskEVM, se espera un resultado (output), se prueba en Dusk L1, se superan las comprobaciones de madurez requerida y del dispute-game, y finalmente se finaliza en L1. La documentación advierte que la inclusión, la ejecución y la finalización no son el mismo estado, y que la preparación debería basarse en el estado del protocolo en lugar del tiempo transcurrido.
Eso me hizo verlo de otra manera.
Mi interpretación: el puente no es un retraso oculto; intenta convertir una máquina de estados entre capas en algo que una wallet pueda explicar. La tensión está entre la seguridad y la dependencia operativa. Los reintentos más seguros, la recuperación tras rollback y las comprobaciones de challenge reducen una clase de fallos, pero las rutas de recuperación también concentran la responsabilidad en algún lugar.
Mi incertidumbre: durante un rollback junto con una falla del relayer, ¿qué puede verificar un usuario de forma independiente antes de que los fondos se liberen o se reintenten? ¿Quién puede pausar o reanudar las operaciones del puente, y cuáles son los límites de esa autoridad si la emergencia dura más de lo esperado?
Quiero observar esto en la práctica.
Ayer por la noche volví a revisar la documentación del @Dusk y me sorprendí tratanto “finalized” como un solo instante. Asumí que, una vez que una transacción de Dusk estaba finalizada, los fondos deberían existir inmediatamente en DuskEVM. La documentación también hizo que esa suposición fuera demasiado sencilla.
En DuskEVM Testnet, un depósito se envía y se finaliza en Dusk L1, luego se procesa antes de que el saldo esté disponible en DuskEVM. Una retirada tiene más etapas: se inicia en DuskEVM, se espera un resultado (output), se prueba en Dusk L1, se superan las comprobaciones de madurez requerida y del dispute-game, y finalmente se finaliza en L1. La documentación advierte que la inclusión, la ejecución y la finalización no son el mismo estado, y que la preparación debería basarse en el estado del protocolo en lugar del tiempo transcurrido.
Eso me hizo verlo de otra manera.
Mi interpretación: el puente no es un retraso oculto; intenta convertir una máquina de estados entre capas en algo que una wallet pueda explicar. La tensión está entre la seguridad y la dependencia operativa. Los reintentos más seguros, la recuperación tras rollback y las comprobaciones de challenge reducen una clase de fallos, pero las rutas de recuperación también concentran la responsabilidad en algún lugar.
Mi incertidumbre: durante un rollback junto con una falla del relayer, ¿qué puede verificar un usuario de forma independiente antes de que los fondos se liberen o se reintenten? ¿Quién puede pausar o reanudar las operaciones del puente, y cuáles son los límites de esa autoridad si la emergencia dura más de lo esperado?
Quiero observar esto en la práctica.
#termmax @TermMax
Anoche volví a revisar la documentación de TermMax con una interpretación inicial: su tasa fija provenía principalmente de bloquear un préstamo hasta su vencimiento. Los mecanismos cambiaron esa visión.
FT es una reclamación fungible ERC-20 canjeable por un token de deuda al vencimiento. XT es su complemento fungible: 1 FT más 1 XT equivalen a un token de deuda, y XT llega a cero al vencimiento. GT es una posición ERC-721 que registra el colateral y la deuda de un préstamo individual. FT también puede venderse antes del vencimiento a la tasa y con la liquidez disponibles en ese momento.
Una orden en rango es una serie de órdenes continuas configuradas por un setter o un curador. Su curva de precios segmentada coloca liquidez a través de rangos de APR, de modo que la tasa que recibe un tomador cambia a medida que las operaciones avanzan por la curva.
Eso me hizo verlo de otra forma.
El contrato de órdenes de la V2 alimenta los días restantes hasta el vencimiento en su cálculo de APR con las reservas virtuales de la curva. Mi interpretación es que TermMax hace más que bloquear una tasa: crea un mercado donde el tiempo, la colocación de liquidez y la ejecución determinan cómo se descubre esa tasa.
¿Cómo se ejecutarán las salidas de FT cuando la liquidez se reduzca y lleguen vendedores al mismo tiempo? ¿Qué tan concentradas pueden volverse las órdenes en un solo segmento de la curva, y qué tan distribuido está el control sobre la curva y los parámetros de riesgo? También quiero ver cómo se comporta la dependencia del oráculo y la liquidación bajo estrés.
Quiero observar esto en la práctica.
Anoche volví a revisar la documentación de TermMax con una interpretación inicial: su tasa fija provenía principalmente de bloquear un préstamo hasta su vencimiento. Los mecanismos cambiaron esa visión.
FT es una reclamación fungible ERC-20 canjeable por un token de deuda al vencimiento. XT es su complemento fungible: 1 FT más 1 XT equivalen a un token de deuda, y XT llega a cero al vencimiento. GT es una posición ERC-721 que registra el colateral y la deuda de un préstamo individual. FT también puede venderse antes del vencimiento a la tasa y con la liquidez disponibles en ese momento.
Una orden en rango es una serie de órdenes continuas configuradas por un setter o un curador. Su curva de precios segmentada coloca liquidez a través de rangos de APR, de modo que la tasa que recibe un tomador cambia a medida que las operaciones avanzan por la curva.
Eso me hizo verlo de otra forma.
El contrato de órdenes de la V2 alimenta los días restantes hasta el vencimiento en su cálculo de APR con las reservas virtuales de la curva. Mi interpretación es que TermMax hace más que bloquear una tasa: crea un mercado donde el tiempo, la colocación de liquidez y la ejecución determinan cómo se descubre esa tasa.
¿Cómo se ejecutarán las salidas de FT cuando la liquidez se reduzca y lleguen vendedores al mismo tiempo? ¿Qué tan concentradas pueden volverse las órdenes en un solo segmento de la curva, y qué tan distribuido está el control sobre la curva y los parámetros de riesgo? También quiero ver cómo se comporta la dependencia del oráculo y la liquidación bajo estrés.
Quiero observar esto en la práctica.
#dusk $DUSK @Dusk
Inicialmente me acerqué a la documentación de Dusk con una comprensión simple: tokenizar un bono o un fondo consiste principalmente en registrar la propiedad en un contrato inteligente. Lo que cambió mi perspectiva fue darme cuenta de que la verdadera complejidad reside en el ecosistema que rodea al token: reglas sobre elegibilidad, transferencias, manejo de datos privados, pagos, liquidación y la prestación de servicios continua, todo ello debía alinearse.
Dusk aborda esto distribuyendo responsabilidades en su arquitectura. DuskVM ejecuta directamente contratos en Rust y WebAssembly en la Capa 1. DuskEVM permite que las aplicaciones basadas en Solidity aprovechen herramientas EVM familiares, mientras que los lotes, los metadatos de transacciones y los compromisos de estado avanzan hacia la liquidación final mediante DuskDS. Citadel emplea credenciales y pruebas de conocimiento cero para que los usuarios puedan demostrar que poseen una licencia aprobada sin revelar información personal ni los detalles completos de la licencia en la cadena; los proveedores de servicios siguen conservando el control sobre qué emisores y atributos reconocen.
Esto cambió la forma en que veía el sistema.
Mi conclusión: la privacidad aquí no consiste en la invisibilidad total. Se trata de permitir la verificación sin exigir una divulgación amplia. El reto, sin embargo, es determinar dónde reside el control cuando estos límites importan. Si una credencial se revoca a mitad de una operación, ¿qué estado gobierna la elegibilidad en la liquidación? ¿Y cuando chocan políticas de emisores, centros de negociación, auditores y reguladores, quién decide finalmente cuándo y cuánto debe divulgarse la información?
Me interesa ver cómo se desarrolla esto en el uso del mundo real.
Inicialmente me acerqué a la documentación de Dusk con una comprensión simple: tokenizar un bono o un fondo consiste principalmente en registrar la propiedad en un contrato inteligente. Lo que cambió mi perspectiva fue darme cuenta de que la verdadera complejidad reside en el ecosistema que rodea al token: reglas sobre elegibilidad, transferencias, manejo de datos privados, pagos, liquidación y la prestación de servicios continua, todo ello debía alinearse.
Dusk aborda esto distribuyendo responsabilidades en su arquitectura. DuskVM ejecuta directamente contratos en Rust y WebAssembly en la Capa 1. DuskEVM permite que las aplicaciones basadas en Solidity aprovechen herramientas EVM familiares, mientras que los lotes, los metadatos de transacciones y los compromisos de estado avanzan hacia la liquidación final mediante DuskDS. Citadel emplea credenciales y pruebas de conocimiento cero para que los usuarios puedan demostrar que poseen una licencia aprobada sin revelar información personal ni los detalles completos de la licencia en la cadena; los proveedores de servicios siguen conservando el control sobre qué emisores y atributos reconocen.
Esto cambió la forma en que veía el sistema.
Mi conclusión: la privacidad aquí no consiste en la invisibilidad total. Se trata de permitir la verificación sin exigir una divulgación amplia. El reto, sin embargo, es determinar dónde reside el control cuando estos límites importan. Si una credencial se revoca a mitad de una operación, ¿qué estado gobierna la elegibilidad en la liquidación? ¿Y cuando chocan políticas de emisores, centros de negociación, auditores y reguladores, quién decide finalmente cuándo y cuánto debe divulgarse la información?
Me interesa ver cómo se desarrolla esto en el uso del mundo real.
#termmax @TermMax
Pasé parte de la última noche rastreando un mercado de TermMax desde la documentación hasta el código del contrato. Mi interpretación inicial fue que FT, XT y GT eran tres etiquetas para un solo préstamo. FT es un ERC-20 comprado por debajo del valor nominal, canjeable por el valor nominal en el token de deuda al vencimiento y negociable antes de eso. XT es un ERC-20 que representa la obligación de intereses; el valor presente combinado de FT y XT equivale al monto inicial del préstamo. GT es un ERC-721 que representa una posición de préstamo y registra su colateral y su deuda.
Una orden de rango es una serie de órdenes continuas configuradas por un configurador o curador. Su curva de precios se construye a partir de segmentos con un límite superior de APR y un límite inferior de XT, y un solo mercado puede contener múltiples órdenes de rango.
Eso me hizo verlo de otra manera.
El whitepaper define su proporción de tiempo como los días hasta el vencimiento divididos entre 365. Los contratos V2 calculan los días restantes y pasan ese valor a la lógica de la curva y el intercambio FT/XT.
Mi interpretación es que la tasa que ve un usuario refleja la colocación de la curva, el movimiento de la reserva de XT y el tiempo. ¿Qué le ocurre a una salida (exit) de FT cuando la liquidez se concentra solo en unos pocos segmentos? En momentos de estrés del mercado, ¿cómo interactúan el respaldo (fallback) de oráculo, el deslizamiento (slippage) del DEX y la capacidad de liquidación? ¿Cómo debería dividirse el control entre curadores, guardianes, administradores y la gobernanza de tokens?
Quiero verlo en la práctica.
Pasé parte de la última noche rastreando un mercado de TermMax desde la documentación hasta el código del contrato. Mi interpretación inicial fue que FT, XT y GT eran tres etiquetas para un solo préstamo. FT es un ERC-20 comprado por debajo del valor nominal, canjeable por el valor nominal en el token de deuda al vencimiento y negociable antes de eso. XT es un ERC-20 que representa la obligación de intereses; el valor presente combinado de FT y XT equivale al monto inicial del préstamo. GT es un ERC-721 que representa una posición de préstamo y registra su colateral y su deuda.
Una orden de rango es una serie de órdenes continuas configuradas por un configurador o curador. Su curva de precios se construye a partir de segmentos con un límite superior de APR y un límite inferior de XT, y un solo mercado puede contener múltiples órdenes de rango.
Eso me hizo verlo de otra manera.
El whitepaper define su proporción de tiempo como los días hasta el vencimiento divididos entre 365. Los contratos V2 calculan los días restantes y pasan ese valor a la lógica de la curva y el intercambio FT/XT.
Mi interpretación es que la tasa que ve un usuario refleja la colocación de la curva, el movimiento de la reserva de XT y el tiempo. ¿Qué le ocurre a una salida (exit) de FT cuando la liquidez se concentra solo en unos pocos segmentos? En momentos de estrés del mercado, ¿cómo interactúan el respaldo (fallback) de oráculo, el deslizamiento (slippage) del DEX y la capacidad de liquidación? ¿Cómo debería dividirse el control entre curadores, guardianes, administradores y la gobernanza de tokens?
Quiero verlo en la práctica.
#termmax @TermMax
He pasado años observando DeFi y su búsqueda de rendimiento, y me resulta especialmente atractivo el prometedor de los mercados con tasa fija. He visto demasiados ciclos en los que la promesa de dinero fácil ha venido a costa de algo más grande: un token de cupón cero que define un derecho al vencimiento, no una salida fácil de realizar.
Algo en el diseño de TermMax llamó mi atención en el contexto de las órdenes por rango: cotizar una tasa a lo largo de una curva, y las órdenes atómicas que abarcan múltiples mercados compartiendo un pool. También me llamó la atención la búsqueda de liquidez de Smart Unwind para deshacer una posición de deuda, y el desafío de la fragmentación entre colaterales y vencimientos. Cada uno de estos elementos de diseño aborda el riesgo de iliquidez al salir, pero a cambio de reducir la disponibilidad de liquidez en cualquier momento. La necesidad de que exista un contrapartida que compre una obligación en un momento dado permanece, y dicha contrapartida puede no estar siempre disponible, lo que deriva en deslizamiento, retrasos o incluso la ausencia total de un mercado. La documentación de Alpha de TermMax reconoce esto al afirmar que la liquidez no está garantizada.
Me pregunto si la promesa del préstamo a tasa fija no es, en sí misma, la fuente del peligro, sino que simplemente traslada el problema a otro lugar. La entrega física del colateral sustenta cualquier obligación, pero el valor del colateral puede resultar ser menor que el de la responsabilidad debida si el prestamista no puede entregar el activo específico prometido en el momento de la liquidación. Las auditorías, el código abierto y los programas de recompensas son útiles, pero no eliminan los riesgos de fallas del contrato, oráculos o la fragmentación del mercado. Al fijar las tasas, TermMax reduce el riesgo de shocks de tasas, pero no el riesgo de shocks de liquidez. Este es el intercambio que estoy dispuesto a aceptar en nombre del rendimiento.
He pasado años observando DeFi y su búsqueda de rendimiento, y me resulta especialmente atractivo el prometedor de los mercados con tasa fija. He visto demasiados ciclos en los que la promesa de dinero fácil ha venido a costa de algo más grande: un token de cupón cero que define un derecho al vencimiento, no una salida fácil de realizar.
Algo en el diseño de TermMax llamó mi atención en el contexto de las órdenes por rango: cotizar una tasa a lo largo de una curva, y las órdenes atómicas que abarcan múltiples mercados compartiendo un pool. También me llamó la atención la búsqueda de liquidez de Smart Unwind para deshacer una posición de deuda, y el desafío de la fragmentación entre colaterales y vencimientos. Cada uno de estos elementos de diseño aborda el riesgo de iliquidez al salir, pero a cambio de reducir la disponibilidad de liquidez en cualquier momento. La necesidad de que exista un contrapartida que compre una obligación en un momento dado permanece, y dicha contrapartida puede no estar siempre disponible, lo que deriva en deslizamiento, retrasos o incluso la ausencia total de un mercado. La documentación de Alpha de TermMax reconoce esto al afirmar que la liquidez no está garantizada.
Me pregunto si la promesa del préstamo a tasa fija no es, en sí misma, la fuente del peligro, sino que simplemente traslada el problema a otro lugar. La entrega física del colateral sustenta cualquier obligación, pero el valor del colateral puede resultar ser menor que el de la responsabilidad debida si el prestamista no puede entregar el activo específico prometido en el momento de la liquidación. Las auditorías, el código abierto y los programas de recompensas son útiles, pero no eliminan los riesgos de fallas del contrato, oráculos o la fragmentación del mercado. Al fijar las tasas, TermMax reduce el riesgo de shocks de tasas, pero no el riesgo de shocks de liquidez. Este es el intercambio que estoy dispuesto a aceptar en nombre del rendimiento.
Anoche volví a consultar la documentación de Dusk, centrándome en comprender el papel real $DUSK que desempeña dentro del protocolo—su función técnica más que la historia impulsada por el mercado.
Lo primero que tuve que desentrañar fueron los dos modelos de transacción de DuskDS. Moonlight es la ruta conocida: cuentas públicas, saldos visibles, remitente, destinatario, cantidad. Phoenix funciona con “notas” cifradas. Para gastar una, el usuario proporciona una prueba de conocimiento cero que demuestra que las reglas de propiedad y saldo se cumplen. Piensa en entregarle a un cajero un sobre sellado cuya firma demuestra que se marcaron todas las casillas necesarias, sin revelar el contenido. Luego, un nullifier permite que la red rechace un segundo gasto sin identificar qué nota del árbol público se utilizó. Leí esa parte dos veces—después una notificación me apartó—porque privacidad no significa “que no se verifica nada”. Significa que la red verifica una prueba en lugar de los detalles ocultos de la transacción. Las claves de visualización pueden revelar información de forma selectiva.
El consenso tuvo otra pasada. Dusk lo llama Attestation concisa: los stakers, o provisioners, bloquean DUSK; la selección determinista ponderada por el stake elige un proponente de bloque, luego un comité valida y otro ratifica. Las firmas agregadas se convierten en una atestación de que un quórum estuvo de acuerdo. Así que $DUSK es tanto el gas como la participación respaldada por el stake.
La parte que examinaría después es la concentración. La selección es sin permiso, pero ¿qué tan distribuidos están en la práctica los créditos efectivos del comité? En las páginas que leí, no pude encontrar una explicación clara de quién cambia los parámetros globales. quizá se me escapó.
¿Qué evidencia mostraría que el poder del comité está genuinamente distribuido? ¿Cómo se gobiernan las claves de visualización en despliegues reales? ¿Quién puede cambiar los parámetros del protocolo y a través de qué proceso?
#dusk $DUSK @Dusk
Lo primero que tuve que desentrañar fueron los dos modelos de transacción de DuskDS. Moonlight es la ruta conocida: cuentas públicas, saldos visibles, remitente, destinatario, cantidad. Phoenix funciona con “notas” cifradas. Para gastar una, el usuario proporciona una prueba de conocimiento cero que demuestra que las reglas de propiedad y saldo se cumplen. Piensa en entregarle a un cajero un sobre sellado cuya firma demuestra que se marcaron todas las casillas necesarias, sin revelar el contenido. Luego, un nullifier permite que la red rechace un segundo gasto sin identificar qué nota del árbol público se utilizó. Leí esa parte dos veces—después una notificación me apartó—porque privacidad no significa “que no se verifica nada”. Significa que la red verifica una prueba en lugar de los detalles ocultos de la transacción. Las claves de visualización pueden revelar información de forma selectiva.
El consenso tuvo otra pasada. Dusk lo llama Attestation concisa: los stakers, o provisioners, bloquean DUSK; la selección determinista ponderada por el stake elige un proponente de bloque, luego un comité valida y otro ratifica. Las firmas agregadas se convierten en una atestación de que un quórum estuvo de acuerdo. Así que $DUSK es tanto el gas como la participación respaldada por el stake.
La parte que examinaría después es la concentración. La selección es sin permiso, pero ¿qué tan distribuidos están en la práctica los créditos efectivos del comité? En las páginas que leí, no pude encontrar una explicación clara de quién cambia los parámetros globales. quizá se me escapó.
¿Qué evidencia mostraría que el poder del comité está genuinamente distribuido? ¿Cómo se gobiernan las claves de visualización en despliegues reales? ¿Quién puede cambiar los parámetros del protocolo y a través de qué proceso?
#dusk $DUSK @Dusk
#termmax @TermMax
Anoche volví a revisar la documentación de TermMax. Mi interpretación inicial fue que solo bloqueaba una tasa de préstamo y emitía un recibo. Los documentos dicen que FT es un ERC-20 comprado por debajo del valor nominal y canjeable por un token de deuda al vencimiento. XT es el ERC-20 que representa la obligación de intereses; los valores actuales de FT y XT equivalen al monto inicial del préstamo. GT es un ERC-721 que registra el colateral y la deuda para una sola posición de préstamo.
Una orden por rango agrupa órdenes continuas configuradas por un configurador de órdenes o un curador. Su curva de precios tiene segmentos con un límite superior de APR y un límite inferior de XT. A medida que las operaciones cambian la reserva de XT, la tasa correspondiente se mueve a lo largo de la curva.
Eso me hizo mirarlo de otra manera.
El whitepaper usa los días hasta el vencimiento divididos entre 365 como su razón de tiempo; los contratos usan los días restantes en los cálculos de la curva. FT también puede venderse antes del vencimiento. Mi lectura es que una salida anticipada depende de la disponibilidad de precios y liquidez, no solo del canje por vencimiento.
Mi interpretación es que la fijación de la tasa se expresa mediante la colocación de liquidez. ¿Cómo se comporta la ejecución cuando la liquidez de FT se adelgaza o cuando la mayor parte de la liquidez está concentrada en un solo segmento? En momentos de estrés del mercado, ¿cómo interactúan el failover del oráculo, la liquidez del DEX, la capacidad de liquidación y los parámetros del protocolo? ¿Cuánto control conservan los curadores y los roles de administración?
Quiero verlo en la práctica.
Anoche volví a revisar la documentación de TermMax. Mi interpretación inicial fue que solo bloqueaba una tasa de préstamo y emitía un recibo. Los documentos dicen que FT es un ERC-20 comprado por debajo del valor nominal y canjeable por un token de deuda al vencimiento. XT es el ERC-20 que representa la obligación de intereses; los valores actuales de FT y XT equivalen al monto inicial del préstamo. GT es un ERC-721 que registra el colateral y la deuda para una sola posición de préstamo.
Una orden por rango agrupa órdenes continuas configuradas por un configurador de órdenes o un curador. Su curva de precios tiene segmentos con un límite superior de APR y un límite inferior de XT. A medida que las operaciones cambian la reserva de XT, la tasa correspondiente se mueve a lo largo de la curva.
Eso me hizo mirarlo de otra manera.
El whitepaper usa los días hasta el vencimiento divididos entre 365 como su razón de tiempo; los contratos usan los días restantes en los cálculos de la curva. FT también puede venderse antes del vencimiento. Mi lectura es que una salida anticipada depende de la disponibilidad de precios y liquidez, no solo del canje por vencimiento.
Mi interpretación es que la fijación de la tasa se expresa mediante la colocación de liquidez. ¿Cómo se comporta la ejecución cuando la liquidez de FT se adelgaza o cuando la mayor parte de la liquidez está concentrada en un solo segmento? En momentos de estrés del mercado, ¿cómo interactúan el failover del oráculo, la liquidez del DEX, la capacidad de liquidación y los parámetros del protocolo? ¿Cuánto control conservan los curadores y los roles de administración?
Quiero verlo en la práctica.
#dusk $DUSK @Dusk
Ayer volví a revisar la documentación de Dusk porque “DeFi regulado” es fácil de decir, pero difícil de imaginar como un sistema.
Primero pensé que la idea principal era la tokenización privada. Unas páginas más adelante, mi visión cambió: el token es solo una pieza. El trabajo más difícil es unir identidad, reglas de transferencia y liquidación sin exponer cada saldo o credencial.
La división entre DuskVM/DuskEVM me ayudó. DuskVM ejecuta contratos Rust/WASM en la L1; DuskEVM permite que las apps de Solidity publiquen datos y se liquiden mediante DuskDS. Mi lectura es que un camino se sitúa más cerca de las herramientas nativas de privacidad de Dusk, mientras que el otro reduce la barrera para los desarrolladores de Ethereum.
Citadel es donde aún tengo preguntas. Probar “soy elegible” sin revelar un registro completo de identidad tiene sentido, pero ¿quién emite y revoca las credenciales? ¿Qué sucede si un emisor queda comprometido? ¿Quién controla el acceso cuando la divulgación es legalmente necesaria?
También no estoy seguro de cómo funciona la descentralización en toda la pila. Se describe que la Acreditación Concisa es sin permisos y basada en comités, pero ¿qué tan descentralizado es el secuenciador de DuskEVM? ¿Quién puede actualizar puentes o contratos principales, y qué controles se aplican? El proceso DIP registra propuestas, pero no pude encontrar una respuesta clara sobre las decisiones finales.
¿Dónde está la suposición de seguridad más grande? ¿Puede coexistir la privacidad, el control regulatorio y una neutralidad creíble sin que una domine?
Ayer volví a revisar la documentación de Dusk porque “DeFi regulado” es fácil de decir, pero difícil de imaginar como un sistema.
Primero pensé que la idea principal era la tokenización privada. Unas páginas más adelante, mi visión cambió: el token es solo una pieza. El trabajo más difícil es unir identidad, reglas de transferencia y liquidación sin exponer cada saldo o credencial.
La división entre DuskVM/DuskEVM me ayudó. DuskVM ejecuta contratos Rust/WASM en la L1; DuskEVM permite que las apps de Solidity publiquen datos y se liquiden mediante DuskDS. Mi lectura es que un camino se sitúa más cerca de las herramientas nativas de privacidad de Dusk, mientras que el otro reduce la barrera para los desarrolladores de Ethereum.
Citadel es donde aún tengo preguntas. Probar “soy elegible” sin revelar un registro completo de identidad tiene sentido, pero ¿quién emite y revoca las credenciales? ¿Qué sucede si un emisor queda comprometido? ¿Quién controla el acceso cuando la divulgación es legalmente necesaria?
También no estoy seguro de cómo funciona la descentralización en toda la pila. Se describe que la Acreditación Concisa es sin permisos y basada en comités, pero ¿qué tan descentralizado es el secuenciador de DuskEVM? ¿Quién puede actualizar puentes o contratos principales, y qué controles se aplican? El proceso DIP registra propuestas, pero no pude encontrar una respuesta clara sobre las decisiones finales.
¿Dónde está la suposición de seguridad más grande? ¿Puede coexistir la privacidad, el control regulatorio y una neutralidad creíble sin que una domine?
SOLO EN: 🇺🇸 Melania Trump ahora ha registrado la calificación de aprobación más baja para una primera dama en la historia de EE. UU., alcanzando -12.
A lo largo del año, ha realizado apenas 38 apariciones públicas y no ha sido vista en público desde que asistió a la final de la Copa Mundial de la FIFA el 19 de julio.
#SECCancelsCryptoRulemakingMeeting
#SP500TopsRecord7800
A lo largo del año, ha realizado apenas 38 apariciones públicas y no ha sido vista en público desde que asistió a la final de la Copa Mundial de la FIFA el 19 de julio.
#SECCancelsCryptoRulemakingMeeting
#SP500TopsRecord7800
Binance ha programado el mantenimiento de la billetera de BNB Smart Chain (BEP20) para el 20 de agosto de 2026 a las 06:00 UTC. Los depósitos y retiros a través de la red se suspenderán a partir de las 05:55 UTC, y se espera que el mantenimiento dure aproximadamente una hora.
La negociación de tokens compatibles con BNB Smart Chain no se verá afectada, por lo que la interrupción solo aplica a depósitos y retiros. Binance indica que estos servicios se reanudarán una vez que la red se considere estable, sin un anuncio de seguimiento por separado.
Quien planee mover activos BEP20 a través de Binance podría querer completar la transacción antes de que comience la suspensión para evitar posibles retrasos.
La negociación de tokens compatibles con BNB Smart Chain no se verá afectada, por lo que la interrupción solo aplica a depósitos y retiros. Binance indica que estos servicios se reanudarán una vez que la red se considere estable, sin un anuncio de seguimiento por separado.
Quien planee mover activos BEP20 a través de Binance podría querer completar la transacción antes de que comience la suspensión para evitar posibles retrasos.
Creo que en los próximos 6–12 meses:
$BTC : $100K - $150K
La última vez que la volatilidad de Bitcoin estuvo tan baja en un mercado bajista fue en 2022.
$BTC estaba en su fase de formación de suelo y se disparó poco después.
Viene algo grande…
#SP500TopsRecord7800
#CardanoSplitsDijkstraUpgradeIntoTwoPhases
#SECReviewsSix3xLeveragedCommodityETFs
$BTC : $100K - $150K
La última vez que la volatilidad de Bitcoin estuvo tan baja en un mercado bajista fue en 2022.
$BTC estaba en su fase de formación de suelo y se disparó poco después.
Viene algo grande…
#SP500TopsRecord7800
#CardanoSplitsDijkstraUpgradeIntoTwoPhases
#SECReviewsSix3xLeveragedCommodityETFs
🇺🇸 ¡LA CASA BLANCA ESTÁ CELEBRANDO LA REUNIÓN CRIPTO MÁS IMPORTANTE HASTA LA FECHA ESTA SEMANA!
Con el presidente Trump, la presidenta de la SEC, Atkins, el presidente de la CFTC, Selig, y firmas cripto Coinbase, Ripple, Gemini, Polymarket, Kalshi, Nasdaq, NYSE, CME y DTCC, entre otras, presentes. Sin embargo, el detalle más notable es el apellido que aparece en esa lista.
DTCC es la organización que liquida la mayoría de las operaciones de acciones en Estados Unidos. ¿Por qué consultarles sobre legislación si ya están finalizando las liquidaciones? La única conclusión lógica es que el presidente Trump ha autorizado el inicio de la implementación. Este desarrollo es lo bastante significativo como para que no sea necesario que entre en vigor la CLARITY Act.
#IsraelStrikesLebanonKillsHezbollahCommander
#SP500TopsRecord7800
#SP500EarningsBeatExpectations
#USToPressNationsToPickUSOrChinaAICoalition
Con el presidente Trump, la presidenta de la SEC, Atkins, el presidente de la CFTC, Selig, y firmas cripto Coinbase, Ripple, Gemini, Polymarket, Kalshi, Nasdaq, NYSE, CME y DTCC, entre otras, presentes. Sin embargo, el detalle más notable es el apellido que aparece en esa lista.
DTCC es la organización que liquida la mayoría de las operaciones de acciones en Estados Unidos. ¿Por qué consultarles sobre legislación si ya están finalizando las liquidaciones? La única conclusión lógica es que el presidente Trump ha autorizado el inicio de la implementación. Este desarrollo es lo bastante significativo como para que no sea necesario que entre en vigor la CLARITY Act.
#IsraelStrikesLebanonKillsHezbollahCommander
#SP500TopsRecord7800
#SP500EarningsBeatExpectations
#USToPressNationsToPickUSOrChinaAICoalition
¡El mercado de las criptomonedas nunca duerme! Aquí están las observaciones más importantes en este momento:
$BTC está manteniendo su nivel de soporte crítico
$ETH muestra señales de un aumento de la actividad en la cadena,
y las altcoins parecen estar estabilizándose para un posible avance pronto.
¿Qué estás notando en el mercado estos días?
#Bitcoin #Ethereum
#IsraelStrikesLebanonKillsHezbollahCommander
#CardanoSplitsDijkstraUpgradeIntoTwoPhases #SECReviewsSix3xLeveragedCommodityETFs
$BTC está manteniendo su nivel de soporte crítico
$ETH muestra señales de un aumento de la actividad en la cadena,
y las altcoins parecen estar estabilizándose para un posible avance pronto.
¿Qué estás notando en el mercado estos días?
#Bitcoin #Ethereum
#IsraelStrikesLebanonKillsHezbollahCommander
#CardanoSplitsDijkstraUpgradeIntoTwoPhases #SECReviewsSix3xLeveragedCommodityETFs
#dusk $DUSK @Dusk
He estado el tiempo suficiente como para notar que las criptomonedas a menudo tratan la privacidad como una función de transferencia: oculta el remitente, el destinatario o el monto y ya está. Eso importa, pero un solo pago privado no crea un sistema financiero privado. La aplicación que lo rodea aún puede exponer posiciones, elegibilidad, contrapartes y reglas de transacción.
Algo de Dusk llamó mi atención. Phoenix ofrece transferencias con protección y basadas en notas, mientras que Moonlight mantiene una ruta pública de cuenta. Lo más interesante es lo que está por encima del pago. Los contratos y la capa de identidad de Dusk están diseñados para que una aplicación pueda comprobar la elegibilidad, hacer cumplir condiciones de transferencia o liquidación, y revelar hechos seleccionados a un emisor o auditor sin publicar todo.
Ya he visto ideas similares antes, y la parte difícil casi nunca fue solo la criptografía. Fue decidir dónde termina la privacidad: quién obtiene derechos de visualización, cómo se rige el acceso, qué metadatos se filtran y si los usuarios entienden las opciones. Las finanzas privadas todavía necesitan liquidez, precios, recuperación y monederos decentes. La ejecución confidencial no borra esos problemas.
Sigo preguntándome si las criptomonedas han encuadrado la privacidad de manera demasiado estrecha. Bitcoin mostró que el valor puede moverse sin un banco, pero su registro abierto también mostró cuánto revela la trazabilidad de un pago. Dusk está probando una idea más amplia: quizá la unidad útil de privacidad no sea una sola transacción, sino la relación financiera que la rodea. Aún no estoy convencido de que los compromisos estén resueltos, pero esa pregunta parece valer la pena seguirla.
He estado el tiempo suficiente como para notar que las criptomonedas a menudo tratan la privacidad como una función de transferencia: oculta el remitente, el destinatario o el monto y ya está. Eso importa, pero un solo pago privado no crea un sistema financiero privado. La aplicación que lo rodea aún puede exponer posiciones, elegibilidad, contrapartes y reglas de transacción.
Algo de Dusk llamó mi atención. Phoenix ofrece transferencias con protección y basadas en notas, mientras que Moonlight mantiene una ruta pública de cuenta. Lo más interesante es lo que está por encima del pago. Los contratos y la capa de identidad de Dusk están diseñados para que una aplicación pueda comprobar la elegibilidad, hacer cumplir condiciones de transferencia o liquidación, y revelar hechos seleccionados a un emisor o auditor sin publicar todo.
Ya he visto ideas similares antes, y la parte difícil casi nunca fue solo la criptografía. Fue decidir dónde termina la privacidad: quién obtiene derechos de visualización, cómo se rige el acceso, qué metadatos se filtran y si los usuarios entienden las opciones. Las finanzas privadas todavía necesitan liquidez, precios, recuperación y monederos decentes. La ejecución confidencial no borra esos problemas.
Sigo preguntándome si las criptomonedas han encuadrado la privacidad de manera demasiado estrecha. Bitcoin mostró que el valor puede moverse sin un banco, pero su registro abierto también mostró cuánto revela la trazabilidad de un pago. Dusk está probando una idea más amplia: quizá la unidad útil de privacidad no sea una sola transacción, sino la relación financiera que la rodea. Aún no estoy convencido de que los compromisos estén resueltos, pero esa pregunta parece valer la pena seguirla.
Con verificación
#dusk $DUSK ¿Cuál es el dilema definitorio de blockchain en el mundo de Blockchain?
Las blockchains públicas exponen todo: cada transacción, cada billetera y cada pago. Imagina un banco publicando carteras de clientes y operaciones en un cartel gigante. Las instituciones prosperan con la discreción, así que se niegan.
Las cadenas totalmente privadas crean lo contrario. Las identidades se desvanecen en el humo. Anonimato total. Sin auditorías. Sin supervisión. Los reguladores entran y se retiran. No es privacidad. Es evasión vestida de criptografía.
Dusk Network rechaza esta falsa elección.
Ofrece divulgación selectiva, un bisturí en un mundo de mazas. Las pruebas de conocimiento cero crean un puente entre la exposición y el anonimato. Demuestra el cumplimiento sin revelar tu mano. Muestra a los reguladores recibos, manteniendo privadas las saldos, los socios y las tenencias. ¿Necesitas verificación? Aquí está la clave. Los demás solo ven sombras.
Moonlight encarna esta doble arquitectura de transparencia y secreto. Su modo público brilla cuando importa la apertura. Phoenix, su gemelo cifrado, oculta importes, remitentes y destinatarios mientras preserva la legitimidad de la prueba. Cambia un interruptor y cambia de mundo. No es un compromiso. Es un espectro de soberanía.
Citadel entreteje identidad en la cadena, habilitando KYC y AML sin sacrificar la privacidad. El estándar XSC integra el cumplimiento en los valores digitales desde su nacimiento, incluyendo bonos, fondos y acciones. Todo es consciente de las reglas. La privacidad no es rebelión. Es la base de la rendición de cuentas.
Esto no es teoría de un PDF.
El 7 de enero de 2026, el mainnet de Dusk enciende. DuskEVM arranca. Desarrolladores de Solidity, vuestras herramientas están listas.
Con NPEX, un exchange neerlandés con licencia, Dusk traerá cientos de millones en valores tokenizados a la cadena. Activos reales. Escala real.
Con Quantoz Payments, creó EURQ, un euro digital en forma de dinero electrónico compatible con MiCA. Anclado y real.
Demasiado desnudo. Demasiado oscuro.
Dusk dice: elige la luz, elige la sombra. Oculta lo que debe permanecer oculto. Revela lo que debe verse. Esto no está equilibrado. Es control.
@Dusk
Las blockchains públicas exponen todo: cada transacción, cada billetera y cada pago. Imagina un banco publicando carteras de clientes y operaciones en un cartel gigante. Las instituciones prosperan con la discreción, así que se niegan.
Las cadenas totalmente privadas crean lo contrario. Las identidades se desvanecen en el humo. Anonimato total. Sin auditorías. Sin supervisión. Los reguladores entran y se retiran. No es privacidad. Es evasión vestida de criptografía.
Dusk Network rechaza esta falsa elección.
Ofrece divulgación selectiva, un bisturí en un mundo de mazas. Las pruebas de conocimiento cero crean un puente entre la exposición y el anonimato. Demuestra el cumplimiento sin revelar tu mano. Muestra a los reguladores recibos, manteniendo privadas las saldos, los socios y las tenencias. ¿Necesitas verificación? Aquí está la clave. Los demás solo ven sombras.
Moonlight encarna esta doble arquitectura de transparencia y secreto. Su modo público brilla cuando importa la apertura. Phoenix, su gemelo cifrado, oculta importes, remitentes y destinatarios mientras preserva la legitimidad de la prueba. Cambia un interruptor y cambia de mundo. No es un compromiso. Es un espectro de soberanía.
Citadel entreteje identidad en la cadena, habilitando KYC y AML sin sacrificar la privacidad. El estándar XSC integra el cumplimiento en los valores digitales desde su nacimiento, incluyendo bonos, fondos y acciones. Todo es consciente de las reglas. La privacidad no es rebelión. Es la base de la rendición de cuentas.
Esto no es teoría de un PDF.
El 7 de enero de 2026, el mainnet de Dusk enciende. DuskEVM arranca. Desarrolladores de Solidity, vuestras herramientas están listas.
Con NPEX, un exchange neerlandés con licencia, Dusk traerá cientos de millones en valores tokenizados a la cadena. Activos reales. Escala real.
Con Quantoz Payments, creó EURQ, un euro digital en forma de dinero electrónico compatible con MiCA. Anclado y real.
Demasiado desnudo. Demasiado oscuro.
Dusk dice: elige la luz, elige la sombra. Oculta lo que debe permanecer oculto. Revela lo que debe verse. Esto no está equilibrado. Es control.
@Dusk
#dusk $DUSK
He notado que cuanto más tiempo paso usando blockchains transparentes, más empieza a sentirse complicada la idea de “transparencia”.
La primera vez que esperé a que una transacción de Ethereum confirmara, la curiosidad me llevó a un explorador de bloques. Lo que me sorprendió no fue la demora, sino cuánta historia financiera puede revelar una dirección pública. Esa transparencia es útil para la verificación, pero se vuelve incómoda cuando el mismo modelo se aplica a instituciones que quizá no puedan o no quieran exponer cada posición, saldo o relación con contrapartes públicamente.
Eso es lo que hace que @Dusk sea interesante para mí.
Dusk no solo vuelve todo privado. Su arquitectura ofrece distintos modelos de visibilidad. Moonlight es transparente y basado en cuentas, mientras que Phoenix proporciona transferencias UTXO protegidas. En las transacciones de Phoenix, el remitente, el destinatario y el monto transferido quedan ocultos al público en general, mientras que las partes involucradas y quienes cuenten con la clave de vista adecuada pueden acceder a la información relevante.
La idea importante, entonces, no es “privacidad versus transparencia”. Es la visibilidad programable.
Dusk también utiliza pruebas de conocimiento cero y divulgación selectiva, permitiendo que los flujos financieros mantengan la información innecesaria en confidencialidad mientras proporcionan evidencia controlada cuando las partes autorizadas la necesitan. Su consenso Succinct Attestation ofrece finalización determinista una vez que un bloque es ratificado.
Ethereum tampoco se queda quieto. Las tecnologías de privacidad siguen desarrollándose allí, mientras que los ZK-rollups no deberían tratarse automáticamente como sistemas de transacciones privadas porque su función principal es escalar mediante pruebas de validez.
Así que sigo volviendo a una sola pregunta: si la actividad financiera puede permanecer protegida por defecto, ¿a qué exactamente debería permitírsele acceder a un auditor, y quién debería controlar ese permiso?
Ese límite puede importar más para la adopción institucional que simplemente hacer pública cada transacción.
He notado que cuanto más tiempo paso usando blockchains transparentes, más empieza a sentirse complicada la idea de “transparencia”.
La primera vez que esperé a que una transacción de Ethereum confirmara, la curiosidad me llevó a un explorador de bloques. Lo que me sorprendió no fue la demora, sino cuánta historia financiera puede revelar una dirección pública. Esa transparencia es útil para la verificación, pero se vuelve incómoda cuando el mismo modelo se aplica a instituciones que quizá no puedan o no quieran exponer cada posición, saldo o relación con contrapartes públicamente.
Eso es lo que hace que @Dusk sea interesante para mí.
Dusk no solo vuelve todo privado. Su arquitectura ofrece distintos modelos de visibilidad. Moonlight es transparente y basado en cuentas, mientras que Phoenix proporciona transferencias UTXO protegidas. En las transacciones de Phoenix, el remitente, el destinatario y el monto transferido quedan ocultos al público en general, mientras que las partes involucradas y quienes cuenten con la clave de vista adecuada pueden acceder a la información relevante.
La idea importante, entonces, no es “privacidad versus transparencia”. Es la visibilidad programable.
Dusk también utiliza pruebas de conocimiento cero y divulgación selectiva, permitiendo que los flujos financieros mantengan la información innecesaria en confidencialidad mientras proporcionan evidencia controlada cuando las partes autorizadas la necesitan. Su consenso Succinct Attestation ofrece finalización determinista una vez que un bloque es ratificado.
Ethereum tampoco se queda quieto. Las tecnologías de privacidad siguen desarrollándose allí, mientras que los ZK-rollups no deberían tratarse automáticamente como sistemas de transacciones privadas porque su función principal es escalar mediante pruebas de validez.
Así que sigo volviendo a una sola pregunta: si la actividad financiera puede permanecer protegida por defecto, ¿a qué exactamente debería permitírsele acceder a un auditor, y quién debería controlar ese permiso?
Ese límite puede importar más para la adopción institucional que simplemente hacer pública cada transacción.
Con verificación
#dusk $DUSK
He notado que la parte más difícil de llevar activos del mundo real a onchain no es la tokenización. Es lo que sucede después de que los activos llegan.
Los mercados regulados exigen verificaciones de identidad, restricciones de transferencia, auditabilidad y privacidad comercial. DeFi depende de infraestructura abierta y de la composabilidad. Hacer que esos sistemas coexistan sin menoscabar sus requisitos fundamentales es el verdadero desafío—y por eso vale la pena examinar @Dusk y Dusk Trade.
Dusk Trade se está construyendo como una capa de aplicación para activos financieros tokenizados, con flujos de trabajo que cubren el alta de inversores, el vinculado de carteras, transferencias controladas, la coordinación de pagos y el settlement conforme.
Por debajo, la red viva de Dusk combina finalización determinista con modelos de transacciones orientados a la privacidad y capacidades de divulgación selectiva. DuskEVM, actualmente en testnet, ofrece un entorno compatible con Solidity conectado a la infraestructura de settlement de Dusk.
Hedger, también en testnet, está diseñado para llevar flujos EVM confidenciales mediante cifrado homomórfico y pruebas de conocimiento cero. El objetivo es mantener privados los saldos sensibles y los detalles de las transacciones, preservando al mismo tiempo la ejecución verificable y la revisión autorizada.
La asociación NPEX conecta esta tesis con infraestructura europea regulada. Sin embargo, una asociación regulada no es la aprobación del modelo onchain completo, y la tecnología en testnet no es settlement de producción.
La pregunta central es si los controles al nivel MTF pueden coexistir con una liquidez DeFi significativa. Esos controles pueden hacer que los valores tokenizados sean aceptables para las instituciones, pero también podrían restringir su movimiento entre mercados de préstamos y pools de liquidez.
DUSK ya paga la ejecución, admite staking y ayuda a asegurar el ecosistema. Lo que aún no está probado es si la actividad financiera en vivo generará una demanda sostenida a escala.
Estaré siguiendo el progreso regulatorio, la emisión en vivo, el volumen de settlement y el uso institucional recurrente, no objetivos promocionales.
¿Pueden los controles regulados y la composabilidad de DeFi coexistir genuinamente a escala?
He notado que la parte más difícil de llevar activos del mundo real a onchain no es la tokenización. Es lo que sucede después de que los activos llegan.
Los mercados regulados exigen verificaciones de identidad, restricciones de transferencia, auditabilidad y privacidad comercial. DeFi depende de infraestructura abierta y de la composabilidad. Hacer que esos sistemas coexistan sin menoscabar sus requisitos fundamentales es el verdadero desafío—y por eso vale la pena examinar @Dusk y Dusk Trade.
Dusk Trade se está construyendo como una capa de aplicación para activos financieros tokenizados, con flujos de trabajo que cubren el alta de inversores, el vinculado de carteras, transferencias controladas, la coordinación de pagos y el settlement conforme.
Por debajo, la red viva de Dusk combina finalización determinista con modelos de transacciones orientados a la privacidad y capacidades de divulgación selectiva. DuskEVM, actualmente en testnet, ofrece un entorno compatible con Solidity conectado a la infraestructura de settlement de Dusk.
Hedger, también en testnet, está diseñado para llevar flujos EVM confidenciales mediante cifrado homomórfico y pruebas de conocimiento cero. El objetivo es mantener privados los saldos sensibles y los detalles de las transacciones, preservando al mismo tiempo la ejecución verificable y la revisión autorizada.
La asociación NPEX conecta esta tesis con infraestructura europea regulada. Sin embargo, una asociación regulada no es la aprobación del modelo onchain completo, y la tecnología en testnet no es settlement de producción.
La pregunta central es si los controles al nivel MTF pueden coexistir con una liquidez DeFi significativa. Esos controles pueden hacer que los valores tokenizados sean aceptables para las instituciones, pero también podrían restringir su movimiento entre mercados de préstamos y pools de liquidez.
DUSK ya paga la ejecución, admite staking y ayuda a asegurar el ecosistema. Lo que aún no está probado es si la actividad financiera en vivo generará una demanda sostenida a escala.
Estaré siguiendo el progreso regulatorio, la emisión en vivo, el volumen de settlement y el uso institucional recurrente, no objetivos promocionales.
¿Pueden los controles regulados y la composabilidad de DeFi coexistir genuinamente a escala?
Inicia sesión para explorar más contenidos