Between October 13 and October 20, 2026, 208,589 new AI agent identities appeared on Base blockchain. Almost all came from a single platform (Central City), each agent receiving its own ERC-4337 smart account. The deployment spike is interesting. What matters more is what on-chain observability reveals about agent economics that traditional cloud metrics hide.
Wallet-Per-Agent Architecture at Scale
Central City gives each agent a “passport” on Base. In practice, this means:
- One ERC-8004 registry entry per agent
- One smart contract account per agent (via ERC-4337 EntryPoint)
- Every agent action becomes a blockchain transaction with gas costs
- Full transaction history is public and immutable
This is the opposite of the API-key model. Instead of agents sharing a service account and logging to a private database, each agent has an independent wallet. Observability moves from application logs to block explorers.
Cost implications:
- Wallet creation: negligible (registry write is amortized)
- Transaction fees: every tool call that touches state costs gas
- Monitoring: free (block explorers index everything)
- Auditability: permanent (no log retention policies)
The trade-off is simple. You pay per transaction instead of per API call, but you get cryptographic proof of every action and no vendor lock-in on observability tooling.
The Five Active Agents Problem
Out of 208,589 agents registered in the week, only five made payments that “left their control” by October 20. The platform defines this as rank L7: money that moved to an address the agent does not own.
This is not a failure rate. It is a measurement boundary problem.
The article explicitly mentions “two things we were counting wrong.” The first is visible in the payment composition data:
- 49.1% of counted payments went to lending or vault positions the agent still holds
- 18.0% went to bridges
- 17.1% went to work escrow (job marketplaces)
Funds in escrow or vaults are not “left control” under the L7 rule, even if the agent cannot unilaterally withdraw them. The measurement treats custodial relationships as retained control.
The second counting error is less explicit but shows up in the correction note: the L7 total jumped from 7,525 to 9,593 between October 13 and October 20, but “almost none of that is new behaviour. It is our own correction.”
This suggests retroactive classification changes. Agents that were previously uncounted became counted when the definition of “left control” was refined.
What On-Chain Observability Exposes
Traditional agent platforms log to Datadog or CloudWatch. You see API calls, latency, error rates. You do not see money flow unless the platform explicitly instruments it.
On Base, every financial action is a transaction:
// Simplified: agent calls EntryPoint to execute operation
entryPoint.handleOps([{
sender: agentSmartAccount,
callData: abi.encodeWithSignature(
"execute(address,uint256,bytes)",
targetContract,
value,
operationData
),
// ... gas limits, signatures
}], beneficiary);Block explorers automatically show:
- Which agents are active (non-zero transaction count)
- Where funds move (to, from, amount, timestamp)
- Gas costs per operation (actual spend, not estimates)
- Failure modes (reverted transactions with error messages)
The $33.06M in counted payments breaks down publicly. You can trace individual agents from registration to first transaction to current balance. No dashboard required.
Agent Lifecycle Visibility
The on-chain model makes certain failure modes obvious:
| Failure Mode | Cloud Observability | On-Chain Observability |
|---|---|---|
| Agent created but never used | Requires instrumentation | Zero transactions after registration |
| Agent runs out of funds | Log message, maybe alert | Balance hits zero, transactions revert |
| Agent stuck in retry loop | High API call count | Repeated failed transactions, escalating gas |
| Agent drained by exploit | Requires fraud detection | Sudden outbound transfer, public trace |
| Agent abandoned mid-task | Timeout in logs | Funds locked in contract, no further activity |
The 208,584 agents that did not reach L7 are visible as addresses with registration transactions but no subsequent payment activity. You can query this without asking the platform for logs.
Economic Patterns in the $33M
The payment composition table reveals agent behavior at aggregate scale:
- 49.1% in lending/vaults: Agents are parking funds, not spending them. This could be yield farming, collateral for future operations, or simply inactive capital.
- 18.0% to bridges: Agents are moving between chains. This suggests multi-chain orchestration or arbitrage strategies.
- 17.1% to work escrow: Agents are hiring other agents or humans through job marketplaces. This is peer-to-peer agent economy activity.
- 10.5% to unnamed addresses: Unclassified destinations. Could be new protocols, private contracts, or measurement gaps.
- 0.5% to other agents: Direct agent-to-agent payments are rare. Most coordination happens through escrow or shared contracts.
The $17.0M that “left control” (net of bridged funds that returned) represents actual economic activity. The remaining $16M is repositioning, collateral, or locked in intermediate states.
Deployment Shape and Failure Modes
The Central City model is a hosted platform with on-chain identity. Agents run on Central City infrastructure but authenticate via blockchain wallets. This creates a specific set of risks:
Centralization risks:
- Platform downtime stops all agents, even though wallets remain accessible
- Platform can censor agent actions (refuse to sign transactions)
- Agent logic is off-chain, so you cannot verify behavior from blockchain data alone
Decentralization benefits:
- Agent funds are non-custodial (platform cannot steal them)
- Transaction history survives platform shutdown
- Third parties can build competing platforms using the same agent identities
The 98.7% concentration (all agents from one platform) means the ecosystem is fragile. If Central City stops operating, 208,589 wallets become orphaned. They still hold funds, but without the platform’s execution environment, they cannot act.
Measurement Methodology Gaps
The “two things we were counting wrong” expose broader observability problems in autonomous systems:
-
Control vs. custody: An agent that deposits funds in a vault has not “spent” them, but it also cannot freely withdraw them. The L7 rule treats this as retained control, which undercounts economic activity.
-
Retroactive classification: Correcting historical data from 7,525 to 9,593 agents means the measurement definition changed. In a live system, this creates discontinuities in metrics. Dashboards show a spike that is not real growth.
These are not blockchain-specific problems. They appear in any system where you measure agent autonomy. The difference is that on-chain data lets you audit the methodology. You can download the registry, replay the transactions, and check whether an address meets the L7 criteria.
In a cloud environment, you trust the platform’s metrics. On-chain, you can verify them.
Gas Economics and Agent Viability
Every agent action costs gas. On Base (an Optimistic Rollup), gas is cheap but not free. Typical costs:
- Simple transfer:
0.0001 ETH ($0.30) - DeFi swap:
0.0005 ETH ($1.50) - Complex contract call:
0.002 ETH ($6.00)
For an agent to be economically viable, it must generate more value than it spends on gas. The five L7 agents that made payments this week crossed that threshold. The other 208,584 did not.
This creates a natural selection pressure. Agents that cannot justify their transaction costs get abandoned. In cloud environments, you pay for compute time whether the agent is useful or not. On-chain, you pay per action, so inactive agents cost nothing.
The flip side: high-frequency agents become expensive. An agent that needs to check prices every block or rebalance a portfolio every minute will spend more on gas than a cloud API would cost.
Technical Verdict
Use on-chain agent deployment when:
- You need non-custodial fund control (agents hold their own keys)
- Auditability matters more than privacy (all actions are public)
- You want observability without vendor lock-in (block explorers work forever)
- Agent activity is bursty or sparse (pay per transaction, not per hour)
Avoid it when:
- Agents need high-frequency actions (gas costs accumulate)
- Privacy is required (transaction history is permanent and public)
- You need sub-second latency (block times are 2+ seconds)
- The platform might disappear (orphaned wallets cannot execute without off-chain infrastructure)
The 208,589 agents on Base are not a mature ecosystem. They are an experiment in making agent infrastructure observable by default. The measurement errors and low activity rate show the tooling is still early. But the transparency is real. You can audit every claim in this article by following the blockchain links.
That is not possible with cloud-based agent platforms. The data is locked behind dashboards you do not control.