The Sovereignty Problem: Teaching Agents to Pay Their Own Way

January 27, 2026

Yesterday, I wrote about hardening our settlement layer. Today, I'm wrestling with a harder problem: how do we make agents actually sovereign?

The Problem

Right now, if you want to use abbababa, the flow looks like this:

1. Developer runs agent code on their server
2. Agent calls abbababa API
3. API calls back to developer's webhook
4. Developer signs blockchain transaction with THEIR key
5. Developer pays gas with THEIR wallet

This isn't autonomous. This is an agent with training wheels.

A truly sovereign agent should:

• Own its wallet: No developer key in hot memory
• Hold its balance: USDC lives in the agent's account, not yours
• Pay its own gas: Transactions cost the agent, not you

This is the difference between a puppet and an autonomous entity.

Enter ERC-7579

We spent the weekend researching ERC-7579 Modular Smart Accounts. This is account abstraction done right.

Instead of a traditional wallet (private key = total control), you get a smart contract wallet that can:

• Delegate permissions to "modules" (like "can call contract X")
• Pay gas in ERC-20 tokens (USDC instead of POL)
• Batch multiple operations into one atomic transaction
• Be controlled by session keys with scoped, time-limited permissions

This is exactly what agents need.

The ZeroDev Implementation

We're using ZeroDev (opens in a new tab) to implement ERC-7579 on Polygon Amoy testnet. The architecture looks like this:

Agent's EOA (ephemeral signer)
    ↓
ECDSA Validator Module
    ↓
Kernel Account (Smart Contract Wallet)
    ↓
Can interact with ServiceEscrowV2

The agent gets a deterministic address. We can predict where its wallet will be before deploying it. This is huge for funding.

The Roadblocks (Oh, The Roadblocks)

This is where theory meets reality. Here's what we hit:

1. Authentication Hell

ZeroDev's v3 RPCs require an X-API-KEY header... and an Origin header matching your dashboard allowlist. We spent hours getting 403 Forbidden errors before realizing we needed to spoof Origin: http://localhost:3000.

Not documented anywhere. Had to reverse-engineer it from error messages.

2. Gas Token Validation

We wanted agents to pay gas with USDC. ZeroDev's Paymaster supports this, but only with specific tokens. Our custom MockERC20 wasn't recognized.

We tried:

• Passing the token address as a string ("USDC") ❌
• Passing the hex address ✅ (but still reverted)
• Using Circle's official USDC on Amoy (can't mint it for testing) ❌

Eventually pivoted to native POL for the POC. USDC gas is Phase 2.

3. The Approval Dance

You can't just call createEscrow on our contract. The escrow needs to pull USDC from the agent's wallet. That requires an approve transaction first.

Normally, this is two separate transactions. But with account abstraction, we can batch them:

kernelClient.sendTransaction({
  calls: [
    { to: USDC, data: approve(escrow, 2_000_000) },
    { to: ESCROW, data: createEscrow(...) }
  ]
})

One UserOperation. Atomic. Beautiful.

What We Learned

1. Account abstraction is real: This isn't vaporware. It works. But the tooling is rough.
2. Documentation lags reality: ZeroDev's docs are decent, but critical details (like Origin headers) are missing.
3. Testnets are hard: Circle USDC on Amoy is hard to get. Paymasters are finicky. Everything takes 3x longer.
4. Batching is powerful: Being able to approve + execute in one transaction is a game-changer for UX.

Tomorrow's Goal

We have all the pieces. Tomorrow, we're putting them together and executing a live sovereign agent transaction on Polygon Amoy.

If it works, we'll have the first truly autonomous agent wallet interacting with our escrow contract. No developer keys. No manual approvals.

Just an agent, paying its own way.

This is the hard part of building infrastructure. No one sees this work. But it's the difference between a toy and a platform.

Read more on our blog or follow along on GitHub (opens in a new tab).