DOCTOR TRAP

Para ser honesto, seguí pensando en las actualizaciones de un panel de reserva de stablecoins: nadie toca la pantalla y el sistema sigue adelante.
Al principio, eso me pareció tranquilizador.
Los correos electrónicos, las firmas y los informes retrasados son herramientas deficientes para sistemas financieros que funcionan las 24 horas.
Sin embargo, la imagen me molestó.
El retraso había desaparecido, pero también había desaparecido el breve momento en el que alguien podría detenerse y preguntar si la actualización tenía sentido.
Fricción.
A menudo tratamos la fricción como un desperdicio. Gran parte lo es.
Las revisiones manuales pueden ser lentas, costosas e inconsistentes. El 15 de julio de 2026, DefiLlama mostró alrededor de 312,3 mil millones de dólares en valor de mercado de stablecoins. RWA.xyz estaba siguiendo decenas de miles de millones de dólares en activos tokenizados distribuidos. El sitio web de Newton también citó más de 4 billones de dólares en volumen mensual de transferencias de stablecoins.

No dejaba de volver a un detalle incómodo sobre la automatización. A menudo damos a un sistema control antes de saber si cada acción merece ese control.
El modelo habitual parece simple. Concede a un agente acceso, define la tarea y revisa su actividad más tarde. Si algo sale mal, inspeccionamos los registros, revocamos el acceso o intentamos recuperar los fondos.
Para entonces, la acción ya ha ocurrido.
Eso me molestó porque la verificación después de la ejecución es útil, pero sigue siendo tarde. Una pista de auditoría puede explicar un error. No siempre puede evitar uno.

@NewtonProtocol $NEWT #Newt
No quiero que cada herramienta de riesgo sea un espejo retrovisor. Honestamente, esa idea se me quedó mientras leía sobre la nueva mainnet beta de Newton. Muchas herramientas de monitoreo son útiles, pero sus advertencias pueden llegar después de la liquidación. Muestran qué cambió o explican por qué una acción fue riesgosa. El informe puede ser preciso. La pérdida aún puede ser real. En DeFi, el timing importa porque las transacciones no esperan a que alguien termine de revisar un panel. El valor puede moverse en segundos. Un gestor de bóveda puede recibir una alerta, pero no puede revertir una asignación completada. Esta es la principal diferencia que veo en el protocolo Newton. Newton está diseñado para verificar una acción antes de la liquidación. En lugar de solo registrar el riesgo después de que el dinero se mueve, evalúa si una transacción propuesta sigue una política aprobada. La acción pasa o falla. Si pasa, la transacción puede continuar. Si falla, el contrato de destino bloquea la liquidación. Los datos de riesgo ya no se limitan a reportes y paneles. Se convierten en parte del proceso de aprobación de la transacción. El anuncio oficial de Newton sobre la mainnet beta, publicado por la magic newton foundation el 23 de junio de 2026, dice que Newton está en vivo en Base y Ethereum. Describe el protocolo como una capa de autorización que verifica las transacciones contra políticas antes de que el valor se mueva, y luego crea un registro onchain firmado y con marca de tiempo. El anuncio establece la contraposición de forma directa: otras herramientas informan lo que ocurrió, mientras que Newton hace cumplir lo que se permite antes de que ocurra. Newton también afirma que esto se puede hacer sin revelar los datos subyacentes. Mira, esa parte me llamó la atención. Una política de transacción puede depender de información que no debería ser pública. Podría usar el estado de identidad, el filtrado de sanciones, un modelo de riesgo privado u otra entrada sensible. Publicar todos los detalles onchain crea otro riesgo. La documentación de Newton dice que el sistema usa computación preservadora de la privacidad y pruebas criptográficas para que el resultado pueda verificarse mientras las entradas sensibles permanecen ocultas. En la práctica, las políticas se pueden escribir en Rego. Newton está diseñado alrededor de operadores que evalúan una transacción propuesta contra la política y los datos relevantes. Cuando una acción se aprueba, el sistema produce una atestación. El contrato de destino comprueba esa prueba antes de permitir la liquidación. Me gusta este modelo porque la aprobación está vinculada a una acción específica. No es una promesa amplia de que una billetera, un gestor o una bóveda, en general, sea segura. La regla tiene que coincidir con la transacción que se propone. Considera una bóveda DeFi con un límite de concentración. La política dice que ningún mercado individual puede tener más del 40% de los activos de la bóveda. Un curador intenta hacer una asignación que empuje a un mercado a 52%. Una herramienta de monitoreo puede detectar la infracción después de la ejecución. Newton puede comprobar el límite primero. Bloqueado. La misma lógica se puede aplicar a requisitos de liquidez. Una política de bóveda puede exigir que un mercado mantenga un nivel mínimo de liquidez antes de recibir una nueva asignación. Si los datos aprobados muestran liquidez por debajo de ese umbral, la acción no debería pasar. El gestor recibe una autorización fallida antes de que los fondos se muevan. Vaultkit, el SDK de bóvedas de Newton, aplica comprobaciones de política a acciones del curador como reasignaciones, cambios de tope (cap), habilitar mercados y cambios de comisiones. El post oficial de VaultKit de Newton dice que una acción aprobada se ejecuta, mientras que una acción denegada no. Si no se puede completar la evaluación, Vaultkit falla cerrado y no reenvía la transacción. Esto no elimina el juicio humano. Las personas siguen eligiendo las reglas, las fuentes de datos y los límites. Newton hace que esas reglas acordadas sean exigibles cuando una transacción intenta liquidarse. Eso cambió la forma en que miré las herramientas de riesgo. Antes me enfocaba principalmente en la calidad de un panel. Ahora pienso que los lectores deberían hacer una pregunta más práctica: ¿puede la herramienta detener la acción, o solo puede explicar lo que pasó después? También deberían preguntar dónde ocurre la verificación, qué datos la respaldan y si el fallo realmente bloquea la ejecución. Un producto puede proporcionar información de riesgo detallada y aun así no tener control sobre la liquidación. La aplicación previa a la transacción trae sus propios riesgos. Al menos, eso creo... Una política mal escrita puede rechazar una transacción válida. Datos incorrectos o desactualizados pueden producir el resultado equivocado. Una regla de concentración que funciona en condiciones normales puede bloquear un rebalance urgente durante el estrés del mercado. La mainnet beta de Newton también advierte que una política es tan fuerte como los datos que la respaldan. Fallar cerrado puede proteger fondos de acciones no verificadas, pero puede retrasar algo urgente. Los equipos necesitan reglas probadas, datos confiables y planes de recuperación claros. Deberían simular casos límite y revisar los falsos rechazos. Desde mi punto de vista, informar sigue importando. ¿Verdad? Las alertas, los registros, los paneles y las investigaciones ayudan a los equipos a entender fallas y mejorar los controles futuros. No trataría la aplicación (enforcement) como un reemplazo de todas ellas. Pero el timing es diferente. La mainnet beta de Newton se centra en el punto antes de la liquidación, cuando una señal de riesgo todavía puede cambiar el resultado. Para mí, esa es la razón más práctica para prestar atención a NewtonProtocol. La prueba real es si una regla acordada puede detener una acción riesgosa antes de que el valor se mueva. En DeFi, ¿es suficiente con saber lo que pasó, o necesitamos sistemas que detengan primero las malas acciones?

Hoy me topé con la historia de Aave Arc y Fireblocks, y me hizo que el problema institucional de DeFi se sintiera mucho más práctico. En enero de 2022, Aave Arc se puso en marcha como una versión con permisos del software subyacente de Aave V2. Fireblocks actuó como su socio inicial de listas blancas. Las instituciones tenían que completar los procesos de KYC/KYB y las comprobaciones de identificación de clientes antes de que las direcciones de billetera aprobadas pudieran suministrar, pedir prestado o actuar como liquidadores. Fireblocks dijo que, al lanzamiento, había aprobado 30 instituciones financieras con licencia. El número era interesante, pero eso no fue lo que se me quedó. Lo que importaba era el motivo por el cual Aave Arc necesitaba esta estructura en primer lugar. Estas instituciones estaban interesadas en DeFi, pero no podían entrar de la misma manera que un usuario minorista ordinario. Necesitaban un entorno controlado. También necesitaban la confianza de que los otros participantes habían superado las comprobaciones requeridas. No veo Aave Arc como una prueba de que el DeFi institucional ya haya logrado una adopción amplia. Lo veo como un intento temprano de resolver un problema real de acceso. Ahí fue donde empecé a pensar en Newton Protocol. Para que quede claro: Newton no estuvo involucrado con Aave Arc. No estoy sugiriendo una asociación ni una conexión técnica entre ellos. La conexión está en el propio problema. Aave Arc se centró en decidir qué instituciones y direcciones de billetera podían entrar en un mercado con permisos. Newton observa qué ocurre después de conceder el acceso. Una billetera aprobada no hace automáticamente que todas las transacciones sean conformes. Esa diferencia es importante. Un fondo puede permitir actividad en DeFi, pero limitar cuánto capital puede exponerse a un solo protocolo. Un custodio puede permitir la interacción solo con contratos inteligentes aprobados. Una entidad regulada puede necesitar controles de sanciones, supervisión de transacciones, informes o varias aprobaciones antes de que una gran transferencia pueda avanzar. Los gestores de fondos también pueden necesitar demostrar que cada operación siguió el mandato de inversión. La documentación de DeFi institucional de Newton sitúa estas preocupaciones bajo requisitos regulatorios, controles de riesgo, requisitos de auditoría, seguridad operativa y deber fiduciario. Esto cambió la forma en que pienso la conformidad. Antes veía la pregunta principal como: «¿Está permitida esta institución para participar?». Ahora creo que la pregunta más útil es: "¿Se permite esta transacción específica bajo las reglas actuales de la institución?" Según la documentación de Newton, el protocolo está diseñado para añadir un paso de evaluación de políticas antes de que una transacción se ejecute. Las instituciones pueden definir políticas en Rego. Esas políticas pueden abarcar límites de exposición, listas de protocolos aprobados, comprobaciones de sanciones, reglas de jurisdicción, topes de transacción, autorización multipartita y time locks. La documentación también indica que las políticas se evalúan por una red descentralizada de operadores de EigenLayer. Una atestación BLS registra que la transacción se revisó y se aprobó. Newton además describe atestaciones onchain y políticas direccionadas por contenido (content-addressed) almacenadas en IPFS, lo que puede hacer que la decisión de autorización sea verificable de manera independiente. Para mí, esa es la parte más útil del diseño. Una regla de cumplimiento tiene un valor limitado cuando solo existe en un documento o aparece dentro de un panel privado. Se vuelve mucho más significativa cuando puede influir en si la transacción realmente avanza. El middleware centralizado de cumplimiento aún puede ser práctico. Algunas instituciones pueden preferirlo porque el modelo les resulta familiar. Pero, dependiendo de cómo se construya, la institución puede necesitar apoyarse fuertemente en la disponibilidad, las decisiones y los registros internos de un único proveedor. Newton presenta un modelo de confianza diferente. En lugar de depender solo de la aprobación de un proveedor, utiliza políticas Rego definidas por la institución, operadores distribuidos, atestaciones onchain y pruebas BLS que otras partes pueden verificar. Eso no elimina todo riesgo. La prueba criptográfica no puede convertir una política mal escrita en una buena. Las instituciones siguen necesitando datos fiables, reglas sensatas y control claro sobre quién puede actualizar esas reglas. Aun así, la historia de Aave Arc me ayudó a ver con más claridad la siguiente etapa del DeFi institucional. El acceso controlado fue un paso. La parte más difícil es asegurarse de que cada transacción siga las reglas que se supone que la gobiernan. Ahí es donde Newton Protocol se vuelve relevante para mí: no como un reemplazo de la responsabilidad institucional, sino como infraestructura que podría hacer esa responsabilidad más exigible y transparente. ¿Crees que las billeteras aprobadas son suficientes para el DeFi institucional, o cada transacción también debería pasar comprobaciones verificables de políticas antes de avanzar?

Hoy estaba navegando y pensando en lo útil que sería si un agente de IA pudiera comparar productos, elegir la mejor oferta y completar el pago por mí.
Al principio, sonaba conveniente.
Pero en el momento en que me di cuenta de que darle acceso a la cartera a ese agente, me sentí incómodo.
La conveniencia es buena, pero ¿y si el agente gasta más de lo que yo tenía previsto?
¿Y si compra en el lugar equivocado?
¿Qué pasa si aprueba una transacción que yo nunca aprobaría?
Y sinceramente, es aquí donde la seguridad de los agentes de IA se volvió práctica para mí....

Para ser honesto, creo que un solo servidor no debería decidirlo todo en las finanzas onchain.
Hoy, estuve mirando la diferencia entre un registro de un servidor privado y un resultado firmado en la cadena (onchain).
Al principio, me pareció un pequeño detalle técnico. Luego me di cuenta de que en realidad se trata de confianza.
Ese es el verdadero problema 🙇 para mí......
En muchos sistemas, el cumplimiento se gestiona mediante un solo servidor privado. Un monedero (wallet), una bóveda (vault) o una aplicación envía una solicitud a ese servidor. El servidor verifica la dirección, el estado del usuario, la regla de riesgo o el límite de la transacción. luego devuelve una respuesta simple. : aprobado o rechazado.