Binance Square
M I N A_
8.4k Publicaciones

M I N A_

Verificado+ de Square
Too real to imitate...✨
130 Siguiendo
34.4K+ Seguidores
23.4K+ Me gusta
Publicaciones
·
--
Con verificación
Chicxs, ya saben que hice clic en "Atrás" más veces que en "Siguiente", lo cual probablemente no era lo que estaba midiendo la testnet, pero sí era lo que yo quería medir.@babylonlabs_io No estaba buscando una transacción fallida. Buscaba el primer momento en el que me sentí inseguro. ¿Naturalmente sabría qué venía después, o dependía de haber leído ya la documentación?🤔 Eso cambió la forma en que vi la nueva testnet pública de Babylon para préstamos nativos con Bitcoin como respaldo en Aave v4. Usando Trustless Bitcoin Vaults (Bóvedas de Bitcoin sin confianza), Bitcoin puede presentarse como colateral sin envolver (wrap), sin puentear (bridging) y sin renunciar a la custodia. Yo esperaba que la mecánica de la "bóveda" dominara mis notas. En cambio, volvía una y otra vez al propio flujo de préstamo. Lo que no esperaba era cuánta atención le da la interfaz a los casos límite en lugar de quedarse solo en el camino feliz. La liquidación parcial, los límites de colateral y el proceso estimado del préstamo aparecen antes de que siquiera pienses en hacer clic en "Prestar". Las reclamaciones del faucet (faucet claims), la configuración de la wallet, publicar el colateral, pedir prestado, reembolsar y cerrar una posición parecen directos sobre el papel, pero, ¿siguen sintiéndose intuitivos cuando deliberadamente te desaceleras? Entonces, reinicié el flujo una vez más después de llegar al paso de colateral porque mi primera impresión me pareció incompleta. La ingeniería detrás de las TBVs es importante, pero esta testnet también se siente como un experimento de coordinación. Los proveedores de wallets, los custodios, los socios de integración y los usuarios individuales recorren el mismo camino, y cada quien probablemente nota un punto distinto de fricción. Entonces, chicxs.. ¿Qué será lo primero que la gente cuestione cuando este flujo de préstamo se pruebe más allá de la documentación?👀 #baby $BABY $BTC
Chicxs, ya saben que hice clic en "Atrás" más veces que en "Siguiente", lo cual probablemente no era lo que estaba midiendo la testnet, pero sí era lo que yo quería medir.@BabylonLabs_io
No estaba buscando una transacción fallida. Buscaba el primer momento en el que me sentí inseguro. ¿Naturalmente sabría qué venía después, o dependía de haber leído ya la documentación?🤔
Eso cambió la forma en que vi la nueva testnet pública de Babylon para préstamos nativos con Bitcoin como respaldo en Aave v4.
Usando Trustless Bitcoin Vaults (Bóvedas de Bitcoin sin confianza), Bitcoin puede presentarse como colateral sin envolver (wrap), sin puentear (bridging) y sin renunciar a la custodia. Yo esperaba que la mecánica de la "bóveda" dominara mis notas. En cambio, volvía una y otra vez al propio flujo de préstamo.
Lo que no esperaba era cuánta atención le da la interfaz a los casos límite en lugar de quedarse solo en el camino feliz. La liquidación parcial, los límites de colateral y el proceso estimado del préstamo aparecen antes de que siquiera pienses en hacer clic en "Prestar".
Las reclamaciones del faucet (faucet claims), la configuración de la wallet, publicar el colateral, pedir prestado, reembolsar y cerrar una posición parecen directos sobre el papel, pero, ¿siguen sintiéndose intuitivos cuando deliberadamente te desaceleras?
Entonces, reinicié el flujo una vez más después de llegar al paso de colateral porque mi primera impresión me pareció incompleta. La ingeniería detrás de las TBVs es importante, pero esta testnet también se siente como un experimento de coordinación. Los proveedores de wallets, los custodios, los socios de integración y los usuarios individuales recorren el mismo camino, y cada quien probablemente nota un punto distinto de fricción.
Entonces, chicxs..
¿Qué será lo primero que la gente cuestione cuando este flujo de préstamo se pruebe más allá de la documentación?👀
#baby $BABY $BTC
Chicos !Cuanto más leía, menos interesado me volvía en la función de préstamo en sí. @babylonlabs_io Abrí el material de Aave v4 con la expectativa de pasar la mayor parte de mi tiempo entendiendo cómo funcionaba el flujo del préstamo. Pero no era ahí donde me quedaba atascado. Me encontré saltando de nuevo a la documentación de Babylon porque casi cada pregunta que tenía terminaba volviendo a lo de “la garantía (collateral)”. Estaba pensando: ¿estoy mirando la parte equivocada del sistema? 🤔 Ya sabes que el “factor de garantía del 78%” propuesto fue lo primero que anoté. Asumí que sería el titular. No lo fue. En algún punto del camino, mis notas dejaron de parecer notas de préstamo y empezaron a parecer notas sobre Bitcoin. Mientras revisaba mis notas, volví al episodio del 17 de julio de Double Down, con Charles d'Haussy. Una frase destacó: Bitcoin es el “activo más prístino” para usar como garantía porque los mercados ya saben cómo valorarlo y es altamente líquido. Una semana después, escuché a Patrick Bush de VanEck hacer una observación similar. Argumentó que, a medida que Bitcoin madura y se acepta como garantía, eso es un paso natural, y recordó a los oyentes que hace una década muchas instituciones lo veían como “residuos tóxicos”. ¿De verdad la historia era el préstamo respaldado nativamente por Bitcoin, o fue la evolución de Bitcoin como garantía el aspecto más importante? Volví a rastrear la arquitectura. La mecánica de préstamo tuvo sentido bastante rápido. Los Trustless Bitcoin Vaults (Bóvedas de Bitcoin sin necesidad de confianza) tardaron más. Ahí fue donde me sorprendí comparando supuestos de confianza en lugar de características. Lo interesante no era simplemente desbloquear liquidez. Era ver cuánta ingeniería hay detrás de permitir que Bitcoin se mantenga “nativo” y aun así sea útil como garantía. Eso no elimina el “riesgo de liquidación”, el “riesgo de mercado” ni el riesgo de contratos inteligentes, pero sí cambia dónde se deposita la confianza. Para cuando cerré las pestañas, ya no estaba pensando en los límites de préstamo. Estaba pensando en si la próxima fase de Bitcoin trata menos de negociarse y más de ser confiable como garantía. Así que chicos, decidme 👀 ¿Se está convirtiendo la garantía en el papel más grande de Bitcoin? #baby $BABY $BTC
Chicos !Cuanto más leía, menos interesado me volvía en la función de préstamo en sí.
@BabylonLabs_io
Abrí el material de Aave v4 con la expectativa de pasar la mayor parte de mi tiempo entendiendo cómo funcionaba el flujo del préstamo. Pero no era ahí donde me quedaba atascado. Me encontré saltando de nuevo a la documentación de Babylon porque casi cada pregunta que tenía terminaba volviendo a lo de “la garantía (collateral)”.
Estaba pensando: ¿estoy mirando la parte equivocada del sistema? 🤔
Ya sabes que el “factor de garantía del 78%” propuesto fue lo primero que anoté. Asumí que sería el titular. No lo fue.
En algún punto del camino, mis notas dejaron de parecer notas de préstamo y empezaron a parecer notas sobre Bitcoin.
Mientras revisaba mis notas, volví al episodio del 17 de julio de Double Down, con Charles d'Haussy. Una frase destacó: Bitcoin es el “activo más prístino” para usar como garantía porque los mercados ya saben cómo valorarlo y es altamente líquido.
Una semana después, escuché a Patrick Bush de VanEck hacer una observación similar. Argumentó que, a medida que Bitcoin madura y se acepta como garantía, eso es un paso natural, y recordó a los oyentes que hace una década muchas instituciones lo veían como “residuos tóxicos”.
¿De verdad la historia era el préstamo respaldado nativamente por Bitcoin, o fue la evolución de Bitcoin como garantía el aspecto más importante?
Volví a rastrear la arquitectura. La mecánica de préstamo tuvo sentido bastante rápido. Los Trustless Bitcoin Vaults (Bóvedas de Bitcoin sin necesidad de confianza) tardaron más. Ahí fue donde me sorprendí comparando supuestos de confianza en lugar de características.
Lo interesante no era simplemente desbloquear liquidez. Era ver cuánta ingeniería hay detrás de permitir que Bitcoin se mantenga “nativo” y aun así sea útil como garantía. Eso no elimina el “riesgo de liquidación”, el “riesgo de mercado” ni el riesgo de contratos inteligentes, pero sí cambia dónde se deposita la confianza.
Para cuando cerré las pestañas, ya no estaba pensando en los límites de préstamo. Estaba pensando en si la próxima fase de Bitcoin trata menos de negociarse y más de ser confiable como garantía.
Así que chicos, decidme 👀
¿Se está convirtiendo la garantía en el papel más grande de Bitcoin?
#baby $BABY $BTC
Chicos, no pude dejar de pensar en una pregunta: ¿Qué es exactamente lo que hace que una bóveda sea "cross-chain" si el BTC nunca sale de Bitcoin?🤔 @babylonlabs_io Esa pregunta me fue trayendo de vuelta a la documentación del peg-in. Pensé que la respuesta estaría en algún punto de cómo Bitcoin y Ethereum se comunicaban entre sí. No era eso. En papel, el flujo no parece inusual. El BTC se bloquea en un script de Taproot mientras la bóveda se registra en Ethereum. Luego noté el hashlock que enlaza ambos lados del proceso, y otro detalle empezó a destacar. La bóveda no se activa hasta que cada participante requerido ya haya firmado todo el grafo de la transacción. Cada ruta de redención, cada respuesta a un desafío, incluso la ruta de reembolso, se acuerdan antes de que la bóveda pueda usarse realmente. Me detuve ahí un segundo porque no estaba seguro de si eso era solo un detalle de implementación o el punto real del diseño. Cuanto más lo miraba, más parecía que el protocolo estaba desplazando deliberadamente la coordinación hacia el inicio en vez de dejarla para después. Chicos, releí el flujo de peg-in porque todavía no me cuadraba algo. Había asumido que serían necesarias nuevas aprobaciones cada vez que los fondos eventualmente se movieran. No lo son. La mayoría de esas decisiones ya se han tomado antes de que la bóveda exista en un sentido práctico. Eso cambia cuando ocurre la coordinación. La ruta de reembolso fue lo que finalmente cambió mi perspectiva. Si la configuración nunca se completa o el secreto nunca se revela, el depositante aún puede recuperar el BTC mediante un hash timelock en el lado de Bitcoin, sin depender de otro participante. Estuve pensando en eso un rato. Me preguntaba por qué dejaría tan poco a decisiones futuras. Me seguía preguntando por qué había que decidir tanto de antemano.... ¿Por qué comprometer cada ruta de gasto legítima antes de que la bóveda esté ni siquiera activa? Tal vez el protocolo no está optimizando principalmente para mover activos entre dos redes después de todo. Quizá está intentando que la incertidumbre sea mucho más difícil de introducir. Así que, ¿Reducir las decisiones futuras es solo otra forma de reducir la confianza?👀 #baby $BABY $BTC
Chicos, no pude dejar de pensar en una pregunta: ¿Qué es exactamente lo que hace que una bóveda sea "cross-chain" si el BTC nunca sale de Bitcoin?🤔
@BabylonLabs_io
Esa pregunta me fue trayendo de vuelta a la documentación del peg-in. Pensé que la respuesta estaría en algún punto de cómo Bitcoin y Ethereum se comunicaban entre sí. No era eso.
En papel, el flujo no parece inusual. El BTC se bloquea en un script de Taproot mientras la bóveda se registra en Ethereum. Luego noté el hashlock que enlaza ambos lados del proceso, y otro detalle empezó a destacar. La bóveda no se activa hasta que cada participante requerido ya haya firmado todo el grafo de la transacción. Cada ruta de redención, cada respuesta a un desafío, incluso la ruta de reembolso, se acuerdan antes de que la bóveda pueda usarse realmente. Me detuve ahí un segundo porque no estaba seguro de si eso era solo un detalle de implementación o el punto real del diseño. Cuanto más lo miraba, más parecía que el protocolo estaba desplazando deliberadamente la coordinación hacia el inicio en vez de dejarla para después.
Chicos, releí el flujo de peg-in porque todavía no me cuadraba algo. Había asumido que serían necesarias nuevas aprobaciones cada vez que los fondos eventualmente se movieran. No lo son. La mayoría de esas decisiones ya se han tomado antes de que la bóveda exista en un sentido práctico. Eso cambia cuando ocurre la coordinación.
La ruta de reembolso fue lo que finalmente cambió mi perspectiva. Si la configuración nunca se completa o el secreto nunca se revela, el depositante aún puede recuperar el BTC mediante un hash timelock en el lado de Bitcoin, sin depender de otro participante. Estuve pensando en eso un rato. Me preguntaba por qué dejaría tan poco a decisiones futuras. Me seguía preguntando por qué había que decidir tanto de antemano.... ¿Por qué comprometer cada ruta de gasto legítima antes de que la bóveda esté ni siquiera activa? Tal vez el protocolo no está optimizando principalmente para mover activos entre dos redes después de todo. Quizá está intentando que la incertidumbre sea mucho más difícil de introducir.
Así que,
¿Reducir las decisiones futuras es solo otra forma de reducir la confianza?👀
#baby $BABY $BTC
Con verificación
@babylonlabs_io Lo que me tomó por sorpresa no fue una característica o un indicador. Fue con qué frecuencia Babylon separa ideas que la mayoría de los protocolos tienden a agrupar. Entré pensando que el modelo de seguridad se centraría principalmente en el slashing. Esa parte es bastante directa. Si un validador delegado comete una infracción sancionable, se puede perder una porción de la participación en Bitcoin. La consecuencia económica es clara. Pero cuanto más seguí el flujo de staking, más me di cuenta de que el slashing es solo una parte del diseño. Lo que destacó fue que la rendición de cuentas y la propiedad no parecen tratarse como lo mismo. Incluso después del staking, Bitcoin sigue siendo recuperable mientras el staker y el validador delegado continúen siguiendo las reglas del protocolo. Eso cambió la forma en que miré el sistema. No parece crear seguridad tomando más control sobre los activos de los usuarios. En cambio, mantiene la propiedad separada mientras hace que la conducta deshonesta sea costosa. Noté algo similar al observar el proceso de retiro. Esperaba que el unbonding dependiera de otra ronda de coordinación entre validadores, pero una vez que se cumplen las condiciones requeridas, los retiros están diseñados para avanzar sin necesitar coordinación de consenso nueva. Es un detalle fácil de pasar por alto, pero elimina en silencio otro lugar en el que los usuarios tendrían que depender de la red. Mirar cada mecanismo por separado no se siente especialmente sorprendente. Ver cómo encajan juntos, sí. El modelo de seguridad parece menos enfocado en añadir protección en todas partes y más enfocado en decidir exactamente dónde debe existir la confianza y dónde no. Si estos límites se mantienen intactos a medida que Babylon crece, ¿se convertirán en su garantía de seguridad más fuerte? #baby $BABY $BTC
@BabylonLabs_io Lo que me tomó por sorpresa no fue una característica o un indicador. Fue con qué frecuencia Babylon separa ideas que la mayoría de los protocolos tienden a agrupar.
Entré pensando que el modelo de seguridad se centraría principalmente en el slashing. Esa parte es bastante directa. Si un validador delegado comete una infracción sancionable, se puede perder una porción de la participación en Bitcoin. La consecuencia económica es clara.
Pero cuanto más seguí el flujo de staking, más me di cuenta de que el slashing es solo una parte del diseño.
Lo que destacó fue que la rendición de cuentas y la propiedad no parecen tratarse como lo mismo. Incluso después del staking, Bitcoin sigue siendo recuperable mientras el staker y el validador delegado continúen siguiendo las reglas del protocolo. Eso cambió la forma en que miré el sistema. No parece crear seguridad tomando más control sobre los activos de los usuarios. En cambio, mantiene la propiedad separada mientras hace que la conducta deshonesta sea costosa.

Noté algo similar al observar el proceso de retiro. Esperaba que el unbonding dependiera de otra ronda de coordinación entre validadores, pero una vez que se cumplen las condiciones requeridas, los retiros están diseñados para avanzar sin necesitar coordinación de consenso nueva. Es un detalle fácil de pasar por alto, pero elimina en silencio otro lugar en el que los usuarios tendrían que depender de la red.

Mirar cada mecanismo por separado no se siente especialmente sorprendente. Ver cómo encajan juntos, sí. El modelo de seguridad parece menos enfocado en añadir protección en todas partes y más enfocado en decidir exactamente dónde debe existir la confianza y dónde no.

Si estos límites se mantienen intactos a medida que Babylon crece, ¿se convertirán en su garantía de seguridad más fuerte?
#baby $BABY $BTC
Necessary Trust?
50%
Deliberate Boundaries?
50%
Lasting Resilience?
0%
2 Votos • Votación cerrada
¿Hemos estado haciendo la pregunta equivocada sobre la seguridad de Bitcoin todo este tiempo? @babylonlabs_io ¡Gente!! Pensé que iba a pasar una hora entendiendo cómo un Bóveda de Bitcoin sin confianza (Trustless) bloquea BTC. En algún punto entre releer las mismas secciones y llenar otra página de notas, me di cuenta de que estaba invirtiendo mucho más tiempo pensando en la confianza que en la custodia. Mi primera suposición fue simple: si Bitcoin se está usando como colateral en algún otro lugar, entonces alguien debe ser responsable de guardarlo. Esa suposición se fue desmoronando cuanto más me quedaba con ella. Lo que me volvía una y otra vez no era simplemente que el BTC se queda en Bitcoin. Era la forma en que las condiciones de gasto se fijan cuando se crea la bóveda. Cuando empecé a mirarlo desde ese ángulo, dejé de buscar la parte “que sostiene” el Bitcoin y presté más atención a las reglas que determinan cómo puede moverse. Eso no hace que el sistema esté libre de riesgos. Las rutas de recuperación siguen importando. Aún existen estados de pausa operativa. La red de pruebas pública también trae sus propias salvedades. Me encontré trazando esos compromisos porque revelan lo que el protocolo realmente asume, en lugar de lo que la gente a menudo cree que asume. En algún momento mis notas dejaron de tratar de custodia por completo. Estaba esbozando supuestos de confianza en su lugar, tachando cosas, dibujando flechas y luego volviéndolas a tachar. La pregunta que tenía enfrente había cambiado en silencio....bczz no terminé “¿Quién controla el Bitcoin?” 🤔 Terminé preguntándome dónde vive realmente la confianza cuando está incrustada en reglas del protocolo en lugar de en instituciones. ¿Qué opinas?? ¿Estamos mejorando al eliminar la confianza o solo mejorando al reubicarla? #baby $BABY
¿Hemos estado haciendo la pregunta equivocada sobre la seguridad de Bitcoin todo este tiempo?
@BabylonLabs_io
¡Gente!! Pensé que iba a pasar una hora entendiendo cómo un Bóveda de Bitcoin sin confianza (Trustless) bloquea BTC. En algún punto entre releer las mismas secciones y llenar otra página de notas, me di cuenta de que estaba invirtiendo mucho más tiempo pensando en la confianza que en la custodia.
Mi primera suposición fue simple: si Bitcoin se está usando como colateral en algún otro lugar, entonces alguien debe ser responsable de guardarlo.
Esa suposición se fue desmoronando cuanto más me quedaba con ella.
Lo que me volvía una y otra vez no era simplemente que el BTC se queda en Bitcoin. Era la forma en que las condiciones de gasto se fijan cuando se crea la bóveda. Cuando empecé a mirarlo desde ese ángulo, dejé de buscar la parte “que sostiene” el Bitcoin y presté más atención a las reglas que determinan cómo puede moverse.
Eso no hace que el sistema esté libre de riesgos. Las rutas de recuperación siguen importando. Aún existen estados de pausa operativa. La red de pruebas pública también trae sus propias salvedades. Me encontré trazando esos compromisos porque revelan lo que el protocolo realmente asume, en lugar de lo que la gente a menudo cree que asume.
En algún momento mis notas dejaron de tratar de custodia por completo. Estaba esbozando supuestos de confianza en su lugar, tachando cosas, dibujando flechas y luego volviéndolas a tachar. La pregunta que tenía enfrente había cambiado en silencio....bczz no terminé
“¿Quién controla el Bitcoin?” 🤔
Terminé preguntándome dónde vive realmente la confianza cuando está incrustada en reglas del protocolo en lugar de en instituciones.
¿Qué opinas??
¿Estamos mejorando al eliminar la confianza o solo mejorando al reubicarla?
#baby $BABY
@babylonlabs_io Lo que empezó como una inmersión en la arquitectura de Babilonia se convirtió lentamente en un recordatorio de que entender el riesgo es tan importante como entender cómo funciona un protocolo Pensé que pasaría la tarde aprendiendo sobre el staking. Pero seguí yendo a la sección de riesgos. Incluso tomé otro café y releí algunas páginas porque una de mis notas no coincidía con lo que estaba leyendo Al principio pensé que la seguridad respaldada por Bitcoin significaba que la mayoría de los riesgos ya estaban cubiertos. Cuanto más leía, más me daba cuenta de que no era así. Como cualquier protocolo de blockchain, Babylon todavía tiene riesgos de contrato, de protocolo y de mercado, y cada uno es diferente Al principio los había agrupado todos en mi cabeza. Luego volví a revisar la documentación. El riesgo de smart contract consiste en que el código funcione como se espera. El riesgo de protocolo puede cambiar a medida que la red crece mediante actualizaciones o decisiones de gobernanza. El riesgo de mercado es distinto. Incluso un protocolo ya implementado no puede evitar las variaciones de precio ni las condiciones cambiantes del mercado Casi me salté esa parte de la documentación porque pensé que ya lo entendía. Me alegra no haberlo hecho. No intentaba decir que Babylon no tenga riesgos. Solo estaba recordando a los usuarios que comprendan los riesgos antes de participar. Es curioso: empecé buscando oportunidades y terminé leyendo las secciones de precaución ¿Qué riesgo de Babylon crees que merece más atención antes de decidir participar? #baby $BABY $BTC
@BabylonLabs_io Lo que empezó como una inmersión en la arquitectura de Babilonia se convirtió lentamente en un recordatorio de que entender el riesgo es tan importante como entender cómo funciona un protocolo
Pensé que pasaría la tarde aprendiendo sobre el staking. Pero seguí yendo a la sección de riesgos. Incluso tomé otro café y releí algunas páginas porque una de mis notas no coincidía con lo que estaba leyendo
Al principio pensé que la seguridad respaldada por Bitcoin significaba que la mayoría de los riesgos ya estaban cubiertos. Cuanto más leía, más me daba cuenta de que no era así. Como cualquier protocolo de blockchain, Babylon todavía tiene riesgos de contrato, de protocolo y de mercado, y cada uno es diferente
Al principio los había agrupado todos en mi cabeza. Luego volví a revisar la documentación. El riesgo de smart contract consiste en que el código funcione como se espera. El riesgo de protocolo puede cambiar a medida que la red crece mediante actualizaciones o decisiones de gobernanza. El riesgo de mercado es distinto. Incluso un protocolo ya implementado no puede evitar las variaciones de precio ni las condiciones cambiantes del mercado
Casi me salté esa parte de la documentación porque pensé que ya lo entendía. Me alegra no haberlo hecho. No intentaba decir que Babylon no tenga riesgos. Solo estaba recordando a los usuarios que comprendan los riesgos antes de participar.
Es curioso: empecé buscando oportunidades y terminé leyendo las secciones de precaución
¿Qué riesgo de Babylon crees que merece más atención antes de decidir participar?
#baby $BABY $BTC
🔸I'd start with protocol risk
100%
🔸I'd read the risk section
0%
🔸Smart contract risk for me.
0%
2 Votos • Votación cerrada
Con verificación
@babylonlabs_io Esperaba que los Bóvedas Bitcoin sin confianza de Babylon tuvieran tres rutas de redención diferentes. Lo que encontré fue un único modelo de seguridad repetido en todas ellas. Babylon ya ha atraído más de 100,000 BTC en stake comprometido, lo que me hizo preguntarme cómo un sistema de este tamaño gestiona las salidas sin reemplazar una suposición de confianza por otra. Comencé a trazar cómo funcionaba cada ruta de redención, esperando que sus suposiciones de seguridad divergieran en algún punto del camino. Después de releer la documentación, me di cuenta de que todas convergen en el mismo mecanismo de finalización. Independientemente de que el BTC se redima mediante rutas de diferentes redes, todas terminan con el mismo proceso. Una prueba de conocimiento cero se verifica en Bitcoin mediante la construcción BABE, seguida de un período de desafío de aproximadamente tres días. Durante esa ventana, un Universal Challenger, un Application Vault Keeper o incluso el depositante pueden disputar una reclamación inválida antes de que se libere cualquier BTC. Esa capa compartida de verificación cambió en silencio la forma en que pienso sobre el diseño de la bóveda. La ruta de redención pasa a ser menos importante que la consistencia de las garantías de liquidación que se encuentran debajo. En lugar de confiar en la red que inició la solicitud, cada ruta se somete al mismo proceso de verificación y disputa antes de que se finalice la liquidación. Me hizo darme cuenta de que el problema de ingeniería más difícil no es mover Bitcoin entre redes; es asegurar que cada salida siga las mismas suposiciones de seguridad. ¿La innovación real es la ruta o el modelo de seguridad compartido que hay detrás? #baby $BABY $BTC
@BabylonLabs_io Esperaba que los Bóvedas Bitcoin sin confianza de Babylon tuvieran tres rutas de redención diferentes. Lo que encontré fue un único modelo de seguridad repetido en todas ellas.
Babylon ya ha atraído más de 100,000 BTC en stake comprometido, lo que me hizo preguntarme cómo un sistema de este tamaño gestiona las salidas sin reemplazar una suposición de confianza por otra.
Comencé a trazar cómo funcionaba cada ruta de redención, esperando que sus suposiciones de seguridad divergieran en algún punto del camino. Después de releer la documentación, me di cuenta de que todas convergen en el mismo mecanismo de finalización.
Independientemente de que el BTC se redima mediante rutas de diferentes redes, todas terminan con el mismo proceso. Una prueba de conocimiento cero se verifica en Bitcoin mediante la construcción BABE, seguida de un período de desafío de aproximadamente tres días. Durante esa ventana, un Universal Challenger, un Application Vault Keeper o incluso el depositante pueden disputar una reclamación inválida antes de que se libere cualquier BTC.
Esa capa compartida de verificación cambió en silencio la forma en que pienso sobre el diseño de la bóveda. La ruta de redención pasa a ser menos importante que la consistencia de las garantías de liquidación que se encuentran debajo. En lugar de confiar en la red que inició la solicitud, cada ruta se somete al mismo proceso de verificación y disputa antes de que se finalice la liquidación.
Me hizo darme cuenta de que el problema de ingeniería más difícil no es mover Bitcoin entre redes; es asegurar que cada salida siga las mismas suposiciones de seguridad.
¿La innovación real es la ruta o el modelo de seguridad compartido que hay detrás?

#baby $BABY $BTC
🟢 Security
86%
🟢Convergence
0%
🟢Redemption
0%
🟢Settlement
14%
7 Votos • Votación cerrada
@babylonlabs_io I kept zooming out, then back in again, because every layer of Babylon seemed to answer one question while creating another. Initially assumed the Cosmos SDK node was where most of the interesting engineering lived. I even sketched it in the center of my notes. Then I went back through the checkpointing section and realized I was following the protocol from the wrong direction. What first caught my attention wasn't a single module. It was how Bitcoin scripts, checkpointing, the BTC staking monitor, and the Vigilante network keep Bitcoin and Babylon Genesis aligned without asking them to behave like the same chain. I paused there longer than I expected. The Babylon node sits in the middle, bringing together modules like Epoching, BTC Staking, Finality, Rewards, and the BTC Light Client. On paper they read like independent building blocks. Reading them together, they started to feel more like a set of relationships than a list of features. The lower layer took me the longest to understand. Finality Providers, the EOTS Manager, Covenant Emulator, and IBC relayers kept appearing in different parts of the documentation, so I found myself jumping between tabs just to see how they connected. That's where the architecture finally clicked. These components validate external data, enforce staking and unbonding transactions, and standardize communication across networks, but they're also what make the higher layers possible in the first place. Somewhere in that layered design, Babylon stopped looking like a staking protocol in my notes. It started to look more like infrastructure whose real job is coordinating trust across systems. What does this architecture tell us about Babylon's priorities? #baby $BABY $BTC
@BabylonLabs_io I kept zooming out, then back in again, because every layer of Babylon seemed to answer one question while creating another.
Initially assumed the Cosmos SDK node was where most of the interesting engineering lived. I even sketched it in the center of my notes. Then I went back through the checkpointing section and realized I was following the protocol from the wrong direction.
What first caught my attention wasn't a single module. It was how Bitcoin scripts, checkpointing, the BTC staking monitor, and the Vigilante network keep Bitcoin and Babylon Genesis aligned without asking them to behave like the same chain. I paused there longer than I expected.
The Babylon node sits in the middle, bringing together modules like Epoching, BTC Staking, Finality, Rewards, and the BTC Light Client. On paper they read like independent building blocks. Reading them together, they started to feel more like a set of relationships than a list of features.
The lower layer took me the longest to understand. Finality Providers, the EOTS Manager, Covenant Emulator, and IBC relayers kept appearing in different parts of the documentation, so I found myself jumping between tabs just to see how they connected. That's where the architecture finally clicked. These components validate external data, enforce staking and unbonding transactions, and standardize communication across networks, but they're also what make the higher layers possible in the first place.
Somewhere in that layered design, Babylon stopped looking like a staking protocol in my notes. It started to look more like infrastructure whose real job is coordinating trust across systems.

What does this architecture tell us about Babylon's priorities?
#baby $BABY $BTC
@babylonlabs_io Quizás la verdadera escasez en las criptomonedas nunca fue el espacio de bloque. Quizás fue la seguridad económica. Babylon me llevó por un camino que no esperaba. Siempre traté la seguridad como la tarifa de entrada: cada cadena Proof-of-Stake tenía que pagarla. Construir el conjunto de validadores. Crecer lo suficiente el peso económico detrás de ello. Esperar a través de suficientes ciclos de mercado para que la gente deje de preguntarse si un ataque coordinado sigue siendo barato. Así es como maduraban las redes nuevas. Luego me di cuenta de que estaba tratando ese proceso como si fuera una ley de la naturaleza. Bitcoin nunca se saltó esos años. Los absorbió. Cada ataque fallido, cada retirada brutal, cada periodo en el que la gente estaba convencida de que no sobreviviría añadió algo que no se puede reproducir con recompensas de staking más altas o con un tesoro más grande. La seguridad económica se acumula de manera distinta. Esa es la parte de Babylon que no podía ignorar. El protocolo no intenta recrear la historia de Bitcoin. Parte del supuesto de que la historia ya existe. Si la seguridad de Bitcoin puede extenderse a cadenas Proof-of-Stake, una red ya no tiene que comprimir quince años de credibilidad en sus primeros momentos. Ese es un punto de partida muy diferente.Y también cambia los incentivos. Cuando la seguridad económica no es el primer obstáculo, la conversación se desplaza hacia todo lo que viene después: su ejecución, coordinación, aplicaciones y si la red crea suficiente valor como para justificar la seguridad que hay debajo. Aún no sé hasta dónde llega esa idea. Pero sigo volviendo a la misma pregunta: si Bitcoin puede asegurar cadenas PoS, ¿en qué deberían competir esas cadenas una vez que la seguridad ya no es lo más difícil de construir? #baby $BABY
@BabylonLabs_io Quizás la verdadera escasez en las criptomonedas nunca fue el espacio de bloque.
Quizás fue la seguridad económica.
Babylon me llevó por un camino que no esperaba.
Siempre traté la seguridad como la tarifa de entrada: cada cadena Proof-of-Stake tenía que pagarla. Construir el conjunto de validadores. Crecer lo suficiente el peso económico detrás de ello. Esperar a través de suficientes ciclos de mercado para que la gente deje de preguntarse si un ataque coordinado sigue siendo barato. Así es como maduraban las redes nuevas.
Luego me di cuenta de que estaba tratando ese proceso como si fuera una ley de la naturaleza.
Bitcoin nunca se saltó esos años. Los absorbió. Cada ataque fallido, cada retirada brutal, cada periodo en el que la gente estaba convencida de que no sobreviviría añadió algo que no se puede reproducir con recompensas de staking más altas o con un tesoro más grande. La seguridad económica se acumula de manera distinta.
Esa es la parte de Babylon que no podía ignorar.
El protocolo no intenta recrear la historia de Bitcoin. Parte del supuesto de que la historia ya existe. Si la seguridad de Bitcoin puede extenderse a cadenas Proof-of-Stake, una red ya no tiene que comprimir quince años de credibilidad en sus primeros momentos. Ese es un punto de partida muy diferente.Y también cambia los incentivos.
Cuando la seguridad económica no es el primer obstáculo, la conversación se desplaza hacia todo lo que viene después: su ejecución, coordinación, aplicaciones y si la red crea suficiente valor como para justificar la seguridad que hay debajo.
Aún no sé hasta dónde llega esa idea.
Pero sigo volviendo a la misma pregunta: si Bitcoin puede asegurar cadenas PoS, ¿en qué deberían competir esas cadenas una vez que la seguridad ya no es lo más difícil de construir?
#baby $BABY
@OpenGradient Un pequeño detalle se repetía mientras trazaba los flujos de trabajo recientes de agentes. Las cadenas de razonamiento se volvieron más sofisticadas con cada iteración. Sin embargo, justo en el momento en que esas cadenas salieron del modelo y entraron en un entorno de ejecución, la arquitectura de repente se sintió más antigua. Casi heredada. Ese desajuste se ha quedado conmigo más tiempo de lo que esperaba. Hablamos de inteligencia como si los modelos mejores produjeran automáticamente sistemas mejores. No estoy convencido de que sea así. La coordinación sigue apareciendo como la restricción más silenciosa. No la calidad del modelo. Algo que está por debajo de esas capas. Al observar el kit de herramientas OpenGradient para la integración con LangChain, me encontré prestando menos atención a la integración en sí que a lo que OpenGradient asume en silencio sobre la inferencia. La inferencia descentralizada entra en el flujo de trabajo de un agente casi sin exigir atención. La ejecución deja de sentirse como un destino. Empieza a incorporar suposiciones económicas y de gobernanza que la mayoría de las aplicaciones nunca exponen. A menudo se describe la infraestructura como si simplemente recibiera instrucciones. No creo que sea exacto. Recompensa ciertas rutas de ejecución, desalienta otras y, luego, influye en silencio en lo que los desarrolladores finalmente confunden con un buen diseño. Volví una y otra vez a la conexión de LangChain dentro de OpenGradient. Lo interesante no era otro framework alcanzando otra red. Era la distancia que se encogía entre la lógica del agente y la inferencia descentralizada. A medida que ese límite se desvanece, la economía que hay debajo de la ejecución se vuelve más difícil de ignorar. Últimamente me he preguntado si OpenGradient apunta a algo más institucional que técnico. La verificación, la coordinación y la ejecución comienzan a afectarse mutuamente hasta que la distinción en sí se debilita. Nada dramático anuncia ese cambio. Otro kit de herramientas. Otra integración. Las suposiciones que están debajo se mueven primero. Si OpenGradient hace que la inferencia descentralizada se sienta ordinaria, ¿qué suposiciones dejan de verse como opcionales? #opg $OPG
@OpenGradient Un pequeño detalle se repetía mientras trazaba los flujos de trabajo recientes de agentes. Las cadenas de razonamiento se volvieron más sofisticadas con cada iteración. Sin embargo, justo en el momento en que esas cadenas salieron del modelo y entraron en un entorno de ejecución, la arquitectura de repente se sintió más antigua. Casi heredada.

Ese desajuste se ha quedado conmigo más tiempo de lo que esperaba.

Hablamos de inteligencia como si los modelos mejores produjeran automáticamente sistemas mejores. No estoy convencido de que sea así. La coordinación sigue apareciendo como la restricción más silenciosa. No la calidad del modelo. Algo que está por debajo de esas capas.

Al observar el kit de herramientas OpenGradient para la integración con LangChain, me encontré prestando menos atención a la integración en sí que a lo que OpenGradient asume en silencio sobre la inferencia. La inferencia descentralizada entra en el flujo de trabajo de un agente casi sin exigir atención. La ejecución deja de sentirse como un destino. Empieza a incorporar suposiciones económicas y de gobernanza que la mayoría de las aplicaciones nunca exponen.

A menudo se describe la infraestructura como si simplemente recibiera instrucciones. No creo que sea exacto. Recompensa ciertas rutas de ejecución, desalienta otras y, luego, influye en silencio en lo que los desarrolladores finalmente confunden con un buen diseño.

Volví una y otra vez a la conexión de LangChain dentro de OpenGradient. Lo interesante no era otro framework alcanzando otra red. Era la distancia que se encogía entre la lógica del agente y la inferencia descentralizada. A medida que ese límite se desvanece, la economía que hay debajo de la ejecución se vuelve más difícil de ignorar.

Últimamente me he preguntado si OpenGradient apunta a algo más institucional que técnico. La verificación, la coordinación y la ejecución comienzan a afectarse mutuamente hasta que la distinción en sí se debilita.

Nada dramático anuncia ese cambio. Otro kit de herramientas. Otra integración. Las suposiciones que están debajo se mueven primero.

Si OpenGradient hace que la inferencia descentralizada se sienta ordinaria, ¿qué suposiciones dejan de verse como opcionales?
#opg $OPG
Trust models
50%
Coordination rules
25%
Execution incentives
25%
4 Votos • Votación cerrada
Una inferencia se asentó y me di cuenta de que la respuesta desaparecía más rápido que la opción de asentamiento que había detrás. Eso se me quedó. Mientras profundizaba en la arquitectura x402 de @OpenGradient OpenGradient, quedó claro que el asentamiento no se trata como simple contabilidad después de la inferencia. Es parte del propio diseño de la inferencia. PRIVATE permite ejecutar sin dejar rastros en la cadena. BATCH_HASHED, la ruta predeterminada, ancla muchas inferencias mediante compromisos de Merkle agregados. INDIVIDUAL_FULL conserva el registro completo de la inferencia, incluida la información del modelo, las entradas, las salidas y los metadatos de ejecución. Sigo volviendo a lo que esas decisiones implican en silencio. No solo cambian el almacenamiento. Redistribuyen dónde vive la confianza, qué puede verificarse de forma independiente y cuánta información histórica decide conservar la red. El modo de asentamiento empieza a influir en la coordinación mucho antes de que alguien note que está influyendo en la gobernanza. Eso se siente inusualmente alineado con la dirección de OpenGradient. Si la inferencia se está convirtiendo en un primitivo económico, entonces el asentamiento ya no es una capa administrativa por debajo de ella. Pasa a formar parte del lenguaje del protocolo para expresar privacidad, evidencia y permanencia sin asumir que cada carga de trabajo deba hacer el mismo tipo de intercambio. Me interesa menos qué modo se vuelve dominante que si distintas categorías de inferencia se asientan naturalmente de manera diferente con el tiempo. La métrica que estoy vigilando es la distribución cambiante de PRIVATE, BATCH_HASHED e INDIVIDUAL_FULL en la inferencia de la red. ¿Qué empieza a revelar esa distribución sobre cómo la inteligencia quiere coordinarse? #opg $OPG
Una inferencia se asentó y me di cuenta de que la respuesta desaparecía más rápido que la opción de asentamiento que había detrás.

Eso se me quedó.

Mientras profundizaba en la arquitectura x402 de @OpenGradient OpenGradient, quedó claro que el asentamiento no se trata como simple contabilidad después de la inferencia. Es parte del propio diseño de la inferencia. PRIVATE permite ejecutar sin dejar rastros en la cadena. BATCH_HASHED, la ruta predeterminada, ancla muchas inferencias mediante compromisos de Merkle agregados. INDIVIDUAL_FULL conserva el registro completo de la inferencia, incluida la información del modelo, las entradas, las salidas y los metadatos de ejecución.

Sigo volviendo a lo que esas decisiones implican en silencio. No solo cambian el almacenamiento. Redistribuyen dónde vive la confianza, qué puede verificarse de forma independiente y cuánta información histórica decide conservar la red. El modo de asentamiento empieza a influir en la coordinación mucho antes de que alguien note que está influyendo en la gobernanza.

Eso se siente inusualmente alineado con la dirección de OpenGradient. Si la inferencia se está convirtiendo en un primitivo económico, entonces el asentamiento ya no es una capa administrativa por debajo de ella. Pasa a formar parte del lenguaje del protocolo para expresar privacidad, evidencia y permanencia sin asumir que cada carga de trabajo deba hacer el mismo tipo de intercambio.

Me interesa menos qué modo se vuelve dominante que si distintas categorías de inferencia se asientan naturalmente de manera diferente con el tiempo.

La métrica que estoy vigilando es la distribución cambiante de PRIVATE, BATCH_HASHED e INDIVIDUAL_FULL en la inferencia de la red.

¿Qué empieza a revelar esa distribución sobre cómo la inteligencia quiere coordinarse?
#opg $OPG
🔹Verification Priorities
0%
🔹Trust Preferences
0%
🔹Coordination Logic
0%
0 Votos • Votación cerrada
@OpenGradient La primera wallet que conecto a una red me dice más que cualquier documentación. Es un pequeño momento. Fácil de pasar por alto. Sin embargo, casi siempre es ahí donde empiezo a entender con qué tipo de infraestructura realmente estoy tratando. Cuando conecté mi wallet compatible con Ethereum a OpenGradient, nada de la configuración me pareció desconocido. Instalé MetaMask, añadí manualmente la red de OpenGradient, cambié y financié la dirección. Los pasos fueron directos. Casi ordinarios. Esa experiencia ordinaria fue lo que captó mi atención. OpenGradient está construido alrededor de la ejecución descentralizada de IA, pero antes de que pueda ocurrir cualquier inferencia, la red primero establece una relación a través de la wallet. Lo que parece una conexión sencilla es también el punto en el que comienzan a compartir la misma capa operativa la identidad, las transacciones y la participación futura. No creo que sea casualidad. Cuanto más observo la infraestructura de IA, menos veo la configuración de la wallet como un proceso de incorporación. La veo como el primer evento de coordinación. El protocolo reconoce una identidad antes de coordinar cualquier cómputo. La interacción dura solo unos minutos, pero en silencio marca cada interacción que sigue. La interfaz familiar de MetaMask oculta el hecho de que no me estoy limitando a conectarme a otra red EVM. Estoy estableciendo la ruta por la cual OpenGradient puede coordinar la ejecución descentralizada de IA con la participación en la red. Entonces, ¿qué es lo que realmente empieza cuando se conecta la wallet? #opg $OPG
@OpenGradient La primera wallet que conecto a una red me dice más que cualquier documentación.

Es un pequeño momento. Fácil de pasar por alto.

Sin embargo, casi siempre es ahí donde empiezo a entender con qué tipo de infraestructura realmente estoy tratando.

Cuando conecté mi wallet compatible con Ethereum a OpenGradient, nada de la configuración me pareció desconocido. Instalé MetaMask, añadí manualmente la red de OpenGradient, cambié y financié la dirección. Los pasos fueron directos. Casi ordinarios.

Esa experiencia ordinaria fue lo que captó mi atención.

OpenGradient está construido alrededor de la ejecución descentralizada de IA, pero antes de que pueda ocurrir cualquier inferencia, la red primero establece una relación a través de la wallet. Lo que parece una conexión sencilla es también el punto en el que comienzan a compartir la misma capa operativa la identidad, las transacciones y la participación futura.

No creo que sea casualidad.

Cuanto más observo la infraestructura de IA, menos veo la configuración de la wallet como un proceso de incorporación. La veo como el primer evento de coordinación. El protocolo reconoce una identidad antes de coordinar cualquier cómputo. La interacción dura solo unos minutos, pero en silencio marca cada interacción que sigue.

La interfaz familiar de MetaMask oculta el hecho de que no me estoy limitando a conectarme a otra red EVM. Estoy estableciendo la ruta por la cual OpenGradient puede coordinar la ejecución descentralizada de IA con la participación en la red.

Entonces, ¿qué es lo que realmente empieza cuando se conecta la wallet?
#opg $OPG
🟣Network Participation
75%
🔵Identity Coordination
13%
🟡Protocol Interaction
12%
🟢Compute Access
0%
8 Votos • Votación cerrada
@OpenGradient I me detuve en la palabra "verificado" hoy y me pregunté por qué se lo exigimos a las blockchains pero casi nunca a la IA. Eso se me quedó grabado más tiempo de lo que esperaba. Inspeccionaremos validadores, cuestionaremos puentes, discutiremos durante horas sobre la descentralización. Luego, un modelo de IA devuelve una respuesta y el proceso desaparece. Todo el mundo debate el resultado. Casi nadie pregunta si el cálculo en sí puede demostrarse. Yo seguía diciéndome que esto era, sobre todo, una conversación sobre IA. No lo era. La parte incómoda está debajo. Un sistema descentralizado no se vuelve confiable porque las cargas de trabajo se distribuyan en más máquinas. La confianza oculta tiene la costumbre de sobrevivir a los diagramas de arquitectura. A veces simplemente se desplaza. La ejecución empezó a sentirse más importante que el modelo. Esa era la hebra que no podía soltar. OpenGradient seguía apareciendo en segundo plano no porque sea otra red de IA, sino porque trata la inferencia como algo que no debería depender solo de la reputación. Si la ejecución puede verificarse y auditarse de forma independiente en una red descentralizada, la confianza empieza a adherirse al proceso en lugar de al proveedor. No creo que hayamos asimilado del todo lo que eso cambia. En realidad, no. La seguridad empieza a verse menos como proteger infraestructura y más como eliminar las razones para confiar en una infraestructura invisible desde el principio. Casi he dejado de prestar atención a las gráficas de benchmarks. El número que estoy mirando es mucho más pequeño: con qué frecuencia los desarrolladores piden una prueba de la ejecución antes de pedir un mejor rendimiento del modelo. Si la ejecución de la IA no puede verificarse de forma independiente, ¿qué exactamente estamos llamando descentralizado? #opg $OPG
@OpenGradient I me detuve en la palabra "verificado" hoy y me pregunté por qué se lo exigimos a las blockchains pero casi nunca a la IA.

Eso se me quedó grabado más tiempo de lo que esperaba.

Inspeccionaremos validadores, cuestionaremos puentes, discutiremos durante horas sobre la descentralización. Luego, un modelo de IA devuelve una respuesta y el proceso desaparece. Todo el mundo debate el resultado. Casi nadie pregunta si el cálculo en sí puede demostrarse.

Yo seguía diciéndome que esto era, sobre todo, una conversación sobre IA.

No lo era.

La parte incómoda está debajo. Un sistema descentralizado no se vuelve confiable porque las cargas de trabajo se distribuyan en más máquinas. La confianza oculta tiene la costumbre de sobrevivir a los diagramas de arquitectura. A veces simplemente se desplaza.

La ejecución empezó a sentirse más importante que el modelo.

Esa era la hebra que no podía soltar. OpenGradient seguía apareciendo en segundo plano no porque sea otra red de IA, sino porque trata la inferencia como algo que no debería depender solo de la reputación. Si la ejecución puede verificarse y auditarse de forma independiente en una red descentralizada, la confianza empieza a adherirse al proceso en lugar de al proveedor.

No creo que hayamos asimilado del todo lo que eso cambia.

En realidad, no.

La seguridad empieza a verse menos como proteger infraestructura y más como eliminar las razones para confiar en una infraestructura invisible desde el principio.

Casi he dejado de prestar atención a las gráficas de benchmarks.

El número que estoy mirando es mucho más pequeño: con qué frecuencia los desarrolladores piden una prueba de la ejecución antes de pedir un mejor rendimiento del modelo.

Si la ejecución de la IA no puede verificarse de forma independiente, ¿qué exactamente estamos llamando descentralizado?
#opg $OPG
Con verificación
URGENTE: 🇺🇸 La economía de EE. UU. superó las expectativas: la lectura final del PIB del 1T se situó en 2,1%, superando la previsión del 1,6% y señalando un impulso económico más sólido de lo esperado. #USGDP #Macro #MarketSentimentToday
URGENTE: 🇺🇸 La economía de EE. UU. superó las expectativas: la lectura final del PIB del 1T se situó en 2,1%, superando la previsión del 1,6% y señalando un impulso económico más sólido de lo esperado.

#USGDP #Macro #MarketSentimentToday
AHORA MISMO: 🇪🇺 CZ dice que la UE está dejando fuera a los usuarios de una de las mayores fuentes de liquidez cripto del mundo al no conceder a Binance una licencia MiCA. #CZ #Eu $G $TNSR #CZ
AHORA MISMO: 🇪🇺 CZ dice que la UE está dejando fuera a los usuarios de una de las mayores fuentes de liquidez cripto del mundo al no conceder a Binance una licencia MiCA.
#CZ #Eu
$G $TNSR
#CZ
·
--
Alcista
Las velas verdes están robándose el protagonismo hoy Unas cuantas nombres de futuros están destacando como compradores que siguen empujando los precios más arriba en todo el mercado. 🟢 Gravity ($G ) sube +45% 🟢 Heima ($HEI ) sube +33% 🟢 Tensor ($TNSR ) sube +18% El fuerte impulso vuelve al escenario, pero la gran pregunta es si estas subidas pueden seguir escalando o si los traders empezarán a asegurar ganancias. ¿Cuál de los principales ganadores estás siguiendo? - 🚀 G Liderando la subida - ⚡ HEI Construyendo impulso - 🔥 TNSR ¿Espacio para seguir? 👀 ¿Cuál tiene el mayor potencial alcista desde aquí? Deja tu opinión del mercado abajo 👇 #TopGainers
Las velas verdes están robándose el protagonismo hoy

Unas cuantas nombres de futuros están destacando como compradores que siguen empujando los precios más arriba en todo el mercado.

🟢 Gravity ($G ) sube +45%
🟢 Heima ($HEI ) sube +33%
🟢 Tensor ($TNSR ) sube +18%

El fuerte impulso vuelve al escenario, pero la gran pregunta es si estas subidas pueden seguir escalando o si los traders empezarán a asegurar ganancias.

¿Cuál de los principales ganadores estás siguiendo?

- 🚀 G Liderando la subida
- ⚡ HEI Construyendo impulso
- 🔥 TNSR ¿Espacio para seguir?

👀 ¿Cuál tiene el mayor potencial alcista desde aquí?

Deja tu opinión del mercado abajo 👇

#TopGainers
G 🚀
35%
HEI ⚡
48%
TNSR 🔥
17%
40 Votos • Votación cerrada
¿Qué ocurre realmente cuando un modelo tarda demasiado dentro de un bloque? No en teoría. En la práctica. El bloque está abierto. La inferencia sigue en ejecución. La ventana se está cerrando. Todo lo que está detrás espera. No porque falle la red. No porque se rompa el consenso. En algún punto de la ruta de ejecución, una máquina sigue trabajando en un cálculo que no le importa lo rápido que haya que construir el siguiente bloque. Yo seguí tirando de ese hilo. La producción de bloques asume que la ejecución se mantiene razonablemente acotada. Lo bastante rápida para secuenciar. Lo bastante predecible para finalizar. La inferencia de ML no se comporta así. Un modelo se ejecuta hasta que llega a una salida. A veces rápido. A veces no. La latencia de un modelo se convierte en la latencia del bloque y, a su vez, en la latencia de todos los usuarios. La mayoría de los usuarios nunca ve dónde se van esos segundos extra. Solo notan que las cosas se sienten más lentas que antes. Fue entonces cuando dejó de parecer un problema de cómputo. Empezó a parecer un problema arquitectónico. Eso es lo que hizo que la arquitectura PIPE de OpenGradient me encajara. El objetivo no es hacer que la producción de bloques espere de forma más eficiente. Es dejar de hacer que la producción de bloques espere en primer lugar. La inferencia se mueve a un mempool dedicado donde las solicitudes se ejecutan antes del armado del bloque. Mientras el consenso avanza, la inferencia ocupa su propio carril. Para cuando se construye un bloque, el trabajo costoso ya está resuelto. El bloque no está esperando a que se genere la inteligencia. Está reuniendo resultados. La complejidad de la inferencia deja de filtrarse directamente hacia la latencia del consenso. Los modelos más grandes pueden requerir más cómputo, pero no ralentizan automáticamente la producción de bloques. La pregunta interesante quizá no sea si la IA puede escalar on-chain. Podría ser si, al final, la infraestructura de IA necesita que el tiempo de ejecución y el tiempo de consenso se conviertan en capas económicas separadas por completo. Por ahora, estoy observando la profundidad del mempool de inferencia durante los picos de carga y si la latencia de producción de bloques permanece sin cambios mientras esa cola crece.#opg $OPG @OpenGradient
¿Qué ocurre realmente cuando un modelo tarda demasiado dentro de un bloque?
No en teoría. En la práctica.
El bloque está abierto. La inferencia sigue en ejecución. La ventana se está cerrando.
Todo lo que está detrás espera.
No porque falle la red. No porque se rompa el consenso. En algún punto de la ruta de ejecución, una máquina sigue trabajando en un cálculo que no le importa lo rápido que haya que construir el siguiente bloque.
Yo seguí tirando de ese hilo.
La producción de bloques asume que la ejecución se mantiene razonablemente acotada. Lo bastante rápida para secuenciar. Lo bastante predecible para finalizar.
La inferencia de ML no se comporta así.
Un modelo se ejecuta hasta que llega a una salida. A veces rápido. A veces no.
La latencia de un modelo se convierte en la latencia del bloque y, a su vez, en la latencia de todos los usuarios.
La mayoría de los usuarios nunca ve dónde se van esos segundos extra. Solo notan que las cosas se sienten más lentas que antes.
Fue entonces cuando dejó de parecer un problema de cómputo.
Empezó a parecer un problema arquitectónico.
Eso es lo que hizo que la arquitectura PIPE de OpenGradient me encajara.
El objetivo no es hacer que la producción de bloques espere de forma más eficiente. Es dejar de hacer que la producción de bloques espere en primer lugar.
La inferencia se mueve a un mempool dedicado donde las solicitudes se ejecutan antes del armado del bloque. Mientras el consenso avanza, la inferencia ocupa su propio carril. Para cuando se construye un bloque, el trabajo costoso ya está resuelto.
El bloque no está esperando a que se genere la inteligencia.
Está reuniendo resultados.
La complejidad de la inferencia deja de filtrarse directamente hacia la latencia del consenso. Los modelos más grandes pueden requerir más cómputo, pero no ralentizan automáticamente la producción de bloques.
La pregunta interesante quizá no sea si la IA puede escalar on-chain.
Podría ser si, al final, la infraestructura de IA necesita que el tiempo de ejecución y el tiempo de consenso se conviertan en capas económicas separadas por completo.
Por ahora, estoy observando la profundidad del mempool de inferencia durante los picos de carga y si la latencia de producción de bloques permanece sin cambios mientras esa cola crece.#opg $OPG @OpenGradient
·
--
Bajista
Las velas rojas están dominando el tablero de futuros hoy Algunos activos están enfrentando una fuerte presión de venta, con Biconomy ($BICO ), Resolv ($RESOLV ), ($ARX) Arcium liderando el movimiento a la baja. 🔻 BICO abajo -31.09% 🔻 RESOLV abajo -21.29% 🔻 ARX abajo -19.71% Las grandes ventas suelen captar la atención de los traders. Mientras algunos ven oportunidad en la caída, otros esperan confirmación antes de entrar al mercado. ¿Cuál tiene el mejor potencial de rebote? 🚀 BICO Corrección profunda ⚡ RESOLV Observando soporte 🔥 ARX Candidato a recuperación 👀 ¿Cuál estarías observando para un posible rebote? Comparte tu perspectiva del mercado abajo 👇 #TopLosers #MarketWatch
Las velas rojas están dominando el tablero de futuros hoy

Algunos activos están enfrentando una fuerte presión de venta, con Biconomy ($BICO ), Resolv ($RESOLV ), ($ARX) Arcium liderando el movimiento a la baja.

🔻 BICO abajo -31.09%
🔻 RESOLV abajo -21.29%
🔻 ARX abajo -19.71%
Las grandes ventas suelen captar la atención de los traders. Mientras algunos ven oportunidad en la caída, otros esperan confirmación antes de entrar al mercado.

¿Cuál tiene el mejor potencial de rebote?

🚀 BICO Corrección profunda
⚡ RESOLV Observando soporte
🔥 ARX Candidato a recuperación

👀 ¿Cuál estarías observando para un posible rebote?

Comparte tu perspectiva del mercado abajo 👇

#TopLosers #MarketWatch
BICO
37%
RESOLV
23%
ARX
40%
111 Votos • Votación cerrada
·
--
Alcista
Las velas verdes están robando el espectáculo hoy Algunos nombres de futuros están destacando mientras los compradores continúan empujando los precios hacia arriba en todas partes. 🟢 Synapse ($SYN ) subiendo hasta un +89% 🟢 Heima ($HEI ) subiendo hasta un +67% 🟢 DeXe ($DEXE ) subiendo hasta un +76% Movimientos fuertes como estos a menudo atraen a los traders de momentum, pero la verdadera pregunta es si estos rallies aún tienen espacio para seguir subiendo o si la toma de ganancias está a la vuelta de la esquina. 👀 ¿Cuál crees que tiene más potencial a partir de aquí? ¿Qué ganador top estás siguiendo? - 🚀 SYN Liderando el aumento - ⚡ HEI Fuerte momentum - 🔥 DEXE Manteniendo fuerza Deja tu opinión sobre el mercado abajo 👇 #TopGainers #MarketWatch
Las velas verdes están robando el espectáculo hoy

Algunos nombres de futuros están destacando mientras los compradores continúan empujando los precios hacia arriba en todas partes.

🟢 Synapse ($SYN ) subiendo hasta un +89%
🟢 Heima ($HEI ) subiendo hasta un +67%
🟢 DeXe ($DEXE ) subiendo hasta un +76%

Movimientos fuertes como estos a menudo atraen a los traders de momentum, pero la verdadera pregunta es si estos rallies aún tienen espacio para seguir subiendo o si la toma de ganancias está a la vuelta de la esquina.

👀 ¿Cuál crees que tiene más potencial a partir de aquí?
¿Qué ganador top estás siguiendo?

- 🚀 SYN Liderando el aumento
- ⚡ HEI Fuerte momentum
- 🔥 DEXE Manteniendo fuerza

Deja tu opinión sobre el mercado abajo 👇

#TopGainers #MarketWatch
SYN🔥
50%
HEI ⚡
22%
DEXE ❤️‍🔥
28%
32 Votos • Votación cerrada
@OpenGradient 156,461 inferencias se ejecutaron de forma privada el mes pasado en OpenGradient. No me quedé solo con su palabra. Abrí el panel de control, vi el contador en vivo y escribí mi propia pregunta para ver qué realmente sucede dentro. La pregunta fue simple: ¿puede la privacidad escalar a 156K inferencias? Lo que regresó no sonaba como un discurso de ventas. Tu prompt deja tu dispositivo ya encriptado. OHTTP elimina cada rastro de quién lo envió antes de que toque la red. Sin IP. Sin identidad. Nada. Luego se ejecuta dentro de un enclave de hardware, un entorno sellado donde incluso la máquina que lo aloja no puede ver lo que está sucediendo dentro. La respuesta regresa. Una prueba criptográfica viene con ella. Nadie vio el medio. Ni el operador. Ni OpenGradient. Nadie. Seguí pensando en eso. 10,390 inferencias solo hoy. 3,714 OG gastados para alimentar la red. BitQuant por sí solo ejecutando el 83% de todas las solicitudes a través de esto. Estas no son estimaciones. Estaba viendo los números moverse en vivo. En algún momento simplemente dejé de analizar y observé el contador. Escribimos cosas en la IA todos los días que nunca diríamos en voz alta. Pensamientos a medio terminar. Preguntas que nos da vergüenza hacer a la gente. Y la mayoría de las veces no tenemos idea de a dónde va todo eso realmente. Simplemente hicimos clic en aceptar y seguimos escribiendo. OpenGradient se construye sobre una suposición diferente. Que no deberías tener que confiar en nadie en absoluto. Nadie realmente piensa en ello. Hasta que lo hacen. Y entonces ya está hecho. El contador estaba en 156,461 cuando abrí la pestaña. No esperó a que terminara de pensar. Cuéntame en los comentarios ¿Cuándo fue la última vez que realmente verificaste a dónde fue tu data? ¿O simplemente hiciste clic en aceptar y seguiste escribiendo? $OPG #OPG
@OpenGradient 156,461 inferencias se ejecutaron de forma privada el mes pasado en OpenGradient.
No me quedé solo con su palabra. Abrí el panel de control, vi el contador en vivo y escribí mi propia pregunta para ver qué realmente sucede dentro.
La pregunta fue simple: ¿puede la privacidad escalar a 156K inferencias?
Lo que regresó no sonaba como un discurso de ventas.
Tu prompt deja tu dispositivo ya encriptado. OHTTP elimina cada rastro de quién lo envió antes de que toque la red. Sin IP. Sin identidad. Nada. Luego se ejecuta dentro de un enclave de hardware, un entorno sellado donde incluso la máquina que lo aloja no puede ver lo que está sucediendo dentro.
La respuesta regresa. Una prueba criptográfica viene con ella.
Nadie vio el medio. Ni el operador. Ni OpenGradient. Nadie.
Seguí pensando en eso.
10,390 inferencias solo hoy. 3,714 OG gastados para alimentar la red. BitQuant por sí solo ejecutando el 83% de todas las solicitudes a través de esto. Estas no son estimaciones. Estaba viendo los números moverse en vivo.
En algún momento simplemente dejé de analizar y observé el contador.
Escribimos cosas en la IA todos los días que nunca diríamos en voz alta. Pensamientos a medio terminar. Preguntas que nos da vergüenza hacer a la gente. Y la mayoría de las veces no tenemos idea de a dónde va todo eso realmente.
Simplemente hicimos clic en aceptar y seguimos escribiendo.
OpenGradient se construye sobre una suposición diferente. Que no deberías tener que confiar en nadie en absoluto.
Nadie realmente piensa en ello. Hasta que lo hacen. Y entonces ya está hecho.
El contador estaba en 156,461 cuando abrí la pestaña.
No esperó a que terminara de pensar.
Cuéntame en los comentarios
¿Cuándo fue la última vez que realmente verificaste a dónde fue tu data?
¿O simplemente hiciste clic en aceptar y seguiste escribiendo?
$OPG #OPG
Inicia sesión para explorar más contenidos
Únete a usuarios de criptomonedas de todo el mundo en Binance Square
⚡️ Obtén la información más reciente y útil sobre criptomonedas.
💬 Confía en el mayor exchange de criptomonedas del mundo.
👍 Descubre opiniones reales de creadores verificados.
Correo electrónico/número de teléfono
Mapa del sitio
Preferencias de cookies
Términos y condiciones de la plataforma