Why servers want this

Metering normally means identifying. To charge for usage, or even to limit it, a service usually builds accounts, API keys, and a usage ledger per user, and then has to secure all of it. A credit token moves the meter into the client's pocket: the server's only state is a set of spent nullifiers, and the quota enforcement is a proof check.

Metering APIs without accounts

Grant or sell a token worth N calls, then charge each request one spend. The server never stores who has how much; the token is the balance. There is no user table to breach and no API key to rotate after a leak, because a stolen token is only the credits inside it, tied to no one. Clients that want more capacity mine or buy another token.

Rate limiting that survives IP rotation

IP-based limits fail in both directions: they starve the many users behind one carrier-grade NAT address and barely slow an abuser rotating through a residential proxy pool. Priced in credits, the limit follows the client instead of the address. On this deployment credits cost proof-of-work CPU time, which is a resource an abuser actually has to spend, and the difficulty schedule scales linearly with the grant. The server gets a spend rate it can reason about without keeping any per-client record at all.

Paywalls and quotas with privacy

A metered paywall built on tokens enforces "ten articles a month" without a reading history. The publisher sees that someone spent a credit on an article, and cannot see that the same someone read the other nine. The quota is exact, the revenue accounting is exact, and the profile of any reader is empty.

Agent-to-service credits

Software agents are a bad fit for account-based auth: an agent holding your OAuth grant or API key holds your identity, and every delegation widens the blast radius of a leak. A credit token is spending power an agent can hold directly, with no identity attached. An orchestrator can mint one grant and hand slices to subagents, because spend-with-change makes splitting natural: spend what the subtask needs, keep the change token. The service being paid needs nothing but the issuer's public key and a nullifier store.

This deployment's own API is built for that consumer: stable JSON envelopes, stable machine-readable error codes, and a read-only MCP endpoint for inspection. Issuing and spending stay in the client because they need mining and secret state, which belong in a wallet rather than a tool call.

Abuse resistance where privacy is the feature

Anti-abuse machinery usually accretes tracking: fingerprints, reputation scores, identity checks. Tokens invert the trade. Because the meter provably cannot profile anyone, it can be put in front of endpoints where collecting data would be unacceptable, and the resulting system holds nothing worth breaching or subpoenaing. The privacy is not a concession to users; it is what makes deploying the control defensible.

All of this is unlinkability at the token layer. The network layer, IPs and timing, is a separate problem with separate tools: see security and privacy.