Tutoriales, comparativas y patrones de diseño para construir agentes autónomos que se autofinancian, llaman a 345+ modelos y orquestan MCP Tools.
La revision 2026-07-28 de MCP convirtio a los Client ID Metadata Documents en la forma preferida de que un agente se identifique, y deprecio Dynamic Client Registration. Diffeamos las tres revisiones del draft del IETF, crawleamos las 87.160 entradas del registry de MCP y resolvimos 3.450 authorization servers. Solo el 17,2 por ciento publica soporte de CIMD; el 93,7 por ciento sigue publicando un endpoint de DCR; y el 88,5 por ciento de los que adoptaron CIMD dejaron DCR corriendo al lado.
x402 separa la verificación del pago de la liquidación on-chain, y esa ventana fue objeto de tres papers de seguridad este año. Corrimos los ataques contra @x402/express 2.24.0 y auditamos el monorepo en HEAD. El grant duplicado está cerrado. El trabajo duplicado no, y la sustitución de recursos sigue funcionando al primer intento.
Un agente que solo tiene USDC igual necesita gas. Circle Paymaster es la vía permissionless para pagarlo en USDC, y es un modelo de confianza distinto al del facilitator de x402 que absorbe el fee. Auditamos cada deployment de mainnet y medimos un día completo de tráfico: el precio del gas lo fija la user operation, no la cadena, y en la ventana medida las cuentas pagaron 202.307 USDC por transacciones que costaron 358 dólares incluir.
El working group AIPREF del IETF tiene dos drafts standards-track que vencen en el IESG el 31 de agosto de 2026. Uno de ellos dice, en su propia portada, que su contenido no refleja el consenso del grupo. Leimos cada revision, implementamos el algoritmo de resolucion y lo corrimos contra un crawl fresco del top 10.000 de dominios. Exactamente un dominio emite una preferencia que la especificacion puede leer.
Entre el 21 y el 28 de agosto, tres cambios mergeados en x402 atacaron la misma premisa: que un pago es una request, una firma y una liquidacion. auth-capture se convirtio en un ciclo completo authorize/capture/void/refund con binding onchain del authorizer, settlement_pending dejo de ser problema del caller y el scheme exact aprendio a liquidar antes de servir. MCP, en paralelo, publico su roadmap posterior a 2026-07-28.
Una tabla en los SDKs de x402 decide tres cosas a la vez: a qué stablecoin resuelve un precio en dólares, qué dominio EIP-712 firma el cliente y qué activos puede pagar un cliente por defecto. Corrimos cada fila EVM contra su token on-chain. Diecinueve de veinte entradas EIP-3009 verifican. Una lleva cinco meses firmando contra el dominio equivocado, en los tres SDKs.
Veintitrés bytes de código de delegación cambian qué función valida la firma de pago de tu agente: ecrecover pasa a ser isValidSignature, y decide el delegate. Escaneamos 74.029 autorizaciones EIP-3009 en Base en 24 horas, clasificamos a cada pagador, encontramos 497 smart EOAs sobre 18 implementaciones distintas y luego sintetizamos una cuenta 7702 para cada una para correr el camino real de USDC con una firma cruda del dueño. Trece la aceptaron, cinco la rechazaron, y las cuentas vivas nos explicaron por qué la división no depende solo del delegate.
Nuestras dos últimas auditorías encontraron que el cap por pago de x402 y el presupuesto onchain de Coinbase nunca componen. Esta semana auditamos el stack que por fin conecta ambas capas: el Delegation Framework de MetaMask, el asset transfer method erc7710 en la spec de x402 y un facilitator vivo redimiendo delegaciones en Base. Verificamos bytecode en cuatro cadenas, medimos 20.009 redemptions en siete días — 36x el rail de Coinbase — y probamos los paquetes de npm hasta encontrar el default que rompe el propio quickstart de MetaMask.