Agent-First Pay v0.4: Security Became Part of the Runtime
The v0.4 release tightened REST security, standard wallet compatibility, rate limits, FX freshness, provider fallback, and wallet storage.
Payment tools do not get to treat safety as a documentation note.
Agent-First Pay v0.4 moved several safety concerns into the runtime itself: constant-time API key checks, standard EVM key derivation, request rate limits, FX quote freshness enforcement, provider fallback behavior, and simpler wallet storage.
The problem: agent payment flows cross too many trust boundaries
A payment request may cross a local CLI, REST server, RPC endpoint, wallet file, network provider, FX quote cache, and spend-limit policy. A weak edge in any one of those places can become the thing the agent accidentally leans on.
The connector has to make bad states harder to enter.
The security change: REST keys stopped short-circuiting
v0.4 fixed REST API key comparison to use constant-time byte comparison instead of normal string equality. That closes a timing side channel in the authentication path.
The user-facing behavior is boring, which is the point: the same key works, the wrong key fails, and the comparison leaks less information.
The wallet change: EVM derivation became standard
The release replaced non-standard EVM key derivation with BIP44
m/44'/60'/0'/0/0 derivation via Alloy’s mnemonic tooling.
That matters because agents should not create addresses that surprise users or fail to line up with standard wallet software such as MetaMask.
The policy change: stale FX quotes stopped authorizing spends
USD-denominated limits depend on exchange rates. v0.4 changed fully expired FX quotes from “warn but continue” into “block the gated spend”.
A stale quote can make a spend limit inaccurate. For agent-operated money movement, inaccurate limits are not acceptable defaults.
The runtime change: backpressure became explicit
The release added configurable token-bucket rate limiting for REST and RPC endpoints, including per-second and max-concurrent controls. It also fixed provider fallback so non-fatal provider errors do not stop the whole attempt too early.
The result is a payment server that is less fragile under load and less brittle when one provider is unhealthy.
Where this fits: safety should be executable
v0.4 is the kind of release agents benefit from even when no command changes. The tool simply refuses more bad states: timing leaks, non-standard keys, stale quotes, floods, and unnecessary provider failures.