DEV Community: Ori Tzvielli

Introducing "Token Proof of Work"

Ori Tzvielli — Thu, 27 Aug 2026 04:49:06 +0000

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.

Why We're Building Apps for the Internet — Here's Our Direction

Ori Tzvielli — Mon, 02 Mar 2026 02:26:19 +0000

Why We're Building Apps for the Internet

There's a simple reason we do this: we want to give more than we take.

Before One Scales, I ran a web development company with up to 38 people. We built websites, we sold hours — we were more like a factory. One Scales is a different bet. Use code and content to reach a lot of people, reduce waste, build things once that keep working.

Finding What's Missing

We look for gaps. Underserved niches, tools that don't exist yet, problems people are quietly frustrated by. When we find one, we build something and create content around it to help people save time and do something useful.

What We're Building Right Now

AI SEO / llms.txt — We believe AI discoverability is the next generation of SEO. Just like websites had to learn to speak Google's language, they'll need to speak AI's. The llms.txt standard is part of that shift. Our flagship project is Hi LLMs — a suite of tools that help websites connect with AI systems, including an embeddable AI Summary Widget, free Chrome extensions, and more in the pipeline.

Apify Apps — We publish automation and scraping tools on the Apify marketplace. 21 apps live, 3,800+ users and growing. A few examples:

LLMS.txt Generator — Make websites discoverable to AI assistants
Bulk Image Downloader — Download thousands of images at scale
Sitemap URL Extractor — Extract all URLs from any sitemap
Bulk AI Markdown Maker — Convert pages to clean markdown with AI
Website Screenshot Pro — Capture high-quality screenshots at scale
Simple SEO Data Extractor — Pull SEO metadata from websites

We Share Everything We Learn

On our YouTube channel we publish tutorials and walkthroughs. One video on improving .mbox files from Google Takeout/Gmail has helped over 100,000 people.

We also write articles on onescales.com — anything we can share that either doesn't exist online or we think we can explain better. It's not always tech. We timestamped all the scary parts of Moana so parents of toddlers know exactly what to skip. Simple, useful, real.

And we open-source tools on GitHub — a Google Sheet API wrapper, a Calendar ICS exporter, an IPFS bulk uploader, and more. If we build something useful, we share it.

Honest About Where We Are

One Scales isn't a full-time income yet. It's a side mission we believe in, built step by step, with the goal of becoming something sustainable. We're learning, adjusting, and continuing.

If any of this resonates, we'd love to connect.

Follow along: YouTube · GitHub · Apify · Twitter/X

trying to figure out browser-use

Ori Tzvielli — Mon, 12 Jan 2026 13:12:03 +0000