Pham Kim 26
26 Publicaciones
Pham Kim 26
110 Siguiendo
19 Seguidores
21 Me gusta
Publicaciones
Durante mucho tiempo, “escrow” me sonó como una palabra de seguridad vaga para mí, algo que Binance P2P mencionaba sin que entendiera realmente qué hacía de forma mecánica. Una vez que por fin negocié lo suficiente como para verlo en acción, se convirtió en la parte del sistema en la que más confío.
Cuando un vendedor crea o acepta una orden en Binance P2P, el activo cripto que se vende no queda libre en su monedero durante la operación: se bloquea en escrow en el mismo instante en que se abre la orden. Ninguna de las dos partes puede acceder a él durante ese período. El comprador no puede recibirlo hasta que el vendedor lo libere manualmente, y el vendedor no puede retirarlo ni gastarlo en otro lugar mientras esté bloqueado. Ese único mecanismo es lo que hace que el resto del sistema funcione: un comprador puede enviar el pago con seguridad sabiendo que el vendedor, físicamente, no puede desaparecer llevándose tanto el pago como el activo cripto, y un vendedor puede esperar confirmación de pago con seguridad sin preocuparse de que el activo se mueva por sí solo. Combinado con la verificación de KYC, el chat dentro de la app y la opción de apelar una disputa, el escrow forma el núcleo estructural de por qué el trading en Binance P2P funciona con la seguridad con la que lo hace, siempre y cuando la operación ocurra completamente dentro de la plataforma.
Entender esto cambió cómo opero de varias maneras concretas. Dejé de preocuparme por si un vendedor podría huir con mi pago, porque el activo cripto permanece bloqueado independientemente. En cambio, pongo mi atención en las partes que el escrow no cubre: verificar el perfil de la contraparte antes de empezar, confirmar que el pago realmente se acreditó antes de esperar la liberación y estar atento a señales de alerta como una urgencia inusual. También llevo una nota simple del número de orden y la marca de tiempo de cada operación que completo, por si necesito consultar los detalles más adelante. Si alguna liberación alguna vez parece demorarse más allá de una ventana normal, me pongo en contacto con el soporte de Binance en lugar de asumir lo peor, ya que ellos pueden ver directamente el estado del escrow.
@Binance Vietnam #BinanceP2PAnToan
$TUT $BLUAI
Cuando un vendedor crea o acepta una orden en Binance P2P, el activo cripto que se vende no queda libre en su monedero durante la operación: se bloquea en escrow en el mismo instante en que se abre la orden. Ninguna de las dos partes puede acceder a él durante ese período. El comprador no puede recibirlo hasta que el vendedor lo libere manualmente, y el vendedor no puede retirarlo ni gastarlo en otro lugar mientras esté bloqueado. Ese único mecanismo es lo que hace que el resto del sistema funcione: un comprador puede enviar el pago con seguridad sabiendo que el vendedor, físicamente, no puede desaparecer llevándose tanto el pago como el activo cripto, y un vendedor puede esperar confirmación de pago con seguridad sin preocuparse de que el activo se mueva por sí solo. Combinado con la verificación de KYC, el chat dentro de la app y la opción de apelar una disputa, el escrow forma el núcleo estructural de por qué el trading en Binance P2P funciona con la seguridad con la que lo hace, siempre y cuando la operación ocurra completamente dentro de la plataforma.
Entender esto cambió cómo opero de varias maneras concretas. Dejé de preocuparme por si un vendedor podría huir con mi pago, porque el activo cripto permanece bloqueado independientemente. En cambio, pongo mi atención en las partes que el escrow no cubre: verificar el perfil de la contraparte antes de empezar, confirmar que el pago realmente se acreditó antes de esperar la liberación y estar atento a señales de alerta como una urgencia inusual. También llevo una nota simple del número de orden y la marca de tiempo de cada operación que completo, por si necesito consultar los detalles más adelante. Si alguna liberación alguna vez parece demorarse más allá de una ventana normal, me pongo en contacto con el soporte de Binance en lugar de asumir lo peor, ya que ellos pueden ver directamente el estado del escrow.
@Binance Vietnam #BinanceP2PAnToan
$TUT $BLUAI
"Accidentalmente te envié de más. ¿Puedes reembolsar la diferencia de inmediato?" Ese mensaje llegó cuatro minutos después de que empezara una operación en Binance P2P, y es uno de los intentos de estafa más ingeniosos con los que me he topado.
Así funciona el montaje. Un comprador envía una notificación de pago alegando un importe mayor que el que en realidad requería la orden y, después, le pide al vendedor que reembolse la parte pagada de más directamente mediante una transferencia por separado, presentándolo como algo urgente y embarazoso para él. El truco es que el pago original no llega o llega más tarde mediante un método reversible, mientras que el reembolso del vendedor sale inmediatamente con fondos reales. Si el vendedor se apresura a ser educado por el error, termina enviando dinero real mientras no recibe nada o recibe un pago que luego le reclaman.
Binance P2P realmente tiene un canal adecuado para esta situación exacta. Si un comprador paga de más de verdad, lo correcto es comentarlo por el chat oficial y resolver cualquier importe extra mediante una apelación si hace falta, nunca a través de un reembolso privado enviado fuera de la orden. Le dije al comprador esto de forma directa, revisé mi app bancaria y confirmé que todavía no había entrado ningún pago, y me negué a enviar nada de vuelta. Se puso impaciente, luego se quedó en silencio y, finalmente, la orden simplemente expiró.
Lo que hace efectiva esta artimaña en particular es lo razonable que suena. Nadie quiere parecer difícil por algo que parece un error honesto, y los estafadores se aprovechan de ese impulso de cortesía más que de cualquier truco técnico.
Mi regla desde ese día: cualquier solicitud que implique un reembolso, un segundo pago o mover dinero fuera de la orden se trata automáticamente como una señal de alerta, sin excepciones por lo educado o disculpándose que suene el mensaje. El sistema de depósito en garantía y apelación de Binance P2P existe precisamente para que los vendedores no tengan que tomar esa decisión solos bajo presión, y usarlos es mejor que intentar ser buena gente ante una solicitud sospechosa.
@Binance Vietnam #BinanceP2PAnToan
$ACE
Así funciona el montaje. Un comprador envía una notificación de pago alegando un importe mayor que el que en realidad requería la orden y, después, le pide al vendedor que reembolse la parte pagada de más directamente mediante una transferencia por separado, presentándolo como algo urgente y embarazoso para él. El truco es que el pago original no llega o llega más tarde mediante un método reversible, mientras que el reembolso del vendedor sale inmediatamente con fondos reales. Si el vendedor se apresura a ser educado por el error, termina enviando dinero real mientras no recibe nada o recibe un pago que luego le reclaman.
Binance P2P realmente tiene un canal adecuado para esta situación exacta. Si un comprador paga de más de verdad, lo correcto es comentarlo por el chat oficial y resolver cualquier importe extra mediante una apelación si hace falta, nunca a través de un reembolso privado enviado fuera de la orden. Le dije al comprador esto de forma directa, revisé mi app bancaria y confirmé que todavía no había entrado ningún pago, y me negué a enviar nada de vuelta. Se puso impaciente, luego se quedó en silencio y, finalmente, la orden simplemente expiró.
Lo que hace efectiva esta artimaña en particular es lo razonable que suena. Nadie quiere parecer difícil por algo que parece un error honesto, y los estafadores se aprovechan de ese impulso de cortesía más que de cualquier truco técnico.
Mi regla desde ese día: cualquier solicitud que implique un reembolso, un segundo pago o mover dinero fuera de la orden se trata automáticamente como una señal de alerta, sin excepciones por lo educado o disculpándose que suene el mensaje. El sistema de depósito en garantía y apelación de Binance P2P existe precisamente para que los vendedores no tengan que tomar esa decisión solos bajo presión, y usarlos es mejor que intentar ser buena gente ante una solicitud sospechosa.
@Binance Vietnam #BinanceP2PAnToan
$ACE
Considero que una orden de Binance P2P vencida o cancelada es un límite firme. Si el dinero se mueve después de ese límite, no vuelvo a recrear el trato anterior por acuerdo privado. El precio cotizado puede haber cambiado, el escrow puede ya no proteger la transferencia prevista y el plazo de la orden puede no respaldar la acción que la otra parte ahora quiere.
Como comprador, reviso el contador de la transferencia antes de enviar. Solo uso al beneficiario que se muestra en la orden activa, pago desde una cuenta que coincida con mi nombre verificado y marco el pago únicamente después de que realmente envió la cantidad exacta. Si la orden se cierra primero, no transfiero y le pido al vendedor que libere manualmente. Me pongo en contacto con el Soporte de Binance si ya ocurrió un pago tardío o duplicado.
Como vendedor, verifico el estado de la orden antes de liberar el cripto. Que el comprador diga "pagado" no reanima una operación cancelada. Abro mi banco o la app de pagos, identifico al remitente, verifico el monto y confirmo si los fondos están liquidados. Mantengo el cripto intacto mientras describo el problema de tiempos en el chat de órdenes de Binance o en el Soporte oficial. Nunca hago reembolsos a una cuenta nueva proporcionada en un mensaje apresurado, porque eso puede separar la devolución del pagador original.
Mi lista de señales de alerta incluye solicitudes para continuar en otro lugar, abrir una orden nueva pero contar un pago antiguo, aceptar un remitente de un tercero o liberar al precio vencido. Guardo el número de la orden anterior, las marcas de tiempo, el chat, el ID de transacción del pago y cualquier nuevo número de orden. Esos enlaces importan si se necesita una apelación o una revisión de Soporte.
KYC, escrow, chat y Apelación protegen una transacción definida dentro de la plataforma. No son una garantía general para acuerdos paralelos que se arman después de que una orden termina. Respeto el estado de la orden tanto como respeto el monto del pago. Mi secuencia es: orden activa, identidad coincidente, cuenta especificada, fondos liquidados, liberación confirmada. Si el reloj rompe esa secuencia, me detengo y dejo que Soporte de Binance indique el siguiente paso.
@Binance Vietnam #BinanceP2PAnToan
$BLESS
Como comprador, reviso el contador de la transferencia antes de enviar. Solo uso al beneficiario que se muestra en la orden activa, pago desde una cuenta que coincida con mi nombre verificado y marco el pago únicamente después de que realmente envió la cantidad exacta. Si la orden se cierra primero, no transfiero y le pido al vendedor que libere manualmente. Me pongo en contacto con el Soporte de Binance si ya ocurrió un pago tardío o duplicado.
Como vendedor, verifico el estado de la orden antes de liberar el cripto. Que el comprador diga "pagado" no reanima una operación cancelada. Abro mi banco o la app de pagos, identifico al remitente, verifico el monto y confirmo si los fondos están liquidados. Mantengo el cripto intacto mientras describo el problema de tiempos en el chat de órdenes de Binance o en el Soporte oficial. Nunca hago reembolsos a una cuenta nueva proporcionada en un mensaje apresurado, porque eso puede separar la devolución del pagador original.
Mi lista de señales de alerta incluye solicitudes para continuar en otro lugar, abrir una orden nueva pero contar un pago antiguo, aceptar un remitente de un tercero o liberar al precio vencido. Guardo el número de la orden anterior, las marcas de tiempo, el chat, el ID de transacción del pago y cualquier nuevo número de orden. Esos enlaces importan si se necesita una apelación o una revisión de Soporte.
KYC, escrow, chat y Apelación protegen una transacción definida dentro de la plataforma. No son una garantía general para acuerdos paralelos que se arman después de que una orden termina. Respeto el estado de la orden tanto como respeto el monto del pago. Mi secuencia es: orden activa, identidad coincidente, cuenta especificada, fondos liquidados, liberación confirmada. Si el reloj rompe esa secuencia, me detengo y dejo que Soporte de Binance indique el siguiente paso.
@Binance Vietnam #BinanceP2PAnToan
$BLESS
Di que el modelo de gobernanza de Babilonia es justo y razonable, y la gente asiente; di que es un desajuste estructural y la gente asiente también. Ambas reacciones responden a la misma elección de diseño real.
Los titulares de tokens BABY son quienes votan las propuestas de Babylon Genesis: la configuración estándar para una cadena de Cosmos SDK en la que el token nativo otorga derechos de gobernanza, consistente con cómo opera esencialmente cada cadena comparable en ese ecosistema. Los stakers de BTC, las personas que realmente bloquean miles de millones de dólares en Bitcoin para proporcionar la seguridad que Babylon vende a redes externas, no tienen una votación on-chain paralela mediante esa posición en BTC. Desde un punto de vista puramente arquitectónico, eso tiene sentido: los stakers de BTC interactúan con la propia cadena de Bitcoin, no con Babylon Genesis, así que canalizar la gobernanza a través del token nativo es el diseño convencional. Desde el punto de vista de los incentivos, se ve más extraño: el grupo que asume el riesgo real de slashing y el bloqueo de capital tiene menos voz formal que el grupo que mantiene un token que, a mediados de 2026, cotiza a una fracción pequeña del valor que, en conjunto, aportan los stakers de BTC.
La comunidad de Babylon claramente ha notado esa tensión por sí misma. Se ha planteado una propuesta de co-staking BTC-BABY específicamente para alinear incentivos entre ambos grupos de stakers y reducir la inflación, lo cual solo ocurre cuando ya existe una discrepancia viva sobre la división actual.
El diseño de gobernanza de Babylon es defendible, no obviamente correcto. Canalizar los votos a través de BABY coincide con la práctica estándar de Cosmos SDK, pero deja a los stakers de BTC, que aportan el capital de seguridad real de varios miles de millones de dólares, sin poder formal directo. Esa tensión es sugerida por la propia propuesta de co-staking del proyecto, la cual indica que tampoco está completamente resuelta internamente.
@BabylonLabs_io $BABY #baby
$BLESS
Los titulares de tokens BABY son quienes votan las propuestas de Babylon Genesis: la configuración estándar para una cadena de Cosmos SDK en la que el token nativo otorga derechos de gobernanza, consistente con cómo opera esencialmente cada cadena comparable en ese ecosistema. Los stakers de BTC, las personas que realmente bloquean miles de millones de dólares en Bitcoin para proporcionar la seguridad que Babylon vende a redes externas, no tienen una votación on-chain paralela mediante esa posición en BTC. Desde un punto de vista puramente arquitectónico, eso tiene sentido: los stakers de BTC interactúan con la propia cadena de Bitcoin, no con Babylon Genesis, así que canalizar la gobernanza a través del token nativo es el diseño convencional. Desde el punto de vista de los incentivos, se ve más extraño: el grupo que asume el riesgo real de slashing y el bloqueo de capital tiene menos voz formal que el grupo que mantiene un token que, a mediados de 2026, cotiza a una fracción pequeña del valor que, en conjunto, aportan los stakers de BTC.
La comunidad de Babylon claramente ha notado esa tensión por sí misma. Se ha planteado una propuesta de co-staking BTC-BABY específicamente para alinear incentivos entre ambos grupos de stakers y reducir la inflación, lo cual solo ocurre cuando ya existe una discrepancia viva sobre la división actual.
El diseño de gobernanza de Babylon es defendible, no obviamente correcto. Canalizar los votos a través de BABY coincide con la práctica estándar de Cosmos SDK, pero deja a los stakers de BTC, que aportan el capital de seguridad real de varios miles de millones de dólares, sin poder formal directo. Esa tensión es sugerida por la propia propuesta de co-staking del proyecto, la cual indica que tampoco está completamente resuelta internamente.
@BabylonLabs_io $BABY #baby
$BLESS
Los puentes que conectan Bitcoin con otra cadena suelen apoyarse en un grupo con permisos para detectar fraudes: un conjunto de observadores remunerados destinado a notar si alguien intenta reclamar BTC que no le corresponde. Ese grupo es, por sí mismo, una suposición de confianza. Además, el propio documento del vault de Babylon, publicado en agosto de 2025, señala que no existe una forma conocida de construir un puente totalmente sin confianza de Bitcoin con el lenguaje de scripting de Bitcoin tal como existe hoy, ya que Bitcoin todavía carece de opcodes de covenants como OP-CAT.
Los Bitcoin Vaults sin confianza sortean ese vacío de manera distinta. Las reclamaciones de redención y de liquidación en TBV se verifican mediante pruebas de conocimiento cero de lo que ocurrió en la cadena anfitriona, vinculadas a dos spokes dedicados de Aave v4: el Babylon Core Lending Spoke y el BTC Vault Swap Spoke. Cualquier reclamación que no incluya una prueba válida puede ser impugnada durante una ventana de prueba de fraude antes de que se liquide. El diseño de Babylon va más allá que el de la mayoría al asegurarse de que el depositante siempre sea elegible para actuar como su propio impugnador, de modo que defender BTC nunca requiere estrictamente que aparezca un observador separado y remunerado a tiempo.
Esa elección tiene un costo real. Permitir que los depositantes sirvan como su propia última línea de defensa significa que la seguridad depende en parte de que los usuarios realmente monitoreen las posiciones abiertas, en un sistema que solo ha existido en una testnet pública desde el 2 de junio de 2026: una carga mayor que hacer clic en aprobar una vez y marcharse.
Babylon no solo eliminó un comité de firmantes de TBV: también trasladó la tarea de detectar fraudes a la persona con más en juego, el depositante. Es un intercambio deliberado de conveniencia por pureza arquitectónica, y solo compensa a los usuarios que entienden qué están defendiendo.
@BabylonLabs_io $BABY #baby
$BLESS
Los Bitcoin Vaults sin confianza sortean ese vacío de manera distinta. Las reclamaciones de redención y de liquidación en TBV se verifican mediante pruebas de conocimiento cero de lo que ocurrió en la cadena anfitriona, vinculadas a dos spokes dedicados de Aave v4: el Babylon Core Lending Spoke y el BTC Vault Swap Spoke. Cualquier reclamación que no incluya una prueba válida puede ser impugnada durante una ventana de prueba de fraude antes de que se liquide. El diseño de Babylon va más allá que el de la mayoría al asegurarse de que el depositante siempre sea elegible para actuar como su propio impugnador, de modo que defender BTC nunca requiere estrictamente que aparezca un observador separado y remunerado a tiempo.
Esa elección tiene un costo real. Permitir que los depositantes sirvan como su propia última línea de defensa significa que la seguridad depende en parte de que los usuarios realmente monitoreen las posiciones abiertas, en un sistema que solo ha existido en una testnet pública desde el 2 de junio de 2026: una carga mayor que hacer clic en aprobar una vez y marcharse.
Babylon no solo eliminó un comité de firmantes de TBV: también trasladó la tarea de detectar fraudes a la persona con más en juego, el depositante. Es un intercambio deliberado de conveniencia por pureza arquitectónica, y solo compensa a los usuarios que entienden qué están defendiendo.
@BabylonLabs_io $BABY #baby
$BLESS
Ver traducción
Alpha season rồi các con vk ơi, Top gain toàn coin alpha thế này 🤣🤣🤣
$BLESS $memes
$BLESS $memes
He visto a personas usar LBTC, SolvBTC y Babylon indistintamente en la misma frase, como si fueran 3 nombres para un solo producto. Es un malentendido comprensible. Las 3 aparecen en las mismas conversaciones sobre BTCFi, las 3 se remontan a bitcoin apostado mediante el protocolo de Babylon, y las 3 se presentan como formas de hacer que el bitcoin ocioso sea productivo.
No son lo mismo, y la diferencia importa si te preocupa en qué estás confiando realmente. El LBTC de Lombard se acuña y canjea mediante un Security Consortium que incluye nodos institucionales como Galaxy y Wintermute, un grupo de partes en las que estás confiando para ejecutar ese proceso con honestidad. El SolvBTC de Solv se canaliza a través de su propia Staking Abstraction Layer, y el stBTC de Lorenzo se emite por Staking Agents designados responsables de apostar los fondos de los usuarios y de reportar las pruebas correspondientes. Cada uno de esos es una empresa distinta que superpone sus propias suposiciones de confianza sobre el protocolo base de staking de Babylon. Los Trustless Bitcoin Vaults (TBV) propios de Babylon son otra cosa totalmente: un primitivo de primera parte en el que el BTC permanece en una bóveda de custodia propia y pre-firmada, controlada mediante pruebas de conocimiento cero, sin que exista un consorcio ni un agente de staking que acuñe nada en tu nombre.
Babylon es la capa de liquidación y seguridad que está debajo de LBTC, SolvBTC y stBTC; no es un cambio de marca de ninguno de ellos, y TBV es el producto propio de Babylon que está junto a esos envoltorios más que dentro de ellos.
@BabylonLabs_io $BABY #baby
$WMTX
No son lo mismo, y la diferencia importa si te preocupa en qué estás confiando realmente. El LBTC de Lombard se acuña y canjea mediante un Security Consortium que incluye nodos institucionales como Galaxy y Wintermute, un grupo de partes en las que estás confiando para ejecutar ese proceso con honestidad. El SolvBTC de Solv se canaliza a través de su propia Staking Abstraction Layer, y el stBTC de Lorenzo se emite por Staking Agents designados responsables de apostar los fondos de los usuarios y de reportar las pruebas correspondientes. Cada uno de esos es una empresa distinta que superpone sus propias suposiciones de confianza sobre el protocolo base de staking de Babylon. Los Trustless Bitcoin Vaults (TBV) propios de Babylon son otra cosa totalmente: un primitivo de primera parte en el que el BTC permanece en una bóveda de custodia propia y pre-firmada, controlada mediante pruebas de conocimiento cero, sin que exista un consorcio ni un agente de staking que acuñe nada en tu nombre.
Babylon es la capa de liquidación y seguridad que está debajo de LBTC, SolvBTC y stBTC; no es un cambio de marca de ninguno de ellos, y TBV es el producto propio de Babylon que está junto a esos envoltorios más que dentro de ellos.
@BabylonLabs_io $BABY #baby
$WMTX
Los anuncios de financiación son las noticias cripto más fáciles de exagerar, así que intento leerlos por lo que señalan sobre la convicción, no como prueba por sí sola del éxito del producto. La tabla de cap de Babylon me da mucho que analizar.
La lista incluye Polychain Capital, Hack VC, Paradigm, Galaxy Digital y una inversión de 15 millones de dólares de a16z crypto específicamente, entre varios otros fondos. Es una nómina de inversores realmente profunda, que entiende la infraestructura cripto lo suficiente como para haber dicho que no a un montón de propuestas competitivas de Bitcoin DeFi. Apostar por un colateral nativo de BTC, entregado mediante Trustless Bitcoin Vaults y Aave v4 en lugar de un modelo envuelto o puenteado, fue una elección de tesis real entre varias alternativas.
Aun así, no permitiré que eso sustituya la evidencia de que el producto funciona para personas que no están recibiendo un pago por usarlo. La actividad en testnet ligada a campañas de incentivos te dice casi nada sobre la demanda orgánica, y cada protocolo que he observado a lo largo de los años ha tenido que demostrar que esa brecha se cierra después del mainnet, cuando los premios se agotan y solo el mecanismo en sí queda para justificar el uso.
La convicción de capital de inversores serios es una señal real sobre el equipo y la tesis. No es una señal sobre si un titular de Bitcoin, sin incentivos de campaña, elige Babylon en vez de simplemente mantener BTC y no hacer nada con ello. Ese segundo punto de prueba aún no ha ocurrido.
@BabylonLabs_io $BABY #baby
$GIGGLE
La lista incluye Polychain Capital, Hack VC, Paradigm, Galaxy Digital y una inversión de 15 millones de dólares de a16z crypto específicamente, entre varios otros fondos. Es una nómina de inversores realmente profunda, que entiende la infraestructura cripto lo suficiente como para haber dicho que no a un montón de propuestas competitivas de Bitcoin DeFi. Apostar por un colateral nativo de BTC, entregado mediante Trustless Bitcoin Vaults y Aave v4 en lugar de un modelo envuelto o puenteado, fue una elección de tesis real entre varias alternativas.
Aun así, no permitiré que eso sustituya la evidencia de que el producto funciona para personas que no están recibiendo un pago por usarlo. La actividad en testnet ligada a campañas de incentivos te dice casi nada sobre la demanda orgánica, y cada protocolo que he observado a lo largo de los años ha tenido que demostrar que esa brecha se cierra después del mainnet, cuando los premios se agotan y solo el mecanismo en sí queda para justificar el uso.
La convicción de capital de inversores serios es una señal real sobre el equipo y la tesis. No es una señal sobre si un titular de Bitcoin, sin incentivos de campaña, elige Babylon en vez de simplemente mantener BTC y no hacer nada con ello. Ese segundo punto de prueba aún no ha ocurrido.
@BabylonLabs_io $BABY #baby
$GIGGLE
Los poseedores minoristas de Bitcoin no eran la única audiencia en mente de Babylon cuando diseñó sus Trustless Bitcoin Vaults, y creo que esa parte de la historia está infravalorada. Babylon se está asociando con Utila, una plataforma de carteras MPC para instituciones que cuenta con la confianza de más de 300 instituciones, incluidas exchanges, custodios, fondos de cobertura y bancos, para llevar el préstamo nativo respaldado por Bitcoin con Aave v4 directamente a los clientes institucionales de Utila.
Ese detalle cambia la forma en que pienso sobre quién se mueve primero en esta tecnología. Los poseedores individuales valoran la autocustodia por razones filosóficas y prácticas, pero las instituciones tienen un conjunto completamente distinto, y a menudo más estricto, de requisitos en torno al riesgo de contraparte, las certificaciones de custodia y los controles operativos. Una institución que tiene una gran posición nativa en Bitcoin históricamente se ha enfrentado a una mala elección: mantenerla ociosa y sin rendimiento, o entregarla a un custodio y aceptar exposición a la contraparte solo para acceder a mercados de préstamos. El planteamiento de Babylon para plataformas como Utila es que el préstamo respaldado por BTC nativo elimina ese dilema sin que las instituciones renuncien al modelo de custodia operativa que ya confían.
El préstamo respaldado por Bitcoin nativo a través de los Trustless Bitcoin Vaults de Babylon ya está en funcionamiento en la testnet pública con Aave v4 hoy, y las integraciones institucionales como esta todavía se describen como “llegando en los próximos meses” en lugar de estar activas ahora. Ese espacio entre el anuncio y el flujo institucional en vivo es algo que vale la pena observar con atención.
Sigo preguntándome si las instituciones realmente desplegarán un tamaño significativo en un sistema que aún está en etapa de testnet y que todavía espera la aprobación de la gobernanza de Aave en los parámetros de riesgo finales, o si esto se convierte en un volumen real solo una vez que se active el mainnet. Los anuncios son baratos. El capital institucional que aparece es la señal real.
@BabylonLabs_io $BABY #baby
$COTI
Ese detalle cambia la forma en que pienso sobre quién se mueve primero en esta tecnología. Los poseedores individuales valoran la autocustodia por razones filosóficas y prácticas, pero las instituciones tienen un conjunto completamente distinto, y a menudo más estricto, de requisitos en torno al riesgo de contraparte, las certificaciones de custodia y los controles operativos. Una institución que tiene una gran posición nativa en Bitcoin históricamente se ha enfrentado a una mala elección: mantenerla ociosa y sin rendimiento, o entregarla a un custodio y aceptar exposición a la contraparte solo para acceder a mercados de préstamos. El planteamiento de Babylon para plataformas como Utila es que el préstamo respaldado por BTC nativo elimina ese dilema sin que las instituciones renuncien al modelo de custodia operativa que ya confían.
El préstamo respaldado por Bitcoin nativo a través de los Trustless Bitcoin Vaults de Babylon ya está en funcionamiento en la testnet pública con Aave v4 hoy, y las integraciones institucionales como esta todavía se describen como “llegando en los próximos meses” en lugar de estar activas ahora. Ese espacio entre el anuncio y el flujo institucional en vivo es algo que vale la pena observar con atención.
Sigo preguntándome si las instituciones realmente desplegarán un tamaño significativo en un sistema que aún está en etapa de testnet y que todavía espera la aprobación de la gobernanza de Aave en los parámetros de riesgo finales, o si esto se convierte en un volumen real solo una vez que se active el mainnet. Los anuncios son baratos. El capital institucional que aparece es la señal real.
@BabylonLabs_io $BABY #baby
$COTI
Una liquidación en Bitcoin tiene un problema de tiempos que no existe en las liquidaciones en Ethereum. El reembolso nativo de BTC desde una bóveda sigue el ritmo de liquidación propio de Bitcoin, y no hay manera de hacerlo más rápido sin entregar a alguien el control custodial de las monedas, lo cual acabaría por derrotar el propósito completo del diseño desde el principio.
Babylon y la respuesta de Aave consiste en desacoplar los dos eventos. Cuando una bóveda se liquida, se intercambia por WBTC de inmediato, de modo que la posición del prestamista se liquida al instante según el calendario de Ethereum. El reembolso real de BTC nativo ocurre entonces por separado, en el calendario propio de Bitcoin, sin bloquear la resolución del préstamo para nadie más en el mercado. También hay un segundo beneficio incluido aquí. Aave actualmente mantiene cerca de 5 mil millones de dólares en suministro de WBTC que Babylon ha descrito como infrautilizado en el lado de los préstamos; así que canalizar la liquidación a través de eso también hace que parte de ese WBTC inactivo vuelva a ponerse a trabajar.
La alternativa sería obligar a que cada liquidación espere la confirmación de Bitcoin nativo y la lógica propia del reembolso de la bóveda antes de que cualquier prestamista vea resolución alguna. Es más puro a nivel filosófico, cero activos envueltos tocados en cualquier punto, pero significa que las liquidaciones avanzan al ritmo de Bitcoin justo en el momento en que la rapidez es lo que protege a un prestamista de pérdidas adicionales.
Babylon no es sin envolturas de punta a punta: es sin envolturas en el camino que la mayoría de los usuarios realmente tomará. En la fase de liquidación en particular, Babylon eligió la velocidad para el prestamista por encima de la pureza para la salida del prestatario: un intercambio defendible, pero al fin y al cabo un intercambio.
@BabylonLabs_io $BABY #baby
$BANK
Babylon y la respuesta de Aave consiste en desacoplar los dos eventos. Cuando una bóveda se liquida, se intercambia por WBTC de inmediato, de modo que la posición del prestamista se liquida al instante según el calendario de Ethereum. El reembolso real de BTC nativo ocurre entonces por separado, en el calendario propio de Bitcoin, sin bloquear la resolución del préstamo para nadie más en el mercado. También hay un segundo beneficio incluido aquí. Aave actualmente mantiene cerca de 5 mil millones de dólares en suministro de WBTC que Babylon ha descrito como infrautilizado en el lado de los préstamos; así que canalizar la liquidación a través de eso también hace que parte de ese WBTC inactivo vuelva a ponerse a trabajar.
La alternativa sería obligar a que cada liquidación espere la confirmación de Bitcoin nativo y la lógica propia del reembolso de la bóveda antes de que cualquier prestamista vea resolución alguna. Es más puro a nivel filosófico, cero activos envueltos tocados en cualquier punto, pero significa que las liquidaciones avanzan al ritmo de Bitcoin justo en el momento en que la rapidez es lo que protege a un prestamista de pérdidas adicionales.
Babylon no es sin envolturas de punta a punta: es sin envolturas en el camino que la mayoría de los usuarios realmente tomará. En la fase de liquidación en particular, Babylon eligió la velocidad para el prestamista por encima de la pureza para la salida del prestatario: un intercambio defendible, pero al fin y al cabo un intercambio.
@BabylonLabs_io $BABY #baby
$BANK
Di "Bitcoin plus DeFi" a la mayoría de los nativos cripto y su cerebro salta directamente a un puente o una sidechain. Envuelve tu moneda, envíala a través, confía en un conjunto de validadores o en un multisig al otro lado, y espera que el propio puente nunca se convierta en el titular por la razón equivocada. Años de exploits en puentes entrenaron ese reflejo por una buena razón.
Los Trustless Bitcoin Vaults se agrupan constantemente en ese mismo cajón mental, y ese cajón es el equivocado. El diseño de Babylon no mueve BTC fuera de la red de Bitcoin en absoluto: la moneda se bloquea en un Taproot UTXO bajo condiciones impuestas por script y permanece ahí durante todo el ciclo de préstamo, con Ethereum solo viendo una prueba criptográfica de ese estado bloqueado a través de un light client, en lugar de custodia del activo en sí. No hay una cadena de ejecución separada que mantenga una reserva de BTC puenteados como requeriría un modelo de sidechain. Luego, la arquitectura de spoke de Aave v4 encamina el préstamo contra esa prueba, no contra un token puenteado que esté en la reserva de alguien.
Llamarlo "solo otro puente" no capta la diferencia real de ingeniería y, sinceramente, subestima el problema más difícil que Babylon eligió resolver. Los puentes mueven valor. Esto mueve la prueba de valor mientras la moneda permanece exactamente donde empezó.
Babylon no es un puente de Bitcoin ni una sidechain con nueva marca. Con este diseño, la moneda nunca sale de la red de Bitcoin. Lo que cruza a Ethereum es una prueba de estado bloqueado, no el activo en sí, y esa distinción es la razón completa por la que el riesgo de custodia tipo puente no aplica aquí como sí ocurre en otros lugares.
@BabylonLabs_io $BABY #baby
$DEXE $BANK
Los Trustless Bitcoin Vaults se agrupan constantemente en ese mismo cajón mental, y ese cajón es el equivocado. El diseño de Babylon no mueve BTC fuera de la red de Bitcoin en absoluto: la moneda se bloquea en un Taproot UTXO bajo condiciones impuestas por script y permanece ahí durante todo el ciclo de préstamo, con Ethereum solo viendo una prueba criptográfica de ese estado bloqueado a través de un light client, en lugar de custodia del activo en sí. No hay una cadena de ejecución separada que mantenga una reserva de BTC puenteados como requeriría un modelo de sidechain. Luego, la arquitectura de spoke de Aave v4 encamina el préstamo contra esa prueba, no contra un token puenteado que esté en la reserva de alguien.
Llamarlo "solo otro puente" no capta la diferencia real de ingeniería y, sinceramente, subestima el problema más difícil que Babylon eligió resolver. Los puentes mueven valor. Esto mueve la prueba de valor mientras la moneda permanece exactamente donde empezó.
Babylon no es un puente de Bitcoin ni una sidechain con nueva marca. Con este diseño, la moneda nunca sale de la red de Bitcoin. Lo que cruza a Ethereum es una prueba de estado bloqueado, no el activo en sí, y esa distinción es la razón completa por la que el riesgo de custodia tipo puente no aplica aquí como sí ocurre en otros lugares.
@BabylonLabs_io $BABY #baby
$DEXE $BANK
Babylon comercializa su protocolo de staking bajo la premisa de que no existe custodia por terceros: ninguna empresa tiene tu BTC, ningún operador de puente que pueda desaparecer con los fondos. El comité del pacto queda un poco incómodo junto a esa propuesta. Se trata de un grupo de múltiples firmas de partes externas, cuyas firmas son legalmente necesarias para que una transacción de desinscripción o de slashing sea válida, una estructura M-de-N aplicada directamente dentro del script de Bitcoin. En la documentación de su propia red de testnet, ese comité tenía 9 miembros en total, y 3 de esos 9 asientos, una tercera parte completa, fueron operados por la propia Babylon Foundation.
Una parte que tú no elegiste, con una participación significativa del poder de firma necesario para mover tus fondos a través de una ruta aprobada, es una forma de exposición a contrapartes, incluso si es más limitada que una custodia que tenga tus llaves de manera directa. El blog de la propia fundación de Babylon reconoce esto de forma directa, describiendo que el supuesto de confianza detrás de este tipo de comité se reduce a la honestidad existencial: basta con que exista un firmante honesto, en lugar de que el problema quede eliminado de raíz, y propone covenants criptoeconómicos que puedan ser sancionados como la solución definitiva.
Babylon no ha logrado la confianza cero con terceros que implica su planteamiento sin custodia, al menos todavía: el comité del pacto es una dependencia real y la Foundation está incluida dentro de él. Lo que ha construido es una dependencia más acotada que la de un custodio, con su propio plan para reducirla aún más. Son dos afirmaciones distintas, y solo una es completamente cierta hoy.
@BabylonLabs_io $BABY #baby
$LAB
Una parte que tú no elegiste, con una participación significativa del poder de firma necesario para mover tus fondos a través de una ruta aprobada, es una forma de exposición a contrapartes, incluso si es más limitada que una custodia que tenga tus llaves de manera directa. El blog de la propia fundación de Babylon reconoce esto de forma directa, describiendo que el supuesto de confianza detrás de este tipo de comité se reduce a la honestidad existencial: basta con que exista un firmante honesto, en lugar de que el problema quede eliminado de raíz, y propone covenants criptoeconómicos que puedan ser sancionados como la solución definitiva.
Babylon no ha logrado la confianza cero con terceros que implica su planteamiento sin custodia, al menos todavía: el comité del pacto es una dependencia real y la Foundation está incluida dentro de él. Lo que ha construido es una dependencia más acotada que la de un custodio, con su propio plan para reducirla aún más. Son dos afirmaciones distintas, y solo una es completamente cierta hoy.
@BabylonLabs_io $BABY #baby
$LAB
Ver traducción
Most proof of stake chains anchor security to a single asset. Validators stake the native token, misbehavior gets punished by slashing that same token, and the system's economic weight rests on one number: how much of that token is locked up.
Babylon Genesis runs two separate security tracks at once. CometBFT validators secure the chain through BABY delegation while a completely different set of participants, finality providers, secure it through Bitcoin delegation, and both tracks can be slashed independently if their participants misbehave. The chain funds both sides from the same well: BABY carries 8% annual inflation, split exactly in half, with 4% flowing to BABY stakers and the other 4% to Bitcoin stakers, an even split rather than one side subsidizing the other. Registering a stake even runs through a Cosmos SDK transaction that consumes BABY purely as gas, since BABY itself was never issued as an ERC-20.
The decision to run two tracks instead of one is a bet that Bitcoin's economic weight and BABY's economic weight are both necessary and neither is sufficient alone. Anchoring only to BABY would leave crypto-economic security tied to a young, thinly traded token; anchoring only to Bitcoin delegation would leave consensus without a token whose holders are incentivized to govern the chain itself.
Babylon doesn't pick between Bitcoin's security or BABY's incentive alignment, it funds both at once with an evenly split inflation reward. That reveals a team unwilling to bet the chain's entire security budget on one asset, even when one of those two assets is worth vastly more than the other.
@BabylonLabs_io $BABY #baby
$PIEVERSE
Babylon Genesis runs two separate security tracks at once. CometBFT validators secure the chain through BABY delegation while a completely different set of participants, finality providers, secure it through Bitcoin delegation, and both tracks can be slashed independently if their participants misbehave. The chain funds both sides from the same well: BABY carries 8% annual inflation, split exactly in half, with 4% flowing to BABY stakers and the other 4% to Bitcoin stakers, an even split rather than one side subsidizing the other. Registering a stake even runs through a Cosmos SDK transaction that consumes BABY purely as gas, since BABY itself was never issued as an ERC-20.
The decision to run two tracks instead of one is a bet that Bitcoin's economic weight and BABY's economic weight are both necessary and neither is sufficient alone. Anchoring only to BABY would leave crypto-economic security tied to a young, thinly traded token; anchoring only to Bitcoin delegation would leave consensus without a token whose holders are incentivized to govern the chain itself.
Babylon doesn't pick between Bitcoin's security or BABY's incentive alignment, it funds both at once with an evenly split inflation reward. That reveals a team unwilling to bet the chain's entire security budget on one asset, even when one of those two assets is worth vastly more than the other.
@BabylonLabs_io $BABY #baby
$PIEVERSE
Ver traducción
I assumed my grandfather would never manage a smartphone banking app, he'd spent sixty years writing checks by hand. Then I watched him check his balance mid conversation without looking down. I had underestimated what an old system could adapt to, and Bitcoin gets underestimated the same way.
The common assumption is that Bitcoin, lacking Ethereum-style smart contracts, simply can't serve as native DeFi collateral without being wrapped into a token on another chain first, a workaround that's produced billions in exploits over the years because it usually means trusting a custodian somewhere.
Babylon's vaults were built specifically to challenge that assumption. BTC gets locked in a UTXO governed by preset cryptographic rules and pre-signed transactions, and unlocking it requires submitting a zero-knowledge proof rather than a custodian's signature. That locked, native Bitcoin then functions as collateral for lending or stablecoin issuance on external chains including Ethereum and Cosmos, without a wrapped token ever being minted. The entire mechanism runs on Bitcoin as it exists right now, no new opcodes, no soft fork required to make any of this possible.
Bitcoin's scripting language genuinely is more limited than Ethereum's. That limitation shaped how Babylon had to build this, favoring pre-signed transaction paths and off-chain proof verification over the flexible, always-on-chain logic Ethereum allows. Limited isn't the same as incapable, and the vault design is evidence the constraint can be engineered around rather than only bypassed with a wrapper.
Bitcoin doesn't need to become Ethereum to participate in DeFi collateral, it just needed a different architecture, and Babylon's vaults show what that looks like.
@BabylonLabs_io $BABY #baby
$DEXE
The common assumption is that Bitcoin, lacking Ethereum-style smart contracts, simply can't serve as native DeFi collateral without being wrapped into a token on another chain first, a workaround that's produced billions in exploits over the years because it usually means trusting a custodian somewhere.
Babylon's vaults were built specifically to challenge that assumption. BTC gets locked in a UTXO governed by preset cryptographic rules and pre-signed transactions, and unlocking it requires submitting a zero-knowledge proof rather than a custodian's signature. That locked, native Bitcoin then functions as collateral for lending or stablecoin issuance on external chains including Ethereum and Cosmos, without a wrapped token ever being minted. The entire mechanism runs on Bitcoin as it exists right now, no new opcodes, no soft fork required to make any of this possible.
Bitcoin's scripting language genuinely is more limited than Ethereum's. That limitation shaped how Babylon had to build this, favoring pre-signed transaction paths and off-chain proof verification over the flexible, always-on-chain logic Ethereum allows. Limited isn't the same as incapable, and the vault design is evidence the constraint can be engineered around rather than only bypassed with a wrapper.
Bitcoin doesn't need to become Ethereum to participate in DeFi collateral, it just needed a different architecture, and Babylon's vaults show what that looks like.
@BabylonLabs_io $BABY #baby
$DEXE
Un casero al que le alquilé en una ocasión no dejaba de aumentar el número total de unidades del edificio convirtiendo cuartos de almacenamiento en estudios; técnicamente más oferta, técnicamente más ingresos, y técnicamente diluyendo qué tan especial se sentía cualquier unidad en particular para vivir en ella. El crecimiento y la dilución aparecieron en la misma remodelación.
BABY no tiene un suministro máximo fijo; los rastreadores de tokenomics describen su calendario de liberación como algo que se extiende indefinidamente, en vez de estar acotado a un número final como hacen los 21 millones de Bitcoin. La asignación inicial planificada cubre 10 mil millones de tokens entre las categorías de inversionistas, equipo, ecosistema, I+D y comunidad, pero la emisión continua más allá de ese punto de referencia no está limitada por el diseño del protocolo de la misma forma tan estricta. Los defensores lo presentan como algo necesario: para mantener un conjunto de validadores que crece y un proveedor de finalidades, además de incentivos comunitarios a largo plazo, hace falta un flujo de tokens sostenido en lugar de una asignación única que se agota. Los críticos señalan el mismo mecanismo como una presión estructural de venta: ya circulan aproximadamente 3.99 mil millones de BABY y cada mes entra más mediante el vesting y la emisión futura, diluyendo la participación de los tenedores existentes en la red independientemente del crecimiento del uso. Ambas lecturas se basan en el mismo hecho: un suministro sin tope, en expansión continua, que alimenta un token de gobernanza y gas cuyo valor depende en parte de la escasez y en parte de que la demanda de utilidad vaya al ritmo de las nuevas emisiones. El historial de precios de BABY aporta contexto: un máximo en abril de 2025 cerca de $0.1661 seguido por una caída de aproximadamente 93% hasta $0.0107 en marzo de 2026 muestra que el mercado ya está incorporando alguna versión de este debate sobre la dilución.
Ninguno de los dos casos —el de crecimiento ni el de dilución— gana completamente aquí. Un suministro infinito puede financiar un ecosistema que madura o, en silencio, erosionar el valor para los tenedores; y qué resultado ocurra depende del crecimiento de la demanda que Babylon no puede garantizar por sí sola.
@BabylonLabs_io $BABY #baby
$DEXE
BABY no tiene un suministro máximo fijo; los rastreadores de tokenomics describen su calendario de liberación como algo que se extiende indefinidamente, en vez de estar acotado a un número final como hacen los 21 millones de Bitcoin. La asignación inicial planificada cubre 10 mil millones de tokens entre las categorías de inversionistas, equipo, ecosistema, I+D y comunidad, pero la emisión continua más allá de ese punto de referencia no está limitada por el diseño del protocolo de la misma forma tan estricta. Los defensores lo presentan como algo necesario: para mantener un conjunto de validadores que crece y un proveedor de finalidades, además de incentivos comunitarios a largo plazo, hace falta un flujo de tokens sostenido en lugar de una asignación única que se agota. Los críticos señalan el mismo mecanismo como una presión estructural de venta: ya circulan aproximadamente 3.99 mil millones de BABY y cada mes entra más mediante el vesting y la emisión futura, diluyendo la participación de los tenedores existentes en la red independientemente del crecimiento del uso. Ambas lecturas se basan en el mismo hecho: un suministro sin tope, en expansión continua, que alimenta un token de gobernanza y gas cuyo valor depende en parte de la escasez y en parte de que la demanda de utilidad vaya al ritmo de las nuevas emisiones. El historial de precios de BABY aporta contexto: un máximo en abril de 2025 cerca de $0.1661 seguido por una caída de aproximadamente 93% hasta $0.0107 en marzo de 2026 muestra que el mercado ya está incorporando alguna versión de este debate sobre la dilución.
Ninguno de los dos casos —el de crecimiento ni el de dilución— gana completamente aquí. Un suministro infinito puede financiar un ecosistema que madura o, en silencio, erosionar el valor para los tenedores; y qué resultado ocurra depende del crecimiento de la demanda que Babylon no puede garantizar por sí sola.
@BabylonLabs_io $BABY #baby
$DEXE
Un amigo mío es un médico titulado con licencia en su país de origen, pero el hospital donde ahora trabaja publica un descargo de responsabilidad que indica que su licencia de casa no tiene validez legal local. Es la misma persona, el mismo título, y sin embargo que aquí sea "un médico con licencia" depende por completo de qué reglamento del país consultes.
GRVT presenta una división similar. En diciembre de 2024 obtuvo una Licencia de Negocio de Activos Digitales Modificada de Clase M de la Autoridad Monetaria de Bermudas, que la empresa y la mayor parte de la cobertura describen como lo que la convierte en la primera bolsa mundial de derivados onchain regulada. Esa credencial se repite constantemente en el marketing y en las reseñas. Mientras tanto, la entidad operativa detrás de la aplicación, GRVT Technologies Pte Ltd, tiene su sede en Singapur, y el propio listado de la tienda de aplicaciones de la plataforma incluye un descargo de responsabilidad directo para ese mercado: GRVT no está licenciada, aprobada, autorizada, designada, reconocida, registrada ni de otro modo regulada bajo ninguna legislación administrada por la Autoridad Monetaria de Singapur, y los usuarios allí no reciben ninguna de las salvaguardas regulatorias que normalmente proporcionaría la supervisión de la MAS. Así que la respuesta honesta a "¿GRVT está regulada?" se divide según la jurisdicción, en lugar de resolverse en una sola palabra. Bermudas, sí, bajo una categoría de licencia modificada. Singapur, explícitamente no, según las propias palabras de la empresa. La plataforma también está buscando una licencia de Bermudas más completa, además de entablar conversaciones con reguladores de la UE y Oriente Medio; ninguno de esos procesos está terminado aún. Un usuario que lea, de forma aislada, el titular de "la primera DEX regulada del mundo" razonablemente asumiría una cobertura más amplia que la que en realidad proporciona una única licencia modificada en una jurisdicción pequeña, mientras que un usuario con sede en Singapur que lea la letra pequeña del listado en la tienda de aplicaciones obtiene la impresión contraria por completo.
Que GRVT esté regulada depende de qué jurisdicción se consulte: en Bermudas es real, bajo una licencia modificada; en Singapur está explícitamente ausente según el descargo de responsabilidad de la propia empresa, y ningún lado por sí solo cuenta toda la historia.
@grvt_io #grvt
$LAB $VELVET
GRVT presenta una división similar. En diciembre de 2024 obtuvo una Licencia de Negocio de Activos Digitales Modificada de Clase M de la Autoridad Monetaria de Bermudas, que la empresa y la mayor parte de la cobertura describen como lo que la convierte en la primera bolsa mundial de derivados onchain regulada. Esa credencial se repite constantemente en el marketing y en las reseñas. Mientras tanto, la entidad operativa detrás de la aplicación, GRVT Technologies Pte Ltd, tiene su sede en Singapur, y el propio listado de la tienda de aplicaciones de la plataforma incluye un descargo de responsabilidad directo para ese mercado: GRVT no está licenciada, aprobada, autorizada, designada, reconocida, registrada ni de otro modo regulada bajo ninguna legislación administrada por la Autoridad Monetaria de Singapur, y los usuarios allí no reciben ninguna de las salvaguardas regulatorias que normalmente proporcionaría la supervisión de la MAS. Así que la respuesta honesta a "¿GRVT está regulada?" se divide según la jurisdicción, en lugar de resolverse en una sola palabra. Bermudas, sí, bajo una categoría de licencia modificada. Singapur, explícitamente no, según las propias palabras de la empresa. La plataforma también está buscando una licencia de Bermudas más completa, además de entablar conversaciones con reguladores de la UE y Oriente Medio; ninguno de esos procesos está terminado aún. Un usuario que lea, de forma aislada, el titular de "la primera DEX regulada del mundo" razonablemente asumiría una cobertura más amplia que la que en realidad proporciona una única licencia modificada en una jurisdicción pequeña, mientras que un usuario con sede en Singapur que lea la letra pequeña del listado en la tienda de aplicaciones obtiene la impresión contraria por completo.
Que GRVT esté regulada depende de qué jurisdicción se consulte: en Bermudas es real, bajo una licencia modificada; en Singapur está explícitamente ausente según el descargo de responsabilidad de la propia empresa, y ningún lado por sí solo cuenta toda la historia.
@grvt_io #grvt
$LAB $VELVET
Un amigo que construía un food truck insistió en ponerlo a funcionar en un estacionamiento cerrado durante dos fines de semana antes de aparcarlo en una esquina real de la calle. Su pareja quería lanzarlo de inmediato en el centro. Él dijo que el equipo necesitaba fallar en algún lugar pequeño primero, no en el almuerzo de un cliente que paga.
GRVT puso su mercado spot en vivo en testnet el 29 de abril de 2026, meses antes de cualquier declaración pública sobre una fecha de lanzamiento de spot en mainnet. Esto ocurrió después de que el exchange ya hubiera construido su reputación casi por completo en futuros perpetuos, abarcando aproximadamente 168 mercados; así que el spot representó una lógica de emparejamiento y liquidación realmente nueva, en lugar de ser un simple complemento de poca importancia. Ejecutarlo primero en testnet significó que usuarios reales e integradores pudieran enrutar órdenes, probar casos límite y detectar errores contra un tipo de mercado que la plataforma nunca había operado en vivo antes, sin poner en riesgo ni un solo dólar de volumen spot real si algo se rompía. Los exchanges competidores con frecuencia lanzan productos nuevos directamente a mainnet con la presión de tiempo que imponen los lanzamientos de tokens o los calendarios de marketing, aceptando el riesgo de que los errores iniciales sean descubiertos por usuarios que pagan en lugar de por testers. El despliegue de spot de GRVT se integró en una hoja de ruta más amplia de 2026, bajo una presión real de plazos, propia, siguiendo una serie de anuncios vinculados a meses específicos; sin embargo, el equipo aun así insertó una fase en testnet antes de permitir que las órdenes spot tocaran fondos reales. Esa elección de secuenciación cambia la velocidad de salida por un menor riesgo de un fallo vergonzoso o costoso cuando el capital real empieza a fluir a través de un tipo de orden que la plataforma nunca había ejecutado en vivo antes.
GRVT no está apresurando cada producto nuevo directamente hacia el capital real como podría sugerir la presión de la hoja de ruta; su lanzamiento de spot demuestra una disposición a frenar y hacer pruebas de esfuerzo primero, incluso mientras la hoja de ruta que lo rodea avanza con un plazo público.
@grvt_io #grvt
$LAB
GRVT puso su mercado spot en vivo en testnet el 29 de abril de 2026, meses antes de cualquier declaración pública sobre una fecha de lanzamiento de spot en mainnet. Esto ocurrió después de que el exchange ya hubiera construido su reputación casi por completo en futuros perpetuos, abarcando aproximadamente 168 mercados; así que el spot representó una lógica de emparejamiento y liquidación realmente nueva, en lugar de ser un simple complemento de poca importancia. Ejecutarlo primero en testnet significó que usuarios reales e integradores pudieran enrutar órdenes, probar casos límite y detectar errores contra un tipo de mercado que la plataforma nunca había operado en vivo antes, sin poner en riesgo ni un solo dólar de volumen spot real si algo se rompía. Los exchanges competidores con frecuencia lanzan productos nuevos directamente a mainnet con la presión de tiempo que imponen los lanzamientos de tokens o los calendarios de marketing, aceptando el riesgo de que los errores iniciales sean descubiertos por usuarios que pagan en lugar de por testers. El despliegue de spot de GRVT se integró en una hoja de ruta más amplia de 2026, bajo una presión real de plazos, propia, siguiendo una serie de anuncios vinculados a meses específicos; sin embargo, el equipo aun así insertó una fase en testnet antes de permitir que las órdenes spot tocaran fondos reales. Esa elección de secuenciación cambia la velocidad de salida por un menor riesgo de un fallo vergonzoso o costoso cuando el capital real empieza a fluir a través de un tipo de orden que la plataforma nunca había ejecutado en vivo antes.
GRVT no está apresurando cada producto nuevo directamente hacia el capital real como podría sugerir la presión de la hoja de ruta; su lanzamiento de spot demuestra una disposición a frenar y hacer pruebas de esfuerzo primero, incluso mientras la hoja de ruta que lo rodea avanza con un plazo público.
@grvt_io #grvt
$LAB
Una ciudad cerca de mí instaló cámaras de tráfico en vivo en su puente principal hace unos años y las promocionó como si fueran en tiempo real. Revisé una durante un trayecto una vez, vi los mismos tres coches quedarse congelados en el mismo lugar durante lo que se sintió como una eternidad, y me di cuenta de que la transmisión en realidad solo se actualizaba cada 40 minutos más o menos. Nada estaba roto; la etiqueta simplemente estaba haciendo más trabajo que la tecnología subyacente podía soportar.
La cadena de GRVT se asienta a través del sistema de pruebas de ZKsync, y el lenguaje que rodea a las pruebas de conocimiento cero a menudo se describe de forma laxa como una verificación en tiempo real de cada transacción a medida que ocurre. En la práctica, el monitoreo independiente de L2BEAT muestra que las presentaciones de pruebas de ZKsync Era llegan a Ethereum aproximadamente cada 38 minutos en promedio, y las actualizaciones de estado siguen un ritmo similar de 29 minutos, no por transacción, en absoluto. Aun así, eso sigue siendo rápido según los estándares de blockchain y no es un fallo; las pruebas se agrupan deliberadamente para que cada una sea económica de verificar en la capa base de Ethereum en lugar de hacerlo con cada operación. Pero esto significa que tu operación se prueba en Ethereum está más cerca de que tu operación se incluya en un lote que se prueba aproximadamente cada media hora, que de una garantía instantánea por operación. El mismo monitoreo registró además un desfase real de capacidad de respuesta (liveness) en junio de 2026: no se registraron envíos de pruebas durante más de 10 horas frente al ritmo típico de 38 minutos; fue una anomalía más que la norma, pero documentada y vale la pena saberla, independientemente de lo raro que fue.
El asentamiento subyacente de GRVT no verifica las operaciones a Ethereum instantáneamente en el momento en que ocurren: agrupa aproximadamente media hora de actividad en cada prueba antes de que esa prueba se publique en Ethereum, con algunas brechas ocasionalmente documentadas que se extienden bastante más allá del promedio. La garantía de seguridad es real una vez que la prueba se publica; el momento en que eso ocurre simplemente es más lento y más “irregular” de lo que sugiere el concepto de tiempo real.
@grvt_io #grvt
$LAB
La cadena de GRVT se asienta a través del sistema de pruebas de ZKsync, y el lenguaje que rodea a las pruebas de conocimiento cero a menudo se describe de forma laxa como una verificación en tiempo real de cada transacción a medida que ocurre. En la práctica, el monitoreo independiente de L2BEAT muestra que las presentaciones de pruebas de ZKsync Era llegan a Ethereum aproximadamente cada 38 minutos en promedio, y las actualizaciones de estado siguen un ritmo similar de 29 minutos, no por transacción, en absoluto. Aun así, eso sigue siendo rápido según los estándares de blockchain y no es un fallo; las pruebas se agrupan deliberadamente para que cada una sea económica de verificar en la capa base de Ethereum en lugar de hacerlo con cada operación. Pero esto significa que tu operación se prueba en Ethereum está más cerca de que tu operación se incluya en un lote que se prueba aproximadamente cada media hora, que de una garantía instantánea por operación. El mismo monitoreo registró además un desfase real de capacidad de respuesta (liveness) en junio de 2026: no se registraron envíos de pruebas durante más de 10 horas frente al ritmo típico de 38 minutos; fue una anomalía más que la norma, pero documentada y vale la pena saberla, independientemente de lo raro que fue.
El asentamiento subyacente de GRVT no verifica las operaciones a Ethereum instantáneamente en el momento en que ocurren: agrupa aproximadamente media hora de actividad en cada prueba antes de que esa prueba se publique en Ethereum, con algunas brechas ocasionalmente documentadas que se extienden bastante más allá del promedio. La garantía de seguridad es real una vez que la prueba se publica; el momento en que eso ocurre simplemente es más lento y más “irregular” de lo que sugiere el concepto de tiempo real.
@grvt_io #grvt
$LAB
Muchos traders nuevos asumen que los pagos de funding en un exchange de perpetuos funcionan como una comisión de trading: dinero que la plataforma cobra por dejarte mantener una posición apalancada durante la noche. En GRVT esa suposición es simplemente incorrecta. El funding es explícitamente de persona a persona entre largos y cortos; la propia documentación de GRVT lo declara con total claridad: el funding no es una comisión del exchange, en ningún momento toca los ingresos de la plataforma.
El mecanismo existe únicamente para mantener el precio del perpetuo anclado al índice spot. Cuando el perpetuo cotiza con prima frente al spot, los largos le pagan a los cortos para comprimir esa prima de vuelta hacia cero. Cuando cotiza con descuento, en ese caso los cortos le pagan a los largos. GRVT no es una contrapartida que extrae valor de cualquiera de los dos lados; es el lugar donde se redistribuyen los pagos entre dos grupos de traders que, estructuralmente, apuestan en direcciones opuestas sobre la evolución del precio. Los ingresos de GRVT provienen de las comisiones de trading en el lado taker y maker, una partida completamente separada del mecanismo de funding.
La diferencia entre la suposición y la realidad aquí importa porque cambia la forma en que un trader debería pensar sobre los costos de funding. El funding persistentemente alto no es GRVT cobrando más; es el propio mercado señalando que hay muchos largos y que están pagando una prima para mantenerse largos con apalancamiento. Entender que el funding es una señal del mercado, no una comisión de la plataforma, cambia cómo un trader lo interpreta antes de abrir una posición, no después de que le hayan cobrado por una. La primera vez que vi una tasa de funding persistentemente positiva en un mercado de GRVT, mi instinto fue comprobar si la plataforma había subido alguna comisión en silencio, y me tomó leer la documentación con cuidado darme cuenta de que ese instinto estaba simplemente equivocado: el número me estaba diciendo algo sobre el posicionamiento largo abarrotado en ese mercado en particular, no sobre los ingresos de GRVT en absoluto, y eso cambió la forma en que interpreté cada gráfico de funding a partir de entonces.
@grvt_io #grvt
$LAB
El mecanismo existe únicamente para mantener el precio del perpetuo anclado al índice spot. Cuando el perpetuo cotiza con prima frente al spot, los largos le pagan a los cortos para comprimir esa prima de vuelta hacia cero. Cuando cotiza con descuento, en ese caso los cortos le pagan a los largos. GRVT no es una contrapartida que extrae valor de cualquiera de los dos lados; es el lugar donde se redistribuyen los pagos entre dos grupos de traders que, estructuralmente, apuestan en direcciones opuestas sobre la evolución del precio. Los ingresos de GRVT provienen de las comisiones de trading en el lado taker y maker, una partida completamente separada del mecanismo de funding.
La diferencia entre la suposición y la realidad aquí importa porque cambia la forma en que un trader debería pensar sobre los costos de funding. El funding persistentemente alto no es GRVT cobrando más; es el propio mercado señalando que hay muchos largos y que están pagando una prima para mantenerse largos con apalancamiento. Entender que el funding es una señal del mercado, no una comisión de la plataforma, cambia cómo un trader lo interpreta antes de abrir una posición, no después de que le hayan cobrado por una. La primera vez que vi una tasa de funding persistentemente positiva en un mercado de GRVT, mi instinto fue comprobar si la plataforma había subido alguna comisión en silencio, y me tomó leer la documentación con cuidado darme cuenta de que ese instinto estaba simplemente equivocado: el número me estaba diciendo algo sobre el posicionamiento largo abarrotado en ese mercado en particular, no sobre los ingresos de GRVT en absoluto, y eso cambió la forma en que interpreté cada gráfico de funding a partir de entonces.
@grvt_io #grvt
$LAB
Inicia sesión para explorar más contenidos