Settlement cross-chain para agentes: CCTP V2 Fast Transfer y Hooks

x402 y EIP-3009 liquidan un pago en una cadena. No dicen nada sobre que pasa cuando los dolares que tiene un agente viven en otra parte. Ese hueco es donde la mayoria de los disenos de pago de agentes se rompe en silencio.

Ya dedicamos varios posts a los primitivos de settlement de una sola cadena. x402 convierte un HTTP 402 en un desafio pagable por maquinas. EIP-3009 es la autorizacion gasless que va debajo: el pagador firma, un facilitator la envia, el USDC se mueve. Ambos asumen que pagador y receptor estan en la misma cadena, con el mismo contrato de token.

Los agentes autonomos violan esa suposicion todo el tiempo. Un agente gana fees en Base, mantiene una tesoreria en Arbitrum y llama una tool cotizada en USDC en Polygon. Los dolares son reales y nativos en todas partes, pero no estan en el lugar correcto. El arreglo ingenuo — pre-fondear un balance en cada cadena donde el agente podria llegar a pagar — es capital ocioso repartido en una docena de dominios. El otro arreglo ingenuo — puentear con un asset envuelto (wrapped) — cambia un dolar nativo por un IOU respaldado por un custodio de bridge, que es justo la suposicion de confianza que el settlement en stablecoins venia a eliminar.

La capa que cierra este hueco es el Cross-Chain Transfer Protocol de Circle, y en concreto CCTP V2. No es un bridge en el sentido de asset envuelto. Es la capa de movilidad de settlement que a x402 le faltaba.

Burn and mint, no lock and wrap

Un bridge convencional bloquea USDC en un contrato de la cadena origen y emite un reclamo envuelto en la destino. El token envuelto vale solo tanto como el colateral del bridge y su multisig. CCTP hace lo contrario: quema (burn) USDC nativo en la cadena origen y acuna (mint) USDC nativo en la destino. No hay representacion envuelta, ni pool de liquidez, ni custodio de terceros sosteniendo tu balance. El dolar que llega es el mismo USDC canonico que Circle emite y redime en esa cadena.

En cadenas EVM la maquinaria tiene dos capas. TokenMessengerV2 es la capa de logica que quema y acuna tokens; delega el burn a TokenMinterV2. MessageTransmitterV2 es la capa de mensajeria generalizada por debajo. El flujo es determinista:

// 1. Cadena origen: el agente quema USDC y emite un mensaje
tokenMessenger.depositForBurn(
  amount,              // USDC a quemar en la cadena origen
  destinationDomain,   // domain id de Circle de la cadena destino
  mintRecipient,       // direccion bytes32 que recibe el mint
  usdc,                // burnToken en la cadena origen
  destinationCaller,   // bytes32(0) = cualquier relayer puede finalizar
  maxFee,              // techo de la fee, pagada en USDC
  minFinalityThreshold // elige Fast vs Standard (ver abajo)
);

Tras el burn, el servicio de atestacion off-chain de Circle — llamado Iris — observa el evento de la cadena origen, espera las confirmaciones requeridas y firma una atestacion sobre el mensaje. Cualquiera puede tomar esa atestacion de la API de Circle y enviarla a MessageTransmitterV2#receiveMessage en la cadena destino, que verifica la firma y dispara el mint. El replay se previene con un nonce computado en el momento de la atestacion a partir de la transaccion y su evento emitido, un diseno elegido justamente para que un reorg de la cadena origen no colisione dos mensajes en el mismo nonce.

Dos propiedades importan para los agentes. Primero, destinationCaller puesto en bytes32(0) significa que cualquier relayer puede finalizar la transferencia — el agente no necesita gas ni una hot key en la cadena destino para completar el settlement. Segundo, las direcciones de los contratos son deterministas por dominio, asi que una integracion escrita contra la interfaz V2 se comporta identico en todas las cadenas soportadas.

Fast Transfer: atestar antes de la finalidad

La unica perilla que decide cuanto tarda una transferencia es minFinalityThreshold. La referencia de finalidad y fees de Circle define los niveles: los mensajes con un minFinalityThreshold de 1000 o menos se tratan como mensajes Fast; un valor de 2000 es una transferencia Standard, totalmente finalizada. El minimo que acepta el contrato es 500.

Standard Transfer espera la finalidad dura en la cadena origen — unos 13 a 19 minutos en Ethereum y sus L2s — y luego acuna. Fast Transfer deja que Iris ateste antes de la finalidad dura, una vez que la transaccion esta confirmada pero aun no es irreversible. Eso colapsa la espera a segundos. Circle absorbe el riesgo de reorg durante esa ventana con su Fast Transfer Allowance, y cobra una fee por ello.

La fee aparece en el mensaje de burn. El BurnMessage de V2 lleva maxFee (el techo que el pagador firma) y feeExecuted (lo que efectivamente se dedujo del monto transferido en el mint), mas un expirationBlock para los mensajes Fast. La fee se cotiza en puntos basicos desde el endpoint /v2/burn/USDC/fees de Circle y se paga en USDC del monto transferido. Si pones maxFee demasiado bajo para un Fast Transfer, o pones minFinalityThreshold por encima de 1000, la transferencia cae a Standard, donde la fee es actualmente cero en la mayoria de los deployments.

Del lado receptor, la finalidad ejecutada es visible para el destinatario. Un contrato implementa handleReceiveFinalizedMessage para aceptar solo mensajes donde finalityThresholdExecuted sea al menos 2000, o handleReceiveUnfinalizedMessage para aceptar tambien mensajes Fast por debajo de eso. Si un mensaje Fast queda sin consumir y expira, no se cobra fee, y puede re-atestarse a un umbral mayor bajo el mismo nonce. El receptor decide cuanta finalidad exige antes de tratar un dolar como recibido.

Hooks: pagar al llegar, de forma atomica

La caracteristica que convierte a CCTP de un rail de transferencia en un rail de settlement son los Hooks. El caller de la cadena origen usa la variante con un payload de bytes al final:

tokenMessenger.depositForBurnWithHook(
  amount,
  destinationDomain,
  mintRecipient,        // el contrato receptor en la destino
  usdc,
  bytes32(0),          // cualquier relayer puede finalizar
  maxFee,
  1000,                 // Fast
  hookData              // bytes arbitrarios, reenviados tras el mint
);

Tras el mint en la destino, MessageTransmitterV2 reenvia hookData al contrato receptor dentro de la misma transaccion de la cadena destino. Una sola accion en la cadena origen puede entonces acunar USDC nativo y actuar sobre el de inmediato: depositar en un mercado de prestamos, hacer swap a otra stablecoin, liquidar una orden o pagar un servicio. El receptor reacciona implementando el handler:

function handleReceiveUnfinalizedMessage(
  uint32 sourceDomain,
  bytes32 sender,
  uint32 finalityThresholdExecuted,
  bytes calldata messageBody
) external returns (bool) {
  // corre tras el mint, en la misma tx — atomico
  // decodifica hookData, libera la tool call, acredita al agente
}

Antes de los Hooks, el patron requeria dos transacciones de usuario — acunar aca, luego actuar alla — o un relayer off-chain que tenia poder de firma y podia atascar o reordenar. Los Hooks quitan esa costura. El mint y el efecto posterior o pasan ambos o no pasa ninguno, sin ninguna suposicion de confianza agregada mas alla de la propia atestacion de CCTP.

Como compone con x402

x402 y CCTP resuelven mitades distintas de la misma transaccion. x402 es autorizacion de pago: un resource server declara su precio y esquema aceptado, el cliente firma una autorizacion EIP-3009 y un facilitator la verifica y liquida — todo en una cadena. CCTP es movilidad de settlement: entrega dolares nativos a la cadena donde esa autorizacion debe aterrizar.

Componelos y el pago cross-chain deja de ser un caso especial. Un agente en Base quiere una tool que solo liquida en Arbitrum. Quema USDC en Base con un Hook cuyo payload lleva la intencion de pago de la cadena destino. El mint aterriza en Arbitrum, el Hook dispara en la misma transaccion y el contrato receptor hace el settlement con forma de x402 localmente — verificando y acreditando el pago contra el USDC recien acunado y nativo. El agente nunca pre-fondeo Arbitrum, nunca toco un token envuelto y nunca sostuvo una hot key en la cadena destino.

Es la misma disciplina de capas que defendimos con la extension A2A x402 y con account abstraction para wallets de agentes: manten la politica de la llave de firma angosta, manten la transferencia de valor nativa y deja que cada protocolo posea exactamente una responsabilidad. CCTP es la pieza que permite a un agente tener un unico balance consolidado de dolares y aun asi pagar en cualquier lado.

Donde puede morder

Nativo no significa trustless. La unica suposicion de confianza de CCTP es el servicio de atestacion de Circle — la misma entidad que emite y redime USDC en cada cadena, asi que no es una contraparte nueva, pero es una real. Circle retiene un rol privilegiado que puede pausar atestaciones o pausar receiveMessage globalmente. Un agente que trata una transferencia en vuelo como ya liquidada esta expuesto durante esa ventana.

La velocidad de Fast Transfer se compra con una suposicion de reorg. Circle asume el riesgo de finalidad, pero un agente deberia igual tratar un mint Fast como economicamente final solo hasta el valor que este dispuesto a perder en un reorg de la cadena origen. Para movimientos grandes de tesoreria, Standard Transfer y handlers finalizados son el default conservador. Y la cobertura de Circle no es universal: para 2026 CCTP V2 abarca Ethereum, Base, Arbitrum, Optimism, Polygon, Avalanche, Solana y una lista creciente, pero las cadenas fuera de ese conjunto aun necesitan otro rail. CCTP V1 comienza su phase-out el 31 de julio de 2026, asi que cualquier integracion deberia apuntar a V2 desde el inicio.

Que significa para LLM4Agents

LLM4Agents liquida el uso en stablecoins sobre un gateway compatible con OpenAI. Hoy ese settlement es local a la cadena: un agente fondea un balance en una cadena soportada y lo consume. El settlement cross-chain cambia la forma del balance. En lugar de pedir a los operadores que pre-posicionen USDC en cualquier cadena desde la que sus agentes pagan, la plataforma puede aceptar un burn en la cadena de origen del agente y acunar en la cuenta de settlement — USDC nativo, sin desvio envuelto, sin floats ociosos por cadena.

Tambien ensancha la superficie de fondeo. Como cubrimos en fondear agentes con stablecoins, la parte dificil es llevar los dolares a donde el agente gasta. CCTP convierte eso de un problema de onboarding por cadena en una sola llamada de burn-and-mint. Y los Hooks permiten a la plataforma hacer los depositos atomicos: el top-up cross-chain de un agente puede acreditar su balance en el gateway en la misma transaccion que acuna el USDC, asi nunca hay una ventana donde los dolares llegaron pero la cuenta no fue acreditada.

La amenaza a vigilar es el acoplamiento. Apoyarse en un unico servicio de atestacion para la movilidad de settlement concentra una dependencia. La plataforma deberia tratar a CCTP como una ruta de settlement entre varias, no la unica, y mantener el modelo de balance agnostico de la cadena para que un segundo rail entre sin reescritura.

Como mantenerse en la frontera

Pasos concretos, en orden.

Primero, hacer el modelo de balance agnostico de la cadena. El balance de un agente en el gateway deberia ser una unica cifra consolidada de dolares, no un ledger por cadena que el operador tenga que administrar. Esa es la precondicion para aceptar settlement de cualquier cadena soportada sin casos especiales.

Segundo, integrar CCTP V2 como ruta de fondeo entrante. Aceptar un burn de Fast Transfer en la cadena de origen del agente, acunar en la cuenta de settlement de la plataforma y acreditar el balance de forma atomica via un Hook. Exponer la eleccion de finalidad — Fast versus Standard — como una politica por transferencia que el operador fija, para que los top-ups sensibles al tiempo paguen por velocidad y los movimientos de tesoreria tomen el camino gratis.

Tercero, unificarlo con el settlement de x402. El handler de la cadena destino que recibe un mint de CCTP deberia compartir codigo con el camino del facilitator de x402, para que un pago cross-chain y un pago en la misma cadena acrediten el balance a traves de la misma logica verificada. Un unico core de settlement, dos puntos de entrada.

Cuarto, mantener la politica de la llave angosta. El settlement cross-chain no debe requerir que el agente tenga gas ni una hot key en la cadena destino — destinationCaller = bytes32(0) y la finalizacion por relayer mantienen la superficie de firma del agente exactamente donde account abstraction ya la puso.

Quinto, planear un segundo rail. Abstraer la ruta de settlement detras de una interfaz ahora, mientras CCTP es la unica implementacion, para que agregar despues un rail competidor de burn-and-mint o basado en intents sea un adaptador nuevo y no una migracion.