Muzamil Abbas⁷⁵ 穆扎米尔_阿巴斯

#dusk $DUSK @Dusk
Estaba leyendo el enfoque de Dusk para la tokenización de valores de seguridad y un detalle no dejaba de llamar mi atención. La mayoría de las transferencias en blockchain parecen instantáneas desde fuera. Los activos se mueven, los saldos cambian y la transacción se considera finalizada. Pero los activos regulados no siempre funcionan así.

En el modelo Zedger de Dusk, una transferencia no se completa automáticamente en el momento en que se envía. El receptor debe aceptarla explícitamente primero. Hasta que eso ocurra, el importe transferido aún debe contabilizarse correctamente. Suena como una elección de diseño pequeña, pero resuelve un problema sorprendentemente difícil.

Empecé a pensar en situaciones en las que una parte de una transacción está lista antes que la otra. Quizá el remitente ya haya iniciado la transferencia, pero el receptor todavía no la haya aprobado. Los sistemas cripto tradicionales suelen centrarse en mover el valor lo más rápido posible. Dusk parece estar más centrado en rastrear la responsabilidad durante el periodo entre la iniciación y la liquidación.

Lo que me parece interesante es que este estado intermedio se trata como parte del proceso en lugar de como una excepción. El sistema lleva el control de la propiedad y los saldos mientras espera el paso final de aprobación.

Para los valores tokenizados y los activos regulados, eso se parece mucho más a cómo funcionan realmente los flujos de trabajo financieros. La pregunta es si más sistemas blockchain eventualmente necesitarán una lógica de liquidación similar a medida que crezca la tokenización.

#dusk $DUSK @Dusk
yi think la privacidad se vuelve mucho más útil cuando puedes entender claramente lo que realmente se está ocultando.

Esa es una de las razones por las que el diseño de Dusk destaca para mí. En Phoenix, el whitepaper separa las salidas en tipos transparentes y ofuscados. Así, la privacidad no se trata como un simple interruptor donde todo desaparece. Algunas informaciones pueden permanecer visibles, mientras que otros detalles se protegen.

Zedger lleva esta idea más allá con la tokenización de seguridad. Los cambios en el saldo de la cuenta pueden mantenerse en memoria privada, mientras que se revela públicamente una raíz de Sparse Merkle Segment Trie. Eso le da al sistema algo verificable sin exponer la información subyacente de la cuenta.

Para mí, esa distinción es importante. Un sistema de privacidad no solo se trata de ocultar datos. También necesita un límite claro entre lo que la red puede verificar públicamente y lo que se mantiene privado para el usuario relevante.

Ahí es donde el enfoque de Dusk resulta interesante. La privacidad y la transparencia no son necesariamente opuestas. La pregunta real es si el protocolo puede hacer que ambas funcionen juntas sin exponer información que no necesita ser pública.

#dusk $DUSK @Dusk
Estaba pensando en cómo la mayoría de las conversaciones sobre cripto todavía tratan la privacidad como algo que pertenece a una cadena específica. Si quieres privacidad, mueves los activos allí. Si necesitas cumplimiento u otra funcionalidad, te mueves a otro lugar. Esa separación siempre me ha parecido un poco limitante.

Lo que me llamó la atención con DUSK es la idea de que la privacidad puede convertirse en parte del flujo de trabajo en lugar del destino. La red se diseñó para transacciones confidenciales, pruebas de conocimiento cero y estructuras que pueden admitir activos regulados sin exponer cada detalle públicamente. En vez de obligar a los usuarios a elegir entre transparencia y privacidad, el objetivo parece ser hacer que ambas existan dentro del mismo entorno, dependiendo de lo que requiera la situación.

Eso me parece más práctico que el debate habitual entre cadena privada versus cadena pública. La actividad financiera real rara vez es unidimensional. Los distintos participantes necesitan diferentes niveles de visibilidad, y un sistema que pueda adaptarse a eso puede ser más útil que uno construido alrededor de una sola regla para todos.

La pregunta es si el mercado valorará con el tiempo la privacidad como infraestructura, en lugar de como una función específica de nicho asociada a una blockchain en particular.

#dusk $DUSK @Dusk
He estado pensando más en el enfoque de Dusk para poner datos de mercado en la cadena de bloques y hay algo que no me deja tranquilo

Poner un precio en una blockchain es un problema
Decidir qué precio merece estar allí es otro

Para un activo líquido varios mercados activos pueden darte una referencia razonable porque hay suficiente actividad de negociación como para comparar

Pero una seguridad con poca liquidez es diferente

Una operación pequeña puede mover el precio cotizado mientras que el último precio negociado podría no representar por lo que alguien realmente podría vender el activo

Si ese número pasa a formar parte de un flujo de trabajo en cadena, la fuente de datos de repente importa casi tanto como la infraestructura que lo transporta

Eso me hace mirar el papel de Dusk de forma distinta

La pregunta interesante para mí no es simplemente si los datos de precios pueden llevarse onchain

Es cómo el sistema maneja el desacuerdo entre fuentes precios antiguos baja liquidez o operaciones inusuales

Tiene que haber alguna manera de evaluar la calidad de los datos en lugar de simplemente registrar lo que llegue primero

Me gustaría ver cómo funciona esto en la práctica en activos regulados con menor liquidez, especialmente cuando diferentes fuentes producen valoraciones ligeramente distintas

Porque en ese punto la pregunta real se vuelve sencilla

¿Quién tiene la última palabra sobre cuál es el precio que realmente es “real”?

#dusk $DUSK @Dusk
He estado pensando en el diseño post-contratación de Dusk de una manera un poco diferente después de leer el material sobre el ciclo de vida. Antes pensaba que la conformidad programable se trataba sobre todo de asegurarse de que una operación esté permitida antes de que ocurra. Pero la pregunta más difícil parece comenzar después de la operación, cuando la titularidad, los derechos de voto, la elegibilidad para dividendos y el estado de cumplimiento tienen que mantenerse correctos.

Eso hace que la idea de que el cumplimiento se vuelva programable sea bastante útil, pero también ligeramente incómoda. El código puede hacer cumplir una regla de forma consistente. No puede saber automáticamente qué hacer cuando la situación del mundo real detrás de esa regla cambia o no encaja con las suposiciones en las que se construyó. Si la elegibilidad de un titular cambia, o si alguna condición regulatoria requiere una excepción, tiene que haber un mecanismo para gestionar ese estado en lugar de simplemente confiar en la lógica original.

Ahí es donde creo que Dusk resulta más interesante que solo tokenizar un activo. El propio token es casi la capa más sencilla. El problema más difícil es mantener el registro preciso a medida que siguen ocurriendo operaciones. Pero aún me queda la duda sobre la capa de anulación. ¿Quién es realmente confiable para intervenir cuando las reglas codificadas producen el resultado incorrecto, y cómo evitas que esa autoridad se convierta en el punto más débil en un sistema por lo demás programable?

#TermMax
Últimamente he estado pensando en la estructura de madurez de TermMax de una manera un poco diferente. Al principio, sobre todo veía los plazos fijos como una forma de hacer que los costos de endeudamiento sean más fáciles de entender. Pero luego empecé a preguntarme qué pasa cuando el sentimiento del mercado cambia rápidamente y de repente todo el mundo quiere plazos más cortos.

Eso parece una prueba de estrés más útil que simplemente preguntar si los mercados de plazo fijo funcionan en condiciones normales. Si los prestatarios se sienten incómodos al mantener el capital bloqueado por más tiempo, la demanda podría desplazarse hacia plazos más cortos al mismo tiempo. Los prestamistas también podrían reaccionar, especialmente si empiezan a esperar mejores tasas en otros lugares. Entonces la curva de precios tiene que ajustarse, y ahí es donde estoy más curioso por TermMax.

El diseño de órdenes por rangos hace que esto sea interesante porque no necesariamente se ofrece liquidez en una única madurez o tasa. Un market maker puede expresar condiciones diferentes a lo largo de un rango, pero eso no significa automáticamente que la liquidez se mantenga atractiva cuando las preferencias cambian de forma abrupta. Aún depende de qué tan rápido los participantes actualizan sus órdenes y de cuánta profundidad existe alrededor de las madureces que, de repente, empieza a preferir la gente.

Esa es la parte que quiero observar. No solo si TermMax tiene liquidez, sino cómo se comporta esa liquidez cuando los usuarios, en conjunto, cambian su preferencia temporal. ¿El mercado reprecifica de manera fluida, o las madureces más cortas se abarrotan mientras las más largas quedan atrás?
#termmax @TermMax

#TermMax
Últimamente he estado mirando las órdenes de rango de TermMax de otra manera. Al principio, las traté como otra forma de que los creadores de mercado colocaran liquidez y ganaran a partir del préstamo. Pero cuanto más pienso en la curva de precios, más parece una manera de expresar una visión sobre la tasa.

Un creador de mercado no tiene que ofrecer liquidez en un único punto. Con una orden de rango, puede definir cómo cambian los términos a lo largo de un rango, lo que significa que su liquidez puede reflejar en qué lugares se siente cómodo participando. Si creo que la demanda de préstamo se mantendrá fuerte solo hasta una cierta tasa, puedo ajustar mi curva alrededor de esa suposición en lugar de aceptar cualquier tasa que aparezca.

La orden de rango bidireccional (Two-Way Range Order) lo hace aún más interesante porque las curvas de préstamo y de préstamo (lending) pueden quedar dentro de la misma orden. Eso hace que la provisión de liquidez se sienta más cercana a posicionarse alrededor de las tasas, en lugar de simplemente depositar capital y esperar.

Aun así, me interesa la calidad de la ejecución. Una curva en papel significa poco si la actividad del mercado se mantiene fuera de ella, o si las condiciones cambiantes vuelven esa visión de la tasa obsoleta. Quisiera ver qué tan rápido se llenan estos rangos, con qué frecuencia los creadores los ajustan y si la flexibilidad se traduce en una mayor eficiencia del capital con el tiempo.
#termmax @TermMax

Esta semana estuve leyendo algunos informes antiguos sobre exploits en puentes y acabé pensando en algo que se siente un poco incómodo. Cuando un puente se hackea, normalmente se habla del contrato inteligente, del conjunto de validadores o de la cantidad que fue robada. Pero después de ver suficientes casos, parece que el puente suele estar exponiendo algo más grande que un fallo en el propio puente.

Un puente se sitúa entre sistemas que no se confían naturalmente entre sí. Por eso, normalmente depende de algún grupo de validadores, firmantes multisig de relayers o operadores para verificar lo que ocurrió en otra cadena. En el papel eso puede parecer lo bastante descentralizado. En la práctica, sin embargo, una cantidad sorprendente de confianza todavía puede terminar concentrada en unas pocas personas o en procesos operativos.

Esa es la parte a la que sigo volviendo. Un hack de un puente no solo muestra dónde falló el código. A veces muestra dónde los humanos pasan a formar parte del modelo de seguridad, incluso si los usuarios asumían que todo se estaba haciendo cumplir mediante la cadena en sí. La blockchain puede ser descentralizada, pero el camino que la conecta con otra red puede introducir suposiciones muy diferentes.

No digo que todos los diseños de puentes tengan las mismas debilidades. Algunos claramente están mejorando. Aun así, cada vez que evalúo un sistema entre cadenas ahora, paso menos tiempo preguntando cómo se mueven los activos y más tiempo preguntando quién, en última instancia, recibe la confianza cuando algo sale mal. ¿Estamos mejorando a la hora de reducir esa dependencia, o más bien la estamos ocultando detrás de una infraestructura más compleja?
#dusk $DUSK @Dusk

#TermMax
He estado mirando cómo TermMax maneja las posiciones a tipo fijo, y la estructura FT, XT y GT probablemente es la parte que ahora entiendo de manera diferente. Al principio pensé que dividir una posición a tipo fijo en tokens separados era, en gran medida, una forma más limpia de representar la misma deuda. Después de profundizar un poco más en la mecánica, estoy empezando a ver por qué la separación importa.

FT representa el lado del principal mientras que XT aísla el componente de intereses, y GT está vinculado más de cerca al lado del vencimiento de la posición. Lo que me resulta útil aquí es que una única posición de deuda a tipo fijo ya no tiene que comportarse como un activo indivisible. Diferentes partes de la exposición económica potencialmente se pueden gestionar por separado dependiendo de lo que realmente quiera mantener o negociar un usuario.

Pero hay un intercambio que no dejo de considerar. Más modularidad puede crear más maneras de gestionar la exposición, pero también puede dificultar la comprensión de la fijación de precios y la liquidez, especialmente si cada token desarrolla su propia profundidad de mercado. Me gustaría ver qué tan consistentemente se negocian estos componentes y si la separación realmente mejora la eficiencia de capital en el uso real, en lugar de solo verse bien a nivel de protocolo.

Sigo observando esa parte de cerca. ¿Romper la deuda a tipo fijo en piezas más pequeñas crea mercados genuinamente mejores, o simplemente estamos moviendo la complejidad a otro lugar?
#termmax @TermMax

He estado pensando en DuskEVM desde un ángulo un poco diferente últimamente: no solo en cuánto cuesta una transacción, sino en qué tan predecible es ese costo cuando estás construyendo algo regulado.

Lo interesante es que la tarifa no es realmente un solo número simple. Depende de dos capas de precios: por un lado los costos de ejecución y, por el otro, los costos de disponibilidad de datos. Esa segunda capa es donde la previsión puede volverse menos sencilla.

Imagina una aplicación financiera que procesa miles de transacciones similares. Si la ejecución se mantiene relativamente estable, pero el componente de disponibilidad de datos cambia según las condiciones de la red, la tarifa promedio que esperabas al inicio del mes puede no ser la que realmente pagues. Para un usuario normal una pequeña diferencia quizá apenas importe. Para un producto regulado con presupuestos fijos, requisitos de reporte y modelos de costos estrictos, la incertidumbre repetida puede convertirse en un problema operativo.

Por eso creo que la previsibilidad de las tarifas merece más atención en las conversaciones sobre DuskEVM. La pregunta no es simplemente si las transacciones son baratas. Es si una aplicación puede estimar de forma confiable sus costos de transacción antes de escalar la actividad.

Para las finanzas reguladas, la previsibilidad puede ser casi tan importante como la tarifa absoluta en sí. Ese es un interesante desafío de diseño para Dusk
#dusk $DUSK @Dusk

#termmax @TermMax
Seguí mirando la Orden de Rango Bidireccional de TermMax y al principio pensé que era solo otra forma de colocar órdenes flexibles de préstamo o de toma de préstamo. Después de profundizar en cómo se comportan esas dos curvas, ya no estoy tan convencido de que sea así de simple.

La posición puede llevar al mismo tiempo una curva de toma de préstamo y una curva de préstamo. Eso suena como una pequeña decisión de diseño, pero cambia la forma en que pienso sobre la liquidez. En lugar de decidir de antemano que mi capital pertenece solo a un lado, en la práctica estoy estableciendo condiciones para ambas direcciones. Si un lado se completa, la posición asume ese rol, mientras que el otro lado puede permanecer disponible con sus propias reglas de precios.

La parte que todavía intento entender es el spread. Un mayor espacio entre las curvas de toma de préstamo y de préstamo parece atractivo en el papel, pero no significa automáticamente mejores rendimientos. La probabilidad de ejecución en función de la utilización, las condiciones del colateral y qué tan rápido se mueve el mercado entre esos rangos deberían importar mucho.

Eso hace que la pregunta real sea menos sobre si esas dos curvas son ingeniosas y más sobre qué tan eficientemente se aprovechan en mercados reales. Yo querría observar la distribución de ejecuciones a lo largo del tiempo antes de decidir cuánto de una ventaja crea realmente.
#TermMax

Sigo notando que la mayoría de las conversaciones sobre las asociaciones de DUSK se centran en NPEX, pero creo que la historia más grande puede ser el patrón que se está formando a su alrededor. Cuando aparecen nombres como Cordial Systems, 21X y NPEX en la misma conversación del ecosistema, empieza a parecerse menos a una sola relación empresarial y más a una prueba de si un mismo modelo de infraestructura puede servir para múltiples mercados regulados.

Lo que me interesa es que cada participante opera en una parte diferente del panorama de los valores digitales, pero todos se enfrentan a desafíos similares. Los registros de propiedad deben mantenerse precisos después de cada operación. Los derechos de voto, la elegibilidad para dividendos y el estado de cumplimiento deben actualizarse continuamente a medida que los activos cambian de manos. Como DUSK suele destacar, la emisión de tokens es solo el principio. El verdadero reto es mantener registros correctos a lo largo de todo el ciclo de vida del activo.

Por eso estoy prestando atención a la creciente red de socios en lugar de a cualquier anuncio único. Si varios participantes de mercados regulados están explorando la misma infraestructura, ¿podría ser una señal de que la industria está convergiendo hacia un modelo post trade compartido?
#dusk $DUSK @Dusk

#dusk $DUSK @Dusk
Sigo volviendo a una pregunta sencilla: cuando la gente dice que una transacción es privada, ¿qué exactamente están protegiendo? La mayoría de los debates se centran en la transacción en sí, pero creo que algunos de los riesgos de privacidad más interesantes aparecen en los márgenes.

Imagina a dos usuarios realizando transferencias confidenciales a través de Dusk. Los montos, las identidades y los detalles de la transacción pueden permanecer ocultos, pero los patrones de tiempo, la frecuencia de actividad de la cartera o los momentos en que el dinero entra y sale de un entorno confidencial aún pueden revelar señales útiles. No es suficiente para exponerlo todo, pero a veces basta para reducir las posibilidades. La privacidad a menudo se trata como una sola característica, mientras que en la práctica se siente más como una cadena en la que incluso la criptografía más sólida puede depender de vínculos conductuales más débiles.

Por eso DUSK me resulta interesante. El desafío no es solo mantener los datos confidenciales durante una transacción. También consiste en reducir la información que se filtra antes y después de que esa transacción ocurra. Un sistema puede proteger con éxito el contenido, mientras los usuarios, sin darse cuenta, exponen el contexto a través de sus propios hábitos.

Cuanto más lo pienso, más la privacidad empieza a parecerse menos a una casilla técnica y más a un problema continuo de coordinación entre el diseño del protocolo y el comportamiento humano. Si la infraestructura confidencial sigue mejorando, ¿el próximo gran desafío de privacidad vendrá de la red en sí o de los patrones que dejan los usuarios?

He notado algo interesante en la campaña actual de Binance Square. Mucha gente se centra solo en las recompensas, pero la clasificación está influenciada en gran medida por el volumen de trading elegible generado por los espectadores.

Por eso estoy observando de cerca $DUSK . El proyecto está construyendo infraestructura centrada en la privacidad para las finanzas reguladas, mientras que las recompensas de la campaña reflejan la actividad real del mercado en lugar de un simple compromiso. El volumen elegible de Spot y Futures cuenta, haciendo que participar esté más conectado con el comportamiento de trading real.

Estaré en vivo hoy para hablar sobre $DUSK y la actividad del mercado en torno a la campaña. Si te interesa seguir la acción, únete al livestream y participa en la conversación sobre oportunidades de trading futuras y el crecimiento del ecosistema.

#dusk $DUSK @Dusk
Empecé a preguntarme por algo que rara vez se menciona cuando la gente habla de la privacidad en cadena: ¿cuántas otras transacciones hay realmente alrededor de las tuyas?

Parece un detalle pequeño, pero la privacidad no ocurre en aislamiento. Si una transacción privada está dentro de una multitud muy reducida, puede haber menos posibilidades para ocultar su relación con la actividad que la rodea. A medida que la multitud crece, también crece el número de posibles candidatos. Esa es la intuición básica detrás de un conjunto de anonimato.

Imagina 10 personas saliendo de la misma sala. Si solo una de ellas lleva un paquete determinado, adivinar se vuelve fácil. Si pones 1000 personas en la sala, la misma observación se vuelve mucho menos útil. La tecnología no ha cambiado mágicamente, pero la incertidumbre sí.

Por eso, la actividad de red es una parte interesante del debate sobre la privacidad en torno a Dusk. Phoenix está diseñado para mantener confidenciales los detalles de las transacciones, pero el resultado de privacidad más amplio aún puede depender de cuántos usuarios y transacciones estén participando en el sistema.

Así que no juzgaría la privacidad solo preguntando si un protocolo oculta datos. También preguntaría cuánta actividad real rodea esos datos ocultos.

Si la adopción crece, ¿la multitud en expansión se convierte en un recurso de privacidad por sí misma para los usuarios de Dusk?

#dusk $DUSK @Dusk
Me sorprendí a mí mismo pensando en una transferencia sencilla el otro día. En la mayoría de las redes, la transacción o bien tiene saldo suficiente y una firma válida, o falla. La decisión es, en gran parte, técnica. Pero, ¿qué sucede cuando la propia red también necesita decidir, antes que nada, si la transacción está permitida?

Esa pregunta es lo que me llevó a profundizar más en Dusk. Si la lógica de cumplimiento pasa a formar parte de la capa de transacciones, una transferencia deja de ser solo mover valor de una dirección a otra. Empieza a comprobar condiciones antes de que ocurra la liquidación. ¿Quién está recibiendo el activo? ¿Son elegibles? ¿La transferencia aún cumple los requisitos asociados a ese activo?

Lo que me resulta interesante es que esto cambia dónde vive la complejidad. En lugar de que el cumplimiento sea gestionado después por las instituciones, parte de esa responsabilidad se acerca a la propia red. Suena eficiente, pero también crea un desafío distinto. Las reglas cambian. Las jurisdicciones cambian. Los activos que parecen idénticos en la superficie pueden llevar restricciones diferentes por debajo.

Imagina que una entidad emisora actualiza un requisito que afecta a transferencias futuras sin cambiar el activo en sí. La transacción todavía se ve sencilla para el usuario, pero la lógica detrás de ella se vuelve mucho más complicada.

Eso me hace preguntarme si la prueba más grande para la infraestructura de blockchain regulada es la velocidad de las transacciones o la capacidad de mantener estas reglas invisibles bajo control a medida que siguen evolucionando.

#dusk $DUSK @Dusk
Solía asumir que las acciones tokenizadas se convertirían en algo común en cuanto alguien resolviera el lado de la emisión. Últimamente no estoy tan seguro.

Crear un token que represente una participación es un paso. Llevar el control de todo lo que ocurre después es el verdadero desafío. Cada operación puede afectar a quién se le permite votar, quién califica para un dividendo, quién aparece en los registros de accionistas y si la titularidad aún cumple con los requisitos regulatorios.

Piensa en una acción que cambia de manos cientos de veces en unos pocos meses. La transacción en sí puede tardar segundos, pero todos los derechos asociados a ese activo deben moverse correctamente en cada ocasión. Si incluso una parte de ese proceso se vuelve poco fiable, el token sigue existiendo, pero el sistema que lo rodea empieza a perder credibilidad.

Por eso me resulta más interesante el lado posterior a la operación que la tokenización en sí. Un mercado no es solo compradores y vendedores que intercambian activos. Es una colección de registros, permisos, obligaciones e historiales de propiedad que deben mantenerse precisos mientras los participantes entran y salen.

Lo que llamó mi atención de Dusk es su enfoque en esa capa menos visible. Muchos proyectos hablan de poner activos en la cadena. Son menos los que se centran en preservar todo lo que le da sentido a esos activos después de que la operación se completa.

Si las acciones tokenizadas escalan a nivel global, ¿qué problema resultará más difícil: crear el activo o mantener todo su ciclo de vida?