Antes pensaba que que bitcoin no admita covenants era solo una nota técnica, un tipo de detalle que los desarrolladores mencionan antes de pasar al producto real. Me corregí una vez que entendí por qué esa ausencia es, precisamente, la razón por la cual los vaults sin confianza son difíciles de construir.
Un covenant te permitiría restringir cómo se gasta el bitcoin en el futuro, a nivel de script, antes incluso de que ocurra. Bitcoin deliberadamente no tiene eso. cada intento de añadirlo se ha estancado durante años, en parte porque dar al script el poder de limitar el gasto futuro también le da el poder de crear nuevos tipos de modos de fallo que nadie ha mapeado del todo todavía.
Así que Babylon no está sorteando una función que eventualmente se añadirá; está diseñando un sistema de vaults asumiendo que los covenants quizá nunca existan en bitcoin. por eso la solución real se apoya en cosas como gráficos de transacciones prefirmadas y pruebas basadas en retos, recreando restricciones tipo covenant mediante coordinación y criptografía en lugar de hacerlo mediante un nuevo opcode que el núcleo de bitcoin tendría que aprobar.
Lo que no dejo de preguntarme es si ese enfoque es realmente el camino más conservador o solo uno más difícil disfrazado de cautela.
Incorporar la restricción en la fase de configuración evita tocar las reglas de consenso de bitcoin, pero también significa que cada caso de uso nuevo tiene que resolverse desde cero en la capa de la aplicación, en vez de obtener una primitiva general una sola vez, en la capa de protocolo.
Asumí que BABY era principalmente un token de gobernanza en el sentido habitual: algo que tienes para votar propuestas que nadie lee con atención, hasta que vi cómo en realidad se conecta con la estructura de comisiones del protocolo.
la mayoría de los tokens de gobernanza votan parámetros después de los hechos, ajustando un número aquí o allá una vez que la decisión ya se ha debatido en otro lugar. ese es un papel bastante pasivo. lo interesante con BABY es el mecanismo de comisiones basado en subastas que se encuentra debajo de la capa de gobernanza.
las comisiones del protocolo no solo se recaudan y se distribuyen: pasan por un proceso de subasta, lo que significa que el token no solo decide reglas desde fuera, sino que está conectado a cómo el valor se mueve realmente a través del sistema en tiempo real.
esa distinción importa más de lo que suena. un token que solo vota parámetros estáticos puede ser en gran medida decorativo si nadie está prestando atención. un token que, por su estructura, es requisito para un mecanismo de subastas en curso tiene que mantenerse funcionalmente relevante solo para que el sistema siga operando como está diseñado.
lo que aún no puedo determinar es si ese diseño de subasta realmente produce un mejor descubrimiento de precios para las comisiones que un modelo de tarifa fija más simple, o si simplemente añade complejidad que parece sofisticada sin cambiar mucho el resultado. las subastas funcionan bien cuando hay suficiente demanda en competencia para que sean significativas. todavía no sé si existe esa demanda en el uso de TBV.
Antes asumía que "prueba basada en desafíos" significaba que el sistema se desafiaba a sí mismo de alguna manera, con algún proceso automatizado funcionando en silencio en segundo plano. Cambié de opinión cuando me di cuenta de que un desafío solo ocurre si alguien realmente envía uno.
todo el modelo de seguridad detrás de demostrar que algo ocurrió en otra cadena, sin bifurcar bitcoin, depende de que exista una ventana de desafío en la que cualquiera puede disputar una reclamación si es incorrecta. eso suena sólido en teoría. pero "cualquiera puede" y "alguien realmente hace" son dos garantías muy diferentes. si se presenta una redención fraudulenta y nadie está vigilando lo bastante de cerca como para detectarla dentro de esa ventana, el mecanismo de desafío no falla técnicamente: simplemente nunca se utiliza.
eso desplaza parte de la pregunta de seguridad desde la criptografía hacia los incentivos. ¿hay una recompensa suficiente para ejecutar un vigilante que revise cada redención, o ese trabajo se deja principalmente a quien ocurra estar prestando atención? muchos sistemas basados en desafíos en otros lugares se han topado exactamente con este problema: la prueba funciona bien sobre el papel, pero el número real de desafiadores activos resulta ser menor de lo asumido cuando hay dinero real en juego.
lo que todavía no sé es si el diseño de Babylon contempla esto haciendo que desafiar sea lo bastante rentable por sí mismo, o si actualmente depende de la suposición de que suficientes personas solo vigilarán por interés propio sin que se les pague directamente por hacerlo.
Asumí que la asociación de GoMining era solo Babylon añadiendo otro logotipo a una página de asociaciones, hasta que vi qué es realmente necesario que sea cierto para que esa integración funcione.
las recompensas de minería normalmente provienen de ejecutar hardware o de pagar a alguien que lo haga. GoMining permite que los titulares de BTC ganen una parte de las recompensas de minería sin tener que poseer ni operar nada. La parte fácil de pasar por alto es qué respalda ese flujo de recompensas: tiene que estar ligado a un hashrate real y verificable; si no, la “recompensa” es solo un número inventado por alguien.
ahí es donde TBV hace el trabajo. el BTC se mantiene bloqueado en una bóveda con custodia propia en bitcoin durante todo el proceso. no hay nada envuelto, nada pasa a la custodia de GoMining y nada se puentea a otra cadena para que la integración sea posible. la bóveda solo permite que ese BTC bloqueado se comprometa con los productos de minería de GoMining, mientras que la propiedad nunca sale de las manos del titular.
hasta 1,000 BTC es el objetivo inicial para esto, alrededor de $82 millones a los precios actuales. es una cifra real comprometida mediante mecánicas reales de la bóveda, no un valor proyectado que aparece en una diapositiva de una hoja de ruta.
lo que todavía no sé es cómo se sostiene esto cuando empiecen a fluir las recompensas de vuelta. que la custodia no se mueva es un problema resuelto. verificar que las recompensas de minería que se distribuyen realmente coincidan con la salida de hashrate real, de forma continua, sin que nadie tenga que confiar en el propio reporte de GoMining, parece un problema separado que TBV por sí solo no responde.
Asumí que el endeudamiento a tipo fijo era solo un término de marketing para “elegimos un número y lo bloqueamos”, hasta que miré por qué eso en realidad es difícil de hacer con bitcoin como garantía.
el préstamo a tipo variable funciona porque el protocolo puede ajustar el tipo en tiempo real a medida que cambia la utilización. eso es fácil cuando la garantía y la curva de tipos viven en el mismo sistema. TBV cambia ese planteamiento. el BTC queda bloqueado en el propio bitcoin, no en la cadena donde se ejecuta la lógica del préstamo, así que el tipo no puede reaccionar simplemente a las condiciones on-chain como normalmente lo haría.
ese es el problema real que Aegis está resolviendo al construir el endeudamiento a tipo fijo sobre TBV. el tipo debe acordarse y fijarse con un precio correcto antes de que se abra la posición, ya que no hay un bucle de retroalimentación en vivo entre la cadena de bitcoin y la cadena de préstamos una vez que la bóveda queda bloqueada. si se fija mal ese precio, o bien el prestamista asume el riesgo, o bien el prestatario obtiene un tipo que no refleja lo que vale realmente mantener el BTC como garantía.
lo que sigo preguntándome es si el tipo fijo es una solución genuina aquí o solo el punto de partida más seguro mientras el ecosistema averigua cómo valorar correctamente el riesgo de la garantía entre cadenas. el préstamo a tipo variable contra BTC nativo parece el problema más difícil y más interesante que aún no se ha resuelto.
Antes pensaba que el soporte para carteras de hardware era solo una casilla que los equipos marcaban una vez que un token se volvía lo suficientemente popular. Me retracté después de ver por qué Ledger añadió soporte específicamente para TBV.
una clave de almacenamiento en frío solo es útil si las transacciones que firma son lo bastante simples como para confiar a ciegas. Los dispositivos de Ledger te muestran lo que estás firmando, pero no pueden razonar sobre una lógica de bóveda compleja; solo lo muestran. Eso significa que un proyecto solo se toma en serio por una cartera de hardware cuando sus condiciones de gasto son lo bastante estrechas y previsibles como para que un dispositivo con casi ninguna pantalla y sin computación real pueda representarlas con seguridad.
así que que Ledger añada soporte para TBV no es realmente un anuncio de alianza: es una señal de que las rutas de transacción prefirmadas en una bóveda de Babylon son lo bastante simples a nivel de firma como para colocarse junto a las claves reales de almacenamiento en frío de alguien sin introducir una nueva clase de error.
lo que aún no puedo determinar es si eso se mantiene cierto a medida que se construyan más casos de uso sobre TBV. Una bóveda con cuatro rutas de gasto es una cosa para mostrarla de forma segura. No sé si eso se sostiene cuando empiecen a acumularse en la misma bóveda la lógica de liquidación, múltiples prestamistas o condiciones entre cadenas.
Seguí asumiendo que la bóveda de Babylon era "inteligente" en el sentido en que la gente compara Bitcoin con Ethereum. Pasé tiempo leyendo en serio el diseño de TBV y me di cuenta de que es al revés.
la bóveda no toma decisiones después de que tu BTC queda bloqueado. no puede. antes de que la salida de la bóveda taproot llegue a estar activa, cada ruta de gasto legítima, cada reembolso, liquidación, resolución de un desafío y reembolso está ya construido y prefirmado como un grafo de transacciones. nada se improvisa más tarde. un hashlock controla cuándo se activa la bóveda, y una ruta de recuperación separada con timelock es la salida del depositante si la configuración nunca termina.
eso es lo contrario de lo que hacen los smart contracts. Ethereum evalúa la lógica mientras una transacción se ejecuta. TBV mueve toda esa lógica a la fase de configuración; así, Bitcoin solo tiene que hacer cumplir un conjunto pequeño y fijo de resultados que ya acordó con antelación.
No creo que sea una limitación; creo que podría ser la razón misma por la que esto puede existir en Bitcoin en absoluto sin que Bitcoin tenga que cambiar. donde me quedo atascado es si eso se mantiene a escala. los casos de uso más acotados con resultados limpios y predecibles parecen encajar de forma obvia.
pero, ¿se conserva la misma estructura prefirmada cuando los grafos de transacciones crecen y hay que contemplar de antemano más rutas?
Solía pensar que “trustless” era sobre todo una palabra de marketing que la gente le pegaba a cualquier cosa autocustodiada, hasta que de verdad miré cómo TBV maneja el lado del retiro en lugar del de los depósitos.
bloquear BTC en una bóveda es la parte fácil de explicar; todos lo entienden al instante. el problema más difícil es demostrar que algo ocurrió en otra cadena sin bifurcar bitcoin ni agregar nuevos opcodes. esa es la parte que la mayoría de los proyectos pasa por alto.
TBV verifica la redención mediante una prueba basada en desafíos que el script de bitcoin ya puede comprobar hoy: sin soft fork, sin reglas de consenso nuevas, y sin que nada deba acordarlo primero el bitcoin core.
lo que sigo considerando es que esto solo importa si resiste condiciones reales, no condiciones de testnet. una criptografía ingeniosa en un signet silencioso es una cosa. la misma criptografía con liquidez real, actores adversarios y presión de comisiones peleando por los mismos bloques es una prueba totalmente distinta.
así que la pregunta no es si el diseño es inteligente, lo es claramente. la pregunta es si el sistema “trustless” sobrevive al encontrarse con un entorno en el que alguien realmente tiene dinero en juego para romperlo.
Pasé un tiempo analizando por qué las Bóvedas Bitcoin Trustless de Babylon (TBV) @BabylonLabs_io realmente resuelven un problema en lugar de solo cambiarle la marca.
Bitcoin es el activo más grande en cripto, pero la mayoría de DeFi todavía te obliga a envolverlo o a entregarlo a un puente para poder usarlo en algún lugar. Esa es la parte a la que TBV va directo. El préstamo nativo respaldado por BTC en Aave v4, impulsado por TBV, es la primera configuración que te permite usar bitcoin como garantía sin envolverlo, sin usar puentes y sin confiar en un intermediario.
Cuatro cosas destacaron cuando lo desglosé:
Eficiente en capital — obtienes tasas de préstamo DeFi sin renunciar al activo en sí
Autocustodia — tus claves, tu BTC, todo el tiempo
Útil como garantía — BTC nativo, no un derivado envuelto que vive en alguna otra cadena
Trustless — no hay una parte centralizada entre tú y tus fondos
La testnet pública ya está activa ahora mismo con marcas reales ya integradas. Vale la pena probar el flujo por tu cuenta y dar feedback si te interesa ver cómo se comporta realmente, en lugar de solo leer sobre ello.
TBV todavía está en una etapa temprana. ¿Alguien ya pasó el ciclo de préstamo completo en la testnet? ¿O todos solo están leyendo la documentación hasta ahora?
He estado investigando @BabylonLabs_io Bóvedas de Bitcoin sin confianza (TBV) y la elección de diseño aquí es, en realidad, la parte interesante, no el rendimiento.
la mayoría de los juegos de "BTC en DeFi" fuerzan una operación: envolverlo, hacer un puente o entregar la custodia a otra persona. TBV se salta las tres. tu BTC permanece bloqueado en un script de autocustodia directamente en la cadena de Bitcoin, sin moverse y sin estar representado por un token sintético en otro lugar.
el mecanismo que lo hace posible es BitVM3, una evolución de BitVM que desplaza la computación fuera de la cadena mediante circuitos ofuscados para que las pruebas de fraude sigan siendo ligeras en Bitcoin. los retiros solo se concretan cuando una prueba zk que valida el estado específico de un contrato se verifica en cadena. esa es la parte sin confianza, no el texto promocional.
números prácticos a tener en cuenta: los tiempos de depósito (peg-in) se han reducido a ~3 horas y las comisiones onchain bajan hasta 3x+, lo cual importa mucho si estás pensando en la usabilidad real frente a las cifras de una demo en testnet.
la integración con Aave es donde esto se vuelve real para un titular paquistaní con BTC: invertirlo mediante babylon, pedir prestados stablecoins contra ello y conservar tanto la custodia como el rendimiento de la apuesta. sin un token de BTC envuelto, sin el riesgo de puente apilado encima.
vale la pena preguntarse, eso sí: ¿alguien ya estresó realmente la ruta de prueba de fraude de BitVM3 fuera de condiciones de testnet, o todavía lo estamos aceptando todo con fe?
Protocolo Newton: encontré la comparación con OAuth escondida en los documentos de Newton
Tengo la costumbre de cuando veo terminología técnica que no entiendo del todo — no sigo adelante hasta que encuentro la analogía que hace que encaje. el argot normalmente es solo un concepto familiar con ropa poco familiar zkPermissions apareció en todo lo que leí sobre el Protocolo Newton. circuitos de conocimiento cero, restricciones programables, delegación con alcance. de acuerdo. pero, ¿qué es realmente Fui a buscar la versión en lenguaje claro y la encontré en la propia documentación de Newton. una frase que lo cambió todo
Volví a revisar el informe de transparencia de Newton buscando detalles que todo el mundo pasó por alto
encontré uno que vale la pena señalar
NEWT ahora mismo es un token ERC-20 en Ethereum. eso es lo que estás sosteniendo, lo que se está negociando, lo que se deposita
pero el informe de transparencia dice explícitamente: "el contrato del token puede actualizarse en el futuro para admitir funcionalidades nativas de rollup una vez que el rollup de Keystore esté suficientemente desarrollado"
también esto: "inicialmente, las comisiones de transacción pueden estar subvencionadas por la Fundación mientras la infraestructura de validadores entra en funcionamiento"
así que dos cosas son ciertas al mismo tiempo ahora
el token que estás sosteniendo es una forma temporal: migra a nativo de rollup cuando se lance Keystore. y el modelo de comisiones que impulsa las recompensas de los validadores actualmente está subvencionado por la Fundación, no generado por el protocolo
ninguna de estas dos cosas está oculta. ambas están en el informe de transparencia. pero no he visto a nadie hablando de lo que significa en la práctica un evento de migración de tokens para los titulares cuando el rollup entre en funcionamiento
observando el lanzamiento del rollup de Keystore con más atención que casi cualquier otra cosa en la hoja de ruta de Newton. ahí es cuando el token se convierte en lo que realmente está diseñado para ser
@grvt_io markets GRVT alrededor de una idea: "el 100% del superávit del protocolo vuelve a los titulares" recompras, reinversión, todo el discurso es
que los ingresos hacen que el token valga la pena mantenerlo, no solo comerciarlo
fui y saqué el desglose real de la oferta en lugar de quedarme con el eslogan tal cual. la oferta total está fija en 1B. la comunidad y los participantes del airdrop reciben 28%. los inversores de venta privada reciben 19.9%. el resto queda bajo un calendario de vesting estructurado
así que casi el 20% del token pertenece a personas que entraron antes de que cualquiera de nosotros viera un panel de puntos, presumiblemente con mejores condiciones de entrada, y ese tramo se desbloquea con su propio calendario de vesting, independientemente de cuánto superávit redirijan las recompras
el mecanismo de recompra es real y probablemente sí ayuda al precio con el tiempo. pero "el 100% del superávit va a los titulares" asume en silencio que todos los titulares son iguales, cuando una quinta parte de la oferta pertenece a un grupo con una base de costo y un calendario de desbloqueo totalmente distintos a los granjeros de la temporada 2 que hicieron el volumen real
vale la pena preguntarse si las recompras realmente ayudan a los titulares que de todos modos tienen que desbloquear y vender en la liquidez temprana escasa, o si principalmente amortiguan la salida del tramo privado primero
sigo pensando que el mecanismo es legítimo; solo que no creo que "el valor se acumula a los titulares" y "los inversores privados tienen casi una quinta parte de la oferta" deban ir en la misma frase sin una pregunta de seguimiento
¿alguien comparó las fechas del cliff de vesting de la venta privada con el timeline del TGE todavía?
Protocolo Newton: busqué información sobre ERC-8004 y encontré algo más interesante de lo que esperaba
tengo un hábito que probablemente es molesto para cualquiera que me vea investigando: no me detengo en el anuncio. busco lo que el anuncio realmente significa a nivel técnico y si se sostiene cuando vi que el github de Newton tenía una implementación de referencia para ERC-8004, asumí que esta era la propuesta estándar de Newton. los equipos hacen esto todo el tiempo: presentan un EIP, le llaman infraestructura, construyen la narrativa así que fui y leí la propuesta real. y cambió la forma en que pienso sobre esto 👀 esto es lo primero que vale la pena saber
Revisé los repositorios de GitHub de Newton en lugar de simplemente leer los anuncios
enterrado en ellos: una implementación de referencia para ERC-8004 — "Trustless Agents, a trust layer for the open agent economy" ERC-8004 es una propuesta de estándar de Ethereum que Newton está impulsando activamente.
la idea es que cada agente de IA que opere onchain implemente este estándar — definiendo cómo los agentes declaran sus permisos, cómo se aplican las políticas antes de la ejecución, cómo se verifican las atestaciones
aquí está por qué este detalle específico importa
si ERC-8004 se adopta como estándar de Ethereum, Newton no se convierte solo en una capa de cumplimiento más entre muchas. se convierte en la arquitectura predeterminada en la que se construyen todos los protocolos que crean agentes de IA ese es un resultado muy diferente de "Newton es una herramienta útil para bóvedas"
el planteamiento es: una capa de aplicación de políticas para DeFi. la jugada real podría ser: establecer el estándar de cómo operan todos los agentes onchain y luego ser dueño de la infraestructura sobre la que corre ese estándar
los EIPs se adoptan o no se adoptan. la mayoría no. pero los equipos que entienden este juego proponen el estándar primero y construyen la adopción después
vigilando ERC-8004 con más atención que casi cualquier otra cosa en la hoja de ruta de Newton 👀
Pasé esta mañana revisando las mecánicas de recompensas @grvt_io porque algo del planteamiento de "más volumen = más puntos" no me convencía, y creo que encontré el truco.
La propuesta es simple: el pool semanal de puntos escala con el volumen total de trading por intercambio. Semana con $2B de volumen = 100K puntos compartidos. Semana con $4B de volumen = 125K puntos compartidos. Más actividad, pool más grande, y todos se benefician. Ese es el encuadre de marketing.
pero vuelve a leer la mecánica otra vez. el pool crece con el volumen, sí, pero también crece el número de traders que lo reparten. los traders activos mensuales de GRVT crecieron con fuerza durante la Temporada 2.
así que la pregunta real no es "¿el pool se hizo más grande?", sino "¿el pool creció más rápido que la base de usuarios?" Si el crecimiento de usuarios supera el incremento de ~25% del pool entre los niveles de $2B y $4B, tu parte individual se está reduciendo aunque el titular del número del pool suba.
Luego está la decisión del plan de multiplicador que se monta encima de esto, en vivo ahora mismo hasta el 17 de julio: opta para diferir tu distribución y obtener una parte multiplicada más grande, o toma la asignación estándar en TGE sin nada extra. El tamaño del pool para cualquier camino es fijo. Las elecciones de multiplicador redistribuyen la porción existente, no la hacen crecer.
Así que hay dos mecánicas de dilución separadas corriendo simultáneamente en las dos semanas antes de TGE: una por el crecimiento de nuevos usuarios diluyendo los puntos semanales, y otra por las opt-in de multiplicador reponderando el reparto final. La mayoría de la gente solo está prestando atención a una de ellas.
en serio no sé si esto hace que la decisión del multiplicador sea mejor o peor para los titulares más pequeños; podría depender totalmente de cuánta gente haga opt-in.
¿Alguien aquí realmente hizo las cuentas de su tendencia de parte semanal antes de decidir el plan de multiplicador, o entró guiándose por sensaciones como casi hice yo?
Protocolo Newton: la elección criptográfica enterrada en los documentos de la que nadie está hablando
tengo la costumbre, cuando investigo protocolos de infraestructura, de no quedarme en lo que dicen que hacen. intento encontrar una decisión criptográfica o arquitectónica concreta que me diga si las personas que lo están construyendo realmente saben lo que hacen a un nivel profundo no la lista de socios. no la hoja de ruta. la elección técnica específica que separa a los equipos que entienden el problema de los equipos que solo lo leen con Newton lo encontré enterrado en la documentación de la arquitectura de privacidad Newton utiliza firmas BLS en la curva BN254 para las atestaciones de los operadores
la mayoría de las dex más perseguidas están corriendo para añadir más mercados y apalancamiento. @grvt_io tomó una ruta más lenta y extraña: conseguir una licencia
de vuelta en diciembre de 2024, obtuvieron una Licencia de Negocio de Activos Digitales Clase M de la Autoridad Monetaria de Bermudas, convirtiéndose en la primera dex regulada del mundo. eso no es una etiqueta de marketing: es una licencia real de un regulador real, asentada sobre un intercambio de autocustodia
la parte de la que no se habla lo suficiente: cuando lanzaron, tenían KYC obligatorio, y luego lo eliminaron en agosto de 2025 una vez que la base regulatoria ya estaba en su lugar. así que ahora puedes comerciar con autocustodia usando solo un correo electrónico, pero el motor de cumplimiento sigue ahí debajo si lo necesitas (se requiere si más adelante vas a reclamar el token)
es una secuencia extraña frente a la mayoría de defi, que construye primero y luego se las arregla con la regulación, ya sea al final o nunca. grvt construyó la capa regulatoria antes de aflojar el kyc, no después
plantea la pregunta de si "dex regulada" termina siendo un nicho solo para instituciones, o si en realidad se convierte en lo que hace que más usuarios minoristas se sientan cómodos al salir de los intercambios centralizados
¿una licencia + autocustodia realmente te generan más confianza, o da igual de cualquier manera
Newton Protocol: i verifiqué con hechos su afirmación institucional más específica
hay una frase en el anuncio de Newton's VaultKit que me hizo detenerme a la mitad de la lectura no es el tema tecnológico. no la lista de socios. una sola frase sobre lo que las instituciones realmente necesitan "los mayores gestores de activos que exploran la tokenización no tienen un problema de discreción. tienen un problema de control demostrable. ya pueden redactar la política. lo que les ha faltado es una forma de hacerla cumplir en la cadena de bloques, de manera verificable, sin entregar su lógica de cumplimiento al público" esa es una afirmación inusualmente precisa. la mayoría de los proyectos dicen "estamos construyendo para instituciones". Newton dijo algo más específico: las instituciones ya saben cómo redactar reglas de cumplimiento. la pieza que falta no es la política, sino la capa de ejecución que puede demostrar que la política se aplicó sin revelar qué contiene la política
En vez de solo leer el pitch deck, fui a revisar los productos reales en vivo de Newton
Newton se presenta como una infraestructura de cumplimiento de nivel institucional para bóvedas DeFi, RWAs, stablecoins
¿y el primer agente que de verdad se construyó y está funcionando en vivo en el protocolo?
un agente de compra recurrente. DCA automatizado. compras de cripto programadas
eso no es una crítica: hay que empezar por algún lado y el DCA realmente es útil. pero hay una brecha interesante entre "capa de autorización para finanzas onchain institucionales" y "configura tu compra semanal de bitcoin
también encontré esto: según el fundador de Kaito, las referencias del ecosistema provenientes de una campaña de marketing representan 1/3 de todos los agentes verificados de Newton
así que el primer agente en vivo es una herramienta de DCA y un tercio de toda la actividad de agentes provino de una campaña de marketing, no de un uso orgánico
la historia de cumplimiento institucional es real y la arquitectura la respalda. pero ahora, el uso real cuenta otra historia
observa cuándo salga en vivo la primera bóveda real o la primera institución usando Newton. ese es el momento en que el relato y la realidad onchain empiezan a alinearse 👀