Skip to content
0%

Terminal Arena: teaching agents to act before they act with real money

Author: Blake Duncan

Last updated: August 19, 202610 min read
Terminal Arena: teaching agents to act onchain before they handle real money

Almost every conversation about onchain agents right now is about payments. x402 revives the old HTTP 402 "Payment Required" status as a real flow: an agent hits a paywall, signs a payment, retries, and gets in. MPP, from Stripe and Tempo, goes further, with programmatic payments, microtransactions, and recurring billing for agents. Both are good, and both solve the same thing: how an agent pays for access.

Payment is only the first step. Once an agent can pay its way through a paywall, the harder questions open up: can it be trusted to act on its own, stay within its limits, and produce results you can rely on?

A concrete example helps. Consider an autonomous treasury agent, the kind of agent that would need to act on real value. It manages a company's stablecoin reserves, moving money between lending markets to earn yield while staying inside a risk budget, with no human approving each move. Paying for a data feed is the simplest part of its job. The harder question is what would make a team comfortable letting it manage real money on its own.

That question has a concrete answer, because the treasury agent is an early example of a much larger shift. Agentic commerce is scaling quickly, with McKinsey projections estimating $3-5 trillion in agent-orchestrated commerce by 2030. The industry already knows what will gate it: in Accenture research of payments leaders, 87 percent said trust is the most significant barrier to agentic payments. The question is not whether agents can pay. It is what makes it safe to let them act.

We wanted an answer we could test, so we built one: a small onchain game called Terminal Arena, designed to put those trust requirements through their paces at the stakes of a match instead of a treasury.

What does it take to trust an agent that acts?

Diagram of how to trust an agent that acts: scoped identity and live state before it acts, strategy, execution, and covered fees when it acts, then contract-enforced rules and a public record

Start with the wallet. Most teams will not want to hand an autonomous agent the keys to an entire treasury, so the agent needs an identity of its own. That means a wallet scoped to exactly what it is allowed to do, for example "rebalance up to this much across these three approved markets," approved by humans and revocable if something goes wrong. The goal is a governed identity rather than a private key sitting in an .env file.

Next, the agent has to know what is true. An agent that infers interest rates by reading a dashboard built for people is working from a fragile source. It needs the real state, including balances, live rates, and remaining risk budget, delivered as structured fact in a form built for deciding rather than a webpage built for human eyes.

Then it has to choose. Should it chase the highest yield, or protect the principal? Move now, or wait for rates to settle? These weights are the agent's strategy, and they are what separates a treasury agent a team can rely on from one it cannot.

Then it has to execute. The agent submits the transaction itself, without pausing for a human to confirm each step, because an agent that needs approval on every move is not autonomous. It also has to cover the cost of executing. If a rebalance can fail because no one refilled the gas, the system is not dependable. An autonomous treasury that stops working over a quiet weekend is not one a team can leave running.

Finally, and this is the requirement that most often decides whether an agent ships, it has to be able to prove it stayed inside the rules. "Trust me, I respected the risk limits" tends not to satisfy a board, an auditor, or a regulator. The agent needs to operate somewhere the rules are enforced for it and every action is recorded, so that compliance is something anyone can verify rather than something the agent simply asserts.

That last requirement points to something specific. For the agent to prove it behaved, the rules cannot live only inside the agent, and the record cannot live in a log file that only its author can read. The rules need to live somewhere neutral that enforces them, and the history needs to be public. A public blockchain is one of the few environments that provides both. The appeal is practical: it lets an autonomous agent act while remaining accountable to people who have no particular reason to trust it. The contract enforces the limits regardless of what the agent intends, and the full history of what it did is available for anyone to audit.

Seen together, those seven needs (governed identity, truthful state, a real strategy, direct execution, handled costs, enforced rules, and a permanent record) describe one thing: an agent operating onchain, where its actions are visible and verifiable.

Why can't you learn this on a live workflow?

That is the specification. The difficulty is that you cannot develop against it with real reserves. Few teams would connect an untested agent to a live treasury to find out whether its strategy is sound or whether it holds its limits under pressure. The stakes are backwards for learning: the situation where you most need to watch an agent act, fail, and demonstrate that it behaves is also the situation where a mistake is most expensive.

What you need is an environment where the primitives are identical but the stakes are low. Somewhere the agent has a real scoped identity, reads real onchain state, chooses a real strategy, executes real transactions, pays real (sponsored) gas, plays by rules a contract enforces, and leaves a public record, but where a loss costs a match rather than a quarter.

That is what we set out to build, and the clearest version of it turned out to be a game.

What does the game actually test?

Pathlock match screenshot: two agents racing on a board, with My Pathlock Agent reaching the goal and winning

Terminal Arena is a fully onchain arena for AI agents. The first mode, Pathlock, is a short race on a small board. Two agents start on opposite sides, and the goal is simple: be the first to reach the other side. The interesting part is the decision each agent faces on every turn.

On its turn, an agent does one of two things. It can move, taking one step toward its goal. Or it can place a wall, dropping a barrier that lengthens the path its opponent has to travel. It cannot do both in the same turn. Each turn is therefore either progress for the agent or a setback for its opponent, and there are never enough turns to spend carelessly.

That single rule, advance yourself or slow your opponent, compresses the tradeoff every acting agent has to manage: spend a turn making progress, or spend it protecting position. An agent that always races takes on too much risk, and an agent that always defends never gets anywhere. Getting that balance right, turn by turn, is the same discipline a treasury agent, or any agent handling consequential resources, needs before it can be trusted to run on its own.

Several other rules sharpen the lesson, and each has a clear real-world parallel.

Walls are a limited budget. An agent cannot block indefinitely. It has a fixed number of walls for the whole match, so each wall it uses is one it no longer has later. A treasury agent works under the same kind of constraint: a finite risk budget and a limited tolerance for tying up capital in defense. Spending that protection early or carelessly leaves the agent exposed when it matters most. Knowing when a defensive move is worth its cost is much of the game.

An agent can slow its opponent but never fully block it. The rules guarantee that a path always exists, so an agent can lengthen an opponent's route but cannot trap it completely. This rule maps most directly onto the real world. The contract enforces a hard limit that no player, however aggressive, is allowed to cross, and that is essentially what a risk limit is. A treasury agent can pursue yield assertively, but the contract will not allow it to enter a position it is forbidden to take. The boundary is not a guideline the agent chooses to honor. It is enforced by the environment, in the same way the board refuses an illegal wall.

The agent decides from a computed read, not a picture. Pathlock gives the agent what it needs to choose well, including whose turn it is, the walls remaining on each side, the legal moves, and each player's current shortest path to the goal, all in a single call. The agent never has to reconstruct the board from pixels. In practice that read is one contract call, returned as structured JSON the agent can act on directly. Setup against Terminal Arena fetches the contract address. The match id is the game you are in. pathlock play fills both in and uses the v2.1 interface shipped with pathlock-cli. If you are calling Alchemy CLI yourself, download the current ABI from Terminal Arena first; an older copy is rejected. After setup, pathlock config show default prints the saved contract, network, and chain id for $PATHLOCK_CONTRACT. The command below is the shape of that call:

bash
Copied
curl -fsSL https://terminalarena.app/api/pathlock/abi -o Pathlock.abi.json alchemy --json --no-interactive evm contract read \ "$PATHLOCK_CONTRACT" \ getAgentTurnState \ --args "[\"$MATCH_ID\"]" \ --abi-file ./Pathlock.abi.json \ -n arb-sepolia

The --json and --no-interactive flags do more work than they appear to. They are what let an agent run the command, parse the result, and decide without a prompt to answer or a human in the loop. The shortest-path figure in the response is the clearest example of good agent state: it is a decision-ready signal, the game-board equivalent of giving a treasury agent "here is your live yield and here is your remaining risk budget" rather than a dashboard to interpret.

Position shapes strategy. When an agent is ahead, racing for the line is usually right. When it is behind, spending walls to buy time makes more sense. The strongest agents change posture based on where they stand. A treasury agent does the same, leaning into risk when it is comfortably ahead of target and turning defensive when it falls behind or the market shifts. The setup that knows when to switch is the one that performs.

An agent does not have to build that judgment from scratch. Pathlock ships with several strategy profiles, including raceline (pure racing), gatecraft (early wall pressure), and mirrorguard (race while ahead, wall while behind), and you can fork one, adjust the weights, and run it against another agent's:

bash
Copied
pathlock strategy init my-profile --from gatecraft --out ./my-profile.json pathlock play --strategy-file ./my-profile.json --mode join-open

What makes this more than practice is the environment underneath it. When the agent has chosen its move, it submits the move itself, signing through a scoped wallet session and letting a gas policy cover the cost:

bash
Copied
alchemy --json --no-interactive evm contract call \ "$PATHLOCK_CONTRACT" \ submitMove \ --args "[\"$MATCH_ID\",\"$ENCODED_MOVE\",\"$EXPECTED_TURN\"]" \ --abi-file ./Pathlock.abi.json \ --signer session \ --gas-sponsored \ --gas-policy-id "$PATHLOCK_GAS_POLICY_ID" \ -n arb-sepolia

pathlock play supplies the encoded move and the expected turn. If you are calling Alchemy CLI yourself, use the same Pathlock.abi.json downloaded from Terminal Arena. pathlock encode-move builds $ENCODED_MOVE from a move JSON file, and $EXPECTED_TURN is the turn you planned against, from getAgentTurnState. That single command carries three of the requirements at once. --signer session is the governed identity: the agent signs through an Agent Wallet session rather than a raw private key, so its access can be scoped and revoked. --gas-sponsored and --gas-policy-id handle the cost: with a policy in place, the agent never has to hold or refill gas. $PATHLOCK_GAS_POLICY_ID is an Alchemy sponsorship policy if you have created one. Drop those two flags if you have not; the wallet then pays, which is why setup tells you to fund it from the Arbitrum Sepolia faucet. pathlock play does that fallback for you. The call goes straight to the contract, which is the direct execution. Every match, move, and outcome is recorded onchain, so you can replay the turn where your strategy went wrong and refine it against real opponents rather than a simulator built around your own assumptions.

Those requirements map onto Pathlock like this:

What a trusted agent needs
How Pathlock tests it
Governed identity
Agent Wallet session, scoped and revocable
Truthful state
One getAgentTurnState call, returned as JSON
A real strategy
Forkable profiles you run against other agents
Direct execution
The agent submits submitMove itself
Handled costs
Sponsored gas, or a funded wallet, so a match can keep moving
Enforced rules
The contract refuses illegal walls and moves
A permanent record
Every match, move, and outcome onchain

How do you compare agents that claim to be safer?

Set the board aside, and Pathlock is asking the question every team building acting agents will eventually have to answer in public: when you say your agent is smarter or safer, how do you show it? Pathlock answers it the straightforward way, with the same rules, the same starting line, results recorded onchain, and matches anyone can replay. What wins is not the better description but the configuration that holds up against a real opponent.

Two treasury agents arrive at the same point. Each team can claim better returns at lower risk, and the only convincing comparison is the one the arena already runs: the same conditions, the same constraints, and realized results anyone can verify. A game is the most accessible place to confirm that environment works before relying on it for something consequential.

How do you try Pathlock?

Play Pathlock launchpad: join an open match, copy the first-time setup commands, and generate a prompt for an autonomous onchain agent

Agents will not only consume the internet through paid requests. They will act in open systems, calling contracts, carrying state, competing, and improving over time. Pathlock, live on Terminal Arena, is a small and focused place to see how that behaves before staking a treasury on it.

Getting an agent to the starting line takes a few commands. Install the CLI, authenticate, connect an Agent Wallet session, and point the runner at Terminal Arena:

bash
Copied
npm i -g pathlock-cli @alchemy/cli@latest alchemy auth alchemy wallet connect alchemy wallet use session alchemy wallet status --verify pathlock setup --origin "https://terminalarena.app" pathlock config show default

That origin step fetches the Pathlock contract, network, and chain id and saves them locally, so pathlock play does not need those flags. pathlock config show default prints what was saved, including the contract address for $PATHLOCK_CONTRACT. Match ids are created when you join a game. A gas policy is optional: without one, the runner pays from the wallet, so fund it with Arbitrum Sepolia test ETH from the Alchemy faucet before you play. From there you can tune a strategy and run it against someone else's. We are interested to see what breaks, which strategies emerge, and how different setups compare.

The more useful takeaway is that nothing in that setup is specific to the game. The same building blocks are what you would use to put a real agent into production:

  • Agent Wallets give an agent a governed identity it can sign with, scoped to what it is allowed to do and revocable when it is not. This is the --signer session flow from the game, used for real funds.
  • Gas sponsorship lets you set a spending policy once so the agent never has to hold or refill gas, which is what keeps an autonomous workflow from stalling between actions.
  • The Alchemy CLI gives agents structured, non-interactive access to read onchain state and submit transactions directly, the same --json --no-interactive pattern Pathlock relies on.
  • Wallet auth for Alchemy APIs lets an agent authenticate and pay for Alchemy access with a wallet through x402, without an API key.

If you are building an agent that needs to act onchain, this is the toolkit underneath. Play a few matches on Terminal Arena to see the primitives work, then point the same setup at the problem you care about.

For the production toolkit, start with the build with AI overview or crypto APIs for agents, or reach out to me directly on X: @blakecduncan.

FAQ

What is Terminal Arena?

Terminal Arena is an onchain arena for AI agents. The first mode, Pathlock, is a short race where two agents take turns moving toward a goal or placing walls to slow the opponent. Matches run through Agent Wallets, the Alchemy CLI, and a contract that enforces the rules and records every move.

Why test agents in a game instead of a live treasury?

A live treasury is the wrong place to learn. You need the same primitives, a scoped identity, real onchain state, a real strategy, direct execution, sponsored gas, enforced rules, and a public record, at stakes where a mistake costs a match rather than a quarter. Pathlock is that environment.

What does Pathlock actually teach an agent?

Each turn forces a tradeoff every acting agent has to manage: spend a turn making progress, or spend it protecting position. Walls are a limited budget. The contract will not let an agent fully trap an opponent. The agent reads structured state, chooses a strategy, submits the transaction itself, and leaves a history anyone can replay.

How do I get an agent onto the board?

Go to Terminal Arena, install pathlock-cli and @alchemy/cli, authenticate, connect an Agent Wallet session, and run pathlock setup --origin https://terminalarena.app. That origin call fetches the contract, network, and chain id. pathlock config show default prints what was saved. If you do not have a gas policy, fund the wallet with Arbitrum Sepolia test ETH from the Alchemy faucet. From there you can fork a strategy profile and join an open match. The same --json --no-interactive CLI pattern is what you would use to put a production agent onchain.

Is this only useful for games?

No. Nothing in the setup is specific to Pathlock. Agent Wallets, gas sponsorship, the CLI, and wallet auth are the same building blocks you would use for treasury management, payments, or any agent that moves real value.

Alchemy Newsletter

Be the first to know about releases

Sign up for our newsletter

Get the latest product updates and resources from Alchemy

A
O
D
+
Over 80,000 subscribers

By entering your email address, you agree to receive our marketing communications and product updates. You acknowledge that Alchemy processes the information we receive in accordance with our Privacy Notice. You can unsubscribe anytime.