Siempre he pensado que el KYC tiene un punto que resulta especialmente molesto.
No es que sea una molestia hacer una sola vez.
Es que, aunque ya hayas entregado tu nombre, dirección, documentos y toda clase de información en una plataforma, si cambias a otra plataforma, te obligan a hacerlo desde el principio otra vez.
Recientemente vi el Citadel 2 de @Dusk y de pronto pensé que quizá el enfoque del problema no debería plantearse así.
¿De verdad las plataformas necesitan saber “quién soy”?
¿O en realidad solo quieren comprobar algunas cosas:
si vengo de una región permitida;
si tengo la edad suficiente;
y si cumplo algún requisito de inversión.
Si solo es para confirmar esas condiciones, entonces volver a enviar todo el paquete de datos de identidad cada vez sí es un poco redundante.
La idea de Citadel tampoco es eliminar el KYC.
La verificación de identidad del mundo real sigue siendo necesaria.
La diferencia está después.
Una vez verificado, obtienes un credential y luego usas ZK para demostrar que cumples una condición específica, sin tener que volver a exponer toda la información a la siguiente plataforma cada vez.
Creo que esa diferencia es bastante práctica.
Demostrar que “soy apto” no significa que tenga que volver a entregar toda mi información personal.
Por supuesto, tampoco hay que entender esto como anonimato absoluto.
Si el dispositivo, la red y los atributos en sí son lo suficientemente singulares, eso también puede afectar la privacidad.
Pero al menos aborda un problema que siempre me pareció muy molesto:
Lo que necesita la plataforma, eso es lo que hay que demostrar.
No asumas que cada vez hay que tomar de nuevo todo el paquete de información desde el principio.
Antes veía “EVM compatible” y, básicamente, no pensaba mucho.
Si con Solidity se puede escribir, con Foundry se puede ejecutar y el monedero también se puede conectar, ¿entonces no es básicamente seguir usando el mismo modelo de Ethereum?
Más recientemente leí la Reference de DuskEVM de @Dusk y me di cuenta de que, al hacer un despliegue real, aún no se puede ser tan descuidado.
Un ejemplo muy simple: DuskEVM ahora tiene su propio sequencer.
Cuando la transacción obtiene un receipt, significa que ya se ha incluido en un bloque, pero eso no es lo mismo que el settlement posterior.
También está prevrandao.
En Ethereum, algunos desarrolladores lo usan a menudo para lógica relacionada con números aleatorios de forma automática; pero la documentación oficial de Dusk advierte específicamente que, en DuskEVM, no lo trates como una fuente de aleatoriedad segura y sin sesgos.
Este tipo de cosas, si normalmente no miras la Reference, es muy fácil escribirlo directamente siguiendo los hábitos antiguos.
Así que ahora mi comprensión de la compatibilidad EVM es más realista que antes:
Puede ahorrarte muchos costos de migración, eso está bien.
Pero “la interfaz es familiar” y “el entorno subyacente es igual” no son lo mismo.
Si de verdad vas a ponerlo en producción, todavía hay que revisar de nuevo cosas como el sequencer, la finality y el estado entre capas.
De hecho, me gusta que la documentación oficial ponga estas limitaciones de forma tan directa.
Lo que más me preocupa no es que haya diferencias.
Supongamos que estás listo para comprar activos por 5 millones de dólares.
El pedido todavía no se ha ejecutado, pero todo el mercado ya sabe que los estás comprando.
Saben de qué lado estás.
Saben lo urgente que es para ti.
Incluso podrían estimar cuántas órdenes más pendientes tienes detrás.
En ese momento, ¿“total transparencia en la cadena” tiene que ser necesariamente algo bueno?
Recientemente vi el Hedger de @Dusk ; lo que más me interesa no es ZK, ni la criptografía homomórfica.
Me interesa lo que menciona: los libros de órdenes ofuscados.
Mi primera reacción fue:
Por fin alguien se toma en serio el hecho de que el dinero grande no quiere mostrar sus cartas con antelación.
Que un minorista cuelgue órdenes de unos cientos o miles de dólares, y que sea un poco más transparente, no es un problema.
Pero las instituciones no son así.
La intención de una orden es, en sí misma, información.
Si vas a comprar o vender, cuánta liquidez necesitas, cuánto estás dispuesto a esperar: con que eso se revele con anticipación, otros pueden ajustar su estrategia alrededor de tus necesidades.
Al final, quizá no es que “te hayan hackeado”.
Pero el precio de ejecución puede salir peor que de costumbre.
Por eso cada vez siento más que:
La transparencia, para los minoristas, puede ser información; pero para el gran capital, a veces es un costo de ejecución.
El Hedger no pretende convertir la bolsa en una caja negra.
Más bien, intenta ocultar la intent y la exposición que no deberían hacerse públicas de antemano, manteniendo al mismo tiempo la verificación de la ejecución y auditorías reguladas.
Entiendo esa dirección.
Pero todavía no puedo decir que ya haya resuelto el problema.
Porque DuskEVM / Hedger todavía están en Testnet; y en la descripción oficial del obfuscated order book, sigue figurando como “próximo despliegue”.
Lo realmente importante es ver, una vez que salga, si este diseño sacrifica el descubrimiento de precios, la eficiencia del emparejamiento o la liquidez.
Así que mi postura actual sobre Hedger es muy sencilla:
Si la dirección es correcta, básicamente ya lo entiendo.
Lo demás, lo veremos cuando el mercado nos diga qué tan útil resulta en la práctica.
Antes hacía apalancamiento, y la situación que más me molestaba era esta:
Por último, la dirección era la correcta, pero a la persona la liquidaron primero.
Así que cuando vi por primera vez una estructura como @TermMax , donde se paga Premium primero y no hay una línea de liquidación tradicional, sí que se siente un poco más ligero.
Pero hoy, cuando miré esos contratos de HYPE que vencían el 21 de agosto, volví a quedarme atascado en otro problema.
Supongamos que yo creo que HYPE va a subir.
Al final, efectivamente subió.
Pero justo subió después de que venciera el contrato.
Para esta posición, entonces no sirve de nada.
La dirección estaba bien.
El tiempo estaba mal.
Así que ahora, cuando veo este tipo de estructura, ya no es tan fácil decir simplemente “como no hay liquidación, es cómodo”.
Antes solo me daba miedo que el mercado me barriera primero.
Ahora también tengo que adivinar otra cosa:
Si de verdad llega a tiempo.
El Premium se paga por adelantado, y la Maturity ya está fijada.
Que no exista una línea de liquidación tradicional no significa que el tiempo no sea importante.
A veces, lo más difícil no es adivinar si sube o baja.
Supongamos que, de repente, entra un pago en mi monedero.
En la cadena, otras personas no saben quién lo envió, no saben a quién se envió, y tampoco pueden ver el monto.
Suena a que la privacidad está al máximo.
Pero si yo fuera el destinatario, al descubrirlo encontraría:
Yo mismo tampoco sé quién envió ese dinero.
Entonces se vuelve un poco problemático.
¿Y si cobro por error?
¿Y si el origen del dinero no es correcto?
Si la contabilidad de la empresa me pregunta quién pagó esta cantidad, ¿yo respondo “no se puede comprobar”?
Así que estos días estuve mirando la Phoenix 2.0 de @Dusk ; lo que más me interesa no es cuánto puede ocultar.
Sino que no deja ciegas también a las dos partes de la transacción.
Phoenix hacia el exterior puede ocultar el sender, el receiver y el amount, pero el receiver aún puede confirmar el origen de los fondos.
Si este dinero necesita devolverse, el diseño también contempla el refund originator.
Esto ya no se parece tanto a lo que antes entendía por “transacciones anónimas”.
No se trata de buscar:
Que nadie sepa lo que pasó.
Más bien se parece a:
Que los transeúntes no necesiten saber de quién recibí el dinero;
pero como destinatario, yo sí debo saber de dónde viene.
Y cuando hay requisitos de auditoría o cumplimiento, también se puede usar viewing key / selective disclosure para gestionar la visibilidad.
Creo que esto es lo que más se parece al tipo de problemas que se encontrarían en las finanzas reales.
Al fin y al cabo, a la empresa no le preocupa realmente que “las dos partes sepan mutuamente quiénes son”.
Le preocupa que una transacción que en principio solo concierne a dos personas, termine siendo un registro permanente que todo el mundo pueda consultar.
Por eso, me gusta mucho el diseño de Phoenix 2.0:
La privacidad no consiste en dejar a todos con los ojos vendados.
Si no deberían mirar, con que no puedan ver basta.
Al principio, cuando investigaba la arquitectura de Dusk, tuve una pregunta bastante directa:
¿Por qué Dusk quiere montar tantas cosas como DuskDS, DuskEVM y Hedger? ¿No sería más sencillo meterlo todo en una sola cadena?
Luego revisé un poco la documentación y descubrí que estos tres nombres, en realidad, se pueden entender con tres frases.
DuskEVM: aquí es donde corre todo.
Solidity, EVM y esas aplicaciones principales se ejecutan en esta capa, así que los desarrolladores no tienen que aprender desde cero algo completamente ajeno solo para Dusk.
Hedger: qué cosas no deben mostrarse a todo el mundo.
Datos financieros como saldos, posiciones y montos de transacción, cuando se necesita confidencialidad, se gestionan en esta capa. No es que se “oculten” las transacciones, sino que no se permita que toda la información sensible quede expuesta.
DuskDS: al final, quién tiene la última palabra.
Los datos de las transacciones y el estado, en última instancia, deben asentarse en DuskDS, que se encarga del settlement a nivel base y de la disponibilidad de datos.
Con esa separación, de hecho me parece más razonable.
Pensemos en una empresa financiera: tampoco harían que el sistema de operaciones del “front” se encargue al mismo tiempo de permisos, base de datos, compensación y todo el trabajo de back-office. Lo que ve el usuario es un producto; debajo, en realidad, hay distintos sistemas haciendo cada uno lo suyo.
Dusk ahora también sigue un enfoque similar.
Que una aplicación pueda ejecutarse es una cosa, cómo tratar los datos sensibles es otra, y cómo se realiza el settlement final es otra más.
Por supuesto, ahora DuskEVM todavía está en fase de testnet, así que la arquitectura en el papel tiene sentido, pero no significa que al lanzarse en la mainnet vaya a funcionar sin problemas.
Pero al menos, ahora cuando veo “DuskEVM + Hedger + DuskDS”, no siento que sea solo una pila de tres nombres técnicos.
En realidad están resolviendo tres cosas diferentes.
Hoy vi el mercado de «tokenized stock» en @TermMax y mi primera reacción no fue «Fixed Rate», sino:
Si todos los activos bursátiles ya están tokenizados y en cadena, ¿por qué cuando necesitas dinero necesariamente tienes que vender primero?
Por ejemplo, si tienes tokenizado NVDA.
Si necesitas temporalmente una cantidad de USDT, lo más sencillo es venderlo.
Pero al vender, también se elimina la exposición al precio original de las acciones.
La otra vía que ofrece TermMax es:
Usar este tipo de activos bursátiles en cadena como garantía y sacar primero la liquidez en stablecoins.
Es decir, la exposición original a las acciones en cadena sigue existiendo; primero se completa la financiación.
En este punto, de hecho entiendo mejor por qué TermMax últimamente se está moviendo hacia la dirección de RWA.
Porque para activos que planeas mantener durante meses, o incluso más tiempo, que te puedan prestar dinero es solo la mitad.
La otra mitad es:
En los próximos meses, ¿cuánto de esos fondos se gastará realmente en costos de financiación?
Ahí es donde «Fixed Rate» encaja perfectamente.
Por supuesto, lo fijo es el costo del préstamo, no el precio del activo.
Si las acciones tienen que caer, caerán igualmente; y el riesgo de la garantía no desaparece solo porque la tasa esté fija. Si usas apalancamiento, el riesgo también se amplifica de la misma manera.
Pero considero que vale la pena seguir observando esta dirección.
Antes, cuando la gente hablaba de RWA, lo más común era hablar de cómo llevar acciones y bonos del Tesoro a la cadena.
Ahora me preocupa más el siguiente paso:
Que RWA en cadena sea solo el primer paso. Después de poder negociarse, ¿se puede financiar como un activo real?
Mi primera reacción seguramente es: ¿por qué tendría que pagar ese 1% extra?
Pero si cambio el escenario, lo entenderé.
Si planeo ejecutar una estrategia apalancada de 90 días, el rendimiento que calculo es del 10%; el costo del préstamo es del 4%, y hay un margen del 6% en medio.
Pero resulta que el día 20, el mercado de repente se precipita por liquidez y la tasa de los préstamos sube del 4% al 8%.
El activo no cae y la estrategia tampoco estaba equivocada, pero la ganancia que yo había calculado ya fue comida en gran parte por el costo de capital.
Entonces, mirando hacia atrás, ¿qué es exactamente ese 1% adicional del préstamo fijo al 5%?
Creo que se parece más a esto:
Estoy comprando con ese 1% una “certeza” sobre el costo de los fondos para los próximos 90 días.
Lo que realmente le está vendiendo al prestatario no es solo una tasa fija, sino que, en el momento de abrir la posición, tú ya sabes cuánto te costará realmente este dinero hasta el vencimiento.
Por supuesto, esto no significa que el riesgo desaparezca.
El colateral puede seguir cayendo; el apalancamiento puede seguir siendo liquidado; la estrategia puede seguir perdiendo.
TermMax fija el costo del préstamo, no el resultado de la inversión.
Así que no voy a decir simplemente que “la tasa fija es necesariamente mejor que la variable”.
La pregunta real debería ser:
Cuando el mercado empiece a volverse extremadamente volátil, ¿cuánto estás dispuesto a pagar para tener certeza sobre el costo futuro de los fondos?
Ese precio, quizá, es lo que el mercado de tasas fijas realmente está negociando.
Recientemente vi que @Dusk siempre enfatiza la “selective disclosure”; mi primera reacción fue:
Si al final los organismos reguladores todavía pueden verlo, ¿eso aún puede llamarse “Privacidad”?
Luego pensé: en realidad yo había mezclado “privacidad” con “que nadie lo vea”.
Como el saldo de mi banco: no se pega en la puerta del banco.
Que lo vea el vecino de al lado no es posible; tampoco otros clientes; y mucho menos los competidores.
Pero, bajo condiciones en que la ley y la autorización lo permiten, el banco, la auditoría o el sistema regulatorio aún pueden verificar la información correspondiente.
Entonces tú no dirías:
“Mi cuenta bancaria no tiene ninguna privacidad”.
La diferencia real es—
Quién tiene autorización para mirar.
Esa es la forma más simple en que ahora entiendo la “privacy programable” de Dusk.
No busca ocultar para siempre toda actividad financiera, sino una privacidad cuando hace falta y transparencia cuando es útil, y además, mediante selective disclosure, permitir que las entidades autorizadas realicen revisiones cuando sea necesario.
Esto puede parecer complejo para transferencias comunes de cripto, pero si en el futuro bonos, fondos y valores—esos activos regulados—realmente se suben a la cadena a gran escala, entonces creo que será una barrera con la que sí o sí habrá que lidiar.
Porque los dos extremos no son útiles:
Que todos puedan ver tu saldo, tu posición y las relaciones de tus transacciones, quizá las instituciones no se atrevan a usarlo;
Que nadie pueda verificarlo, y el marco regulatorio financiero sería difícil de sostener.
Así que ahora, en cambio, pienso que:
El verdadero “opuesto” de la privacidad financiera no necesariamente es “la regulación”.
Podría ser—
Las personas que no tienen nada que ver también poseen el derecho de ver tu información.
Si Dusk puede llevar realmente esos límites de permisos al flujo de trabajo financiero on-chain, la programmable privacy no sería solo una etiqueta bonita.
Mira @Dusk Hablando recientemente de Tokenización, hubo una frase que me hizo volver a pensar “la liquidez” de la RWA.
Supongamos que hay un activo con un valor de 1 millón de dólares.
Antes, solo una persona podía comprarlo.
Ahora, lo tokenizas, lo divides en 1 millón de partes y cada una cuesta solo 1 dólar.
Suena como si el umbral bajara de 1 millón a 1 dólar, y la liquidez debería dispararse, ¿verdad?
En realidad, no es así.
La propiedad fraccionada resuelve el problema de “si puedes pagarlo o no”.
La liquidez resuelve el problema de “si, cuando quieres vender, hay otra persona dispuesta a comprarte”.
Si divides un activo que nadie está negociando en 1 millón de partes, al final podrías terminar con 1 millón de partes más baratas, pero que siguen sin tener a nadie que las quiera.
Esa es también la razón por la que me parece tan importante el punto de vista de Dusk últimamente.
En un mercado financiero real en la cadena, además de la tokenización, se necesitan inversores elegibles, un lugar de negociación, pagos, descubrimiento de precios y el settlement final.
Entonces, al observar a Dusk y NPEX, y el planteamiento de Dusk Trade, la lógica se ve mucho más clara que la idea de “trasladar la RWA a la cadena”.
NPEX no aporta solo un logo, sino un mercado regulado y una base real de inversionistas; lo que Dusk Trade quiere resolver no es solo la exhibición del activo, sino el camino completo: desde la elegibilidad del inversor, pasando por el trading, la coordinación de pagos, hasta el settlement.
Así que ahora ya no creo mucho en:
“Fraccionamiento = Liquidez”.
Bajar el umbral, claro, tiene valor.
Pero lo que realmente determina si una RWA puede formar un mercado es esto: una vez que la puedes comprar, ¿también puedes venderla sin problemas?
La RWA lleva tanto tiempo sonando; ayer, de repente, me hice una pregunta bastante incómoda:
¿Cuántas RWA on-chain he comprado de verdad?
La respuesta es tristemente poca.
No es porque no haya activos en la cadena.
He mirado montones de productos relacionados con bonos, fondos y acciones a lo largo de estos años, pero cuando de verdad llega el momento de sacar la cartera, el problema aparece al instante:
¿Tengo derecho a comprar?
¿Dónde se compra?
Después de comprar, ¿cómo se realiza la entrega del dinero y de los activos?
Este token, ¿qué derechos representa exactamente?
Si en el futuro quiero salir, ¿a quién se lo vendo?
Tras investigar a Dusk Trade, el proyecto @Dusk , me di cuenta de que en el pasado yo siempre había considerado el paso más simple de RWA como el más difícil.
Convertir los activos en tokens, en realidad, es solo el comienzo.
Lo que Dusk Trade intenta conectar es toda esa larga lista de problemas que viene después:
descubrimiento de activos, onboarding y elegibilidad de inversores, carteras, trading, coordinación de pagos, y finalmente el settlement.
Suena menos sexy que “mover billones de activos a la cadena”, pero desde la perspectiva de un usuario que de verdad está listo para pagar, creo que estas cosas son aún más importantes.
Porque no me importa cuántos protocolos haya detrás.
Solo quiero que, después de abrir una puerta de entrada, pueda confirmar que sí puedo comprar, que la transacción realmente se completa, que el activo de verdad me pertenece, y que al final también pueda venderlo de forma real.
¿Por qué funcionan tan bien los brokers tradicionales?
No porque las acciones se hayan digitalizado.
Sino porque el usuario común ni siquiera alcanza a percibir cuántos sistemas existen detrás de cosas como la apertura de cuenta, el enrutamiento (matching), el registro, el pago y la liquidación.
Así que, ahora, mi mayor expectativa sobre Dusk Trade no es “añadir más RWA”.
Más bien es que algún día, al comprar bonos on-chain o fondos y otros activos, no tenga que aprender primero a ser, aunque sea, medio ingeniero blockchain.
La adopción real y a gran escala de la RWA quizá ocurra el día en que los usuarios por fin ya no tengan que preocuparse de si eso es o no RWA.
Hoy volví a casa y vi a un viejo amigo @Dusk , que volvió a sacar creadores. La primera vez que aparecieron en la lista dieron 2000 u de una; incluso si no entraron, solo por escribir un artículo te daban 30 u. De verdad me hace recordar cuando la economía iba bien. Hoy, después de ver esto, estuve observando #dusk .
Descubrí que, cuando antes miraba RWA, lo único que más me preocupaba era una cuestión: ¿realmente existe un activo tangible?
Últimamente he estado investigando el $DUSK de Dusk Trade, y de hecho me hizo darme cuenta de que estaba preguntando demasiado pronto.
Supongamos que mañana de verdad se sube a la cadena un bono o un ETF, ¿y luego qué?
¿Puedo comprarlo? ¿Quién confirma que tengo derecho a comprar? Después de la operación, ¿cuándo el activo realmente pasa a ser mío? ¿El dinero y el activo se liquidan al mismo tiempo? Si en el futuro quiero vender, ¿dónde encuentro liquidez?
Si estas preguntas no se resuelven, entonces hay un Token en la cadena que, para el inversor común, en realidad tiene un significado bastante limitado.
Por eso me parece interesante Dusk Trade.
No se trata simplemente de construir otro DEX para poder comprar RWA, sino de intentar meter activos financieros tokenizados como MMF, ETF, bonos, etc., dentro de un entorno de trading más completo: la elegibilidad de los inversores, la negociación de activos, la coordinación de pagos y el Settlement, todo lo posible, completado dentro del mismo conjunto de infraestructura.
Antes yo pensaba que la competencia en RWA era quién logra subir primero los activos a la cadena.
Ahora cada vez pienso más que subir los activos a la cadena solo te da el pase para entrar; lo verdaderamente difícil es traer “el mercado” con él.
Al fin y al cabo, en las finanzas reales, el hecho de emitir un activo nunca es el final.
Que alguien pueda comprar, que alguien pueda vender, que se pueda confirmar la identidad y la elegibilidad, y que después de la operación realmente se complete la transferencia de propiedad… esas cosas, unidas, es lo que se llama mercado.
Así que en adelante, cuando mire Dusk Trade, no me voy a fijar primero en cuántos activos puede listar.
Lo que quiero ver es: después de que entre la primera tanda de usuarios reales, desde la apertura de cuenta, la negociación y hasta el Settlement final, si de verdad puede funcionar como un ciclo cerrado completo.
Si esta cadena logra correr bien, creo que merece más atención que simplemente sumar algunas clases más de RWA.
#baby $BABY Estos días sigo revisando la información de TBV y me di cuenta de que antes había puesto el enfoque en el lugar equivocado.
Muchos están hablando de que BitVM3 reduce los costos y que la verificación es más rápida; claro que eso es algo bueno. Pero lo que más me importa es: ¿qué es exactamente lo que reemplaza?
Antes siempre pensaba que lo más importante de la descentralización es que “cualquiera pueda supervisar”. Ahora, para reducir el costo de las controversias, el mecanismo de desafíos de TBV está más orientado a que los desafíos se realicen con desafiadores predefinidos. La eficiencia, efectivamente, ha mejorado, pero también ha cambiado la manera de supervisar.
No digo que esto esté mal; en la vida real muchos protocolos hacen concesiones entre eficiencia y apertura. Lo que pasa es que, como usuario común, quiero saber esto: si en el futuro el tamaño de los fondos sigue creciendo, ¿los desafiadores serán lo suficientemente diversos? Si aparecen nodos desconectados o condiciones de mercado extremas, ¿podrán responder a tiempo?
Cada vez me convenzo más de que no se puede evaluar un protocolo solo mirando TPS, Gas o tasas de rendimiento.
Lo que realmente determina si puede funcionar durante mucho tiempo suelen ser esos detalles que casi nadie comenta: quién supervisa, si la supervisión tiene redundancia, y si existe un plan de respaldo cuando algo sale mal.
Por eso, en adelante seguiré prestando atención a @BabylonLabs_io . No solo para ver las mejoras de rendimiento que trae BitVM3, sino también para observar la ecología de los desafiadores, la transparencia de la gobernanza y si los límites de seguridad se siguen perfeccionando.
Las rupturas técnicas son algo que vale la pena esperar, pero si el modelo de seguridad puede resistir la prueba del tiempo, creo que es más importante que cualquier beneficio positivo a corto plazo.
Ayer, mientras organizaba una wallet fría, volví a encontrar aquella serie de BTC UTXO que llevaba años sin moverse.
Siempre he pensado que la mayor contradicción de Bitcoin no es la seguridad, sino tenerlo inmovilizado sin flujo de efectivo. Recientemente estuve investigando la testnet TBV de Babylon y descubrí que, en el mecanismo de redención, se reserva específicamente un período de desafío de tres días. Al principio me pareció demasiado lento, pero luego entendí que en realidad le está dando tiempo a la seguridad.
Como el BTC permanece bloqueado durante todo el proceso en un script de Taproot, no usa puentes entre cadenas y tampoco requiere empaquetar activos. Al momento de la redención, se necesita que el Vault Provider presente una prueba; si alguien falsifica la prueba, el retador aún puede detener la transacción durante esos tres días. Sin esa ventana, el atacante podría perfectamente pedir prestado stablecoins primero y huir antes de que el BTC se desbloquee de forma real.
Sin embargo, lo que de verdad me hace dudar no son esos tres días.
Actualmente, quienes se encargan del desafío todavía son solo una pequeña parte de nodos designados; los usuarios comunes casi nunca despliegan ellos mismos el programa de desafío. Es decir, en el momento clave aún tienes que confiar en que esos retadores se mantengan en línea y funcionen correctamente de forma continua. En la práctica, lo más realista es que los intereses del préstamo durante el período de redención no se detienen; si el mercado fluctúa de manera brusca, puede que para cuando el BTC vuelva, la posición ya haya sido liquidada.
Me parece bien el rumbo de Babylon de no usar puentes y no empaquetar, porque realmente es más mesurado que muchas propuestas de BTCFi. Pero una vez que el protocolo se implemente de verdad, si los retadores pueden estar suficientemente diversificados y si la respuesta es lo bastante rápida, creo que ahí está la clave para determinar la experiencia.
La rentabilidad puede atraer usuarios, pero lo que realmente los mantiene son esos detalles que siguen funcionando incluso en condiciones de mercado extremas.
En 2018, estudié un proyecto con un prestigio técnico muy alto. El trasfondo del equipo era prácticamente impecable. Sin embargo, tras el lanzamiento de la red principal, los problemas salieron a la luz muy pronto. El código en sí no tenía vulnerabilidades; el verdadero problema eran los mecanismos de incentivos: la recompensa que obtenían los nodos por la validación no alcanzaba para cubrir los costos operativos. Entonces comenzaron a ir saliendo gradualmente, y la seguridad de la red también fue disminuyendo. Esa experiencia me hizo comprender que, en muchos casos, los protocolos no terminan perdiendo por la tecnología, sino por el modelo económico.
Recientemente, al volver a investigar el mecanismo TBV de Babylon, también he seguido fijándome en este punto. Para que un nodo participe en el proceso de desafíos, tiene que mantenerse en línea de forma estable. Y mantener la conexión estable significa inversión continua en servidores, ancho de banda, operación y monitoreo. Si estos costos van acercándose cada vez más a los rendimientos del staking, a largo plazo es natural que algunos nodos decidan abandonar.
Para cualquier red PoS, si los nodos están dispuestos a seguir operando depende, en esencia, de tres cosas: el umbral de acceso, el riesgo de penalización y la rentabilidad. Entre estos elementos debe existir un margen de beneficios suficiente; si no, es difícil que el ecosistema de nodos mantenga su vitalidad a largo plazo. En la actualidad, Babylon describe más bien el diseño del mecanismo, pero sobre la medición de los rendimientos en distintos entornos de mercado, el modelo de costos y el punto de equilibrio de nodos—todavía hay datos públicos bastante limitados.
Hay otra cuestión que vale la pena observar de forma continua. Si en el futuro el rendimiento del staking de BABY se mantiene a largo plazo por encima de otras vías de rentabilidad de BTCFi, el capital de gran escala podría concentrarse aún más en unos pocos nodos grandes para buscar mayor eficiencia. Este es un desafío que muchos otros sistemas PoS han enfrentado en sus primeras etapas.
Estas discusiones no pretenden negar Babylon; más bien, sostienen que lo que realmente determina la competitividad a largo plazo de un protocolo no es solo si la solución técnica es avanzada, sino si los incentivos económicos pueden superar las pruebas del mercado real. En adelante, me centraré especialmente en la cantidad de nodos, la distribución de nodos y los cambios en la tasa de retorno, para evaluar si este modelo realmente se pone en marcha.
Recientemente hablé con amigos sobre el diseño de los reembolsos (redemptions) de Babylon para BTC, y una pregunta me hizo volver a leer el documento: de las tres opciones de reembolso, ¿quién es el que realmente decide si podrás o no usarlas?
Las opciones que ofrece oficialmente son Unbonding, Emergency Redemption e Instant Redemption. A primera vista, parece que el usuario tiene planes de liquidez distintos, pero al profundizar se descubre que no son decisiones completamente autónomas del usuario.
Por ejemplo, en el caso de Instant Redemption, el precio de intercambio no depende enteramente de las operaciones del mercado; también se ve afectado por el mecanismo de fijación de precios del protocolo. Emergency Redemption tampoco se activa automáticamente por cumplir una condición objetiva en la cadena; está condicionado por parámetros de gobernanza. Es decir, el usuario tiene distintos puntos de entrada para reembolsar, pero no controla por completo cuándo se abren esos puntos ni cuál es el coste.
Desde el ángulo de la seguridad de los activos, el BTC sigue bloqueado en scripts de Taproot y en UTXO; el modelo de custodia no ha cambiado. Pero desde el ángulo de la liquidez, lo que realmente determina la experiencia es el mecanismo encargado de interpretar el estado y calcular los parámetros.
Para un usuario común, la sensación quizá sea simplemente pagar unos cuantos puntos porcentuales más de coste al reembolsar. En cambio, para instituciones que necesitan gestionar la liquidez, esto implica incertidumbre tanto en el coste de reembolso como en el tiempo de recepción, afectando la planificación de fondos.
Por eso, no voy a asumir que el riesgo de liquidez ya se ha resuelto solo porque existan tres opciones de reembolso. Me interesan más algunos datos reales después del lanzamiento en la red principal:
* si el slippage real de Instant Redemption se estabiliza gradualmente; * cuántas confirmaciones de bloque se necesitan en Emergency Redemption, desde que se activa hasta que el BTC se desbloquea; * si, al modificar parámetros clave, la comunidad dispone de un periodo suficientemente largo de discusión pública y una ventana de oposición.
Solo cuando estos datos superen la prueba de un ciclo completo de mercado alcista y bajista, Babylon tendrá la oportunidad de actualizar el Bitcoin Staking de “cambiar el bloqueo a largo plazo por rendimientos” a una infraestructura de “reglas transparentes y liquidez predecible”.
Si fueras tú, ¿cómo lo elegirías?
A. Aceptar un periodo de desbloqueo más largo, buscando un rendimiento mayor. B. Pagar un coste por la liquidez y elegir el reembolso inmediato. C. Observar primero los datos reales de reembolso después del lanzamiento en mainnet y decidir si participar.