What We Lost When Web3 Went to Shit

@adhurjaty.bsky.social

I can't get this idea out of my head. When I hear stories about shortcomings of the internet we have — Facebook taking advantage of users, Amazon's dominance of so many parts of our lives, X's (Twitter's) algorithmic decisions plausibly altering the direction of our politics — I keep coming back to this idea. "Web3 was supposed to solve this".

When I heard the chorus of "crypto is a solution in search of a problem" during the crypto frenzy of the early part of this decade, I was baffled. The problem is obvious.

The Gravity Problem

You need to be on X to follow the national conversation. You need Amazon to buy things online from anyone you haven't met in person. You can't purchase from an unfamiliar website without handing over your credit card number and hoping for the best. These aren't accidents. They're the equilibrium state of an internet where every useful service tends toward monopoly.

Cory Doctorow calls the dynamic enshittification. Platforms start by serving users well to attract them, then gradually degrade the experience to extract value. Or in his words, writing about Amazon:

Amazon has produced a planned economy run as capriciously as a Soviet smelting plant, but Party Secretary Bezos doesn't even pretend to be a servant of the people. From his lordly seat aboard his penis-rocket, Bezos decides which products live and which ones die.

Remember that one of those search-results for a cat-bed was a product for dogs? Remember that Amazon made that dog product? How did that end up there? Well, if you're a seller trying to make a living from cat-beds, your ad-spending is limited by your profit margin. Guess how much it costs Amazon to advertise on Amazon? Amazon is playing with its own chips, and it can always outbid the other players at the table.

You end up with worse products for everyone and no competitive pressure to fix it, because switching costs are too high. X for discourse, Amazon for commerce, Google for search.

But the monopoly tendency is a symptom. The deeper problem is structural. Building any web service today means assembling a stack of vendor integrations. Authentication via Google OAuth. Payment processing through Stripe, with their fees and terms. Logistics partnerships with warehouses and shippers, each with their own API and contract. Every integration is a negotiation. Every negotiation is a barrier to entry. The incumbent already has those partnerships at scale. A new entrant has to recreate the entire stack before they can compete on the product.

In startup culture, founders are trying to find their moat: what is stopping other companies from competing with you. Challenges in building and maintaining these connections and infrastructure is a moat. We're past the feudal age, fuck your moat.

What Web3 Was Actually Attempting

Paying with a crypto wallet is a smooth experience. JavaScript runs on the page. A browser extension prompts for approval. Payment goes through. No login, no form, no credit card number transmitted anywhere. The extension could be using Ethereum or Visa under the hood; it doesn't matter. What matters is the trust boundary: the buyer authenticates once, with a wallet, and the merchant never touches the payment credentials.

Contrast that with the current model, where every pizza shop and every one-time shoe purchase gets to see your card number. The problem isn't that you have to trust anyone — it's that you have to trust everyone, repeatedly, with no standardization and no way to limit exposure.

Apple Pay moves in the right direction: the merchant never sees your card number. But it requires an Apple account. Apple can deplatform merchants. The underlying card networks make sub-cent transactions economically impossible. The principle is right but the execution is captive to a single company.

What crypto was attempting wasn't a currency. It was a protocol, a payment layer at the foundation of the internet, the same way email is a protocol anyone can participate in without asking Google's permission. The specific hard problem blockchain solved was double-spending: ensuring the same dollar can't be sent twice without requiring a central ledger keeper who becomes a chokepoint. Bitcoin proved you could maintain a shared ledger without a central authority. Ethereum extended that insight: the ledger doesn't just record transactions, it runs programs. A smart contract is a program on that shared ledger — escrow, bidding, conditional payment, all executing automatically without a middleman. (If you want the full explanation of how Bitcoin works, 3Blue1Brown's video is excellent.) Whether the underlying technology is a blockchain, an Interledger-style protocol, or something not yet invented is secondary. The principle matters more than the implementation.

The idea is still alive. HTTP status code 402 — "Payment Required" — has been reserved since the 1990s and never used. In late 2025, Coinbase shipped x402, an open standard that finally puts it to work, using stablecoins for machine-to-machine payments. Meanwhile, the AT Protocol (the infrastructure behind Bluesky) shows that open, portable, decentralized architecture can be built as a web protocol without blockchain at all. These are early, but they exist.

When Payment Is a Protocol Primitive, Any Resource Becomes a Market

When payment works as an open protocol (programmable, sub-cent, trustless) any resource currently provisioned by a centralized gatekeeper can be replaced by a market. A market where anyone with spare capacity can participate, and price signals coordinate supply and demand automatically.

This isn't purely theoretical. Filecoin already did it for storage: owners of idle hard drives offer capacity to a network and earn fees. The protocol handles coordination, pricing, and verification. No one negotiated a partnership with Amazon S3 (cloud file storage). The same logic extends to compute, bandwidth, content, and commerce.

Reading the Web Without Ads or Subscriptions

Imagine a blogging platform where reading an article triggers a small payment for a fraction of a cent per page. The blog can tune the model: charge per request, charge only past a certain depth, give the first article free. No ads. No subscription. Readers pay proportionally to what they actually consume, and writers are paid directly by readers rather than by an advertising intermediary.

This is economically impossible on existing card networks. Visa's interchange fee alone is roughly ten cents plus a percentage per transaction. A $0.003 payment isn't just unprofitable, it's structurally blocked. The only path to sub-cent transactions is a settlement layer without per-transaction percentage fees.

The classic objection, and it's a fair one: even trivially small payments create cognitive friction. Nick Szabo made this argument in 1999. The act of deciding whether to pay is more annoying than the amount. This is why Spotify works better than iTunes' 99-cent songs — removing the per-item decision is part of the product. A per-request paywall puts a mental tollbooth before every article.

There's no proven solution, but there's a plausible sketch: your browser maintains a "gas tank". A balance auto-depletes with each payment request, below a rate limit you configure once. Instead of "do I want to pay for this article?" you ask once: "how much am I willing to spend per page request, across all sites?" Then it runs in the background like a data plan. Sites that want to participate in auto-pay apply for a credential from an issuer your browser trusts: something like a Michelin star for payment behavior. Abuse the credential, lose it. Don't have one, get blocked from auto-pay. The issuers themselves can't enshittify because they hold no custody over your data. If one goes bad, you swap it out and nothing migrates. Trusted coordination without lock-in.

Alternate payment options could sit on top of this one. A browser payment plugin could allow you to browse for free, but show ads on top of the pages. The plugin developer pays the toll. The content creator is abstracted away from how the user chooses to pay.

This is unvalidated. The mental transaction cost problem may be why micropayments never got off the ground: not fraud, not speculation, just UX. But the architecture is sound, and the infrastructure to attempt it is closer to existing than it was five years ago.

The First Market: Infrastructure Without AWS

A DDoS attack is structurally unfair: botnets are cheap, bandwidth is expensive, and the victim bears all the cost. A market-based hosting model inverts this entirely.

Filecoin incentivizes owners of idle hard drives to offer storage. Apply the same incentive structure to compute and bandwidth, and individuals run application nodes and earn fees for serving requests.

AWS regions AWS model ![[filecoin_mesh_network.jpg|Assets/hosting-distributed.svg]] Filecoin mesh network model

In a pay-per-request model, every request costs the requester something. DDoS becomes economically irrational. The attacker is funding the victim's node operators. This is a structural realignment of who bears the cost.

Traffic spikes handle themselves through surge pricing. When demand rises, fees rise. Higher fees do two things simultaneously: motivated users pay more to get through (the same model as Disney Lightning Lane or Uber surge pricing), and more node operators are induced to come online to collect the higher fees. Supply responds to demand automatically. No human intervention, no capacity planning, no 3 AM pages.

Diffuse Servers

The network self-organizes geographically. Nodes near high-demand concentrations earn more, so more local nodes come online, so latency improves for local users. If AXS is selling Phillies tickets, nodes near Philadelphia become more profitable to run. The network clusters around demand without any central planning.

Concentrated Servers

Commerce Without Amazon

The integration moat is most obvious in commerce. Amazon owns the payment processor, the warehouse, the shipping carrier — all at scale. A new entrant rebuilds the entire stack before competing on the product itself.

What if the stack were unbundled into independent layers connected by protocol?

Commerce Contrast

Suppliers — manufacturers, artisans, anyone with inventory — list their products (SKUs) on an open registry. No exclusive relationships, no platform fees for listing.

Aggregators curate from that registry and serve as storefronts. They play the role brands play today — trusted selection, a browsing experience, a checkout interface — but without owning any of the supply chain beneath them. Think of them as Bluesky feed generators for products: you choose an aggregator for the quality of their curation, and switching to a different one costs you nothing. They're funded by micropayments per browse: the same protocol primitive from the previous sections, applied to a different resource. No referral fees, no paid placement, no financial relationship with suppliers. They're paid for being useful to shop, not for steering you toward whoever pays them the most.

On purchase, the aggregator creates a smart contract: the SKU, the delivery location, a timeframe the customer selected, and escrowed funds priced from historical fulfillment costs. This contract enters a fulfillment market. Anyone who can deliver the item within the specified terms can accept it. The first to accept wins. The winner handles everything: sourcing the item, getting it to the customer, by whatever means they choose. They might use FedEx internally. The protocol doesn't care. It cares that the item arrives and the customer confirms receipt, which releases the escrow.

If no one accepts the contract before timeout, the funds return to the buyer — the equivalent of "unavailable for your area," but more informative. It's not that the item doesn't exist; it's that no one can deliver it to you at that price in that timeframe. Retry with a longer window or a higher budget.

Warehouses emerge as a market optimization. A warehouse is just a supplier who bought inventory in bulk and positioned it near anticipated demand. They win fulfillment contracts because proximity means lower delivery costs. The market incentivized their existence through price signals. Fulfillment bid data is the demand signal. This is what Amazon does with its fulfillment centers, except Amazon does it through central planning with proprietary data, and here the market does it openly. The same self-organization that clusters hosting nodes near demand clusters inventory near customers.

The pattern is recursive. The same protocol that moves a finished product from a supplier to a customer also moves components from a raw materials provider to a manufacturer. Warehouses re-enter the supply chain as local suppliers at the next level. One coordination primitive, tiling across the entire supply chain depth.

Commerce Recursion This leaves real problems unsolved. Smart contracts can't inspect a box. Dispute resolution needs an arbitration layer, and optional insurance markets are a plausible direction (insurers become natural risk assessors with better cross-platform data than Amazon has). Reputation and identity need some form of Verifiable Credentials to prevent bad actors from cycling through new identities. Price discovery starts with standing rate cards and evolves toward dynamic bidding as liquidity grows. None of these are solved. But the architecture is coherent, and the hard part - programmable escrow as a coordination primitive - already works.

Reputation and Identity

Your Uber rating means nothing on Airbnb. Your Amazon seller history doesn't follow you to a different marketplace. The platform owns your reputation as much as you do and they have no incentive to make it portable, because portable reputation reduces lock-in.

Every example above requires trust infrastructure that doesn't currently exist and platform-specific reputation systems can't provide it.

Verifiable Credentials offer a different architecture. California's DMV already issues a mobile driver's license built on the W3C Verifiable Credentials standard. Using zero-knowledge proofs, a site can verify that you're over 21 without learning your birthdate, or that you hold a valid license without learning your name. The site learns only what the credential attests — nothing more.

Applied to commerce: a shipping credential issued by a carrier network says "this entity has completed 500 deliveries with a 98% on-time rate." A buyer credential says "this entity has resolved disputes in good faith." You carry whichever credentials are relevant to a given interaction and disclose only what's required. Domain-specific, opt-in, privacy-preserving.

The dystopian version of this, the Black Mirror "Nosedive" scenario, is a single aggregated score that follows you everywhere and determines your access to housing, transportation, and social standing. The safeguard is design, not technology: keep credentials siloed by issuer and context, make disclosure opt-in, and prevent any single actor from combining credentials across contexts into a unified profile. This is a genuine design challenge, and "web3 is better positioned to solve it" doesn't mean it gets solved. But user-held credentials are structurally harder to aggregate than platform-held data, which is at least the right starting point.

Why It Didn't Work

The failure wasn't incidental to the technology, it was partially structural. The same token designed for micropayments becomes a speculative instrument the moment it can appreciate in value. You can't build a payment protocol on an asset people want to hoard. You don't want to end up being the Bitcoin Pizza guy: spending what's now worth > $100M on 2 pizzas.

Path dependency is the rest of the answer. Existing payment infrastructure - Visa, Apple Pay, Stripe - is good enough for most use cases. Not ideal, not open, not programmable, but functional. Bootstrapping any of the markets described above requires a discontinuity large enough to overcome switching costs. Every one of these examples has a chicken-and-egg problem: the fulfillment market needs suppliers, suppliers need storefronts, storefronts need customers, customers need a reason to leave Amazon. The micropayment system needs sites, sites need users with gas-tank-enabled browsers, browsers need a credentialing ecosystem. Each layer waits for the others.

There is one opening, and it's accidental. AI agents don't have mental transaction costs. They're already transacting programmatically, at scale, without needing UX. x402 was designed primarily for machine-to-machine payments. The machine-to-machine payment layer might establish the protocols, standards, and liquidity that human-facing applications eventually inherit — not by design, but because AI agent commerce happened to need the same infrastructure first. Agent-to-agent transactions could establish fulfillment market liquidity before human commerce requires it. Stateless AI workloads could bootstrap a distributed hosting network before anyone tries to run a database on it.

This isn't a prediction. The infrastructure and incentives are both moving — but toward what, and whether fast enough to matter, isn't clear. The idea was right: the internet doesn't have to work the way it does. Payment as a protocol primitive would change what's possible at every layer of the stack. Whether anyone builds it is an open question. But the problem hasn't gone away.

adhurjaty.bsky.social

@adhurjaty.bsky.social

Post reaction in Bluesky

*To be shown as a reaction, include article link in the post or add link card

Reactions from everyone (0)