Kim Jon sun

Estaba profundamente metido en la integración de Chainlink CCIP en Dusk Network $DUSK cuando un detalle técnico me dejó en seco. No la parte del puente: cada proyecto de RWA ya tiene una narrativa de puente. Algo más silencioso. #dusk @Dusk
La testnet de DuskEVM salió en vivo el 10 de agosto. Ese es el entorno donde las securities emitidas por NPEX realmente se desplegarán. Y bajo la integración de CCIP, cuando esos activos se mueven entre cadenas, Dusk y NPEX conservan la propiedad total de los contratos de tokens: límites programáticos de velocidad, rutas de actualización, todo. El modelo de quema/acuñación de CCT elimina por completo las pools de liquidez de terceros. Sin dependencia de slippage. Sin un custodio externo que mantenga el activo subyacente en un puente.
Esa es la parte que la mayor parte de la cobertura pasa por alto. Aquí CCIP no es solo infraestructura de interoperabilidad. Es lo que permite a un emisor regulado mantener los controles de cumplimiento intactos incluso después de que un activo sale de Dusk y aterriza en Ethereum o Solana. Normalmente, el movimiento entre cadenas es donde los marcos de cumplimiento se rompen: el activo llega a un puente, se envuelve y pierde el contexto. Aquí, los controles viajan con él.
Chainlink DataLink también se convierte en el oráculo on-chain exclusivo para los datos de intercambio de NPEX. Así, se publican en cadena datos de mercado de calidad regulatoria, no solo el activo en sí. Me quedé un tiempo sentado con esa combinación: movimiento de activos con cumplimiento más fuentes de datos institucionales verificadas. Es mucha infraestructura apuntando al mismo vacío.
Aun así… CCIP procesó $18B+ en volumen en el Q1 2026, en su mayoría DeFi. La porción de securities reguladas de eso es presumiblemente diminuta. Si esta arquitectura se prueba con volumen institucional real antes del próximo ciclo, la verdad no lo sé

Pasé un tiempo esta semana rastreando las interacciones del contrato de la red de pruebas DuskEVM — la actividad del explorador de alrededor del 10–13 de agosto muestra que se estaba probando una lógica de liquidación temprana; la finalización de las transferencias se ejecuta sin ventanas de retroceso. Cosas pequeñas. Pero me señaló algo en lo que no había pensado con claridad antes.
La liquidación determinista no es solo una mejora de velocidad. Es una restricción arquitectónica que cambia lo que puedes construir encima. En los mercados de capitales tradicionales, la incertidumbre en la liquidación — la brecha entre la ejecución de la operación y la finalización — es estructural. Los sistemas de márgenes, los mecanismos de compensación, los colchones de riesgo de contraparte, recortes de colateral — gran parte de esa infraestructura existe precisamente porque no puedes estar seguro de que la operación realmente se cerró hasta T+2. O más tarde.
Dusk, $DUSK , #dusk @Dusk está avanzando hacia una liquidación que es definitiva en el momento de la ejecución. Sin ventana de ambigüedad. Y si eso se cumple en la práctica — no solo en condiciones de red de pruebas, sino bajo cargas reales de activos — no solo haría que carriles existentes de los mercados de capitales funcionen más rápido. Potencialmente, haría innecesarios varios de ellos. La infraestructura construida para gestionar la incertidumbre en la liquidación empieza a parecer un sobrecargo.
Me encontré deteniéndome en eso más tiempo del esperado. Porque eliminar el sobrecargo suena limpio en teoría, pero las entidades que operan ese sobrecargo no desaparecen. Se adaptan, o empujan hacia atrás.
Lo que todavía no tengo claro es si Dusk ha considerado la fricción institucional que realmente crea la finalización determinista — no la parte técnica, la parte política.

Algo me detuvo a mitad de la tarea en Dusk Network. La documentación de Dusk Trade lo describe como una capa de producto que convierte "primitivas de infraestructura en flujos de trabajo orientados al usuario". Onboarding de inversores. Enlace de billeteras. Coordinación de pagos. Transferencias controladas. $DUSK , #dusk , @Dusk . El lenguaje es deliberado — y también lo es lo que no dice.
Dusk Trade funciona sobre DuskEVM, que recibió su testnet hace cuatro días — 10 de agosto. Esa es la capa que está debajo del producto orientado al usuario. Lo que significa que la plataforma de trading que se presenta como la interfaz entre la infraestructura de blockchain y los mercados bursátiles reales regulados se apoya en infraestructura que entró en testnet hace menos de una semana. No es necesariamente una crítica. Solo una secuencia que vale la pena señalar.
Esto es lo que realmente me llamó la atención. "Orientado al usuario" en el contexto de Dusk Trade significa algo distinto a lo que se entiende en DeFi. La elegibilidad del inversor, KYC, transferencias controladas, asociación de la billetera a identidades verificadas — estos no son flujos opcionales. Son la puerta de entrada. Las licencias de broker y MTF de NPEX ponen el portón. Así, lo que parece un producto accesible para consumidores está más cerca de una interfaz de bróker con licencia y UX simplificada. El enfoque de acceso para "pequeños inversores" del pitch original de STOX es real, pero solo después de superar un embudo de cumplimiento que la mayoría de participantes minoristas no encontrará trivial.
La lista de espera se abrió en enero de 2026. DuskEVM testnet el 10 de agosto. Me pregunto cómo se ve realmente el onboarding cuando se ponga en marcha — y quién logra pasar primero.

Mientras realizaba la tarea, estuve leyendo el protocolo Citadel de Dusk Network. El repositorio de Citadel en GitHub recogió commits el 8 de agosto — trabajo activo, no una especificación estática — y acabé atascado en el modelo de tres partes durante más tiempo del previsto.
La frase "divulgación selectiva" se usa mucho en los materiales $DUSK @Dusk #dusk . Es precisa. Pero hay un detalle estructural que la arquitectura revela y que el discurso no destaca.
Citadel tiene tres partes: Usuario, Proveedor de Licencia (LP) y Proveedor de Servicio (SP). Las pruebas ZK te protegen del SP: verifican que cumples un umbral de cumplimiento sin ver tus datos reales. Esa parte funciona como se describe. Pero el LP realiza el KYC completo. Ellos tienen tus datos. Emiten la licencia en la cadena. Cada proveedor de servicios posterior solo obtiene una prueba, lo cual es elegante. La fricción está antes, en el proceso de incorporación, no en cada puerta.
Así que el modelo de privacidad de Dusk no es "oculto ante la autoridad". Es "oculto frente a los contrapartes, visible para la autoridad que eliges". El LP lo sabe todo. Los SP no saben nada. Para las finanzas reguladas, probablemente sea el diseño correcto — alguien tiene que ser el custodio responsable de los datos ante los reguladores. Pero se lee distinto de la forma en que la mayoría interpreta la "privacidad en blockchain", que tiende a significar oculto para todos por defecto.
Hmm… la pregunta abierta y fascinante es quién desempeña realmente el papel de LP en la práctica. Si es un custodio regulado o un proveedor de KYC con licencia, eso es infraestructura de identidad subcontratada con mejor experiencia de usuario, no identidad descentralizada. No estoy seguro de que esas dos formas de encuadrarlo alguna vez se resuelvan del todo entre sí.

Pasé un tiempo esta semana recorriendo los documentos de la testnet de Babylon: el flujo de Trustless Bitcoin Vault con Aave v4. Lock signet BTC en Bitcoin, el vault se activa y vaultBTC aparece automáticamente como colateral en Ethereum. Intenté seguir el proceso peg-in de principio a fin. Me detuve un momento con la sensación de estar un poco inquieto/a.
No porque esté roto. Porque la arquitectura está casi al revés de lo que normalmente implica "Bitcoin-centric Web3". Babylon $BABY @BabylonLabs_io no está llevando Bitcoin a Web3. Está reestructurando cómo opera el DeFi del lado de Ethereum teniendo en cuenta las limitaciones nativas de Bitcoin. El BTC nunca cruza. Los retiros solo se desbloquean cuando se verifica de vuelta en la cadena de Bitcoin una prueba de conocimiento cero del estado del contrato inteligente. Ethereum acepta las condiciones de Bitcoin. Ese es el diseño real. #baby
La llamada de fundadores del 30 de julio confirmó que el préstamo nativo respaldado por BTC ya está activo en la testnet pública con Aave v4; los tiempos de peg-in ahora se redujeron a aproximadamente tres horas. Esa reducción importa: es la diferencia entre un protocolo que es arquitectónicamente interesante y uno que la gente quizá realmente usaría. Tres horas sigue siendo tres horas para una interacción de DeFi, pero es un número muy distinto al de una cola de confirmación de un puente.
Esto es lo que me sigue rondando. Menos del 1% de todo el BTC ha tocado alguna vez una plataforma de contratos inteligentes. El modelo de vault elimina el riesgo del puente que mantuvo fuera la mayor parte de ese BTC. Pero, ¿elimina también la fricción? Flujos de peg-in, verificadores ZK, direcciones de recompensas separadas: el modelo de confianza es más limpio, pero el camino de la UX no.
¿Qué importa más para la adopción real?

Algo solo hizo clic después de abrir la Propuesta #13 en babylon.explorers.guru: la votación de deflación del BSN, que actualmente está en curso con una ventana de 3 días y se requiere una supermayoría de 2/3 para aprobarse.
Lo que me detuvo: la gobernanza en Babylon Protocol es deliberadamente lenta. Se requiere un depósito de 50,000 $BABY para presentar. Votación ponderada por el peso de los validadores. Un umbral de supermayoría alto. @BabylonLabs_io incorporó esa fricción por diseño. Y contrasta con fuerza con la forma en que realmente funciona el slashing en el otro lado del mismo protocolo.
El slashing no toca la gobernanza en absoluto. Si un Proveedor de Finalidad (Finality Provider) firma doble: reutiliza la misma aleatoriedad EOTS en la misma altura de bloque dos veces; entonces, ambas firmas juntas revelan su clave privada. Matemáticamente. Cualquiera que tenga esa prueba puede transmitir la transacción de slashing pre-firmada directamente a Bitcoin. Sin voto de comité. Sin propuesta. Sin periodo de espera. La penalización es criptográfica, no social.
Esa es la verdadera brecha arquitectónica entre esto y el staking convencional. En la mayoría de los sistemas PoS, el slashing vive dentro de la misma capa que también puede bifurcarse, ser negociada (lobbied) o retrasada por el mismo aparato de gobernanza. En #baby , la mala conducta se prueba por sí misma y el castigo se puede ejecutar de forma permisional por quien lo detecte primero.
hmm… aunque hay un matiz que sigue rondándome: el comité del covenant co-firma las transacciones de slashing en el momento de creación del stake. Si ese comité queda comprometido en ese momento específico, la ejecución permisional se deshace. Esa dependencia de confianza aparece antes en el flujo de lo que la mayoría de análisis casuales reconoce.
Así que el diseño es genuinamente más limpio que el staking convencional, pero hay una única suposición silenciosa y determinante sobre la que aún se apoya la arquitectura…

Todo el mundo está enfocado en el número de $5.6B TVL. Así que empecé a revisar qué es exactamente lo que esos 56,853 BTC están asegurando ahora mismo — y Babylon Protocol @BabylonLabs_io tiene la capa de proveedor de finalidades totalmente construida: más de 250 operadores activos, la Propuesta #13 en babylon.explorers.guru fue aprobada en agosto de 2025, con codificación fija de un bucle de quema donde las recompensas de BSN se subastan para $BABY destrucción. Eso debería significar que la máquina de seguridad compartida está funcionando. Pero cuando rastreé los flujos, casi todo apunta a Génesis en sí — la propia cadena de Babylon — y no hacia afuera, a una distribución de BSNs de consumidores que estén extrayendo simultáneamente seguridad BTC desde el pool. El multi-staking, el mecanismo real donde una sola apuesta de BTC asegura múltiples redes a la vez, todavía está en un despliegue inicial. Así que lo que tienes es una oferta abrumadora: 56,853 BTC en cola, 250 proveedores de finalidades listos. La demanda — BSNs externos en vivo que enrut as sus requisitos de seguridad a través de #baby — todavía está débil. Pensé que el mecanismo de quema de la Propuesta #13 era la señal de que el volante ya estaba en movimiento. En realidad, es más bien una prueba de que la ignición está conectada correctamente. La arquitectura es real. Lo que aún no puedo determinar es cuántas redes realmente lo necesitan, o qué tan rápido se están encendiendo las señales del lado de la demanda.

Pasé por el flujo TBV en la testnet de Aave V4 — en vivo desde el 2 de junio de 2026 vía babylon.explorers.guru y confirmado ese mismo día por Bitget News — porque @BabylonLabs_io lo llama "BTC colateral sin renunciar a la custodia" y quería ver qué significa eso en la práctica.

La secuencia en la interfaz son cuatro pasos: bloquear BTC en la bóveda, el estado de colateral se vuelve verificable en Ethereum, pedir stablecoins a través de Aave y desbloquear BTC después del repago. Esa última línea es de la que nadie habla. "Desbloquear BTC después del repago" significa que el BTC es inaccesible hasta que se complete una transacción de Ethereum. Tú tienes las llaves. No tienes la salida.

Pensé que $BABY y el modelo TBV preservaban todas las propiedades nativas del BTC. Lo que realmente hace es separar la propiedad del acceso: las llaves viven en Bitcoin y la condición de liberación vive en Ethereum. Es un modelo de custodia distinto, no custodia cero. Si Ethereum está congestionado cuando necesitas repagar, o si el parámetro de liquidación de Aave se activa antes de que puedas actuar, tu Bitcoin... espera.

#baby da a los titulares de BTC una utilidad realmente nueva sin envolverlo. Pero ¿sigue siendo el marco correcto decir "tú tienes tu BTC" cuando el mecanismo que te permite acceder a él se ejecuta en una cadena diferente? #baby

Hilo que vi esta mañana: alguien preguntaba por qué cualquier equipo de desarrollo serio integraría Babylon en lugar de… construir su propio conjunto de validadores con el tiempo. Buena pregunta. De hecho, yo pensé lo mismo hace un par de semanas.
Así que empecé a indagar en el lado de desarrollo de $BABY . Y lo que cambió mi forma de pensar fue esto: las cadenas nuevas no tienen un problema de confianza; tienen un problema de tiempo. Construir un conjunto de validadores nativo con una seguridad económica significativa tarda meses, a veces años: necesitas stakers, necesitas valor del token para que el slashing duela, necesitas que todo el mecanismo se ponga en marcha. Babylon, esencialmente, ofrece un atajo. Conectarte con colateral denominado en BTC desde el día uno, saltarte la fase de arranque. Eso no es un discurso técnico: es un discurso de plazos.
Pero aquí está lo que no me termina de encajar. La seguridad prestada y la seguridad construida se sienten idénticas hasta que se ponen a prueba. Si una cadena asegurada por Babylon se enfrenta a un ataque real y la respuesta depende de que los stakers de BTC reaccionen, se coordinen y el slashing funcione limpiamente bajo presión… entonces hay un montón de supuestos apilados. Los desarrolladores que están publicando esto podrían estar optimizando más por credibilidad de lanzamiento que por resiliencia real. Y no siempre son lo mismo.
Para cadenas en etapa temprana con bajo TVL nativo, quizá ese intercambio tenga sentido. Para cualquier cosa que intente mantener un valor serio a largo plazo… no estoy tan seguro.
En fin. Vuelvo a mirar las gráficas. $BABY ha estado en silencio esta semana.

@BabylonLabs_io #baby

Algo llamó mi atención a mitad de la tarea mientras revisaba los documentos de integración. Babylon, $BABY , #baby , @BabylonLabs_io — el discurso del desarrollador está limpio: intégrate como BSN, evita el problema de seguridad del arranque en frío, hereda el peso de Bitcoin desde el primer día. Y estructuralmente, eso es real. Pero los mecanismos detrás son más condicionales de lo que sugiere la frase.
El hecho es que la finalidad respaldada por Bitcoin en un BSN nuevo no ocurre simplemente al implementarlo. Se activa cuando 2/3 de la participación delegada en BTC firma un bloque a través de proveedores de finalidad. Hasta que se alcanza ese umbral —que depende por completo de cuánta BTC se haya delegado a los proveedores de finalidad de ese BSN en particular— la cadena funciona solo con el consenso de CometBFT. Se producen bloques. Las transacciones se confirman. Pero la capa de finalidad anclada a Bitcoin permanece inactiva.
Lo estaba viendo desarrollarse en babylon.explorers.guru esta semana. El propio Babylon Genesis, como el primer BSN, tiene la delegación para alcanzar consistentemente ese quórum. Los checkpoints horarios de Bitcoin están llegando; la salud de la cadena se ve bien. Pero Genesis tiene 56,000+ BTC detrás. Un nuevo BSN de Fase 3 que se integra ahora comienza con todo lo que logren atraer a su propio conjunto de proveedores de finalidad desde cero.
Me verifiqué esto varias veces porque los documentos lo plantean como "heredar la seguridad de Bitcoin". Técnicamente es correcto. Pero está más cerca de "puedes heredarla, una vez que hayas incorporado suficiente delegación de BTC para tus proveedores de finalidad". No es la misma frase.
El problema del arranque en frío para la seguridad no desaparece. Solo se desplazó un nivel hacia abajo. Me pregunto cuántos equipos que están construyendo BSNs ahora han modelado cómo se ve su quórum de finalidad en el lanzamiento.

Han sido unos días raros. El mercado avanza en rango lateral, sin resolverse nada. Al final me puse a leer en lugar de actualizar los gráficos.
Me metieron en algo sobre la filosofía de diseño de Babylon — específicamente el enfoque de “confianza mínima”. Yo siempre lo había entendido como una afirmación de seguridad. Pero si lo pienso más a fondo, creo que en realidad es otra cosa completamente distinta.
No es una característica técnica. Es una capa de compatibilidad entre creencias. Cada producto de rendimiento de Bitcoin le pide a los tenedores que muevan su BTC a algún lado — un puente, un wrapper, un custodio. Cada uno te obliga a admitir en silencio que el Bitcoin puro no es suficiente. Babylon no te pide eso. Tu BTC se queda en Bitcoin. El staking es nativo. Y eso significa que, por primera vez, un maximalista de Bitcoin puede participar en economías multi-cadena sin sentir que ha traicionado una postura que ha mantenido durante años. Eso no es poca cosa. Es una puerta muy específica que se abre para un grupo muy específico de personas.
Pero esto es lo que no termino de decidir: ese grupo también es famoso por resistirse a todo. Aunque la puerta esté abierta, ¿acaso entran? Los que mantienen una postura ideológica han sobrevivido años de propuestas de “rentabilidad sobre tu Bitcoin” y las han ignorado todas. No estoy seguro de que la elegancia técnica cambie esa realidad conductual.
Aun así. Algo en el encuadre se siente diferente esta vez. O quizá simplemente estoy inquieto.
@BabylonLabs_io #baby $BABY

Pasé un par de horas en Babylon Protocol $BABY hoy, rastreando el flujo nativo de staking. @BabylonLabs_io hace que la reclamación de no wrapping sea ruidosa y es técnicamente exacta: 56,853 BTC que están en UTXOs Taproot con timelock en la red principal de Bitcoin, sin puente, sin custodio tocando las monedas. Esa parte se mantuvo bajo escrutinio. #Babylon no está tomando atajos a nivel de protocolo.

Pero luego seguí tirando del hilo. Si tu BTC está bloqueada en un script de desindexación (unbonding) de 301 bloques y no puedes gastarla, intercambiarla o usarla como colateral mientras está staked... ¿qué hace el mercado? La envuelve. Lombard emite LBTC encima de las posiciones de Babylon. Solv hace lo mismo. Lombard controla aproximadamente el 60% del mercado de liquid staking de BTC precisamente porque los UTXOs con timelock de Babylon no tienen liquidez nativa. El protocolo elimina el puente custodial. El ecosistema reconstruye en silencio una versión más suave de eso una capa por encima.

Observé esto mientras miraba cómo caía el volumen $BABY 24h un 35.9% esta semana en CoinGecko; la oferta circulante ahora está en 4B y subiendo. El mercado de tokens se enfría, pero el bloqueo de BTC se mantiene. Una asimetría interesante.

Hmm... entonces la garantía de no wrapping se aplica al contrato de staking. Si se aplica a tu experiencia real como usuario depende por completo de si necesitas que tu capital se mueva. La mayoría de la gente sí.

Aun así, sigo pensando en lo que ese vacío significa para la relación a largo plazo de Babylon con su propio ecosistema LST.
#baby

La tesis de "Bitcoin como capa de seguridad económica" es uno de los argumentos estructurales más interesantes en el cripto de hoy. Pasé tiempo hoy en la arquitectura real de Babylon: documentos, mecánicas del proveedor de finalidad y datos de delegación en vivo. #baby $BABY @BabylonLabs_io .
Esto es lo que me detuvo. Hay 250 proveedores de finalidad registrados en la red de Babylon. Pero solo los 60 principales según la delegación en BTC participan activamente en asegurar la cadena. Los otros 190 están presentes en papel, pero inactivos desde un punto de vista de seguridad real. Así que si un staker de BTC eligiera un proveedor fuera de ese top 60, su Bitcoin estaría técnicamente bloqueado en el protocolo — pero sin contribuir con seguridad activa de PoS en este momento. Espera — esa es una distinción bastante significativa.
Ese vacío se mantiene en silencio bajo el titular. 56,853 BTC, aproximadamente $5.6B en TVL, es la cifra que la mayoría de la gente cita. BABY cotizaba a $0.0125 el 19 de julio, con una capitalización de mercado de alrededor de $50M, bajando 4.2% respecto a la semana anterior. El precio probablemente ya descuenta cierta escepticismo sobre qué tan rápido la expansión de la Fase 3 de BSN — la cobertura real de seguridad multi-cadena más allá del propio Babylon Genesis — se convierte en un efecto de red en vivo.
El mecanismo de slashing vía EOTS se aplica en la capa base de Bitcoin. Sin puente. Esa parte es técnicamente elegante. Pero que Bitcoin se convierta en la capa real de seguridad económica a escala... depende por completo de cuántas BSNs externas terminen activas y de cómo ese conjunto activo de 60 cupos crezca para adaptarse a ellas.

Estaba terminando esta tarea de CreatorPad en Newton Protocol $NEWT #Newt @NewtonProtocol y seguía quedando atrapado en el mismo vacío. El marco de la "futuro financiero nativo de IA" implica una economía en funcionamiento: modelos ganando, creadores cobrando y regalías enrutándose automáticamente. Se lee bien. Luego abrí explorer.newt.foundation/mainnet y simplemente... me quedé viendo lo que realmente hay.
Lo que está en vivo es la capa de cumplimiento. Atestaciones de políticas, pruebas firmadas con TEE, verificaciones de quórum BLS desde el conjunto de operadores de EigenLayer. Todo está fechado, todo es legible. A 10 de julio, el número de titulares rondaba los 13,026. Tranquilo, pero la actividad de atestación es más densa de lo que ese número sugiere.
Espera — la capa financiera que Newton describe requiere que exista primero el Model Registry. Las regalías necesitan algo desde lo que enrutar. La exploración necesita algo para poder mostrar. Ninguno está desplegado todavía. Así que el discurso de "finanzas nativas de IA" está describiendo el resultado de una infraestructura que aún no se ha entregado por completo, no lo que está funcionando hoy.
No creo que sea un problema fatal. La infraestructura suele verse vacía justo antes de que deje de estarlo. Pero 17.84M $NEWT se desbloquea el 24 de julio, y la economía financiera que se comercializa como motor de valor sigue estando en el plan. Esa es la parte en la que sigo quedándome.
¿Quién se beneficia realmente primero cuando esto se abra — los creadores, los editores de modelos o los validadores que ahora mismo ejecutan la atestación?

Algo sobre el marco de la visión a largo plazo siempre me hace querer revisar primero las cifras actuales. Así que lo hice. Abrí el contrato NEWT en Etherscan — 0xd0ec028a — y al 10 de julio a las 14:57 UTC el número de titulares estaba en 13.026 wallets. Eso es todo. Para un protocolo que Newton Protocol, $NEWT , #Newt , @NewtonProtocol está presentando como el núcleo de cumplimiento de políticas para toda la economía AI x Web3.
Hmm. No es exactamente una crítica. Solo una referencia útil.
La visión a largo plazo es real y técnicamente coherente: zkPermissions Keystore Rollup entre cadenas, un Verifiable Automation Marketplace, un Model Registry, gobernanza DAO eventualmente. La idea de que $NEWT becomes la tarifa de gas que paga cada agente de IA cada vez que supera una comprobación de políticas — a escala, ese es un modelo de demanda interesante. Pasé un rato creyendo de verdad el planteamiento.
Pero la visión solo funciona si Newton se vuelve infraestructura invisible. Algo que nadie mira porque simplemente está corriendo en segundo plano de cada interacción con cada bóveda, cada transacción de cada agente, cada comprobación de cumplimiento entre cadenas. Y... 13.026 titulares no están apostando a lo invisible. Están mirando un precio y una hoja de ruta.
Son dos apuestas genuinamente distintas, en el mismo token. No sé cuál gana a la larga. Ni siquiera estoy seguro de que el mercado ya haya resuelto eso.

En algún punto a mitad de la tarea, el tema y los documentos reales empezaron a tirar en direcciones diferentes. Newton Protocol, $NEWT , #Newt , @NewtonProtocol se enmarca en rollups seguros que habilitan el escalado de IA — y el rollup de Keystore es real en el sentido de la hoja de ruta — pero abre explorer.newt.foundation/mainnet ahora mismo y lo que realmente estás viendo es infraestructura previa a los rollups. Red de operadores en Ethereum mainnet y Base. Restaking en EigenLayer. Evaluación de políticas basada en TEE por transacción. No hay una capa de rollup dedicada en el estado en vivo.
Lo que significa que la historia de escalabilidad para aplicaciones de IA no es lo que se está entregando hoy. Lo que se entrega es el cumplimiento por transacción mediante consenso de operadores de AVS — algo significativo, pero no lo mismo. Los cambios del rollup alteran la economía: verificación de pruebas amortizada, menor coste por evaluación, y la capacidad de agrupar y liquidar decisiones de políticas a velocidad de rollup en lugar de la finalización de L1. Ese es el desbloqueo para las aplicaciones de IA que funcionan con volumen real. Hasta entonces, los flujos de agentes de alta frecuencia topan con la sobrecarga de L1 en cada paso de autorización.
17.84M NEWT liberados el 24 de julio en todas las categorías de interesados, ~$882K al precio actual. La oferta se mueve. La infraestructura que se supone que debe servir aún está poniéndose al día con su propia hoja de ruta.
Volví y revisé GitHub: el repo newton-contracts, actividad reciente escasa. El trabajo de zkPermissions existe en el litepaper y en los docs con detalle arquitectónico real. Solo que todavía no está en mainnet.
Hmm. El rollup es lo que hace que tenga sentido escalar la IA aquí. Difícil evaluar una tesis de escalabilidad cuando la capa de escalado no es lo que está en vivo…