DEV Community: One Scales

Why I'm Passionate About x402

Ori Tzvielli — Wed, 23 Sep 2026 07:12:41 +0000

I've been building on the web for a long time, and I've paid a lot of middlemen along the way: payment processors, billing platforms, marketplaces, subscription tools. Each one added an account, a fee, and another step between a buyer and the thing they wanted.

x402 is the first payment standard in years that made me think that stack could get a lot thinner. This post explains why I care about it, what we're doing with it at _done, and where it isn't ready yet.

x402 in one minute

HTTP has had a status code called 402 Payment Required since the 1990s. It was "reserved for future use" and almost nobody used it. x402 is an open protocol, started by Coinbase and backed by Cloudflare among others, that finally puts it to work.

The flow is simple:

A client requests a resource.
The server answers 402 with a price and where to pay.
The client pays, usually in USDC on Base or Solana, and retries with proof of payment.
The server checks the payment (typically through a facilitator such as Coinbase's) and returns the result.

There's no signup and no key. Paying is how you authenticate.

Why I'm excited about it

The potential is huge. Almost every online interaction that involves money can be expressed as "request, price, pay, deliver." That covers APIs, data, content, files, and eventually ordinary checkouts. A native payment layer for HTTP is a big idea, not a niche one.

No accounts, no logins, no API keys. Think about what a developer goes through to try a new API today: sign up, verify an email, find the dashboard, create a key, store it somewhere safe, add a card, pick a plan. With x402, all of that collapses into one retried request. There are no keys to leak and no passwords to reset.

It's built for AI agents. An agent can't click an email confirmation link or fill in a billing form, and it shouldn't have to. Give it a wallet with a few dollars and it can buy exactly what it needs to finish a task, one call at a time.

Fewer middlemen, lower fees. Card payments carry fixed fees that make anything under roughly 30–40 cents uneconomical. With x402, charging a cent or less per call actually works. The money moves from buyer to seller without a stack of platforms each taking a cut. That makes pricing models possible that simply didn't exist before.

What we're experimenting with at _done

_done is a catalog of small, pay-per-call utility APIs aimed at AI agents: things like DNS and WHOIS lookups, screenshots, OCR, hashing, QR codes, and SEO extraction. Every call costs one cent in USDC over x402. There's no account and no key.

We picked these tools deliberately. They're tasks an LLM genuinely can't do on its own. A model can't resolve DNS, reach a live website, or compute a correct SHA-256 hash, however confident its output looks. An agent that can pay a cent to get the real answer is more useful than one that guesses.

What we're learning along the way:

Discovery matters as much as payment. Each API publishes an openapi.json, and we list on registries like x402scan and the Coinbase Bazaar. An agent can't pay for a tool it can't find.
Machine-readable descriptions need care. Agents read your spec literally. A sloppy description gets a wrong call, and the buyer still pays.
One cent is the norm. Agents expect tiny payments, and a flat price keeps things predictable.

The honest downsides

I'm excited about x402, but it's early, and pretending otherwise wouldn't help anyone.

Buyers are scarce. Most people don't have a crypto wallet, and most agents aren't set up to pay yet. Right now there are more services accepting x402 than clients using it.
The spec is still moving. Implementations differ slightly, and what works today may need changes in a few months.
"Crypto" is a hard sell for some. Even with a dollar-pegged stablecoin, some buyers and finance teams will say no on principle.
Don't expect overnight revenue. Adding a 402 to your API won't bring in money by itself. Demand is still catching up.

Should you care?

If you're building tools for AI agents, I'd start experimenting now. Nobody else has solved "an agent buys something without a human" this cleanly.

If your customers are mostly people with credit cards, add x402 alongside your existing checkout, not in place of it. It's cheap to set up, and you'll be ready as demand grows.

I'll keep sharing what we learn from running _done. If you're building with x402 too, I'd like to compare notes in the comments.

Verifiable Data > Claimed Data: What i'm Trying to do with Ori's List

Ori Tzvielli — Wed, 23 Sep 2026 07:08:17 +0000

Most of the data we act on is claimed data. Someone tells you a number, shows you a chart, or hands you a PNG, and you decide whether to believe them.

Verifiable data is different. You can trace it back to the system that produced it, and the person showing it to you couldn't have changed it along the way.

As developers, we already know this. We don't trust a screenshot of a passing test suite. We trust the CI run. We don't trust "it works on my machine." We trust a reproducible build. Proof is something you can check, not something someone describes to you.

I've done SEO since 2007, and the SEO agency market runs almost entirely on claimed data. That's the gap I'm trying to close with Ori's List.

The problem, in engineering terms

When you hire an SEO agency, the pitch is usually a case study: a traffic chart, a big percentage, a client logo. Every one of those is a claim. The chart went through the seller's hands before it reached you, and nothing ties it back to its source.

Nobody has to be lying for this to be a problem. The format makes honest agencies and dishonest ones look identical. There's no signal in it.

The question I actually want answered is simple: can this agency rank its own website? Their own site is the one project they fully control. If they can't get organic traffic for themselves, why would you trust them to get it for you?

Google already knows the answer. It lives in Google Search Console. The trick is getting it out without anyone touching it on the way.

The mechanism: read-only OAuth instead of uploads

Ori's List doesn't accept screenshots, reports, or self-reported numbers. An agency connects its own Search Console through Google OAuth with a single scope:

https://www.googleapis.com/auth/webmasters.readonly

From there, a few design rules do most of the work:

The data comes from Google, not the agency. The directory pulls clicks for the agency's own root domain directly from the API. There's no form field where a number could be typed in.
It's re-checked every week. Verification is a subscription to reality, not a one-time badge. If access is revoked or the property goes missing two checks in a row, the verified mark and the performance data come down.
The numbers can't be bought. Free and paid listings publish exactly the same data. Paying gets a check mark, a link, and placement. It never gets a better number.
Data is allowed to go down. If an agency's traffic declines, the listing says Declining. It keeps its listing and its verification.

That last rule is the one I care about most. A system that can only show good news isn't proof. It's a trophy case. Verified doesn't mean good. It means real.

Minimum access, minimum storage

If you're asking businesses to connect a Google account, the privacy design has to be as strict as the verification. The rules I stuck to:

Read-only scope, nothing broader.
Own domain only. Client properties are rejected.
Aggregates only. Individual search queries are never published.
Disconnecting wipes the stored data.

Asking for less access also makes it easier for an agency to say yes. That's the practical upside of scoping tightly.

The pattern is bigger than SEO

Swap the nouns and this applies to a lot of software:

Freelancer platforms showing earnings pulled from a payment API instead of self-reported.
Growth claims backed by a read-only analytics connection instead of a slide.
Uptime pages built from independent probes instead of a status page someone edits.

Most major platforms already offer read-only OAuth scopes. The infrastructure for verifiable data exists. We just haven't made "show me the source" a normal thing to ask for, or a normal thing to build.

What I'd ask other builders

If your product displays a number that someone could be tempted to inflate, ask yourself:

Can this come straight from the source system instead of from the user?
Can the person displaying it edit it? If so, why?
Does it update, or does it freeze at its best moment?
Can it go down?

If the answers are yes, no, it updates, and yes, you're publishing verifiable data. Otherwise it's a claim, however nicely it's formatted.

I'd love feedback on the approach, especially on the privacy side of the OAuth flow. And if you run an SEO agency and think you can rank yourself, you know where to prove it.

Building In-Browser Private Tools: When the Server Is the Liability

Ori Tzvielli — Wed, 23 Sep 2026 06:54:16 +0000

Most file tools on the web work the same way: upload the file, process it on a server, download the result. That made sense when browsers were weak. It doesn't anymore. If your tool views, searches, converts, or exports a user's own file, it can often run entirely in the browser, and then the file never leaves the user's machine.

Why skip the server

An uploaded file becomes your liability: storage, retention, deletion, breaches. The user can't verify any of it. If the file never arrives, there's nothing to leak. That's privacy by architecture, not by policy.

The toolkit

File API and Blob.slice() to read huge files in chunks with bounded memory.
Web Workers to parse without freezing the UI.
WebAssembly when an existing Rust or C parser beats rewriting one in JS.
IndexedDB or OPFS to store a local index, not the whole file.
Blob URLs to hand exports back without touching the network.

Example: read mbox

Google Takeout gives you your Gmail as one huge .mbox file that nothing on Windows or Mac can open. Most "online" viewers want you to upload it. readmbox.com reads, indexes, and searches it right in the tab instead. What I like about it:

No upload endpoint exists, so there's no server to send your mail to.
Files of tens of gigabytes work, because they're read in chunks.
No install and no account.
Exports (CSV, PDF, EML, split MBOX, attachments) are generated locally too.

It does use analytics and says so openly. The claim is scoped precisely: your email never leaves your machine.

Make it verifiable

Load the page, turn off Wi-Fi, then open a file and use it. If it still works, the data isn't going anywhere. You can also watch the Network tab in DevTools, and enforce the guarantee with a strict connect-src in your Content Security Policy so nothing can quietly start uploading later.

Before you add an upload button

Ask whether the file really needs to leave the user's device. Often it doesn't. Every file you never receive is one you can't lose.

Building local-first tools? I'd like to see them in the comments.

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