Nova_eth_20
422 Publicaciones
Nova_eth_20
129 Siguiendo
1.5K+ Seguidores
450 Me gusta
Publicaciones
Todo
Cotizaciones
#baby $BABY @BabylonLabs_io
Estaba comparando validadores para mi delegación de BABY y casi me salté el “encarcelamiento” (jailing), que es el boilerplate estándar de Cosmos que tiene cualquier cadena: faltas de bloques, tiempo de espera temporal, nada específico para Babylon. Luego leí que los validadores realmente firman dos veces, no una.
Cada validador de Genesis de Babylon hace dos trabajos separados. Firmado de bloques CometBFT normal, el trabajo habitual que hace cualquier validador de Cosmos, y uno segundo: votación BLS al final de cada época (epoch), donde las firmas del validador se agregan en un checkpoint que se marca con una marca de tiempo directamente en Bitcoin. Esa segunda firma es la razón completa por la que la gente llama a esta cadena “asegurada por Bitcoin”.
El encarcelamiento por indisponibilidad (downtime jailing) solo se fija en el primer trabajo, en sus propios términos, una exigencia estándar de vivacidad, nada dramático. Lo que no pude precisar con exactitud es la interacción exacta: si un encarcelamiento que cae a mitad de una época descalifica en silencio la contribución BLS de toda esa época, o si solo importa cuando aún está activo en el momento en que termina la época. La documentación de Babylon confirma que los dos trabajos están separados. No especifica en ningún lugar que encontré ese límite temporal concreto.
De todos modos, los dos trabajos comparten un único registro de disponibilidad (uptime). Un validador encarcelado por bloques perdidos ordinarios, la misma regla que ejecuta cualquier cadena de Cosmos, no queda protegido de también perder la firma que en realidad se ancla a Bitcoin en esa época, por un motivo que no tiene nada que ver con la seguridad de Bitcoin.
No creo que sea un fallo de diseño; no hay una forma limpia de encarcelar a alguien de un rol y no del otro con la misma clave. Lo que no había separado en mi cabeza antes de esto es que el historial de indisponibilidad no es solo sobre recompensas perdidas. Es un indicador aproximado de la frecuencia con la que un validador estuvo realmente presente para la firma que hace que “asegurada por Bitcoin” sea verdad.
Volví a revisar el historial de encarcelamiento de mi lista corta. Dos nombres tenían una entrada cada uno: ambos con más de un año, y ambos seguidos de largos tramos limpios. No es una bandera roja. Solo que no era el mismo “cero” que yo asumía que un porcentaje limpio de uptime ya me estaba diciendo.
$BLESS
🤔 ¿Qué es lo primero que verificas antes de delegar a tu bebé?
Estaba comparando validadores para mi delegación de BABY y casi me salté el “encarcelamiento” (jailing), que es el boilerplate estándar de Cosmos que tiene cualquier cadena: faltas de bloques, tiempo de espera temporal, nada específico para Babylon. Luego leí que los validadores realmente firman dos veces, no una.
Cada validador de Genesis de Babylon hace dos trabajos separados. Firmado de bloques CometBFT normal, el trabajo habitual que hace cualquier validador de Cosmos, y uno segundo: votación BLS al final de cada época (epoch), donde las firmas del validador se agregan en un checkpoint que se marca con una marca de tiempo directamente en Bitcoin. Esa segunda firma es la razón completa por la que la gente llama a esta cadena “asegurada por Bitcoin”.
El encarcelamiento por indisponibilidad (downtime jailing) solo se fija en el primer trabajo, en sus propios términos, una exigencia estándar de vivacidad, nada dramático. Lo que no pude precisar con exactitud es la interacción exacta: si un encarcelamiento que cae a mitad de una época descalifica en silencio la contribución BLS de toda esa época, o si solo importa cuando aún está activo en el momento en que termina la época. La documentación de Babylon confirma que los dos trabajos están separados. No especifica en ningún lugar que encontré ese límite temporal concreto.
De todos modos, los dos trabajos comparten un único registro de disponibilidad (uptime). Un validador encarcelado por bloques perdidos ordinarios, la misma regla que ejecuta cualquier cadena de Cosmos, no queda protegido de también perder la firma que en realidad se ancla a Bitcoin en esa época, por un motivo que no tiene nada que ver con la seguridad de Bitcoin.
No creo que sea un fallo de diseño; no hay una forma limpia de encarcelar a alguien de un rol y no del otro con la misma clave. Lo que no había separado en mi cabeza antes de esto es que el historial de indisponibilidad no es solo sobre recompensas perdidas. Es un indicador aproximado de la frecuencia con la que un validador estuvo realmente presente para la firma que hace que “asegurada por Bitcoin” sea verdad.
Volví a revisar el historial de encarcelamiento de mi lista corta. Dos nombres tenían una entrada cada uno: ambos con más de un año, y ambos seguidos de largos tramos limpios. No es una bandera roja. Solo que no era el mismo “cero” que yo asumía que un porcentaje limpio de uptime ya me estaba diciendo.
$BLESS
🤔 ¿Qué es lo primero que verificas antes de delegar a tu bebé?
Validator uptime 📈
34%
Jailing history 🚨
0%
Commission fees 💰
33%
Reputation & community 🌟
33%
3 Votos • Votación cerrada
$CYS
Mù 穆涵
·
--
$BABY #baby @BabylonLabs_io
Elegí un proveedor de finality basándome en su tamaño de delegación de BTC y su historial de disponibilidad, los números que muestra cualquier panel. Solo después leí qué es lo que realmente mantiene a ese proveedor funcionando día a día, y resulta que no es el BTC.
Todo proveedor de finality necesita una clave de operación separada financiada con BABY, con importes pequeños, usada para pagar el gas al comprometer aleatoriedad fresca en un cronograma recurrente. Las presentaciones de votos se reembolsan automáticamente; la propia documentación de operadores de Babylon confirma que eso es así directamente. Otras transacciones en esa misma clave, incluidas las confirmaciones recurrentes de aleatoriedad, requieren gas que no regresa. La documentación lo describe casi como un detalle menor: financíala con un monto mínimo, mantenla funcionando mucho tiempo, una sola frase junto a la maquinaria de seguridad que yo en realidad estaba buscando.
Si no haces ese reabastecimiento, el proveedor no queda comprometido en secreto: su delegación de BTC sigue siendo exactamente igual de grande y honesta que ayer. Solo que ya no puede seguir participando hasta que alguien note una cartera vacía y la vuelva a llenar. Un proveedor puede ser impecable en cada métrica que verifiqué antes de delegar y aun así apagarse por algo tan pequeño como una clave de gas que nadie recordó reabastecer.
Los paneles de delegación muestran comisión, tamaño de la delegación e historial de disponibilidad. Ninguno muestra si la clave de operación de un proveedor está financiada cómodamente o funcionando con lo justo, porque ese número nunca estuvo pensado para hacerse público en primer lugar.
No creo que sea una falla de diseño: mantener la clave de operación mínima y separada de las tenencias reales de un proveedor es una decisión razonable de seguridad, no negligencia. Lo que significa para cualquiera que delega es más pequeño: el proveedor que elegiste por su historial de BTC también, silenciosamente, está en el negocio de recordar comprar gas.
$HEI
¿Sabías que la clave de operación de un proveedor de finality puede agotarse incluso mientras su delegación de BTC se ve perfectamente saludable?
Elegí un proveedor de finality basándome en su tamaño de delegación de BTC y su historial de disponibilidad, los números que muestra cualquier panel. Solo después leí qué es lo que realmente mantiene a ese proveedor funcionando día a día, y resulta que no es el BTC.
Todo proveedor de finality necesita una clave de operación separada financiada con BABY, con importes pequeños, usada para pagar el gas al comprometer aleatoriedad fresca en un cronograma recurrente. Las presentaciones de votos se reembolsan automáticamente; la propia documentación de operadores de Babylon confirma que eso es así directamente. Otras transacciones en esa misma clave, incluidas las confirmaciones recurrentes de aleatoriedad, requieren gas que no regresa. La documentación lo describe casi como un detalle menor: financíala con un monto mínimo, mantenla funcionando mucho tiempo, una sola frase junto a la maquinaria de seguridad que yo en realidad estaba buscando.
Si no haces ese reabastecimiento, el proveedor no queda comprometido en secreto: su delegación de BTC sigue siendo exactamente igual de grande y honesta que ayer. Solo que ya no puede seguir participando hasta que alguien note una cartera vacía y la vuelva a llenar. Un proveedor puede ser impecable en cada métrica que verifiqué antes de delegar y aun así apagarse por algo tan pequeño como una clave de gas que nadie recordó reabastecer.
Los paneles de delegación muestran comisión, tamaño de la delegación e historial de disponibilidad. Ninguno muestra si la clave de operación de un proveedor está financiada cómodamente o funcionando con lo justo, porque ese número nunca estuvo pensado para hacerse público en primer lugar.
No creo que sea una falla de diseño: mantener la clave de operación mínima y separada de las tenencias reales de un proveedor es una decisión razonable de seguridad, no negligencia. Lo que significa para cualquiera que delega es más pequeño: el proveedor que elegiste por su historial de BTC también, silenciosamente, está en el negocio de recordar comprar gas.
$HEI
¿Sabías que la clave de operación de un proveedor de finality puede agotarse incluso mientras su delegación de BTC se ve perfectamente saludable?
#baby @BabylonLabs_io
Leí una explicación de un recorte anoche mientras buscaba el número exacto de penalización de BTC. Lo encontré: el 0,1% de BTC en staking por doble firma. Luego vi la línea justo al lado de eso que no estaba buscando: las recompensas ganadas previamente no se recuperan.
El proveedor queda permanentemente prohibido, encarcelado para siempre, sin más delegaciones, sin más comisiones. Pero cualquier comisión que ya haya cobrado antes de la infracción se queda con ellos. La penalización se aplica hacia adelante desde el momento en que los detectan. No se retrotrae por todo el tiempo que estuvieron operando antes.
Para un proveedor totalmente nuevo, esa brecha apenas importa: todavía no hay nada acumulado para retener. Para uno que ha estado ejecutando delegaciones durante un año, ganando un recorte de comisiones en cada ciclo de recompensas durante todo ese tiempo, las matemáticas cambian. Un solo recorte del 0,1% afecta a todos los delegados que delegaron con ellos, proporcionalmente, tanto al proveedor como a los delegadores. Lo que no se toca es el historial de comisiones, por mucho que se hayan quedado con ello.
No sé cuánto ha ganado realmente cualquier proveedor individual durante su permanencia; eso no es público en ningún lugar que encontré, así que no puedo decirte si esa brecha es trivial o real. Lo que sí puedo decir es que el disuasivo se diseñó a propósito para que fuera solo hacia adelante. Recuperar recompensas históricas implicaría reabrir cada ciclo de recompensas pasado; sería un lío propio para diseñar alrededor.
Prohibido para siempre y arruinado son dos resultados distintos, y el diseño de slashing propio de Babylon solo garantiza el primero.
$CYS $BABY
Leí una explicación de un recorte anoche mientras buscaba el número exacto de penalización de BTC. Lo encontré: el 0,1% de BTC en staking por doble firma. Luego vi la línea justo al lado de eso que no estaba buscando: las recompensas ganadas previamente no se recuperan.
El proveedor queda permanentemente prohibido, encarcelado para siempre, sin más delegaciones, sin más comisiones. Pero cualquier comisión que ya haya cobrado antes de la infracción se queda con ellos. La penalización se aplica hacia adelante desde el momento en que los detectan. No se retrotrae por todo el tiempo que estuvieron operando antes.
Para un proveedor totalmente nuevo, esa brecha apenas importa: todavía no hay nada acumulado para retener. Para uno que ha estado ejecutando delegaciones durante un año, ganando un recorte de comisiones en cada ciclo de recompensas durante todo ese tiempo, las matemáticas cambian. Un solo recorte del 0,1% afecta a todos los delegados que delegaron con ellos, proporcionalmente, tanto al proveedor como a los delegadores. Lo que no se toca es el historial de comisiones, por mucho que se hayan quedado con ello.
No sé cuánto ha ganado realmente cualquier proveedor individual durante su permanencia; eso no es público en ningún lugar que encontré, así que no puedo decirte si esa brecha es trivial o real. Lo que sí puedo decir es que el disuasivo se diseñó a propósito para que fuera solo hacia adelante. Recuperar recompensas históricas implicaría reabrir cada ciclo de recompensas pasado; sería un lío propio para diseñar alrededor.
Prohibido para siempre y arruinado son dos resultados distintos, y el diseño de slashing propio de Babylon solo garantiza el primero.
$CYS $BABY
$BICO
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
Anoche comprobé la comisión de un proveedor de finalidad antes de delegar; 5%, me pareció razonable al lado de los demás de la lista. Casi delego solo con ese número. Luego descubrí el comando de registro que Babilonia realmente requiere.
Cada proveedor de finalidad establece tres números al registrarse, no uno. La tasa de comisión actual, una tasa máxima que nunca puede superar, y una tasa máxima de cambio: qué tan rápido se le permite subir hacia ese tope. El 5% que estaba mirando nunca era todo el panorama; era una instantánea en un dial con su propio tope separado y más alto incorporado desde el primer día.
Nada impide que un proveedor se registre con 5% y un tope máximo de 50%, y luego lo vaya subiendo en pasos legales pequeños en cada período hasta que los delegadores que entraron con 5% estén ganando con un número muy diferente. No se rompió ninguna regla, no hubo engaño: solo un techo que estuvo publicado todo el tiempo.
Fui a buscar dónde aparece realmente ese techo para un delegador que decide a quién elegir. Por lo que pude ver, la documentación de staking de Babilonia y la API que alimenta el panel muestran exactamente un campo en esa etapa: comisión; a menor comisión, mayores recompensas, y nada más granular que eso. No el tope máximo que aparece un campo después en los datos de registro del propio proveedor.
No creo que esto haga que el mecanismo sea depredador. Existe un tope de tasa de cambio precisamente para que la comisión no pueda saltar de la noche a la mañana, y esa protección es real. Lo que falta es algo menor: el número que realmente acota tus ganancias futuras nunca se construyó para llegar a la pantalla desde la que estás decidiendo. Los documentos no dicen cuántos proveedores activos ya se han movido desde su tasa inicial, ni qué tan cerca está cualquiera de ellos de su tope ahora mismo, así que no puedo decirte si esto es un riesgo en vivo o uno teórico.
El 5% que ves es una fotografía. El techo era siempre el acuerdo real.
¿Sabías que la comisión de tu proveedor de finalidad puede subir más allá del número que ves hoy? 📈
Anoche comprobé la comisión de un proveedor de finalidad antes de delegar; 5%, me pareció razonable al lado de los demás de la lista. Casi delego solo con ese número. Luego descubrí el comando de registro que Babilonia realmente requiere.
Cada proveedor de finalidad establece tres números al registrarse, no uno. La tasa de comisión actual, una tasa máxima que nunca puede superar, y una tasa máxima de cambio: qué tan rápido se le permite subir hacia ese tope. El 5% que estaba mirando nunca era todo el panorama; era una instantánea en un dial con su propio tope separado y más alto incorporado desde el primer día.
Nada impide que un proveedor se registre con 5% y un tope máximo de 50%, y luego lo vaya subiendo en pasos legales pequeños en cada período hasta que los delegadores que entraron con 5% estén ganando con un número muy diferente. No se rompió ninguna regla, no hubo engaño: solo un techo que estuvo publicado todo el tiempo.
Fui a buscar dónde aparece realmente ese techo para un delegador que decide a quién elegir. Por lo que pude ver, la documentación de staking de Babilonia y la API que alimenta el panel muestran exactamente un campo en esa etapa: comisión; a menor comisión, mayores recompensas, y nada más granular que eso. No el tope máximo que aparece un campo después en los datos de registro del propio proveedor.
No creo que esto haga que el mecanismo sea depredador. Existe un tope de tasa de cambio precisamente para que la comisión no pueda saltar de la noche a la mañana, y esa protección es real. Lo que falta es algo menor: el número que realmente acota tus ganancias futuras nunca se construyó para llegar a la pantalla desde la que estás decidiendo. Los documentos no dicen cuántos proveedores activos ya se han movido desde su tasa inicial, ni qué tan cerca está cualquiera de ellos de su tope ahora mismo, así que no puedo decirte si esto es un riesgo en vivo o uno teórico.
El 5% que ves es una fotografía. El techo era siempre el acuerdo real.
¿Sabías que la comisión de tu proveedor de finalidad puede subir más allá del número que ves hoy? 📈
#baby @BabylonLabs_io
Ahora mismo tengo BTC apostado a través de Babylon, así que cuando anoche encontré la palabra "overflow" enterrada en la documentación antigua del Cap-3, no la leí como historia. La leí como una pregunta sobre mi propia situación: ¿podría pasarme a mí.
Durante la Fase 1, las transacciones de staking que se confirmaban después de que el límite ya se hubiera llenado igual bloqueaban el BTC en el contrato exactamente igual que a todos los demás. Simplemente no ganaron nada, ningún punto, ninguna asignación. Además, recuperar las monedas tampoco era automático: los documentos son explícitos. Las apuestas por overflow todavía tenían que desabonarse y retirarse, con el mismo tiempo de espera que una posición activa, para un staking que pagó cero durante todo el tiempo que permaneció bloqueado.
Lo que decidió quién entraba no fue cuándo alguien hizo clic en apostar. Fue en qué bloque de Bitcoin se confirmó realmente la transacción, un número que nadie controla del todo una vez que sale de la cartera. Dos personas podían emitir la transacción con minutos de diferencia y quedar en cualquier orden dependiendo de las tarifas, la congestión del mempool o de qué minero encontrara primero el siguiente bloque.
Los topes de la Fase 1 ya se acabaron, pero el mecanismo que creó el overflow no es exclusivo de esa fase. Cualquier ronda futura con tope, un nuevo onboarding de BSN con una asignación fija, una integración con plazas limitadas, hereda la misma carrera en el momento en que usa confirmaciones de bloques en lugar de una cola. Nada de ese fallo de diseño fue corregido. Simplemente se quedó atrás cuando desaparecieron los topes.
No creo que el diseño original fuera injusto: un hard cap necesita algún corte, y la confirmación de bloques no se puede falsificar como sí puede hacerse con una marca de tiempo. Lo que me queda es algo más pequeño: mi propio BTC, que ahora mismo está bloqueado, nunca estuvo protegido por habilidad o por buen timing. Cruzó una línea trazada por los mineros, no por mí, y la próxima vez que se trace esa línea, seguirá pasando.
$SKYAI $BICO $BABY
"¿Te impediría ese riesgo de overflow hacer staking en una ronda futura con tope?" 🎯
Ahora mismo tengo BTC apostado a través de Babylon, así que cuando anoche encontré la palabra "overflow" enterrada en la documentación antigua del Cap-3, no la leí como historia. La leí como una pregunta sobre mi propia situación: ¿podría pasarme a mí.
Durante la Fase 1, las transacciones de staking que se confirmaban después de que el límite ya se hubiera llenado igual bloqueaban el BTC en el contrato exactamente igual que a todos los demás. Simplemente no ganaron nada, ningún punto, ninguna asignación. Además, recuperar las monedas tampoco era automático: los documentos son explícitos. Las apuestas por overflow todavía tenían que desabonarse y retirarse, con el mismo tiempo de espera que una posición activa, para un staking que pagó cero durante todo el tiempo que permaneció bloqueado.
Lo que decidió quién entraba no fue cuándo alguien hizo clic en apostar. Fue en qué bloque de Bitcoin se confirmó realmente la transacción, un número que nadie controla del todo una vez que sale de la cartera. Dos personas podían emitir la transacción con minutos de diferencia y quedar en cualquier orden dependiendo de las tarifas, la congestión del mempool o de qué minero encontrara primero el siguiente bloque.
Los topes de la Fase 1 ya se acabaron, pero el mecanismo que creó el overflow no es exclusivo de esa fase. Cualquier ronda futura con tope, un nuevo onboarding de BSN con una asignación fija, una integración con plazas limitadas, hereda la misma carrera en el momento en que usa confirmaciones de bloques en lugar de una cola. Nada de ese fallo de diseño fue corregido. Simplemente se quedó atrás cuando desaparecieron los topes.
No creo que el diseño original fuera injusto: un hard cap necesita algún corte, y la confirmación de bloques no se puede falsificar como sí puede hacerse con una marca de tiempo. Lo que me queda es algo más pequeño: mi propio BTC, que ahora mismo está bloqueado, nunca estuvo protegido por habilidad o por buen timing. Cruzó una línea trazada por los mineros, no por mí, y la próxima vez que se trace esa línea, seguirá pasando.
$SKYAI $BICO $BABY
"¿Te impediría ese riesgo de overflow hacer staking en una ronda futura con tope?" 🎯
😰 Yeah, dealbreaker
34%
😌 Nah, worth the risk
33%
🤔 Depends on the cap size
33%
🙈 Didn't know this existed
0%
3 Votos • Votación cerrada
$BLESS
Mù 穆涵
·
--
$BABY $BLESS #baby
Bloqueé mi ratio de co-staking hace tres semanas: 20.000 BABY por cada BTC, el ratio recomendado por Babylon. Anoche revisé mis recompensas. Eran menores que la cifra que calculé el día que hice el stake.
Mi posición no se había movido ni un centímetro. Algo más sí.
El impulso de co-staking del 2,35% no es una tasa. Es un fondo de tamaño fijo, dividido proporcionalmente entre cada wallet que co-stakea justo en ese momento. Babylon lo dice tal cual en su propia documentación: a más co-stakers, recompensas individuales más pequeñas. Si aciertas el ratio a la perfección, tu parte real sigue dependiendo de cuántas otras wallets también lo hayan alcanzado, un número que cambia sin que tú toques tu posición.
No hay un panel que haga seguimiento en tiempo real de ese número. Puedes ver tu propio peso. No puedes ver cómo cambia el peso total del fondo debajo de él.
A diferencia de otros riesgos de Babylon que se esconden dentro de infraestructura faltante u operadores concentrados, este se oculta a plena vista: la fórmula es totalmente pública. Lo único que falta es quién más la está usando.
Hay una cosa que conviene vigilar: ese 2,35% no es un cimiento, es un número de gobernanza. Solo existe porque una propuesta de septiembre pasado dividió la inflación de Babylon en porciones fijas: 1% para stakers de BTC, 2% para stakers de BABY, 2,35% para co-stakers, y el resto se reparte en otros lugares. Una votación futura podría redimensionar esa porción de la misma forma en que esta la creó. Nadie ha propuesto reducirla todavía, así que esto sigue siendo un asiento que observas, no una mesa cuya permanencia esté garantizada.
Hay un segundo filo incorporado en la fórmula. El peso elegible se limita a lo que sea menor: tu BABY dividido entre 20.000, o tu BTC. Si te pasas del ratio, el BABY extra solo gana la tasa de staking normal. Si te quedas corto, solo una parte de tu BTC recibe el impulso.
Combinar BTC y BABY se diseñó para fortalecer ese vínculo, y un fondo compartido es una forma razonable de financiarlo. El diseño no es el problema. Lo que falta es poder ver que tu parte cambia antes de que ocurra.
Si has alcanzado el ratio exactamente como yo, no estás ganando un 2,35% fijo. Estás alquilando un asiento en una mesa que se llena más y más a su propio ritmo, con gente a la que nunca verás llegar.
Bloqueé mi ratio de co-staking hace tres semanas: 20.000 BABY por cada BTC, el ratio recomendado por Babylon. Anoche revisé mis recompensas. Eran menores que la cifra que calculé el día que hice el stake.
Mi posición no se había movido ni un centímetro. Algo más sí.
El impulso de co-staking del 2,35% no es una tasa. Es un fondo de tamaño fijo, dividido proporcionalmente entre cada wallet que co-stakea justo en ese momento. Babylon lo dice tal cual en su propia documentación: a más co-stakers, recompensas individuales más pequeñas. Si aciertas el ratio a la perfección, tu parte real sigue dependiendo de cuántas otras wallets también lo hayan alcanzado, un número que cambia sin que tú toques tu posición.
No hay un panel que haga seguimiento en tiempo real de ese número. Puedes ver tu propio peso. No puedes ver cómo cambia el peso total del fondo debajo de él.
A diferencia de otros riesgos de Babylon que se esconden dentro de infraestructura faltante u operadores concentrados, este se oculta a plena vista: la fórmula es totalmente pública. Lo único que falta es quién más la está usando.
Hay una cosa que conviene vigilar: ese 2,35% no es un cimiento, es un número de gobernanza. Solo existe porque una propuesta de septiembre pasado dividió la inflación de Babylon en porciones fijas: 1% para stakers de BTC, 2% para stakers de BABY, 2,35% para co-stakers, y el resto se reparte en otros lugares. Una votación futura podría redimensionar esa porción de la misma forma en que esta la creó. Nadie ha propuesto reducirla todavía, así que esto sigue siendo un asiento que observas, no una mesa cuya permanencia esté garantizada.
Hay un segundo filo incorporado en la fórmula. El peso elegible se limita a lo que sea menor: tu BABY dividido entre 20.000, o tu BTC. Si te pasas del ratio, el BABY extra solo gana la tasa de staking normal. Si te quedas corto, solo una parte de tu BTC recibe el impulso.
Combinar BTC y BABY se diseñó para fortalecer ese vínculo, y un fondo compartido es una forma razonable de financiarlo. El diseño no es el problema. Lo que falta es poder ver que tu parte cambia antes de que ocurra.
Si has alcanzado el ratio exactamente como yo, no estás ganando un 2,35% fijo. Estás alquilando un asiento en una mesa que se llena más y más a su propio ritmo, con gente a la que nunca verás llegar.
#baby $BABY @BabylonLabs_io
Ahora mismo, la mitad de mi BTC está en staking a través de Babylon. Nunca una vez pregunté qué pasa con ella si, de golpe, se apaga la mitad del conjunto de validadores; hasta anoche, al leer la mitad del documento fundacional de Babylon que había omitido.
La validación por puntos de control en Bitcoin soluciona la seguridad. Con que un validador honesto envíe una prueba a Bitcoin basta para castigar a los mentirosos y decidir qué historial es real. La vivacidad es otra cuestión: ¿la cadena sigue produciendo bloques?
Esta es la parte que Bitcoin no puede tocar. Ningún protocolo de prueba de participación garantiza la vivacidad cuando validadores adversarios superan la mitad del conjunto activo. Ni con Bitcoin detrás, ni con cualquier servicio de datestamp — no a menos que los datos de cada validador se publiquen on-chain, y el rendimiento de Bitcoin nunca se diseñó para eso.
La prueba se mantiene frente a la malicia. No dice nada sobre validadores que simplemente dejan de aparecer. La cadena se estanca exactamente igual en cualquier caso, y Bitcoin no puede decirte cuál ocurrió.
"Asegurado por Bitcoin" suena como una sola garantía. Son dos. Bitcoin compra certeza sobre qué historial es verdadero. No compra una promesa de que la cadena siga avanzando si desaparece de golpe la mitad de los validadores — una caída, una salida, o un ataque que nadie detectó a tiempo.
Un comité que necesita un firmante honesto, un relé que necesita que al menos uno se mantenga en línea — eso se arregla con que haya más operadores presentes. Este techo está probado por matemáticas, no es un problema de personal. Apretar más la vigilancia no lo mueve.
Mi BTC está bloqueado de cualquier modo. Bitcoin me entregará un recibo para el momento exacto en que la cadena se detuvo. Volverla a hacer respirar nunca formó parte de la prueba.
$BLESS $HOME
Si esta noche la mitad de los validadores de Babylon se apagara, ¿qué pasa con tu BTC?
Ahora mismo, la mitad de mi BTC está en staking a través de Babylon. Nunca una vez pregunté qué pasa con ella si, de golpe, se apaga la mitad del conjunto de validadores; hasta anoche, al leer la mitad del documento fundacional de Babylon que había omitido.
La validación por puntos de control en Bitcoin soluciona la seguridad. Con que un validador honesto envíe una prueba a Bitcoin basta para castigar a los mentirosos y decidir qué historial es real. La vivacidad es otra cuestión: ¿la cadena sigue produciendo bloques?
Esta es la parte que Bitcoin no puede tocar. Ningún protocolo de prueba de participación garantiza la vivacidad cuando validadores adversarios superan la mitad del conjunto activo. Ni con Bitcoin detrás, ni con cualquier servicio de datestamp — no a menos que los datos de cada validador se publiquen on-chain, y el rendimiento de Bitcoin nunca se diseñó para eso.
La prueba se mantiene frente a la malicia. No dice nada sobre validadores que simplemente dejan de aparecer. La cadena se estanca exactamente igual en cualquier caso, y Bitcoin no puede decirte cuál ocurrió.
"Asegurado por Bitcoin" suena como una sola garantía. Son dos. Bitcoin compra certeza sobre qué historial es verdadero. No compra una promesa de que la cadena siga avanzando si desaparece de golpe la mitad de los validadores — una caída, una salida, o un ataque que nadie detectó a tiempo.
Un comité que necesita un firmante honesto, un relé que necesita que al menos uno se mantenga en línea — eso se arregla con que haya más operadores presentes. Este techo está probado por matemáticas, no es un problema de personal. Apretar más la vigilancia no lo mueve.
Mi BTC está bloqueado de cualquier modo. Bitcoin me entregará un recibo para el momento exacto en que la cadena se detuvo. Volverla a hacer respirar nunca formó parte de la prueba.
$BLESS $HOME
Si esta noche la mitad de los validadores de Babylon se apagara, ¿qué pasa con tu BTC?
🔐 Safety's covered, I'm fine
33%
🛑 Liveness could still stall
0%
🧊 Frozen either way
0%
⚡ Didn't know
67%
3 Votos • Votación cerrada
Con verificación
@BabylonLabs_io $BABY #baby
Cada vez que deshaces el unbond de BTC desde Babylon, hay nueve claves entre tu Bitcoin y tu wallet. Seis de ellas tienen que estar de acuerdo antes de que recuperes tus fondos.
Una de esas nueve pertenece a Babylon Labs.
La propuesta es "sin confianza": sin custodio, sin empresa que tenga tu BTC; solo Bitcoin Script que aplica las reglas. Y eso es real: ninguna clave puede tocar tus fondos por sí sola. Pero deshacer el unbond es la única puerta de vuelta a tus monedas antes de que se agote el timelock de 15 meses, y el equipo que construyó la puerta también posee una de las claves para abrirla.
Eso no es un escándalo. Las otras ocho claves están con entidades nombradas y reconocidas, y el comité solo puede aprobar o rechazar transacciones estándar; nunca se diseñó para poder huir con el BTC de alguien. Aun así, si lees con suficiente atención la documentación de Babylon, verás que el creador figura como firmante en el sistema que construyó, para no necesitar firmantes.
Pregunta a un participante (staker) de Babylon por qué movieron BTC al protocolo y "sin confianza" suele ser la primera palabra que sale de su boca. Pregúntales quién tiene la clave número uno, y la mayoría no sabrá que la respuesta es Babylon Labs.
$IDOL
¿Que el creador tenga una de las claves de desunbond cambie la forma en que ves "sin confianza"?
Cada vez que deshaces el unbond de BTC desde Babylon, hay nueve claves entre tu Bitcoin y tu wallet. Seis de ellas tienen que estar de acuerdo antes de que recuperes tus fondos.
Una de esas nueve pertenece a Babylon Labs.
La propuesta es "sin confianza": sin custodio, sin empresa que tenga tu BTC; solo Bitcoin Script que aplica las reglas. Y eso es real: ninguna clave puede tocar tus fondos por sí sola. Pero deshacer el unbond es la única puerta de vuelta a tus monedas antes de que se agote el timelock de 15 meses, y el equipo que construyó la puerta también posee una de las claves para abrirla.
Eso no es un escándalo. Las otras ocho claves están con entidades nombradas y reconocidas, y el comité solo puede aprobar o rechazar transacciones estándar; nunca se diseñó para poder huir con el BTC de alguien. Aun así, si lees con suficiente atención la documentación de Babylon, verás que el creador figura como firmante en el sistema que construyó, para no necesitar firmantes.
Pregunta a un participante (staker) de Babylon por qué movieron BTC al protocolo y "sin confianza" suele ser la primera palabra que sale de su boca. Pregúntales quién tiene la clave número uno, y la mayoría no sabrá que la respuesta es Babylon Labs.
$IDOL
¿Que el creador tenga una de las claves de desunbond cambie la forma en que ves "sin confianza"?
🔑 No, still trustless
100%
🔒 Slightly concerning
0%
🚨 Yes, big issue
0%
❓ Didn't know this
0%
1 Votos • Votación cerrada
2 a. m., sigo despierto, leyendo la documentación de Babylon sobre la generación de checkpoints sin ninguna razón en particular, solo porque no podía dormir. Una línea frenó mi scroll: un vigilante honesto y activo en toda la red es suficiente para garantizar checkpoints exitosos y seguros en Bitcoin.
Lee rápido; eso suena a que la descentralización hace su trabajo. Docenas de operadores independientes, solo uno tiene que comportarse.
Volví al propio paper académico de Babylon de 2022, coautoría de sus fundadores: el que prueba esta afirmación como un teorema formal en vez de una frase de marketing. La demostración se cumple bajo una condición: hay un validador honesto activo en todo momento. El paper lo afirma claramente.
Esto es lo que no explica. “Uno es matemáticamente suficiente” y “uno está actualmente en línea” son dos garantías distintas. Solo la primera viene con una prueba adjunta.
Luego, la misma frase apareció otra vez, esta vez junto al emulador de covenant y el relayer de IBC, nombrados como programas separados: la operación segura requiere al menos un operador honesto de cada programa listado, o el sistema lanza una alarma. No sé si eso cubre a los tres por igual, o si se redactó pensando solo en el conjunto de vigilantes. En cualquier caso, el número de personas no se publica.
Babylon lo llama voluntario; cualquiera puede ejecutarlo. Sí, y aun así no dice cuántos lo están haciendo ahora, ni si ese número se mantiene durante un pico de comisiones de Bitcoin que nadie quiere pagar.
Hay una razón por la que nadie publica ese conteo. Revelar lo delgado que es el colchón le ayuda más a un atacante que a ti.
Si estás haciendo staking a través de Babylon ahora mismo, esta es la suposición que está debajo de tu BTC y que ningún panel te muestra: no si las matemáticas funcionan, sino si alguien está realmente despierto para ejecutarlo, esta noche y todas las noches después.
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
¿Harías staking si se desconoce el conteo de “un operador honesto”? 👀
Lee rápido; eso suena a que la descentralización hace su trabajo. Docenas de operadores independientes, solo uno tiene que comportarse.
Volví al propio paper académico de Babylon de 2022, coautoría de sus fundadores: el que prueba esta afirmación como un teorema formal en vez de una frase de marketing. La demostración se cumple bajo una condición: hay un validador honesto activo en todo momento. El paper lo afirma claramente.
Esto es lo que no explica. “Uno es matemáticamente suficiente” y “uno está actualmente en línea” son dos garantías distintas. Solo la primera viene con una prueba adjunta.
Luego, la misma frase apareció otra vez, esta vez junto al emulador de covenant y el relayer de IBC, nombrados como programas separados: la operación segura requiere al menos un operador honesto de cada programa listado, o el sistema lanza una alarma. No sé si eso cubre a los tres por igual, o si se redactó pensando solo en el conjunto de vigilantes. En cualquier caso, el número de personas no se publica.
Babylon lo llama voluntario; cualquiera puede ejecutarlo. Sí, y aun así no dice cuántos lo están haciendo ahora, ni si ese número se mantiene durante un pico de comisiones de Bitcoin que nadie quiere pagar.
Hay una razón por la que nadie publica ese conteo. Revelar lo delgado que es el colchón le ayuda más a un atacante que a ti.
Si estás haciendo staking a través de Babylon ahora mismo, esta es la suposición que está debajo de tu BTC y que ningún panel te muestra: no si las matemáticas funcionan, sino si alguien está realmente despierto para ejecutarlo, esta noche y todas las noches después.
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
¿Harías staking si se desconoce el conteo de “un operador honesto”? 👀
✨ Yes, the math is enough
100%
🤌🏻I'd wnt live operator data
0%
⚠️ That’s a real concern
0%
❓ Didn’t know this
0%
1 Votos • Votación cerrada
Con verificación
#baby $BABY @BabylonLabs_io
Solía pensar que el “slashing” era la forma de Babilonia de castigar la deshonestidad. Eso cambió a las 2 a. m., al desplazarme sin parar por una auditoría de seguridad independiente de la implementación de EOTS, un tipo de documento que nadie abre sin un motivo.
El mecanismo es elegante en sus propios términos. Un proveedor de finalidad se compromete con una pieza de aleatoriedad antes de firmar cualquier bloque en una altura determinada. Si la firma una vez, no ocurre nada. Si la firma dos veces, con dos mensajes distintos, y las matemáticas de las firmas Schnorr hacen que esa misma aleatoriedad se convierta en la clave privada expuesta del proveedor. El doble firmado intencional se vuelve autopenalizante por construcción, y hay una razón: un protocolo solo puede leer firmas, no intención; así que una regla lo bastante estricta para atrapar a un atacante no puede distinguir a un atacante de un accidente.
Ese es el intercambio que la auditoría señaló. Un ataque deliberado y un failover de un nodo de respaldo honesto que se activa en la misma altura producen exactamente el mismo patrón de firmas. Ambos se ven idénticos a EOTS. Ambos reciben slashing de la misma manera, quedan “tombstoned”, sin reinstalación.
Esto no es teórico. Hex Trust, un custodio institucional que ejecuta infraestructura de proveedores de finalidad en Babylon, enumera salvaguardas específicas contra exactamente esto: no reutilizar la clave privada entre máquinas, hacer failover manual en lugar de automático, porque el failover automático es precisamente lo que puede producir dos firmantes activos para una misma clave al mismo tiempo.
Aquí está la parte que no tiene una respuesta limpia. No existe un estándar de divulgación pública sobre qué configuración de failover ejecuta un proveedor. Puedes revisar comisión, disponibilidad y cantidad de delegadores. No esto, no antes de que tu BTC ya esté bloqueado.
Delegar nunca fue solo una apuesta a que el operador no te atacaría. También es una apuesta a que su infraestructura no tendrá un mal día mientras tu BTC esté bloqueado, en un detalle que el protocolo hace imposible conocer de antemano .
$KOMA
Solía pensar que el “slashing” era la forma de Babilonia de castigar la deshonestidad. Eso cambió a las 2 a. m., al desplazarme sin parar por una auditoría de seguridad independiente de la implementación de EOTS, un tipo de documento que nadie abre sin un motivo.
El mecanismo es elegante en sus propios términos. Un proveedor de finalidad se compromete con una pieza de aleatoriedad antes de firmar cualquier bloque en una altura determinada. Si la firma una vez, no ocurre nada. Si la firma dos veces, con dos mensajes distintos, y las matemáticas de las firmas Schnorr hacen que esa misma aleatoriedad se convierta en la clave privada expuesta del proveedor. El doble firmado intencional se vuelve autopenalizante por construcción, y hay una razón: un protocolo solo puede leer firmas, no intención; así que una regla lo bastante estricta para atrapar a un atacante no puede distinguir a un atacante de un accidente.
Ese es el intercambio que la auditoría señaló. Un ataque deliberado y un failover de un nodo de respaldo honesto que se activa en la misma altura producen exactamente el mismo patrón de firmas. Ambos se ven idénticos a EOTS. Ambos reciben slashing de la misma manera, quedan “tombstoned”, sin reinstalación.
Esto no es teórico. Hex Trust, un custodio institucional que ejecuta infraestructura de proveedores de finalidad en Babylon, enumera salvaguardas específicas contra exactamente esto: no reutilizar la clave privada entre máquinas, hacer failover manual en lugar de automático, porque el failover automático es precisamente lo que puede producir dos firmantes activos para una misma clave al mismo tiempo.
Aquí está la parte que no tiene una respuesta limpia. No existe un estándar de divulgación pública sobre qué configuración de failover ejecuta un proveedor. Puedes revisar comisión, disponibilidad y cantidad de delegadores. No esto, no antes de que tu BTC ya esté bloqueado.
Delegar nunca fue solo una apuesta a que el operador no te atacaría. También es una apuesta a que su infraestructura no tendrá un mal día mientras tu BTC esté bloqueado, en un detalle que el protocolo hace imposible conocer de antemano .
$KOMA
Con verificación
$BABY $UAI $COTI #baby @BabylonLabs_io
Al principio asumí que el comité del pacto era un paso de “bootstrap”, algo que Babylon retiraría una vez que su propia hoja de ruta madurara, del mismo modo que la mayoría de protocolos jóvenes prometen descentralizar en su propio calendario. La documentación dice algo más silencioso y extraño que eso.
El comité existe porque Bitcoin en sí no tiene una forma nativa de imponer pactos: no hay un opcode que pueda forzar que un UTXO se gaste solo mediante reglas acordadas previamente. Así que Babylon construyó un multisig de 6 de 9 para emular esa función que falta, observando las solicitudes de staking, firmando conjuntamente la desvinculación y el slashing, y actuando como sustituto de una capacidad que el Script de Bitcoin simplemente aún no tiene. Esa parte es una ingeniería honesta alrededor de una brecha real, y la suposición de confianza es genuinamente más ligera que un multisig custodial normal: en lugar de “honestidad mayoritaria”, es una honestidad existencial; con que haya un firmante honesto, basta para detener el robo.
Lo que me frenó fue la condición de salida. La propia documentación de Babylon no dice que el comité se retire cuando la gobernanza madure, o cuando se alcance un cierto umbral de TVL, o una vez que se entregue algún hito interno. Dice que el comité permanece hasta que la funcionalidad de pactos esté disponible de forma nativa en Bitcoin, mediante opcodes como OP-CAT u OP-CTV, que Bitcoin Core no ha adoptado y para los que no hay una línea de tiempo comprometida.
La fecha de retiro no está en la hoja de ruta de Babylon. Está dentro del proceso de gobernanza de otro protocolo, uno en el que Babylon no tiene voto y del que no puede acelerar nada.
Así que la confianza no desapareció cuando Babylon lo llamó un sistema asegurado por Bitcoin. Se desplazó una capa más lejos: de un multisig con membresía definida, a un soft fork de Bitcoin que quizá se implemente o quizá no se implemente en esta década. Seis de nueve firmantes conocidos es, al menos, una suposición de confianza que puedes nombrar. Una actualización pendiente de opcodes sin fecha límite es una suposición de confianza en la que solo puedes esperar.
El comité de pactos permanece hasta que Bitcoin agregue opcodes de pactos. Ninguna línea de tiempo de Babylon lo controla.
¿Tu opinión? 👀
Al principio asumí que el comité del pacto era un paso de “bootstrap”, algo que Babylon retiraría una vez que su propia hoja de ruta madurara, del mismo modo que la mayoría de protocolos jóvenes prometen descentralizar en su propio calendario. La documentación dice algo más silencioso y extraño que eso.
El comité existe porque Bitcoin en sí no tiene una forma nativa de imponer pactos: no hay un opcode que pueda forzar que un UTXO se gaste solo mediante reglas acordadas previamente. Así que Babylon construyó un multisig de 6 de 9 para emular esa función que falta, observando las solicitudes de staking, firmando conjuntamente la desvinculación y el slashing, y actuando como sustituto de una capacidad que el Script de Bitcoin simplemente aún no tiene. Esa parte es una ingeniería honesta alrededor de una brecha real, y la suposición de confianza es genuinamente más ligera que un multisig custodial normal: en lugar de “honestidad mayoritaria”, es una honestidad existencial; con que haya un firmante honesto, basta para detener el robo.
Lo que me frenó fue la condición de salida. La propia documentación de Babylon no dice que el comité se retire cuando la gobernanza madure, o cuando se alcance un cierto umbral de TVL, o una vez que se entregue algún hito interno. Dice que el comité permanece hasta que la funcionalidad de pactos esté disponible de forma nativa en Bitcoin, mediante opcodes como OP-CAT u OP-CTV, que Bitcoin Core no ha adoptado y para los que no hay una línea de tiempo comprometida.
La fecha de retiro no está en la hoja de ruta de Babylon. Está dentro del proceso de gobernanza de otro protocolo, uno en el que Babylon no tiene voto y del que no puede acelerar nada.
Así que la confianza no desapareció cuando Babylon lo llamó un sistema asegurado por Bitcoin. Se desplazó una capa más lejos: de un multisig con membresía definida, a un soft fork de Bitcoin que quizá se implemente o quizá no se implemente en esta década. Seis de nueve firmantes conocidos es, al menos, una suposición de confianza que puedes nombrar. Una actualización pendiente de opcodes sin fecha límite es una suposición de confianza en la que solo puedes esperar.
El comité de pactos permanece hasta que Bitcoin agregue opcodes de pactos. Ninguna línea de tiempo de Babylon lo controla.
¿Tu opinión? 👀
Safest for now ✅
25%
Uncomfortable, but fair 😕
0%
🚩 Real red flag
75%
Didn’t know this🥱
0%
4 Votos • Votación cerrada
La semana pasada, al elegir un proveedor de finalidad, mirando una lista de unas 30 identidades verificadas, me sorprendí a punto de hacer clic en el que ya tuviera más delegadores. El mismo reflejo que convirtió una gran parte del staking de Ethereum en una historia de Lido.
Luego leí realmente la guía de staking de Babylon.
Ahí se nombra el riesgo de forma directa: delegar en los proveedores más populares aumenta el riesgo de centralización. No es una observación de un crítico; lo dice su propia documentación.
➡ Aproximadamente 30 proveedores tienen una marca de verificación en la app.
➡ Nada en esa lista limita cuánto delegación puede absorber cualquiera de ellos.
Démosle crédito a Babylon por decirlo en voz alta; la mayoría de los productos de staking nunca advierten al usuario final antes de que haga clic.
Esto es lo que se me quedó. La marca de verificación existe para generar confianza. Pero si la mayoría de los stakers recurre por defecto a la opción verificada que ya tiene más delegadores, el patrón exacto que Ethereum vivió, lo que se suponía que debía construir confianza se convierte en el mecanismo que concentra el riesgo del que advierte.
Busqué cifras reales sobre participación en la delegación: cuánto controlan en conjunto los 5 o 10 principales proveedores de finalidad. No encontré nada público. Un escrito de su propio protocolo de una casa de cambio cripto lo llamó "todavía requiere más discusión", un problema abierto marcado por una fuente externa, no algo que Babylon mismo haya abordado en registros.
Dividí mi delegación entre tres proveedores más pequeños en lugar de uno grande. A esta escala probablemente sea más un gesto simbólico que una solución real, y lo sé.
@BabylonLabs_io $BABY #baby $ON
"¿Delegarías a propósito en un proveedor de finalidad más pequeño?"
Luego leí realmente la guía de staking de Babylon.
Ahí se nombra el riesgo de forma directa: delegar en los proveedores más populares aumenta el riesgo de centralización. No es una observación de un crítico; lo dice su propia documentación.
➡ Aproximadamente 30 proveedores tienen una marca de verificación en la app.
➡ Nada en esa lista limita cuánto delegación puede absorber cualquiera de ellos.
Démosle crédito a Babylon por decirlo en voz alta; la mayoría de los productos de staking nunca advierten al usuario final antes de que haga clic.
Esto es lo que se me quedó. La marca de verificación existe para generar confianza. Pero si la mayoría de los stakers recurre por defecto a la opción verificada que ya tiene más delegadores, el patrón exacto que Ethereum vivió, lo que se suponía que debía construir confianza se convierte en el mecanismo que concentra el riesgo del que advierte.
Busqué cifras reales sobre participación en la delegación: cuánto controlan en conjunto los 5 o 10 principales proveedores de finalidad. No encontré nada público. Un escrito de su propio protocolo de una casa de cambio cripto lo llamó "todavía requiere más discusión", un problema abierto marcado por una fuente externa, no algo que Babylon mismo haya abordado en registros.
Dividí mi delegación entre tres proveedores más pequeños en lugar de uno grande. A esta escala probablemente sea más un gesto simbólico que una solución real, y lo sé.
@BabylonLabs_io $BABY #baby $ON
"¿Delegarías a propósito en un proveedor de finalidad más pequeño?"
🔀 Yes, spread it out
0%
🛡️ No, biggest is safest
0%
💰 Depends on commission
0%
🤷 Never thought about it
100%
1 Votos • Votación cerrada
#baby @BabylonLabs_io
Casi puse una pequeña cantidad de BTC en una posición de préstamo respaldada por una bóveda la semana pasada. Antes de hacerlo, quería saber una cosa: si el mercado se movía rápido en mi contra, ¿qué decide realmente cuándo me liquidan? Esa pregunta me llevó a buscar más allá del marketing y hasta el propio sitio de Babylon, para donde la palabra "trustless" deja de aplicar. No estaba enterrado. Solo que no sobrevive la traducción en cada titular construido alrededor de esa única palabra. ➡ La propia página de Learn de Babylon dice, sin rodeos, que el riesgo real está en el lado DeFi, no en la propia bóveda, y pone la liquidación en préstamos como ejemplo. ➡ El whitepaper lo respalda: la liquidación necesita una firma de un oracle de precios, tratada como una dependencia separada del diseño central de la bóveda. Dale crédito a Babylon: ellos mismos lo dejaron por escrito. Nadie tuvo que sacarlo de ellos. Esta es la parte que se me quedó grabada, la parte que realmente cambió cuánto iba a depositar. "Un oracle de precios" suena abstracto, hasta que un informe sobre exactamente este sistema mencionó qué redes mantienen realmente esa relación con Babylon: Band Protocol y Pyth, las mismas redes de propósito general que fijan el precio de docenas de otras cadenas al mismo tiempo. Los materiales de Babylon no las nombran directamente, así que trata ese emparejamiento específico como reportado, no confirmado por el propio Babylon. Si una de esas fuentes llega tarde o es incorrecta durante un movimiento rápido, mi liquidación igual se dispara exactamente tal como está codificado. Actuar correctamente con información mala. La capa base de Bitcoin no tiene voto en ese resultado. La bóveda hace exactamente lo que prometió. El oracle solo le entrega algo falso. Eso no es que falle la bóveda. Es riesgo DeFi, con una etiqueta de confianza cero, heredando el historial de caídas que ya lleva su fuente de precios real de otras cadenas que ni siquiera uso. Aun así hice el depósito. Solo que más pequeño de lo que habría hecho una hora antes. "Trustless" describe lo que le pasa a tu BTC. Nunca fue una promesa sobre lo que pasa con tu dinero cuando sale de la bóveda.
$BROCCOLIF3B $ON $BABY
Casi puse una pequeña cantidad de BTC en una posición de préstamo respaldada por una bóveda la semana pasada. Antes de hacerlo, quería saber una cosa: si el mercado se movía rápido en mi contra, ¿qué decide realmente cuándo me liquidan? Esa pregunta me llevó a buscar más allá del marketing y hasta el propio sitio de Babylon, para donde la palabra "trustless" deja de aplicar. No estaba enterrado. Solo que no sobrevive la traducción en cada titular construido alrededor de esa única palabra. ➡ La propia página de Learn de Babylon dice, sin rodeos, que el riesgo real está en el lado DeFi, no en la propia bóveda, y pone la liquidación en préstamos como ejemplo. ➡ El whitepaper lo respalda: la liquidación necesita una firma de un oracle de precios, tratada como una dependencia separada del diseño central de la bóveda. Dale crédito a Babylon: ellos mismos lo dejaron por escrito. Nadie tuvo que sacarlo de ellos. Esta es la parte que se me quedó grabada, la parte que realmente cambió cuánto iba a depositar. "Un oracle de precios" suena abstracto, hasta que un informe sobre exactamente este sistema mencionó qué redes mantienen realmente esa relación con Babylon: Band Protocol y Pyth, las mismas redes de propósito general que fijan el precio de docenas de otras cadenas al mismo tiempo. Los materiales de Babylon no las nombran directamente, así que trata ese emparejamiento específico como reportado, no confirmado por el propio Babylon. Si una de esas fuentes llega tarde o es incorrecta durante un movimiento rápido, mi liquidación igual se dispara exactamente tal como está codificado. Actuar correctamente con información mala. La capa base de Bitcoin no tiene voto en ese resultado. La bóveda hace exactamente lo que prometió. El oracle solo le entrega algo falso. Eso no es que falle la bóveda. Es riesgo DeFi, con una etiqueta de confianza cero, heredando el historial de caídas que ya lleva su fuente de precios real de otras cadenas que ni siquiera uso. Aun así hice el depósito. Solo que más pequeño de lo que habría hecho una hora antes. "Trustless" describe lo que le pasa a tu BTC. Nunca fue una promesa sobre lo que pasa con tu dinero cuando sale de la bóveda.
$BROCCOLIF3B $ON $BABY
✅ Bitcoin security
0%
📈 Oracle accuracy
0%
⚖️ Both equally
0%
❓Depends on the protocol
0%
0 Votos • Votación cerrada
Parcialmente cierto
#baby $BABY @BabylonLabs_io
Casi puse una pequeña cantidad de BTC en una posición de préstamo respaldada por una bóveda la semana pasada. Antes de hacerlo, quería saber una cosa: si el mercado se movía rápido en mi contra, ¿qué es lo que realmente decide cuándo me liquidan?
Esa pregunta fue la que me llevó a ir más allá del marketing y entrar al propio sitio de Babylon para ver dónde deja de aplicarse la palabra "trustless".
No estaba enterrado. Simplemente no sobrevive la traducción a cada titular que se construye alrededor de esa única palabra.
➡ La propia página de Learn de Babylon dice con claridad que el riesgo real está del lado de DeFi, no dentro de la propia bóveda, y da la liquidación en los préstamos como ejemplo.
➡ El whitepaper lo respalda: la liquidación necesita una firma de un oráculo de precios, tratada como una dependencia separada del diseño central de la bóveda.
Hay que darle crédito a Babylon: ellos mismos lo dejaron por escrito. Nadie tuvo que sacarlo de ahí.
Esta es la parte que se me quedó grabada, la parte que realmente cambió cuánto estaba a punto de depositar. "Un oráculo de precios" suena abstracto, hasta que un informe sobre este sistema exacto nombra qué redes mantienen realmente esa relación con Babylon: Band Protocol y Pyth, las mismas redes de propósito general que valoran docenas de otras cadenas al mismo tiempo. Los materiales de Babylon no los mencionan directamente, así que trata ese emparejamiento específico como reportado, no confirmado por Babylon en sí.
Si uno de esos feeds llega tarde o está mal durante un movimiento rápido, mi liquidación igual se activa exactamente como está codificado. Actuar correctamente, sobre información incorrecta. La capa base de Bitcoin no vota en ese resultado. La bóveda hace exactamente lo que prometió. El oráculo solo le entrega algo falso.
Eso no es la bóveda fallando. Es el riesgo de DeFi, con una etiqueta de trustless, heredando cualquier historial de caídas que su feed de precios real ya tenga de otras cadenas que ni siquiera uso.
Al final sí hice el depósito. Solo que más pequeño de lo que habría hecho una hora antes.
Trustless describe lo que le pasa a tu BTC. Nunca fue una promesa sobre lo que le pasa a tu dinero una vez que sale de la bóveda.
$EUL
¿Puede una bóveda trustless seguir dependiendo de oráculos?
Casi puse una pequeña cantidad de BTC en una posición de préstamo respaldada por una bóveda la semana pasada. Antes de hacerlo, quería saber una cosa: si el mercado se movía rápido en mi contra, ¿qué es lo que realmente decide cuándo me liquidan?
Esa pregunta fue la que me llevó a ir más allá del marketing y entrar al propio sitio de Babylon para ver dónde deja de aplicarse la palabra "trustless".
No estaba enterrado. Simplemente no sobrevive la traducción a cada titular que se construye alrededor de esa única palabra.
➡ La propia página de Learn de Babylon dice con claridad que el riesgo real está del lado de DeFi, no dentro de la propia bóveda, y da la liquidación en los préstamos como ejemplo.
➡ El whitepaper lo respalda: la liquidación necesita una firma de un oráculo de precios, tratada como una dependencia separada del diseño central de la bóveda.
Hay que darle crédito a Babylon: ellos mismos lo dejaron por escrito. Nadie tuvo que sacarlo de ahí.
Esta es la parte que se me quedó grabada, la parte que realmente cambió cuánto estaba a punto de depositar. "Un oráculo de precios" suena abstracto, hasta que un informe sobre este sistema exacto nombra qué redes mantienen realmente esa relación con Babylon: Band Protocol y Pyth, las mismas redes de propósito general que valoran docenas de otras cadenas al mismo tiempo. Los materiales de Babylon no los mencionan directamente, así que trata ese emparejamiento específico como reportado, no confirmado por Babylon en sí.
Si uno de esos feeds llega tarde o está mal durante un movimiento rápido, mi liquidación igual se activa exactamente como está codificado. Actuar correctamente, sobre información incorrecta. La capa base de Bitcoin no vota en ese resultado. La bóveda hace exactamente lo que prometió. El oráculo solo le entrega algo falso.
Eso no es la bóveda fallando. Es el riesgo de DeFi, con una etiqueta de trustless, heredando cualquier historial de caídas que su feed de precios real ya tenga de otras cadenas que ni siquiera uso.
Al final sí hice el depósito. Solo que más pequeño de lo que habría hecho una hora antes.
Trustless describe lo que le pasa a tu BTC. Nunca fue una promesa sobre lo que le pasa a tu dinero una vez que sale de la bóveda.
$EUL
¿Puede una bóveda trustless seguir dependiendo de oráculos?
✅ Yes, already knew
0%
🤯 No,I asumed it covered both
0%
0 Votos • Votación cerrada
⚡✨
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
No pude dormir anoche, así que saqué tres informes separados sobre el lado de Aave Temp Check de Babylon y los puse lado a lado, más por costumbre que por otra cosa.
Una palabra no paraba de darme vueltas.
Bitcoin.com, Cointribune y LiveBitcoinNews describen el flujo de liquidación del TBV de la misma manera. Un liquidador sin permisos intercambia una bóveda incautada por WBTC al instante, con una pequeña prima. Luego, un conjunto separado de "arbitrajistas con permisos" compra esa posición y canjea el BTC real más tarde, siguiendo el cronograma propio de Bitcoin.
Demos crédito a Babylon por la primera mitad: las comprobaciones de liquidación sin permisos salen exactamente como se anunció.
Es la segunda mitad donde fui más atrás que la propuesta de Aave. El propio whitepaper de agosto de Babylon sobre Trustless Bitcoin Vaults tampoco dice "con permisos"; dice que las liquidaciones se ejecutan a través de "liquidadores permitidos" que supervisan el precio y el estado de la bóveda. Diferente palabra, misma forma. Un analista independiente que intercambió mensajes con el equipo de Babylon en X señaló el mismo punto directamente: que suficientes de esas partes permitidas se comporten correctamente es una suposición de confianza que el marketing no menciona.
Así que la palabra resultó ser precisa. La pregunta real es por qué ese rol tiene que restringirse en absoluto, cuando el lado del intercambio por WBTC no lo está. El lenguaje de scripting de Bitcoin no puede evaluar un estado arbitrario fuera de la cadena. BitVM3 lo resuelve envolviendo un verificador de prueba de conocimiento cero dentro de un circuito garbled, pero alguien todavía tiene que generar y enviar esa prueba para activar el canje. El lado del intercambio por WBTC es fácil de dejar sin permisos: cualquier liquidador con capital realiza la operación. Enviar la prueba es el problema más difícil que BitVM3 todavía no ha resuelto.
Esto no trata de si la bóveda es sin confianza. Babylon no ocultó el listado permitido en su propio whitepaper. La confianza no desaparece aquí. Solo termina un paso antes de lo que la mayor parte de la cobertura deja entrever.
$EUL
¿Qué define una bóveda de BTC verdaderamente sin confianza?
No pude dormir anoche, así que saqué tres informes separados sobre el lado de Aave Temp Check de Babylon y los puse lado a lado, más por costumbre que por otra cosa.
Una palabra no paraba de darme vueltas.
Bitcoin.com, Cointribune y LiveBitcoinNews describen el flujo de liquidación del TBV de la misma manera. Un liquidador sin permisos intercambia una bóveda incautada por WBTC al instante, con una pequeña prima. Luego, un conjunto separado de "arbitrajistas con permisos" compra esa posición y canjea el BTC real más tarde, siguiendo el cronograma propio de Bitcoin.
Demos crédito a Babylon por la primera mitad: las comprobaciones de liquidación sin permisos salen exactamente como se anunció.
Es la segunda mitad donde fui más atrás que la propuesta de Aave. El propio whitepaper de agosto de Babylon sobre Trustless Bitcoin Vaults tampoco dice "con permisos"; dice que las liquidaciones se ejecutan a través de "liquidadores permitidos" que supervisan el precio y el estado de la bóveda. Diferente palabra, misma forma. Un analista independiente que intercambió mensajes con el equipo de Babylon en X señaló el mismo punto directamente: que suficientes de esas partes permitidas se comporten correctamente es una suposición de confianza que el marketing no menciona.
Así que la palabra resultó ser precisa. La pregunta real es por qué ese rol tiene que restringirse en absoluto, cuando el lado del intercambio por WBTC no lo está. El lenguaje de scripting de Bitcoin no puede evaluar un estado arbitrario fuera de la cadena. BitVM3 lo resuelve envolviendo un verificador de prueba de conocimiento cero dentro de un circuito garbled, pero alguien todavía tiene que generar y enviar esa prueba para activar el canje. El lado del intercambio por WBTC es fácil de dejar sin permisos: cualquier liquidador con capital realiza la operación. Enviar la prueba es el problema más difícil que BitVM3 todavía no ha resuelto.
Esto no trata de si la bóveda es sin confianza. Babylon no ocultó el listado permitido en su propio whitepaper. La confianza no desaparece aquí. Solo termina un paso antes de lo que la mayor parte de la cobertura deja entrever.
$EUL
¿Qué define una bóveda de BTC verdaderamente sin confianza?
$EUL $CHILLGUY Goooo
y déjame comentarios
y déjame comentarios
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
No pude dormir anoche, así que saqué tres informes separados sobre el lado de Aave Temp Check de Babylon y los puse lado a lado, más por costumbre que por otra cosa.
Una palabra no paraba de darme vueltas.
Bitcoin.com, Cointribune y LiveBitcoinNews describen el flujo de liquidación del TBV de la misma manera. Un liquidador sin permisos intercambia una bóveda incautada por WBTC al instante, con una pequeña prima. Luego, un conjunto separado de "arbitrajistas con permisos" compra esa posición y canjea el BTC real más tarde, siguiendo el cronograma propio de Bitcoin.
Demos crédito a Babylon por la primera mitad: las comprobaciones de liquidación sin permisos salen exactamente como se anunció.
Es la segunda mitad donde fui más atrás que la propuesta de Aave. El propio whitepaper de agosto de Babylon sobre Trustless Bitcoin Vaults tampoco dice "con permisos"; dice que las liquidaciones se ejecutan a través de "liquidadores permitidos" que supervisan el precio y el estado de la bóveda. Diferente palabra, misma forma. Un analista independiente que intercambió mensajes con el equipo de Babylon en X señaló el mismo punto directamente: que suficientes de esas partes permitidas se comporten correctamente es una suposición de confianza que el marketing no menciona.
Así que la palabra resultó ser precisa. La pregunta real es por qué ese rol tiene que restringirse en absoluto, cuando el lado del intercambio por WBTC no lo está. El lenguaje de scripting de Bitcoin no puede evaluar un estado arbitrario fuera de la cadena. BitVM3 lo resuelve envolviendo un verificador de prueba de conocimiento cero dentro de un circuito garbled, pero alguien todavía tiene que generar y enviar esa prueba para activar el canje. El lado del intercambio por WBTC es fácil de dejar sin permisos: cualquier liquidador con capital realiza la operación. Enviar la prueba es el problema más difícil que BitVM3 todavía no ha resuelto.
Esto no trata de si la bóveda es sin confianza. Babylon no ocultó el listado permitido en su propio whitepaper. La confianza no desaparece aquí. Solo termina un paso antes de lo que la mayor parte de la cobertura deja entrever.
$EUL
¿Qué define una bóveda de BTC verdaderamente sin confianza?
No pude dormir anoche, así que saqué tres informes separados sobre el lado de Aave Temp Check de Babylon y los puse lado a lado, más por costumbre que por otra cosa.
Una palabra no paraba de darme vueltas.
Bitcoin.com, Cointribune y LiveBitcoinNews describen el flujo de liquidación del TBV de la misma manera. Un liquidador sin permisos intercambia una bóveda incautada por WBTC al instante, con una pequeña prima. Luego, un conjunto separado de "arbitrajistas con permisos" compra esa posición y canjea el BTC real más tarde, siguiendo el cronograma propio de Bitcoin.
Demos crédito a Babylon por la primera mitad: las comprobaciones de liquidación sin permisos salen exactamente como se anunció.
Es la segunda mitad donde fui más atrás que la propuesta de Aave. El propio whitepaper de agosto de Babylon sobre Trustless Bitcoin Vaults tampoco dice "con permisos"; dice que las liquidaciones se ejecutan a través de "liquidadores permitidos" que supervisan el precio y el estado de la bóveda. Diferente palabra, misma forma. Un analista independiente que intercambió mensajes con el equipo de Babylon en X señaló el mismo punto directamente: que suficientes de esas partes permitidas se comporten correctamente es una suposición de confianza que el marketing no menciona.
Así que la palabra resultó ser precisa. La pregunta real es por qué ese rol tiene que restringirse en absoluto, cuando el lado del intercambio por WBTC no lo está. El lenguaje de scripting de Bitcoin no puede evaluar un estado arbitrario fuera de la cadena. BitVM3 lo resuelve envolviendo un verificador de prueba de conocimiento cero dentro de un circuito garbled, pero alguien todavía tiene que generar y enviar esa prueba para activar el canje. El lado del intercambio por WBTC es fácil de dejar sin permisos: cualquier liquidador con capital realiza la operación. Enviar la prueba es el problema más difícil que BitVM3 todavía no ha resuelto.
Esto no trata de si la bóveda es sin confianza. Babylon no ocultó el listado permitido en su propio whitepaper. La confianza no desaparece aquí. Solo termina un paso antes de lo que la mayor parte de la cobertura deja entrever.
$EUL
¿Qué define una bóveda de BTC verdaderamente sin confianza?
#baby $BABY @BabylonLabs_io
No pude dormir anoche, así que saqué tres informes separados sobre el lado de Aave Temp Check de Babylon y los puse lado a lado, más por costumbre que por otra cosa.
Una palabra no paraba de darme vueltas.
Bitcoin.com, Cointribune y LiveBitcoinNews describen el flujo de liquidación del TBV de la misma manera. Un liquidador sin permisos intercambia una bóveda incautada por WBTC al instante, con una pequeña prima. Luego, un conjunto separado de "arbitrajistas con permisos" compra esa posición y canjea el BTC real más tarde, siguiendo el cronograma propio de Bitcoin.
Demos crédito a Babylon por la primera mitad: las comprobaciones de liquidación sin permisos salen exactamente como se anunció.
Es la segunda mitad donde fui más atrás que la propuesta de Aave. El propio whitepaper de agosto de Babylon sobre Trustless Bitcoin Vaults tampoco dice "con permisos"; dice que las liquidaciones se ejecutan a través de "liquidadores permitidos" que supervisan el precio y el estado de la bóveda. Diferente palabra, misma forma. Un analista independiente que intercambió mensajes con el equipo de Babylon en X señaló el mismo punto directamente: que suficientes de esas partes permitidas se comporten correctamente es una suposición de confianza que el marketing no menciona.
Así que la palabra resultó ser precisa. La pregunta real es por qué ese rol tiene que restringirse en absoluto, cuando el lado del intercambio por WBTC no lo está. El lenguaje de scripting de Bitcoin no puede evaluar un estado arbitrario fuera de la cadena. BitVM3 lo resuelve envolviendo un verificador de prueba de conocimiento cero dentro de un circuito garbled, pero alguien todavía tiene que generar y enviar esa prueba para activar el canje. El lado del intercambio por WBTC es fácil de dejar sin permisos: cualquier liquidador con capital realiza la operación. Enviar la prueba es el problema más difícil que BitVM3 todavía no ha resuelto.
Esto no trata de si la bóveda es sin confianza. Babylon no ocultó el listado permitido en su propio whitepaper. La confianza no desaparece aquí. Solo termina un paso antes de lo que la mayor parte de la cobertura deja entrever.
$EUL
¿Qué define una bóveda de BTC verdaderamente sin confianza?
No pude dormir anoche, así que saqué tres informes separados sobre el lado de Aave Temp Check de Babylon y los puse lado a lado, más por costumbre que por otra cosa.
Una palabra no paraba de darme vueltas.
Bitcoin.com, Cointribune y LiveBitcoinNews describen el flujo de liquidación del TBV de la misma manera. Un liquidador sin permisos intercambia una bóveda incautada por WBTC al instante, con una pequeña prima. Luego, un conjunto separado de "arbitrajistas con permisos" compra esa posición y canjea el BTC real más tarde, siguiendo el cronograma propio de Bitcoin.
Demos crédito a Babylon por la primera mitad: las comprobaciones de liquidación sin permisos salen exactamente como se anunció.
Es la segunda mitad donde fui más atrás que la propuesta de Aave. El propio whitepaper de agosto de Babylon sobre Trustless Bitcoin Vaults tampoco dice "con permisos"; dice que las liquidaciones se ejecutan a través de "liquidadores permitidos" que supervisan el precio y el estado de la bóveda. Diferente palabra, misma forma. Un analista independiente que intercambió mensajes con el equipo de Babylon en X señaló el mismo punto directamente: que suficientes de esas partes permitidas se comporten correctamente es una suposición de confianza que el marketing no menciona.
Así que la palabra resultó ser precisa. La pregunta real es por qué ese rol tiene que restringirse en absoluto, cuando el lado del intercambio por WBTC no lo está. El lenguaje de scripting de Bitcoin no puede evaluar un estado arbitrario fuera de la cadena. BitVM3 lo resuelve envolviendo un verificador de prueba de conocimiento cero dentro de un circuito garbled, pero alguien todavía tiene que generar y enviar esa prueba para activar el canje. El lado del intercambio por WBTC es fácil de dejar sin permisos: cualquier liquidador con capital realiza la operación. Enviar la prueba es el problema más difícil que BitVM3 todavía no ha resuelto.
Esto no trata de si la bóveda es sin confianza. Babylon no ocultó el listado permitido en su propio whitepaper. La confianza no desaparece aquí. Solo termina un paso antes de lo que la mayor parte de la cobertura deja entrever.
$EUL
¿Qué define una bóveda de BTC verdaderamente sin confianza?
⚡ Permissionless liquidation
100%
🔓 Permissionless redemption
0%
🤔 Not sure yet
0%
⚖️ Both are equally important
0%
1 Votos • Votación cerrada
únete
英鸿³³₇
·
--
[Volver a reproducir] 🎙️ Hablemos sobre las pasiones y los odios en el mercado primario, y las inversiones periódicas en BNB en el mercado secundario
02 h 17 min 48 s · 12.8k oyentes
$DEXE Goooooo 👉🏻
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
dos pools del mismo activo, separados por un par de clics, con cero conexión entre ellos hasta ahora. Aave tiene aproximadamente $5B en WBTC que apenas se mueve en el lado de los préstamos. Babylon tiene $4B+ en BTC en staking, ganando nada más que recompensas de staking.
ese es el argumento real enterrado en el Temp Check de Babylon — no "BTC sin confianza", sino emparejar la oferta ociosa en una plataforma con colateral ocioso en otra.
el diseño de Aave de Hub-and-Spoke en V4 es lo que lo hace posible sin que Babylon toque en absoluto el núcleo del pool de préstamos de Aave. dos nuevos Spokes se despliegan como módulos aislados — Babylon es dueña de la lógica del colateral de BTC, y el Hub principal de Aave permanece intacto por cualquier riesgo que esto introduzca.
digno de notar: esto no es una propuesta comunitaria flotando sin ser vista. el propio fundador de Aave lo respaldó públicamente, señalando específicamente la implementación de Spoke como un nuevo patrón para V4 — no solo otro listado de activos.
aún estamos en la fase Temp Check. ARFC y una votación on-chain deben ocurrir antes de que cualquier BTC se mueva realmente a través de esto.
si ambos pools siguen inactivos unos meses después de que esto pase la gobernanza, el problema nunca fue la plomería. fue el apetito.
$DEXE
¿Qué es lo más importante si esto sale en vivo?
dos pools del mismo activo, separados por un par de clics, con cero conexión entre ellos hasta ahora. Aave tiene aproximadamente $5B en WBTC que apenas se mueve en el lado de los préstamos. Babylon tiene $4B+ en BTC en staking, ganando nada más que recompensas de staking.
ese es el argumento real enterrado en el Temp Check de Babylon — no "BTC sin confianza", sino emparejar la oferta ociosa en una plataforma con colateral ocioso en otra.
el diseño de Aave de Hub-and-Spoke en V4 es lo que lo hace posible sin que Babylon toque en absoluto el núcleo del pool de préstamos de Aave. dos nuevos Spokes se despliegan como módulos aislados — Babylon es dueña de la lógica del colateral de BTC, y el Hub principal de Aave permanece intacto por cualquier riesgo que esto introduzca.
digno de notar: esto no es una propuesta comunitaria flotando sin ser vista. el propio fundador de Aave lo respaldó públicamente, señalando específicamente la implementación de Spoke como un nuevo patrón para V4 — no solo otro listado de activos.
aún estamos en la fase Temp Check. ARFC y una votación on-chain deben ocurrir antes de que cualquier BTC se mueva realmente a través de esto.
si ambos pools siguen inactivos unos meses después de que esto pase la gobernanza, el problema nunca fue la plomería. fue el apetito.
$DEXE
¿Qué es lo más importante si esto sale en vivo?
Parcialmente cierto
#baby $BABY @BabylonLabs_io
Estaba leyendo las notas de migración de Aave de v3 a v4 anoche, casi por aburrimiento, y una línea del propio paper de Babylon sobre sus vaults se me quedó grabada cuando cerré la pestaña: las condiciones de gasto de un vault TBV, incluido el contrato de destino, se fijan en el mismo momento en que se crea; literalmente eso es lo que lo hace trustless. Nadie puede redirigir el BTC después sin esa ruta preacordada. Lo que eso significa en silencio es que si Aave alguna vez vuelve a migrar contratos, como hizo justo de v3 a v4, un vault existente no puede seguir el proceso: tiene que deshacerse según el cronograma propio de Bitcoin y recrearse apuntando al nuevo destino, cada vez que el protocolo de destino actualice. La ausencia de confianza aquí no es gratis: se intercambia por rigidez, y nadie realmente lo está valorando en el precio. No pude encontrar detalles públicos sobre si Babylon o Aave tienen planeadas herramientas para hacer esa transición más llevadera. Esto no trata sobre qué tan seguro se ve un vault el día que lo creas, sino sobre qué sucede el día en que la otra parte de él tiene que cambiar.
$DEXE
¿Cuál es el gran intercambio aquí?
Estaba leyendo las notas de migración de Aave de v3 a v4 anoche, casi por aburrimiento, y una línea del propio paper de Babylon sobre sus vaults se me quedó grabada cuando cerré la pestaña: las condiciones de gasto de un vault TBV, incluido el contrato de destino, se fijan en el mismo momento en que se crea; literalmente eso es lo que lo hace trustless. Nadie puede redirigir el BTC después sin esa ruta preacordada. Lo que eso significa en silencio es que si Aave alguna vez vuelve a migrar contratos, como hizo justo de v3 a v4, un vault existente no puede seguir el proceso: tiene que deshacerse según el cronograma propio de Bitcoin y recrearse apuntando al nuevo destino, cada vez que el protocolo de destino actualice. La ausencia de confianza aquí no es gratis: se intercambia por rigidez, y nadie realmente lo está valorando en el precio. No pude encontrar detalles públicos sobre si Babylon o Aave tienen planeadas herramientas para hacer esa transición más llevadera. Esto no trata sobre qué tan seguro se ve un vault el día que lo creas, sino sobre qué sucede el día en que la otra parte de él tiene que cambiar.
$DEXE
¿Cuál es el gran intercambio aquí?
🔒 Stronger security
33%
🔄 Easier upgrades
0%
⚖️ Need both
0%
🤔 Still researching
67%
6 Votos • Votación cerrada
Inicia sesión para explorar más contenidos