Lukukaku
792 Publicaciones
Lukukaku
225 Siguiendo
726 Seguidores
822 Me gusta
Publicaciones
Todo
Cotizaciones
Mi primera operación en Binance P2P y la más reciente podrían no haber dado más diferente, aunque los pasos implicados eran casi idénticos en el papel. La diferencia fue totalmente en cómo llegué preparado.
La primera vez, no revisé el estado de KYC del comerciante, no comparé las tasas de finalización y apenas leí los términos de la operación antes de confirmar. La operación salió bien, pero pasé todo el tiempo con ansiedad, sin estar seguro de si estaba haciendo algo mal, sin saber qué protecciones existían siquiera si salía mal. Binance P2P tenía todo eso disponible en todo momento: verificación de KYC, un bloqueo de depósito en garantía que mantenía el activo cripto de forma segura, un chat dentro de la app que registraba todo y una opción para apelar una disputa si era necesario. Simplemente no había buscado nada de eso ni comprendido cómo encajaban las piezas.
La operación reciente se veía completamente diferente porque ahora sigo un proceso constante. Reviso el estado de KYC y la tasa de finalización antes de abrir una orden. También comparo al menos dos perfiles de comerciantes antes de elegir uno, en lugar de aceptar la primera oferta que aparece, ya que una comparación rápida rara vez cuesta más de un minuto. Leo los términos completos de la operación, no solo el precio. Mantengo cada parte de la conversación dentro de la app, ya que ese registro importa si alguna vez surge una disputa. Confirmo que el pago realmente se acreditó en mi propia cuenta antes de liberar cualquier activo cripto, sin importar lo que afirme una captura de pantalla. Estoy atento a señales de alerta como urgencia o solicitudes para salir de la plataforma, y ya no ignoro una mala sensación solo porque todavía no hay nada concreto que la respalde. Ahora llevo un archivo sencillo de capturas de pantalla y números de orden para cada operación, y sé exactamente cómo contactar al soporte de Binance si alguna vez necesito una segunda opinión.
La mecánica de Binance P2P no cambió entre esas dos operaciones. Lo que sí cambió fue mi comprensión de cómo funcionan, y eso cambió todo sobre cómo se sentía el proceso.
@Binance Vietnam #BinanceP2PAnToan $TUT $BLUAI
La primera vez, no revisé el estado de KYC del comerciante, no comparé las tasas de finalización y apenas leí los términos de la operación antes de confirmar. La operación salió bien, pero pasé todo el tiempo con ansiedad, sin estar seguro de si estaba haciendo algo mal, sin saber qué protecciones existían siquiera si salía mal. Binance P2P tenía todo eso disponible en todo momento: verificación de KYC, un bloqueo de depósito en garantía que mantenía el activo cripto de forma segura, un chat dentro de la app que registraba todo y una opción para apelar una disputa si era necesario. Simplemente no había buscado nada de eso ni comprendido cómo encajaban las piezas.
La operación reciente se veía completamente diferente porque ahora sigo un proceso constante. Reviso el estado de KYC y la tasa de finalización antes de abrir una orden. También comparo al menos dos perfiles de comerciantes antes de elegir uno, en lugar de aceptar la primera oferta que aparece, ya que una comparación rápida rara vez cuesta más de un minuto. Leo los términos completos de la operación, no solo el precio. Mantengo cada parte de la conversación dentro de la app, ya que ese registro importa si alguna vez surge una disputa. Confirmo que el pago realmente se acreditó en mi propia cuenta antes de liberar cualquier activo cripto, sin importar lo que afirme una captura de pantalla. Estoy atento a señales de alerta como urgencia o solicitudes para salir de la plataforma, y ya no ignoro una mala sensación solo porque todavía no hay nada concreto que la respalde. Ahora llevo un archivo sencillo de capturas de pantalla y números de orden para cada operación, y sé exactamente cómo contactar al soporte de Binance si alguna vez necesito una segunda opinión.
La mecánica de Binance P2P no cambió entre esas dos operaciones. Lo que sí cambió fue mi comprensión de cómo funcionan, y eso cambió todo sobre cómo se sentía el proceso.
@Binance Vietnam #BinanceP2PAnToan $TUT $BLUAI
No todos los métodos de pago listados en Binance P2P conllevan el mismo nivel de riesgo, y me tomó algunas operaciones incómodas antes de empezar a prestar atención de verdad a cuál prefería un tercero.
Binance P2P permite que los vendedores elijan qué métodos de pago aceptan al publicar una oferta, y esa elección merece tomarse en serio en lugar de aceptar de todo solo para atraer a más compradores. Las transferencias bancarias dejan un registro claro y rastreable con nombres y números de referencia adjuntos, lo que encaja naturalmente con la verificación de identidad que Binance P2P ya exige a cada usuario. Los métodos que son más difíciles de rastrear o más fáciles de revertir les dan a los estafadores más margen para aprovechar la brecha entre un pago que parece enviado y un pago que realmente se acredita.
Reduje los métodos que acepto a transferencia bancaria únicamente después de una operación en la que un comprador usó un método que apenas reconocí, envió una prueba que parecía legítima y luego invirtió la transacción a través de su proveedor dos días después, cuando mi cripto ya se había entregado. Presenté una apelación con todo lo que tenía, pero para entonces el dinero ya había sido retirado por un canal que hacía la recuperación mucho más difícil de lo que debería.
Ahora, antes de aceptar cualquier pedido, confirmo que el método de pago exacto coincide con lo que especifica mi anuncio, verifico que el nombre del remitente coincide con su perfil verificado en Binance P2P y compruebo que los fondos se hayan acreditado genuinamente en mi propia cuenta, en lugar de simplemente aparecer como pendientes. Ninguna de estas medidas elimina el riesgo por completo, pero reducir los métodos que acepto reduce también la cantidad de formas en que alguien puede explotar la brecha entre lo enviado y lo acreditado.
Ese mismo día también presenté una apelación y guardé todas las capturas de pantalla del intercambio, incluido el método de pago usado y la prueba que se había enviado, ya que el soporte de Binance P2P necesitaba esos detalles específicos para entender qué tipo de reversión estaba describiendo.
Elegir con cuidado tus métodos de pago es una protección que tú controlas incluso antes de que una operación empiece, mucho antes de que entren en juego las insignias de verificación o el comportamiento en el chat.
@Binance Vietnam #BinanceP2PAnToan $TST $HFT
Binance P2P permite que los vendedores elijan qué métodos de pago aceptan al publicar una oferta, y esa elección merece tomarse en serio en lugar de aceptar de todo solo para atraer a más compradores. Las transferencias bancarias dejan un registro claro y rastreable con nombres y números de referencia adjuntos, lo que encaja naturalmente con la verificación de identidad que Binance P2P ya exige a cada usuario. Los métodos que son más difíciles de rastrear o más fáciles de revertir les dan a los estafadores más margen para aprovechar la brecha entre un pago que parece enviado y un pago que realmente se acredita.
Reduje los métodos que acepto a transferencia bancaria únicamente después de una operación en la que un comprador usó un método que apenas reconocí, envió una prueba que parecía legítima y luego invirtió la transacción a través de su proveedor dos días después, cuando mi cripto ya se había entregado. Presenté una apelación con todo lo que tenía, pero para entonces el dinero ya había sido retirado por un canal que hacía la recuperación mucho más difícil de lo que debería.
Ahora, antes de aceptar cualquier pedido, confirmo que el método de pago exacto coincide con lo que especifica mi anuncio, verifico que el nombre del remitente coincide con su perfil verificado en Binance P2P y compruebo que los fondos se hayan acreditado genuinamente en mi propia cuenta, en lugar de simplemente aparecer como pendientes. Ninguna de estas medidas elimina el riesgo por completo, pero reducir los métodos que acepto reduce también la cantidad de formas en que alguien puede explotar la brecha entre lo enviado y lo acreditado.
Ese mismo día también presenté una apelación y guardé todas las capturas de pantalla del intercambio, incluido el método de pago usado y la prueba que se había enviado, ya que el soporte de Binance P2P necesitaba esos detalles específicos para entender qué tipo de reversión estaba describiendo.
Elegir con cuidado tus métodos de pago es una protección que tú controlas incluso antes de que una operación empiece, mucho antes de que entren en juego las insignias de verificación o el comportamiento en el chat.
@Binance Vietnam #BinanceP2PAnToan $TST $HFT
Hago mi primera operación en Binance P2P con un nuevo contraparte de forma deliberadamente pequeña. Un pedido pequeño no elimina el riesgo, pero me permite aprender el flujo de pago, el momento y el estilo de comunicación sin confundir confianza con experiencia. Aun así, aplico la lista de verificación completa porque el fraude no se vuelve seguro por ser de menor monto.
Antes de ordenar, estudio la información de perfil disponible: actividad completada, señales de finalización, reseñas, historial de la cuenta o estado del comerciante cuando se muestra, límites de anuncios y condiciones. Evito seleccionar solo en función del precio. Para mí importa más una tasa razonable y unas instrucciones claras que una oferta que se vuelve atractiva únicamente si ignoro un historial breve o condiciones extrañas.
Una vez que se abre el pedido, lo mantengo completamente en Binance P2P. El KYC ayuda a identificar a ambos usuarios, el escrow retiene la cripto del vendedor, el chat del pedido guarda la conversación de la transacción y Appeal le da a Binance Support una vía de disputa. Rechazo solicitudes para cambiar el beneficiario, negociar un acuerdo paralelo, continuar después de la cancelación o mover el chat a otro lugar.
La identidad y la forma de pago forman mi siguiente barrera. Como comprador, envío el importe exacto desde una cuenta a mi nombre verificado a los detalles de pago mostrados en el pedido en vivo. Como vendedor, comparo el nombre del remitente con la identidad verificada del comprador, abro yo mismo mi banco o billetera y confirmo que el importe completo esté liquidado y disponible. Las capturas de pantalla y las alertas no autorizan la liberación.
Registro el número de pedido, el ID de la transacción, el monto, la marca de tiempo y el chat del pedido relevante hasta que la operación se resuelva. Si el nombre difiere, falta el pago, o la presión reemplaza respuestas claras, dejo la cripto en escrow y uso Appeal o el soporte oficial de Binance. No aumento el tamaño de la operación para recuperar tiempo o demostrar confianza.
Después de una finalización limpia, reviso qué salió realmente bien: los detalles coincidieron, el pago se liquidó y el rastro de la plataforma se mantuvo intacto. Solo la evidencia repetida puede justificar límites más grandes más adelante. Mi primer pedido no es un acto de confianza. Es una prueba controlada del proceso.
@Binance Vietnam #BinanceP2PAnToan $HFT
Antes de ordenar, estudio la información de perfil disponible: actividad completada, señales de finalización, reseñas, historial de la cuenta o estado del comerciante cuando se muestra, límites de anuncios y condiciones. Evito seleccionar solo en función del precio. Para mí importa más una tasa razonable y unas instrucciones claras que una oferta que se vuelve atractiva únicamente si ignoro un historial breve o condiciones extrañas.
Una vez que se abre el pedido, lo mantengo completamente en Binance P2P. El KYC ayuda a identificar a ambos usuarios, el escrow retiene la cripto del vendedor, el chat del pedido guarda la conversación de la transacción y Appeal le da a Binance Support una vía de disputa. Rechazo solicitudes para cambiar el beneficiario, negociar un acuerdo paralelo, continuar después de la cancelación o mover el chat a otro lugar.
La identidad y la forma de pago forman mi siguiente barrera. Como comprador, envío el importe exacto desde una cuenta a mi nombre verificado a los detalles de pago mostrados en el pedido en vivo. Como vendedor, comparo el nombre del remitente con la identidad verificada del comprador, abro yo mismo mi banco o billetera y confirmo que el importe completo esté liquidado y disponible. Las capturas de pantalla y las alertas no autorizan la liberación.
Registro el número de pedido, el ID de la transacción, el monto, la marca de tiempo y el chat del pedido relevante hasta que la operación se resuelva. Si el nombre difiere, falta el pago, o la presión reemplaza respuestas claras, dejo la cripto en escrow y uso Appeal o el soporte oficial de Binance. No aumento el tamaño de la operación para recuperar tiempo o demostrar confianza.
Después de una finalización limpia, reviso qué salió realmente bien: los detalles coincidieron, el pago se liquidó y el rastro de la plataforma se mantuvo intacto. Solo la evidencia repetida puede justificar límites más grandes más adelante. Mi primer pedido no es un acto de confianza. Es una prueba controlada del proceso.
@Binance Vietnam #BinanceP2PAnToan $HFT
"Trustless" es una de las palabras más usadas en exceso en cripto, y creo que las propias Trustless Bitcoin Vaults de Babylon son un buen estudio de caso sobre lo que la palabra debería significar frente a cómo normalmente se usa. Leer la documentación real del protocolo, en lugar del nombre por sí solo, cambia un poco la perspectiva.
TBV no elimina a todos los actores del sistema; elimina el tipo específico de actor que puede mover tu Bitcoin unilateralmente sin tu consentimiento. El sistema todavía tiene 3 tipos de participantes: Vault Providers que se encargan de la creación de la bóveda y de las reclamaciones, Arbitrageurs con derechos de canje autorizados que compran el colateral incautado durante las liquidaciones, y Universal Challengers que monitorean cada reclamación de canje como un respaldo a nivel de protocolo. Ninguno de ellos puede mover BTC fuera de las reglas codificadas en el script de Taproot, y cualquiera de ellos, incluido el depositante, puede bloquear una reclamación inválida durante la ventana de fraud-proof.
Esto es genuinamente distinto de la confianza custodia, donde una sola parte tiene control discrecional unilateral. Sin embargo, no es la ausencia completa de dependencia de otras personas que se presenten y actúen honestamente, que es lo que literalmente implica "trustless". La palabra más precisa es trust-minimized (confianza minimizada): redistribuye la confianza desde un único custodio discrecional hacia un conjunto definido de roles con restricciones criptográficas, varios de los cuales tienen incentivos financieros para detectar los errores de los demás.
No lo digo para menospreciar lo que Babylon construyó; distribuir y acotar la confianza con esta precisión es un logro de ingeniería real que la mayoría de los proyectos BTCFi no han igualado. Lo digo porque entender el modelo real, más que el atajo de marketing, es exactamente lo que determina si el préstamo nativo respaldado por Bitcoin merece la confianza que su nombre sugiere.
@BabylonLabs_io $GRVT $BABY #baby
TBV no elimina a todos los actores del sistema; elimina el tipo específico de actor que puede mover tu Bitcoin unilateralmente sin tu consentimiento. El sistema todavía tiene 3 tipos de participantes: Vault Providers que se encargan de la creación de la bóveda y de las reclamaciones, Arbitrageurs con derechos de canje autorizados que compran el colateral incautado durante las liquidaciones, y Universal Challengers que monitorean cada reclamación de canje como un respaldo a nivel de protocolo. Ninguno de ellos puede mover BTC fuera de las reglas codificadas en el script de Taproot, y cualquiera de ellos, incluido el depositante, puede bloquear una reclamación inválida durante la ventana de fraud-proof.
Esto es genuinamente distinto de la confianza custodia, donde una sola parte tiene control discrecional unilateral. Sin embargo, no es la ausencia completa de dependencia de otras personas que se presenten y actúen honestamente, que es lo que literalmente implica "trustless". La palabra más precisa es trust-minimized (confianza minimizada): redistribuye la confianza desde un único custodio discrecional hacia un conjunto definido de roles con restricciones criptográficas, varios de los cuales tienen incentivos financieros para detectar los errores de los demás.
No lo digo para menospreciar lo que Babylon construyó; distribuir y acotar la confianza con esta precisión es un logro de ingeniería real que la mayoría de los proyectos BTCFi no han igualado. Lo digo porque entender el modelo real, más que el atajo de marketing, es exactamente lo que determina si el préstamo nativo respaldado por Bitcoin merece la confianza que su nombre sugiere.
@BabylonLabs_io $GRVT $BABY #baby
El encuadre de David Tse para bóvedas de Bitcoin sin confianza es contundente: Bitcoin se mantiene en Bitcoin, gobernado por condiciones predefinidas que se verifican en lugar de confiar en ellas, sin intermediarios entre un titular y sus monedas. Esa es la propuesta completa en una sola frase, y del lado de la custodia, el diseño la respalda: BTC bloqueado en un UTXO de Taproot en todo momento.
Pero la forma más segura de usar TBV en la práctica pasa por una pieza de hardware específica. En marzo de 2026, Babylon se asoció con Ledger, cuyos monederos de hardware han vendido más de 8 millones de unidades, de modo que las transacciones de la bóveda puedan firmarse y confirmarse en el dispositivo usando Clear Signing, permitiendo a los usuarios leer detalles de transacciones en formato legible por humanos antes de aprobar cualquier cosa. Eso es realmente más seguro que aprobar ciegamente mediante una ventana emergente del navegador, y también significa que la ruta de seguridad recomendada para TBV depende de confiar en el firmware, la pantalla y la implementación de la firma de un solo fabricante de hardware.
Esto no es un custodio oculto: nadie en Ledger puede mover el BTC de un usuario sin el dispositivo físico y su aprobación. Sigue existiendo una dependencia, ya que un dispositivo comprometido o que funcione mal podría mostrar detalles de la transacción incorrectos para firmar, y el diseño sin confianza de Babylon no llega a garantizar que funcione correctamente ninguna pieza de hardware en particular.
Babylon eliminó al intermediario que podía mover Bitcoin sin pedirlo: custodios y puentes, y esa promesa se mantiene. No eliminó cada dependencia entre un usuario y un resultado correcto, ya que la ruta más segura para llegar a TBV sigue pasando por confiar en que un solo fabricante de hardware muestre la verdad en una pantalla pequeña.
@BabylonLabs_io $HYPER $BABY #baby
Pero la forma más segura de usar TBV en la práctica pasa por una pieza de hardware específica. En marzo de 2026, Babylon se asoció con Ledger, cuyos monederos de hardware han vendido más de 8 millones de unidades, de modo que las transacciones de la bóveda puedan firmarse y confirmarse en el dispositivo usando Clear Signing, permitiendo a los usuarios leer detalles de transacciones en formato legible por humanos antes de aprobar cualquier cosa. Eso es realmente más seguro que aprobar ciegamente mediante una ventana emergente del navegador, y también significa que la ruta de seguridad recomendada para TBV depende de confiar en el firmware, la pantalla y la implementación de la firma de un solo fabricante de hardware.
Esto no es un custodio oculto: nadie en Ledger puede mover el BTC de un usuario sin el dispositivo físico y su aprobación. Sigue existiendo una dependencia, ya que un dispositivo comprometido o que funcione mal podría mostrar detalles de la transacción incorrectos para firmar, y el diseño sin confianza de Babylon no llega a garantizar que funcione correctamente ninguna pieza de hardware en particular.
Babylon eliminó al intermediario que podía mover Bitcoin sin pedirlo: custodios y puentes, y esa promesa se mantiene. No eliminó cada dependencia entre un usuario y un resultado correcto, ya que la ruta más segura para llegar a TBV sigue pasando por confiar en que un solo fabricante de hardware muestre la verdad en una pantalla pequeña.
@BabylonLabs_io $HYPER $BABY #baby
Sin saltos de línea ni puentes, la línea “Babylon” se repite en casi cada pieza del marketing de Trustless Bitcoin Vaults, y no es una afirmación falsa. El Bitcoin depositado en una bóveda nunca se acuña en un token libremente negociable del modo en que lo hace WBTC, y tampoco se enruta a través de un puente de terceros.
Pero un contrato de préstamo o de perpetuos que se ejecuta en Ethereum no puede simplemente “ver” la cadena de Bitcoin y saber que existe una bóveda. Necesita algo contra lo cual comprobarlo. En el piloto de Morpho de Babylon de octubre de 2025, el contrato inteligente del lado de Ethereum verifica la bóveda BTC mediante un cliente ligero de Bitcoin antes de contar ese BTC como colateral, y la aserción subyacente de BitVM3 que hace esto posible aún publica alrededor de 56 kilobytes de datos on-chain. Un análisis externo sobre el diseño incluso compara el rastreador de colateral resultante con un token sintético usado solo para la contabilidad, distinto de un IOU transferible, pero aun así una representación que tiene que existir en algún lugar fuera de la cadena de Bitcoin para que todo esto funcione.
Esa representación no es un token envuelto que puedas enviar a un amigo o volcar en un exchange, y esa distinción es real. Pero que no exista “wrapping” en absoluto simplifica demasiado un sistema que aun así necesita alguna capa de contabilidad que conecte lo que prueba la cadena de Bitcoin y lo que pueden leer los contratos de Ethereum.
Babylon no está “envolviendo” bitcoin en el sentido de WBTC, aunque TBV sigue apoyándose en una representación más ligera y no transferible para que las dos cadenas puedan hablar entre sí.
@BabylonLabs_io $EPIC $BABY #baby
Pero un contrato de préstamo o de perpetuos que se ejecuta en Ethereum no puede simplemente “ver” la cadena de Bitcoin y saber que existe una bóveda. Necesita algo contra lo cual comprobarlo. En el piloto de Morpho de Babylon de octubre de 2025, el contrato inteligente del lado de Ethereum verifica la bóveda BTC mediante un cliente ligero de Bitcoin antes de contar ese BTC como colateral, y la aserción subyacente de BitVM3 que hace esto posible aún publica alrededor de 56 kilobytes de datos on-chain. Un análisis externo sobre el diseño incluso compara el rastreador de colateral resultante con un token sintético usado solo para la contabilidad, distinto de un IOU transferible, pero aun así una representación que tiene que existir en algún lugar fuera de la cadena de Bitcoin para que todo esto funcione.
Esa representación no es un token envuelto que puedas enviar a un amigo o volcar en un exchange, y esa distinción es real. Pero que no exista “wrapping” en absoluto simplifica demasiado un sistema que aun así necesita alguna capa de contabilidad que conecte lo que prueba la cadena de Bitcoin y lo que pueden leer los contratos de Ethereum.
Babylon no está “envolviendo” bitcoin en el sentido de WBTC, aunque TBV sigue apoyándose en una representación más ligera y no transferible para que las dos cadenas puedan hablar entre sí.
@BabylonLabs_io $EPIC $BABY #baby
Los precios de Aave para préstamos a través de la utilización, no a través de una llamada telefónica a un desk de riesgos que decide qué te mereces ese día. Creo que esa distinción está en el centro de por qué Babylon sigue describiendo el préstamo nativo respaldado por Bitcoin como eficiente en capital, y vale la pena desarmar el mecanismo en lugar de tomar la frase tal cual.
En el modelo de Aave, las tasas de interés sobre los activos prestados suben y bajan de forma algorítmica según cuánto de la liquidez disponible se está tomando prestada en ese momento. La alta utilización empuja las tasas hacia arriba para atraer más depositantes y enfriar la demanda de préstamos. La baja utilización empuja las tasas hacia abajo. Cada parte de esa curva es visible on-chain, y nadie en Babylon ni en Aave puede cambiar en silencio tu tasa específica detrás de escena como históricamente podían (y a veces hacían) los prestamistas de Bitcoin centralizados, justo antes de que algunos de ellos colapsaran por completo.
Los Trustless Bitcoin Vaults de Babylon alimentan el colateral nativo de BTC exactamente a este sistema de precios a través del Babylon Core Lending Spoke en Aave v4, que ya está activo en la testnet pública. Los depositantes publican Bitcoin, piden prestados activos respaldados como USDC o USDT, y la tasa que se aplica depende de la demanda real y visible del mercado por esa liquidez, en lugar de una decisión tomada sobre ellos personalmente.
Lo que la testnet aún no puede decirnos con certeza es cómo se comporta este mercado específico cuando el colateral real en Bitcoin nativo alcanza una escala significativa. Las curvas de utilización que parecen razonables con una actividad ligera en testnet pueden comportarse de manera muy diferente cuando realmente aparecen miles de millones de dólares en BTC nativo y una demanda real de endeudamiento. La eficiencia de capital sobre el papel y la eficiencia de capital bajo estrés real son dos afirmaciones distintas, y solo una de ellas se ha probado hasta ahora.
@BabylonLabs_io $GRVT $BABY #baby
En el modelo de Aave, las tasas de interés sobre los activos prestados suben y bajan de forma algorítmica según cuánto de la liquidez disponible se está tomando prestada en ese momento. La alta utilización empuja las tasas hacia arriba para atraer más depositantes y enfriar la demanda de préstamos. La baja utilización empuja las tasas hacia abajo. Cada parte de esa curva es visible on-chain, y nadie en Babylon ni en Aave puede cambiar en silencio tu tasa específica detrás de escena como históricamente podían (y a veces hacían) los prestamistas de Bitcoin centralizados, justo antes de que algunos de ellos colapsaran por completo.
Los Trustless Bitcoin Vaults de Babylon alimentan el colateral nativo de BTC exactamente a este sistema de precios a través del Babylon Core Lending Spoke en Aave v4, que ya está activo en la testnet pública. Los depositantes publican Bitcoin, piden prestados activos respaldados como USDC o USDT, y la tasa que se aplica depende de la demanda real y visible del mercado por esa liquidez, en lugar de una decisión tomada sobre ellos personalmente.
Lo que la testnet aún no puede decirnos con certeza es cómo se comporta este mercado específico cuando el colateral real en Bitcoin nativo alcanza una escala significativa. Las curvas de utilización que parecen razonables con una actividad ligera en testnet pueden comportarse de manera muy diferente cuando realmente aparecen miles de millones de dólares en BTC nativo y una demanda real de endeudamiento. La eficiencia de capital sobre el papel y la eficiencia de capital bajo estrés real son dos afirmaciones distintas, y solo una de ellas se ha probado hasta ahora.
@BabylonLabs_io $GRVT $BABY #baby
En diciembre de 2025, cuando Babylon y Aave anunciaron por primera vez que se estaban asociando, la información de la época describía que las pruebas comenzarían a principios de 2026, con la vista puesta en presentar el producto alrededor de abril. Ese es un objetivo público y específico, no un “algún día” vago.
Llegó abril y pasó sin un testnet público. El Temp Check llegó formalmente al foro de gobernanza de Aave el 25 de mayo, y el préstamo nativo respaldado por Bitcoin no se puso realmente en marcha en el testnet público hasta el 2 de junio, aproximadamente dos meses después de ese objetivo informal original. El propio equipo de Babylon describió después el arco completo de forma distinta, planteándolo como cuatro meses desde un importante avance de investigación hasta el testnet público; eso es cierto en sus propios términos, pero mide desde una línea de salida diferente a la fecha de abril que se reportó en diciembre.
Dos meses no es un escándalo en un proyecto que abarca criptografía novedosa, un foro de gobernanza y una cadena de revisión de seguridad con cinco firmas de auditoría involucradas. Pero sí es una brecha real y comprobable entre un calendario público temprano y lo que realmente se entregó, y vale la pena señalarlo con claridad en lugar de limitarse a repetir la versión de la historia que suena más rápida.
Babylon no es un proyecto que entregue exactamente en su cronograma informal más temprano, y esta integración es un ejemplo claro: no llegó en abril; aterrizó un par de meses después. Esto no menoscaba el logro de entregar infraestructura de testnet funcional, pero es una lectura más honesta que tratar cada hito como si llegara puntualmente.
@BabylonLabs_io $COTI $RIF $BABY #baby
Llegó abril y pasó sin un testnet público. El Temp Check llegó formalmente al foro de gobernanza de Aave el 25 de mayo, y el préstamo nativo respaldado por Bitcoin no se puso realmente en marcha en el testnet público hasta el 2 de junio, aproximadamente dos meses después de ese objetivo informal original. El propio equipo de Babylon describió después el arco completo de forma distinta, planteándolo como cuatro meses desde un importante avance de investigación hasta el testnet público; eso es cierto en sus propios términos, pero mide desde una línea de salida diferente a la fecha de abril que se reportó en diciembre.
Dos meses no es un escándalo en un proyecto que abarca criptografía novedosa, un foro de gobernanza y una cadena de revisión de seguridad con cinco firmas de auditoría involucradas. Pero sí es una brecha real y comprobable entre un calendario público temprano y lo que realmente se entregó, y vale la pena señalarlo con claridad en lugar de limitarse a repetir la versión de la historia que suena más rápida.
Babylon no es un proyecto que entregue exactamente en su cronograma informal más temprano, y esta integración es un ejemplo claro: no llegó en abril; aterrizó un par de meses después. Esto no menoscaba el logro de entregar infraestructura de testnet funcional, pero es una lectura más honesta que tratar cada hito como si llegara puntualmente.
@BabylonLabs_io $COTI $RIF $BABY #baby
"La primera solución de préstamo nativa y sin confianza para Bitcoin en el mercado" es una frase que o bien es completamente cierta o completamente exagerada, dependiendo totalmente de qué tan estrictamente acotes la palabra mercado. No creo que sea justo decir que es una u otra de forma plana.
Acotada específicamente a Aave, es precisa y merece crédito por ello. El propio equipo de Aave describe esto como BTC nativo proporcionado como colateral en su protocolo por primera vez, y eso es un hecho previo para el mayor protocolo de préstamos en DeFi por liquidez. Acotada a toda la categoría BTCFi, la afirmación se vuelve más difusa rápidamente. Un estudio reciente de la industria señaló que Babylon, Solv Protocol y Lombard Finance controlan aproximadamente el 85 por ciento de todo el BTC apostado en el sector; con Solv sola situándose cerca de 2.000 millones de dólares en TVL y Lombard en torno a 1,8 mil millones. Ambos ya operaban productos de Bitcoin sin confianza antes de este lanzamiento de préstamos en particular. "Primera" en préstamos específicamente, en Aave específicamente, convive con "uno de varios" cuando amplías la lente a la infraestructura de Bitcoin sin confianza en general.
Ninguna de las dos formulaciones es deshonesta. Solo están respondiendo preguntas diferentes, y el lector merece saber qué pregunta se está respondiendo antes de tomar "la primera en el mercado" como un hecho no cualificado.
Babylon es la primera a nivel Aave: nunca había respaldado un préstamo con BTC nativo allí antes. Babylon no es la primera a nivel de categoría: Solv y Lombard ya ejecutan productos sustanciales de Bitcoin minimizados en confianza. Acota la palabra first antes de repetirla como un hecho sin calificativos.
@BabylonLabs_io $COTI $RIF $BABY #baby
Acotada específicamente a Aave, es precisa y merece crédito por ello. El propio equipo de Aave describe esto como BTC nativo proporcionado como colateral en su protocolo por primera vez, y eso es un hecho previo para el mayor protocolo de préstamos en DeFi por liquidez. Acotada a toda la categoría BTCFi, la afirmación se vuelve más difusa rápidamente. Un estudio reciente de la industria señaló que Babylon, Solv Protocol y Lombard Finance controlan aproximadamente el 85 por ciento de todo el BTC apostado en el sector; con Solv sola situándose cerca de 2.000 millones de dólares en TVL y Lombard en torno a 1,8 mil millones. Ambos ya operaban productos de Bitcoin sin confianza antes de este lanzamiento de préstamos en particular. "Primera" en préstamos específicamente, en Aave específicamente, convive con "uno de varios" cuando amplías la lente a la infraestructura de Bitcoin sin confianza en general.
Ninguna de las dos formulaciones es deshonesta. Solo están respondiendo preguntas diferentes, y el lector merece saber qué pregunta se está respondiendo antes de tomar "la primera en el mercado" como un hecho no cualificado.
Babylon es la primera a nivel Aave: nunca había respaldado un préstamo con BTC nativo allí antes. Babylon no es la primera a nivel de categoría: Solv y Lombard ya ejecutan productos sustanciales de Bitcoin minimizados en confianza. Acota la palabra first antes de repetirla como un hecho sin calificativos.
@BabylonLabs_io $COTI $RIF $BABY #baby
Ver traducción
Across the entire BTCfi category, one recent industry report puts total value locked at roughly $7.39 billion spread over more than 68,500 BTC, with three protocols, Babylon, Solv, and Lombard, controlling about 85% of it between them. Babylon alone accounts for the largest single share, north of $4.79 billion, more than 47% of the whole category, well ahead of Solv's $1.96 billion and Lombard's $1.78 billion. Separate research puts Babylon's share of Bitcoin-specific staking TVL even higher, around 78%.
Read one way, that is a genuine moat: liquidity, integrations, and finality-provider infrastructure that took roughly two years and close to $95 million in funding to build, hard for a competitor to replicate quickly. Read the other way, it means the entire BTCfi narrative that crypto media points to as evidence Bitcoin can be productive capital is disproportionately a referendum on one protocol's uptime, tokenomics, and security choices. A serious incident at Babylon specifically would not just hurt Babylon, it would drag down the credibility of the whole category it currently defines.
Babylon's dominance is not simply a moat, and it is not simply fragility either, the data supports both readings depending on which lens you use. The category's growth and Babylon's own risk are no longer separable at this concentration level. Whether that changes as Solv and Lombard close the gap remains open.
@BabylonLabs_io $BABY #baby $BTW
Read one way, that is a genuine moat: liquidity, integrations, and finality-provider infrastructure that took roughly two years and close to $95 million in funding to build, hard for a competitor to replicate quickly. Read the other way, it means the entire BTCfi narrative that crypto media points to as evidence Bitcoin can be productive capital is disproportionately a referendum on one protocol's uptime, tokenomics, and security choices. A serious incident at Babylon specifically would not just hurt Babylon, it would drag down the credibility of the whole category it currently defines.
Babylon's dominance is not simply a moat, and it is not simply fragility either, the data supports both readings depending on which lens you use. The category's growth and Babylon's own risk are no longer separable at this concentration level. Whether that changes as Solv and Lombard close the gap remains open.
@BabylonLabs_io $BABY #baby $BTW
Las salidas tempranas basadas en límites de cupo normalmente se interpretan de una de dos maneras: o bien un pequeño grupo de iniciados se adelanta y se lleva la asignación rápido, y el resto es marketing, o bien aparece una demanda genuinamente amplia y sigue apareciendo a medida que se elevan los cupos. No está claro qué historia encaja con el despliegue de la Fase 1 de Babylon solo con el titular de que Cap-1 se llenó en 74 minutos.
Al observar lo que ocurrió después de ese primer cupo, se responde la pregunta. Cap-2 elevó el tope y atrajo aproximadamente 23.000 BTC para octubre de 2024, más de 20 veces el tamaño de la asignación total de Cap-1. Cap-3 avanzó aún más, llegando a unos 57.290 BTC para cuando la Fase-1 se cerró en diciembre de 2024, y el propio informe de Babylon sobre ese cupo final fijó el conteo de participantes en torno a 135.000, no en unos cuantos cientos de grandes billeteras dividiendo un número mayor. El total de BTC creció más de 50 veces desde el cierre de Cap-1 hasta el cierre de Cap-3, y los participantes distintos también crecieron junto con ello, en lugar de mantenerse planos.
La brecha que vale la pena mencionar está entre "un cupo que se llenó rápido" como titular y "una demanda amplia y sostenida" como patrón real: dos cosas que suenan parecido, pero no se garantiza que viajen juntas. Que el conteo de participantes suba a cifras de seis dígitos para Cap-3 es difícil de explicar como un círculo pequeño de iniciados que se mueve rápido, y sugiere que la rapidez inicial fue un síntoma de una demanda real que superaba la capacidad, más que de que la demanda en sí fuera estrecha.
La curva de demanda de Babylon no solo fue rápida al principio; se amplió: el conteo de participantes llegó a cifras de seis dígitos para cuando se cerró la Fase-1, en lugar de permanecer concentrada entre los iniciados tempranos. Esa es una señal distinta a la que sugiere solo un llenado rápido del cupo, aunque no dice nada con certeza sobre si esa misma amplitud se mantiene en las bóvedas.
@BabylonLabs_io $EUL $BABY #baby
Al observar lo que ocurrió después de ese primer cupo, se responde la pregunta. Cap-2 elevó el tope y atrajo aproximadamente 23.000 BTC para octubre de 2024, más de 20 veces el tamaño de la asignación total de Cap-1. Cap-3 avanzó aún más, llegando a unos 57.290 BTC para cuando la Fase-1 se cerró en diciembre de 2024, y el propio informe de Babylon sobre ese cupo final fijó el conteo de participantes en torno a 135.000, no en unos cuantos cientos de grandes billeteras dividiendo un número mayor. El total de BTC creció más de 50 veces desde el cierre de Cap-1 hasta el cierre de Cap-3, y los participantes distintos también crecieron junto con ello, en lugar de mantenerse planos.
La brecha que vale la pena mencionar está entre "un cupo que se llenó rápido" como titular y "una demanda amplia y sostenida" como patrón real: dos cosas que suenan parecido, pero no se garantiza que viajen juntas. Que el conteo de participantes suba a cifras de seis dígitos para Cap-3 es difícil de explicar como un círculo pequeño de iniciados que se mueve rápido, y sugiere que la rapidez inicial fue un síntoma de una demanda real que superaba la capacidad, más que de que la demanda en sí fuera estrecha.
La curva de demanda de Babylon no solo fue rápida al principio; se amplió: el conteo de participantes llegó a cifras de seis dígitos para cuando se cerró la Fase-1, en lugar de permanecer concentrada entre los iniciados tempranos. Esa es una señal distinta a la que sugiere solo un llenado rápido del cupo, aunque no dice nada con certeza sobre si esa misma amplitud se mantiene en las bóvedas.
@BabylonLabs_io $EUL $BABY #baby
La membresía de gimnasio de un amigo le permite cancelarla en cualquier momento, pero primero exige un aviso previo de 30 días. Se quejó de la fricción hasta que un mes lento le hizo sentir gratitud: el gimnasio no podía perder a la mitad de sus miembros de un día para otro por culpa de una mala semana.
Un apostador de Babylon que quiera salir antes de que venza su bloqueo original no puede simplemente retirar. Debe iniciar una solicitud de des-enganche anticipado, que establece un nuevo tiempo mínimo de bloqueo de al menos 1008 bloques de Bitcoin (aproximadamente siete días) y requiere la aprobación del Comité del Pacto antes de que se ejecute la transacción de des-enganche. Esa es la fricción que Babylon decidió incorporar deliberadamente, en lugar de permitir una salida instantánea. El razonamiento de diseño se conecta directamente con cómo Babylon Genesis mide su seguridad: la garantía de finalización del protocolo depende de conocer cuánto BTC está respaldando activamente la red en cada momento, y si los apostadores pudieran salir de manera instantánea e impredecible, el respaldo efectivo de seguridad de un bloque dado podría fluctuar sin avisar, socavando el umbral de firma del 66.66% del que depende la finalización. La ventana obligatoria de des-enganche y la validación del pacto le dan a la red una trayectoria de deslizamiento (glide path) predecible para la salida de capital del sistema, similar en espíritu a los períodos de des-enganche en cadenas PoS tradicionales, pero superpuesta al tiempo de liquidación propio de Bitcoin en lugar del reloj interno de un contrato inteligente. El costo recae por completo en el apostador individual: pierde aproximadamente una semana de liquidez y necesita la cooperación del comité para una acción que, en papel, solo involucra sus propios fondos y su propia firma.
La fricción de salida de Babylon no es un descuido: es un intercambio deliberado. Sacrifica la liquidez del apostador individual por la previsibilidad a nivel de toda la red sobre cuánta BTC realmente respalda la seguridad.
@BabylonLabs_io $RIF $BABY #baby
Un apostador de Babylon que quiera salir antes de que venza su bloqueo original no puede simplemente retirar. Debe iniciar una solicitud de des-enganche anticipado, que establece un nuevo tiempo mínimo de bloqueo de al menos 1008 bloques de Bitcoin (aproximadamente siete días) y requiere la aprobación del Comité del Pacto antes de que se ejecute la transacción de des-enganche. Esa es la fricción que Babylon decidió incorporar deliberadamente, en lugar de permitir una salida instantánea. El razonamiento de diseño se conecta directamente con cómo Babylon Genesis mide su seguridad: la garantía de finalización del protocolo depende de conocer cuánto BTC está respaldando activamente la red en cada momento, y si los apostadores pudieran salir de manera instantánea e impredecible, el respaldo efectivo de seguridad de un bloque dado podría fluctuar sin avisar, socavando el umbral de firma del 66.66% del que depende la finalización. La ventana obligatoria de des-enganche y la validación del pacto le dan a la red una trayectoria de deslizamiento (glide path) predecible para la salida de capital del sistema, similar en espíritu a los períodos de des-enganche en cadenas PoS tradicionales, pero superpuesta al tiempo de liquidación propio de Bitcoin en lugar del reloj interno de un contrato inteligente. El costo recae por completo en el apostador individual: pierde aproximadamente una semana de liquidez y necesita la cooperación del comité para una acción que, en papel, solo involucra sus propios fondos y su propia firma.
La fricción de salida de Babylon no es un descuido: es un intercambio deliberado. Sacrifica la liquidez del apostador individual por la previsibilidad a nivel de toda la red sobre cuánta BTC realmente respalda la seguridad.
@BabylonLabs_io $RIF $BABY #baby
Un consejo de administración de un condominio de un amigo recientemente exigió verificaciones de antecedentes antes de que cualquiera pudiera alquilar una unidad a corto plazo; una regla que molestó a los propietarios ocasionales, pero tranquilizó a los residentes que ya habían lidiado antes con un mal inquilino. La validación ralentiza la incorporación y, además, evita el problema exacto que la gente teme más.
El rol de proveedor de finalización de Babylon Genesis ahora incluye custodios institucionales como Hex Trust, a quienes los clientes delegan BTC para obtener recompensas de staking, mientras Hex Trust se encarga de las responsabilidades técnicas de votación de finalización en su nombre. Esta es una decisión deliberada de nivel de acceso: en lugar de exigir que cada cliente institucional ejecute por su cuenta la gestión de claves de EOTS y la infraestructura del demonio de finalización directamente, el diseño de Babylon permite que los custodios regulados absorban esa carga operativa y de seguridad como intermediarios. El intercambio es real. Delegar mediante un proveedor de finalización institucional concentra más BTC en staking y el peso de la votación en menos operadores, más grandes, en la dirección opuesta a la descentralización máxima; a cambio de una seguridad profesional de claves y de la gestión de cumplimiento que muchos asignadores institucionales requieren antes de que siquiera participen. Dado que todo el mecanismo de slashing depende de que el proveedor de finalización nunca firme doble, elegir un proveedor con disciplina operativa de nivel institucional es una decisión genuina de reducción de riesgos para el delegador, no solo una casilla de cumplimiento. Además, le da a Babylon una propuesta creíble para asignadores que nunca custodiarían las claves por sí mismos, pero delegarán en un nombre que ya confían desde las finanzas tradicionales.
Incorporar proveedores de finalización institucionales es un intercambio real de diseño. Babylon gana seguridad profesional de claves y capital institucional, y renuncia a parte de la descentralización máxima que ofrecería un conjunto de proveedores totalmente sin permisos.
@BabylonLabs_io $BABY #baby $RIF $BANK
El rol de proveedor de finalización de Babylon Genesis ahora incluye custodios institucionales como Hex Trust, a quienes los clientes delegan BTC para obtener recompensas de staking, mientras Hex Trust se encarga de las responsabilidades técnicas de votación de finalización en su nombre. Esta es una decisión deliberada de nivel de acceso: en lugar de exigir que cada cliente institucional ejecute por su cuenta la gestión de claves de EOTS y la infraestructura del demonio de finalización directamente, el diseño de Babylon permite que los custodios regulados absorban esa carga operativa y de seguridad como intermediarios. El intercambio es real. Delegar mediante un proveedor de finalización institucional concentra más BTC en staking y el peso de la votación en menos operadores, más grandes, en la dirección opuesta a la descentralización máxima; a cambio de una seguridad profesional de claves y de la gestión de cumplimiento que muchos asignadores institucionales requieren antes de que siquiera participen. Dado que todo el mecanismo de slashing depende de que el proveedor de finalización nunca firme doble, elegir un proveedor con disciplina operativa de nivel institucional es una decisión genuina de reducción de riesgos para el delegador, no solo una casilla de cumplimiento. Además, le da a Babylon una propuesta creíble para asignadores que nunca custodiarían las claves por sí mismos, pero delegarán en un nombre que ya confían desde las finanzas tradicionales.
Incorporar proveedores de finalización institucionales es un intercambio real de diseño. Babylon gana seguridad profesional de claves y capital institucional, y renuncia a parte de la descentralización máxima que ofrecería un conjunto de proveedores totalmente sin permisos.
@BabylonLabs_io $BABY #baby $RIF $BANK
Llamé a mi compañía de seguros después de un choque menor y me enviaron a una cola de tickets con una promesa de devolución de llamada que nunca llegó. Mi ferretería del barrio sigue teniendo una persona al teléfono cada vez que llamo por una válvula de riego rota. Misma década, apuesta completamente distinta por el soporte.
GRVT hizo su propia apuesta y se inclina más por el modelo de la compañía de seguros que por el de la ferretería. El soporte funciona principalmente mediante autoservicio y canales basados en tickets, en lugar de una línea telefónica en vivo. La primera parada para la mayoría de los usuarios es el Centro de Ayuda, que cubre configuración de la cuenta, trading, depósitos, retiros y temas de seguridad como artículos estáticos en vez de una persona a la que llamar. Para cualquier cosa específica de la cuenta o técnica, la resolución ocurre por correo electrónico y envíos de tickets, no en una cola en la que puedas esperar en tiempo real. El único canal con sensación “en vivo” es el chat de atención al cliente dentro de la app, disponible específicamente dentro de la aplicación móvil en lugar de en toda la plataforma. Esa estructura es deliberada, no un descuido, porque un exchange híbrido que liquida operaciones onchain y procesa un volumen diario significativo no puede, de forma realista, atender un escritorio telefónico 24 horas como lo haría una correduría tradicional; por eso el modelo desplaza el peso hacia documentación y tickets asincrónicos en vez de llamadas. Es un intercambio razonable para un equipo reducido, pero también es un intercambio real. Un trader en medio de una cascada de liquidación a las 3 a. m. con un retiro bloqueado está lidiando con una cola de tickets y un artículo de ayuda, no con una persona al otro lado de la llamada; y vale la pena conocer esa brecha entre un branding de nivel institucional y la capacidad de soporte de una startup antes de que se vuelva urgente.
GRVT no ofrece soporte telefónico en vivo; construyó su estructura de ayuda alrededor de artículos de autoservicio, tickets por correo electrónico y chat dentro de la app. Una elección escalable para un equipo reducido que, además, significa que los problemas urgentes de cuenta se resuelven en el tiempo del ticket, no en el tiempo de una llamada.
@grvt_io $GRVT #grvt $LAB $BEE
GRVT hizo su propia apuesta y se inclina más por el modelo de la compañía de seguros que por el de la ferretería. El soporte funciona principalmente mediante autoservicio y canales basados en tickets, en lugar de una línea telefónica en vivo. La primera parada para la mayoría de los usuarios es el Centro de Ayuda, que cubre configuración de la cuenta, trading, depósitos, retiros y temas de seguridad como artículos estáticos en vez de una persona a la que llamar. Para cualquier cosa específica de la cuenta o técnica, la resolución ocurre por correo electrónico y envíos de tickets, no en una cola en la que puedas esperar en tiempo real. El único canal con sensación “en vivo” es el chat de atención al cliente dentro de la app, disponible específicamente dentro de la aplicación móvil en lugar de en toda la plataforma. Esa estructura es deliberada, no un descuido, porque un exchange híbrido que liquida operaciones onchain y procesa un volumen diario significativo no puede, de forma realista, atender un escritorio telefónico 24 horas como lo haría una correduría tradicional; por eso el modelo desplaza el peso hacia documentación y tickets asincrónicos en vez de llamadas. Es un intercambio razonable para un equipo reducido, pero también es un intercambio real. Un trader en medio de una cascada de liquidación a las 3 a. m. con un retiro bloqueado está lidiando con una cola de tickets y un artículo de ayuda, no con una persona al otro lado de la llamada; y vale la pena conocer esa brecha entre un branding de nivel institucional y la capacidad de soporte de una startup antes de que se vuelva urgente.
GRVT no ofrece soporte telefónico en vivo; construyó su estructura de ayuda alrededor de artículos de autoservicio, tickets por correo electrónico y chat dentro de la app. Una elección escalable para un equipo reducido que, además, significa que los problemas urgentes de cuenta se resuelven en el tiempo del ticket, no en el tiempo de una llamada.
@grvt_io $GRVT #grvt $LAB $BEE
Una enfermera que conozco explicó por qué los hospitales ponen un límite a la velocidad con la que puedes solicitar una reposición, incluso para pacientes que la necesitan a menudo. Los límites de velocidad en las solicitudes no están ahí para frenar a la gente honesta: existen porque un solo actor malicioso que actúa rápido hace más daño que un millar de personas honestas moviéndose despacio.
Newton aplica ese mismo instinto a las actualizaciones de permisos y a la ejecución de intenciones. El protocolo limita la tasa y agrupa qué tan rápido pueden dispararse los cambios de permisos y las acciones iniciadas por agentes, específicamente para prevenir sobrecargas o manipulación, además de una participación descentralizada de validadores destinada a reducir las probabilidades de colusión. Encima de eso se sitúa un programa de recompensas por errores planificado: paga a investigadores para que descubran y divulguen vulnerabilidades antes de que se aprovechen en silencio, además de revisiones regulares del comportamiento de validadores y agentes en busca de anomalías que una auditoría única en el lanzamiento nunca detectaría.
Ninguna de estas cosas, por separado, suena emocionante. Los límites de tasa no son una función destacada, las recompensas por errores son una práctica estándar en la industria desde hace tiempo, no un diferenciador. Lo que resalta es la combinación de tratar la seguridad como una disciplina operativa continua, en lugar de como una lista de verificación de auditoría de una sola vez. Muchos protocolos publican un informe de auditoría y siguen adelante, tratando el PDF final como prueba de seguridad. El enfoque declarado por Newton asume que surgirán nuevos patrones de ataque después del lanzamiento, especialmente cuando los agentes autónomos empiecen a actuar de maneras que ningún auditor anticipó en una revisión estática del código.
Newton no está afirmando que los límites de tasa y las recompensas hagan que el sistema sea inquebrantable; está construyendo la infraestructura para detectar y responder a problemas de manera continua, una apuesta más discreta y menos comercializable que prometer seguridad perfecta desde el principio.
@NewtonProtocol $NEWT #Newt $PALU $VELVET
Newton aplica ese mismo instinto a las actualizaciones de permisos y a la ejecución de intenciones. El protocolo limita la tasa y agrupa qué tan rápido pueden dispararse los cambios de permisos y las acciones iniciadas por agentes, específicamente para prevenir sobrecargas o manipulación, además de una participación descentralizada de validadores destinada a reducir las probabilidades de colusión. Encima de eso se sitúa un programa de recompensas por errores planificado: paga a investigadores para que descubran y divulguen vulnerabilidades antes de que se aprovechen en silencio, además de revisiones regulares del comportamiento de validadores y agentes en busca de anomalías que una auditoría única en el lanzamiento nunca detectaría.
Ninguna de estas cosas, por separado, suena emocionante. Los límites de tasa no son una función destacada, las recompensas por errores son una práctica estándar en la industria desde hace tiempo, no un diferenciador. Lo que resalta es la combinación de tratar la seguridad como una disciplina operativa continua, en lugar de como una lista de verificación de auditoría de una sola vez. Muchos protocolos publican un informe de auditoría y siguen adelante, tratando el PDF final como prueba de seguridad. El enfoque declarado por Newton asume que surgirán nuevos patrones de ataque después del lanzamiento, especialmente cuando los agentes autónomos empiecen a actuar de maneras que ningún auditor anticipó en una revisión estática del código.
Newton no está afirmando que los límites de tasa y las recompensas hagan que el sistema sea inquebrantable; está construyendo la infraestructura para detectar y responder a problemas de manera continua, una apuesta más discreta y menos comercializable que prometer seguridad perfecta desde el principio.
@NewtonProtocol $NEWT #Newt $PALU $VELVET
Una startup de mi vecino se presentó como un proyecto improvisado de garaje, financiado por amigos y familiares. Años después descubrí que uno de esos primeros amigos gestionaba una family office para un fondo soberano del Golfo. La historia de “andar por casa” no era falsa; simplemente omitía quién, en realidad, estaba poniendo el dinero.
El estereotipo sobre un intercambio autoalojado (self-custodial) y sin KYC por defecto es que su capital proviene de rondas de base nativas de cripto, de cheques de ángeles y de creyentes del tipo grassroots, más que de dinero de las finanzas tradicionales. La historia de financiación de GRVT complica esa imagen. Para enero de 2025, la empresa había recaudado 14,3 millones de dólares en múltiples rondas, incluida una inversión estratégica de 5 millones de dólares por parte de Further Ventures, una firma respaldada por ADQ, el fondo soberano de Abu Dabi. Esa ronda estuvo junto a una posterior Serie A de 19 millones de dólares completada a finales de 2025, lo que empujó la financiación privada total por encima de los 33 millones, con patrocinadores que abarcan fondos de infraestructura cripto y firmas cuyo negocio principal es el propio trading. Un capital vinculado a fondos soberanos y dinero tradicional de venture capital detrás de una plataforma que se comercializa “prometiendo” eliminar el KYC y permitir que los usuarios negocien con solo un correo electrónico no es una contradicción exacta, pero sí complica la versión sencilla de la historia, donde los productos que se sienten “sin permisos” solo vendrían de capital que también se siente “sin permisos”. El dinero que financia un intercambio opcional de KYC se remonta, al menos en parte, a instituciones construidas enteramente en torno a flujos de capital verificados por identidad y fuertemente regulados; es la misma categoría de institución que la propia incorporación (onboarding) de la plataforma ya no exige a sus usuarios.
GRVT no es el proyecto grassroots, puramente nativo de cripto, que su branding sin KYC podría sugerir: detrás de ella hay, tanto como fondos nativos de cripto, capital de venture capital tradicional y capital vinculado a fondos soberanos.
@grvt_io $GRVT #grvt $DCR $XEC
El estereotipo sobre un intercambio autoalojado (self-custodial) y sin KYC por defecto es que su capital proviene de rondas de base nativas de cripto, de cheques de ángeles y de creyentes del tipo grassroots, más que de dinero de las finanzas tradicionales. La historia de financiación de GRVT complica esa imagen. Para enero de 2025, la empresa había recaudado 14,3 millones de dólares en múltiples rondas, incluida una inversión estratégica de 5 millones de dólares por parte de Further Ventures, una firma respaldada por ADQ, el fondo soberano de Abu Dabi. Esa ronda estuvo junto a una posterior Serie A de 19 millones de dólares completada a finales de 2025, lo que empujó la financiación privada total por encima de los 33 millones, con patrocinadores que abarcan fondos de infraestructura cripto y firmas cuyo negocio principal es el propio trading. Un capital vinculado a fondos soberanos y dinero tradicional de venture capital detrás de una plataforma que se comercializa “prometiendo” eliminar el KYC y permitir que los usuarios negocien con solo un correo electrónico no es una contradicción exacta, pero sí complica la versión sencilla de la historia, donde los productos que se sienten “sin permisos” solo vendrían de capital que también se siente “sin permisos”. El dinero que financia un intercambio opcional de KYC se remonta, al menos en parte, a instituciones construidas enteramente en torno a flujos de capital verificados por identidad y fuertemente regulados; es la misma categoría de institución que la propia incorporación (onboarding) de la plataforma ya no exige a sus usuarios.
GRVT no es el proyecto grassroots, puramente nativo de cripto, que su branding sin KYC podría sugerir: detrás de ella hay, tanto como fondos nativos de cripto, capital de venture capital tradicional y capital vinculado a fondos soberanos.
@grvt_io $GRVT #grvt $DCR $XEC
Un amigo que antes trabajaba en operaciones en tierra del aeropuerto me dijo que lo más difícil de su trabajo nunca fue mover un solo avión; fue decidir cuál de seis aviones esperando en el mismo callejón de rodaje debía salir primero cuando todos querían la pista a la vez. La equidad bajo controversia es un problema de planificación antes de ser cualquier otra cosa.
La hoja de ruta de Newton toma prestada una estructura de tarifa base más tarifa de prioridad, la misma forma que adoptó Ethereum bajo EIP-1559, para ordenar transacciones de automatización que compiten por ejecutarse en el mismo instante. Esa no es una elección neutral: es una apuesta específica sobre lo que debería significar la equidad cuando múltiples agentes quieren transaccionar al mismo tiempo. Un modelo de tarifa fija, al que la mayoría de herramientas con marca de cumplimiento recurren por defecto, trata cada transacción igual, independientemente de la urgencia; atiende primero llegado, primero servido, sin forma de indicar que una acción importa más ahora que otra.
Las subastas de gas con prioridad en Ethereum han producido problemas reales y bien documentados: bots que pagan de más para adelantarse entre sí, usuarios comunes que quedan fuera de precio durante picos de congestión, y herramientas de estimación de comisiones que adivinan mal en el peor momento posible. Ninguno de esos modos de fallo desaparece solo porque los postores en la cola de Newton sean agentes automatizados en lugar de personas haciendo clic en botones de intercambio.
Tomar prestada la forma de comisiones de Ethereum significa que los agentes pueden pagar una prima de prioridad para saltar la cola durante la contención, a costa de importar las dinámicas exactas de congestión y la volatilidad de comisiones que Ethereum ha pasado años intentando gestionar. Que esa historia se transfiera limpiamente a una red de automatización totalmente nueva, donde los actores que compiten por espacio en bloques son agentes en lugar de personas haciendo clic en botones de intercambio, es algo que genuinamente no se ha probado. Newton no inventó una respuesta nueva al ordenamiento de transacciones; importó una que ya tiene modos de fallo conocidos, apostando a que un sistema diseñado para traders humanos se comportará de forma predecible una vez que los postores sean agentes autónomos.
@NewtonProtocol $NEWT #Newt $DODO $AA
La hoja de ruta de Newton toma prestada una estructura de tarifa base más tarifa de prioridad, la misma forma que adoptó Ethereum bajo EIP-1559, para ordenar transacciones de automatización que compiten por ejecutarse en el mismo instante. Esa no es una elección neutral: es una apuesta específica sobre lo que debería significar la equidad cuando múltiples agentes quieren transaccionar al mismo tiempo. Un modelo de tarifa fija, al que la mayoría de herramientas con marca de cumplimiento recurren por defecto, trata cada transacción igual, independientemente de la urgencia; atiende primero llegado, primero servido, sin forma de indicar que una acción importa más ahora que otra.
Las subastas de gas con prioridad en Ethereum han producido problemas reales y bien documentados: bots que pagan de más para adelantarse entre sí, usuarios comunes que quedan fuera de precio durante picos de congestión, y herramientas de estimación de comisiones que adivinan mal en el peor momento posible. Ninguno de esos modos de fallo desaparece solo porque los postores en la cola de Newton sean agentes automatizados en lugar de personas haciendo clic en botones de intercambio.
Tomar prestada la forma de comisiones de Ethereum significa que los agentes pueden pagar una prima de prioridad para saltar la cola durante la contención, a costa de importar las dinámicas exactas de congestión y la volatilidad de comisiones que Ethereum ha pasado años intentando gestionar. Que esa historia se transfiera limpiamente a una red de automatización totalmente nueva, donde los actores que compiten por espacio en bloques son agentes en lugar de personas haciendo clic en botones de intercambio, es algo que genuinamente no se ha probado. Newton no inventó una respuesta nueva al ordenamiento de transacciones; importó una que ya tiene modos de fallo conocidos, apostando a que un sistema diseñado para traders humanos se comportará de forma predecible una vez que los postores sean agentes autónomos.
@NewtonProtocol $NEWT #Newt $DODO $AA
Hay dos formas de cruzar el río cerca de mi ciudad natal. Está el puente de peaje que el condado construyó y mantiene, más lento para obtener permisos para cambios, pero totalmente bajo el control del propio condado. Luego está un servicio de ferry privado que opera una empresa separada; es más rápido añadir un nuevo muelle o ruta porque no es infraestructura del condado, pero cada cruce depende de que esa empresa siga funcionando.
GRVT ejecuta dos rutas paralelas de depósito y retirada que se dividen aproximadamente de la misma manera. El GRVT Native Bridge cubre exactamente tres redes: Ethereum, Arbitrum One y BNB Smart Chain, moviendo USDT directamente mediante los contratos propios de GRVT. Por separado, el Multichain Bridge de GRVT, impulsado por un socio de puente de terceros, amplía el alcance hasta Solana, Tron, KAIA y Base sobre la misma base de redes, generando una dirección proxy única por cada depósito en lugar de enrutar a través del contrato del propio puente de GRVT. Los dos sistemas no son intercambiables técnicamente: el flujo habilitado por el socio solo admite USDT y USDC en formatos de red específicos como ARB, BEP20 y TRC20, y depositar un token o una red no compatible en ese flujo corre el riesgo de perder los fondos por completo, según la documentación de ayuda de GRVT sobre el tema. Ejecutar ambas rutas permite que GRVT admita muchas más cadenas de las que, razonablemente, podría mantener solo con su puente nativo, a cambio de hacer que parte de la experiencia de depósito dependa del tiempo de actividad de un socio en lugar de los contratos propios de GRVT.
GRVT no mueve fondos a través de un único puente unificado: opera una ruta directa, gestionada por GRVT, para un conjunto pequeño de redes principales, junto con una ruta más amplia gestionada por el socio para todo lo demás. Elegir qué puente usar no es solo una decisión de conveniencia; es elegir entre confiar en los contratos propios de GRVT o confiar en la infraestructura de una empresa separada.
@grvt_io $GRVT #grvt $T $BEE
GRVT ejecuta dos rutas paralelas de depósito y retirada que se dividen aproximadamente de la misma manera. El GRVT Native Bridge cubre exactamente tres redes: Ethereum, Arbitrum One y BNB Smart Chain, moviendo USDT directamente mediante los contratos propios de GRVT. Por separado, el Multichain Bridge de GRVT, impulsado por un socio de puente de terceros, amplía el alcance hasta Solana, Tron, KAIA y Base sobre la misma base de redes, generando una dirección proxy única por cada depósito en lugar de enrutar a través del contrato del propio puente de GRVT. Los dos sistemas no son intercambiables técnicamente: el flujo habilitado por el socio solo admite USDT y USDC en formatos de red específicos como ARB, BEP20 y TRC20, y depositar un token o una red no compatible en ese flujo corre el riesgo de perder los fondos por completo, según la documentación de ayuda de GRVT sobre el tema. Ejecutar ambas rutas permite que GRVT admita muchas más cadenas de las que, razonablemente, podría mantener solo con su puente nativo, a cambio de hacer que parte de la experiencia de depósito dependa del tiempo de actividad de un socio en lugar de los contratos propios de GRVT.
GRVT no mueve fondos a través de un único puente unificado: opera una ruta directa, gestionada por GRVT, para un conjunto pequeño de redes principales, junto con una ruta más amplia gestionada por el socio para todo lo demás. Elegir qué puente usar no es solo una decisión de conveniencia; es elegir entre confiar en los contratos propios de GRVT o confiar en la infraestructura de una empresa separada.
@grvt_io $GRVT #grvt $T $BEE
Inicia sesión para explorar más contenidos