Binance Square
Hasnain Ali007
5.4k Publicaciones

Hasnain Ali007

Abrir operación
Trader ocasional
9 meses
356 Siguiendo
11.1K+ Seguidores
3.5K+ Me gusta
Publicaciones
Cartera
·
--
Alcista
Kite puede ayudar a los agentes a pagar. Pero ¿quién decide si el trabajo se hizo? Una respuesta rápida no siempre significa que alguien haya hecho bien el trabajo. Supongamos que dejo que un agente pague por datos de mercado en tiempo real. Recibe una respuesta casi al instante, pero los datos tienen una hora de antigüedad. El proveedor puede decir que entregó los datos. Mi agente puede decir que los recibió. Pero faltaba lo único que necesitaba: los precios actuales. Esta es la parte de Kite que me interesa. Su sistema de pago propuesto puede vincular condiciones a un servicio, en lugar de tratar cada pago completado como prueba de que todo salió bien. Pero siempre vuelvo a un detalle. ¿Quién decide esas condiciones? Si pago por precios en tiempo real, querría una marca de tiempo y un límite claro sobre la antigüedad que pueden tener los datos. Una respuesta rápida con datos desactualizados no debería contar como un servicio satisfactorio. Y aunque me reembolsen, ¿qué pasa si mi agente ya tomó una decisión usando esa información? Recuperar el dinero no lo soluciona todo. Para mí, el mayor desafío no es conseguir que los agentes paguen por los servicios. Es asegurarse de que realmente reciban aquello por lo que pagaron. ¿Le pagarías a un proveedor que respondió a tiempo, pero envió información desactualizada? @GoKiteAI $KITE #KiteBBW
Kite puede ayudar a los agentes a pagar. Pero ¿quién decide si el trabajo se hizo?

Una respuesta rápida no siempre significa que alguien haya hecho bien el trabajo.

Supongamos que dejo que un agente pague por datos de mercado en tiempo real. Recibe una respuesta casi al instante, pero los datos tienen una hora de antigüedad. El proveedor puede decir que entregó los datos. Mi agente puede decir que los recibió. Pero faltaba lo único que necesitaba: los precios actuales.

Esta es la parte de Kite que me interesa. Su sistema de pago propuesto puede vincular condiciones a un servicio, en lugar de tratar cada pago completado como prueba de que todo salió bien.

Pero siempre vuelvo a un detalle. ¿Quién decide esas condiciones?

Si pago por precios en tiempo real, querría una marca de tiempo y un límite claro sobre la antigüedad que pueden tener los datos. Una respuesta rápida con datos desactualizados no debería contar como un servicio satisfactorio.

Y aunque me reembolsen, ¿qué pasa si mi agente ya tomó una decisión usando esa información?

Recuperar el dinero no lo soluciona todo.

Para mí, el mayor desafío no es conseguir que los agentes paguen por los servicios. Es asegurarse de que realmente reciban aquello por lo que pagaron.

¿Le pagarías a un proveedor que respondió a tiempo, pero envió información desactualizada?

@KITE AI $KITE #KiteBBW
‎🔥 ¡Las criptomonedas que más suben se están moviendo rápido hoy! ‎ ‎$AGT ha subido casi un 95 %, mientras que $Q ha subido un 58 %. $EPIC, $ICNT, $AVA, $GTC, $SAND y otras también están mostrando fuertes subidas. ‎ ‎Estoy siguiendo estas monedas para ver cuál logra mantener el impulso. 🚀 ‎$AVA {future}(AVAUSDT) $EPIC {future}(EPICUSDT) ‎¿Qué moneda crees que todavía tiene más potencial de subida?
‎🔥 ¡Las criptomonedas que más suben se están moviendo rápido hoy!
‎
‎$AGT ha subido casi un 95 %, mientras que $Q ha subido un 58 %. $EPIC , $ICNT, $AVA , $GTC, $SAND y otras también están mostrando fuertes subidas.
‎
‎Estoy siguiendo estas monedas para ver cuál logra mantener el impulso. 🚀
‎$AVA
$EPIC

‎¿Qué moneda crees que todavía tiene más potencial de subida?
‎$AGT 🚀
28%
$Q ⚡
60%
‎‎$EPIC 🔥
7%
$ICNT 👀
5%
213 Votos • Votación cerrada
Acabo de revisar estos tres gráficos y ¡la presión compradora está por las nubes hoy! $AGT +139.43% | $0.0400 AGT pegó un salto enorme, de alrededor de $0.016 a $0.0425. Los compradores lo impulsaron con fuerza, pero esa mecha superior me hace pensar que podría haber un retroceso primero. $ICNT +31.54% | $0.1493 ICNT por fin rompió su larga tendencia bajista. Estoy buscando una posición larga si los compradores siguen defendiendo esta ruptura. La próxima resistencia está en $0.1554. $TIA +28.85% | $0.6878 TIA me parece más fuerte. Mínimos más altos, compras constantes y ahora está poniendo a prueba los $0.7147. Me inclino por una posición larga, sobre todo si supera ese máximo. De estas tres, TIA tiene mi gráfico favorito ahora mismo. $TIA {future}(TIAUSDT) $DUSK {future}(DUSKUSDT) ¿Cuál de estas monedas tendrá la mayor subida?
Acabo de revisar estos tres gráficos y ¡la presión compradora está por las nubes hoy!

$AGT +139.43% | $0.0400

AGT pegó un salto enorme, de alrededor de $0.016 a $0.0425. Los compradores lo impulsaron con fuerza, pero esa mecha superior me hace pensar que podría haber un retroceso primero.

$ICNT +31.54% | $0.1493

ICNT por fin rompió su larga tendencia bajista. Estoy buscando una posición larga si los compradores siguen defendiendo esta ruptura. La próxima resistencia está en $0.1554.

$TIA +28.85% | $0.6878

TIA me parece más fuerte. Mínimos más altos, compras constantes y ahora está poniendo a prueba los $0.7147. Me inclino por una posición larga, sobre todo si supera ese máximo.

De estas tres, TIA tiene mi gráfico favorito ahora mismo.
$TIA
$DUSK

¿Cuál de estas monedas tendrá la mayor subida?
- $AGT — Another big rally
17%
- $ICNT — Breakout continues
17%
- $TIA — New highs coming
66%
6 Votos • Votación cerrada
·
--
Bajista
Intentaba entender por qué Dusk tiene dos maneras diferentes de enviar valor y la respuesta no era tan simple como esperaba. Moonlight es público y está basado en cuentas. Phoenix está protegido y utiliza pruebas de conocimiento cero. Al principio suena como si Phoenix fuera básicamente solo la versión privada de Moonlight. No es tan sencillo. Con Moonlight puedes ver el remitente, el receptor, el monto y el nonce en la cadena. Phoenix funciona con notas protegidas. La transacción demuestra que el gasto es válido sin exponer los mismos detalles públicamente. También usa nullifiers para que una nota no pueda gastarse dos veces simplemente. Así que aunque a ambos se les llame transacciones, están haciendo trabajos distintos. Hay otro detalle que me pareció interesante. Dusk recomienda Moonlight para integraciones de intercambio porque las cuentas públicas son mucho más fáciles de escanear y conciliar. Phoenix necesita una configuración diferente de custodia y escaneo porque la información útil de la transacción no está allí públicamente de la misma manera. Eso no significa que Phoenix sea peor. Si el objetivo completo es la confidencialidad, entonces ocultar la información es la característica. Pero crea un problema operativo diferente. La privacidad necesita cómputo. Dusk incluso tiene infraestructura de prover dedicada para generar las pruebas de conocimiento cero usadas por Phoenix. La documentación actual del prover indica un mínimo de 4 núcleos de CPU y 8 GB de RAM, y señala que la generación de pruebas es de un solo hilo. Eso me hizo dejar de mirar solo el recuento de transacciones. Una transacción de Phoenix y una de Moonlight suman una al conteo, pero no representan el mismo tipo de trabajo. Así que lo que yo vigilaría no es simplemente si Dusk obtiene más transacciones. Vigilaría cuánta actividad privada puede manejar la red antes de que la carga de trabajo adicional de generación de pruebas empiece a convertirse en el factor limitante. Ahí es donde la diferencia entre Moonlight y Phoenix se vuelve mucho más interesante. @Dusk_Foundation #dusk $DUSK {future}(DUSKUSDT) $BMT {future}(BMTUSDT) $TMX {alpha}(560x3c2f61f2e27c865981d2e7aaf6b2cdf823030039)
Intentaba entender por qué Dusk tiene dos maneras diferentes de enviar valor y la respuesta no era tan simple como esperaba.

Moonlight es público y está basado en cuentas.

Phoenix está protegido y utiliza pruebas de conocimiento cero.

Al principio suena como si Phoenix fuera básicamente solo la versión privada de Moonlight.

No es tan sencillo.

Con Moonlight puedes ver el remitente, el receptor, el monto y el nonce en la cadena.

Phoenix funciona con notas protegidas. La transacción demuestra que el gasto es válido sin exponer los mismos detalles públicamente. También usa nullifiers para que una nota no pueda gastarse dos veces simplemente.

Así que aunque a ambos se les llame transacciones, están haciendo trabajos distintos.

Hay otro detalle que me pareció interesante.

Dusk recomienda Moonlight para integraciones de intercambio porque las cuentas públicas son mucho más fáciles de escanear y conciliar. Phoenix necesita una configuración diferente de custodia y escaneo porque la información útil de la transacción no está allí públicamente de la misma manera.

Eso no significa que Phoenix sea peor.

Si el objetivo completo es la confidencialidad, entonces ocultar la información es la característica.

Pero crea un problema operativo diferente.

La privacidad necesita cómputo.

Dusk incluso tiene infraestructura de prover dedicada para generar las pruebas de conocimiento cero usadas por Phoenix. La documentación actual del prover indica un mínimo de 4 núcleos de CPU y 8 GB de RAM, y señala que la generación de pruebas es de un solo hilo.

Eso me hizo dejar de mirar solo el recuento de transacciones.

Una transacción de Phoenix y una de Moonlight suman una al conteo, pero no representan el mismo tipo de trabajo.

Así que lo que yo vigilaría no es simplemente si Dusk obtiene más transacciones.

Vigilaría cuánta actividad privada puede manejar la red antes de que la carga de trabajo adicional de generación de pruebas empiece a convertirse en el factor limitante.

Ahí es donde la diferencia entre Moonlight y Phoenix se vuelve mucho más interesante.

@Dusk
#dusk
$DUSK
$BMT
$TMX
·
--
Alcista
Con verificación
#dusk @Dusk_Foundation Empecé a mirar la privacidad de Dusk como una pregunta simple: “¿Cuánta información de transacciones está oculta?” Resultó ser la métrica equivocada. Dusk tiene cuentas públicas de Moonlight y transferencias de Phoenix protegidas. Con Phoenix, el remitente, el destinatario y el monto no se exponen públicamente. Pero eso no significa que la transacción se convierta en un agujero negro de información. Lo más interesante es la visibilidad controlada. Un tercero puede usar acceso de visualización o divulgación selectiva cuando realmente se necesita evidencia. Citadel lleva la misma idea más lejos al permitir que alguien demuestre que posee un credencial válido sin poner los datos personales subyacentes en la cadena. Así que la métrica real no es “qué tan privada es la cadena”. Es: “¿Cuánta información debe revelarse para probar algo?” Esa distinción importa porque las finanzas reguladas normalmente no pueden funcionar con ninguno de los extremos. La transparencia total puede filtrar saldos y contrapartes. La opacidad total puede dificultar auditorías de elegibilidad y cumplimiento. La divulgación selectiva se sitúa entre esos dos extremos. Un punto incómodo es que añadir privacidad no hace automáticamente que un sistema sea mejor. La prueba real llega cuando varias partes necesitan diferentes partes de los mismos datos de transacción. Lo que estoy observando es si Dusk puede mantener esa divulgación mínima a medida que los flujos de trabajo reales del mercado escalan. $DUSK {future}(DUSKUSDT) $SOL {future}(SOLUSDT) $BTC {future}(BTCUSDT) Porque la pregunta interesante ya no es si los datos pueden ocultarse. Es si el sistema puede probar lo que necesita probar sin revelar todo lo demás. ¿Qué es lo más importante para la financiación centrada en la privacidad?
#dusk @Dusk
Empecé a mirar la privacidad de Dusk como una pregunta simple:

“¿Cuánta información de transacciones está oculta?”

Resultó ser la métrica equivocada.

Dusk tiene cuentas públicas de Moonlight y transferencias de Phoenix protegidas. Con Phoenix, el remitente, el destinatario y el monto no se exponen públicamente. Pero eso no significa que la transacción se convierta en un agujero negro de información.

Lo más interesante es la visibilidad controlada.

Un tercero puede usar acceso de visualización o divulgación selectiva cuando realmente se necesita evidencia. Citadel lleva la misma idea más lejos al permitir que alguien demuestre que posee un credencial válido sin poner los datos personales subyacentes en la cadena.

Así que la métrica real no es “qué tan privada es la cadena”.

Es:

“¿Cuánta información debe revelarse para probar algo?”

Esa distinción importa porque las finanzas reguladas normalmente no pueden funcionar con ninguno de los extremos.

La transparencia total puede filtrar saldos y contrapartes.

La opacidad total puede dificultar auditorías de elegibilidad y cumplimiento.

La divulgación selectiva se sitúa entre esos dos extremos.

Un punto incómodo es que añadir privacidad no hace automáticamente que un sistema sea mejor. La prueba real llega cuando varias partes necesitan diferentes partes de los mismos datos de transacción.

Lo que estoy observando es si Dusk puede mantener esa divulgación mínima a medida que los flujos de trabajo reales del mercado escalan.
$DUSK
$SOL
$BTC

Porque la pregunta interesante ya no es si los datos pueden ocultarse.

Es si el sistema puede probar lo que necesita probar sin revelar todo lo demás.

¿Qué es lo más importante para la financiación centrada en la privacidad?
Maximum privacy
75%
Selective disclosure
25%
Compliance
0%
Scalability
0%
4 Votos • Votación cerrada
·
--
Alcista
Con verificación
#dusk @Dusk_Foundation La noche pasada estaba leyendo los documentos de la asociación NPEX de Dusk y me sorprendí asumiendo que tokenizar un valor básicamente significaba acuñar un token transferible y ya está. Luego miré lo que en realidad prometieron automatizar, y el alcance es más amplio que una simple función de transferencia. Un pago de dividendos, un cupón en un bono, una división de acciones, una cancelación forzada de acciones: no son transferencias sencillas; son eventos iniciados por el emisor que tienen que llegar a cada titular a la vez, sin posibilidad de excluirse. Las propias cifras de Dusk sobre esto merecen que uno se detenga: automatizar la distribución de dividendos puede reducir los costos asociados hasta en un 90 por ciento en comparación con el procesamiento basado en papel, y la carga documental para las PYMES al tokenizar capital baja entre un 20 y un 30 por ciento. Eso suena como una victoria, pero el número que me hizo pausar era diferente. Una reducción del 90 por ciento en costos solo importa si la lógica se ejecuta correctamente para el 100 por ciento de los titulares, porque un dividendo que falla incluso en un solo monedero no es un descuento: es un fallo de cumplimiento. Los mercados tradicionales absorben ese riesgo mediante conciliación por lotes, donde los errores se detectan y corrigen antes de que se finalice la liquidación. En cadena, el modelo de contrato XSC de Dusk hace cumplir estos eventos criptográficamente a nivel de protocolo, lo que elimina el riesgo de conciliación, pero también elimina la red de seguridad que esa conciliación proporcionaba. Lo que estoy observando ahora no es si Dusk puede procesar un dividendo más barato, sino si un emisor puede enmendar o revertir una acción corporativa una vez que ya se ejecutó en cadena, ya que las finanzas tradicionales corrigen los errores con personas y las blockchains los corrigen con inmutabilidad. ¿Eliminar la red de seguridad junto con la carga de trabajo realmente cuenta como progreso, o es solo un tipo de riesgo diferente que se desplaza más hacia el downstream? @Dusk_Foundation #dusk $DUSK {future}(DUSKUSDT) $SPK {future}(SPKUSDT) $BTC {future}(BTCUSDT)
#dusk @Dusk
La noche pasada estaba leyendo los documentos de la asociación NPEX de Dusk y me sorprendí asumiendo que tokenizar un valor básicamente significaba acuñar un token transferible y ya está. Luego miré lo que en realidad prometieron automatizar, y el alcance es más amplio que una simple función de transferencia. Un pago de dividendos, un cupón en un bono, una división de acciones, una cancelación forzada de acciones: no son transferencias sencillas; son eventos iniciados por el emisor que tienen que llegar a cada titular a la vez, sin posibilidad de excluirse. Las propias cifras de Dusk sobre esto merecen que uno se detenga: automatizar la distribución de dividendos puede reducir los costos asociados hasta en un 90 por ciento en comparación con el procesamiento basado en papel, y la carga documental para las PYMES al tokenizar capital baja entre un 20 y un 30 por ciento. Eso suena como una victoria, pero el número que me hizo pausar era diferente. Una reducción del 90 por ciento en costos solo importa si la lógica se ejecuta correctamente para el 100 por ciento de los titulares, porque un dividendo que falla incluso en un solo monedero no es un descuento: es un fallo de cumplimiento. Los mercados tradicionales absorben ese riesgo mediante conciliación por lotes, donde los errores se detectan y corrigen antes de que se finalice la liquidación. En cadena, el modelo de contrato XSC de Dusk hace cumplir estos eventos criptográficamente a nivel de protocolo, lo que elimina el riesgo de conciliación, pero también elimina la red de seguridad que esa conciliación proporcionaba. Lo que estoy observando ahora no es si Dusk puede procesar un dividendo más barato, sino si un emisor puede enmendar o revertir una acción corporativa una vez que ya se ejecutó en cadena, ya que las finanzas tradicionales corrigen los errores con personas y las blockchains los corrigen con inmutabilidad. ¿Eliminar la red de seguridad junto con la carga de trabajo realmente cuenta como progreso, o es solo un tipo de riesgo diferente que se desplaza más hacia el downstream?
@Dusk
#dusk
$DUSK

$SPK
$BTC
·
--
Bajista
#dusk @Dusk_Foundation Me desperté hoy y, sinceramente, el mercado se sentía medio dormido, medio despierto. Ese estado raro entre ambos en el que nada se mueve pero tampoco está muerto. Así que, en vez de desplazarme doom-scrolling por gráficas, acabé de vuelta en los documentos de Citadel 2; no me preguntes por qué, pero me apeteció leer algo técnico. Estaba intentando encontrar el punto exacto en el que Citadel decide realmente si un usuario obtiene acceso. Seguí desplazándome, esperando dar con ello. No lo encontré. Resulta que nunca fue trabajo de Citadel. El usuario demuestra que tiene una licencia válida sin revelar quién es; el contrato de licencia en Dusk lo verifica, se añade un nullifier y se emite una cookie de sesión. Lee como si el acceso estuviera concedido, ¿verdad? Pero el último paso del flujo es el que nadie menciona. El Proveedor de Servicio obtiene esa sesión, revisa la cookie localmente y luego hace su propia llamada sobre si realmente va a conceder el servicio. Citadel solo confirma que la credencial es real y que no se ha reutilizado ya. No dice nada sobre si esa credencial, incluso, es suficiente para lo que el SP quiere. Pequeña distinción, pero cambia qué es lo que realmente está resolviendo todo esto. Una sesión válida te dice que la prueba se generó correctamente por alguien que tiene una licencia genuina, sin doble gasto. No te dice si ese conjunto de atributos coincide con lo que este SP en particular requiere hoy. Una es un problema de matemáticas: Dusk lo resuelve una vez y listo. La otra es una decisión de negocio: cada SP la toma por su cuenta, y puede cambiar mañana sin tocar el sistema de pruebas en absoluto. Lo que estoy vigilando no es qué tan rápido se generan las pruebas en Dusk. Es si los SPs realmente construyen una lógica de políticas real encima de Citadel, o si la verificación se convierte calladamente en otra puerta de “pasa/no pasa” con pasos extra. Si un sistema puede demostrar que algo es verdad pero no puede decidir qué significa esa verdad, parece que el verdadero cuello de botella nunca fue la prueba. Siempre fue la parte que hacía la pregunta. $DUSK {future}(DUSKUSDT) $TUT {future}(TUTUSDT) $PORTAL {future}(PORTALUSDT) ¿Adónde debería ir el modelo de acceso de Citadel 2 a continuación?
#dusk @Dusk
Me desperté hoy y, sinceramente, el mercado se sentía medio dormido, medio despierto. Ese estado raro entre ambos en el que nada se mueve pero tampoco está muerto. Así que, en vez de desplazarme doom-scrolling por gráficas, acabé de vuelta en los documentos de Citadel 2; no me preguntes por qué, pero me apeteció leer algo técnico.

Estaba intentando encontrar el punto exacto en el que Citadel decide realmente si un usuario obtiene acceso. Seguí desplazándome, esperando dar con ello. No lo encontré. Resulta que nunca fue trabajo de Citadel.

El usuario demuestra que tiene una licencia válida sin revelar quién es; el contrato de licencia en Dusk lo verifica, se añade un nullifier y se emite una cookie de sesión. Lee como si el acceso estuviera concedido, ¿verdad? Pero el último paso del flujo es el que nadie menciona. El Proveedor de Servicio obtiene esa sesión, revisa la cookie localmente y luego hace su propia llamada sobre si realmente va a conceder el servicio. Citadel solo confirma que la credencial es real y que no se ha reutilizado ya. No dice nada sobre si esa credencial, incluso, es suficiente para lo que el SP quiere.

Pequeña distinción, pero cambia qué es lo que realmente está resolviendo todo esto. Una sesión válida te dice que la prueba se generó correctamente por alguien que tiene una licencia genuina, sin doble gasto. No te dice si ese conjunto de atributos coincide con lo que este SP en particular requiere hoy. Una es un problema de matemáticas: Dusk lo resuelve una vez y listo. La otra es una decisión de negocio: cada SP la toma por su cuenta, y puede cambiar mañana sin tocar el sistema de pruebas en absoluto.

Lo que estoy vigilando no es qué tan rápido se generan las pruebas en Dusk. Es si los SPs realmente construyen una lógica de políticas real encima de Citadel, o si la verificación se convierte calladamente en otra puerta de “pasa/no pasa” con pasos extra.

Si un sistema puede demostrar que algo es verdad pero no puede decidir qué significa esa verdad, parece que el verdadero cuello de botella nunca fue la prueba. Siempre fue la parte que hacía la pregunta.

$DUSK

$TUT

$PORTAL


¿Adónde debería ir el modelo de acceso de Citadel 2 a continuación?
Custom SP policies
67%
Standard attribute templates
33%
3 Votos • Votación cerrada
·
--
Alcista
Con verificación
Empecé a revisar el "~10s deterministic settlement" de Dusk y al principio sonaba como una simple métrica de velocidad. Pero en mercados regulados, la parte más importante no son los 10 segundos. Lo que importa es lo que ocurre después de esos segundos. DuskDS usa Succinct Attestation, donde un bloque pasa por propuesta → validación → ratificación antes de convertirse en definitivo. Una vez que se finaliza, ya no existe una reorg normal para seguir esperando. Eso cambia la forma en que piensas en el settlement (liquidación/confirmación). Si un activo y su tramo de pago están diseñados para liquidarse juntos, un estado final predecible importa más que simplemente decir "las transacciones son rápidas". Pero hay un detalle importante que no ignoraría. @Dusk_Foundation tiene DuskVM y DuskEVM como rutas de ejecución separadas. DuskVM liquida directamente a través de DuskDS, mientras que DuskEVM tiene su propio secuenciador y modelo de finalidad. Así que "Dusk tiene finalidad determinista" no es suficiente información por sí sola. La pregunta real es: ¿Qué parte del flujo de trabajo realmente depende de la finalidad de DuskDS? Citar 10 segundos es fácil. La métrica más difícil es qué tan consistentemente todo el flujo de trabajo llega a un único estado final en condiciones reales de mercado. Eso es lo que estoy observando con $DUSK y #dusk . $DUSK {future}(DUSKUSDT) @Dusk_Foundation #dusk ¿Qué es más importante para los mercados regulados?
Empecé a revisar el "~10s deterministic settlement" de Dusk y al principio sonaba como una simple métrica de velocidad.

Pero en mercados regulados, la parte más importante no son los 10 segundos.

Lo que importa es lo que ocurre después de esos segundos.

DuskDS usa Succinct Attestation, donde un bloque pasa por propuesta → validación → ratificación antes de convertirse en definitivo. Una vez que se finaliza, ya no existe una reorg normal para seguir esperando.

Eso cambia la forma en que piensas en el settlement (liquidación/confirmación).

Si un activo y su tramo de pago están diseñados para liquidarse juntos, un estado final predecible importa más que simplemente decir "las transacciones son rápidas".

Pero hay un detalle importante que no ignoraría.

@Dusk tiene DuskVM y DuskEVM como rutas de ejecución separadas. DuskVM liquida directamente a través de DuskDS, mientras que DuskEVM tiene su propio secuenciador y modelo de finalidad.

Así que "Dusk tiene finalidad determinista" no es suficiente información por sí sola.

La pregunta real es:

¿Qué parte del flujo de trabajo realmente depende de la finalidad de DuskDS?

Citar 10 segundos es fácil.

La métrica más difícil es qué tan consistentemente todo el flujo de trabajo llega a un único estado final en condiciones reales de mercado.

Eso es lo que estoy observando con $DUSK y #dusk .

$DUSK
@Dusk
#dusk
¿Qué es más importante para los mercados regulados?
Fast settlement
100%
Predictable finality
0%
Both equally
0%
Depends on the asset
0%
4 Votos • Votación cerrada
Parcialmente cierto
#termmax @termmax He estado mirando los números en vivo de @termmax en lugar de solo leer la divulgación de riesgo. El TVL está en $31.22M, bajando un 7.2% en 30 días desde un pico cercano a $49-55M con el valor prestado contabilizado. Respiración normal para préstamos con tasa fija, no lo interesante. Lo que me detuvo fue la página de configuración del oráculo. #TermMax ejecuta Chainlink y RedStone como fuentes primarias, configuración estándar. Pero los valores de latido (heartbeat) para MC_PTs, ETH+, xUSD y varios tokens PT muestran todos 86400. Son 24 horas entre actualizaciones garantizadas a menos que se dispare primero un umbral de desviación. Pueden ocurrir muchas cosas en un día para una posición apalancada que nunca llega a tocar la fijación de precios de la fuente que lo alimenta. Las fuentes de respaldo cuentan una segunda historia. USDS tiene Chainlink como primario y Chronicle como respaldo. MC_PTs no tiene ninguna listada. Un solo feed, sin alternativa, para un activo usado activamente como colateral. La fórmula de liquidación lo vuelve concreto. El colateral liquidado se calcula como la cantidad de deuda por el precio de la deuda por la penalización, dividido entre el precio del colateral. El precio del colateral está en el denominador. Si ese precio entra demasiado bajo, obsoleto o con fallos, el denominador se reduce y la cantidad liquidada crece. La fórmula se ejecuta correctamente. La entrada estaba mal. Tampoco es hipotético. En marzo, un error de configuración en el oráculo de Aave mal valoró wstETH y disparó $26.4M en liquidaciones en 34 cuentas en 15 minutos, con bots capturando cerca de 499 ETH. Protocolo diferente, misma mecánica: el motor de liquidación confió en el precio que se le dio. El mecanismo de entrega física de TermMax ayuda después, distribuyendo colateral proporcional en lugar de dejar deuda incobrable. Eso protege al protocolo. No deshace una liquidación disparada por un número erróneo. Lo que estoy vigilando no es el heartbeat en sí —todo oráculo tiene uno—. Es si los umbrales de desviación realmente fuerzan actualizaciones más rápidas en mercados volátiles, y cuántos corren con una sola fuente sin respaldo. El TVL muestra lo que apareció. No dice nada sobre qué mercados están a un precio “en pausa” de una liquidación que no debería haber ocurrido.
#termmax @TermMax
He estado mirando los números en vivo de @TermMax en lugar de solo leer la divulgación de riesgo. El TVL está en $31.22M, bajando un 7.2% en 30 días desde un pico cercano a $49-55M con el valor prestado contabilizado. Respiración normal para préstamos con tasa fija, no lo interesante. Lo que me detuvo fue la página de configuración del oráculo.

#TermMax ejecuta Chainlink y RedStone como fuentes primarias, configuración estándar. Pero los valores de latido (heartbeat) para MC_PTs, ETH+, xUSD y varios tokens PT muestran todos 86400. Son 24 horas entre actualizaciones garantizadas a menos que se dispare primero un umbral de desviación. Pueden ocurrir muchas cosas en un día para una posición apalancada que nunca llega a tocar la fijación de precios de la fuente que lo alimenta.

Las fuentes de respaldo cuentan una segunda historia. USDS tiene Chainlink como primario y Chronicle como respaldo. MC_PTs no tiene ninguna listada. Un solo feed, sin alternativa, para un activo usado activamente como colateral.

La fórmula de liquidación lo vuelve concreto. El colateral liquidado se calcula como la cantidad de deuda por el precio de la deuda por la penalización, dividido entre el precio del colateral. El precio del colateral está en el denominador. Si ese precio entra demasiado bajo, obsoleto o con fallos, el denominador se reduce y la cantidad liquidada crece. La fórmula se ejecuta correctamente. La entrada estaba mal.

Tampoco es hipotético. En marzo, un error de configuración en el oráculo de Aave mal valoró wstETH y disparó $26.4M en liquidaciones en 34 cuentas en 15 minutos, con bots capturando cerca de 499 ETH. Protocolo diferente, misma mecánica: el motor de liquidación confió en el precio que se le dio.

El mecanismo de entrega física de TermMax ayuda después, distribuyendo colateral proporcional en lugar de dejar deuda incobrable. Eso protege al protocolo. No deshace una liquidación disparada por un número erróneo.

Lo que estoy vigilando no es el heartbeat en sí —todo oráculo tiene uno—. Es si los umbrales de desviación realmente fuerzan actualizaciones más rápidas en mercados volátiles, y cuántos corren con una sola fuente sin respaldo.

El TVL muestra lo que apareció. No dice nada sobre qué mercados están a un precio “en pausa” de una liquidación que no debería haber ocurrido.
·
--
Alcista
#dusk @Dusk_Foundation Comencé a revisar la configuración pública y protegida (shielded) de la cuenta de Dusk y mi primera lectura fue sencilla: los usuarios obtienen una elección. Moonlight para la transparencia y Phoenix para la privacidad. Cambia según lo que exija el cumplimiento o la comodidad. Flexibilidad como propuesta. Pero los dos tipos de cuenta no comparten el mismo modelo de seguridad, y esa es la parte que merece profundizarse. Una transacción de Moonlight se basa en la cuenta y se comprueba con una firma BLS estándar. Las transacciones de Phoenix incluyen una prueba de conocimiento cero que tiene que superar una verificación antes de entrar en el mempool. Una prueba debe establecer que la transacción protegida (shielded) es válida. Si ese sistema de pruebas tiene una vulnerabilidad, el lado protegido hereda ese riesgo. Esto no es meramente teórico. En abril de 2022, Dusk divulgó una vulnerabilidad crítica en su implementación de PLONK que podría permitir pruebas falsificadas. Ese problema se corrigió y, desde entonces, Dusk ha seguido actualizando su infraestructura de pruebas. El modelo basado en firmas de Moonlight no quedó expuesto a esta categoría específica de riesgo de implementación de PLONK. Eso no significa que Phoenix esté roto. Los sistemas de ZK vienen con supuestos criptográficos distintos y esos supuestos requieren una revisión continua a medida que más valor se mueve a través de ellos. Lo que realmente importaría es si el proceso de seguridad se mantiene al ritmo de la cantidad de actividad real que utiliza el lado protegido. Lo que estoy vigilando es cómo evoluciona el uso de Phoenix en relación con Moonlight con el paso del tiempo. $DUSK {future}(DUSKUSDT) $BTC {future}(BTCUSDT) $SOL {future}(SOLUSDT) Si comienza a moverse más valor real a través de Phoenix, ¿su ventaja de privacidad llega a valer la dependencia criptográfica adicional?
#dusk @Dusk
Comencé a revisar la configuración pública y protegida (shielded) de la cuenta de Dusk y mi primera lectura fue sencilla: los usuarios obtienen una elección. Moonlight para la transparencia y Phoenix para la privacidad. Cambia según lo que exija el cumplimiento o la comodidad. Flexibilidad como propuesta.

Pero los dos tipos de cuenta no comparten el mismo modelo de seguridad, y esa es la parte que merece profundizarse. Una transacción de Moonlight se basa en la cuenta y se comprueba con una firma BLS estándar. Las transacciones de Phoenix incluyen una prueba de conocimiento cero que tiene que superar una verificación antes de entrar en el mempool. Una prueba debe establecer que la transacción protegida (shielded) es válida. Si ese sistema de pruebas tiene una vulnerabilidad, el lado protegido hereda ese riesgo.

Esto no es meramente teórico. En abril de 2022, Dusk divulgó una vulnerabilidad crítica en su implementación de PLONK que podría permitir pruebas falsificadas. Ese problema se corrigió y, desde entonces, Dusk ha seguido actualizando su infraestructura de pruebas. El modelo basado en firmas de Moonlight no quedó expuesto a esta categoría específica de riesgo de implementación de PLONK.

Eso no significa que Phoenix esté roto. Los sistemas de ZK vienen con supuestos criptográficos distintos y esos supuestos requieren una revisión continua a medida que más valor se mueve a través de ellos. Lo que realmente importaría es si el proceso de seguridad se mantiene al ritmo de la cantidad de actividad real que utiliza el lado protegido.

Lo que estoy vigilando es cómo evoluciona el uso de Phoenix en relación con Moonlight con el paso del tiempo.
$DUSK

$BTC

$SOL


Si comienza a moverse más valor real a través de Phoenix, ¿su ventaja de privacidad llega a valer la dependencia criptográfica adicional?
Moonlight stays dominant
50%
Phoenix grows faster
50%
Stays roughly balanced
0%
2 Votos • Votación cerrada
Con verificación
#termmax @termmax Creo que la forma en que @termmax gestiona las actualizaciones es bastante interesante. La lógica principal del protocolo se mantiene inmutable. Pero aún se pueden actualizar dos contratos importantes: AccessManager y TermMaxRouter. Eso tiene sentido para mí porque no todo necesita el mismo nivel de flexibilidad. Si la lógica central pudiera cambiarse con facilidad, entonces los usuarios tendrían que depositar más confianza en las futuras actualizaciones. Pero si nada pudiera cambiarse nunca, solucionar problemas importantes podría volverse difícil. TermMax mantiene el núcleo fijo mientras permite actualizar estos dos contratos cuando sea necesario. Es una idea simple, pero una importante para un protocolo DeFi. #TermMax ¿Qué prefieres?
#termmax
@TermMax
Creo que la forma en que @TermMax gestiona las actualizaciones es bastante interesante.
La lógica principal del protocolo se mantiene inmutable. Pero aún se pueden actualizar dos contratos importantes: AccessManager y TermMaxRouter.
Eso tiene sentido para mí porque no todo necesita el mismo nivel de flexibilidad.
Si la lógica central pudiera cambiarse con facilidad, entonces los usuarios tendrían que depositar más confianza en las futuras actualizaciones. Pero si nada pudiera cambiarse nunca, solucionar problemas importantes podría volverse difícil.
TermMax mantiene el núcleo fijo mientras permite actualizar estos dos contratos cuando sea necesario.
Es una idea simple, pero una importante para un protocolo DeFi.
#TermMax
¿Qué prefieres?
Immutable core
0%
More upgrades
0%
Both
0%
Not sure
0%
0 Votos • Votación cerrada
Con verificación
#dusk @Dusk_Foundation Ayer, solía pensar que un sistema de identidad basado en blockchain principalmente necesitaba demostrar que alguien era elegible para acceder a algo. Yo miraba la identidad sobre todo a través de ese lente, así que me convencía bastante fácilmente con la idea de poner credenciales en la cadena. Pero cuando profundicé en Citadel 2, empecé a ver que el problema está en lo que queda expuesto cuando se demuestra una credencial. Citadel 2 se está construyendo no solo para verificar que alguien tiene una licencia válida, sino también para mantener la licencia y sus atributos subyacentes privados. Ese detalle me hizo darme cuenta de que demostrar algo y revelar la información detrás de esa demostración son en realidad dos cosas muy diferentes. Lo que vale la pena pensar es que Citadel 2 quiere que este proceso ocurra mediante pruebas de conocimiento cero, junto con licencias firmadas por LP y verificación de sesión en la cadena. Una vez pensé que si una blockchain puede verificar públicamente una afirmación de identidad, entonces eso debería ser suficiente. Pero para servicios reales, poner atributos personales o incluso la credencial exacta utilizada en la cadena a veces no es la opción más práctica. Un servicio puede necesitar saber que el usuario es válido, mientras que el usuario quizá no quiera revelar todo sobre sí mismo. A partir de ahí, empecé a ver Citadel 2 menos como un sistema típico de “identidad en la cadena”. La ambición real parece ser demostrar que un usuario tiene una credencial válida sin exponer la credencial en sí, mientras todavía se deja la decisión final de acceso al proveedor del servicio. Todavía no sé si este modelo de privacidad será lo suficientemente simple para que los servicios reales lo adopten a escala. Quizá eso sea lo siguiente que vale la pena vigilar. $DUSK {future}(DUSKUSDT) $BTC {future}(BTCUSDT) $TRUMP {future}(TRUMPUSDT) ¿Qué es lo más importante para la identidad en la cadena?
#dusk @Dusk

Ayer, solía pensar que un sistema de identidad basado en blockchain principalmente necesitaba demostrar que alguien era elegible para acceder a algo. Yo miraba la identidad sobre todo a través de ese lente, así que me convencía bastante fácilmente con la idea de poner credenciales en la cadena.

Pero cuando profundicé en Citadel 2, empecé a ver que el problema está en lo que queda expuesto cuando se demuestra una credencial. Citadel 2 se está construyendo no solo para verificar que alguien tiene una licencia válida, sino también para mantener la licencia y sus atributos subyacentes privados. Ese detalle me hizo darme cuenta de que demostrar algo y revelar la información detrás de esa demostración son en realidad dos cosas muy diferentes.

Lo que vale la pena pensar es que Citadel 2 quiere que este proceso ocurra mediante pruebas de conocimiento cero, junto con licencias firmadas por LP y verificación de sesión en la cadena. Una vez pensé que si una blockchain puede verificar públicamente una afirmación de identidad, entonces eso debería ser suficiente. Pero para servicios reales, poner atributos personales o incluso la credencial exacta utilizada en la cadena a veces no es la opción más práctica. Un servicio puede necesitar saber que el usuario es válido, mientras que el usuario quizá no quiera revelar todo sobre sí mismo.

A partir de ahí, empecé a ver Citadel 2 menos como un sistema típico de “identidad en la cadena”. La ambición real parece ser demostrar que un usuario tiene una credencial válida sin exponer la credencial en sí, mientras todavía se deja la decisión final de acceso al proveedor del servicio.

Todavía no sé si este modelo de privacidad será lo suficientemente simple para que los servicios reales lo adopten a escala. Quizá eso sea lo siguiente que vale la pena vigilar.
$DUSK
$BTC
$TRUMP

¿Qué es lo más importante para la identidad en la cadena?
Private proof
21%
Transparency
29%
User control
14%
Both
36%
14 Votos • Votación cerrada
#termmax @termmax #TermMax Entré pensando que el tipo de interés era básicamente solo un número que se adjunta al préstamo. Luego empecé a mirar qué pasa cuando el pedido se hace más grande. Lo que me llamó la atención es que TermMax no necesita mantener la misma tasa en todo el pedido. Los prestamistas pueden establecer una curva donde la tasa cambia a medida que se va tomando más de su liquidez. Los prestatarios pueden hacer lo mismo con su APR de préstamo. Así, un pedido pequeño podría obtener una tasa, mientras que un pedido mucho mayor avanza más en la curva y obtiene otra. Eso tiene sentido cuando piensas en la liquidez. Cuanta más de la liquidez disponible consumes, más importante se vuelve la fijación de precios. @termmax utiliza estas curvas basadas en rangos para permitir que quienes colocan órdenes definan cómo cambian las tasas a lo largo de la orden. Lo que yo vigilaría aquí no es solo el APR principal. Es dónde se ubica tu orden en la curva. ¿Preferirías tomar una cantidad más pequeña con una mejor tasa o aumentar el tamaño sabiendo que la tasa puede moverse?
#termmax @TermMax
#TermMax

Entré pensando que el tipo de interés era básicamente solo un número que se adjunta al préstamo. Luego empecé a mirar qué pasa cuando el pedido se hace más grande.

Lo que me llamó la atención es que TermMax no necesita mantener la misma tasa en todo el pedido.

Los prestamistas pueden establecer una curva donde la tasa cambia a medida que se va tomando más de su liquidez. Los prestatarios pueden hacer lo mismo con su APR de préstamo.

Así, un pedido pequeño podría obtener una tasa, mientras que un pedido mucho mayor avanza más en la curva y obtiene otra.

Eso tiene sentido cuando piensas en la liquidez.

Cuanta más de la liquidez disponible consumes, más importante se vuelve la fijación de precios. @TermMax utiliza estas curvas basadas en rangos para permitir que quienes colocan órdenes definan cómo cambian las tasas a lo largo de la orden.

Lo que yo vigilaría aquí no es solo el APR principal.

Es dónde se ubica tu orden en la curva.

¿Preferirías tomar una cantidad más pequeña con una mejor tasa o aumentar el tamaño sabiendo que la tasa puede moverse?
·
--
Alcista
Con verificación
#dusk @Dusk_Foundation Antes pensaba que la tokenización era el principal desafío para los RWA. Cuanto más lo analizo, menos creo que eso sea cierto. Poner un activo en la cadena es una cosa. La parte difícil es todo lo que lo rodea. ¿Quién puede comprarlo? ¿Quién puede poseerlo? ¿Qué debe mantenerse privado? ¿Qué necesita divulgarse? ¿Cómo se liquidan juntos los activos y el pago? La mayoría de los proyectos de RWA empiezan con el activo. Lo que me interesa de Dusk es que empieza con el flujo de trabajo financiero alrededor de ese activo. Citadel gestiona la identidad y la divulgación selectiva. Phoenix puede mantener las transferencias protegidas mientras Moonlight respalda flujos públicos. DuskDS gestiona la liquidación y la finalidad mientras DuskEVM le da a los desarrolladores un entorno EVM. Toma un fondo tokenizado. Es posible que un inversor necesite demostrar que es elegible sin exponer toda su identidad o su historial financiero. El activo puede tener reglas de transferencia mientras el pago y el activo pueden moverse mediante el mismo flujo de trabajo financiero. Luego está Dusk Trade. Se enfoca en lo práctico: incorporar inversores, verificar elegibilidad, negociar, pago, liquidación y divulgaciones requeridas. Eso cambia la forma en que miro a Dusk. La pregunta no es solo: “¿Podemos poner activos reales en la cadena?” Es: “¿Pueden esos activos funcionar realmente en la cadena bajo reglas financieras reales?” Ese es el problema más difícil. Y $Dusk también tiene un papel dentro de la red. Se usa para gas y staking, lo que conecta el token con la actividad real de la red, en lugar de ser solo un ticker pegado al proyecto. El riesgo sigue siendo la adopción. La buena infraestructura no crea automáticamente actividad financiera real. Dusk todavía tiene que demostrar que los desarrolladores, emisores e instituciones realmente quieren usarlo. Esa es la parte que estoy vigilando. $DUSK {future}(DUSKUSDT) $RICE {alpha}(560xb5761f36fdfe2892f1b54bc8ee8babb2a1b698d3) $BTW {future}(BTWUSDT) ¿Qué es lo más importante para la adopción de RWA?
#dusk @Dusk
Antes pensaba que la tokenización era el principal desafío para los RWA.

Cuanto más lo analizo, menos creo que eso sea cierto.

Poner un activo en la cadena es una cosa.

La parte difícil es todo lo que lo rodea.

¿Quién puede comprarlo? ¿Quién puede poseerlo? ¿Qué debe mantenerse privado? ¿Qué necesita divulgarse? ¿Cómo se liquidan juntos los activos y el pago?

La mayoría de los proyectos de RWA empiezan con el activo.

Lo que me interesa de Dusk es que empieza con el flujo de trabajo financiero alrededor de ese activo.

Citadel gestiona la identidad y la divulgación selectiva. Phoenix puede mantener las transferencias protegidas mientras Moonlight respalda flujos públicos. DuskDS gestiona la liquidación y la finalidad mientras DuskEVM le da a los desarrolladores un entorno EVM.

Toma un fondo tokenizado.

Es posible que un inversor necesite demostrar que es elegible sin exponer toda su identidad o su historial financiero. El activo puede tener reglas de transferencia mientras el pago y el activo pueden moverse mediante el mismo flujo de trabajo financiero.

Luego está Dusk Trade.

Se enfoca en lo práctico: incorporar inversores, verificar elegibilidad, negociar, pago, liquidación y divulgaciones requeridas.

Eso cambia la forma en que miro a Dusk.

La pregunta no es solo:

“¿Podemos poner activos reales en la cadena?”

Es:

“¿Pueden esos activos funcionar realmente en la cadena bajo reglas financieras reales?”

Ese es el problema más difícil.

Y $Dusk también tiene un papel dentro de la red. Se usa para gas y staking, lo que conecta el token con la actividad real de la red, en lugar de ser solo un ticker pegado al proyecto.

El riesgo sigue siendo la adopción.

La buena infraestructura no crea automáticamente actividad financiera real. Dusk todavía tiene que demostrar que los desarrolladores, emisores e instituciones realmente quieren usarlo.

Esa es la parte que estoy vigilando.
$DUSK

$RICE

$BTW


¿Qué es lo más importante para la adopción de RWA?
Privacy + compliance
60%
Fast settlement
20%
Easy onboarding
20%
Institutional adoption
0%
5 Votos • Votación cerrada
#termmax @termmax Una cosa en la que sigo pensando sobre DeFi es cuánto puede cambiar el tipo de interés después de que entras en una posición. Puedes empezar con un tipo que parezca atractivo, pero unos movimientos del mercado después los números pueden verse completamente distintos. Por eso, el debate sobre el tipo fijo frente al variable me resulta interesante. Los tipos variables te dan flexibilidad, pero también introducen incertidumbre. Con TermMax la idea es diferente. Los mercados con tipo fijo permiten a los usuarios conocer los términos de préstamo o de depósito durante un período definido, en lugar de estar lidiando constantemente con cambios en los tipos. Creo que ese nivel de previsibilidad podría ser útil para personas que gestionan posiciones más grandes. Aun así, conlleva riesgos. La liquidez y el vencimiento importan, y los tipos fijos no son automáticamente mejores en cualquier mercado. #TermMax @termmax ¿Qué elegirías?
#termmax @TermMax
Una cosa en la que sigo pensando sobre DeFi es cuánto puede cambiar el tipo de interés después de que entras en una posición.

Puedes empezar con un tipo que parezca atractivo, pero unos movimientos del mercado después los números pueden verse completamente distintos.

Por eso, el debate sobre el tipo fijo frente al variable me resulta interesante.

Los tipos variables te dan flexibilidad, pero también introducen incertidumbre.

Con TermMax la idea es diferente. Los mercados con tipo fijo permiten a los usuarios conocer los términos de préstamo o de depósito durante un período definido, en lugar de estar lidiando constantemente con cambios en los tipos.

Creo que ese nivel de previsibilidad podría ser útil para personas que gestionan posiciones más grandes.

Aun así, conlleva riesgos. La liquidez y el vencimiento importan, y los tipos fijos no son automáticamente mejores en cualquier mercado.
#TermMax @TermMax
¿Qué elegirías?
🔘 Fixed
100%
🔘 Floating
0%
🔘 Both
0%
🔘 Depends
0%
1 Votos • Votación cerrada
‎ Pero, en la práctica, ¿dónde encaja realmente Atomic Settlement en Dusk? ‎ ‎Antes pensaba que Entrega contra Pago era bastante simple. El comprador paga, el vendedor entrega el activo y, una vez que ambas partes terminan, la liquidación también se da por hecha. No pensé mucho en lo que podría ocurrir en el medio. ‎ ‎ Luego empecé a mirar con más detenimiento Atomic Settlement y me di cuenta de que la brecha entre el pago y la entrega en realidad puede importar mucho. ‎ ‎ Lo que llamó mi atención es la idea básica de que ambas partes deben liquidar juntas. El pago no debería completarse mientras el activo aún está esperando ser entregado, y el activo no debería moverse mientras el pago siga siendo incierto. ‎ ‎A partir de ahí empecé a ver DvP de forma diferente. En el caso de los valores tokenizados, no se trata solo de poner el activo en la cadena. Hace falta una forma de que la transferencia de pago y de activo alcance el mismo estado final, sin dejar a una de las partes expuesta en el medio. ‎ ‎ Y aquí es donde Dusk se vuelve interesante para mí. Si los activos regulados van a ponerse en la cadena, no se puede analizar la liquidación por separado de la privacidad y el cumplimiento. Es posible que las partes adecuadas necesiten verificar qué ocurrió, sin hacer públicos todos los detalles de cada transacción. ‎ ‎ Aún tengo curiosidad por ver cómo funciona esto en usos reales. La idea tiene sentido para mí, pero la prueba real es qué sucede cuando comienzan a liquidarse juntos activos regulados y pagos reales. ‎ @Dusk_Foundation #dusk $DUSK {future}(DUSKUSDT) $ACE {future}(ACEUSDT) $EDEN {future}(EDENUSDT) ‎ Lo que más importa para el DvP on-chain?
‎ Pero, en la práctica, ¿dónde encaja realmente Atomic Settlement en Dusk?
‎
‎Antes pensaba que Entrega contra Pago era bastante simple. El comprador paga, el vendedor entrega el activo y, una vez que ambas partes terminan, la liquidación también se da por hecha. No pensé mucho en lo que podría ocurrir en el medio.
‎
‎ Luego empecé a mirar con más detenimiento Atomic Settlement y me di cuenta de que la brecha entre el pago y la entrega en realidad puede importar mucho.
‎
‎ Lo que llamó mi atención es la idea básica de que ambas partes deben liquidar juntas. El pago no debería completarse mientras el activo aún está esperando ser entregado, y el activo no debería moverse mientras el pago siga siendo incierto.
‎
‎A partir de ahí empecé a ver DvP de forma diferente. En el caso de los valores tokenizados, no se trata solo de poner el activo en la cadena. Hace falta una forma de que la transferencia de pago y de activo alcance el mismo estado final, sin dejar a una de las partes expuesta en el medio.
‎
‎ Y aquí es donde Dusk se vuelve interesante para mí. Si los activos regulados van a ponerse en la cadena, no se puede analizar la liquidación por separado de la privacidad y el cumplimiento. Es posible que las partes adecuadas necesiten verificar qué ocurrió, sin hacer públicos todos los detalles de cada transacción.
‎
‎ Aún tengo curiosidad por ver cómo funciona esto en usos reales. La idea tiene sentido para mí, pero la prueba real es qué sucede cuando comienzan a liquidarse juntos activos regulados y pagos reales.
‎
@Dusk
#dusk
$DUSK

$ACE

$EDEN


‎ Lo que más importa para el DvP on-chain?
‎ Atomic settlement
60%
Privacy
0%
Compliance
20%
‎ Fast finality
20%
5 Votos • Votación cerrada
Antes pensaba que el apalancamiento en DeFi era básicamente una sola cosa. Pedir fondos prestados, tomar una posición mayor y gestionar el riesgo. Pero al ver TermMax, en realidad hay varias formas de usar el apalancamiento dependiendo de lo que quieras lograr. Si quieres algo sencillo, la compra GT con un solo clic te ofrece una vía directa para obtener exposición apalancada sin tener que pasar por una configuración complicada. Si el dinero se va a invertir en otro activo fuera de TermMax, tiene más sentido pedir prestado a tipo fijo, porque ya sabes cuál será el costo del préstamo. También puedes mantener todo dentro de TermMax combinando el préstamo y la inversión en la misma estrategia. Luego están las garantías que generan rendimiento. En lugar de que tu garantía se quede ahí sin hacer nada, puede seguir generando rendimiento mientras usas al mismo tiempo fondos prestados. Y para alguien que quiere mucho más apalancamiento, el apalancamiento recursivo lo lleva más lejos repitiendo el proceso de pedir prestado. Pero ese también conlleva un riesgo mucho mayor, así que definitivamente no es para todo el mundo. Esa probablemente es la parte a la que sigo volviendo con @termmax . No es solo una forma de obtener apalancamiento. Puedes elegir la configuración según dónde quieras desplegar el capital y cuánto riesgo estás dispuesto a asumir. #TermMax ¿Cuál usarías tú realmente?
Antes pensaba que el apalancamiento en DeFi era básicamente una sola cosa.

Pedir fondos prestados, tomar una posición mayor y gestionar el riesgo.

Pero al ver TermMax, en realidad hay varias formas de usar el apalancamiento dependiendo de lo que quieras lograr.

Si quieres algo sencillo, la compra GT con un solo clic te ofrece una vía directa para obtener exposición apalancada sin tener que pasar por una configuración complicada.

Si el dinero se va a invertir en otro activo fuera de TermMax, tiene más sentido pedir prestado a tipo fijo, porque ya sabes cuál será el costo del préstamo.

También puedes mantener todo dentro de TermMax combinando el préstamo y la inversión en la misma estrategia.

Luego están las garantías que generan rendimiento.

En lugar de que tu garantía se quede ahí sin hacer nada, puede seguir generando rendimiento mientras usas al mismo tiempo fondos prestados.

Y para alguien que quiere mucho más apalancamiento, el apalancamiento recursivo lo lleva más lejos repitiendo el proceso de pedir prestado.

Pero ese también conlleva un riesgo mucho mayor, así que definitivamente no es para todo el mundo.

Esa probablemente es la parte a la que sigo volviendo con @TermMax .

No es solo una forma de obtener apalancamiento. Puedes elegir la configuración según dónde quieras desplegar el capital y cuánto riesgo estás dispuesto a asumir.
#TermMax

¿Cuál usarías tú realmente?
One-Click GT Purchase
67%
Fixed-Rate Borrowing
33%
Yield-Bearing Collateral
0%
Recursive Leveraging
0%
6 Votos • Votación cerrada
·
--
Alcista
Con verificación
Volvía a revisar otra vez el ecosistema de Dusk y noté algo que probablemente habría pasado por alto antes. Es fácil mirar Dusk y enfocarse solo en la cadena en sí, pero las aplicaciones que se construyen a su alrededor cuentan una historia ligeramente diferente. Sozu es un ejemplo. Ofrece a las personas una forma de participar en el staking de Dusk sin tener que ejecutar su propia infraestructura. Eso suena a algo pequeño, pero eliminar esa barrera técnica puede hacer que el staking sea más accesible. Luego está PieSwap, un DEX comunitario construido sobre DuskEVM para intercambios y liquidez. Esta es la parte que encuentro más interesante, porque una vez que un entorno EVM empieza a reunir aplicaciones, la red se convierte en algo más que “solo” lo que se apuesta. Dusk Domains agrega otra capa con nombres .dusk para carteras, contratos y aplicaciones. Pequeñas piezas como esta no parecen enormes por sí solas, pero juntas empiezan a hacer que el ecosistema se sienta más usable. @Dusk_Foundation #dusk $DUSK {future}(DUSKUSDT) $PORTAL {future}(PORTALUSDT) $GPS {future}(GPSUSDT) Aun así, sigo volviendo a una pregunta: ¿qué parte del ecosistema de Dusk crees que tiene más potencial?
Volvía a revisar otra vez el ecosistema de Dusk y noté algo que probablemente habría pasado por alto antes. Es fácil mirar Dusk y enfocarse solo en la cadena en sí, pero las aplicaciones que se construyen a su alrededor cuentan una historia ligeramente diferente.

Sozu es un ejemplo. Ofrece a las personas una forma de participar en el staking de Dusk sin tener que ejecutar su propia infraestructura. Eso suena a algo pequeño, pero eliminar esa barrera técnica puede hacer que el staking sea más accesible.

Luego está PieSwap, un DEX comunitario construido sobre DuskEVM para intercambios y liquidez. Esta es la parte que encuentro más interesante, porque una vez que un entorno EVM empieza a reunir aplicaciones, la red se convierte en algo más que “solo” lo que se apuesta.

Dusk Domains agrega otra capa con nombres .dusk para carteras, contratos y aplicaciones. Pequeñas piezas como esta no parecen enormes por sí solas, pero juntas empiezan a hacer que el ecosistema se sienta más usable.
@Dusk
#dusk
$DUSK

$PORTAL

$GPS


Aun así, sigo volviendo a una pregunta: ¿qué parte del ecosistema de Dusk crees que tiene más potencial?
Sozu
36%
PieSwap
21%
Dusk Domains
4%
All of them
39%
28 Votos • Votación cerrada
·
--
Alcista
‎ POR QUÉ SIGO VOLVIENDO A LAS AUDITORÍAS DE DUSK ‎ ‎ Últimamente he profundizado en @Dusk_Foundation y, sinceramente, la parte de la auditoría captó mi atención más de lo que esperaba ‎ ‎ Cuando la gente habla sobre una blockchain, la conversación suele ir directamente a la velocidad, la privacidad o lo que puedes construir sobre ella ‎ ‎ Pero para la infraestructura financiera, creo que hay otra pregunta que importa tanto como esa ‎ ‎ ¿Realmente pueden confiar en el sistema que está debajo? ‎ ‎ Ahí es donde la seguridad y la fiabilidad empiezan a ser algo más que simples palabras bonitas ‎ ‎ Dusk está trabajando en casos de uso financieros donde un pequeño error puede significar mucho más que una simple transacción fallida. Por eso, que se revisen la red y sus componentes mediante auditorías independientes es importante ‎ ‎ Por supuesto, una auditoría no significa que todo sea automáticamente seguro para siempre. Las cosas cambian: cambia el código y aparecen nuevos riesgos ‎ ‎ Lo que me importa es que la seguridad se trate como una parte continua de construir la red, no como algo que se agrega al final solo para que se vea bien ‎ ‎ Y probablemente por eso me gusta la idea simple detrás de esta imagen ‎ ‎ Seguridad. Fiabilidad. Confianza. ‎ ‎ Para que la finanza en cadena crezca de verdad, creo que esas tres tienen que reunirse #dusk $DUSK {future}(DUSKUSDT) $HEMI {future}(HEMIUSDT) $AIO {future}(AIOUSDT) ‎ ‎ ¿Confiarías en una blockchain financiera sin auditorías independientes adecuadas, no importa qué tan buena suene la tecnología?
‎ POR QUÉ SIGO VOLVIENDO A LAS AUDITORÍAS DE DUSK
‎
‎ Últimamente he profundizado en @Dusk y, sinceramente, la parte de la auditoría captó mi atención más de lo que esperaba
‎
‎ Cuando la gente habla sobre una blockchain, la conversación suele ir directamente a la velocidad, la privacidad o lo que puedes construir sobre ella
‎
‎ Pero para la infraestructura financiera, creo que hay otra pregunta que importa tanto como esa
‎
‎ ¿Realmente pueden confiar en el sistema que está debajo?
‎
‎ Ahí es donde la seguridad y la fiabilidad empiezan a ser algo más que simples palabras bonitas
‎
‎ Dusk está trabajando en casos de uso financieros donde un pequeño error puede significar mucho más que una simple transacción fallida. Por eso, que se revisen la red y sus componentes mediante auditorías independientes es importante
‎
‎ Por supuesto, una auditoría no significa que todo sea automáticamente seguro para siempre. Las cosas cambian: cambia el código y aparecen nuevos riesgos
‎
‎ Lo que me importa es que la seguridad se trate como una parte continua de construir la red, no como algo que se agrega al final solo para que se vea bien
‎
‎ Y probablemente por eso me gusta la idea simple detrás de esta imagen
‎
‎ Seguridad. Fiabilidad. Confianza.
‎
‎ Para que la finanza en cadena crezca de verdad, creo que esas tres tienen que reunirse
#dusk

$DUSK

$HEMI

$AIO


‎
‎ ¿Confiarías en una blockchain financiera sin auditorías independientes adecuadas, no importa qué tan buena suene la tecnología?
Bullish 💚
60%
Bearish ❤️
40%
5 Votos • Votación cerrada
·
--
Alcista
#dusk Mi amigo me estaba hablando sobre la arquitectura de Kadcast en @Dusk_Foundation y yo como que ok, déjame mirarlo yo mismo porque sinceramente al principio no lo entendí del todo. Entonces, Dusk usa Kadcast para enviar bloques, transacciones y votos de consenso. Lo interesante es que no solo envía el mismo mensaje a cada vecino. Usa Kademlia y la distancia XOR para elegir qué pares deberían pasar el mensaje hacia adelante. Luego están estas cosas de los árboles multicast, donde el mensaje se mueve desde pares más cercanos hacia nodos que están más lejos. Así se envían menos mensajes innecesarios por toda la red. También encontré bastante interesante la parte de tolerancia a fallos. Si algunos nodos se desconectan, otros pares todavía pueden ayudar a reenviar el mensaje, y también hay un lado de privacidad, ya que el mensaje pasa por distintos nodos seleccionados, lo que hace más difícil averiguar el origen original. En serio, pensé que Kadcast era solo algún término de redes, pero en realidad hay mucho en juego aquí. Me hace preguntarme cuánto importa este tipo de cosas cuando la red de dusk se vuelve mucho más concurrida. $DUSK {future}(DUSKUSDT) $COW {future}(COWUSDT) $WAL {future}(WALUSDT)
#dusk
Mi amigo me estaba hablando sobre la arquitectura de Kadcast en @Dusk y yo como que ok, déjame mirarlo yo mismo porque sinceramente al principio no lo entendí del todo.
Entonces, Dusk usa Kadcast para enviar bloques, transacciones y votos de consenso. Lo interesante es que no solo envía el mismo mensaje a cada vecino. Usa Kademlia y la distancia XOR para elegir qué pares deberían pasar el mensaje hacia adelante.
Luego están estas cosas de los árboles multicast, donde el mensaje se mueve desde pares más cercanos hacia nodos que están más lejos. Así se envían menos mensajes innecesarios por toda la red.
También encontré bastante interesante la parte de tolerancia a fallos. Si algunos nodos se desconectan, otros pares todavía pueden ayudar a reenviar el mensaje, y también hay un lado de privacidad, ya que el mensaje pasa por distintos nodos seleccionados, lo que hace más difícil averiguar el origen original.
En serio, pensé que Kadcast era solo algún término de redes, pero en realidad hay mucho en juego aquí.
Me hace preguntarme cuánto importa este tipo de cosas cuando la red de dusk se vuelve mucho más concurrida.
$DUSK

$COW

$WAL
Inicia sesión para explorar más contenidos
Únete a usuarios de criptomonedas de todo el mundo en Binance Square
⚡️ Obtén la información más reciente y útil sobre criptomonedas.
💬 Confía en el mayor exchange de criptomonedas del mundo.
👍 Descubre opiniones reales de creadores verificados.
Correo electrónico/número de teléfono
Mapa del sitio
Preferencias de cookies
Términos y condiciones de la plataforma