ERC-7683 en 2026: cómo funcionan los resolvers y solvers cross-chain

Una operación entre redes blockchain necesita coordinar acciones que se ejecutan en sistemas distintos. En los modelos basados en intents, el usuario expresa el resultado que quiere obtener y otros participantes se encargan de ejecutar la orden bajo sus condiciones. ERC-7683 busca facilitar que esos sistemas compartan una representación comprensible de las órdenes.

La especificación mantiene el estado Draft y utiliza una arquitectura centrada en resolvers, contratos que interpretan las órdenes, distinta del modelo inicial de interfaces rígidas de 2024. Esa evolución importa al comparar implementaciones: una representación común puede facilitar la integración, pero la aplicación debe seguir explicando cómo se ejecuta y cuándo se considera completada cada operación.

Por qué hace falta una representación común de las órdenes

Un intent expresa el resultado que quiere el usuario, por ejemplo, entregar un activo en una cadena y recibir otro en una red distinta, sin imponer todos los pasos de ejecución. El problema aparece cuando cada protocolo codifica esa orden, sus restricciones y sus pagos de forma diferente. Un solver tendría que mantener una integración específica para descubrir y valorar cada mercado.

ERC-7683 coloca una capa de traducción entre ambos lados. La orden original puede ser una carga opaca propia del protocolo. Un resolver la interpreta y devuelve una representación común que otros sistemas pueden consultar sin conocer de antemano todos los detalles de ese formato privado.

Resolver y solver no son lo mismo

El resolver es el adaptador: transforma la orden en pasos, variables y pagos normalizados. El solver es el actor económico que analiza esa salida, estima costes y riesgos, y decide si puede completar la ejecución con beneficio. Separar ambos roles permite que un protocolo conserve su lógica propia y, al mismo tiempo, exponga oportunidades a un conjunto más amplio de ejecutores.

La representación común describe qué acciones deben ocurrir, qué valores pueden variar y qué pagos compensan al ejecutor. Las direcciones interoperables se apoyan en ERC-7930 para identificar cuentas o activos más allá del formato de una única cadena.

Flujo simplificado de una orden

Primero, el usuario firma o envía una orden al protocolo de origen. Segundo, un resolver decodifica esa carga y devuelve la representación común mediante una consulta. Tercero, uno o varios solvers comparan la oportunidad con su liquidez, inventario, latencia y coste de capital. Por último, el solver elegido ejecuta los pasos y el mecanismo del protocolo verifica el resultado antes de liberar el pago.

Qué estandariza y qué deja fuera

La propuesta estandariza la forma en que una oportunidad se resuelve y presenta a los solvers. No define por sí sola un puente universal, un sistema de mensajería, una red de liquidez ni un mecanismo único de disputa. Dos implementaciones compatibles pueden ofrecer garantías muy distintas porque su seguridad depende de cómo verifican y liquidan la ejecución.

Riesgos y decisiones de integración

Un equipo debe fijar la versión exacta del borrador, auditar el resolver, validar que los pagos y variables no permitan ambigüedades, limitar replays y expiraciones, y estudiar qué ocurre si una parte de la operación se ejecuta y otra falla. También debe evaluar la concentración de solvers: un formato abierto mejora el acceso, pero no crea competencia o liquidez por sí solo.

Un ejemplo para revisar los supuestos del solver

Supongamos una orden que exige entregar un activo en otra red antes de un plazo y recibir después el pago correspondiente. El solver necesita algo más que la dirección de destino: debe conocer qué evidencia desbloquea el cobro, cuándo puede considerarla suficiente y qué condiciones podrían impedirlo después de haber comprometido capital.

En la arquitectura descrita por el borrador, el resolver EVM puede consultarse mediante eth_call. Su respuesta incluye instrucciones y supuestos que el solver debe evaluar. La consulta no ejecuta por sí sola la orden ni garantiza que las dependencias externas mantengan el estado observado.

La revisión técnica debería ensayar una expiración durante el recorrido, un cambio de permisos y una prueba de ejecución que no sea aceptada por el sistema de liquidación. El objetivo es localizar dónde queda el capital y qué procedimiento permite completar o cerrar la operación. Una representación común facilita leer las instrucciones; la seguridad depende de que esas instrucciones y sus supuestos sean correctos.

Por qué puede importar aunque siga en Draft

La tesis de ERC-7683 es que la interoperabilidad no necesita obligar a todos los protocolos a compartir una única lógica interna. Puede estandarizar el punto de encuentro donde los ejecutores leen y comparan órdenes. Si el borrador converge y recibe adopción, reduce el coste de integrar nuevos mercados de intents; mientras tanto, conviene tratarlo como una interfaz en evolución, no como una garantía de compatibilidad definitiva.