Khánh Trang1510
25 Publicaciones
Khánh Trang1510
Abrir operación
Trader frecuente
4.3 años
107 Siguiendo
19 Seguidores
24 Me gusta
Publicaciones
Cartera
Un comprador una vez me envió más de la cantidad acordada en una operación de Binance P2P y me pidió que reembolsara la diferencia directamente a una cuenta bancaria distinta de la que procedía el pago. Al principio parecía un error honesto. No lo era.
Este es un patrón conocido que vale la pena nombrar claramente, ya que atrapa incluso a traders con experiencia, no solo a principiantes. El pago de más en sí está diseñado para generar urgencia y confusión, con la esperanza de que el vendedor reembolse el importe extra rápidamente antes de darse cuenta de que el pago original podría revertirse o disputarse después, dejando al vendedor con el envío de ambas cosas: el cripto y un reembolso en efectivo por un pago que en realidad nunca se consolida. Binance P2P protege a los vendedores aquí mediante su sistema de escrow, que mantiene el activo cripto por separado de cualquier conversación de un lado sobre reembolsos, y mediante el requisito de que todo lo relacionado con la operación permanezca dentro de la plataforma y de sus canales oficiales. En el momento en que alguien solicita un reembolso a una cuenta diferente a la del remitente original, eso es una ruptura clara del comportamiento normal de una operación y una señal de alerta que vale la pena detener de inmediato.
Mi regla desde esa operación es sencilla. Nunca reembolso nada fuera del pedido original. Si una cantidad de pago parece incorrecta, no actúo con mi propio criterio: cancelo o contacto con el soporte de Binance y les dejo revisar la discrepancia antes de tocar el activo cripto en absoluto. Siempre confirmo que el nombre del remitente en cualquier pago coincida con el contrapartido verificado en el pedido, ya que un nombre que no coincide es una advertencia por sí misma. Mantengo una captura de pantalla de la cantidad exacta que recibí en mi propia cuenta, no la cantidad que se alega en el chat. Cualquier solicitud para mover dinero fuera de la plataforma, reembolsar o de cualquier otro modo, se reporta en lugar de completarse en silencio.
Confiar en el proceso en lugar de confiar en la historia de un desconocido no me ha costado nada ni una sola vez.
@Binance Vietnam #BinanceP2PAnToan
$TUT $BLUAI
Este es un patrón conocido que vale la pena nombrar claramente, ya que atrapa incluso a traders con experiencia, no solo a principiantes. El pago de más en sí está diseñado para generar urgencia y confusión, con la esperanza de que el vendedor reembolse el importe extra rápidamente antes de darse cuenta de que el pago original podría revertirse o disputarse después, dejando al vendedor con el envío de ambas cosas: el cripto y un reembolso en efectivo por un pago que en realidad nunca se consolida. Binance P2P protege a los vendedores aquí mediante su sistema de escrow, que mantiene el activo cripto por separado de cualquier conversación de un lado sobre reembolsos, y mediante el requisito de que todo lo relacionado con la operación permanezca dentro de la plataforma y de sus canales oficiales. En el momento en que alguien solicita un reembolso a una cuenta diferente a la del remitente original, eso es una ruptura clara del comportamiento normal de una operación y una señal de alerta que vale la pena detener de inmediato.
Mi regla desde esa operación es sencilla. Nunca reembolso nada fuera del pedido original. Si una cantidad de pago parece incorrecta, no actúo con mi propio criterio: cancelo o contacto con el soporte de Binance y les dejo revisar la discrepancia antes de tocar el activo cripto en absoluto. Siempre confirmo que el nombre del remitente en cualquier pago coincida con el contrapartido verificado en el pedido, ya que un nombre que no coincide es una advertencia por sí misma. Mantengo una captura de pantalla de la cantidad exacta que recibí en mi propia cuenta, no la cantidad que se alega en el chat. Cualquier solicitud para mover dinero fuera de la plataforma, reembolsar o de cualquier otro modo, se reporta en lugar de completarse en silencio.
Confiar en el proceso en lugar de confiar en la historia de un desconocido no me ha costado nada ni una sola vez.
@Binance Vietnam #BinanceP2PAnToan
$TUT $BLUAI
Tres letras me salvaron de una mala operación. El nombre verificado del comprador en Binance P2P decía Nguyen Van Minh, y la transferencia que llegó a mi cuenta venía de una cuenta con la etiqueta Nguyen Van Anh. Lo bastante parecido como para pasarlo por alto si te apresuras, pero lo bastante diferente como para importar de verdad.
Binance P2P vincula cada cuenta a una identidad verificada mediante KYC, y se supone que esa identidad debe coincidir con la cuenta de pago usada durante una operación. Cuando confirmo el pago ahora, no solo compruebo la cantidad. Verifico el nombre del remitente, letra por letra, frente al nombre que aparece en el perfil verificado del comprador. Este único hábito existe porque el escrow solo te protege si usas realmente la información a la que te da acceso.
Pausé la operación y consulté directamente la discrepancia en el chat oficial de Binance P2P, que mantiene un registro completo por si la situación necesitaba escalar más adelante. Su explicación incluía la cuenta de un familiar, algo que a veces ocurre, pero las propias reglas de transacción de Binance P2P tratan los pagos de terceros y las discrepancias de nombre como infracciones, independientemente de la razón. No liberé las criptomonedas. Abrí una apelación, expliqué la diferencia con claridad y adjunté tanto el registro del pago como una captura de pantalla del perfil que mostraba la discrepancia de nombres.
Soporte lo revisó y la orden se deshizo: se reembolsó el pago del comprador en lugar de completar la operación. Cero pérdidas por mi parte y ningún fondo liberado contra un pago que no pude verificar por completo.
Ahora entiendo por qué Binance P2P aplica esta regla con tanta rigidez en vez de dejarla como una sugerencia. Los pagos de terceros hacen prácticamente imposible saber quién envió realmente el dinero, lo que rompe toda la cadena de rendición de cuentas que la verificación KYC pretende garantizar. Tratar una discrepancia como algo menor deshace la protección en la que se construyó todo el sistema.
Leer los nombres con atención requiere diez segundos extra. Saltarse ese paso es la forma en que incluso vendedores cuidadosos y experimentados terminan perdiendo criptomonedas en operaciones que al principio parecían completamente normales.
@Binance Vietnam #BinanceP2PAnToan
$ACE
Binance P2P vincula cada cuenta a una identidad verificada mediante KYC, y se supone que esa identidad debe coincidir con la cuenta de pago usada durante una operación. Cuando confirmo el pago ahora, no solo compruebo la cantidad. Verifico el nombre del remitente, letra por letra, frente al nombre que aparece en el perfil verificado del comprador. Este único hábito existe porque el escrow solo te protege si usas realmente la información a la que te da acceso.
Pausé la operación y consulté directamente la discrepancia en el chat oficial de Binance P2P, que mantiene un registro completo por si la situación necesitaba escalar más adelante. Su explicación incluía la cuenta de un familiar, algo que a veces ocurre, pero las propias reglas de transacción de Binance P2P tratan los pagos de terceros y las discrepancias de nombre como infracciones, independientemente de la razón. No liberé las criptomonedas. Abrí una apelación, expliqué la diferencia con claridad y adjunté tanto el registro del pago como una captura de pantalla del perfil que mostraba la discrepancia de nombres.
Soporte lo revisó y la orden se deshizo: se reembolsó el pago del comprador en lugar de completar la operación. Cero pérdidas por mi parte y ningún fondo liberado contra un pago que no pude verificar por completo.
Ahora entiendo por qué Binance P2P aplica esta regla con tanta rigidez en vez de dejarla como una sugerencia. Los pagos de terceros hacen prácticamente imposible saber quién envió realmente el dinero, lo que rompe toda la cadena de rendición de cuentas que la verificación KYC pretende garantizar. Tratar una discrepancia como algo menor deshace la protección en la que se construyó todo el sistema.
Leer los nombres con atención requiere diez segundos extra. Saltarse ese paso es la forma en que incluso vendedores cuidadosos y experimentados terminan perdiendo criptomonedas en operaciones que al principio parecían completamente normales.
@Binance Vietnam #BinanceP2PAnToan
$ACE
Protejo una compra en Binance P2P antes de pulsar Enviar. Los compradores a menudo se centran en recibir criptomonedas, pero la transferencia de fiat es la parte que controlo y puede ser difícil de revertir. Un beneficiario incorrecto, una cuenta de un tercero o una instrucción fuera de la plataforma pueden convertir una orden protegida en un pago no compatible.
Mi primera verificación ocurre en el anuncio. Reviso el perfil del vendedor, el historial de operaciones visible, las señales de finalización, los límites, el método de pago y los términos. Un precio ligeramente mejor no compensa instrucciones poco claras. Una vez que abro la orden, el escrow reserva la criptomoneda del vendedor, el KYC identifica a los usuarios, el chat de la orden registra la conversación y Appeal ofrece una vía hacia el Soporte de Binance. Mantengo cada paso conectado a esa orden.
Antes de pagar, comparo 4 elementos: el número de orden en vivo, el importe exacto en fiat, los datos del beneficiario indicados y el plazo de pago. Envío desde una cuenta con mi nombre verificado. Si el vendedor proporciona una cuenta distinta en el chat, pide que el pago se haga a un amigo o quiere varias transferencias a nombres que no están relacionados, me detengo. Nunca continúo por un canal privado ni pago después de que la orden haya expirado.
Después de realizar la transferencia, verifico la transacción en mi aplicación de pago, conservo su ID y marco como pagado solo cuando el dinero realmente haya salido bajo la orden correcta. Le aviso al vendedor en el chat de la orden y luego espero la liberación. No cancelo una orden pagada solo porque el vendedor lo pida, y no pago dos veces para "desbloquear" la criptomoneda en escrow. Esas solicitudes crean una brecha entre el pago y la evidencia en la plataforma.
Si el vendedor no libera o disputa la recepción, guardo la pantalla de la orden, el registro de la transacción, el beneficiario, el importe, la marca de tiempo y el chat. Uso Appeal o el Soporte oficial de Binance y respondo con la evidencia solicitada. El escrow está diseñado para mantener la criptomoneda durante la revisión, así que no es necesario entrar en pánico y un segundo acuerdo por fuera es peligroso.
La regla de mi comprador es precisa: una sola orden activa, un solo pagador verificado, un solo destinatario indicado y un pago exacto. Permito que el proceso de Binance P2P conecte la prueba del fiat con la criptomoneda en escrow de principio a fin.
@Binance Vietnam #BinanceP2PAnToan
$BLESS
Mi primera verificación ocurre en el anuncio. Reviso el perfil del vendedor, el historial de operaciones visible, las señales de finalización, los límites, el método de pago y los términos. Un precio ligeramente mejor no compensa instrucciones poco claras. Una vez que abro la orden, el escrow reserva la criptomoneda del vendedor, el KYC identifica a los usuarios, el chat de la orden registra la conversación y Appeal ofrece una vía hacia el Soporte de Binance. Mantengo cada paso conectado a esa orden.
Antes de pagar, comparo 4 elementos: el número de orden en vivo, el importe exacto en fiat, los datos del beneficiario indicados y el plazo de pago. Envío desde una cuenta con mi nombre verificado. Si el vendedor proporciona una cuenta distinta en el chat, pide que el pago se haga a un amigo o quiere varias transferencias a nombres que no están relacionados, me detengo. Nunca continúo por un canal privado ni pago después de que la orden haya expirado.
Después de realizar la transferencia, verifico la transacción en mi aplicación de pago, conservo su ID y marco como pagado solo cuando el dinero realmente haya salido bajo la orden correcta. Le aviso al vendedor en el chat de la orden y luego espero la liberación. No cancelo una orden pagada solo porque el vendedor lo pida, y no pago dos veces para "desbloquear" la criptomoneda en escrow. Esas solicitudes crean una brecha entre el pago y la evidencia en la plataforma.
Si el vendedor no libera o disputa la recepción, guardo la pantalla de la orden, el registro de la transacción, el beneficiario, el importe, la marca de tiempo y el chat. Uso Appeal o el Soporte oficial de Binance y respondo con la evidencia solicitada. El escrow está diseñado para mantener la criptomoneda durante la revisión, así que no es necesario entrar en pánico y un segundo acuerdo por fuera es peligroso.
La regla de mi comprador es precisa: una sola orden activa, un solo pagador verificado, un solo destinatario indicado y un pago exacto. Permito que el proceso de Binance P2P conecte la prueba del fiat con la criptomoneda en escrow de principio a fin.
@Binance Vietnam #BinanceP2PAnToan
$BLESS
La investigación académica sobre blockchain tiene un problema de reputación: artículos brillantes, pruebas elegantes y, luego, nada que un usuario normal pueda tocar. Pregúntale a cualquiera que haya pasado por una conferencia de criptografía y te dirá que la mayor parte de lo que se publica se queda publicado.
Babylon parece un objetivo fácil para esa suposición en el papel. El cofundador David Tse pasó 18 años enseñando en la UC Berkeley antes de más de una década en Stanford, donde todavía dirige un laboratorio de investigación, y Babylon ni siquiera tiene un CEO: Tse es científico de investigación mientras que el cofundador Fisher Yu dirige la ingeniería como CTO. Ese es un organigrama académico, no el de una startup típica.
La cronología dice lo contrario. BABE, el protocolo de verificación de pruebas Groth16 de Tse para Bitcoin, llegó a la red de pruebas alfa de Babylon en febrero de 2026, al afirmar una reducción de casi 1.000 veces en el costo de configuración y almacenamiento para verificar pruebas de conocimiento cero en Bitcoin. Para el 2 de junio, aproximadamente cuatro meses después, esa misma investigación sustentó la integración pública de la red de pruebas de Aave v4 de Trustless Bitcoin Vaults, con la participación simultánea de a16z crypto, Ledger y GoMining.
Babylon no es un laboratorio de investigación que simplemente tiene un token: es una prueba de que una estructura de laboratorio aún puede salir adelante al ritmo de una startup cuando los incentivos encajan. Si los ahorros de costos de BABE se mantienen cuando los usuarios adversarios empiecen a sondear TBV en la red principal es la parte que la investigación por sí sola nunca puede responder.
@BabylonLabs_io $BABY #baby
$BLESS
Babylon parece un objetivo fácil para esa suposición en el papel. El cofundador David Tse pasó 18 años enseñando en la UC Berkeley antes de más de una década en Stanford, donde todavía dirige un laboratorio de investigación, y Babylon ni siquiera tiene un CEO: Tse es científico de investigación mientras que el cofundador Fisher Yu dirige la ingeniería como CTO. Ese es un organigrama académico, no el de una startup típica.
La cronología dice lo contrario. BABE, el protocolo de verificación de pruebas Groth16 de Tse para Bitcoin, llegó a la red de pruebas alfa de Babylon en febrero de 2026, al afirmar una reducción de casi 1.000 veces en el costo de configuración y almacenamiento para verificar pruebas de conocimiento cero en Bitcoin. Para el 2 de junio, aproximadamente cuatro meses después, esa misma investigación sustentó la integración pública de la red de pruebas de Aave v4 de Trustless Bitcoin Vaults, con la participación simultánea de a16z crypto, Ledger y GoMining.
Babylon no es un laboratorio de investigación que simplemente tiene un token: es una prueba de que una estructura de laboratorio aún puede salir adelante al ritmo de una startup cuando los incentivos encajan. Si los ahorros de costos de BABE se mantienen cuando los usuarios adversarios empiecen a sondear TBV en la red principal es la parte que la investigación por sí sola nunca puede responder.
@BabylonLabs_io $BABY #baby
$BLESS
La mayoría de los protocolos de préstamos agrupan garantías porque la agrupación es eficiente. Aave y Compound mezclan los depósitos de miles de usuarios en mercados compartidos, lo que profundiza la liquidez y ajusta los precios, y ese modelo de agrupación es exactamente sobre lo que se construye gran parte de la eficiencia de capital en DeFi. Babylon observó ese modelo al diseñar los Trustless Bitcoin Vaults y eligió a propósito una estructura opuesta.
Cada bóveda TBV contiene un bitcoin de un solo usuario, vinculado mediante transacciones prefirmadas a esa posición específica y a ese estado específico del contrato inteligente externo. No se mezcla nada. Babylon y analistas externos que cubren el lanzamiento han descrito esta segregación como orientada de forma directa a la comodidad institucional y regulatoria, ya que el bitcoin de una bóveda permanece trazable a su propio depósito en lugar de integrarse en un pool compartido anónimo, tal como ocurriría con una reserva fraccionaria de un banco. Es destacable que Babylon está optando por conectar este diseño segregado a Aave, precisamente el tipo de protocolo agrupado que decidió no imitar, mediante la integración de Aave v4 prevista alrededor de mediados de 2026, en lugar de construir por su cuenta un mercado de préstamos agrupado desde cero. El intercambio se manifiesta de inmediato: las bóvedas segregadas no pueden igualar la profundidad ni los spreads ajustados que genera un pool compartido, y cada una conlleva su propia carga de configuración y supervisión bajo BitVM3.
Babylon no está optimizando los TBV para la máxima eficiencia de capital; los está optimizando para la auditabilidad y la trazabilidad por posición, una apuesta de que los tenedores institucionales de bitcoin pagarán una prima de liquidez por una contabilidad más limpia.
@BabylonLabs_io $BABY #baby
$WMTX
Cada bóveda TBV contiene un bitcoin de un solo usuario, vinculado mediante transacciones prefirmadas a esa posición específica y a ese estado específico del contrato inteligente externo. No se mezcla nada. Babylon y analistas externos que cubren el lanzamiento han descrito esta segregación como orientada de forma directa a la comodidad institucional y regulatoria, ya que el bitcoin de una bóveda permanece trazable a su propio depósito en lugar de integrarse en un pool compartido anónimo, tal como ocurriría con una reserva fraccionaria de un banco. Es destacable que Babylon está optando por conectar este diseño segregado a Aave, precisamente el tipo de protocolo agrupado que decidió no imitar, mediante la integración de Aave v4 prevista alrededor de mediados de 2026, en lugar de construir por su cuenta un mercado de préstamos agrupado desde cero. El intercambio se manifiesta de inmediato: las bóvedas segregadas no pueden igualar la profundidad ni los spreads ajustados que genera un pool compartido, y cada una conlleva su propia carga de configuración y supervisión bajo BitVM3.
Babylon no está optimizando los TBV para la máxima eficiencia de capital; los está optimizando para la auditabilidad y la trazabilidad por posición, una apuesta de que los tenedores institucionales de bitcoin pagarán una prima de liquidez por una contabilidad más limpia.
@BabylonLabs_io $BABY #baby
$WMTX
Wrapped Bitcoin hizo algo genuinamente importante para esta industria: permitió que la liquidez de Bitcoin apareciera dentro del DeFi de Ethereum años antes de que existiera algo parecido a los Trustless Bitcoin Vaults. La propuesta de Babylon no funciona si te saltas primero dar ese crédito al wrapped BTC.
Pero el diseño del wrapped BTC conlleva un costo estructural permanente. Un custodio mantiene Bitcoin real y acuña un token sintético en una proporción 1:1 contra él, y cada unidad de ese activo sintético solo es tan confiable como la solvencia y la honestidad del custodio. Incluso a una escala significativa, el wrapped BTC sigue representando bien por debajo del 1% del suministro total de Bitcoin: aproximadamente 150,000 BTC de apenas menos de 20 millones, lo cual me indica que la mayoría de los tenedores de Bitcoin simplemente ha rechazado asumir ese intercambio con custodia desde el principio.
La respuesta de Babylon es eliminar por completo al custodio de la ecuación. El BTC nativo bloquea un Taproot UTXO en el propio Bitcoin, y Aave v4 presta respaldándose directamente en esa posición bloqueada, de modo que la moneda que respalda tu préstamo nunca se acuña como una especie de IOU en otro lugar. Los depositantes aportan como colateral Bitcoin real y toman prestados activos respaldados como USDC o USDT en Ethereum sin que ese colateral cambie de forma.
La complicación honesta es que esto actualmente es una testnet pública, no probada a escala de mainnet, mientras que el wrapped BTC tiene años de historial de producción detrás, incluidos errores. Babylon está proponiendo un modelo estructuralmente más seguro para un problema que el wrapped BTC ya resolvió prácticamente, solo que de forma imperfecta. La contienda real aquí es si el modelo estructuralmente más seguro vence a años de infraestructura que ya funciona.
@BabylonLabs_io $BABY #baby
$GIGGLE
Pero el diseño del wrapped BTC conlleva un costo estructural permanente. Un custodio mantiene Bitcoin real y acuña un token sintético en una proporción 1:1 contra él, y cada unidad de ese activo sintético solo es tan confiable como la solvencia y la honestidad del custodio. Incluso a una escala significativa, el wrapped BTC sigue representando bien por debajo del 1% del suministro total de Bitcoin: aproximadamente 150,000 BTC de apenas menos de 20 millones, lo cual me indica que la mayoría de los tenedores de Bitcoin simplemente ha rechazado asumir ese intercambio con custodia desde el principio.
La respuesta de Babylon es eliminar por completo al custodio de la ecuación. El BTC nativo bloquea un Taproot UTXO en el propio Bitcoin, y Aave v4 presta respaldándose directamente en esa posición bloqueada, de modo que la moneda que respalda tu préstamo nunca se acuña como una especie de IOU en otro lugar. Los depositantes aportan como colateral Bitcoin real y toman prestados activos respaldados como USDC o USDT en Ethereum sin que ese colateral cambie de forma.
La complicación honesta es que esto actualmente es una testnet pública, no probada a escala de mainnet, mientras que el wrapped BTC tiene años de historial de producción detrás, incluidos errores. Babylon está proponiendo un modelo estructuralmente más seguro para un problema que el wrapped BTC ya resolvió prácticamente, solo que de forma imperfecta. La contienda real aquí es si el modelo estructuralmente más seguro vence a años de infraestructura que ya funciona.
@BabylonLabs_io $BABY #baby
$GIGGLE
Aquí va un detalle que creo que la mayoría de los resúmenes rápidos sobre los Bóvedas Bitcoin sin custodia de Babylon omiten por completo, y vale la pena detenerse en él porque complica la narrativa limpia de "sin envolturas, nunca". En Aave v4, si una posición nativa con garantía en Bitcoin se liquida, el Spoke de Intercambio (BTC Vault Swap Spoke) permite que los liquidadores intercambien esa posición en BTC incautada por WBTC para que la liquidación pueda ocurrir rápidamente, y el Bitcoin nativo real se redima después en la red de Bitcoin mediante el sistema de pruebas de Babylon.
Así que el Bitcoin envuelto sí aparece aquí, solo que no donde normalmente los usuarios esperan. Los depositantes publican BTC nativo de verdad como colateral, y en esa parte la afirmación se mantiene totalmente: tu Bitcoin permanece en la red de Bitcoin todo el tiempo mientras lo estás usando como respaldo para pedir prestado. Pero la lógica interna de la liquidación usa una representación envuelta específicamente para resolver una discrepancia real de tiempos: el Bitcoin se liquida más lento que Ethereum, y los liquidadores necesitan actuar rápido cuando una posición se vuelve poco saludable.
No lo veo como una contradicción, sino como un compromiso de ingeniería honesto que el lenguaje de marketing tiende a suavizar. Babylon está llevando liquidez de Bitcoin nativa a Ethereum gracias a este diseño, y usar un activo envuelto durante unos pocos segundos de liquidación de alta velocidad es algo muy distinto a exigir que los usuarios envuelvan su Bitcoin solo para poder participar.
Aun así, preferiría que la gente entendiera este matiz antes en el testnet público, en lugar de descubrirlo más tarde y sentirse engañada. "Trustless" describe la capa de custodia y verificación del colateral aquí. No significa que el Bitcoin envuelto haya desaparecido del sistema por completo; solo se ha desplazado a una esquina más estrecha y de movimientos más rápidos.
@BabylonLabs_io $BABY #baby
$COTI
Así que el Bitcoin envuelto sí aparece aquí, solo que no donde normalmente los usuarios esperan. Los depositantes publican BTC nativo de verdad como colateral, y en esa parte la afirmación se mantiene totalmente: tu Bitcoin permanece en la red de Bitcoin todo el tiempo mientras lo estás usando como respaldo para pedir prestado. Pero la lógica interna de la liquidación usa una representación envuelta específicamente para resolver una discrepancia real de tiempos: el Bitcoin se liquida más lento que Ethereum, y los liquidadores necesitan actuar rápido cuando una posición se vuelve poco saludable.
No lo veo como una contradicción, sino como un compromiso de ingeniería honesto que el lenguaje de marketing tiende a suavizar. Babylon está llevando liquidez de Bitcoin nativa a Ethereum gracias a este diseño, y usar un activo envuelto durante unos pocos segundos de liquidación de alta velocidad es algo muy distinto a exigir que los usuarios envuelvan su Bitcoin solo para poder participar.
Aun así, preferiría que la gente entendiera este matiz antes en el testnet público, en lugar de descubrirlo más tarde y sentirse engañada. "Trustless" describe la capa de custodia y verificación del colateral aquí. No significa que el Bitcoin envuelto haya desaparecido del sistema por completo; solo se ha desplazado a una esquina más estrecha y de movimientos más rápidos.
@BabylonLabs_io $BABY #baby
$COTI
Menciona los préstamos respaldados por Bitcoin a cualquiera que estuviera prestando atención en 2022 y probablemente tendrás la misma reacción: así es como la gente lo perdió todo. Celsius, BlockFi, Genesis y Hodlnaut congelaron retiros y se declararon en quiebra en un plazo de aproximadamente seis meses entre sí, y el sector perdió más de 10 mil millones de dólares en activos de clientes en ese solo año. Esa historia es real, no exagerada, y es un estereotipo completamente razonable al que aferrarse al presentar cualquier producto nuevo de préstamos con BTC.
El estereotipo se sostiene porque el patrón de fallas se mantuvo constante en todos ellos. Las investigaciones posteriores apuntaron a la rehipotecación: plataformas que reutilizaban en silencio las garantías de los clientes para sus propias operaciones y apuestas, además de desajustes de vencimientos y una exposición concentrada en un puñado de contrapartes que estallaron al mismo tiempo. Los clientes no tenían una forma real de ver que eso ocurría desde fuera hasta que ya era demasiado tarde.
Trustless Bitcoin Vaults está diseñado para hacer que ese modo de falla específico sea estructuralmente imposible, en lugar de solo prometer un mejor comportamiento esta vez. No hay un custodio que sostenga el BTC de los clientes para rehipotecarlo, no hay un consorcio de firmantes que tome decisiones discrecionales, y las monedas de cada bóveda permanecen bloqueadas en una única relación de contrato inteligente, aislada y específica, en lugar de agruparse en un balance general al que una empresa pueda prestar en secreto.
Babylon no es una versión mejor administrada de Celsius; es una criatura estructuralmente diferente. Los colapsos de 2022 ocurrieron porque las monedas de los clientes estaban en cuentas a las que las empresas podían acceder. En TBV, no existe una cuenta ni una empresa entre la bóveda y el código que la gobierna.
@BabylonLabs_io $BABY #baby
$BANK
El estereotipo se sostiene porque el patrón de fallas se mantuvo constante en todos ellos. Las investigaciones posteriores apuntaron a la rehipotecación: plataformas que reutilizaban en silencio las garantías de los clientes para sus propias operaciones y apuestas, además de desajustes de vencimientos y una exposición concentrada en un puñado de contrapartes que estallaron al mismo tiempo. Los clientes no tenían una forma real de ver que eso ocurría desde fuera hasta que ya era demasiado tarde.
Trustless Bitcoin Vaults está diseñado para hacer que ese modo de falla específico sea estructuralmente imposible, en lugar de solo prometer un mejor comportamiento esta vez. No hay un custodio que sostenga el BTC de los clientes para rehipotecarlo, no hay un consorcio de firmantes que tome decisiones discrecionales, y las monedas de cada bóveda permanecen bloqueadas en una única relación de contrato inteligente, aislada y específica, en lugar de agruparse en un balance general al que una empresa pueda prestar en secreto.
Babylon no es una versión mejor administrada de Celsius; es una criatura estructuralmente diferente. Los colapsos de 2022 ocurrieron porque las monedas de los clientes estaban en cuentas a las que las empresas podían acceder. En TBV, no existe una cuenta ni una empresa entre la bóveda y el código que la gobierna.
@BabylonLabs_io $BABY #baby
$BANK
Los BTC Vaults “trustless” nunca fueron diseñados para hacer solo una cosa. El material de la hoja de ruta de Babylon para su propio producto describe la misma primitiva de bóveda impulsando el trading de perps colateralizados por BTC y la emisión de stablecoins con paridad en dólares respaldadas estrictamente por Bitcoin nativo, además de préstamos. Tres productos iniciales plausibles, una sola pieza de tecnología subyacente.
Babylon eligió los préstamos y eligió específicamente Aave para empezar. Esa es una decisión con lógica real detrás. Los Perps necesitan liquidez profunda y de rápido movimiento en derivados y market makers dispuestos a cotizar frente a un tipo de colateral nuevo. La emisión de stablecoins necesita su propia campaña de credibilidad para otro token en dólares en un mercado que ya está abarrotado. Hacer préstamos contra el mayor protocolo DeFi por liquidez evita ambos problemas: Aave ya tiene prestatarios, depositantes y una infraestructura de liquidación que lleva años funcionando, así que la tecnología de la bóveda obtiene un canal de distribución ya probado en lugar de tener que construir demanda desde cero.
El costo es que el préstamo también es la categoría más disputada, la más vigilada, para lanzar, compitiendo directamente con cada otra forma de colateral de BTC que Aave ya lista. Babylon eligió la sala más difícil para entrar primero, porque además era la que ya estaba construida y llena de liquidez.
Babylon no está eligiendo préstamos porque sea la aplicación más sencilla de TBV; los perps y la emisión de stablecoins están en la misma hoja de ruta. Babylon está eligiendo préstamos porque Aave ya aporta liquidez y usuarios que un venue nuevo de perps o de stablecoin habría tenido que construir desde cero.
@BabylonLabs_io $BABY #baby
$DEXE $BANK
Babylon eligió los préstamos y eligió específicamente Aave para empezar. Esa es una decisión con lógica real detrás. Los Perps necesitan liquidez profunda y de rápido movimiento en derivados y market makers dispuestos a cotizar frente a un tipo de colateral nuevo. La emisión de stablecoins necesita su propia campaña de credibilidad para otro token en dólares en un mercado que ya está abarrotado. Hacer préstamos contra el mayor protocolo DeFi por liquidez evita ambos problemas: Aave ya tiene prestatarios, depositantes y una infraestructura de liquidación que lleva años funcionando, así que la tecnología de la bóveda obtiene un canal de distribución ya probado en lugar de tener que construir demanda desde cero.
El costo es que el préstamo también es la categoría más disputada, la más vigilada, para lanzar, compitiendo directamente con cada otra forma de colateral de BTC que Aave ya lista. Babylon eligió la sala más difícil para entrar primero, porque además era la que ya estaba construida y llena de liquidez.
Babylon no está eligiendo préstamos porque sea la aplicación más sencilla de TBV; los perps y la emisión de stablecoins están en la misma hoja de ruta. Babylon está eligiendo préstamos porque Aave ya aporta liquidez y usuarios que un venue nuevo de perps o de stablecoin habría tenido que construir desde cero.
@BabylonLabs_io $BABY #baby
$DEXE $BANK
Enterrado en el script de staking de Babylon hay una pequeña elección criptográfica que dice mucho sobre las prioridades del equipo. La salida de desunbonding en cada UTXO apostado es una salida de Taproot, y las salidas de Taproot normalmente admiten dos formas de gastar: una ruta de clave rápida o una ruta de script más lenta con condiciones explícitas escritas en. Babylon deshabilita por completo la ruta de clave, usando lo que se llama un punto NUMS, sin nada oculto en la manga, como clave interna: un valor construido de modo que nadie pueda mantener una clave privada para él incluso en teoría.
Esa única elección obliga a que cada transacción de desunbonding pase por la ruta de script, la que requiere un quórum de firmas del comité de covenants definido por un umbral específico establecido en los parámetros de la cadena. Una atajo de ruta de clave habría sido más simple de implementar y más barato de gastar. También habría creado una salida no auditable que eludiría toda la lógica de slashing y desunbonding sobre la que se construye el protocolo. Babylon eligió a propósito la ruta más lenta y totalmente acotada.
Babylon no está eligiendo comodidad aquí: está eligiendo restricción demostrable, cerrando un atajo que la mayoría de usuarios nunca notaría. Esa única decisión de script revela un hábito: cuando chocan eficiencia y auditabilidad en la capa base, este equipo elige auditabilidad. Solo aparece cuando lees el script, no cuando miras el deck de presentación.
@BabylonLabs_io $BABY #baby
$LAB
Esa única elección obliga a que cada transacción de desunbonding pase por la ruta de script, la que requiere un quórum de firmas del comité de covenants definido por un umbral específico establecido en los parámetros de la cadena. Una atajo de ruta de clave habría sido más simple de implementar y más barato de gastar. También habría creado una salida no auditable que eludiría toda la lógica de slashing y desunbonding sobre la que se construye el protocolo. Babylon eligió a propósito la ruta más lenta y totalmente acotada.
Babylon no está eligiendo comodidad aquí: está eligiendo restricción demostrable, cerrando un atajo que la mayoría de usuarios nunca notaría. Esa única decisión de script revela un hábito: cuando chocan eficiencia y auditabilidad en la capa base, este equipo elige auditabilidad. Solo aparece cuando lees el script, no cuando miras el deck de presentación.
@BabylonLabs_io $BABY #baby
$LAB
Un contratista una vez me dijo que la forma más rápida de arruinar un presupuesto de una remodelación es gastar por igual en lo que la gente ve y en lo que no ve. Los renovadores inteligentes ponen el dinero donde es visible y aceptan la complejidad oculta detrás de las paredes. Los ingenieros de Babylon hicieron un cálculo similar con BitVM3.
La investigación de BitVM3 detrás de las bóvedas de Babylon informa una reducción aproximada de 1000 veces en los costos de disputas on-chain en comparación con el diseño anterior de BitVM2, con una transacción de aserción que cuesta alrededor de 5 dólares y una transacción de refutación por menos de 0,20 dólares. Ese es el beneficio visible: economía on-chain barata, utilizable y ejecutable para algo que antes era prohibitivo por su costo al momento de disputar.
El costo “habita” detrás de las paredes. Lograr esa reducción implica mover la mayor parte de la computación por completo fuera de Bitcoin, hacia circuitos ofuscados (garbled circuits) que un retador evalúa fuera de la cadena, en lugar de publicarlos en la blockchain pieza por pieza. Una revisión técnica independiente señala que estos circuitos ocupan decenas de gigabytes y dependen de infraestructura de servidor ordinaria para almacenar y transmitir, infraestructura que queda totalmente fuera de las garantías de seguridad de Bitcoin, un hecho que rara vez aparece en el titular.
Así que el diseño no eliminó la complejidad: la trasladó de una forma on-chain cara a una forma off-chain barata. Ese es un intercambio (trade-off) de ingeniería defendible para una capa base tan limitada como la de Bitcoin: la computación on-chain costosa nunca iba a escalar hasta un volumen real de DeFi, no importa cómo se estructuraran las tarifas. Ese único número —cinco dólares frente a una fracción de centavo— está haciendo mucho trabajo para que todo el modelo de bóvedas sea viable comercialmente a escala en Bitcoin.
El equipo de Babylon eligió la asequibilidad por encima de minimizar la superficie de confianza off-chain y, dadas las limitaciones de scripting de Bitcoin, eso parece ser el único intercambio que permite que las bóvedas funcionen a un costo utilizable.
@BabylonLabs_io $BABY #baby
$DEXE
La investigación de BitVM3 detrás de las bóvedas de Babylon informa una reducción aproximada de 1000 veces en los costos de disputas on-chain en comparación con el diseño anterior de BitVM2, con una transacción de aserción que cuesta alrededor de 5 dólares y una transacción de refutación por menos de 0,20 dólares. Ese es el beneficio visible: economía on-chain barata, utilizable y ejecutable para algo que antes era prohibitivo por su costo al momento de disputar.
El costo “habita” detrás de las paredes. Lograr esa reducción implica mover la mayor parte de la computación por completo fuera de Bitcoin, hacia circuitos ofuscados (garbled circuits) que un retador evalúa fuera de la cadena, en lugar de publicarlos en la blockchain pieza por pieza. Una revisión técnica independiente señala que estos circuitos ocupan decenas de gigabytes y dependen de infraestructura de servidor ordinaria para almacenar y transmitir, infraestructura que queda totalmente fuera de las garantías de seguridad de Bitcoin, un hecho que rara vez aparece en el titular.
Así que el diseño no eliminó la complejidad: la trasladó de una forma on-chain cara a una forma off-chain barata. Ese es un intercambio (trade-off) de ingeniería defendible para una capa base tan limitada como la de Bitcoin: la computación on-chain costosa nunca iba a escalar hasta un volumen real de DeFi, no importa cómo se estructuraran las tarifas. Ese único número —cinco dólares frente a una fracción de centavo— está haciendo mucho trabajo para que todo el modelo de bóvedas sea viable comercialmente a escala en Bitcoin.
El equipo de Babylon eligió la asequibilidad por encima de minimizar la superficie de confianza off-chain y, dadas las limitaciones de scripting de Bitcoin, eso parece ser el único intercambio que permite que las bóvedas funcionen a un costo utilizable.
@BabylonLabs_io $BABY #baby
$DEXE
Un compañero de clase entró en una universidad de primera línea mediante admisión por legado y todos asumieron que el título por sí solo garantizaría la carrera. Tres años después de graduarse, todavía estaba descubriendo cómo colocarse, igual que el resto de nosotros. La carta probó acceso, no resultados.
La lista de patrocinadores de Babylon se lee como una lista de verificación de fondos de venture capital cripto de primer nivel: una ronda semilla de 8 millones de dólares en enero de 2022 liderada por IDG Capital y Breyer Capital, una Serie A de 18 millones de dólares en diciembre de 2023 de Polychain Capital, Hack VC, Castle Island Ventures y Symbolic Capital, y una ronda de 70 millones de dólares en mayo de 2024 liderada por Paradigm con Hashkey Capital y Polychain devolviendo. La cantidad total recaudada ronda los 96 millones de dólares de inversores que también incluyen Binance Labs, Galaxy Digital y Amber Group. Ese capital y reputación realmente redujeron la fricción de la distribución; Babylon se integró con Bitget Wallet, OKX Wallet y Binance Earn mucho antes que muchos proyectos competidores de BTCFi, y los propios anuncios de la ronda de financiamiento generaron atención real del mercado cada vez. Pero el capital y las integraciones son entradas, no resultados. La divulgación de la vulnerabilidad de la extensión de voto BLS de enero de 2026 ocurrió en una empresa respaldada por todo lo anterior. Las preocupaciones de tokenomics sobre una concentración interna de aproximadamente el 66% surgieron por parte de miembros de la comunidad, a pesar de la lista de inversores, no por ella. El respaldo fuerte de VC predice con mucha más fiabilidad una pista más larga y un mejor acceso a la distribución que predice una ejecución impecable, y el propio historial de un año de operaciones de Babylon muestra tanto fortalezas como tropiezos ocurriendo bajo el mismo paraguas de financiación.
La lista de inversores de Babylon no es una garantía de resultados técnicos ni tokenómicos. Compró margen, credibilidad y distribución; ninguno de los cuales evitó las vulnerabilidades o las preocupaciones de concentración que de todos modos surgieron.
@BabylonLabs_io $BABY #baby
$DEXE
La lista de patrocinadores de Babylon se lee como una lista de verificación de fondos de venture capital cripto de primer nivel: una ronda semilla de 8 millones de dólares en enero de 2022 liderada por IDG Capital y Breyer Capital, una Serie A de 18 millones de dólares en diciembre de 2023 de Polychain Capital, Hack VC, Castle Island Ventures y Symbolic Capital, y una ronda de 70 millones de dólares en mayo de 2024 liderada por Paradigm con Hashkey Capital y Polychain devolviendo. La cantidad total recaudada ronda los 96 millones de dólares de inversores que también incluyen Binance Labs, Galaxy Digital y Amber Group. Ese capital y reputación realmente redujeron la fricción de la distribución; Babylon se integró con Bitget Wallet, OKX Wallet y Binance Earn mucho antes que muchos proyectos competidores de BTCFi, y los propios anuncios de la ronda de financiamiento generaron atención real del mercado cada vez. Pero el capital y las integraciones son entradas, no resultados. La divulgación de la vulnerabilidad de la extensión de voto BLS de enero de 2026 ocurrió en una empresa respaldada por todo lo anterior. Las preocupaciones de tokenomics sobre una concentración interna de aproximadamente el 66% surgieron por parte de miembros de la comunidad, a pesar de la lista de inversores, no por ella. El respaldo fuerte de VC predice con mucha más fiabilidad una pista más larga y un mejor acceso a la distribución que predice una ejecución impecable, y el propio historial de un año de operaciones de Babylon muestra tanto fortalezas como tropiezos ocurriendo bajo el mismo paraguas de financiación.
La lista de inversores de Babylon no es una garantía de resultados técnicos ni tokenómicos. Compró margen, credibilidad y distribución; ninguno de los cuales evitó las vulnerabilidades o las preocupaciones de concentración que de todos modos surgieron.
@BabylonLabs_io $BABY #baby
$DEXE
Una aerolínea de bajo costo cerca de mí lanzó una campaña con vallas que decían "volamos a todas partes". El mapa de rutas real en el lanzamiento cubría seis ciudades: ninguna ruta internacional, y la mitad del mapa nacional tenía la etiqueta de "próximamente". Aún pienso en lo seguro que imprimieron "todas partes" antes de que el calendario lo respaldara.
El lanzamiento de la app móvil de GRVT utilizó un lenguaje similar. Cuando la app de Android llegó a Google Play el 29 de mayo de 2025, el comunicado de prensa la describió como llevar "todo el poder de la plataforma de trading de GRVT a usuarios de todo el mundo, al alcance de sus dedos", y la cita del CEO hablaba de convertir a GRVT en "el mercado financiero onchain definitivo, uno donde todos puedan acceder fácilmente a herramientas potentes". El despliegue real en ese momento era solo para Android, disponible en 50 países específicos mencionados en el anuncio, lugares como Argentina, Japón, Corea del Sur y Vietnam, entre otros; no era un lanzamiento global. La versión de iOS no formaba parte de ese lanzamiento: el comunicado indicó que llegaría "en su momento" sin una fecha comprometida. Cualquiera que leyera "de todo el mundo" y "todos" el día del lanzamiento y luego revisara la App Store para iPhone no habría encontrado nada para descargar. Ambas plataformas ya están en línea ahora, aproximadamente un año después, y es probable que la lista de 50 países haya crecido, pero la brecha en el mismo día del lanzamiento fue real: un titular de "de todo el mundo, todos" apoyado en un lanzamiento de una sola plataforma con una lista fija de países y una app hermana sin fecha programada. Eso no es inusual cuando una startup va enviando el producto por etapas: la mayoría de las empresas escalonan el lanzamiento y, en marketing, hablan del destino más que del paso actual. La falta de coincidencia importa porque "de todo el mundo" y "todos" son palabras absolutas, y las palabras absolutas invitan a que alguien las contraste con la lista real, como hice yo al comprobar el mapa de esa aerolínea frente a sus vallas.
El lenguaje del lanzamiento móvil de GRVT de "de todo el mundo, todos" no coincidió con su alcance del día uno: un lanzamiento solo para Android en 50 países nombrados, con iOS sin programación, una brecha que vale la pena mencionar en cualquier afirmación de lanzamiento.
@grvt_io #grvt
$LAB $VELVET
El lanzamiento de la app móvil de GRVT utilizó un lenguaje similar. Cuando la app de Android llegó a Google Play el 29 de mayo de 2025, el comunicado de prensa la describió como llevar "todo el poder de la plataforma de trading de GRVT a usuarios de todo el mundo, al alcance de sus dedos", y la cita del CEO hablaba de convertir a GRVT en "el mercado financiero onchain definitivo, uno donde todos puedan acceder fácilmente a herramientas potentes". El despliegue real en ese momento era solo para Android, disponible en 50 países específicos mencionados en el anuncio, lugares como Argentina, Japón, Corea del Sur y Vietnam, entre otros; no era un lanzamiento global. La versión de iOS no formaba parte de ese lanzamiento: el comunicado indicó que llegaría "en su momento" sin una fecha comprometida. Cualquiera que leyera "de todo el mundo" y "todos" el día del lanzamiento y luego revisara la App Store para iPhone no habría encontrado nada para descargar. Ambas plataformas ya están en línea ahora, aproximadamente un año después, y es probable que la lista de 50 países haya crecido, pero la brecha en el mismo día del lanzamiento fue real: un titular de "de todo el mundo, todos" apoyado en un lanzamiento de una sola plataforma con una lista fija de países y una app hermana sin fecha programada. Eso no es inusual cuando una startup va enviando el producto por etapas: la mayoría de las empresas escalonan el lanzamiento y, en marketing, hablan del destino más que del paso actual. La falta de coincidencia importa porque "de todo el mundo" y "todos" son palabras absolutas, y las palabras absolutas invitan a que alguien las contraste con la lista real, como hice yo al comprobar el mapa de esa aerolínea frente a sus vallas.
El lenguaje del lanzamiento móvil de GRVT de "de todo el mundo, todos" no coincidió con su alcance del día uno: un lanzamiento solo para Android en 50 países nombrados, con iOS sin programación, una brecha que vale la pena mencionar en cualquier afirmación de lanzamiento.
@grvt_io #grvt
$LAB $VELVET
Una vez descargué la versión móvil de una aplicación de trading que ya usaba en escritorio, esperando el mismo conjunto de herramientas exacto en el bolsillo. La mitad de los tipos de órdenes en los que confiaba a diario simplemente no aparecían en la pantalla del teléfono, y tenía que seguir cambiando de vuelta a una laptop para cualquier cosa más allá de una orden de mercado básica.
GRVT lanzó sus apps de Android e iOS financiadas en parte por los 14,3 millones de dólares que la empresa había recaudado para enero de 2025, una ronda que incluyó un cheque estratégico de 5 millones de dólares de Further Ventures, una firma respaldada por el fondo soberano de Abu Dabi, ADQ. En el lanzamiento, las apps móviles admitían más de 40 pares de trading perpetuos, una porción importante de los aproximadamente 168 mercados disponibles a través de la plataforma completa, pero lejos del catálogo completo. La diferencia entre "GRVT es una plataforma completa de trading con autocustodia" y "la app móvil de GRVT cubre un subconjunto de lo que la plataforma realmente lista" importa para cualquiera que asuma que existe paridad automática entre la experiencia de la tienda de apps y la del escritorio. Un trader que gestione posiciones en pares especializados fuera de esos primeros 40 quizá tenga que recurrir a un navegador igualmente, incluso después de descargar la app específicamente para operar en movimiento. Es probable que la cobertura móvil se haya ampliado desde ese conteo inicial, dado lo rápido que ha crecido la lista general de mercado en toda la plataforma, pero la brecha fundacional entre la completitud publicitada y la completitud entregada vale la pena tenerla en cuenta antes de asumir que cualquier función existe en cada superficie que toca la marca. La misma ronda de financiación que pagó por las apps también respaldó el trabajo de infraestructura central, lo que significa que el desarrollo móvil compitió por recursos con el back end del exchange en lugar de funcionar, desde el día uno, como una vía totalmente independiente y dotada de personal.
Las apps móviles de GRVT no son simplemente una ventana más pequeña hacia la misma plataforma completa: se entregaron más reducidas que la experiencia de escritorio. Conviene revisarlo antes de depender del teléfono para cualquier cosa más allá de los pares más comunes.
@grvt_io #grvt
$LAB
GRVT lanzó sus apps de Android e iOS financiadas en parte por los 14,3 millones de dólares que la empresa había recaudado para enero de 2025, una ronda que incluyó un cheque estratégico de 5 millones de dólares de Further Ventures, una firma respaldada por el fondo soberano de Abu Dabi, ADQ. En el lanzamiento, las apps móviles admitían más de 40 pares de trading perpetuos, una porción importante de los aproximadamente 168 mercados disponibles a través de la plataforma completa, pero lejos del catálogo completo. La diferencia entre "GRVT es una plataforma completa de trading con autocustodia" y "la app móvil de GRVT cubre un subconjunto de lo que la plataforma realmente lista" importa para cualquiera que asuma que existe paridad automática entre la experiencia de la tienda de apps y la del escritorio. Un trader que gestione posiciones en pares especializados fuera de esos primeros 40 quizá tenga que recurrir a un navegador igualmente, incluso después de descargar la app específicamente para operar en movimiento. Es probable que la cobertura móvil se haya ampliado desde ese conteo inicial, dado lo rápido que ha crecido la lista general de mercado en toda la plataforma, pero la brecha fundacional entre la completitud publicitada y la completitud entregada vale la pena tenerla en cuenta antes de asumir que cualquier función existe en cada superficie que toca la marca. La misma ronda de financiación que pagó por las apps también respaldó el trabajo de infraestructura central, lo que significa que el desarrollo móvil compitió por recursos con el back end del exchange en lugar de funcionar, desde el día uno, como una vía totalmente independiente y dotada de personal.
Las apps móviles de GRVT no son simplemente una ventana más pequeña hacia la misma plataforma completa: se entregaron más reducidas que la experiencia de escritorio. Conviene revisarlo antes de depender del teléfono para cualquier cosa más allá de los pares más comunes.
@grvt_io #grvt
$LAB
El edificio de oficinas en el que solía trabajar tenía un proceso normal para cualquier renovación: presentar una solicitud, esperar a un comité de revisión, obtener un permiso y, luego, esperar un período de notificación obligatorio antes de que los equipos pudieran tocar cualquier elemento estructural. Había exactamente una excepción a todo ese proceso: un panel de seguridad contra incendios que unos pocos miembros del personal directivo podían activar de inmediato durante una emergencia activa, sin período de espera, sin comité; la acción podía realizarse en minutos.
La estructura de gobernanza de ZKsync, a la que pertenece la cadena de GRVT, tiene una excepción similar incorporada. Las mejoras ordinarias del protocolo conllevan un retraso obligatorio de aproximadamente 4 días 3 horas hasta 8 días 3 horas antes de que puedan ejecutarse, lo que brinda tiempo a la comunidad para detectar y reaccionar ante cualquier cosa sospechosa en un cambio de código propuesto. Pero hay una única vía alternativa para eludir por completo ese período de espera: el Emergency Upgrade Board, formado por el Security Council, los Guardians y el ZK Foundation Multisig actuando conjuntamente, puede impulsar una actualización de inmediato, sin ningún retraso. Ese mecanismo existe por una razón real: una vulnerabilidad crítica descubierta a mitad de un ataque no puede esperar 4 días a que haya una ventana de revisión comunitaria antes de que se corrija. Pero la misma vía rápida que permite al equipo detener un exploit activo en minutos es, por diseño, también una forma de que un pequeño grupo coordinado impulse un cambio de contrato con cero aviso público si alguna vez lo decidiera. Nada sobre el mecanismo en sí le indica a observadores externos qué escenario está ocurriendo realmente en cualquier momento en que se activa.
Si el Emergency Upgrade Board es una válvula de seguridad necesaria o un riesgo de centralización depende por completo de la situación en la que se use, y los usuarios de GRVT no tienen forma de distinguir una corrección de emergencia de una impulsada con prisa hasta después de los hechos. Ninguna de las dos lecturas está completamente equivocada, y la postura honesta es que el intercambio no se ha resuelto, solo se ha aceptado como el costo de moverse rápido cuando importa.
@grvt_io #grvt
$LAB
La estructura de gobernanza de ZKsync, a la que pertenece la cadena de GRVT, tiene una excepción similar incorporada. Las mejoras ordinarias del protocolo conllevan un retraso obligatorio de aproximadamente 4 días 3 horas hasta 8 días 3 horas antes de que puedan ejecutarse, lo que brinda tiempo a la comunidad para detectar y reaccionar ante cualquier cosa sospechosa en un cambio de código propuesto. Pero hay una única vía alternativa para eludir por completo ese período de espera: el Emergency Upgrade Board, formado por el Security Council, los Guardians y el ZK Foundation Multisig actuando conjuntamente, puede impulsar una actualización de inmediato, sin ningún retraso. Ese mecanismo existe por una razón real: una vulnerabilidad crítica descubierta a mitad de un ataque no puede esperar 4 días a que haya una ventana de revisión comunitaria antes de que se corrija. Pero la misma vía rápida que permite al equipo detener un exploit activo en minutos es, por diseño, también una forma de que un pequeño grupo coordinado impulse un cambio de contrato con cero aviso público si alguna vez lo decidiera. Nada sobre el mecanismo en sí le indica a observadores externos qué escenario está ocurriendo realmente en cualquier momento en que se activa.
Si el Emergency Upgrade Board es una válvula de seguridad necesaria o un riesgo de centralización depende por completo de la situación en la que se use, y los usuarios de GRVT no tienen forma de distinguir una corrección de emergencia de una impulsada con prisa hasta después de los hechos. Ninguna de las dos lecturas está completamente equivocada, y la postura honesta es que el intercambio no se ha resuelto, solo se ha aceptado como el costo de moverse rápido cuando importa.
@grvt_io #grvt
$LAB
GRVT se comercializa en torno a la custodia propia: los fondos nunca se mantienen en manos de un tercero, y el control recae en el trader. Su fondo de seguro complica discretamente esa narrativa. Cuando una posición liquidada se cierra a un precio peor que su precio de quiebra, la diferencia tiene que salir de algún lado, y en GRVT, como en casi cualquier exchange con apalancamiento, ese origen es un fondo común financiado con el capital de todos los traders de la plataforma a través de las comisiones de liquidación.
Ese fondo es, funcionalmente, riesgo de contraparte mancomunado. Si el fondo de seguro se queda sin liquidez durante un evento extremo, el respaldo pasa a ser la auto reducción de apalancamiento (auto deleveraging), donde los traders rentables pueden ver sus posiciones ganadoras cerradas forzosamente para cubrir el déficit de otra persona. Ningún mecanismo tiene que ver con quién tiene las llaves privadas de tu colateral. La custodia propia protege tus activos de la empresa GRVT; no hace nada para proteger tu PnL abierto de la realidad matemática de que los derivados con apalancamiento requieren alguna forma de socialización de pérdidas cuando una posición quiebra más rápido de lo que puede cerrarse.
Esto no es una falla exclusiva de GRVT; cada plataforma seria de perpetuos funciona así. Pero significa que las afirmaciones sobre custodia propia y las del fondo de seguro responden a dos preguntas distintas. Una es sobre la custodia de tu capital. La otra es sobre quién absorbe la pérdida cuando el mercado se mueve más rápido de lo que el motor de liquidaciones puede reaccionar, y la custodia propia nunca iba a resolver por sí sola esa segunda pregunta. Pienso en esto cada vez que un proyecto se vende de manera puramente enfocada en la custodia propia sin mencionar el fondo de seguro en la misma frase, porque los dos mecanismos responden a preguntas de riesgo completamente diferentes y confundirlas deja al trader con una falsa sensación de cuán protegidas están realmente sus ganancias no realizadas durante un evento extremo real en cualquier venue con apalancamiento, incluido GRVT.
@grvt_io #grvt
$LAB
Ese fondo es, funcionalmente, riesgo de contraparte mancomunado. Si el fondo de seguro se queda sin liquidez durante un evento extremo, el respaldo pasa a ser la auto reducción de apalancamiento (auto deleveraging), donde los traders rentables pueden ver sus posiciones ganadoras cerradas forzosamente para cubrir el déficit de otra persona. Ningún mecanismo tiene que ver con quién tiene las llaves privadas de tu colateral. La custodia propia protege tus activos de la empresa GRVT; no hace nada para proteger tu PnL abierto de la realidad matemática de que los derivados con apalancamiento requieren alguna forma de socialización de pérdidas cuando una posición quiebra más rápido de lo que puede cerrarse.
Esto no es una falla exclusiva de GRVT; cada plataforma seria de perpetuos funciona así. Pero significa que las afirmaciones sobre custodia propia y las del fondo de seguro responden a dos preguntas distintas. Una es sobre la custodia de tu capital. La otra es sobre quién absorbe la pérdida cuando el mercado se mueve más rápido de lo que el motor de liquidaciones puede reaccionar, y la custodia propia nunca iba a resolver por sí sola esa segunda pregunta. Pienso en esto cada vez que un proyecto se vende de manera puramente enfocada en la custodia propia sin mencionar el fondo de seguro en la misma frase, porque los dos mecanismos responden a preguntas de riesgo completamente diferentes y confundirlas deja al trader con una falsa sensación de cuán protegidas están realmente sus ganancias no realizadas durante un evento extremo real en cualquier venue con apalancamiento, incluido GRVT.
@grvt_io #grvt
$LAB
Inicia sesión para explorar más contenidos