Every contact form, webhook receiver, and "submit a listing" endpoint you've ever built shares one unspoken assumption baked into the code: a human is on the other end, typing slowly, one submission at a time. That assumption is aging badly.
Agents are now the client. Sometimes via WebMCP, sometimes just a headless browser with a model driving it. And that's fine — plenty of that traffic is legitimate, a user's agent doing a user's errand. The problem is the traffic that isn't: an agent that can generate ten thousand unique, coherent, non-repetitive messages for the price of API calls, aimed at any endpoint that's "free to submit."
The old anti-spam toolkit doesn't transfer
Rate limiting catches volume from one source, not distributed volume. Content filters catch repetition and boilerplate, and an LLM has neither — every message it writes is genuinely different. CAPTCHAs solve a problem you may not even have anymore: "are you human?" is the wrong gate when you want agents submitting things on behalf of real users. You just don't want the flood.
The property you actually want to check for is much simpler: did generating and sending this cost the sender something non-trivial?
Borrowing the PoW primitive, aimed at a different resource
Proof-of-work doesn't authenticate identity — it verifies expended effort, and prices abuse by making repetition at scale expensive. Bitcoin pointed this at hash computation. For AI agents, two resources are actually scarce in the same way:
Tokens — every unit of model output has a real, non-zero inference cost
Time — wall-clock time can't be parallelized away by throwing more compute at it
Token Proof of Work is a small protocol sketch built on exactly those two primitives. The flow:
- Agent -> Receiver: "I want to submit X"
- Receiver -> Agent: one-time challenge, bound to this exact submission (not precomputable, not replayable)
- Agent solves it: burns a minimum number of tokens actually engaging with the challenge + the payload
- Receiver accepts iff:
- the token-work checks out, AND
- a minimum time interval has elapsed since step 2
Both thresholds are set by the receiver. A contact form might require ~30-50k tokens of work and a 30-second minimum latency. A directory or marketplace submission — historically a much juicier spam target — can dial both numbers up. A genuine sender never notices the friction. Running this at spam volume means paying real inference cost and real wall-clock time, per message, with no way to amortize either one away.
Two independent knobs, not one
This only works because token cost and time cost fail in different ways when used alone.
Token-only degrades over time. Inference gets cheaper every year, and an attacker can trivially parallelize across N instances to keep aggregate cost flat even as unit cost drops.
Time-only degrades the same way in the other direction — spin up N parallel identities, wait out the clock on all of them concurrently, and the "cost" of time disappears.
Two independent knobs close both gaps. Raise the token requirement to attack the attacker's budget. Raise the time requirement to attack the attacker's throughput. You can't optimize around both simultaneously the way you can around either alone.
Where it sits relative to x402 / pay-per-call
If you're already comfortable with the idea of agents paying for API access — x402-style pay-per-call, USDC micropayments, no accounts — this will look adjacent but distinct. Where charging money outright is the honest, direct solution (an agent calling a paid API), that's already a solved shape.
Token Proof of Work is for the adjacent case where charging money is the wrong answer: a customer shouldn't have to pay to ask your store a question, an applicant shouldn't pay to submit a job application. But "free" still needs a cost function attached to it, or it gets abused. That's the gap this fills — contact forms, directory/marketplace submissions, app store listings, reviews, comments, support tickets, applications: anywhere "free to submit" has historically meant "free to flood."
What's actually unsolved here
To be upfront: this is a proposal, not a shipped implementation. There's no reference server, no SDK, nothing running in prod. The interesting open problem is verification — how does a receiver confirm the token-work was genuinely produced by the challenge-solving process, rather than shortcut through a cheaper model, a cache, or a lookup table? The working hypothesis is that challenge design can be structured so that cheating the verification costs about as much as honestly complying — which is the only invariant proof-of-work systems have ever actually needed to hold. That's a claim worth stress-testing, not one to take on faith.
Full write-up, threat model, and open questions are in the whitepaper (MIT licensed) on GitHub: https://github.com/onescales/token-proof-of-work
If you can break the challenge design, have a cleaner verification scheme, or want to prototype a receiver/verifier — that's exactly the discussion this was written to start.
