Una intención es una orden que dice qué resultado quieres obtener, no qué transacciones hay que enviar. La firmas, un conjunto de solvers compite por entregar ese resultado y una capa de liquidación paga a quien lo consiguió. Con eso el enrutamiento, el gas y la espera entre cadenas pasan del usuario a una contraparte profesional, y aparece otro conjunto de preguntas: quién puede pujar, con qué vara se le mide, qué respalda su promesa y qué ocurre con tu dinero cuando nadie puja.
Órdenes declarativas: qué es realmente una intención
Una transacción normal es imperativa. Nombra el contrato, la función, los argumentos y el gas, y firmarla autoriza exactamente un camino de cómputo sobre un estado dado. Todo queda decidido antes de la firma, y todo lo que no se previó es problema tuyo.
Una intención es declarativa. Es un conjunto firmado de restricciones que describe el resultado que aceptarás, y admite cualquier ruta de ejecución que las cumpla. La transacción dice «haz A y luego B, paga exactamente C y recibe X»; la intención dice «quiero X y estoy dispuesto a pagar como mucho C». Vista así, la transacción es el caso particular de una intención que sólo admite una transición de estado.
La consecuencia práctica es que, al firmar y difundir una intención, concedes a un tercero permiso para elegir el camino de cómputo en tu nombre. De ahí viene la comodidad, y de ahí viene también cada riesgo de este artículo.
Nada de esto es nuevo en su forma. Las órdenes limitadas, pagar la comisión con un token que ya tienes o los agregadores que prometen la mejor ruta entre varios mercados tienen forma de intención: el usuario pone la condición y otro elige la ejecución. Lo nuevo es que ahora se construye como infraestructura general y que una misma orden puede abarcar varias cadenas.
Los cuatro papeles de un sistema de intenciones
Escrito como ciclo de vida, el patrón tiene cuatro partes. Un usuario expresa una intención a una aplicación; la aplicación la convierte en una orden de un protocolo concreto; la orden entra en un flujo de órdenes donde los solvers la ven; un solver la evalúa, ejecuta los pasos necesarios y un proceso de liquidación paga al solver.
Vale la pena aprender el vocabulario, porque ya está escrito en un estándar. Una orden es una oferta de pago a cambio de que se cumpla un conjunto de requisitos. Un solver, también llamado filler, es quien cumple esos requisitos. El pago cierra el circuito: el solver trabaja primero y cobra en la liquidación.
El estándar en cuestión es ERC-7683, intenciones entre cadenas (Cross Chain Intents). Es un ERC de la vía Standards Track, creado en abril de 2024, y al escribir esto sigue en estado Draft, es decir, borrador. Además se ha rehecho a fondo: un borrador anterior estandarizaba la codificación de las órdenes, un flujo de órdenes en cadena, la custodia y la función de ejecución, mientras que el texto actual estandariza sólo la interfaz por la que un solver lee una orden y deja a cada protocolo libertad en la creación de órdenes, la autorización, el precio y la liquidación. Se apoya en ERC-7930, el formato de direcciones interoperables, que está en estado Review.
Que siga en borrador pesa aquí más que en otros sitios, porque no es la única propuesta del área: ERC-7521 cubre intenciones generales para billeteras de contrato inteligente y también sigue en borrador. No des nada de esto por cerrado. El campo de estado de cada ERC aparece al principio de su página en el repositorio de ERCs de Ethereum, y la discusión viva está en el hilo de Ethereum Magicians que ese texto indica, así que comprueba tú mismo la etapa actual.
Por qué es el solver quien adelanta el dinero
Bajo las intenciones entre cadenas hay un hecho incómodo: dos cadenas no liquidan de forma atómica, alguien tiene que moverse primero. En el diseño habitual, los fondos del usuario quedan bloqueados en un contrato de la cadena de origen al crear la orden, de modo que el solver tenga la certeza de que el dinero existe antes de comprometer capital propio al otro lado.
Después el solver entrega el resultado con su propio inventario: tiene el activo en la cadena de destino, te lo envía y sólo más tarde se le reembolsa desde los fondos bloqueados a través del proceso de liquidación. En un diseño ya en producción las ejecuciones se agrupan en lotes y se reembolsan en un ciclo que se mide en horas y no en segundos, y por eso un solver necesita capital de trabajo y no sólo un bot rápido.
Las transacciones también las envía el solver, así que el gas lo paga él. Ese es el mecanismo detrás de los flujos de intenciones que se anuncian sin gas: el coste no ha desaparecido, se ha trasladado al precio que el solver te cotiza.
Ese hueco entre gastar y cobrar es justo donde vive el riesgo del solver. La sección de seguridad del propio estándar lo dice sin rodeos: un solver queda expuesto desde el momento en que compromete capital, autorizaciones o transacciones hasta que su pago esperado es definitivo y disponible. Todo lo que puede torcerse en esa ventana, desde una reorganización de la cadena hasta la entrega de mensajes o un protocolo que cambia de estado, ya está incorporado al precio que ves.
Cómo decide la competencia el precio que recibes
Como el usuario ha dejado de indicar la ruta, el precio tiene que producirlo la competencia. Los diseños difieren en cómo: unos usan subastas holandesas en las que el listón que el solver debe batir se mueve con el tiempo, otros toman el precio de un oráculo, otros fijan la comisión y dejan que los solvers compitan sólo en velocidad.
Las subastas por lotes son la versión más explícita. Las órdenes se recogen durante una ventana corta, los solvers presentan soluciones completas, cada solución se puntúa más o menos por el excedente que genera para los usuarios del lote y gana la de mayor puntuación. A los ganadores se les paga con una regla de segundo precio, así que la recompensa depende del margen sobre la siguiente mejor oferta y no de lo que el ganador declare.
La competencia sólo sirve si hay una referencia. Un conjunto de reglas publicado exige que los precios de un solver no sean peores que lo que el usuario habría obtenido en una lista definida de fuentes de liquidez de referencia, y exige precios de liquidación uniformes: dos órdenes del mismo par y en el mismo sentido deben recibir el mismo precio. Sin algo así, la mejor ejecución es lo que diga el solver ganador.
Esta es también la respuesta honesta a por qué las intenciones pueden ganar al enrutamiento manual. Un solver puede casar tu orden con la orden contraria de otro usuario, empaquetar varias ejecuciones en una sola transacción y elegir para el reembolso la cadena que menos le cuesta. El ahorro es real, pero te llega en la medida en que la competencia y la regla de puntuación lo obligan a soltarlo.
Qué respalda de verdad la promesa del solver
Firmar una intención es dar margen a otro. Lo que frena el abuso no es la firma, sino la capa de rendición de cuentas construida alrededor del conjunto de solvers, y esa capa es distinta en cada sistema, que es justo lo que casi todas las explicaciones se saltan.
El primer control suele ser la entrada. En un conjunto de reglas publicado, un solver debe estar en una lista blanca antes de poder siquiera enviar una liquidación; los operadores mantienen un monitoreo que revisa cada liquidación en cadena y marca las sospechosas; el incumplimiento sistemático puede sancionarse, hasta llegar al slashing.
El segundo control es la verificación con ventana de impugnación. En lugar de demostrar cada ejecución en cadena, un diseño de liquidación deja que un actor proponga un lote de resultados junto con una garantía, y el lote se acepta si nadie lo impugna dentro de un plazo fijo. El usuario recibe primero la velocidad; la prueba llega después.
El tercer control es la propia frontera de confianza, y el estándar es inusualmente claro sobre dónde termina. ERC-7683 estandariza cómo se describe una orden a los solvers; no estandariza ni garantiza la seguridad del protocolo que acaba liquidándola. Se espera que los solvers revisen ellos mismos el contrato que les traduce las órdenes y validen los supuestos que ese contrato no puede comprobar. Al usuario, el estándar no le promete nada sobre el sistema de liquidación que hay debajo.
Concentración, censura y el camino de vuelta de tu dinero
El riesgo estructural del modelo de intenciones es que el conjunto de quienes ven y pueden ejecutar tu orden se vuelva pequeño. Si el acceso al flujo de intenciones es permisionado y la lista se elige sin cuidado, el flujo de órdenes se concentra, y quien controle una parte grande está en posición de cobrar rentas y, en el extremo, de censurar.
La difusión abierta no lo arregla sola. Un nodo capaz de ejecutar una intención con beneficio no tiene incentivo para reenviarla a la competencia, y un pool de intenciones totalmente público expone las órdenes a la misma extracción que un mempool público. Por eso muchos sistemas acaban en diseños permisionados o híbridos, y por eso la pregunta práctica no es si está descentralizado, sino quién está en la lista y quién decide.
El coste asociado es la opacidad. En la peor versión firmas algo, desaparece y reaparece como una transacción sin que se vea quién la construyó ni qué alternativas descartó. La calidad de ejecución que no puedes auditar es calidad de ejecución que aceptas por confianza.
Luego está el fallo más corriente, más frecuente que los exóticos: no puja nadie. Las órdenes llevan un plazo de ejecución. Si pasa sin ejecución y sin ejecución parcial, la orden caduca y los fondos bloqueados vuelven, normalmente a la dirección indicada en la orden y, por defecto, en la cadena de origen. Las causas son prosaicas: un importe inusualmente grande, un par de tokens poco común o solvers caídos un rato.
Lo que ese reembolso no es, es inmediato. Como el dinero vuelve por el mismo proceso de liquidación por lotes que paga a los solvers, una ejecución normal tarda segundos y una caducidad puede tardar horas en resolverse. Cuando dimensionas una orden o construyes un producto encima, el plazo de ejecución y la ruta de reembolso son los dos parámetros que conviene leer antes que la comisión.
En resumen
Las intenciones trasladan el trabajo de ejecutar del usuario a quien puja: firmas el resultado que quieres, los solvers compiten por entregarlo, adelantan el capital y el gas, y una capa de liquidación paga a quien cumplió. La eficiencia es real y el intercambio también, porque entregas a un tercero la discreción sobre cómo se ejecuta tu orden, y lo que te protege no es la firma, sino las reglas de la subasta, la referencia contra la que se puntúan esas pujas, las condiciones de entrada y el monitoreo alrededor del conjunto de solvers, y el plazo que te devuelve el dinero cuando no puja nadie. El estándar de órdenes entre cadenas, ERC-7683, sigue siendo un borrador y ya ha sido rediseñado una vez, así que trata cualquier descripción suya, incluida esta, como una foto de un momento, y comprueba su campo de estado antes de construir sobre él.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Diseños de puente: bloqueo, quema y emisión nativa
- ¿Qué es Hyperlane? Interoperabilidad sin permisos
- Puentes de stablecoins: mover dólares entre cadenas
Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en agosto de 2026; consulta la información oficial más reciente.
Fuentes
[1] ERC-7683: Cross Chain Intents eips.ethereum.org
[2] ERC-7930: Interoperable Addresses eips.ethereum.org
[3] ERC-7521: General Intents for Smart Contract Wallets eips.ethereum.org
[4] Intent-Based Architecture and Their Risks paradigm.xyz
[5] What are Crosschain Intents? docs.across.to
[6] Intent Lifecycle in Across docs.across.to
[7] Refunds docs.across.to
[8] Solver competition rules docs.cow.fi
