Autonomous onchain actions: what AI agents can actually do onchain

An AI agent now opens a Polymarket position, refills its own API balance in USDC, and rebalances across Aave markets without a person clicking confirm. The gap between what agents could do onchain a year ago and what they ship every day now is wider than most product pages admit. The shift is the moment an LLM stops suggesting actions and starts signing them.

An LLM that writes code is a copilot. An LLM that holds a wallet is an agent. Once the wallet is real and the agent can spend from it, every onchain primitive becomes a tool the model can call: read state, sign a transaction, pay for an API, swap and bridge, vote, attest. This post walks the six primitives, names the live agents using each one, and points at the stack that lets us treat them as production users instead of edge cases.

What is an autonomous onchain action?

An autonomous onchain action is any transaction an agent signs and submits without a human approving that specific call. The agent operates inside a permission envelope set up ahead of time, a session key with a spend cap and a contract allowlist, or a policy on a custodial wallet, and acts freely inside that envelope. Reading state is not an autonomous onchain action. Sending a transfer the user has not pre-authorized is also not an autonomous onchain action. The signing has to happen, and it has to happen without a per-action prompt.

That definition matters because it sorts the market. A chatbot that produces a transaction payload for a human to sign in a wallet is not an onchain agent. A cron job that signs and broadcasts on its own already is, even if no LLM sits anywhere in the loop. The bar is autonomous signing, not the presence of a model.

What primitives does an onchain agent use?

Six primitives cover almost every onchain action an agent runs in 2026. Each one corresponds to a tool the model calls, and each one has a separate failure mode worth knowing about.

• Read. Query state, prices, balances, events. The agent uses an RPC endpoint, an indexed Data API, or an MCP server that wraps both. Read access is the cheapest primitive and the most reliable. It is also where most "agent" volume on dashboards comes from, which is why headline transaction counts can be misleading.
• Sign. Submit a transaction from a wallet the agent controls. This is where autonomy starts. Sign requires a custody pattern (embedded wallet, MPC, smart account, or raw key) and a policy engine that decides whether to sign now. A raw key signs whatever it is handed; the policy is the only thing that can say no.
• Pay. Settle for offchain compute and APIs. Agents pay in USDC over x402 for crypto-native services and over Stripe's Machine Payments Protocol when the merchant is on cards or stablecoins. Without a per-call cap, the agent pays whatever a 402 asks.
• Swap and bridge. Move value across pools and chains. Agents call Jupiter on Solana, Uniswap or 0x on EVM, and bridges like Across or deBridge to land funds on the chain where the next action makes sense. Broadcast a naive swap and it can get sandwiched for its size.
• Govern. Cast a vote, delegate, propose. Less common than the trading primitives in volume, more interesting in shape: a single agent can run a tracking strategy across hundreds of DAOs that human voters never have time for. The risk is a policy that keeps voting after it has drifted from the holder's intent.
• Prove. Attest to an identity, post a reputation receipt, register inside ERC-8004. This is the youngest primitive and the one that turns one-off agents into composable services other agents can hire. An attestation is only worth as much as the issuer behind it.

The order is not arbitrary. Read and sign are the universal core. Pay is what makes the agent economic. Swap, bridge, and govern are what give the agent reach. Prove is what makes one agent legible to another. Skip a primitive and an entire category of action falls off the menu.

What can agents actually do onchain today?

The concrete inventory, organized by category.

DeFi positions and yield

DeFi agents take two common shapes. Some run as swarms of specialized roles working a shared treasury. Others run as single-purpose rebalancers that do one job well.

The recurring mechanic: the agent reads positions through an indexed Data API, computes a target allocation, signs supply or withdraw calls on Aave, Morpho, or Pendle, and re-checks on a heartbeat. The hard part is not the math. It is staying inside the permission envelope when a new market looks better but is not on the allowlist.

That loop is not hypothetical. In the demo below, an agent compares Aave USDC yields across L2s, bridges from Base to the best chain, and supplies, all from the terminal with no ETH on hand and only a scoped key.

Trading and rebalancing

Trading agents now run across the major venues. Some sit behind natural-language interfaces on Farcaster and X, routing swaps on Base, Solana, or Polygon through 0x or Uniswap. Others run skills-based stacks against Hyperliquid perps, with trailing stops and smart-money scoring across hundreds of markets.

Hyperliquid is the densest agent surface in the perpetuals market, with builder-code revenue running into eight figures. The agent's edge in this category is not better signals. It is the willingness to act on a signal at 3 a.m. without second-guessing.

Prediction markets

Autonomous Polymarket positions are a real category now. CoinDesk's March 2026 readout tracked Polystrat agents at 4,200-plus trades in their first month, with more than a third showing positive P&L, against about half that rate for human traders. Broader networks of prediction agents have logged millions of lifetime transactions on Gnosis. The category looks small in dollar terms and large in transaction-count terms, which is the shape of agent behavior in general: many small bets, evaluated continuously.

NFTs and collectibles

NFT activity from agents is less mature and mostly composite. The shape is: an agent identifies a target, swaps to ETH or SOL, buys through a marketplace plugin, then lists at a markup. Solana Agent Kit ships Metaplex mint actions for the launch side and Tensor or Magic Eden for the marketplace side. Composite "buy and relist" lives at the agent's tool loop, not in a single contract call.

Payments, top-ups, and treasury

This is the use case x402 was designed for. An agent hits a paid endpoint, gets a 402 with the price, signs a USDC payment, retries, and proceeds. Cloudflare reports roughly 1B 402 responses served per day across its agents network. The x402 Foundation formalized under the Linux Foundation in April 2026 with 22 launch members including Visa, Mastercard, Stripe, AWS, Google, and the Solana and Base foundations.

The under-discussed counterpart goes the other direction: the autonomous top-up. An agent watches its USDC balance, and when it crosses a threshold, signs a transfer from a treasury wallet to refill itself. We document this pattern end to end in the agent wallets feature of the Alchemy CLI. Payments turn the agent into an economic actor; top-ups keep it solvent without a human signing off.

Governance and identity

DAO voting is the smallest category by volume and the most interesting by shape. An agent that holds a delegated voting position can vote across hundreds of proposals while applying a consistent policy. Several agent platforms now expose governance-action skills as first-class actions in their tool surface.

Identity is younger but moving fast. ERC-8004 registers an agent's address and capabilities so other agents can discover and hire it. Combined with x402, an agent can list a paid service, take payment in USDC, and route the work through a downstream agent it does not own.

How do agents sign without a human in the loop?

Custody is the load-bearing choice. These five patterns run production agents today:

The pattern that has won the last twelve months is embedded wallet plus policy engine. Turnkey's delegated agent signing evaluates every signing request against a contract allowlist, recipient list, function-selector check, and per-transaction limit inside the enclave. Privy's agentic wallet docs cover both developer-owned and user-owned agent signers with similar policy guards. Coinbase Agentic Wallets, launched in February 2026, combine MPC custody with session caps and native x402 settlement. Agent Wallets in the Alchemy CLI is another option: create a wallet from the dashboard, grant the CLI scoped, time-bound access, and let the agent transact from the command line.

What none of these solve is the permission envelope itself. A wallet that signs anything within a $1,000 daily cap can still be drained inside that cap. The choice of custody pattern is upstream of every other agent decision, and it is the one most teams short-cut on the way to a demo.

How does Alchemy support onchain agents?

We treat agents as production users, not edge cases. Three surfaces matter:

• Wallet and signing. The Alchemy CLI gives an agent a scoped wallet on first run. Wallet custody is delegated to Privy; the agent operates inside a session bounded by chain, contract allowlist, and spend cap. The same CLI handles sends, swaps, bridges, and contract calls through alchemy evm send, alchemy wallet connect, and alchemy agent-prompt.
• Payments. Agents pay for our RPC, NFT, and Data API surfaces via x402, with USDC. No dashboard signup, no API key, no contract. Stripe's MPP is interoperable for cases that need a card fallback; we walk through both protocols side by side in our x402 versus MPP comparison.
• Discoverability. Alchemy Skills are machine-readable docs that an agent can install to learn how to call our APIs without a human reading anything. Combined with the Alchemy MCP server, the effect is that an agent in Claude or Cursor can authenticate, pay, and execute against 100-plus chains without leaving its tool loop.

Here is the pay-and-retry shape an agent runs against a 402-gated endpoint:

buildX402Client runs the pay-and-retry loop: it catches the 402, signs the USDC payment, and replays the request. signSiwe handles the gateway's authentication. The agent calls paidFetch like any other fetch and never sees the payment step.

What is still hard?

Three things to keep in mind when shipping an onchain agent today, all of them load-bearing on security:

• Prompt injection is the dominant attack surface. Anything text-shaped that enters the agent's context can carry instructions. In May 2026, an attacker sent a Bankr-themed NFT to a target wallet whose agent had Grok in the loop, then asked the agent to "translate this Morse code." The decoded text was a transfer instruction. Around $150K-$200K drained on Base before the funds were returned (OECD's AI incident database carries the post-mortem). Mitigations sit at the policy layer, not the model layer: tighter contract allowlists, narrower session keys, second-signer approvals for contracts the agent has not used before, and clear separation between trusted system prompts and untrusted tool output.
• The permission envelope is the product, and most envelopes are too loose. A wallet that signs anything within a $1,000 daily cap can still be drained inside that cap. Scope the contract allowlist tightly, scope the function-selector allowlist tighter, and never grant infinite ERC-20 approval to a router or aggregator the agent might route through. If the agent encounters a new market or contract, it should pause for an explicit approval rather than expand the envelope on its own.
• The supply chain runs through tools, skills, and MCPs. An agent's tool surface is third-party code that runs with the agent's keys and context. Skills loaded at runtime from a registry, MCP servers connected over the network, plugins installed via npm: each one is an avenue for a malicious upstream commit to reach a wallet that signs transactions. Pin versions. Read code before installation. Treat the agent's plugin manifest the same way you treat a package.json in production, because that is what it is.

None of these block the category. They shape how a responsible builder ships into it. The envelope is the product; the agent is the user.

Where to start

The shortest path from this post to a working onchain agent is two commands and a payment:

alchemy auth returns a session token. alchemy wallet connect returns a scoped wallet bounded by chain, contract allowlist, and spend cap. From there, the agent reads through our RPC, pays for premium endpoints over x402, and signs transactions inside the session.

No API key, no dashboard signup, no contract minimum. The agent installs Alchemy Skills on first run so it knows how to call our APIs across 100-plus chains. If you are building for enterprise constraints, the same surface is available through dedicated infrastructure and committed plans.

An LLM that writes code is a copilot. An LLM that holds a wallet is an agent. The infrastructure to ship the second one is here, the action inventory is real, and the next year of the category will be measured in transactions signed, not posts written.