--- title: "Cómo construir agentes onchain: wallets, pagos y datos en tiempo real" description: "Cómo construir agentes onchain: una guía agnóstica de chain para dotar a los agentes de IA de wallets seguras, pagos autónomos basados en x402 y datos blockchain en tiempo real con Alchemy." --- # Cómo construir agentes onchain: wallets, pagos y datos en tiempo real La mayoría de los tutoriales sobre "agentes de IA" se detienen en el LLM. La parte difícil empieza cuando el agente necesita una wallet, una forma de pagar por los servicios que consume y una vista en tiempo real de la cadena sobre la que actúa. Para construir agentes onchain, dale al agente tres primitivas: una wallet con permisos acotados para firmar, un riel de pago como x402, y un feed de datos en tiempo real a través de webhooks, WebSockets o gRPC. El modelo decide; estas primitivas le permiten actuar onchain. Un LLM que escribe código es un copiloto. Un agente que maneja dinero, firma transacciones y reacciona a eventos onchain en tiempo real es otra cosa: un participante de la economía. La infraestructura existe, pero está dispersa entre primitivas de wallet, pago y datos en tiempo real. Esta guía recorre las tres que realmente necesitas y cómo conectarlas entre sí. El [Alchemy CLI](https://www.alchemy.com/docs/alchemy-cli) y nuestros [productos agénticos](https://www.alchemy.com/agents) entregan cada una como una primitiva que puedes usar directamente. ## ¿Qué es distinto al construir un agente onchain? La mayor parte del stack de un agente de IA normal sigue funcionando onchain: el modelo, el framework, el patrón de tool-calling, el loop de orquestación, el harness de evaluación, el almacén de prompts. Todo eso se traslada. Si ya construiste un bot de Slack, un agente de código o un agente de investigación, la mitad superior del stack ya te resulta familiar. Tres cosas no se trasladan: la wallet, el riel de pago y el feed de datos en tiempo real. Ninguna de las tres tiene un equivalente limpio en el mundo del tooling de LLMs, ninguna se resuelve eligiendo un modelo más inteligente, y equivocarse en cualquiera de ellas es el tipo de error que vacía una wallet o traba un agente en producción. - **La identidad es una clave privada, no una dirección de correo.** Lo que el agente puede firmar, lo puede gastar. La custodia de la clave pasa de ser un archivo de configuración a un modelo de seguridad. - **Los pagos ocurren en la capa de protocolo.** Stripe no acepta "soy un agente" como forma de pago. Los rieles cripto sí, a través de estándares como [HTTP 402/x402](https://www.alchemy.com/blog/how-x402-brings-real-time-crypto-payments-to-the-web). - **Los datos en tiempo real son el modo por defecto, no una funcionalidad.** Los tiempos de bloque son cortos y la finalidad importa. Hacer polling quema presupuesto; el agente necesita que la cadena le empuje el estado. Cada uno de los tres bloques de construcción a continuación corresponde a uno de estos cambios. ## ¿Cuáles son los tres bloques de construcción de un agente onchain? Un agente onchain en producción suele necesitar tres cosas: 1. Wallet. El agente puede firmar con ella, con permisos acotados para que un prompt comprometido no pueda vaciarla. 2. Riel de pago. El agente paga por APIs offchain y gas onchain sin un humano en el ciclo. 3. Canal de datos en tiempo real. El agente reacciona a nuevos bloques, transacciones y eventos de contratos en el instante en que ocurren. El resto de esta guía es una sección por bloque de construcción, más un recorrido final que los une. ## ¿Cómo le das una wallet a un agente sin exponer tus claves? El patrón ingenuo es el que todos prueban primero: poner una clave privada en un archivo `.env`, cargarla con `dotenv`, firmar transacciones con ella desde dentro del loop del agente. Funciona en una demo local. Está a un prompt injection de distancia de una wallet vaciada en producción. Están surgiendo dos patrones como alternativas más seguras. El primer patrón son las smart accounts embebidas (contratos de wallet programables, no cuentas de clave privada en crudo) con firma delegada. La clave vive dentro de un servicio de custodia ([Privy](https://www.privy.io/), [Turnkey](https://www.turnkey.com/), [Coinbase MPC](https://www.coinbase.com/developer-platform) para computación multipartita). Tu agente nunca la ve. Llama a una API de firma, el servicio verifica la solicitud contra una política, y la transacción firmada vuelve. El agente puede firmar dentro de las reglas que definas (valor máximo por tx, contratos permitidos, límites diarios) y nada más. El segundo patrón son wallets con alcance de sesión aprobadas desde una superficie de desarrollador. El agente obtiene una sesión revocable y con tiempo limitado, vinculada a una wallet específica. Tú apruebas la sesión desde una UI que controlas. Revocarla toma un clic. La versión más reciente del patrón 2 es la [funcionalidad de agent wallet en el Alchemy CLI](https://www.alchemy.com/blog/agent-wallets-alchemy-cli), que viene incluida como parte del CLI mismo: `alchemy wallet connect` abre nuestro dashboard en un navegador. Eliges la wallet que usará el agente, apruebas la sesión, y desde ese momento el CLI puede firmar en nombre del agente. La clave privada se queda con Privy. Cada llamada de firma pasa por un flujo de dos pasos: nuestro backend construye el payload, el CLI firma localmente, la solicitud llega a Privy. Si la sesión expiró, fue revocada, o falla las validaciones de binding, la solicitud se rechaza antes de salir de nuestra infraestructura. El CLI fue diseñado como una superficie de herramientas para agentes, no solo para humanos. Estos comandos importan: --json --no-interactive", "# Print the JSON manifest of every command and flag", "alchemy --json --no-interactive agent-prompt", "# Install Alchemy Skills for agent clients", "npx skills add alchemyplatform/skills --yes", ].join("\n")} /> `alchemy --json --no-interactive agent-prompt` es la parte que hace que esto sea nativo para agentes. En vez de pedirle a tu LLM que memorice la superficie del CLI, le das el manifiesto JSON al inicio de la sesión y el modelo conoce todo el espacio de comandos, los códigos de error y ejemplos de invocación. Eso elimina toda una categoría de fallas de "el agente alucinó una flag que no existe". Conecta el [servidor MCP alojado](https://www.alchemy.com/docs/alchemy-mcp-server) por separado para herramientas de datos de chain en vivo. Cómo elegir entre los dos patrones: Elijas el que elijas, la regla es la misma: el agente nunca ve una clave privada en crudo. Si tu diseño tiene una en memoria, construiste una vulnerabilidad, no un agente. ## ¿Cómo paga un agente por los servicios que consume? Una vez que el agente tiene una wallet, todavía tiene que pagar por cosas. Dos tipos de cosas: - **Costos onchain.** Gas, comisiones de swap, comisiones de bridge, cualquier cosa que la cadena cobre por cambios de estado. - **Costos offchain.** Solicitudes RPC, APIs de datos indexados, inferencia, cualquier cosa que el agente necesite de un servidor. Los costos onchain se resuelven con [patrocinio de gas](https://www.alchemy.com/gasless-transactions). Muchos proveedores de account abstraction exponen una [API de paymaster](https://www.alchemy.com/docs/wallets/transactions/sponsor-gas), donde un paymaster es un contrato que paga el gas en nombre de otro. El agente envía una user operation (el equivalente de ERC-4337 a una transacción para smart accounts), el paymaster la cubre, tú reconcilias el uso de tu lado. Este patrón ya es común en sistemas de smart accounts. Los costos offchain son el problema más difícil, porque el agente no tiene una tarjeta de crédito registrada y tú no quieres aprovisionar API keys para cada agente. El patrón que está convergiendo en el ecosistema es x402: el código de estado HTTP 402 Payment Required, más un payload pequeño que le indica al agente cómo pagar. Este es el flujo completo: 1. El agente hace una solicitud HTTP a un servicio. 2. El servicio responde con `402 Payment Required` y un cuerpo JSON que describe el precio, el token aceptado y la chain. 3. El agente construye un pago (USDC en Base es el valor por defecto más común), lo firma con su wallet, y reintenta la solicitud original con una prueba de pago en un header. 4. El servicio verifica, liquida, y devuelve los datos. Nosotros implementamos esto de extremo a extremo. Un agente puede golpear nuestras [RPC API](https://www.alchemy.com/rpc-api), [Token API](https://www.alchemy.com/token-api), [Portfolio API](https://www.alchemy.com/docs/reference/portfolio-apis), [NFT API](https://www.alchemy.com/nft-api) y [Prices API](https://www.alchemy.com/docs/reference/prices-api-quickstart) sin API key y sin registrarse en el dashboard. La primera solicitud recibe un 402; las siguientes pagan el monto cotizado por el endpoint en USDC en Base y devuelven datos. Sin humano en el ciclo. Un manejador mínimo del lado cliente se ve así: El agente reintenta la misma URL con el header de pago firmado. El endpoint liquida el pago onchain, entrega los datos, y el agente continúa. El patrón se compone entre proveedores: cualquier servicio que hable x402 puede aceptar pagos de agentes sin escribir auth personalizada. ## ¿Cómo se mantiene el agente sincronizado con la chain? Las chains no le hacen push a tu app por defecto. Si tu agente hace polling a `eth_blockNumber` cada segundo para saber qué está pasando, estás pagando por el polling y llegando tarde a cada evento que te importa. Tres patrones cubren casi todos los casos de uso en tiempo real. El desglose completo está en la [comparación entre webhooks, WebSockets y gRPC](https://www.alchemy.com/overviews/webhooks-vs-websockets-vs-grpc), pero aquí va la versión resumida para quienes construyen agentes: gRPC streaming", tooltip: "", icon: "", }, useWhen: { title: "The agent is throughput-bound on Solana or another high-TPS chain. Lowest latency, highest cost to integrate.", tooltip: "", icon: "", }, id: 2, }, ], }} /> Para la mayoría de los agentes, [webhooks](https://www.alchemy.com/webhooks) más algunas llamadas a la [Data API](https://www.alchemy.com/docs/data) ([balances de tokens](https://www.alchemy.com/token-api), [historial de transacciones](https://www.alchemy.com/docs/reference/transfers-api), [portfolio](https://www.alchemy.com/docs/reference/portfolio-apis)) son suficientes. El webhook se dispara, el agente despierta, consulta el estado enriquecido, decide qué hacer, firma una transacción, y vuelve a dormir. ## Uniendo todo: una arquitectura mínima de agente onchain Aquí hay un boceto de arquitectura compacto que combina los tres bloques de construcción. Observa su propia wallet, consulta un endpoint de pago cuando llega algo, le pregunta a un LLM qué hacer, y firma una transacción de respuesta. Reemplaza el helper de firma x402 con tu proveedor de custodia antes de ejecutarlo en producción. {", " for (const tx of block.transactions) {", " if (tx.to?.toLowerCase() !== agentWallet) continue;", "", " const portfolio = await paidFetch(", " `https://api.g.alchemy.com/data/v1/portfolio/${tx.from}`", " );", "", " const decision = await openai.chat.completions.create({", ' model: "gpt-4o",', " messages: [", " {", ' role: "system",', ' content: "You are a treasury agent. Decide whether to refund.",', " },", " {", ' role: "user",', " content: JSON.stringify({ tx, sender_portfolio: portfolio }),", " },", " ],", " });", "", " const action = JSON.parse(decision.choices[0].message.content!);", " if (action.refund) {", " await refund(tx.from, action.amount);", " }", " }", " },", "});", ].join("\n")} /> Tres cosas vale la pena señalar sobre esta estructura: - **Ninguna clave privada en el proceso.** Cada llamada de firma pasa por la sesión del CLI, que habla con Privy. Si este proceso se ve comprometido, el atacante obtiene una sesión revocable, no una wallet. - **Sin API key para la llamada de datos.** `paidFetch` funciona contra cualquier endpoint que hable x402. El endpoint cobra por solicitud en USDC. - **El LLM es la pieza más pequeña.** La mayor parte de la superficie son wallets, pagos y plomería de datos. El modelo solo decide. Ese es el patrón. Cambia el disparador (mensaje de Discord, cron, evento de marketplace), cambia la acción (swap, voto, bridge, mint), cambia el modelo, y tienes un agente distinto. ### Constrúyelo con Claude O deja que Claude lo construya por ti. Instala [Alchemy Skills](https://www.alchemy.com/docs/alchemy-agent-skills) y conecta el [servidor MCP alojado](https://www.alchemy.com/docs/alchemy-mcp-server): Luego pega este prompt en Claude Code: El resultado refleja el script de arriba: un WebSocket de viem contra nuestro RPC, nuestra Portfolio API detrás de x402, y firma por CLI a través de la sesión de agent wallet aprobada para el reembolso. Sin clave privada en el proceso. ## ¿Qué framework de agentes deberías usar? Los frameworks se apoyan sobre las tres primitivas anteriores. Manejan el loop del agente, el registro de herramientas, la memoria y (en algunos casos) clientes de plataformas sociales. La elección correcta depende de si estás optimizando por profundidad en una chain, amplitud multi-chain, o un runtime completo. GOAT SDK by Crossmint", tooltip: "", icon: "", }, bestFor: { title: "Multi-chain agents that need EVM and Solana under one API", tooltip: "", icon: "", }, chains: { title: "EVM + Solana", tooltip: "", icon: "" }, notes: { title: "Plugin model. Good fit when the agent crosses chains.", tooltip: "", icon: "", }, id: 1, }, { framework: { title: "ElizaOS agent runtime", tooltip: "", icon: "", }, bestFor: { title: "Social agents (Twitter, Discord, Farcaster) with character files", tooltip: "", icon: "", }, chains: { title: "Any", tooltip: "", icon: "" }, notes: { title: "Full runtime including memory and platform clients. Heavier than a library.", tooltip: "", icon: "", }, id: 2, }, { framework: { title: "Solana Agent Kit by SendAI", tooltip: "", icon: "", }, bestFor: { title: "Deepest Solana protocol coverage (Jupiter, Raydium, Drift, etc.)", tooltip: "", icon: "", }, chains: { title: "Solana only", tooltip: "", icon: "" }, notes: { title: "Tool library, not a runtime. Bring your own loop.", tooltip: "", icon: "", }, id: 3, }, { framework: { title: "Vercel AI SDK", tooltip: "", icon: "" }, bestFor: { title: "Streaming agent responses to a web UI", tooltip: "", icon: "", }, chains: { title: "Any (via tools)", tooltip: "", icon: "" }, notes: { title: "Good fit for streaming agent responses to a browser UI.", tooltip: "", icon: "", }, id: 4, }, ], }} /> Para una construcción nativa de chain de extremo a extremo con configuración de wallet, integración RPC, y swaps de [Jupiter](https://www.alchemy.com/dapps/jupiter), consulta la [guía de construcción de agentes de IA en Solana](https://www.alchemy.com/blog/how-to-build-solana-ai-agents-in-2026). Para una comparación de proveedores independiente de la chain, consulta [las mejores APIs de blockchain para agentes onchain autónomos](https://www.alchemy.com/overviews/best-blockchain-apis-for-autonomous-onchain-agents). Los frameworks son intercambiables de una manera que los bloques de construcción no lo son. Puedes cambiar LangChain por GOAT en una tarde. Cambiar cómo firma tu agente es una revisión de seguridad. ## Qué construir después Los tres bloques de construcción se componen entre sí. Una vez que tienes un agente que mantiene una wallet con alcance de sesión, paga por datos con x402, y reacciona a eventos en tiempo real, la pregunta deja de ser "¿puede el agente hacer esto?" y pasa a ser "¿qué debería hacer el agente?". Entregamos cada uno de los tres bloques de construcción como una primitiva. Nuestro [CLI](https://www.alchemy.com/docs/alchemy-cli) maneja las wallets mediante sesiones revocables respaldadas por Privy. Nuestras APIs de [RPC](https://www.alchemy.com/rpc-api), [Token](https://www.alchemy.com/token-api), [Portfolio](https://www.alchemy.com/docs/reference/portfolio-apis), [NFT](https://www.alchemy.com/nft-api) y [Prices](https://www.alchemy.com/docs/reference/prices-api-quickstart) hablan x402 directamente. Sin API key, sin registro en el dashboard, sin contrato. [Webhooks](https://www.alchemy.com/webhooks), [suscripciones por WebSocket](https://www.alchemy.com/docs/reference/subscription-api), y [streaming gRPC de Solana](https://www.alchemy.com/solana-grpc) cubren el feed de datos en tiempo real. Ejecuta `npx skills add alchemyplatform/skills --yes`, conecta el [servidor MCP alojado](https://www.alchemy.com/docs/alchemy-mcp-server), y luego apunta LangChain, GOAT, ElizaOS, o tu framework hacia las APIs de Alchemy. Empieza con `npm i -g @alchemy/cli@latest` y `alchemy auth`. Aprende más en [alchemy.com/agents](https://www.alchemy.com/agents). ## Preguntas frecuentes ### ¿Qué es un agente onchain? Un agente onchain es un agente de IA que puede leer el estado de una blockchain, tener o controlar una wallet, y firmar transacciones según una política o una decisión de un modelo. El modelo decide qué hacer; la wallet, el riel de pago y el feed de datos le permiten actuar. ### ¿Cómo se construye un agente onchain? Empieza con tres primitivas: una wallet con alcance acotado para firmar, un riel de pago como x402 para llamadas a APIs pagas, y un feed de datos en tiempo real a través de webhooks, WebSockets o gRPC. Luego conecta esas primitivas al framework de agentes o al loop de orquestación que ya uses. ### ¿Qué wallet debería usar un agente de IA? Usa un patrón de wallet que mantenga las claves privadas en crudo fuera del proceso del agente. Las smart accounts embebidas con firma delegada funcionan bien para apps orientadas al usuario final, mientras que las wallets de CLI con alcance de sesión funcionan bien para agentes de desarrolladores, automatización interna, y prototipos. ### ¿Cómo pagan los agentes onchain por las APIs? Pueden usar pagos x402. El agente hace una solicitud, recibe una respuesta `402 Payment Required` con los detalles del pago, firma el pago con su wallet, y reintenta la solicitud con una prueba de pago. ### ¿Los agentes onchain deberían usar webhooks, WebSockets o gRPC? Usa webhooks cuando el agente corre como un servicio y puede recibir eventos empujados. Usa WebSockets cuando el agente corre como un proceso persistente y necesita logs o transacciones pendientes con baja latencia. Usa streaming gRPC para cargas de trabajo de alto throughput tipo Solana donde la latencia importa lo suficiente como para justificar más trabajo de integración. ### ¿Cuál es el mejor framework para agentes onchain? El mejor framework depende del loop que necesites. LangChain o LangGraph son flexibles para orquestación general, GOAT es útil para cobertura de herramientas multi-chain, ElizaOS está construido para agentes sociales, Solana Agent Kit va profundo en Solana, y el Vercel AI SDK es una buena opción para UIs de agentes orientadas al navegador. La infraestructura central está lista para construir. Lo que hagas con ella es la parte que nadie más puede escribir por ti.