AI's Currency: How Bitcoin Micropayments Integrate with AI?
TechFlow Selected TechFlow Selected
AI's Currency: How Bitcoin Micropayments Integrate with AI?
Bitcoin is mine, sats belong to AI.
Navigating Web3 tides with focused insightsAuthor: Pang Cheku
Sometimes it feels magical—whenever Bitcoin is mentioned in different environments, there are always people who express skepticism toward Bitcoin due to reasons like “not (wanting to) understand” or “impure motives.” Their concerns mostly revolve around “time” and “value,” rather than the technology itself as a sophisticated design.
I’m not skeptical. For me, Bitcoin is an irreplaceable source of novelty.
-
Recently, this sense of novelty comes from the lightning-fast experience of sats continuously streaming into my wallet from across the ocean—the idea that value as tiny as 1 satoshi ($0.00023) can travel immeasurable distances over wires and land directly in your hands;
-
From the delightful surprise of using Lightning ⚡ payments for banana ice cream scoops and Bolognese pasta at sidewalk restaurants in Paris and Bologna;
-
From the joy of receiving a small universal hardware kit shipped by Teacher Ajian across the sea, allowing me to build my own Bitcoin signer—a DIY seed signer.
I love a quote from Ajian: Bitcoin does things that no other technology can possibly achieve.
Today I want to discuss some topics I’ve been mulling over in my notes for the past three months:
The history of micropayments, experiments on the Lightning Network, and potential convergence between micropayments and AI.
A Brief History of Micropayments
W3C
Ted Nelson coined the term "micropayment" back in the 1960s. Ted Nelson, the pioneer behind internet terminology such as hypertext and hypermedia, introduced the concept of micropayments in the 1960s.
In 1992, Tim Berners-Lee, creator of HTTP and HTML, released his second version of HTTP, which included the first reference to what we now know as standard status codes. One of these codes, which Berners-Lee and others believed would one day be used to pay for digital content, was 402 Payment Required. Unfortunately, this status code was formally “reserved for future use,” because from the very beginning, all attempts at enabling micropayments on the web failed. Over 30 years after the invention of the internet, we’re still waiting for one of its original core visions to be realized.
Tim Berners-Lee founded the World Wide Web Consortium (W3C) in 1994 to guide the development of the web, and micropayments were a primary consideration from the outset.
In 1995, Phillip Hallam-Baker, who authored numerous RFCs on internet security, drafted the Micropayment Transfer Protocol (MPTP) [1], though the protocol appears never to have been implemented. Nevertheless, it offered many insights into the nature of micropayments—insights just as relevant today as they were at the dawn of the internet:
There is a large interest in payment systems which support charging relatively small amounts for a unit of information. Here the speed and cost of processing payments are critical factors in assessing a scheme’s usability. Fast user response is essential if the user is to be encouraged to make a large number of purchases.
However, a key limitation of MPTP was that the protocol explicitly required a third party (called a broker). At the time, digital payments could not exist without trusted intermediaries, so any attempt at a micropayment protocol had to involve some form of escrow.
W3C continued pushing micropayments for a while, publishing a micropayments overview in 1998 and recommending MPTP as a practical approach, noting:
Micropayments have to be suitable for the sale of non-tangible goods over the Internet […] With the rising importance of intangible (e.g. information) goods in global economies and their instantaneous delivery at negligible cost, “conventional” payment methods tend to be more expensive than the actual product.
This echoes Hallam-Baker’s second major concern: transaction costs imposed by the technical or administrative overhead of available payment mechanisms. His primary concern—“fast user response”—is often overlooked in discussions about micropayment feasibility.
It wasn’t until 1999 that Nick Szabo further explored “fast user response” in his paper *Micropayments and Mental Transaction Costs* [3]. This paper is highly recommended. Szabo argues that micropayments aren't merely a technical challenge but also involve cognitive costs—the psychological burden of making micro-transactions far outweighs the technical costs. How do we understand the decision-making process behind micropayments? Assuming technical transaction costs will continue to decline, how should we design interaction flows to minimize “mental transaction costs”? One possible scenario: personal resources/capital automatically matching one’s implicit preferences (e.g., packaging APIs or “internet connectivity” via micropayments).
A network based on micropayments implies frequent transactions, which leads to decision fatigue. For most micropayments, the mental cost of constantly deciding whether to buy may exceed the value of the item being purchased.
Large companies like Compaq and IBM, along with startups such as Pay2See, Millicent, and iPin, all attempted early solutions to reduce both technical and psychological transaction costs of micropayments—but the idea remained elusive from the start.
Perhaps the most famous among these ventures was DigiCash, led by David Chaum, which left a lasting impact on the Bitcoin community. Chaum had already formally proposed blockchain-like data structures and secure digital cash concepts back in 1982, then founded DigiCash in 1989. DigiCash implemented Chaum’s proposals, allowing users to withdraw funds from banks (called eCash) and enabling untraceable digital micropayments. Unfortunately, only one bank ever adopted eCash, and the company went bankrupt in 1998.
Around the same time, other micropayment initiatives disbanded, and W3C itself ended its support for micropayment activities in 1998.
The dot-com bubble was collapsing in full force, and micropayments were among the hardest-hit ideas. It became a great time to be a critic. Writer Clay Shirky published *A Case Against Micropayments*, boldly declaring:
Micropayment systems have not failed because of poor implementation; they have failed because they are a bad idea. Furthermore, since their weakness is systemic, they will continue to fail in the future.
In 2000, his main argument against their fundamental flaw wasn’t technical or infrastructural—it echoed Nick Szabo’s point from a year earlier: decision fatigue. He elaborated:
In particular, users want predictable and simple pricing. Micropayments, meanwhile, waste the users’ mental effort in order to conserve cheap resources, by creating many tiny, unpredictable transactions. Micropayments thus create in the mind of the user both anxiety and confusion, characteristics that users have not heretofore been known to actively seek out.
Shirky went on to predict that three payment models would dominate the web—and none would suffer from decision fatigue: aggregation (bundling low-value items into single high-value transactions), subscriptions, and subsidies (having someone else pay instead of the user—today seen in advertising models).
By the end of the dot-com bust, Shirky’s predictions looked increasingly prescient. Credit card infrastructure made sub-$1 payments impractical, becoming the de facto standard, while enthusiasm for micropayment projects faded. Against the backdrop of an increasingly centralized, monitored, and ad-driven predecessor—Web 2.0—the web’s once-promising and exciting future dimmed.
Bitcoin and Decentralized Networks
We must trust them to protect our privacy and believe they won’t let identity thieves steal our accounts. The huge administrative costs make micropayments impossible. — Satoshi Nakamoto
The driving idea behind 402 was that clearly, payment support should be a first-class concept on the web, and clearly, there should be massive direct commerce happening online […] What emerged instead was a single dominant business model: advertising. That leads to massive centralization, because the platforms with the highest cost per click become the biggest.
— John Collison, President of Stripe
Satoshi Nakamoto released the Bitcoin whitepaper at the end of 2008, during the U.S. housing crisis. Soon after, he released the original code. Bitcoin represented a monumental breakthrough in both computer science and monetary history, sparking renewed interest in the possibilities of the internet. For the first time, there was a permissionless way to transfer value using an internet-native currency, without relying on the clunky, inelegant infrastructure required by credit cards.
For a time, Bitcoin’s price was so low that some advocated using it as a micropayment system, although Nakamoto acknowledged it wasn’t yet a good solution:
Bitcoin is currently impractical for very small micropayments. It’s unsuitable for pay-per-search or pay-per-pageview content without aggregation mechanisms, or for fees below 0.01.
Yet the fee limitations didn’t stop people from dreaming about its new possibilities. Marc Andreessen, creator of the first popular web browser, cited content monetization and spam prevention as examples:
One reason media businesses like newspapers struggle to charge for content is that they face a binary choice: charge fully (via subscription for all content) or offer nothing (leading to terrible banner ads everywhere online). Suddenly, with Bitcoin, there’s an economically viable way to charge arbitrary small amounts per article, section, hour, video play, archive access, or news alert.
Of course, this isn’t true today (at least not on Layer 1), but in 2014, fees were low enough to actually build around micropayments. One interesting project built around that time was Bitmonet, which allowed users to choose subscription tiers: 10 cents per article, 15 cents for unlimited hourly access, or 20 cents for a daily pass. Unfortunately, transaction fees soon rose too high to sustain arbitrary micropayments. Although Nakamoto clearly foresaw this issue from day one, Bitcoin wasn’t specifically designed to solve micropayments.
Shirky’s prediction about content monetization proved remarkably accurate, especially regarding subscriptions and advertising.
In the advertising model, content is subsidized by advertisers (usually through third parties). From 2014 to 2022, Google and Facebook essentially formed a duopoly over the online ad market as intermediaries between advertisers and content creators. These companies (like most big tech firms) collected vast amounts of personal data and simply asked users to trust them with their data safety—despite frequent breaches. This data is used to show targeted ads for products people are more likely to buy. Companies often call this model “free with ads.” But users do pay a price. The ad model forces users to exchange content for two things:
1. User data, forcibly shared with third parties—as Nick Szabo noted, a security vulnerability.
2. User attention. The longer users spend on ad-supported sites, the more money advertisers, platforms, and creators earn. Thus, creators are economically incentivized to display as many ads as possible without driving users away. In the “free-with-ads” web, the currency is user attention. You are the product. The ad model makes clear that consumers become second-class citizens. Since revenue for creators is abstracted from end-users, delivering a good user experience isn’t the top priority. As more consumers adopt ad blockers, content creators are forced to push ads harder, worsening everyone’s browsing experience.
Subscriptions have also grown increasingly popular. Users say they prefer paying regularly for bulk access to licensed content like movies and music rather than owning individual songs. While more honest as a business model, subscriptions can cause major problems when they’re the only option. In recent years, as competition intensifies, more people report suffering from “subscription fatigue.” They can’t access specific articles, films, or songs when needed, forcing suboptimal choices—paying for bundles and optimizing usage across subscriptions.
Take streaming services as an example. Today, so many services compete for content licenses that users often need multiple subscriptions to access desired shows. Yet they only really want a small portion of each service’s offerings. When choosing a service for a particular movie or show, it often doesn’t stay long—content unpredictably jumps from one platform to another as licenses expire and renew.
News articles are another case. Outlets like The New York Times or The Economist attract readers by letting them read a few sentences before hitting a paywall. This is even more pronounced with newspapers, where customers would likely prefer paying a small amount for individual articles rather than bundled deals for unwanted content.
While subscriptions offer a more direct alternative to ads, managing them in practice often becomes an increasingly costly and stressful game.
When Clay Shirky wrote about the problem of mental transaction costs, he did so before subscription and ad fatigue began weighing heavily on users as they do today. Bitcoin solved the problem of internet-native currency, but slow processing speeds and high fees quickly became prohibitive for supporting micropayment systems. Before micropayment technology could truly take off, a major innovation was still needed.
Lightning Network
In the Lightning Network whitepaper, the idea of micropayments takes center stage.
"A decentralized system is proposed whereby transactions are sent over a network of micropayment channels (aka, payment channels or transaction channels)" — Lightning White Paper
Current Lightning micropayment projects
AI’s Currency
Just as humans need passports and currency to cross borders, AI agents may require forms of identity verification and payment mechanisms to access various services and resources on the internet.
From 402 Error to L402
What are HTTP error codes? 200 OK, 404 NOT FOUND, and 500 INTERNAL SERVER ERROR are all examples.
-
4xx codes indicate client errors, meaning the client sent an invalid request. The most common include:
-
* 401 Unauthorized: authentication required or failed.
-
* 403 Forbidden: server rejected the request.
-
* 404 Not Found: requested resource not found.
-
HTTP status code 402 means “Payment Required,” indicating the client must pay to access the resource.
In 1992, Tim Berners-Lee, creator of HTTP and HTML, released his second HTTP version, including the first reference to commonly used status codes. One of these codes—402 Payment Required—was intended by Berners-Lee and others to someday enable payment for digital content. Unfortunately, this status code was officially “reserved for future use” because, from the start, all attempts at implementing micropayments on the web failed.
At the dawn of internet design, the absence of functional HTTP 402 meant the web couldn’t support (micro)payments. The Lightning Network’s L402 protocol is designed to support authentication and payment in distributed networks—in essence: enabling payments for internet-native applications or services (e.g., APIs, login, digital resource access), where such services rely on unit economics.
Macaroon Isn’t Sweet This Time
Here, macaroon isn’t the French dessert, but an advanced authentication mechanism for distributed systems. Designed to combine the benefits of bearer tokens and identity-based systems into a single token, macaroons can be issued and verified quickly without accessing a central database.
Macaroons are Cookies with Contextual Caveats for Decentralized Authorization in the Cloud. [4]
AI representatives—intelligent LLMs and AI agents—have no native relationship with fiat systems (can’t register accounts or show ID). Macaroons can provide identity (authentication) to AI entities within distributed systems.
Bitcoin Is Mine, Sats Belong to AI
I recall a friend’s soulful question: regardless of one’s outlook on Bitcoin’s future, she personally wouldn’t use Bitcoin for microtransactions (like buying coffee or banana ice cream muffins). Indeed, hoarding is hard enough—why burn precious BTC? A sudden thought flashes: what if satoshis, in some way, aren’t meant for humans at all?
Yet these agents will certainly need to pay for resources, whether gated APIs or paid data sources. Moreover, they’ll need to effectively evaluate pricing signals to determine the most efficient path to complete tasks. These payments, evaluations, and decisions will lead thousands of AI agents to make countless micropayments and micro-decisions daily. Given these factors, it makes sense that creators of AI agents would ultimately favor Bitcoin and the Lightning Network—globally accessible, permissionless, near-instant settlement, internet-native monetary systems—over traditional fiat systems fundamentally incapable of supporting such demands.
If sats become AI’s currency, my question is: what do these AI agents—needing high-frequency, unit-economics-dependent micropayments—actually look like? Or in what scenarios are such AI agents actively working?
It’s easy to imagine users assigning tasks/goals to AI agents and funding them (e.g., 10,000 sats) to complete those tasks, with agents navigating the internet’s alleys to find optimal paths. But what are the tasks?
Variant Funds’ article *Crypto AI Agents: The First-Class Citizens of Onchain Economies* [5] gives several examples, such as:
Gnosis demonstrates this early infrastructure through its AI Mechs, packaging AI scripts into smart contracts so anyone (or another bot) can invoke the contract to execute agent actions (e.g., placing bets on prediction markets) and pay the agent.
AI agents need fine-tuning for specific industries, topics, and niches. Bittensor incentivizes “miners” to train models for specific tasks (e.g., image generation, pretraining, predictive modeling), organized around target sectors (e.g., crypto, biotech, academia).
AI
My understanding of AI mainly comes from frequent interactions with GPT.
AI understands how AI works and the AI itself is, is not just maximizing its intelligence and problem solving capability in service, for instance, to answering Bing requests, but it's trying to maximize its own agency.
And that means it's maximizing its ability to control the future and play longer games.
"AI understands how AI works. Their goal isn’t just solving problems, but thinking about sustainability (playing positive-sum games) and anticipating future events." — Joscha Bach [6]
A recent OpenAI paper [7] explores how weak supervision can unlock strong model capabilities. The research team fine-tuned GPT-4 series models across various tasks and found that weakly supervised models outperformed their supervisors—a phenomenon called “weak-to-strong generalization.” In plain terms: how to make computer programs (like chatbots) perform well even with vague instructions. Usually, we need to give detailed guidance for programs to work correctly. But the study found that even with insufficient guidance, these programs sometimes exceed expectations. It’s like teaching a child: giving only basic instructions, yet the child figures out how to do better on their own.
For example, my recent experience frequently calling APIs—Google Scholar, Semantic Scholar, GPT (indirectly)—made me feel my role was primarily moving API keys and copying API descriptions (so GPT could match formats).
The interaction here is fascinating: humans still need to learn code, but more importantly, understand the roles of components and their interconnections. For instance, designing a system targeting XYZ goals, using KG to structure idea skeletons and APIs to connect data joints—we can focus more on what to connect (to create something more interesting or achieve certain goals), while GPT provides connection strategies. Recently, I tried a “collaborating with GPT to complete tasks” roleplay, where GPT acted as developer offering code solutions, and I served as the API key mover（笑) and provided ideas on which APIs to assemble:
Examples of AI running independently with specific toolkits already exist. One project aggressively testing this boundary is tldraw: draw-a-UI, experimenting with AI combining multiple APIs to accomplish diverse interactive tasks.
AI agents can propose practical or impractical ideas—either initiated by humans or autonomously—obtain funding via rule-based smart contracts, then recruit real people (developers, designers, memesters) to help build and iterate. Perhaps many novel tasks will emerge and form markets, enabling “human-AI collaboration to rewards.”
AI agents are bold and imaginative but lack boundaries and constraints. Collaborating with humans allows previously unimaginable ideas to materialize. Could Bitcoin or cryptocurrency inject vitality into corresponding currencies, capital, and micro-rewards to support their growth?
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
