Rokyo

Quería saber a qué acceso real le da un dApp cuando pulsa “Connect Wallet”, así que probé el flujo en Dario y Pieswap en la red de prueba de Dusk. En ambos casos, la primera conexión solo devolvió el ID de perfil y la cuenta pública. El popup era explícito: “El sitio solo podrá usar la cuenta pública del perfil seleccionado”. Solo cuando pedí la dirección de recepción en modo protegido apareció un segundo paso de consentimiento, y solo entonces la respuesta incluyó shieldedAddress. El popup también cambió, nombrando la “dirección de recepción protegida compartible”. Ambas integraciones mostraron la misma secuencia.

Aquí está el giro: yo estaba tratando “Connect Wallet” como si fuera un único evento de permiso. No lo es. La prueba controlada separó el acceso a la cuenta pública de compartir la dirección de recepción protegida en el momento del consentimiento.

Esa separación coloca parte del límite de divulgación mínima en el flujo de consentimiento de la wallet, no totalmente en manos del usuario para gestionarlo. En ambas pruebas, hacer clic en “Connect” por sí solo nunca concedió el alcance de la dirección protegida; un dApp tuvo que atravesar un paso de consentimiento separado para obtenerlo.

También cometí un error al investigar. Pensé que la cadena de cuenta de 132 caracteres podría insinuar acceso protegido. No es así. Ambos dApps devolvieron el mismo formato de cuenta en la base, mientras que shieldedAddress se mantuvo ausente hasta la solicitud explícita.

Sigue habiendo una pregunta sin resolver. Una sesión anterior en mainnet de Dario se comportó de manera diferente, pero no la he reproducido bajo las mismas condiciones controladas, así que no lo estoy llamando una fuga. Solo puedo decir que el límite de permiso de “solo público” se mantuvo en las dos integraciones de testnet que comprobé, no que esté garantizado en cada entorno.

“Una conexión de wallet debería exponer el alcance que aprobaste, no dejarte inferirlo”.

Lo siguiente que me gustaría ver: la misma prueba controlada en mainnet con la misma versión de wallet, permisos limpios y una instrumentación idéntica, para ver si el límite se mantiene a través de los entornos.

#dusk $DUSK @Dusk

Asumí que, si quería hacer tres cosas en cadena—aprobar, intercambiar y luego apostar—, la cadena lo trataría como una sola acción que sucede o que no sucede. Un issue abierto en el propio repositorio de Rusk de Dusk dice que no funciona así hoy en día.

Una transacción de Dusk hoy en día lleva una única operación opcional: una llamada a un contrato, un despliegue o un memo, con un valor, un destinatario, un nonce y una firma. Así que aprobar, intercambiar y apostar se convierten en tres transacciones separadas, cada una incluida o descartada de forma independiente. El issue de Dusk lo afirma sin rodeos: no existe una garantía de atomicidad entre ellas. Haces land approve y swap pero no stake, y te quedas a medio camino, sin un rollback a nivel de protocolo.

El problema no es solo que los flujos de varios pasos pueden detenerse a la mitad. Corregir eso cambia quién tiene que absorber el costo de compatibilidad.

Un contrato batcher hace atómica toda la secuencia, porque una subllamada fallida revierte la transacción externa. Pero un contrato objetivo que verifique quién lo llama directamente vería el batcher, no tú, a menos que ese contrato ya esté escrito para mirar más allá del llamador inmediato. Una transacción por lotes a nivel de protocolo te mantiene como llamador en cada paso, pero no se envía sin un nuevo formato de transacción, cambios de consenso, un hard-fork y que cada SDK de billetera se ponga al día.

Agregar batching no elimina el tradeoff. Decide si la carga de compatibilidad recae en la autorización de la aplicación o en el stack del protocolo.

"Arreglar la atomicidad no elimina el tradeoff; decide dónde se mueve la carga de compatibilidad y el límite de confianza."

Lo que yo realmente querría observar: si Dusk elige el batcher a nivel de aplicación o la transacción a nivel de protocolo, y qué supuestos existentes de autorización obliga a cambiar esa elección a los desarrolladores.

#dusk $DUSK @Dusk

Asumí que el significado de una transacción quedaba fijado en el momento en que existían sus bytes: la decodifico una vez y obtengo la misma respuesta en todas partes. El changelog propio de Rusk para la actualización Boreas trata eso como algo que hay que diseñar, no como algo que pueda darse por sentado.

Boreas incorporó una decodificación de transacciones dependiente de la versión, vinculada a un hardfork específico, además de una selección de formato gobernada por hardfork para cómo se vuelven a reproducir los bloques antiguos. El código ahora tiene dos tipos explícitamente separados, CanonicalTransaction y LedgerTransaction, separando la representación en memoria de una transacción del formato en el que realmente se persiste en el ledger. Incluso hay una prueba de regresión dedicada únicamente para decodificar correctamente transacciones anteriores a la era Aegis durante la serialización de bloques.

Eso solo se vuelve necesario una vez que la decodificación de transacciones tiene que tener en cuenta diferentes eras de protocolo y etapas de procesamiento: recién recibidas del cable desde un cliente, almacenadas en memoria como un objeto canónico, y reproducidas de un bloque que es anterior a las reglas actuales.

Lo que significa que una actualización de protocolo no es segura solo porque las nuevas transacciones funcionen bajo las nuevas reglas. Solo es segura si esas nuevas reglas no rompen en silencio la capacidad de reproducir correctamente el estado histórico del ledger bajo las reglas que lo produjeron. Esta es la clase de fallo por desajuste de versión que la compatibilidad de reproducción histórica y la decodificación condicionada por hardfork están diseñadas para evitar.

"Una transacción solo es fiable si cada etapa que la toca está de acuerdo en lo que significa".

Lo que realmente me gustaría ver: una reproducción real de un bloque pre-Aegis en un nodo actual sin cambiar cómo se decodifican sus transacciones históricas bajo las reglas aplicables, no solo una prueba de regresión que pase de forma aislada.

#dusk $DUSK @Dusk

Asumí que «DuskEVM admite Solidity» significaba que los desarrolladores podían presentarse con la infraestructura existente de Ethereum y ya estaría. Los propios documentos de inicio rápido de Dusk agregan en silencio un paso que la mayoría de la gente se salta: verificar el origen.

Implementar es la parte fácil. DuskEVM usa Blockscout como su explorador, y hacer que un contrato se verifique allí, «Verify & Publish», significa que los ajustes de compilación relevantes, la versión del compilador, la configuración del optimizador, los archivos de origen, los argumentos del constructor, deben poder reproducir el bytecode que realmente se implementó.

Eso es una exigencia diferente a la compatibilidad con EVM. La implementación prueba que el código puede ejecutarse. La verificación permite que otra persona compruebe qué es lo que realmente se está ejecutando. Un contrato puede implementarse y funcionar mientras sigue sin estar verificado, dejando a cualquiera más sin la posibilidad de comprobar de forma independiente si el código fuente publicado coincide realmente con lo que está en vivo.

Lo que significa que «compatible con EVM» y «listo para desarrolladores» no son exactamente la misma afirmación. Una trata sobre si tu código se ejecuta aquí. La otra trata sobre si un auditor, una institución o un usuario pueden confirmar realmente que lo que se está ejecutando coincide con lo que se ha afirmado.

«Una cadena puede ejecutar tu contrato de Solidity y aun así dejarte incapaz de demostrar qué es realmente ese contrato.»

Lo que me gustaría ver a continuación: si un contrato implementado a través de la ruta estándar de Solidity/Hardhat se puede verificar de forma fiable con respecto a su bytecode implementado, en lugar de simplemente haberse implementado con éxito.

#dusk $DUSK @Dusk

Asumí que la fragmentación era la mayor parte de la historia de la liquidez: dividir un activo en porciones más pequeñas y ampliar el conjunto de posibles propietarios. El propio escrito de Dusk sobre tokenización para PYMES, publicado esta semana, afirma que eso es solo una parte limitada del panorama, y un estudio académico independiente sobre activos tokenizados reales muestra por qué esa brecha importa.

Dusk lo dice sin rodeos: "la propiedad fraccionada desempeña un papel limitado. Las unidades más pequeñas no pueden generar demanda de inversores, certeza jurídica ni liquidez". El valor, según argumentan, proviene de conectar el valor con operadores responsables, compradores elegibles, pagos y liquidación fiables, y un centro autorizado, no de lo fino que esté segmentado.

Un estudio de 2023 publicado en Financial Innovation probó algo cercano a esto con 58 propiedades residenciales tokenizadas reales en EE. UU. Sobre la propiedad, los resultados fueron claros: la propiedad promedio tenía 254 propietarios distintos. Pero en cuanto a la negociación, la imagen fue diferente. La propiedad se traspasaba aproximadamente una vez al año en promedio, y las propiedades en exchanges descentralizados se negociaban con más frecuencia que las que se negociaban de igual a igual, aunque el punto de partida anual se mantuvo bajo en ambos casos.

Lo que significa que las dos afirmaciones que la gente suele confundir, "este activo está fraccionado" y "este activo es líquido", en realidad describen cosas distintas. La fragmentación es una característica del token. La liquidez es una característica del mercado que lo rodea.

"Una unidad más pequeña puede ampliar quién tiene permitido poseer algo sin crear un mercado donde puedan, en la práctica, negociarlo".

Lo que vigilaría en los activos vinculados a NPEX que lleguen a Dusk: no qué tan finamente están fraccionados en la emisión, sino si la negociación secundaria realmente persiste después de eso, la misma brecha que el estudio de las 58 propiedades encontró entre la propiedad amplia y la negociación activa.

#dusk $DUSK @Dusk

Asumí que un hack de puente significaba que alguien encontró un fallo en el código, una debilidad en la criptografía, algo que una auditoría de seguridad había pasado por alto. El post-mortem de Dusk sobre su incidente de puente de enero describe otra cosa.

El 16 de enero, un atacante comprometió una wallet de firmas usada por el puente Dusk-to-EVM, moviendo fondos directamente en Dusk antes de enrutar parte de ellos hacia BNB Smart Chain. Dusk apagó el puente a mitad del ataque, lo que causó que un intento final de transferencia de aproximadamente 8.9 millones de DUSK fallara.

Esto no fue un fallo de consenso ni una explotación de protocolo. Dusk dice que la causa directa fue la (comprometida) de la clave, y que el diseño antiguo permitía que la wallet de firmas, el manejo de eventos y la conectividad de red funcionaran todos dentro de una misma ruta. La debilidad se concentró en la autoridad operativa, no en una criptografía débil.

El rediseño que siguió se resume en una frase enterrada en el post-mortem: "la ingesta ya no es equivalente al gasto". Ver que ocurrió un evento y tener la autoridad para liberar fondos debido a él antes era el mismo paso. Ahora no lo es. La ingesta de eventos se pone con checkpoints y se encola como un trabajo; un proceso separado y explícito es el que realmente mueve fondos contra él.

"Un protocolo puede funcionar según lo diseñado mientras la capa operativa que lo rodea dé a una sola ruta comprometida demasiada autoridad".

Lo que realmente me gustaría ver: confirmación de que el puente rediseñado mantiene en la práctica la ingesta de eventos y la liberación de fondos en rutas separadas, no solo en la descripción del nuevo diseño que aparece en el post-mortem.

#dusk $DUSK @Dusk

Supuse que un préstamo con tasa fija en TermMax significaba un solo número: lo que pedirías prestado, esa sería la cantidad fija que eventualmente devolverías. Pero no es toda la historia.

Aquí está el mecanismo. Cuando un prestatario toma un préstamo, recibe tokens de deuda y puede pagarlo devolviendo ese mismo valor nominal exacto. Pero TermMax también les permite recomprar FT, el token que representa esa misma deuda, en el mercado abierto. FT puede negociarse por debajo del valor nominal antes del vencimiento, y el ejemplo trabajado de TermMax ilustra cómo eso puede reducir el costo de la devolución. En ese ejemplo, un prestatario que debe 800 FT puede recomprarlos a $0.80 cada uno y saldar la deuda por $640, en lugar de pagar directamente $800. La misma obligación, dos precios distintos para cerrarla.

Eso no es una diferencia por redondeo. Es una brecha del 20% entre el monto de devolución contractual y lo que realmente puede costar cerrar la posición, dependiendo de dónde esté negociándose FT ese día.

Esto revela lo siguiente: el mismo token FT es simultáneamente el derecho de ingreso fijo del prestamista mantenido hasta el vencimiento y, para el prestatario, una herramienta para saldar la deuda de forma anticipada. La deuda no es un número que permanece inmóvil entre la originación y el vencimiento. Puede tener un precio de mercado antes del vencimiento, y ese precio puede moverse de manera independiente de la tasa cotizada en la originación.

Una salvedad que vale la pena nombrar: la propia documentación de TermMax utiliza esa cifra del 20% como un ejemplo trabajado, no como una condición de mercado garantizada. El descuento real de FT se mueve con las condiciones del mercado y no siempre será tan amplio.

Entonces, ¿qué número debería definir realmente un “préstamo de tasa fija”: la tasa que bloqueaste en la originación, o el precio de mercado del instrumento que tendrías que comprar para cerrarlo?

#termmax @TermMax

Asumí que “liquidated” en TermMax significaba que una posición se liquidaba simplemente en el momento en que intervenía un liquidator. Pero no es exactamente así para posiciones más grandes.

La liquidación se activa cuando el LTV de un préstamo supera el umbral LLTV, o cuando el prestatario incumple el pago de vencimiento fijo, abriendo una ventana de liquidación de dos horas. Pero hay un tope incorporado en el propio mecanismo: si la deuda pendiente supera los $10,000, un liquidator solo puede liquidar hasta el 50% del valor total de la deuda en ese turno.

Así que, para una posición lo suficientemente grande, la limitación no es necesariamente si un liquidator quiere actuar. El protocolo en sí no permitirá que una sola liquidación liquide todo.

Eso cambia lo que significa “parcialmente liquidated”. No necesariamente es una prueba de que la demanda de liquidación era demasiado delgada o de que el mercado se movió demasiado rápido. Puede ser una consecuencia esperada del propio mecanismo. Y si el préstamo aún no se ha pagado o solo se ha liquidado parcialmente cuando se cierra esa ventana de dos horas, la entrega física comienza automáticamente.

El tamaño de una posición no solo afecta cuánto está en riesgo. También puede afectar si el proceso de liquidación puede resolver por completo la posición dentro de la ventana disponible.

Entonces, ¿la eficiencia de la liquidación debe juzgarse por si aparece un liquidator, o por cuánto de la posición el mecanismo realmente puede resolver antes de que se cierre la ventana?

#termmax @TermMax

Respuestas de KYC para quienes se calificaron en el onboarding. Los controles de transferencia responden a quién sigue siendo elegible cuando el activo se mueve. El modelo de infraestructura de mercado propio de Dusk trata eso como etapas separadas, y esa brecha es lo interesante.

Dusk enumera el onboarding de inversores, "vincular billeteras a participantes o credenciales verificadas", por separado de los controles de transferencia, "hacer cumplir quién puede mantener o transferir el activo". Uno establece un estado inicial de elegibilidad. El otro es lo que hace que ese estado sea exigible cuando el activo realmente se mueve.

El material XSC más antiguo va más allá del onboarding: los emisores pueden incluir billeteras en lista blanca y conservar controles a nivel de activo, como congelar o forzar la transferencia. Esto importa porque la elegibilidad no solo se establece una vez. Tiene que mantenerse exigible después de la decisión inicial.

Lo que significa que "KYC aprobado" y "elegible para mantener este activo" son dos afirmaciones diferentes que pueden divergir en silencio. Una billetera puede permanecer verificada en el sentido de identidad mientras ya no sea el tipo de titular que este activo en particular tiene permitido. La exigencia de cumplimiento no termina en el onboarding; tiene que continuar en el ciclo de transferencias del activo.

"Aprobar un control de cumplimiento y seguir siendo elegible son dos afirmaciones diferentes".

Eso cambia la pregunta real de evaluación. No "¿este activo tiene controles de elegibilidad". La pregunta real es si el estado de elegibilidad actual se hace cumplir cuando el activo se mueve, o si simplemente el estado de onboarding original continúa.

Lo que yo realmente querría ver: una billetera cuya elegibilidad cambie después del onboarding, por ejemplo, un cambio de jurisdicción, mientras aún mantiene el activo, luego una transferencia intentada y si la lógica de transferencia del activo detecta ese cambio.

#dusk $DUSK @Dusk

Asumí que un “mercado de tasa fija” significaba una sola tasa: ya sabes el número antes de hacer la transacción, punto. Al mirar con más detalle cómo TermMax realmente fija el precio de un préstamo, esa suposición no se cumple.

Las tasas no se cotizan como un único número. Se definen mediante curvas. En una Lending Range Order, la curva puede empezar con una tasa más baja y subir por escalones a medida que se llena más de la orden, de forma similar a como un AMM avanza por distintos niveles de precio en lugar de ofrecer un solo precio. Un mercado puede mantener varias range orders a la vez, así que distintos participantes pueden completar en puntos diferentes de la curva.

Esa es la distinción que me faltaba: el mercado no tiene una sola tasa fija. Cada posición ejecutada obtiene una tasa fija determinada por el punto en el que su ejecución cae sobre la curva. Una vez completada, esa tasa se mantiene fija durante el plazo.

La curva tampoco es arbitraria en tiempo de ejecución. Las acciones del Curator se ajustan a restricciones del protocolo como mercados con lista blanca y cambios temporizados.

Así que cuando TermMax la llama un “mercado de tasa fija”, la pregunta interesante no es simplemente cuál es la tasa fija. Es cuánto de esa tasa está determinado por la curva y cuánto por el lugar exacto en el que tu liquidez realmente se llena.

#termmax @TermMax

Pregunta a la mayoría de las personas que evalúan una cadena de privacidad si es privada, y marcarán una casilla: sí o no. Para Dusk, esa es la pregunta equivocada, y el propio texto de Dusk sobre Hedger muestra por qué.

Zedger, el protocolo nativo de privacidad preservada de Dusk, puede proporcionar anonimato total. Hedger, creado para DuskEVM, no puede. Dusk lo dice sin rodeos: el modelo de cuentas de la EVM impide el anonimato total, mientras que Hedger mantiene los detalles de las transacciones cifrados mediante cifrado homomórfico y pruebas de conocimiento cero, sin ofrecer la misma garantía de anonimato completo.

Eso no es un fallo que Dusk esté ocultando. Es la compensación que la arquitectura hace explícita: la compatibilidad con EVM conlleva una garantía de privacidad distinta a la del anonimato total de Zedger.

Así es lo que realmente cambia cuando se realiza esa compensación. La diferencia importante no es simplemente si los detalles de las transacciones se cifran. Es la garantía de anonimato. Usa la ruta de Zedger y el anonimato total está disponible. Usa la ruta de Hedger compatible con EVM y no está garantizado lo mismo. Mis maaarcas, misma palabra "confidential," distinta garantía debajo.

Eso cambia cuál debería ser la pregunta real para cualquiera que evalúe esto. No "¿Dusk admite transacciones confidenciales?" Ambas rutas admiten flujos de transacciones privadas, pero no proporcionan la misma garantía de anonimato. La pregunta real es si la garantía que obtiene un activo regulado coincide realmente con lo que su flujo de trabajo necesita.

"La privacidad que mantiene los detalles de las transacciones en confidencialidad y la privacidad que proporciona anonimato total son dos garantías distintas, incluso cuando un proyecto publica ambas bajo la misma palabra."

Lo que yo realmente querría ver: qué ruta de privacidad usa en realidad una seguridad regulada dentro de Dusk Trade, y qué requiere ese flujo de trabajo para permanecer oculto.

#dusk $DUSK @Dusk

Asumí que hacer staking en una cadena PoS significaba que una sola clave controlaba todo: metes DUSK, obtienes recompensas, y la misma clave lo gestiona de principio a fin.

La documentación oficial del operador de Dusk lo divide en dos.

La clave de consenso es la clave que usa un nodo para firmar y votar en el consenso. Tiene que residir en un nodo conectado a internet y participar mientras el validador opera. La clave de propietario es diferente: es la clave que puede deshacer el staking o retirar fondos, y la documentación indica que no necesita tocar el nodo en absoluto.

El beneficio de seguridad no es simplemente que existan dos claves. Es que la autoridad para participar en el consenso y la autoridad para retirar fondos no tienen que estar en el mismo lugar. Si la clave de consenso se ve comprometida porque el servidor en el que está alojada sufre una brecha, un atacante puede interferir con la participación en el consenso, pero aun así no puede desestacar ni retirar el stake. Esa autoridad nunca estuvo en la máquina que, en primer lugar, está expuesta a internet. En consecuencia, la pregunta real de seguridad no es solo cuánto está staked. Es dónde se encuentra realmente la autoridad para retirarlo en relación con la máquina que está expuesta a los atacantes.

Pero hay una trampa que la documentación no oculta: esta separación no es lo predeterminado. Si haces staking sin especificar un owner separado, la clave de consenso automáticamente pasa a ser también la clave de propietario: una clave, un límite, de vuelta al modelo que yo asumí originalmente. La configuración más segura es una elección que el operador tiene que hacer de forma activa, no algo que el protocolo les impone.

"Un límite de seguridad que hay que aceptar es una garantía distinta a la que se incorpora en el camino predeterminado, incluso cuando ambos están técnicamente disponibles".

Lo que realmente me gustaría saber: cuántos provisioners activos se ejecutan con una clave de propietario separada frente al valor predeterminado, porque eso me diría si el límite más fuerte se está adoptando de verdad, en lugar de que solo esté disponible.

#dusk $DUSK @Dusk

Asumí que una posición fija con plazo cerrado significaba exactamente eso: cerrada, punto y final, hasta el vencimiento. Luego encontré el Smart Unwind de TermMax y asumí que simplemente lo resolvía. No funciona como yo esperaba.

Smart Unwind no extrae liquidez de salida de un pool. Funciona haciendo que tu posición sea lo suficientemente atractiva como para que alguien más quiera hacerse cargo de ella. Un leverager establece un APR o un precio objetivo. Si el colateral se aprecia lo suficiente, un arbitrajista compra la posición a ese precio fijo y vende el colateral en el mercado abierto para obtener una ganancia. Si suben las tasas de préstamo, es posible que un nuevo leverager se haga cargo de la posición con una prima en lugar de abrir una nueva.

Así que el protocolo no está garantizando la salida. La salida depende de que otra persona encuentre la operación lo bastante atractiva como para tomarla.

Esa es la parte que no había considerado: las condiciones en las que un leverager más quiere salir —un precio del colateral en caída o un mercado bajo estrés— podrían ser precisamente las condiciones en las que un arbitrajista no tiene apreciación que capturar y un nuevo leverager no tiene motivos para hacerse cargo de una posición perdedora. El mecanismo puede funcionar mejor justamente cuando menos lo necesitarías, y quedarse en silencio exactamente cuando lo necesitarías.

Smart Unwind tampoco está en vivo aún, así que todavía no se observa nada de esto; es solo lo que sugiere el diseño.

¿Un mecanismo de salida que depende del incentivo de otra persona realmente resuelve la iliquidez de las posiciones con plazo fijo, o solo traslada el mismo problema a quien tenga que encontrarse en el otro lado?

#termmax @TermMax

Miré más allá de la etiqueta de “financiación a tasa fija” de TermMax para ver qué está pasando realmente por debajo.

El componente parece menos una piscina de préstamos con un APY fijo y más un mercado de renta fija en cadena. Su FT es un token tipo bono cupón cero: los prestamistas lo compran por debajo del valor nominal y lo canjean a la par al vencimiento, con el rendimiento fijado en el momento de la entrada. Eso cambia la forma en que pienso sobre el producto: la tasa fija no es solo un parámetro de una piscina de préstamos. Está incorporada en una reclamación con vencimiento.

En enero, el mismo modelo de tasa fija se extendió más allá de las garantías nativas de cripto hacia valores tokenizados, lanzando préstamos con tasa fija respaldados por acciones tokenizadas de Ondo Global Markets.

Una tasa fija elimina la incertidumbre sobre la tasa durante el plazo. No elimina la necesidad de refinanciar cuando termina el plazo. TermMax ya tiene un rollover con un clic, ya sea hacia un vencimiento fijo posterior o hacia los mercados de tasa variable de Morpho, así que el protocolo ha diseñado explícitamente para ese paso de refinanciación. Lo que está bien documentado es la arquitectura; lo que escasea es la información sobre cómo funciona ese camino cuando muchas posiciones necesitan renovarse a la vez bajo estrés.

Con $90M+ de TVL en 10 cadenas EVM y el TGE del $TMX programado para el 25 de agosto, esa es la parte que yo vigilaría después.

#termmax @TermMax

Esperaba que las "verificaciones de elegibilidad" detrás de Dusk Trade fueran algo construido específicamente para el trading. Un módulo de cumplimiento atornillado a la capa del exchange, como hacen la mayoría de los brokers al integrar KYC directamente en la plataforma.

Pero no es eso lo que hay debajo.

La capa de identidad en la que se apoya Dusk Trade se llama Citadel, y no nació como una función de trading. Dusk la lanzó en enero de 2023 como un protocolo de KYC/identidad de conocimiento cero: demostrar que tienes un credencial válido sin revelar lo que contiene, y luego reutilizar esa prueba en distintos servicios en lugar de volver a enviar tus datos cada vez.

Ese momento cambia la forma en que leo las "verificaciones de elegibilidad" en la documentación. Parece menos un cumplimiento a medida construido para un solo producto y más una primitiva de identidad que antecede al producto que la utiliza.

Lo interesante es que Citadel fue diseñado para proveedores de servicios más allá de un único flujo de trading. Dusk lo describió como una capa de identidad a la que las empresas podrían recurrir para verificar si alguien cumple sus criterios sin tener que hacerse con la custodia de todos los datos de identidad subyacentes.

"Una verificación de elegibilidad construida para un solo producto y una capa de identidad diseñada para sobrevivir al producto son dos tipos distintos de infraestructura, incluso cuando los usuarios experimentan ambas como 'demostrar quién eres.'"

Lo que en realidad me gustaría ver: un credencial probado mediante Citadel y aceptado por otro proveedor de servicios fuera de Dusk Trade; la evidencia que convierte "una primitiva de identidad compartida" de una descripción arquitectónica en una reutilización demostrada entre servicios.

#dusk $DUSK @Dusk

Esperaba que "Dusk haga pareja con Chainlink" significara el discurso habitual. Un puente. Tokens moviéndose entre cadenas. La historia estándar de interoperabilidad que eventualmente anuncia cada proyecto.

Eso es parte de ello, pero es la parte más pequeña.

Anunciado en noviembre, el acuerdo vincula Chainlink CCIP como la capa de interoperabilidad para los valores tokenizados de NPEX con algo fácil de pasar por alto: Chainlink DataLink convirtiéndose en el oráculo exclusivo de datos onchain para NPEX. No uno de varios feeds de precios. El exclusivo. El mismo acuerdo también permite que DUSK en sí mismo se mueva de forma nativa entre Ethereum y Solana a través del estándar CCT de Chainlink, de modo que el token también obtiene la historia del puente.

Nueve meses después, esa es la parte que merece separarse. CCIP permite que un activo se mueva a través de ecosistemas. DataLink entrega los datos de mercado de NPEX que el sistema receptor puede confiar. Uno trata sobre el alcance. El otro, sobre quién obtiene ser creído. Cualquier cadena que consuma esos datos de NPEX está construyendo sobre la misma fuente oficial de datos de mercado.

No creo que sea automáticamente una falla. Los mercados regulados ya dependen de fuentes autorizadas de datos de mercado. Pero significa que aquí la composabilidad entre cadenas no es completamente infraestructura neutral. Es una composabilidad construida alrededor de una fuente exclusiva para los datos oficiales de mercado de NPEX, sin importar dónde y cuándo se lean esos datos.

"Poder mover un activo entre cadenas y ser la fuente exclusiva de sus datos oficiales de mercado son dos tipos distintos de poder, incluso cuando un solo acuerdo concede ambos."

Lo que en realidad me gustaría saber, nueve meses después: qué ocurre en las otras cadenas si esa fuente de datos exclusiva de NPEX se vuelve inaccesible o es cuestionada, y si "composable" en silencio significa "dependiente de una única línea exclusiva que vuelve a NPEX".

#dusk $DUSK @Dusk

Antes pensaba que la tokenización y la emisión nativa eran básicamente dos formas de poner un activo en la cadena. La página de comparación de Dusk cambió ese enfoque. No son dos grados de la misma cosa. Son arquitecturas totalmente distintas.

Según la propia definición de Dusk, la tokenización emite un token que representa un activo o un derecho sobre él, mientras que el activo subyacente puede seguir vinculado a los procesos de custodia, registro y liquidación que ya se ejecutaban fuera de la cadena. El token es una representación, no el propio activo subyacente. La emisión nativa elimina esa capa: el activo existe en la cadena como tal, y su ciclo de vida —emitido, transferido, gestionado, liquidado— no necesita un registro separado en algún otro lugar que apunte a él.

El punto clave es que un token aún puede depender de otro sistema que permanezca como la fuente real de la verdad. Si ese registro fuera de la cadena se retrasa o falla, la garantía del token solo será tan sólida como la conciliación que lo respalde.

Aquí es donde se vuelve condicional. La comparación de Dusk dice que la emisión nativa puede reducir la dependencia de capas separadas de custodia y registro, "dependiendo de la estructura legal". Ese matiz es el que hace el mayor trabajo en esta tesis. El argumento de eficiencia no proviene de que exista cierta tecnología. Depende de que la estructura legal realmente permita que el registro onchain lleve ese peso, en lugar de seguir siendo solo otra copia del verdadero.

"Un token que representa un activo y un activo que existe como token son dos promesas diferentes, incluso cuando ambos se venden como tokenización".

Lo que yo realmente querría ver antes de llamarlo real: una seguridad regulada en la que el registro autorizado viva en la cadena, y no una capa de liquidación que funcione junto a un registro que aún tenga la última palabra.

#dusk $DUSK @Dusk

Me encontré mirando el explorador de testnet de DuskEVM, y el número que destaca, 845,113 transacciones contra 282 direcciones de cartera, es casi el equivocado en el que enfocarse. Aproximadamente son 3,000 transacciones por dirección; una proporción que dice menos sobre adopción de lo que sugiere el titular.

Las dos transacciones más recientes mostraron Valor 0 DUSK: se pagaron comisiones, pero no se movió ningún valor nativo. El feed más reciente estaba etiquetado como un depósito L1→L2. No es una prueba de cómo se ven las otras 845K, pero sí es suficiente para que deje de leer esto como si fuera un solo número. Lo que el explorador está mostrando primero, en realidad, es actividad de red: la cadena procesando transacciones. Si alguna de esa actividad es económica, si de verdad cambia de manos un valor por algún motivo, es una cuestión distinta que el conteo de transacciones no puede responder por sí solo.

Esa distinción importa porque Dusk, en última instancia, está posicionando esta infraestructura para activos financieros regulados, que es exactamente lo que el plan de Dusk para llevar €300M de activos NPEX onchain necesitaría demostrar en el futuro. Una cadena ocupada y una cadena que lleve un volumen real de liquidación pueden producir una página de estadísticas con una apariencia idéntica.

"La actividad de red no es la misma afirmación que la actividad financiera, incluso cuando ambas se muestran como un solo número en un explorador".

Lo que yo vigilaría como señal de que esto pasa de ser actividad de red a uso financiero: cuánto de eso representa un valor económico real liquidado, una vez que NPEX nos dé algo real contra lo que compararlo.

#dusk $DUSK @Dusk

Dusk's propia descripción de Hedger pone la generación de pruebas en el lado del cliente por debajo de 2 segundos. Léanlo dos veces antes de que cayera. Es lo suficientemente rápido como para que "confidential tiene que ser más lento" dejara de sentirse como una suposición segura. Me puse a investigar qué se está probando realmente tan rápido. La red de pruebas pública de DuskEVM está activa desde diciembre, y hace unos días la Dusk Foundation la abrió para pruebas con Solidity y Hardhat: esa fue la actualización sobre la que, en realidad, estaba leyendo. La frase que me frenó: la elegibilidad se verifica antes del acceso o la transferencia. Al principio pensé que esa era la parte de cumplimiento interesante. Lo dejé abierto en una pestaña mientras me tomaba un café, volví, lo releí y me di cuenta de que no era así. Dusk dice que los datos de los participantes, los saldos y los importes de las transferencias pueden permanecer cifrados. Esa es la parte que realmente me atrapó: la brecha entre demostrar que tienes permiso y exponer lo que llevas una vez que ya lo tienes. El paso de elegibilidad encaja en la documentación: está claramente definido, no es solo una afirmación vaga de cumplimiento. Aun así, no pude encontrar un ejemplo concreto de lo que ve un revisor autorizado cuando se usa esa ruta de auditoría. Revíselos dos veces. A los pocos días de abrirse esto de Solidity/Hardhat, me dio curiosidad si ese ejemplo aparece conforme todo madura, o si "auditable" simplemente se queda como la palabra que nadie tiene que demostrar todavía: aquí o en cualquier cadena que haga la misma afirmación.

#dusk $DUSK @Dusk

Subí la gráfica de BABY esta noche solo para ver cuántos días faltaban antes del desbloqueo, y el conteo regresivo no fue lo que destacó.

10 de agosto. Faltan cinco días. 136.11M de tokens, cerca de 1.43M de dólares, el 1.2% del suministro, yendo mayormente al equipo, asesores e inversores de rondas tempranas: los mismos números que cualquiera que esté siguiendo esto ya sabe.

Lo que no había mirado en realidad eran los siete días anteriores.

BABY está bajando alrededor de un 10.3% esta semana. El precio está cerca de $0.0105, con una capitalización de mercado de unos $45M, quedando por debajo del mercado cripto en general, que básicamente está plano durante el mismo tramo.

Mi primera lectura fue: bien, tiene que ser una venta relacionada con el desbloqueo que empieza temprano.

Puede que no sea eso. Podrían ser condiciones más amplias del mercado que no tienen nada que ver con el 10 de agosto. No tengo una forma de separar a "gente que se adelanta al desbloqueo" de "BABY simplemente está teniendo una mala semana junto con todo lo demás".

De cualquier modo, los tokens que caen en esas billeteras el 10 de agosto llegan a un precio que ya está 10% más abajo que donde estaba hace una semana.

Quien vendió esta semana vendió en esa caída. Quien reciba el desbloqueo vende en lo que quede después de eso.

Son lados distintos de los mismos cinco días, absorbiendo mitades diferentes del movimiento.

No sé si ese patrón se cumple esta vez. Nada de lo que leí desglosa cuánto de los desbloqueos pasados de Babylon estaba ya descontado antes versus cuánto se reflejó después.

Si el precio ya se movió antes de que ocurriera el desbloqueo, ¿qué revela todavía el propio día del desbloqueo?

@BabylonLabs_io #baby $BABY