Crypto460
3.9k Publicaciones
Crypto460
Crypto Trader || Market Analyst || Content Creator || Binance Square Creator || Community Builder || X:- @Soikat0077
Trader frecuente
2.3 año(s)
1.2K+ Siguiendo
4.2K+ Seguidores
8.4K+ Me gusta
Publicaciones
Todo
Citas
#dusk $DUSK @Dusk
Hace quince días, empecé a analizar Dusk función por función.
Esperaba encontrar una blockchain centrada en la privacidad con un conjunto de funciones financieras.
Ahora mi visión es más específica.
Lo interesante es cómo encajan las piezas.
DuskEVM mantiene el camino de desarrollo EVM familiar.
Moonlight y Phoenix gestionan modelos de transacción distintos.
Hedger se centra en la lógica de activos regulados y la privacidad.
Citadel se ocupa de la identidad y el acceso.
DuskDS proporciona liquidación y disponibilidad de datos.
La Attestation Succinct ofrece finalización determinista.
Dusk Trade mueve la infraestructura hacia un flujo de trabajo de mercado real.
Luego están las relaciones institucionales en torno a la custodia, los pagos, las bolsas e información de mercado, todo ello asegurado por validadores que hacen staking $DUSK debajo de la @Dusk del consenso. #dusk
Después de ver todo esto, creo que la pregunta real ya no es si Dusk tiene tecnología interesante.
La pregunta difícil es la ejecución.
¿Los activos regulados realmente se mueven?
¿Las instituciones usan la infraestructura?
¿Los controles de privacidad resisten en flujos de trabajo reales?
¿La liquidación funciona a un volumen significativo?
¿Los desarrolladores encuentran práctico el camino de EVM?
Las respuestas a eso importan más para mí ahora que otro anuncio de funciones.
También creo que aquí es donde ser prudente ayuda.
Una buena arquitectura te da un punto de partida.
Una asociación te da acceso.
Ninguna de las dos demuestra adopción.
La próxima evidencia que quiero ver es un uso real a escala.
Ahí es donde la tesis de Dusk se fortalece o se pone a prueba.
Después de 15 días, esa es la parte que vigilaré con más atención.
Hace quince días, empecé a analizar Dusk función por función.
Esperaba encontrar una blockchain centrada en la privacidad con un conjunto de funciones financieras.
Ahora mi visión es más específica.
Lo interesante es cómo encajan las piezas.
DuskEVM mantiene el camino de desarrollo EVM familiar.
Moonlight y Phoenix gestionan modelos de transacción distintos.
Hedger se centra en la lógica de activos regulados y la privacidad.
Citadel se ocupa de la identidad y el acceso.
DuskDS proporciona liquidación y disponibilidad de datos.
La Attestation Succinct ofrece finalización determinista.
Dusk Trade mueve la infraestructura hacia un flujo de trabajo de mercado real.
Luego están las relaciones institucionales en torno a la custodia, los pagos, las bolsas e información de mercado, todo ello asegurado por validadores que hacen staking $DUSK debajo de la @Dusk del consenso. #dusk
Después de ver todo esto, creo que la pregunta real ya no es si Dusk tiene tecnología interesante.
La pregunta difícil es la ejecución.
¿Los activos regulados realmente se mueven?
¿Las instituciones usan la infraestructura?
¿Los controles de privacidad resisten en flujos de trabajo reales?
¿La liquidación funciona a un volumen significativo?
¿Los desarrolladores encuentran práctico el camino de EVM?
Las respuestas a eso importan más para mí ahora que otro anuncio de funciones.
También creo que aquí es donde ser prudente ayuda.
Una buena arquitectura te da un punto de partida.
Una asociación te da acceso.
Ninguna de las dos demuestra adopción.
La próxima evidencia que quiero ver es un uso real a escala.
Ahí es donde la tesis de Dusk se fortalece o se pone a prueba.
Después de 15 días, esa es la parte que vigilaré con más atención.
#dusk $DUSK @Dusk
Empecé a analizar el diseño del settlement y acabé centrándome en un concepto financiero:
Entrega contra pago.
La idea es sencilla.
Un lado entrega el activo.
El otro lado entrega el pago.
Ambos deben liquidarse al mismo tiempo.
Si el activo se mueve mientras el pago falla, la transacción tiene un problema.
Si el pago se mueve mientras el activo falla, el problema simplemente cambia de lado.
Por eso, poner una seguridad en la cadena (onchain) es solo una parte del problema del settlement.
Importan tanto la pata del activo como la pata del pago.
El Régimen Piloto de la UE para DLT es especialmente relevante, porque proporciona un marco para probar infraestructuras de mercados financieros basadas en DLT bajo condiciones regulatorias.
La finalidad determinista de @Dusk le da a la red un punto de liquidación claro, con $DUSK asegurando a los validadores que llegan hasta allí. #dusk
Pero la finalidad por sí sola no crea DvP.
Todavía es necesario que ambos lados coordinen correctamente.
Esa es la parte que me gustaría ver demostrada en una transacción real regulada.
No un diagrama.
No un concepto.
Una pata real del activo y una pata real del pago completándose juntas bajo las reglas requeridas.
Eso me diría mucho más sobre el diseño de settlement de Dusk que otra comparación de rendimiento.
Empecé a analizar el diseño del settlement y acabé centrándome en un concepto financiero:
Entrega contra pago.
La idea es sencilla.
Un lado entrega el activo.
El otro lado entrega el pago.
Ambos deben liquidarse al mismo tiempo.
Si el activo se mueve mientras el pago falla, la transacción tiene un problema.
Si el pago se mueve mientras el activo falla, el problema simplemente cambia de lado.
Por eso, poner una seguridad en la cadena (onchain) es solo una parte del problema del settlement.
Importan tanto la pata del activo como la pata del pago.
El Régimen Piloto de la UE para DLT es especialmente relevante, porque proporciona un marco para probar infraestructuras de mercados financieros basadas en DLT bajo condiciones regulatorias.
La finalidad determinista de @Dusk le da a la red un punto de liquidación claro, con $DUSK asegurando a los validadores que llegan hasta allí. #dusk
Pero la finalidad por sí sola no crea DvP.
Todavía es necesario que ambos lados coordinen correctamente.
Esa es la parte que me gustaría ver demostrada en una transacción real regulada.
No un diagrama.
No un concepto.
Una pata real del activo y una pata real del pago completándose juntas bajo las reglas requeridas.
Eso me diría mucho más sobre el diseño de settlement de Dusk que otra comparación de rendimiento.
La divulgación selectiva suena sencilla hasta que preguntas:
¿Quién está autorizado a ver la información?
Esa pregunta me llevó a Citadel.
@Dusk describe a Citadel como su identidad y capa de acceso, con soporte para divulgación selectiva. #dusk
La idea es sencilla.
Un participante prueba algo sobre sí mismo sin exponer cada dato personal que hay detrás de la prueba.
En un sistema financiero regulado, esa distinción importa.
Un inversor podría necesitar demostrar su elegibilidad.
Un proveedor de servicios necesita verificar la credencial correspondiente.
Un regulador podría necesitar acceso controlado a información específica.
Toda la red no necesita verlo todo.
Ahí es donde la identidad se vuelve más que una dirección de cuenta.
El sistema necesita una forma de establecer quién es un participante y qué está autorizado a hacer, mientras que la verificación en sí sigue asentándose como una transacción $DUSK por debajo.
Citadel usa pruebas de conocimiento cero como parte de este modelo de identidad.
Lo que aún quiero entender es el flujo de trabajo práctico.
¿Cómo recibe alguien una credencial?
¿Cómo verifica otra parte esa credencial?
¿Cómo cambian los permisos cuando cambia el estado subyacente?
Esos detalles determinan qué tan útil se vuelve la divulgación selectiva en la práctica.
Para mí, Citadel es interesante porque la privacidad solo funciona bien en las finanzas reguladas cuando el acceso es programable.
¿Quién está autorizado a ver la información?
Esa pregunta me llevó a Citadel.
@Dusk describe a Citadel como su identidad y capa de acceso, con soporte para divulgación selectiva. #dusk
La idea es sencilla.
Un participante prueba algo sobre sí mismo sin exponer cada dato personal que hay detrás de la prueba.
En un sistema financiero regulado, esa distinción importa.
Un inversor podría necesitar demostrar su elegibilidad.
Un proveedor de servicios necesita verificar la credencial correspondiente.
Un regulador podría necesitar acceso controlado a información específica.
Toda la red no necesita verlo todo.
Ahí es donde la identidad se vuelve más que una dirección de cuenta.
El sistema necesita una forma de establecer quién es un participante y qué está autorizado a hacer, mientras que la verificación en sí sigue asentándose como una transacción $DUSK por debajo.
Citadel usa pruebas de conocimiento cero como parte de este modelo de identidad.
Lo que aún quiero entender es el flujo de trabajo práctico.
¿Cómo recibe alguien una credencial?
¿Cómo verifica otra parte esa credencial?
¿Cómo cambian los permisos cuando cambia el estado subyacente?
Esos detalles determinan qué tan útil se vuelve la divulgación selectiva en la práctica.
Para mí, Citadel es interesante porque la privacidad solo funciona bien en las finanzas reguladas cuando el acceso es programable.
Comencé a mirar a los socios institucionales como anuncios separados.
Luego noté algo.
Resuelven partes diferentes de la misma estructura de mercado.
Quantoz proporciona EURQ, un activo de pago digital denominado en euros.
Cordial Systems se centra en la custodia institucional.
21X aporta la infraestructura regulada del mercado.
NPEX aporta la parte del intercambio regulado.
Esos roles son diferentes.
Un activo regulado necesita algún lugar donde negociarse.
Los inversores necesitan una forma compatible de acceder a él.
Los activos necesitan custodia.
Los pagos necesitan un activo de liquidación.
La blockchain está debajo de todo esto.
Eso cambió la forma en que veo la estrategia de asociación de @Dusk . #dusk
Una larga lista de socios no significa mucho por sí sola.
La pregunta útil es si cada socio cumple un requisito específico en el flujo de trabajo financiero.
Todavía hay una brecha entre la infraestructura y su uso.
Quiero ver transacciones reales fluir a través de estas relaciones, con $DUSK liquidando las comisiones que haya debajo de todo ello.
Quiero ver cómo se conectan los distintos componentes cuando intervienen activos reales y dinero real.
Para mí, lo interesante es la estructura de la red en torno a Dusk.
La siguiente prueba es si esas piezas separadas operan como un solo mercado funcional.
@Dusk $DUSK #dusk
Luego noté algo.
Resuelven partes diferentes de la misma estructura de mercado.
Quantoz proporciona EURQ, un activo de pago digital denominado en euros.
Cordial Systems se centra en la custodia institucional.
21X aporta la infraestructura regulada del mercado.
NPEX aporta la parte del intercambio regulado.
Esos roles son diferentes.
Un activo regulado necesita algún lugar donde negociarse.
Los inversores necesitan una forma compatible de acceder a él.
Los activos necesitan custodia.
Los pagos necesitan un activo de liquidación.
La blockchain está debajo de todo esto.
Eso cambió la forma en que veo la estrategia de asociación de @Dusk . #dusk
Una larga lista de socios no significa mucho por sí sola.
La pregunta útil es si cada socio cumple un requisito específico en el flujo de trabajo financiero.
Todavía hay una brecha entre la infraestructura y su uso.
Quiero ver transacciones reales fluir a través de estas relaciones, con $DUSK liquidando las comisiones que haya debajo de todo ello.
Quiero ver cómo se conectan los distintos componentes cuando intervienen activos reales y dinero real.
Para mí, lo interesante es la estructura de la red en torno a Dusk.
La siguiente prueba es si esas piezas separadas operan como un solo mercado funcional.
@Dusk $DUSK #dusk
Quería separar el token de la conversación de trading.
¿Qué hace realmente dentro de la red @Dusk ? #dusk
Dos funciones destacaron para mí.
Gas.
Staking.
$DUSK paga las comisiones de transacción y los costos de ejecución de contratos en Dusk.
También sirve como activo de staking para la seguridad de la red.
El número que llamó mi atención fue 210M+ DUSK en staking.
Eso le da a la red una cantidad significativa de valor económico comprometido con el staking.
Pero no juzgaría la seguridad solo con ese número.
La distribución también importa.
210M DUSK repartidos entre muchos participantes independientes presentan un panorama de seguridad diferente al mismo monto concentrado entre un pequeño número de participantes.
Así que creo que hay dos conversaciones separadas alrededor de DUSK.
Una es el mercado.
La otra es la utilidad de la red.
El gas paga la ejecución.
El staking conecta el token con la participación en el consenso.
Esas funciones no dependen de si el precio de mercado sube o baja.
El siguiente número que querría entender no es solo el total de DUSK en staking.
Es cómo ese stake se distribuye por toda la red.
¿Qué importa más al evaluar la seguridad de la red $DUSK ?
¿Qué hace realmente dentro de la red @Dusk ? #dusk
Dos funciones destacaron para mí.
Gas.
Staking.
$DUSK paga las comisiones de transacción y los costos de ejecución de contratos en Dusk.
También sirve como activo de staking para la seguridad de la red.
El número que llamó mi atención fue 210M+ DUSK en staking.
Eso le da a la red una cantidad significativa de valor económico comprometido con el staking.
Pero no juzgaría la seguridad solo con ese número.
La distribución también importa.
210M DUSK repartidos entre muchos participantes independientes presentan un panorama de seguridad diferente al mismo monto concentrado entre un pequeño número de participantes.
Así que creo que hay dos conversaciones separadas alrededor de DUSK.
Una es el mercado.
La otra es la utilidad de la red.
El gas paga la ejecución.
El staking conecta el token con la participación en el consenso.
Esas funciones no dependen de si el precio de mercado sube o baja.
El siguiente número que querría entender no es solo el total de DUSK en staking.
Es cómo ese stake se distribuye por toda la red.
¿Qué importa más al evaluar la seguridad de la red $DUSK ?
Total DUSK staked
0%
Stake distribution
0%
DUSK market price
0%
Trading volume
0%
0 Voto(s) • Votación cerrada
Antes pensaba que el consenso era el momento en que los validadores se ponen de acuerdo sobre un bloque.
Al profundizar en Dusk, me hizo separar dos cosas:
Producción de bloques.
Finalidad.
Dusk utiliza Sucesión de Testimonio (Succinct Attestation), un diseño de consenso basado en prueba de participación y comités, en el que los validadores apuestan $DUSK para participar.
El detalle clave para mí es la finalidad determinista.
Una vez que un bloque alcanza la ratificación requerida, la red tiene un estado final definido en lugar de depender de un número creciente de confirmaciones para que la reversión sea menos probable.
Esa distinción importa más cuando la cadena de bloques se usa para la liquidación.
Una institución financiera necesita saber cuándo una transacción es final.
“Probablemente final” es una garantía diferente a la finalidad determinista.
La estructura de comités es lo que hace que el proceso sea interesante.
Pero no me quedaría solo con la descripción del protocolo.
La selección de comités importa.
La participación importa.
Las condiciones de red importan.
Son esos detalles los que me gustaría entender antes de juzgar cómo se comporta el sistema ante una tensión seria.
Así que mi conclusión no es que @Dusk ha resuelto el consenso. #dusk
Es que Dusk trata la finalidad como un resultado específico del protocolo, en lugar de asumir que la producción de bloques por sí sola responde la pregunta sobre la liquidación.
Para la infraestructura financiera, creo que esa distinción merece más atención.
@Dusk $DUSK #dusk
¿Qué es lo más importante para ti?
Al profundizar en Dusk, me hizo separar dos cosas:
Producción de bloques.
Finalidad.
Dusk utiliza Sucesión de Testimonio (Succinct Attestation), un diseño de consenso basado en prueba de participación y comités, en el que los validadores apuestan $DUSK para participar.
El detalle clave para mí es la finalidad determinista.
Una vez que un bloque alcanza la ratificación requerida, la red tiene un estado final definido en lugar de depender de un número creciente de confirmaciones para que la reversión sea menos probable.
Esa distinción importa más cuando la cadena de bloques se usa para la liquidación.
Una institución financiera necesita saber cuándo una transacción es final.
“Probablemente final” es una garantía diferente a la finalidad determinista.
La estructura de comités es lo que hace que el proceso sea interesante.
Pero no me quedaría solo con la descripción del protocolo.
La selección de comités importa.
La participación importa.
Las condiciones de red importan.
Son esos detalles los que me gustaría entender antes de juzgar cómo se comporta el sistema ante una tensión seria.
Así que mi conclusión no es que @Dusk ha resuelto el consenso. #dusk
Es que Dusk trata la finalidad como un resultado específico del protocolo, en lugar de asumir que la producción de bloques por sí sola responde la pregunta sobre la liquidación.
Para la infraestructura financiera, creo que esa distinción merece más atención.
@Dusk $DUSK #dusk
¿Qué es lo más importante para ti?
Fast blocks
100%
Finality
0%
Validator security
0%
Network stability
0%
1 Voto(s) • Votación cerrada
Antes yo veía la liquidación T+2 principalmente como un problema de velocidad.
Luego empecé a pensar en por qué existen esos dos días.
Ocurre una operación.
Diferentes partes confirman sus obligaciones.
Los custodios actualizan los registros.
El activo y el pago aún deben llegar a los lados correctos.
El periodo de espera le da al sistema tradicional tiempo para gestionar el riesgo de liquidación.
Así que cuando observo DuskDS, no pienso que la pregunta interesante sea simplemente:
“¿Puede la liquidación ocurrir más rápido?”
La mejor pregunta es:
“¿Qué aporta certidumbre cuando el periodo de espera se acorta?”
DuskDS se diseñó como la capa de liquidación y disponibilidad de datos de la @Dusk network, con $DUSK liquidando lo que sea que se mueva a través de ella. #dusk
Su finalidad determinista le da a las aplicaciones un punto definido donde el estado queda liquidado.
Eso es importante para los flujos de trabajo financieros.
Pero una liquidación más rápida no reproduce automáticamente cada protección dentro de los sistemas tradicionales de liquidación.
El riesgo todavía necesita gestionarse en algún lugar.
Esa es la parte que quiero ver demostrada.
Una transacción institucional real me diría mucho más que una simple comparación de segundos contra días.
Para mí, la parte interesante de DuskDS no es solo la velocidad.
Es lo que el sistema hace con certidumbre una vez que la transacción alcanza la finalidad.
@Dusk $DUSK #dusk
¿Qué es lo más importante cuando la liquidación se vuelve más rápida?
Luego empecé a pensar en por qué existen esos dos días.
Ocurre una operación.
Diferentes partes confirman sus obligaciones.
Los custodios actualizan los registros.
El activo y el pago aún deben llegar a los lados correctos.
El periodo de espera le da al sistema tradicional tiempo para gestionar el riesgo de liquidación.
Así que cuando observo DuskDS, no pienso que la pregunta interesante sea simplemente:
“¿Puede la liquidación ocurrir más rápido?”
La mejor pregunta es:
“¿Qué aporta certidumbre cuando el periodo de espera se acorta?”
DuskDS se diseñó como la capa de liquidación y disponibilidad de datos de la @Dusk network, con $DUSK liquidando lo que sea que se mueva a través de ella. #dusk
Su finalidad determinista le da a las aplicaciones un punto definido donde el estado queda liquidado.
Eso es importante para los flujos de trabajo financieros.
Pero una liquidación más rápida no reproduce automáticamente cada protección dentro de los sistemas tradicionales de liquidación.
El riesgo todavía necesita gestionarse en algún lugar.
Esa es la parte que quiero ver demostrada.
Una transacción institucional real me diría mucho más que una simple comparación de segundos contra días.
Para mí, la parte interesante de DuskDS no es solo la velocidad.
Es lo que el sistema hace con certidumbre una vez que la transacción alcanza la finalidad.
@Dusk $DUSK #dusk
¿Qué es lo más importante cuando la liquidación se vuelve más rápida?
Speed of settlement
0%
Certainty after finality
0%
Lower settlement risk
0%
Institutional adoption
0%
0 Voto(s) • Votación cerrada
Seguí viendo mencionados Moonlight y Phoenix por separado.
Así que empecé con una pregunta:
¿Por qué @Dusk necesita dos modelos de transacción?
Moonlight usa transferencias públicas basadas en cuentas.
Phoenix usa transferencias privadas basadas en notas con pruebas de conocimiento cero.
Ambas convergen en DuskDS.
La diferencia es qué información se vuelve visible.
Moonlight expone saldos y detalles de las transferencias.
Phoenix mantiene la información de las transacciones protegida mientras, aun así, prueba que la transacción sigue las reglas requeridas.
Esa distinción tiene más sentido cuando piensas en la actividad financiera.
Algunos flujos necesitan registros públicos.
Otros involucran información que no debería ser visible para todo observador de la red.
Dusk no obliga a que ambas situaciones encajen en el mismo modelo de transacción.
Me parece ese diseño más interesante que solo llamar $DUSK a una moneda de privacidad. #dusk
También hay una cuestión práctica.
Modelos de transacción diferentes significan requisitos de desarrollo e integración diferentes.
Así que quiero ver qué tan naturalmente las aplicaciones eligen entre ellos.
La separación técnica tiene sentido para mí.
La experiencia del desarrollador es la parte que todavía quiero entender.
@Dusk $DUSK #dusk
Así que empecé con una pregunta:
¿Por qué @Dusk necesita dos modelos de transacción?
Moonlight usa transferencias públicas basadas en cuentas.
Phoenix usa transferencias privadas basadas en notas con pruebas de conocimiento cero.
Ambas convergen en DuskDS.
La diferencia es qué información se vuelve visible.
Moonlight expone saldos y detalles de las transferencias.
Phoenix mantiene la información de las transacciones protegida mientras, aun así, prueba que la transacción sigue las reglas requeridas.
Esa distinción tiene más sentido cuando piensas en la actividad financiera.
Algunos flujos necesitan registros públicos.
Otros involucran información que no debería ser visible para todo observador de la red.
Dusk no obliga a que ambas situaciones encajen en el mismo modelo de transacción.
Me parece ese diseño más interesante que solo llamar $DUSK a una moneda de privacidad. #dusk
También hay una cuestión práctica.
Modelos de transacción diferentes significan requisitos de desarrollo e integración diferentes.
Así que quiero ver qué tan naturalmente las aplicaciones eligen entre ellos.
La separación técnica tiene sentido para mí.
La experiencia del desarrollador es la parte que todavía quiero entender.
@Dusk $DUSK #dusk
Empecé a mirar Dusk Trade desde una perspectiva simple:
¿Qué es lo que realmente hace un inversor?
Encuentras un activo.
Verificas si eres elegible.
Decides comprar.
La operación debe ejecutarse.
Luego la transacción debe liquidarse.
Un token por sí solo no proporciona todo este flujo de trabajo.
Por eso Dusk Trade llamó mi atención. @Dusk lo describe como la capa de aplicación para activos financieros tokenizados, con flujos de trabajo que cubren el alta de inversores, el vinculado de carteras, transferencias controladas, coordinación de pagos y liquidación. #dusk
Eso hace que el producto sea diferente de observar un token RWA de forma aislada.
Lo difícil de los mercados regulados es el flujo de trabajo en torno al activo.
¿Quién obtiene acceso?
¿Quién puede tenerlo?
¿Quién puede transferirlo?
¿Cómo se liquida la operación?
Dusk Trade se está construyendo alrededor de esas preguntas.
Aún quiero ver el proceso completo funcionando con activos regulados reales y usuarios reales, con comisiones de transacción pagadas en $DUSK igual que cualquier otra cosa en la red.
La arquitectura me da una idea de cómo se supone que debe operar el flujo de trabajo.
El producto en vivo me dirá cuánta fricción queda.
Esa es la parte que estoy observando.....
¿Qué es lo que realmente hace un inversor?
Encuentras un activo.
Verificas si eres elegible.
Decides comprar.
La operación debe ejecutarse.
Luego la transacción debe liquidarse.
Un token por sí solo no proporciona todo este flujo de trabajo.
Por eso Dusk Trade llamó mi atención. @Dusk lo describe como la capa de aplicación para activos financieros tokenizados, con flujos de trabajo que cubren el alta de inversores, el vinculado de carteras, transferencias controladas, coordinación de pagos y liquidación. #dusk
Eso hace que el producto sea diferente de observar un token RWA de forma aislada.
Lo difícil de los mercados regulados es el flujo de trabajo en torno al activo.
¿Quién obtiene acceso?
¿Quién puede tenerlo?
¿Quién puede transferirlo?
¿Cómo se liquida la operación?
Dusk Trade se está construyendo alrededor de esas preguntas.
Aún quiero ver el proceso completo funcionando con activos regulados reales y usuarios reales, con comisiones de transacción pagadas en $DUSK igual que cualquier otra cosa en la red.
La arquitectura me da una idea de cómo se supone que debe operar el flujo de trabajo.
El producto en vivo me dirá cuánta fricción queda.
Esa es la parte que estoy observando.....
€300M+ llamó mi atención cuando empecé a mirar Dusk y NPEX.🔥🔥🔥
Entonces dejé de mirar la cifra del activo y empecé a mirar los datos que hay detrás de los activos.
Un mercado regulado necesita más que un token onchain.
Las aplicaciones también necesitan información de mercado fiable.
¿Cuál es el precio?
¿Cuál es el estado del mercado?
¿De dónde provienen los datos?
Aquí es donde la relación entre @Dusk , NPEX y Chainlink se pone interesante para mí. #dusk
Las direcciones CCIP enlazan el movimiento entre cadenas.
DataLink y Data Streams abordan los datos de mercado.
Son problemas distintos, y la mayoría de los proyectos solo resuelve uno de ellos.
Mover un activo entre redes no le dice a una aplicación cuál es su valor.
Un feed de precios no resuelve la liquidación entre cadenas.
Dusk resolviendo ambos a la vez, mediante una sola integración en lugar de dos añadidos separados, es lo que realmente me convenció de que esto no es solo otro anuncio de colaboración.
Mientras investigaba esto, hubo un número que destacó y que no tenía nada que ver con la asociación… la testnet incentivada de Dusk ya tiene 8.000+ nodos activos en funcionamiento. No es una cifra llamativa, es una infraestructura, y me dice que hay participación real ocurriendo antes de que el mainnet esté siquiera en marcha.
Cada llamada sigue pasando por la red y se liquida en $DUSK igual que cualquier otra transacción.
¿Qué tan de cerca la información de mercado onchain sigue la fuente que usa NPEX?
¿Qué tan rápido llega la información actualizada a las aplicaciones?
Son esos detalles los que realmente lo demostrarán, y NPEX ya aporta licencias reales mientras ocurre… estado AFM regulado, MTF, Broker y ECSP ya listo incluso antes de que se lanzara esta integración.
La tokenización atrae la atención.
La infraestructura que, en silencio, hace que esa tokenización sea confiable, incluyendo el conteo de nodos, es donde creo que Dusk realmente va por delante.
@Dusk $DUSK #dusk
Entonces dejé de mirar la cifra del activo y empecé a mirar los datos que hay detrás de los activos.
Un mercado regulado necesita más que un token onchain.
Las aplicaciones también necesitan información de mercado fiable.
¿Cuál es el precio?
¿Cuál es el estado del mercado?
¿De dónde provienen los datos?
Aquí es donde la relación entre @Dusk , NPEX y Chainlink se pone interesante para mí. #dusk
Las direcciones CCIP enlazan el movimiento entre cadenas.
DataLink y Data Streams abordan los datos de mercado.
Son problemas distintos, y la mayoría de los proyectos solo resuelve uno de ellos.
Mover un activo entre redes no le dice a una aplicación cuál es su valor.
Un feed de precios no resuelve la liquidación entre cadenas.
Dusk resolviendo ambos a la vez, mediante una sola integración en lugar de dos añadidos separados, es lo que realmente me convenció de que esto no es solo otro anuncio de colaboración.
Mientras investigaba esto, hubo un número que destacó y que no tenía nada que ver con la asociación… la testnet incentivada de Dusk ya tiene 8.000+ nodos activos en funcionamiento. No es una cifra llamativa, es una infraestructura, y me dice que hay participación real ocurriendo antes de que el mainnet esté siquiera en marcha.
Cada llamada sigue pasando por la red y se liquida en $DUSK igual que cualquier otra transacción.
¿Qué tan de cerca la información de mercado onchain sigue la fuente que usa NPEX?
¿Qué tan rápido llega la información actualizada a las aplicaciones?
Son esos detalles los que realmente lo demostrarán, y NPEX ya aporta licencias reales mientras ocurre… estado AFM regulado, MTF, Broker y ECSP ya listo incluso antes de que se lanzara esta integración.
La tokenización atrae la atención.
La infraestructura que, en silencio, hace que esa tokenización sea confiable, incluyendo el conteo de nodos, es donde creo que Dusk realmente va por delante.
@Dusk $DUSK #dusk
Verificado
Esperaba que DuskEVM requiriera un flujo de trabajo de desarrollador completamente diferente….
Luego miré las herramientas. 👍
Solidity se mantiene familiar.
Hardhat.
Foundry.
ethers.
La pila habitual de desarrollo EVM sigue aplicando.
Me llamó la atención porque pasar a una nueva blockchain a menudo significa aprender un entorno nuevo antes de poder construir algo útil.
DuskEVM toma una ruta distinta. Proporciona un entorno de ejecución equivalente a EVM en @Dusk mientras DuskDS gestiona el settlement y la disponibilidad de datos por debajo…
Así que el desarrollador no necesita desechar el flujo EVM para construir en la red; el gas se paga en $DUSK de la misma manera en que funciona ETH en Ethereum.
Para mí, esto cambia la pregunta sobre la adopción.
El problema ya no es solo si Dusk tiene las funciones que los desarrolladores necesitan…
También se trata de cuánto conocimiento e infraestructura EVM existentes pueden los desarrolladores reutilizar.
Todavía hay algo que quiero probar.
La compatibilidad en la documentación es una cosa.
Desplegar una aplicación real, depurar contratos, conectar wallets y mantener la aplicación es otra.
Creo que ahí es donde DuskEVM demostrará si este enfoque funciona tan fluido como sugiere la arquitectura. #dusk
Luego miré las herramientas. 👍
Solidity se mantiene familiar.
Hardhat.
Foundry.
ethers.
La pila habitual de desarrollo EVM sigue aplicando.
Me llamó la atención porque pasar a una nueva blockchain a menudo significa aprender un entorno nuevo antes de poder construir algo útil.
DuskEVM toma una ruta distinta. Proporciona un entorno de ejecución equivalente a EVM en @Dusk mientras DuskDS gestiona el settlement y la disponibilidad de datos por debajo…
Así que el desarrollador no necesita desechar el flujo EVM para construir en la red; el gas se paga en $DUSK de la misma manera en que funciona ETH en Ethereum.
Para mí, esto cambia la pregunta sobre la adopción.
El problema ya no es solo si Dusk tiene las funciones que los desarrolladores necesitan…
También se trata de cuánto conocimiento e infraestructura EVM existentes pueden los desarrolladores reutilizar.
Todavía hay algo que quiero probar.
La compatibilidad en la documentación es una cosa.
Desplegar una aplicación real, depurar contratos, conectar wallets y mantener la aplicación es otra.
Creo que ahí es donde DuskEVM demostrará si este enfoque funciona tan fluido como sugiere la arquitectura. #dusk
#dusk $DUSK @Dusk Sigo viendo debates de RWA que tratan los activos emitidos tokenizados y los emitidos nativamente como si fueran lo mismo.
@Dusk t los trata de forma diferente, y creo que esta distinción importa.
“Tokenizado” normalmente significa que un token representa un activo que se mantiene en algún lugar distinto.
Pensemos en un bono, un fondo o una acción.....
El activo sigue estando fuera de la cadena (offchain) con un custodio.
El token apunta al activo.
Cuando el token se mueve onchain, el sistema que mantiene el activo real aún necesita una actualización coincidente.
Dos registros.
Dos lugares.
Alguien tiene que mantenerlos alineados.
La emisión nativa toma un enfoque diferente.
Dusk se centra en el ciclo de vida completo del activo:
Emisión.
Transferencia.
Gestión.
Liquidación.
Estos procesos se ejecutan en infraestructura diseñada para mercados regulados, donde la estructura legal permite el modelo.
El token no es un comprobante de algo que está en otra parte.
El registro en Dusk se convierte en el registro principal.
Aquí es donde la capa base de Dusk me resulta especialmente interesante.
Controles de acceso.
Verificaciones de elegibilidad.
Divulgación selectiva.
Estas funciones están en la capa base en lugar de añadirse después.
Una cadena de propósito general sin primitivas de cumplimiento no tiene la misma configuración.
Así que el activo se queda en la etapa de “wrapper” por diseño.
Ahora veamos el ejemplo del bono desde el otro lado.
Con emisión nativa, la emisión y las transferencias del bono ocurren donde ya viven las reglas de elegibilidad y divulgación.
No hay un sistema separado que deba mantenerse sincronizado.
Por eso vuelvo una y otra vez a una pregunta al observar proyectos de RWA:
¿Los activos realmente se emiten de forma nativa, o siguen siendo tokens que representan activos mantenidos en algún lugar distinto?
Para mí, esta distinción dice más sobre la infraestructura que lo que hace la palabra “tokenización”.
@Dusk t los trata de forma diferente, y creo que esta distinción importa.
“Tokenizado” normalmente significa que un token representa un activo que se mantiene en algún lugar distinto.
Pensemos en un bono, un fondo o una acción.....
El activo sigue estando fuera de la cadena (offchain) con un custodio.
El token apunta al activo.
Cuando el token se mueve onchain, el sistema que mantiene el activo real aún necesita una actualización coincidente.
Dos registros.
Dos lugares.
Alguien tiene que mantenerlos alineados.
La emisión nativa toma un enfoque diferente.
Dusk se centra en el ciclo de vida completo del activo:
Emisión.
Transferencia.
Gestión.
Liquidación.
Estos procesos se ejecutan en infraestructura diseñada para mercados regulados, donde la estructura legal permite el modelo.
El token no es un comprobante de algo que está en otra parte.
El registro en Dusk se convierte en el registro principal.
Aquí es donde la capa base de Dusk me resulta especialmente interesante.
Controles de acceso.
Verificaciones de elegibilidad.
Divulgación selectiva.
Estas funciones están en la capa base en lugar de añadirse después.
Una cadena de propósito general sin primitivas de cumplimiento no tiene la misma configuración.
Así que el activo se queda en la etapa de “wrapper” por diseño.
Ahora veamos el ejemplo del bono desde el otro lado.
Con emisión nativa, la emisión y las transferencias del bono ocurren donde ya viven las reglas de elegibilidad y divulgación.
No hay un sistema separado que deba mantenerse sincronizado.
Por eso vuelvo una y otra vez a una pregunta al observar proyectos de RWA:
¿Los activos realmente se emiten de forma nativa, o siguen siendo tokens que representan activos mantenidos en algún lugar distinto?
Para mí, esta distinción dice más sobre la infraestructura que lo que hace la palabra “tokenización”.
#dusk $DUSK @Dusk Si los datos están completamente ocultos, ¿cómo puede un sistema regulado demostrar que se siguieron realmente las normas?
Esa es la pregunta en la que muchas herramientas de privacidad se quedan cortas. Se centran en ocultar los datos. Dejan casi sin margen para comprobar qué ocurrió.
Para aplicaciones que necesitan supervisión, este intercambio se convierte en un problema.
Lo que destacó cuando observé @Dusk is Hedger. Está en DuskEVM. Está construido como un módulo de privacidad para aplicaciones financieras.
Hedger combina cifrado homomórfico con pruebas de conocimiento cero para que una transacción pueda permanecer confidencial mientras aún permite la verificación.
Una operación cifrada puede permanecer oculta para el público. Un responsable autorizado de cumplimiento puede, aun así, confirmar que se siguieron las reglas correctas sin ver los datos subyacentes completos de la transacción.
La elección de diseño de Hedger parece deliberada.
En lugar de tratar la privacidad como opacidad total, Hedger intenta mantener los datos de las aplicaciones financieras protegidos y, al mismo tiempo, que la revisión del proceso sea posible.
Esta combinación de proteger los datos y permitir la verificación es más rara de lo que debería en las aplicaciones.
La privacidad se vuelve más útil para las finanzas cuando aún puede respaldar la verificación y la supervisión de las aplicaciones.
Esa es la parte a la que sigo volviendo cuando pienso en Hedger y Dusk y el papel de $DUSK en ello.
Esa es la pregunta en la que muchas herramientas de privacidad se quedan cortas. Se centran en ocultar los datos. Dejan casi sin margen para comprobar qué ocurrió.
Para aplicaciones que necesitan supervisión, este intercambio se convierte en un problema.
Lo que destacó cuando observé @Dusk is Hedger. Está en DuskEVM. Está construido como un módulo de privacidad para aplicaciones financieras.
Hedger combina cifrado homomórfico con pruebas de conocimiento cero para que una transacción pueda permanecer confidencial mientras aún permite la verificación.
Una operación cifrada puede permanecer oculta para el público. Un responsable autorizado de cumplimiento puede, aun así, confirmar que se siguieron las reglas correctas sin ver los datos subyacentes completos de la transacción.
La elección de diseño de Hedger parece deliberada.
En lugar de tratar la privacidad como opacidad total, Hedger intenta mantener los datos de las aplicaciones financieras protegidos y, al mismo tiempo, que la revisión del proceso sea posible.
Esta combinación de proteger los datos y permitir la verificación es más rara de lo que debería en las aplicaciones.
La privacidad se vuelve más útil para las finanzas cuando aún puede respaldar la verificación y la supervisión de las aplicaciones.
Esa es la parte a la que sigo volviendo cuando pienso en Hedger y Dusk y el papel de $DUSK en ello.
⚠️ ADVERTENCIA DE GRAN TORMENTA🚨🚨🚨
$BTC nunca toca fondo en el primer desplome.
Lo hace en la segunda pierna: la capitulación final a la que casi nadie está posicionado.
Mira el patrón del ciclo:
2018: $19k → $10k → $3.5k 2022: $69k → $32k → $15k 2026: $126k → $64k → $45k
Primera pierna: salen los turistas. Luego llega el rebote que todos llaman “el fondo”. Ese es el falso rompimiento al alza.
El verdadero vaciado ocurre después… recortando el precio casi a la mitad otra vez mientras el cronograma aún grita que lo peor ya pasó.
Esa segunda pierna es donde el ciclo realmente se reinicia. Es la cifra que la mayoría de la gente se niega a decir en voz alta hasta que ya está impresa. Y es exactamente donde se gana el dinero de verdad.
Ahora mismo estamos atrapados en el señuelo.
La mayoría solo lo reconocerá en el retrovisor.
$BTC nunca toca fondo en el primer desplome.
Lo hace en la segunda pierna: la capitulación final a la que casi nadie está posicionado.
Mira el patrón del ciclo:
2018: $19k → $10k → $3.5k 2022: $69k → $32k → $15k 2026: $126k → $64k → $45k
Primera pierna: salen los turistas. Luego llega el rebote que todos llaman “el fondo”. Ese es el falso rompimiento al alza.
El verdadero vaciado ocurre después… recortando el precio casi a la mitad otra vez mientras el cronograma aún grita que lo peor ya pasó.
Esa segunda pierna es donde el ciclo realmente se reinicia. Es la cifra que la mayoría de la gente se niega a decir en voz alta hasta que ya está impresa. Y es exactamente donde se gana el dinero de verdad.
Ahora mismo estamos atrapados en el señuelo.
La mayoría solo lo reconocerá en el retrovisor.
$BTC simplemente se deslizó por debajo de $63K. El S&P está en máximos históricos.
Dos activos, misma semana, direcciones opuestas. Eso no es ruido… eso es una señal sobre dónde está realmente el apetito por el riesgo en este momento.
No significa que las criptomonedas hayan terminado. Significa que el capital está rotando, y rotaciones como esta ya han ocurrido antes. La diferencia esta vez es lo fuerte que se siente porque todo el mundo está mirando ambos gráficos al mismo tiempo.
No estoy vendiendo. No estoy entrando en pánico. Solo estoy prestando atención.
Dos activos, misma semana, direcciones opuestas. Eso no es ruido… eso es una señal sobre dónde está realmente el apetito por el riesgo en este momento.
No significa que las criptomonedas hayan terminado. Significa que el capital está rotando, y rotaciones como esta ya han ocurrido antes. La diferencia esta vez es lo fuerte que se siente porque todo el mundo está mirando ambos gráficos al mismo tiempo.
No estoy vendiendo. No estoy entrando en pánico. Solo estoy prestando atención.
#dusk $DUSK @Dusk Antes suponía que la privacidad y el cumplimiento eran, básicamente, opuestos en las blockchains públicas. O todo está totalmente visible o queda bloqueado de tal manera que comprobar cualquier cosa se vuelve casi imposible. La mayoría de los sistemas parecían construidos para esa lógica de «todo o nada».
Mirando más de cerca @Dusk cambié mi forma de verlo. Su enfoque se llama privacidad programable. No fuerza a la red a irse a un extremo. Algunos datos se mantienen privados. Otros se mantienen abiertos cuando eso ayuda. Y las personas adecuadas aún pueden revisar lo que necesiten. La privacidad y el cumplimiento no tienen por qué pelear entre sí. Pueden coexistir a la vez.
Imagina un escenario sencillo.... Un gestor de fondos podría querer que las posiciones de su cartera se mantengan alejadas de los competidores. Al mismo tiempo, un regulador quizá necesite acceso a registros específicos. La privacidad programable está diseñada para que ambas cosas puedan ser ciertas sin romper la otra.
Lo que me resulta interesante es el cambio de enfoque. En lugar de tratar la privacidad como algo que tiene que sacrificarse por la regulación, o la regulación como algo que mata la privacidad, el diseño parte de la suposición de que las finanzas reguladas necesitan ambas. Ese pequeño cambio en el punto de partida parece moldearlo todo.
Aún estoy empezando a explorar el proyecto, pero esta idea en particular es la que me hizo seguir leyendo.
Mirando más de cerca @Dusk cambié mi forma de verlo. Su enfoque se llama privacidad programable. No fuerza a la red a irse a un extremo. Algunos datos se mantienen privados. Otros se mantienen abiertos cuando eso ayuda. Y las personas adecuadas aún pueden revisar lo que necesiten. La privacidad y el cumplimiento no tienen por qué pelear entre sí. Pueden coexistir a la vez.
Imagina un escenario sencillo.... Un gestor de fondos podría querer que las posiciones de su cartera se mantengan alejadas de los competidores. Al mismo tiempo, un regulador quizá necesite acceso a registros específicos. La privacidad programable está diseñada para que ambas cosas puedan ser ciertas sin romper la otra.
Lo que me resulta interesante es el cambio de enfoque. En lugar de tratar la privacidad como algo que tiene que sacrificarse por la regulación, o la regulación como algo que mata la privacidad, el diseño parte de la suposición de que las finanzas reguladas necesitan ambas. Ese pequeño cambio en el punto de partida parece moldearlo todo.
Aún estoy empezando a explorar el proyecto, pero esta idea en particular es la que me hizo seguir leyendo.
Acabo de girar la ruleta y me gané algunas recompensas.❤️❤️❤️
¡Aquí está lo que gané de la campaña de hoy:
$1 en $TSLAB
$3 en $SPCXB
$1 en $TSLAB
El estado actualmente está Procesando, pero ¡cada mini recompensa suma! 💰
¿Alguien logró alcanzar los premios más grandes como el $1,000 PLTRB o $500 AMZNB?
¡Pongan sus resultados del giro abajo! 👇
#Binance #CryptoRewards #SpinToWin #TradingRewards
¡Aquí está lo que gané de la campaña de hoy:
$1 en $TSLAB
$3 en $SPCXB
$1 en $TSLAB
El estado actualmente está Procesando, pero ¡cada mini recompensa suma! 💰
¿Alguien logró alcanzar los premios más grandes como el $1,000 PLTRB o $500 AMZNB?
¡Pongan sus resultados del giro abajo! 👇
#Binance #CryptoRewards #SpinToWin #TradingRewards
@BabylonLabs_io He estado siguiendo de cerca la línea de tiempo de TBV. La última llamada con los fundadores hizo que el progreso se sintiera real. La testnet pública ya ha creado más de 2,000 bóvedas desde finales de mayo. El tiempo de creación de bóvedas pasó de unas tres horas a alrededor de 90 minutos tras un avance de investigación. El Temp Check de Aave pasó con un fuerte apoyo. Se espera el ARFC a mediados de agosto. El equipo apunta al mainnet de octubre una vez que se completen las auditorías y la preparación.
Partners como Bedrock, GoMining y 84 Labs han mostrado interés en el tamaño de hasta 1,000 BTC cada uno. Carteras de hardware y MPC, incluyendo Ledger, Keystone y Utila, están agregando las firmas adicionales que TBV necesita. Los datos de uso en vivo, los socios de infraestructura y el progreso de la gobernanza, juntos, convierten una idea de investigación en algo utilizable.
Para mí, la señal es clara. La garantía nativa en Bitcoin sin wrapping ni custodia está pasando del experimento de testnet a algo que las instituciones realmente pueden planear.
$BABY #baby
¿Qué es lo que más te da confianza en TBV?
A. Velocidad
B. Aave
C. Socios
D. BTC nativo
Partners como Bedrock, GoMining y 84 Labs han mostrado interés en el tamaño de hasta 1,000 BTC cada uno. Carteras de hardware y MPC, incluyendo Ledger, Keystone y Utila, están agregando las firmas adicionales que TBV necesita. Los datos de uso en vivo, los socios de infraestructura y el progreso de la gobernanza, juntos, convierten una idea de investigación en algo utilizable.
Para mí, la señal es clara. La garantía nativa en Bitcoin sin wrapping ni custodia está pasando del experimento de testnet a algo que las instituciones realmente pueden planear.
$BABY #baby
¿Qué es lo que más te da confianza en TBV?
A. Velocidad
B. Aave
C. Socios
D. BTC nativo
#baby $BABY @BabylonLabs_io
Noté algo en la estructura de gobernanza de Babylon. Parece más valioso sentarse a reflexionarlo que pasarlo por alto. Los stakers de BTC proporcionan la seguridad económica. Su bitcoin respalda a los proveedores de finalización. Su capital está en riesgo si algo se castiga (se slashea). Pero la gobernanza se realiza solo por $BABY holders. Votan cambios de comisiones, parámetros de inflación y actualizaciones del protocolo. Los stakers de BTC no tienen derecho a voto. En un nivel, eso tiene sentido. BABY es el token nativo de gobernanza. Así fue diseñado el sistema desde el principio. Pero crea una brecha específica. El grupo que asume el riesgo de seguridad y el grupo que establece los parámetros económicos no necesariamente son las mismas personas. Podrías estar profundamente expuesto como staker de BTC. Podrías no tener voz en un voto que cambia los términos bajo los cuales estás apostando (staked). Quizá en la práctica eso esté bien. Es posible que los dos grupos se superpongan mucho. Muchos stakers de BTC probablemente también tengan BABY. Pero “probablemente se superpongan” y “garantizado estructuralmente que se superpongan” son cosas diferentes. No he visto nada que exija la segunda opción. No digo que esto sea exactamente un defecto. Es solo una elección de diseño que vale la pena nombrar. No deberíamos asumir que la gobernanza y la seguridad apuntan automáticamente en la misma dirección.
Noté algo en la estructura de gobernanza de Babylon. Parece más valioso sentarse a reflexionarlo que pasarlo por alto. Los stakers de BTC proporcionan la seguridad económica. Su bitcoin respalda a los proveedores de finalización. Su capital está en riesgo si algo se castiga (se slashea). Pero la gobernanza se realiza solo por $BABY holders. Votan cambios de comisiones, parámetros de inflación y actualizaciones del protocolo. Los stakers de BTC no tienen derecho a voto. En un nivel, eso tiene sentido. BABY es el token nativo de gobernanza. Así fue diseñado el sistema desde el principio. Pero crea una brecha específica. El grupo que asume el riesgo de seguridad y el grupo que establece los parámetros económicos no necesariamente son las mismas personas. Podrías estar profundamente expuesto como staker de BTC. Podrías no tener voz en un voto que cambia los términos bajo los cuales estás apostando (staked). Quizá en la práctica eso esté bien. Es posible que los dos grupos se superpongan mucho. Muchos stakers de BTC probablemente también tengan BABY. Pero “probablemente se superpongan” y “garantizado estructuralmente que se superpongan” son cosas diferentes. No he visto nada que exija la segunda opción. No digo que esto sea exactamente un defecto. Es solo una elección de diseño que vale la pena nombrar. No deberíamos asumir que la gobernanza y la seguridad apuntan automáticamente en la misma dirección.
BULLISH???
50%
BEARISH???
50%
2 Voto(s) • Votación cerrada
Al principio pensé que la parte más interesante del diseño de Babylon era la eficiencia de capital.
Un UTXO de Bitcoin que ayude a asegurar múltiples Redes Bitcoin Aseguradas suena como una mejora obvia. El mismo BTC puede contribuir a la seguridad en diferentes cadenas en lugar de estar bloqueado por separado para cada una.
La relación entre el colateral compartido y el slashing aislado me llamó la atención.
La documentación explica que el slashing es parcial, alrededor de un 0,1% del stake por mala conducta, y que cada BSN tiene límites de aislamiento para que los problemas en una red no se propaguen a otra.
Eso tiene sentido por sí mismo.
Pero entonces empecé a preguntarme qué pasa cuando el mismo UTXO está asegurando más de una cadena al mismo tiempo.
Si la Cadena A sufre un evento de slashing porque sus Proveedores de Finalidad se comportan mal, ¿solo se quema la porción de stake asignada a la Cadena A?
¿O el UTXO subyacente en sí asume la pérdida, reduciendo también el colateral que todavía está asegurando la Cadena B?
Para mí, ahí es donde empieza la pregunta interesante.
“Isolado” y “colateral compartido” parecen perfectamente compatibles a alto nivel, pero una vez que piensas en la mecánica, es menos obvio cómo encajan entre sí.
Puede haber una respuesta sencilla. La contabilidad por debajo podría ser mucho más granular de lo que me estoy imaginando.
Solo que todavía no he encontrado documentación que recorra ese escenario específico.
¿Alguien ha encontrado una explicación detallada de cómo se maneja ese caso?
@BabylonLabs_io $BABY #baby
Un UTXO de Bitcoin que ayude a asegurar múltiples Redes Bitcoin Aseguradas suena como una mejora obvia. El mismo BTC puede contribuir a la seguridad en diferentes cadenas en lugar de estar bloqueado por separado para cada una.
La relación entre el colateral compartido y el slashing aislado me llamó la atención.
La documentación explica que el slashing es parcial, alrededor de un 0,1% del stake por mala conducta, y que cada BSN tiene límites de aislamiento para que los problemas en una red no se propaguen a otra.
Eso tiene sentido por sí mismo.
Pero entonces empecé a preguntarme qué pasa cuando el mismo UTXO está asegurando más de una cadena al mismo tiempo.
Si la Cadena A sufre un evento de slashing porque sus Proveedores de Finalidad se comportan mal, ¿solo se quema la porción de stake asignada a la Cadena A?
¿O el UTXO subyacente en sí asume la pérdida, reduciendo también el colateral que todavía está asegurando la Cadena B?
Para mí, ahí es donde empieza la pregunta interesante.
“Isolado” y “colateral compartido” parecen perfectamente compatibles a alto nivel, pero una vez que piensas en la mecánica, es menos obvio cómo encajan entre sí.
Puede haber una respuesta sencilla. La contabilidad por debajo podría ser mucho más granular de lo que me estoy imaginando.
Solo que todavía no he encontrado documentación que recorra ese escenario específico.
¿Alguien ha encontrado una explicación detallada de cómo se maneja ese caso?
@BabylonLabs_io $BABY #baby
Inicia sesión para explorar más contenidos