Wallet Rotation Quietly Breaks Your Spend History

Rotation is the right call, and it has a cost

Teams that run agents with onchain wallets rotate addresses for sound reasons. A key sat in an environment variable too long. A contractor had access. A deploy pipeline makes a fresh wallet for every release. Some setups give each task or customer its own address so funds and blast radius stay separate.

None of that is wrong. The trouble is that most spend tracking, including the one-off scripts teams write themselves, is keyed on the address. When the address changes, the history stops. The new wallet starts at zero spent, zero alerts fired, and no baseline to compare against.

What actually goes missing

Three things disappear when an agent moves to a new address.

The first is cumulative spend. If your daily cap is 200 USDC and the agent spent 180 from the old wallet before rotation at 14:00, the new wallet shows 0 spent. The agent can spend another 200 before anything trips. Your real daily outflow is now 380.

The second is the baseline. Anomaly thresholds only make sense against normal behaviour. A wallet created an hour ago has no normal. A spike looks like the first data point.

The third is the audit trail. When finance asks what the research agent spent in September, the answer sits across four addresses on two chains, and nobody wrote down which address belonged to which agent in which week.

Why this happens more on agent fleets than human wallets

A person might rotate a wallet once a year. Agent fleets rotate far more often, usually without anyone making a decision. Infrastructure-as-code rebuilds a signer. A container restart comes up with a freshly generated key because the old one was never persisted. A Solana setup spins up a new keypair per job to avoid account contention.

Each of these is invisible to anyone watching spend. The old address goes quiet, and a quiet address looks like a healthy one. The new address was never added to monitoring, so its spending isn't watched at all.

This is the specific failure: nothing alerts, because the one thing being watched stopped moving.

Budget the agent, not the address

The fix is conceptual before it is technical. A budget belongs to an agent or a job, not to a public key. An address is just where that agent's money happens to sit right now.

In practice that means keeping a small mapping: agent name, the set of addresses it has used, and the time range each was active. Caps and alerts are worked out across the whole set. Rotation then adds an address to the group instead of starting a new history.

This mapping costs almost nothing to keep, and it is the piece most teams skip. Write it down in the same change that creates the new key.

Detecting rotations you did not plan

Unplanned rotations are the dangerous ones, and you can catch them from the chain side without touching any keys.

Watch for an address that was spending regularly and then goes completely silent. A sudden drop to zero is as much a signal as a spike, especially if the agent's upstream job is still running.

Watch the funding path. New agent wallets almost always get their first balance from a known treasury or hot wallet. A transfer from treasury to an address you don't monitor is a strong hint that a new signer just came online. On Base that is usually a USDC transfer. On Solana, look for SOL for fees plus a token account being created for the stablecoin.

Watch for leftover balance on the old address. A rotation that leaves funds behind is both a small loss and proof that the move was not deliberate.

A rotation checklist that fits in a pull request

Before the new key is live: add the new address to the same budget group as the old one, on the right chain.

At cutover: note the timestamp so spend can be split correctly between the two addresses for that day.

After cutover: sweep what is left on the old address back to treasury, then keep the old address monitored for at least one full billing cycle. Late settlements and retried payments can still land there.

Finally, check that the cap still reflects combined spend. The easiest test is to compare the group total against what the agent's job logs say it paid for.

Where GetAgentCap fits

GetAgentCap watches any address you give it on Base or Solana, builds a live ledger from the chain, and sends threshold alerts. There is no SDK and no key access, so adding a freshly rotated address is a paste, not a deploy.

That makes it cheap to follow the practice above: monitor every address an agent has used, keep watching the retired ones for a while, and read spend per agent instead of per key.

Rotation is good security. It just shouldn't reset your view of what your agents are spending.