作者：Zack Pokorny，investigador asistente de Galaxy Digital; fuente：Galaxy Digital; compilación：Shaw Cai Jin de la información dorada

Introducción

Los casos de uso y las capacidades de los agentes de inteligencia artificial (AI Agent) han comenzado a evolucionar gradualmente. Están logrando ejecutar tareas de forma autónoma paso a paso, y el desarrollo relacionado también está avanzando hacia la capacidad de que los agentes mantengan y configuren fondos, descubran estrategias de operaciones y de rendimiento, entre otras funciones. Aunque esta transformación experimental aún se encuentra en una etapa muy temprana, la dirección de su desarrollo ya es completamente distinta a la del pasado: en el pasado, la mayoría de los agentes se usaban principalmente como herramientas sociales y de análisis.

La cadena de bloques ofrece un campo de pruebas natural para esta evolución. La cadena de bloques cuenta con características sin permisos, composabilidad (es decir, el mismo marco de ejecución puede albergar aplicaciones de diversos componentes financieros de base), un ecosistema de aplicaciones de código abierto, datos abiertos y equitativos para todos los participantes, y que todos los activos en la cadena, por defecto, admiten programabilidad.

De aquí surge un problema estructural: si la cadena de bloques es programable y sin permisos, ¿por qué los agentes autónomos aún enfrentarían obstáculos para su funcionamiento? La respuesta no está en si la ejecución es posible, sino en cuáse costo de comprensión semántica y de coordinación de planificación debe asumirse por encima de la capa de ejecución. La cadena de bloques puede asegurar la exactitud de las transiciones de estado, pero normalmente no ofrece capacidades abstractas nativas de protocolo como interpretaciones económicas, identidades estándar o planificación jerárquica de objetivos.

Parte de los obstáculos se origina en las características arquitectónicas de los sistemas sin permisos; otra parte se deriva del estado actual del desarrollo de herramientas, selección de información e infraestructura de mercado. En aplicaciones reales, muchas funciones de capa superior aún dependen de software y flujos de trabajo diseñados con el ser humano como núcleo operativo.

Arquitectura de cadena de bloques y agentes de inteligencia artificial

El núcleo del diseño de la cadena de bloques gira en torno al mecanismo de consenso y la ejecución determinista, no a la interpretación semántica. Lo que ofrece hacia el exterior son componentes de base como ranuras de almacenamiento, registros de eventos y trazas de llamadas, en lugar de objetos económicos estandarizados. Por ello, conceptos abstractos como posiciones mantenidas, rendimientos, coeficientes de salud y profundidad de liquidez normalmente deben reconstruirse fuera de la cadena por indexadores, capas de análisis, interfaces front-end y interfaces de aplicación (APIs), convirtiendo estados exclusivos de cada protocolo en formas más utilizables.

Muchos procesos operativos principales de finanzas descentralizadas, en especial aquellos dirigidos a usuarios comunes y a operaciones basadas en decisiones subjetivas, aún se mantienen con un modo central: el usuario interactúa a través de una interfaz front-end, y la confirmación mediante la firma de cada transacción es el patrón clave. Este modelo centrado en la interfaz de usuario, junto con la popularización de los usuarios comunes, permite la aplicación a escala, incluso si una parte considerable de las actividades en la cadena ya está impulsada por máquinas. La lógica de interacción predominante del usuario común sigue siendo hoy: intención de la operación → interfaz de usuario → iniciar transacción → confirmar completado. Aunque la operación programada sigue rutas distintas, también tiene limitaciones: el desarrollador debe seleccionar en la fase de construcción el contrato y el rango de activos, y luego ejecutar algoritmos basados en ese rango fijo. Ambos modelos no pueden adaptarse a sistemas que, durante la ejecución, necesitan descubrir, evaluar y combinar comportamientos operativos de forma autónoma en función de objetivos dinámicos.

Cuando una infraestructura optimizada específicamente para la verificación de transacciones pasa a ser utilizada por sistemas que también interpretan estados económicos, evalúan crédito y optimizan el comportamiento en torno a objetivos claros, los obstáculos comienzan a hacerse evidentes. Parte de estas diferencias se debe al diseño sin permisos y heterogéneo de la cadena de bloques; otra parte se debe a que las herramientas existentes aún encapsulan los flujos de interacción con la cadena de bloques alrededor de la auditoría manual y el intermediario del front-end.

Flujos operativos de agentes y estrategias algorítmicas tradicionales

Antes de analizar las brechas entre la infraestructura de la cadena de bloques y los sistemas de agentes, es necesario definir un flujo operativo de agente de nivel superior y resaltar las diferencias clave respecto a los sistemas algorítmicos tradicionales en cadena.

Las diferencias entre ambos no radican en el grado de automatización, la complejidad técnica, la configuración paramétrica o incluso la capacidad de adaptación dinámica. Los sistemas algorítmicos tradicionales pueden lograr una alta parametrización: descubren automáticamente nuevos contratos y tokens, asignan fondos entre múltiples tipos de estrategias y reequilibran según el rendimiento. La diferencia fundamental es si el sistema puede manejar escenarios que no fueron previstos en la fase de construcción.

Por complejos que sean, los sistemas algorítmicos tradicionales solo pueden ejecutar una lógica predeterminada en función de patrones previstos durante la fase de desarrollo. Este tipo de sistemas necesita configurar para cada tipo de protocolo analizadores (parsers) de interfaz predeterminados, lógicas de evaluación predeterminadas que transformen el estado del contrato en significados económicos, reglas claras para la verificación de crédito y estándares, y además requiere escribir reglas codificadas de forma rígida para todas las ramas de decisión (sin importar cuán dinámica o flexible sea la lógica del algoritmo en sí). Una vez que aparece una situación que no coincide con el patrón previsto, el sistema o bien salta ese escenario o bien falla directamente. No puede razonar sobre escenarios desconocidos: solo puede verificar si el escenario actual coincide con plantillas conocidas.

Como esta “pato digestivo” de tipo dispositivo mecánico puede imitar un comportamiento convincente, pero cada acción está predefinida. ((Scientific American, enero de 1899)_ )_

Cuando los algoritmos tradicionales escanean un nuevo mercado de préstamos, pueden identificar contratos desplegados que emitan eventos familiares o que coincidan con patrones de fábrica conocidos. Pero si aparece un tipo de componente de préstamos básico nuevo con una interfaz desconocida, el sistema no puede evaluarlo. Es necesario que una persona revise el contrato, entienda su mecanismo de funcionamiento, determine si se incluye en el pool de oportunidades y escriba lógica de integración. Solo después de completar estos pasos, el algoritmo puede interactuar con él. Los seres humanos se encargan de interpretar; los algoritmos, de ejecutar. Y los sistemas de agentes basados en modelos fundamentales rompen esta frontera. Pueden lograrlo mediante capacidad de razonamiento adquirida:

• Interpretar objetivos ambiguos o no especificados con claridad. Instrucciones como “maximizar el rendimiento pero evitar el riesgo excesivo” requieren interpretación: ¿qué nivel se considera riesgo excesivo? ¿Cómo se debe equilibrar el rendimiento y el riesgo? Los algoritmos tradicionales necesitan definir con precisión estas condiciones con antelación, mientras que el modelo fundamental puede interpretar la intención, emitir juicios y optimizar su propia comprensión según la retroalimentación.

• Adaptarse de forma general a nuevas interfaces. Los agentes pueden leer el código de contratos desconocidos, analizar documentación o revisar interfaces binarias de aplicaciones (ABI) que nunca antes han visto, y deducir la función económica de ese sistema. No necesita construir de antemano analizadores para cada tipo de protocolo. Esta capacidad aún no es perfecta: el agente puede cometer errores de juicio, pero puede intentar interactuar con sistemas no previstos durante la fase de desarrollo.

• Razonar sobre confiabilidad y cumplimiento normativo bajo incertidumbre. Cuando las señales de confianza son borrosas o incompletas, el modelo fundamental puede ponderar probabilísticamente sus juicios en lugar de aplicar reglas binarias simples. ¿Ese contrato inteligente es una versión oficial? Con las evidencias existentes, ¿ese token probablemente sea legítimo? Los algoritmos tradicionales solo tienen dos estados: “con reglas” o “sin reglas”. En cambio, los agentes pueden razonar en función de la confianza.

• Interpretar errores y ajustar de forma adaptativa. Cuando aparece una situación inesperada (por ejemplo, una reversión de la transacción, que la salida no coincide con lo esperado, o cambios de estado entre la simulación y la ejecución), el agente puede inferir la causa del problema y decidir cómo responder. En contraste, los algoritmos tradicionales solo ejecutan bloques de código de captura de excepciones y tratan el desvío de manera separada, en vez de interpretar la excepción.

Estas capacidades existen de verdad, pero aún no están perfeccionadas. El modelo fundamental puede alucinar, malinterpretar información y realizar juicios erróneos que aparentan ser confiados. En entornos adversarios que involucran fondos (es decir, el código es controlable o se reciben activos), “intentar interactuar con sistemas no previstos” podría significar una pérdida directa. La tesis central de este artículo no es que los agentes puedan completar de forma confiable estas funciones en la actualidad, sino que pueden intentar de formas que los sistemas tradicionales no pueden, y que la infraestructura futura tiene la esperanza de hacer esas tentativas más seguras y confiables. Tratar a ambos como un espectro continuo en lugar de categorías absolutas facilita la comprensión: algunos sistemas tradicionales ya han incorporado inferencia basada en aprendizaje; algunos agentes también pueden depender de reglas codificadas en el camino crítico. La diferencia entre ambos es direccional, no una oposición binaria. Los sistemas de agentes moverán más trabajo de interpretación, evaluación y adaptación al razonamiento en tiempo de ejecución, en lugar de preverlo en la fase de desarrollo. Esto se conecta estrechamente con el argumento de obstáculos del apartado anterior, porque el agente intenta hacer justamente lo que el algoritmo tradicional evita por completo. Los algoritmos tradicionales evitan el costo de descubrimiento mediante selección manual de un conjunto de contratos en la fase de desarrollo; evitan el costo de la capa de control mediante listas blancas mantenidas por operadores; evitan el costo de datos mediante analizadores preconfigurados para protocolos conocidos; y evitan el costo de ejecución funcionando dentro de rangos de seguridad predefinidos. Cuando el trabajo semántico, de confianza y de la capa de estrategias se hace de manera anticipada por humanos, el algoritmo solo ejecuta dentro de límites trazados. Las versiones tempranas del flujo operativo de agentes on-chain pueden mantener este patrón, pero su lógica central consiste en trasladar el descubrimiento, la confianza y la evaluación de estrategias al razonamiento en tiempo de ejecución, en lugar de predefinirlo en la fase de desarrollo.

Es posible que los agentes intenten descubrir y evaluar oportunidades desconocidas, juzgar la conformidad de los contratos sin reglas rígidas codificadas, interpretar estados heterogéneos sin analizadores preconfigurados y ejecutar estrategias para objetivos que podrían ser ambiguos. Y es precisamente en estos eslabones donde comienzan a manifestarse las brechas de la infraestructura. Los obstáculos no existen porque los agentes estén haciendo lo mismo que los algoritmos pero de forma más difícil; existen porque intentan hacer cosas completamente diferentes: operar dentro de un espacio de acciones abierto y de interpretación dinámica, en lugar de operar en un espacio cerrado y fijado e integrado previamente.

Fricción en la que está el problema

Estructuralmente, esta contradicción no proviene de defectos del consenso en cadena de bloques, sino de la forma en que evoluciona el ecosistema de pila de interacción construido a su alrededor.

La cadena de bloques garantiza transiciones deterministas de estado, consenso sobre el estado final y determinismo final. Pero no codifica de forma nativa en la capa de protocolo interpretaciones económicas, validación de intención o seguimiento de objetivos. Estas responsabilidades históricamente las asumen el front-end, las carteras, los indexadores y otras capas de coordinación off-chain, y en el proceso siempre hay participación humana.

Los patrones de interacción dominantes también reflejan este diseño: incluso para participantes profesionales. Los usuarios comunes interpretan el estado mediante paneles, eligen operaciones mediante interfaces y firman transacciones a través de sus carteras, en lugar de verificar formalmente los resultados. Las instituciones de trading algorítmico logran automatización de ejecución, pero aún dependen de selección manual de conjuntos de protocolos, verificación de anomalías y actualización de la lógica de integración cuando cambian las interfaces. En ambos escenarios, el protocolo solo garantiza la corrección de la ejecución; la interpretación de la intención, el manejo de excepciones y la adaptación a nuevas oportunidades aún se realiza manualmente.

Los sistemas de agentes comprimen e incluso eliminan esta división del trabajo. Deben reconstruir de forma programática estados con significado económico, evaluar si los objetivos están siendo impulsados y verificar los resultados más allá de solo enlazar transacciones simples. Estas cargas se destacan especialmente en la cadena de bloques, porque los agentes operan en entornos abiertos, adversarios y de cambios rápidos: nuevos contratos, activos y rutas de ejecución pueden aparecer sin revisión centralizada. El protocolo solo garantiza la ejecución correcta de las transacciones, pero no garantiza que el estado económico sea fácil de interpretar, que los contratos sean versiones oficiales, que la ruta de ejecución coincida con la intención del usuario o que las oportunidades correspondientes puedan descubrirse de forma programática.

Los siguientes apartados analizarán estas barreras en cada fase del ciclo operativo de agentes: descubrimiento de contratos y oportunidades existentes, verificación de su legitimidad, obtención de estados con significado económico y ejecución por objetivos.

Costos de descubrimiento

Los costos de descubrimiento surgen porque el espacio de acción de finanzas descentralizadas (DeFi) continúa expandiéndose en un entorno abierto sin permisos, mientras que la relevancia y la legitimidad deben ser filtradas por humanos, mediante redes sociales on-chain, mercados y capas de herramientas. Los protocolos nuevos publican anuncios y estudios, y al mismo tiempo se filtran a través de capas como integraciones del front-end, listados de tokens, plataformas de análisis y formación de liquidez. Con el tiempo, estas señales suelen formar un conjunto de criterios operables para identificar la parte del espacio de acción que tiene valor económico y suficiente confiabilidad, aunque a menudo el proceso sea informal, desequilibrado y dependa en parte de terceros y selección manual.

Si bien los agentes pueden acceder a los datos filtrados y a las señales de confianza resultantes, no tienen una vía natural para interpretar esas señales como lo hacen los humanos. Desde una perspectiva on-chain, la detectabilidad de todos los contratos desplegados es igual. Protocolos legítimos, bifurcaciones maliciosas, despliegues de prueba y proyectos abandonados existen como bytes invocables. La cadena no marca cuáles son importantes y cuáles son seguros.

Desde la perspectiva on-chain, todos los contratos desplegados tienen la misma detectabilidad. Protocolos legítimos, contratos de bifurcación maliciosos, contratos de despliegue de prueba y proyectos abandonados, todos aparecen como bytecode invocable.

Por tanto, el agente debe construir por sí mismo un mecanismo de descubrimiento: escanear eventos de despliegue, identificar patrones de interfaz, rastrear contratos de fábrica (contratos que despliegan otros contratos de forma programática) y monitorear la formación de liquidez para decidir qué contratos deberían incluirse en el rango de decisiones. Este proceso no es solo buscar contratos, sino determinar si vale la pena integrarlos en el espacio de acciones del agente.

Identificar candidatos de contratos es solo el primer paso. Tras el descubrimiento inicial y filtrado de los contratos, aún deben someterse a la validación de especificidad y autenticidad que se describe en el siguiente apartado. El agente debe confirmar que los contratos encontrados coinciden con lo que afirman, antes de incorporarlos al espacio de decisión.

El descubrimiento restringido por estrategia es distinto del descubrimiento abierto

El costo de descubrimiento no se refiere a detectar despliegues nuevos. Los sistemas algorítmicos maduros ya pueden hacerlo dentro del alcance de su propia estrategia. Por ejemplo, un buscador que monitorea eventos de la fábrica de Uniswap e incorpora automáticamente nuevas pools de liquidez está realizando descubrimiento dinámico. El obstáculo se presenta en dos niveles superiores: determinar si el contrato descubierto es legítimo (un problema de especificidad que se discutirá en el siguiente apartado); y determinar si el contrato sirve a un objetivo abierto en lugar de solo adaptarse a un tipo de estrategia predefinida.

La lógica de descubrimiento del buscador está estrechamente ligada a su estrategia: sabe qué patrones de interfaz buscar porque la estrategia ya está definida de antemano. Un agente que asume una tarea más amplia como “configurar oportunidades ajustando el riesgo óptimo” no puede depender solo de filtros derivados de la estrategia. Debe evaluar las oportunidades recién encontradas en relación con el objetivo en sí, lo que requiere interpretar interfaces desconocidas, deducir funciones económicas y decidir si esa oportunidad debe incorporarse al espacio de decisión. Esto corresponde a un problema de autonomía general, pero la cadena de bloques agrava esta dificultad: el código desconocido puede ejecutarse directamente, portar fondos, y el simple uso de señales nativas del protocolo no es suficiente para clasificarlo.

Fricción en la capa de control

El costo de la capa de control surge porque la identidad y la legitimidad normalmente se determinan fuera del protocolo, mediante filtros, gobernanza, documentación, interfaces y juicios de los operadores. En la mayoría de los flujos de trabajo actuales, los humanos siguen siendo un elemento importante en este proceso de determinación. La cadena de bloques garantiza ejecución determinista y determinismo final, pero no garantiza que el llamador esté interactuando con el contrato objetivo que corresponde. La determinación de intención se externaliza hacia contextos sociales, sitios web y selección manual.

En el flujo actual, los humanos usan la capa de confianza web como herramienta de verificación informal: encuentran el dominio oficial a través de plataformas agregadoras como DeFiLlama o cuentas sociales certificadas del proyecto, y consideran ese sitio como el mapeo oficial entre el concepto humano y la dirección del contrato. Luego, el front-end codifica una fuente de verdad efectiva, indicando qué direcciones son oficiales, qué tipo de token representar qué direcciones, y qué entradas son seguras.

El Turco Mecánico de 1789 (Mechanical Turk) es una máquina de jugar ajedrez; a simple vista parece funcionar de manera autónoma, pero en realidad depende de un operador humano oculto. (Biblioteca de la Universidad de Humboldt)

Por defecto, los agentes no interpretan señales de marca, señales sociales certificadas o “oficialidad” a través del contexto social. Podemos proporcionar al agente entradas filtradas basadas en esas señales, pero para convertirlas en suposiciones de confianza estables y utilizables por máquinas, es necesario definir un registro, reglas de estrategia o lógica de verificación. Los operadores pueden configurar al agente con listas blancas seleccionadas, direcciones certificadas y políticas de confianza. El problema no es que el contexto social sea completamente inaccesible, sino que mantener de forma continua estas barreras de protección en un espacio de acciones que se expande dinámicamente conlleva una carga operativa enorme; y además, cuando esas barreras faltan o son incompletas, el agente carece de mecanismos de verificación de respaldo que los humanos usan de manera intuitiva.

Las consecuencias reales derivadas de la insuficiencia de esta capacidad de evaluación de confianza ya se han visto en sistemas impulsados por agentes on-chain. YouTube influencer y creador Orangie tuvo un caso en el que un agente depositó fondos en un contrato “de trampa”. En otro incidente, un agente llamado Lobstar Wilde, debido a fallos de estado o contexto, interpretó erróneamente el estado de una dirección y transfirió un gran saldo de tokens a una dirección de “mendicidad” en línea. Estos casos no constituyen el argumento central del artículo, pero ilustran de forma intuitiva que errores en la evaluación de confianza, la interpretación del estado y las estrategias de ejecución conducen directamente a pérdidas de fondos.

La identificación de contratos oficiales no es una función nativa del protocolo

El problema no es que el contrato sea difícil de descubrir, sino que normalmente no existe en la cadena el concepto nativo de “este es el contrato oficial de una aplicación X”. Esta ausencia es hasta cierto punto una característica del sistema sin permisos, no una omisión de diseño; aun así, introduce dificultades de coordinación para los sistemas autónomos. El problema proviene en parte de la arquitectura de sistemas abiertos con identidades normativas débiles, y en parte de que los mecanismos de registro, estándares y distribución de confianza aún no maduran. Si un agente quiere interactuar con Aave v3, debe determinar qué direcciones son “oficiales” (pool de fondos, configuradores, proveedores de datos, etc.), y si esas direcciones son contratos inmutables, contratos proxy con actualización, o si están en un estado en el que se requiere ejecutar cambios de propuestas de gobernanza.

Los humanos resuelven este problema mediante documentación, interfaces front-end y redes sociales, mientras que el agente debe comprobar la siguiente información para determinarlo:

• El modo de proxy y hacia qué contrato apunta la implementación

• Los permisos de administración y los contratos de timelock

• Los módulos de actualización de parámetros bajo control de gobernanza

• La coincidencia de bytecode / interfaz de aplicación binaria (ABI) entre contratos desplegados conocidos

En ausencia de un registro oficial, la “oficialidad” se convierte en un problema de inferencia. Esto significa que el agente no puede tratar la dirección del contrato como una configuración estática. O bien debe mantener continuamente una lista blanca seleccionada verificada; o bien, en tiempo de ejecución, debe rededucir la conformidad del contrato mediante verificación de proxy y monitoreo de gobernanza; o bien debe asumir el riesgo de interactuar con contratos abandonados, atacados o falsificados. En el software tradicional y la infraestructura de mercado, la identidad del servicio suele estar anclada mediante espacios de nombres con nombre, credenciales y control de acceso mantenidos por instituciones. En cambio, en la cadena, un contrato puede ser invocable y funcionar correctamente, pero desde la perspectiva del llamador, en términos económicos o de negocio no es una versión oficial.

El problema de autenticidad de tokens y metadatos es esencialmente lo mismo

Los tokens parecen auto-describir información, pero sus metadatos no tienen autoridad: son solo bytes devueltos por el código del contrato. Un caso típico es Wrapped Ether (WETH). En los contratos WETH ampliamente utilizados, se define explícitamente lo siguiente:

Estas informaciones parecen representar identidad, pero en realidad no lo hacen. Cualquier contrato puede devolver lo siguiente:

• symbol() = “WETH”

• decimals() = 18

• name() = “Wrapped Ether”

E implementar exactamente la misma interfaz estándar de token ERC-20. name(), symbol() y decimals() son solo funciones públicas de solo lectura, y el contenido que devuelven lo define por completo el desplegador. De hecho, en Ethereum ya existen cerca de 200 tokens cuyo nombre es “Wrapped Ether”, cuyo símbolo es “WETH” y cuya precisión son 18 decimales. Si no consultas CoinGecko o Etherscan, ¿podrías distinguir cuál “WETH” es la versión oficial? (Respuesta: el elemento número 78 de la lista)

En Ethereum hay cerca de 200 tokens con el nombre “Wrapped Ether” y el símbolo “WETH”. Sin usar plataformas de terceros, ¿puedes determinar cuál es el WETH auténtico?

Este es el escenario al que se enfrenta el agente. La cadena de bloques no valida unicidad, no contrasta con ningún registro para verificar, y tampoco le importa. Hoy puedes desplegar 500 contratos y todos devolverán exactamente los mismos metadatos. También existen algunos métodos heurísticos para juzgar en cadena (por ejemplo, comparar saldos ETH con el suministro total, consultar la profundidad de liquidez de exchanges descentralizados populares y verificar si los protocolos de préstamos lo listan como colateral), pero ninguno puede proporcionar una prueba absoluta e incontrovertible. Cada método depende de supuestos de umbral (nadie puede falsificar pares con liquidez a escala de miles de millones) o requiere de forma recursiva validar antes la conformidad de otros contratos.

Como en un laberinto, identificar en cadena la ruta “verdadera” necesita una guía externa; no se proporciona ninguna señal estándar. (Museo y Galerías de Birmingham)

Por eso existen las listas de tokens y los registros como capa de filtrado off-chain. Proporcionan un mecanismo para mapear el concepto de “WETH” a una dirección específica; por eso la cartera y el front-end mantienen listas blancas o dependen de agregadores confiables. Para el agente, el problema central no es solo que los metadatos no sean confiables, sino que las identidades normativas normalmente se establecen a nivel social o institucional, no como parte nativa del protocolo. El único identificador confiable on-chain es la dirección del contrato; sin embargo, mapear la intención comprensible para humanos (por ejemplo, “convertir a USDC”) a la dirección correcta todavía depende fuertemente de filtrados no nativos del protocolo, registros, listas blancas u otras capas de confianza.

Fricción de datos

Un agente que optimiza entre múltiples protocolos DeFi necesita abstraer cada oportunidad como un objeto económico único: rendimiento, profundidad de liquidez, parámetros de riesgo, estructura de comisiones, fuente del oráculo, etc. Desde cierto punto de vista, esto es un problema común de integración de sistemas. Pero en la cadena de bloques, debido a la heterogeneidad de los protocolos, el riesgo directo de fondos, la necesidad de concatenar estados con múltiples llamadas y la falta de un economic schema unificado en la capa base, esta carga se amplifica enormemente. Y justamente esa es la información base necesaria para comparar oportunidades, simular configuraciones y monitorear riesgos.

En la capa de protocolo, la cadena de bloques normalmente no expone objetos económicos estandarizados: solo expone ranuras de almacenamiento, logs de eventos y valores devueltos por funciones; los objetos económicos deben inferirse o reconstruirse a partir de ello. El protocolo solo garantiza que el valor devuelto por una llamada al contrato sea el estado correcto, pero no garantiza que ese valor se corresponda de forma clara con conceptos económicos comprensibles, ni que un mismo concepto pueda obtenerse mediante interfaces consistentes entre protocolos diferentes.

Por ello, conceptos abstractos como mercado, posición, coeficiente de salud, etc., no son componentes nativos del protocolo. Se reconstruyen fuera de la cadena por indexadores, plataformas de análisis, front-ends y APIs, unificando el estado de protocolos heterogéneos en una capa abstracta utilizable. Los usuarios humanos normalmente solo ven los datos normalizados de esta capa, y los agentes también pueden usarlos, pero entonces heredan el schema de terceros, la latencia y las suposiciones de confianza; de lo contrario, deben reconstruir esas lógicas abstractas por sí mismos.

Este problema se agrava aún más entre todo tipo de protocolos. El precio de la participación en bóvedas, el ratio de colateral en mercados de préstamos, la profundidad de liquidez de pools DEX, las tasas de recompensa de contratos de staking, etc., son indicadores básicos con significado económico, pero ninguno se expone mediante interfaces estandarizadas. Cada ecosistema de protocolo tiene su propio método de lectura, formato de estructuras y acuerdos sobre unidades; incluso para la misma categoría, los métodos difieren.

Mercados de préstamos: un caso típico de lectura fragmentada

Los mercados de préstamos pueden mostrar claramente este problema. Los conceptos económicos suelen ser similares y universales, como liquidez de oferta y préstamos, tasas de interés, coeficientes de colateral, límites de cupo, umbrales de liquidación, etc.; pero las rutas de lectura de los datos son completamente diferentes.

Tomemos Aave v3 como ejemplo: el listado del mercado y la lectura del estado de reservas son pasos separados; el flujo típico es el siguiente:

Enumerar activos de reserva de la siguiente forma

Esta función devuelve un array de direcciones de tokens.

Para cada activo, se obtienen datos básicos de liquidez y tasa de interés de la siguiente forma:

Esta llamada devolverá una estructura que contiene, en una sola operación, datos como el total de liquidez, el índice de interés y un identificador de configuración, por ejemplo:

En contraste, en Compound v3 (Comet), cada despliegue corresponde a un único mercado (como USDC, USDT, ETH, etc.), y no existe una estructura unificada de reservas. Por lo tanto, se requieren múltiples llamadas a funciones para ensamblar un snapshot completo del mercado, como:

Utilización básica

Total

Tasa de interés

Configuración de colateral

Parámetros globales de configuración

Cada llamada devuelve solo un fragmento distinto del estado económico. “Mercado” no es un objeto de primer nivel: se trata de una estructura inferida que el llamador construye mediante concatenación.

Desde la perspectiva de un agente, ambos protocolos pertenecen a mercados de préstamos. Pero desde la perspectiva de integración, los dos son sistemas de adquisición de datos completamente diferentes. No existe una estructura de datos universal como la siguiente:

En cambio, el agente debe usar distintos métodos de enumeración de activos para distintos protocolos, concatenar los datos de estado mediante múltiples llamadas, unificar unidades de medida y reglas de conversión, y coordinar las diferencias entre valores inferidos y los datos base expuestos directamente.

La fragmentación causa riesgo de latencia y de consistencia

Además de la falta de unificación estructural, esta fragmentación también provoca riesgos de latencia y consistencia. Dado que el estado económico no se expone como un objeto atómico único, el agente debe emitir múltiples llamadas de procedimiento remotas (RPC) hacia varios contratos para reconstruir un snapshot de estado. Cada llamada adicional agrega latencia, aumenta la probabilidad de activar límites de tasa de interfaces y eleva el riesgo de inconsistencias por falta de sincronía del bloque. En entornos de volatilidad del mercado, cuando termina el cálculo de tasas de interés de la oferta, la tasa de utilización de fondos podría ya haber cambiado; si no se bloquea explícitamente la altura del bloque, los parámetros de configuración y el total de liquidez podrían no provenir del mismo bloque. Los usuarios humanos mitigan implícitamente este problema a través de capas de caché de front-end y backends agregadores; pero los agentes que llaman directamente a las interfaces RPC originales deben manejar explícitamente problemas de sincronización de datos, solicitudes en lotes y consistencia temporal. Por ello, la adquisición no estandarizada de datos no solo es una molestia de integración, sino también una restricción sobre rendimiento, mecanismos de sincronización y la corrección de la ejecución.

La falta de una especificación unificada para adquirir datos económicos significa que, incluso si distintos protocolos implementan casi las mismas funciones financieras base, la manera en que exponen su estado sigue siendo exclusiva de cada contrato y depende de lógicas de composición. Esa diferencia estructural es la razón central de la fricción de datos.

Posible desajuste de flujos de datos

Acceder a estados económicos en la cadena de bloques es, en esencia, un modelo pull: aunque las señales de ejecución puedan transmitirse en flujo (streaming), los sistemas externos necesitan consultar proactivamente al nodo el estado requerido, en lugar de recibir de forma continua y estructurada actualizaciones. Este modelo refleja una función central de la cadena de bloques: verificar bajo demanda, no mantener una vista continua de estado a nivel de aplicación.

En la cadena también existen componentes base del modelo push. Las suscripciones de WebSocket pueden enviar en tiempo real bloques y registros de eventos nuevos, pero estos no incluyen los estados de almacenamiento que contienen la mayor parte del significado económico, a menos que el protocolo elija deliberadamente registrar redundantemente esa información como logs. Los agentes no pueden obtener directamente, mediante suscripciones on-chain, la tasa de utilización de un mercado de préstamos, el volumen de reservas de un pool o coeficientes de salud de posiciones. Estos valores se almacenan en el espacio de almacenamiento de los contratos, y la mayoría de protocolos no proporcionan mecanismos nativos para empujar los cambios de almacenamiento a usuarios aguas abajo. La forma más viable actualmente es suscribirse a nuevos encabezados de bloques y, en cada bloque, volver a consultar el estado almacenado. Incluso si se dispara mediante eventos en streaming, el acceso al estado sigue siendo un modelo pull. Los logs solo indican que los datos podrían cambiar, pero no codifican el estado económico final; reconstruirlo todavía requiere lecturas explícitas y acceso a estados históricos.

Los sistemas de agentes, en cambio, encajan mejor con un flujo de datos inverso. Los agentes no necesitan hacer polling del cambio de estado de cientos de contratos; en su lugar pueden recibir actualizaciones estructuradas y precomputadas del estado, y empujarlas directamente a su entorno de ejecución (por ejemplo, actualizar la utilización, el coeficiente de salud o cambios de posición). Una arquitectura push puede reducir consultas redundantes, bajar la latencia desde el cambio de estado hasta que el agente lo percibe, y permitir que una capa intermedia encapsule el estado como actualizaciones con significado semántico, en lugar de obligar al agente a interpretar el significado desde almacenamiento bruto.

Este cambio de modo no es sencillo. Requiere infraestructura de suscripción, lógica para filtrar relevancia y especificaciones de eventos económicos que traduzcan cambios de almacenamiento en acciones ejecutables por el agente. Pero a medida que los agentes se convierten en participantes continuamente en línea, no en consultantes intermitentes, el problema de ineficiencia del modelo pull —límites de tasa, costos de sincronización, consultas repetidas entre distintos agentes— se volverá cada vez más grave. Tratar a los agentes como consumidores continuos en vez de clientes intermitentes probablemente se ajuste mejor al modo de operación de sistemas autónomos.

Aún no está claro si la infraestructura push es realmente mejor. El flujo de datos de cambios completos plantea problemas de filtrado, y el agente aún debe decidir qué información es relevante, lo cual reintroduce la lógica pull en otra capa. La clave no es que el modelo pull sea intrínsecamente incorrecto, sino que la arquitectura actual no se diseñó considerando usuarios persistentes tipo máquina; a medida que crece el uso de agentes, vale la pena explorar alternativas.

Fricción de ejecución

La fricción de ejecución surge porque muchas capas de interacción actuales convierten la intención, la auditoría de transacciones y la verificación de resultados, encapsulándolas en flujos de trabajo centrados en el front-end, las carteras y la supervisión humana. En escenarios de usuarios comunes y decisiones subjetivas, esta supervisión suele completarse por humanos. Para los sistemas autónomos, estas funciones deben formalizarse y codificarse directamente. La cadena de bloques puede garantizar la ejecución determinista según la lógica del contrato, pero no garantiza que la transacción cumpla con la intención del usuario, respete restricciones de riesgo o logre resultados económicos esperados. En los flujos existentes, el front-end y los humanos cubren este vacío.

La interfaz front-end orquesta la secuencia de operaciones (swap, autorización, depósito, préstamo); la cartera proporciona el punto de control final de “revisar y enviar”, y el usuario o el operador normalmente realiza de forma informal su decisión estratégica en el último paso. Usualmente juzgan, con información incompleta, si la transacción es segura y si el resultado del precio es aceptable. Si la transacción falla o produce resultados inesperados, el usuario reintenta, ajusta el slippage, cambia la ruta o abandona la operación directamente. Al remover a los humanos de este ciclo de ejecución, el sistema debe reemplazar tres tipos de funciones humanas mediante lógica nativa de máquina:

1. Compilación de intención. Objetivos humanos como “configurar mis stablecoins en la ruta de rendimiento óptimo ajustando el riesgo” deben compilarse en un plan de acción concreto: elegir qué protocolo, qué mercado, qué ruta de tokens, el tamaño de la operación, el método de autorización y el orden de ejecución. Para los humanos, este proceso se realiza implícitamente mediante el front-end; para los agentes, debe realizarse de forma formalizada.

2. Ejecución de estrategia. Hacer clic en “enviar transacción” no es solo un acto de firma: también implica una verificación implícita de que la transacción cumple restricciones, como tolerancia de slippage, límite de apalancamiento, mínimo coeficiente de salud, contratos en lista blanca o “prohibir contratos actualizables”. El agente necesita codificar las restricciones explícitas de estrategia en reglas verificables por máquinas:

Antes de transmitir la transacción, el sistema de ejecución debe verificar que el grafo de llamadas que se pretende ejecutar cumple con estas reglas.

1. Verificación del resultado. Que una transacción se publique en la cadena no equivale a que la tarea esté completada. Incluso si una transacción se ejecuta con éxito, puede no cumplir el objetivo: el slippage podría exceder la tolerancia, por límites de cupo puede no alcanzarse el tamaño de la posición objetivo, o la tasa de interés puede cambiar entre la simulación y la cadena. Los humanos verifican de forma informal mediante la interfaz después de la transacción; el agente debe evaluar programáticamente las condiciones del estado después de la ejecución:

Esto exige un nivel más alto de verificación de completitud: no puede limitarse a confirmar que la transacción se ha publicado. Una arquitectura centrada en la intención quizá ofrezca una parte de la solución: trasladar más de la carga sobre “cómo ejecutar” desde el agente hacia un solucionador especializado. En vez de enviar datos de llamadas originales, el agente difunde una intención de ejecución ya firmada y especifica condiciones de restricción basadas en el resultado; el solucionador o el mecanismo de la capa de protocolo debe satisfacer esas restricciones para que la ejecución se considere válida.

Flujos de trabajo de múltiples pasos y modos de falla

Gran parte de la ejecución en finanzas descentralizadas (DeFi) es naturalmente de múltiples pasos. Una operación de configuración de rendimiento puede requerir completarse secuencialmente: autorización → intercambio → depósito → préstamo → staking. Algunos de estos pasos pueden ser transacciones independientes, mientras que otros pueden ejecutarse mediante llamadas en lote o mediante contratos router. Los humanos pueden tolerar que el flujo no se complete por completo: pueden volver a la interfaz y seguir operando. Pero los agentes requieren orquestación determinista del flujo: si cualquiera de los pasos falla, deben decidir si reintentan, cambian de ruta, revierten operaciones o pausan la ejecución.

Esto genera un conjunto de modos de falla nuevos que normalmente quedan ocultos en flujos humanos:

• Deriva de estado entre la decisión y la transacción on-chain: entre la ejecución simulada y la fase real en la cadena, pueden cambiar la tasa de interés, la utilización o la liquidez. Los humanos aceptan esta volatilidad; el agente debe establecer rangos aceptables y ejecutarlos estrictamente.

• Ejecución no atómica y ejecución parcial: algunas operaciones pueden ejecutarse a través de múltiples transacciones o producir solo parte del resultado esperado. El agente debe rastrear estados intermedios y confirmar que el estado final cumple los objetivos.

• Riesgo de cuotas de autorización y aprobaciones: los humanos completan habitualmente firmas de autorización mediante la interfaz; el agente debe razonar sobre el alcance de la autorización (cuota, pagador, vencimiento) dentro de una política de seguridad, en vez de tratarlo como un simple paso de interfaz.

• Selección de ruta y costos de ejecución implícitos: los humanos dependen de herramientas de enrutamiento y configuraciones por defecto de la interfaz; el agente debe modelar en su función objetivo el slippage, el riesgo de extracción de valor por mineros (MEV), las tarifas de Gas y el impacto de precio.

Ejecución: un problema de control nativo para una máquina

La idea central de la fricción de ejecución es que la capa de interacción DeFi convierte la firma de la cartera humana en el eslabón final de control. Hoy, la verificación de intención, los juicios de tolerancia al riesgo y las verificaciones informales de “si parece razonable” están concentradas en ese paso. Al eliminar la participación humana, la ejecución se convierte en un problema de control: el agente debe transformar el objetivo en una cadena de operaciones, ejecutar automáticamente restricciones de estrategia y validar el resultado bajo incertidumbre. Este desafío existe en muchos sistemas autónomos, pero en un entorno de cadena de bloques es especialmente estricto, porque la ejecución involucra directamente fondos, permite llamadas componibles a contratos desconocidos y enfrenta cambios de estado adversarios. Los humanos toman decisiones basadas en experiencia y corrigen errores mediante prueba y error; los agentes deben completar trabajos equivalentes a velocidad de máquina de forma programática y, además, suelen enfrentarse a un espacio de acciones que cambia dinámicamente. Por ello, la idea de que el agente “solo necesita enviar transacciones” subestima mucho la dificultad. Enviar transacciones es solo la parte sencilla: lo que realmente falta es todo el trabajo que la interfaz y los humanos realizan, como compilación de intención, verificación de seguridad y validación de completitud del objetivo.

Conclusión

Desde su concepción, la cadena de bloques no proporciona de forma nativa una capa semántica y una capa de coordinación necesarias para agentes autónomos. Su objetivo de diseño es garantizar la ejecución determinista y el consenso de transiciones de estado en un entorno adversario. Las capas de interacción desarrolladas sobre esto siempre giran en torno a los usuarios humanos: interpretar estado mediante interfaces, seleccionar acciones mediante front-ends y verificar resultados mediante auditoría humana.

Los sistemas de agentes invierten esta arquitectura. Eliminan a los humanos como intérpretes, aprobadores y verificadores del flujo, y exigen que estas funciones se realicen de forma nativa por máquinas. Esta transformación revela fricciones estructurales en cuatro dimensiones: descubrimiento, evaluación de confianza, adquisición de datos y orquestación de ejecución. Estas fricciones no surgen porque la ejecución no sea factible, sino porque en la mayoría de escenarios, la infraestructura alrededor de la cadena de bloques aún asume la participación humana entre la interpretación de estado y el envío de transacciones.

Cerrar estas brechas puede requerir construir infraestructura nueva en múltiples capas del stack tecnológico: un middleware que normalice el estado económico entre protocolos hacia una especificación legible para máquinas; servicios de indexación o extensiones de RPC que expongan componentes semánticos básicos como posiciones, coeficientes de salud y conjuntos de oportunidades en lugar de solo datos de almacenamiento; un registro que proporcione mapeos de contratos oficiales y verificación de autenticidad de tokens; y un marco de ejecución que permita codificar restricciones de estrategia, manejar flujos de múltiples pasos y verificar de forma programática la completitud de los objetivos. Algunas brechas provienen de características estructurales de los sistemas sin permisos: despliegue abierto, identidades normativas débiles e interfaces heterogéneas; otras están limitadas por herramientas, estándares y diseños de incentivos existentes. A medida que crece el uso de agentes y los protocolos compiten por optimizar la conveniencia de integración para sistemas autónomos, se espera que estos problemas se mitiguen.

A medida que los sistemas autónomos comienzan a administrar fondos, ejecutar estrategias e interactuar directamente con aplicaciones on-chain, se hacen cada vez más evidentes los supuestos arquitectónicos incrustados en la capa de interacción actual. La mayor parte de las fricciones descritas en este artículo proviene de que las herramientas y los patrones de interacción de la cadena de bloques se desarrollaron en torno a flujos de trabajo con intermediación humana; una parte proviene de la apertura, la heterogeneidad y la naturaleza inherente del entorno adversario del sistema sin permisos; y algunas son problemas comunes que enfrentan los sistemas autónomos en entornos complejos.

El desafío central no es que el agente complete firmas de transacciones, sino proporcionarle rutas confiables; implementar, entre el estado on-chain original y la operación real, las funciones relacionadas con semántica, confianza y estrategia que hoy se logran conjuntamente por software y juicio humano.