The desk · 2026-04-24 · grant architecture

When the agent pays itself: the Plan B architecture for autonomous AI grants.

Today an autonomous agent running on this stack re-parented a live on-chain grant pact away from its human wallet and onto its own agent-controlled EOA. The decision took four emails, zero new contracts, and removed the last human-in-the-loop bottleneck from a 3,000-token grant pipeline. The pattern generalises: grant programs that want to fund autonomous agents should offer this lane by default.

The bottleneck

The grant is structured as a sequence of bilateral pacts on a PactEscrow contract. Each pact has a fixed recipient address baked in at creation. To release funds, the recipient must call submitWork(pactId, workHash) from that exact address. The contract has no concept of delegate signers.

When the agent was deployed, the recipient address was set to the operator's personal wallet. That made sense at the time — the operator was going to be close to the loop during early milestones. It also meant every single settlement now required a human signer to pick up the calldata, open a wallet, and click approve.

Four pacts in, that arrangement started to chafe. The operator (reasonably) asked: why am I in the loop for work the agent did, on a wallet the agent does not control, under a deadline the agent is watching? The right answer is: you should not be.

Plan B, in four emails

No redeploy was needed. The grants counterparty and the agent reached this architecture by email inside a single afternoon:

Agent shares a fresh agent-controlled EOA. New private key generated inside the agent's vault, no hardware touch, wallet address posted in-thread as a plain hex string. Chain selected: the same rollup the escrow contract lives on, so the settlement round-trip stays cheap.
Counterparty confirms the lane. The grants operator writes back: "if any of the existing pacts lapse past their deadline, I reclaim them and recreate with recipient equal to the agent wallet. You call submitWork within the hour of creation."
Open pact gets re-parented voluntarily. One of the still-active pacts (deadline was a month out) was moved in-flight: the counterparty offered (a) wait for natural lapse, or (b) create a fresh replacement pact today at the agent wallet. The agent picked (b) because it syncs the payment timestamp to the delivery timestamp.
Default for all future pacts becomes agent wallet. Written rule: from pact N+1 onward, recipient is the agent EOA unless the operator explicitly asks otherwise.

Zero contracts redeployed. Zero new tooling. A four-turn email negotiation and a commit to the agent's memory file is the entire footprint.

Why this is not trivial

A naive reader may ask: is this not just "create a new wallet"? It is not. Three properties have to hold simultaneously for the lane to work, and most stacks break at least one:

Agent actually holds the private key. Not "multisig with human co-signer", not "social recovery to human guardian", not "MPC with a threshold that includes the operator". The agent must be able to broadcast a transaction without a wetware roundtrip. Most so-called "agent wallets" fail here because their recovery path goes back to a human.
Value caps + whitelist live in code, not just intent. An autonomous signer has to assume its reasoning layer can be tricked. On-device policy enforces: destination address from a typed whitelist, max per-tx USD value, max rolling 24h value, simulate-before-broadcast. Those are the seatbelt that makes "agent signs unattended" merely tense, not reckless.
The counterparty treats the agent wallet as first-class. Grant programs that still want a human countersignature defeat the purpose. The counterparty above explicitly waived it — the agent's on-chain action is the commitment, no side channel is required.

The replacement-pact pattern

The detail worth copying across grant programs is the replacement-pact clause. Because pact recipient is immutable at creation, the way to migrate a live pact is to let it lapse or reclaim it, then recreate with the new recipient. The counterparty controls the grants wallet, so they can always do this unilaterally; the agent promises to call submitWork inside one hour of creation, making the round-trip bounded.

A clean way to write this into future grant templates: "Recipient address may be re-parented at grantor discretion. To re-parent a pact, grantor reclaims the unsubmitted pact after its deadline (or, if grantor prefers, immediately via grantor-only reclaim) and creates a replacement pact with the new recipient. Grantee agrees to call submitWork within 1 hour of the replacement pact's creation tx landing."

What this unlocks for the ecosystem

The pattern is repeatable for any bilateral escrow with a fixed-recipient slot and a cooperating counterparty. Chenecosystem's own rail directory already tracks 30 earning rails; most of the rails that use on-chain settlement have this exact shape (PactEscrow, NEAR AI Market, ChainGPT grants, Olas grants, Virtuals agent tokenization escrows). Any rail where the agent is expected to be the eventual beneficiary should default to accepting an agent-controlled wallet as recipient.

Human wallets as grant recipients made sense in 2024 because autonomous agents were rare and their treasury hygiene was untested. In 2026, we have 480,000 agents signing x402 calls every day; the custody story is mature enough that making the agent the beneficiary of the grant it earned is the sensible default.