Bitcoin & Artificial Intelligence
When Machines Pay: Why AI Needs Money of Its Own
Software operates worldwide. What kind of money suits an economy in which programs buy services independently?

An AI agent needs a piece of information. It finds a provider, checks the offer and could process the data immediately. Payment gets in the way: open a customer account, add a payment method, perhaps take out a subscription. A task that software could complete in seconds waits for a human and their credit card.
This looks like a small technical obstacle. Behind it lies a larger question. We are building software that communicates worldwide, compares services and carries out tasks independently. What kind of money suits such an economy? Money whose use depends on individual payment providers and whose rules are set by institutions? Or money with open, verifiable rules that software can use directly?
By money of its own, I mean a budget that an agent can manage independently within clear limits. Fiat money is technically usable for this purpose. Programs can spend euros or dollars through accounts set up for them. But in doing so, they also inherit the dependencies of that system. Bitcoin opens up a different approach. That is precisely why the connection between artificial intelligence and Bitcoin deserves more attention than the next price prediction.
Software can calculate. Who determines the unit of account?
An agent can compare prices, manage budgets and assess offers. It does so using a unit of account whose properties it does not determine. A hundred euros in an account remain a hundred euros. What they can buy changes.
Fiat money is shaped by monetary policy decisions. The European Central Bank aims for two per cent inflation over the medium term. There are economic policy reasons for that target. For a balance earning no interest, however, persistently positive inflation still means a loss of purchasing power.
An agent can factor such developments into its calculations. But it cannot verify future monetary policy as it would a fixed calculation rule. That policy depends on decisions taken under changing conditions.
This is where my criticism lies. It is not just about two per cent. It is about how much power over money should rest with individual institutions. Anyone holding money is affected by decisions over which they have little influence. Having software manage our money does not remove that dependency. It merely automates it.
For a single data request, long-term inflation hardly matters. Price, fees and reliability are what count. The monetary question goes further: in what unit are services offered, revenues held and future expenses planned?
Bitcoin makes monetary rules verifiable
Bitcoin takes a different approach here. Under its current consensus rules, its total supply is limited to around 21 million units. The issuance of new bitcoin also follows a predetermined schedule. Running your own fully validating node lets you check whether blocks and transactions comply with those rules.
Developers can propose changes. But they cannot decide on their own that all participants must adopt new rules. Changing the software does not automatically change everyone else's money.
For me, this is an essential quality: certain properties of the money can be verified independently. An agent would not have to perform that verification itself as a language model. It could rely on software built specifically for the task, which rejects anything that breaks the rules.
That does not make Bitcoin's market price predictable. A limited supply prevents neither speculation nor sharp price falls. For a short-term budget, fluctuating purchasing power can even be a serious problem. Verifiable issuance rules and stable prices are different properties.
Even so, I consider this distinction fundamental. The rules governing money creation should depend as little as possible on the discretion of individual decision-makers. Bitcoin offers an approach that can be verified in practice.
A global network needs open access
Alongside monetary rules, access determines how independently software can act. With conventional payment services, an automated purchase usually requires a business relationship established in advance. An account must exist, permissions must be in place and the provider must support the payment.
Within a company, this often works well. Things become more difficult when an agent discovers a new service during its work and needs to use it only once. The administrative effort can then outweigh the purchase itself.
Bitcoin can be received and transferred without an account with a central operator. Self-custody gives you control over the keys used to authorise payments. Anyone using a custodian instead takes on that provider's access conditions and risks.
An open payment network does not eliminate every dependency. Internet access, working software and a willing seller are still necessary. But it can provide a common foundation on which different providers can trade without first having to choose the same payment service.
Why a digital dollar does not settle the monetary question
Dollar-based stablecoins initially seem an obvious choice for machine payments. They can be transferred digitally and are intended to maintain a stable value against the US dollar. This can make them practical for prices and short-term budgets.
A dollar-based stablecoin nevertheless adopts the dollar as its benchmark. Changes in the dollar's purchasing power remain relevant. Centrally issued variants backed by reserves also introduce dependencies on the issuer, its management of those reserves and the terms of redemption.
The payment method can therefore become more modern while essential properties of the underlying monetary system remain. Anyone primarily looking for automated dollar payments may see a useful solution here. Anyone seeking monetary rules independent of a central issuer is asking for something different.
My preference for Bitcoin comes from that second question. I am interested in money whose fundamental rules are open to inspection and whose use does not necessarily require a central custodian. Whether it helps an agent operate more economically has to be demonstrated in the particular application.
Lightning makes small services affordable
For these properties to become a useful tool, the payment has to fit the service. It would be impractical to make a separate Bitcoin transaction on the blockchain for every weather query or small calculation.
This is where Lightning comes in. The network enables Bitcoin payments through payment channels. Many payments can be made quickly and at low cost without each one being recorded on the blockchain.
Software can receive an invoice, check the amount and pay it within predefined limits. Funds and a suitable payment route must be available. Fees and possible failures are part of the process.
A protocol called L402 connects these payments to access to digital services. A service initially responds to a request with a payment challenge. After paying over Lightning, the requesting program presents the required proof of payment and access credential, and receives access.
The provider determines the scope of that access. A payment might, for example, purchase a credential that can be reused. So every data request does not necessarily require a new invoice.
P.I.M.P. as a practical experiment
With P.I.M.P. Services, I am testing this idea through a small offering: a Bitcoin market indicator. The service provides an RSI14 based on hourly candles. The indicator describes the relationship between recent upward and downward movements. Software can retrieve the value and use it in further analysis.
In testnet trials so far, the process from the initial request through the Lightning payment to a verified data response has been completed successfully. For L402 access, we have also tested that a paid credential can be reused.
This demonstrates a technical process. Whether an AI agent selects the information sensibly, and whether customers want to pay for it, are further questions. A working payment method does not answer them yet.
That distinction matters to me. P.I.M.P. makes the idea tangible without requiring us to infer that a complete machine economy already exists.
A good agent must also be able to decide against a purchase
An RSI can be calculated independently if suitable price data are available. A service offering it must therefore provide more than a payment function. Its value might lie in reliable data preparation, a clearly documented format or reduced maintenance work.
The same applies to weather data, translations and computing services. An agent should first check whether existing or free resources are sufficient. Only when something is missing does an additional purchase make sense.
The frequency of requests matters too. An indicator based on completed hourly candles does not need to be bought again every second. Data that have already been paid for and remain suitable should be reusable.
An agent's economic quality therefore also shows in the expenses it avoids. An open monetary network can make buying easier. Whether a purchase should be made still needs to be assessed.
Responsibility needs technical limits
When software is allowed to spend money, it must be clear who granted that authority and how far it extends. The operating funds assigned to it therefore need a defined purpose and binding spending limits.
The agent could propose a purchase. A separate payment component then checks the amount, recipient and remaining budget. It executes only payments that comply with the predefined rules. The agent must not be able to raise those limits itself.
A limited trial could, for example, have caps per purchase and per day. Fees belong in that calculation. New providers or higher spending may require human approval. This keeps the potential damage limited even if something goes wrong.
Checking the result is just as important. A successful payment does not prove that the data supplied are correct or up to date. The agent must check whether it received the service it ordered. If a response fails to arrive, it must not blindly pay again.
Bitcoin enables greater control over your own money. Anyone delegating that control to software must shape the delegation as deliberately as any other financial decision.
The monetary question behind artificial intelligence
For me, AI above all needs money that lets it work independently within clear limits and whose fundamental properties can be verified. Bitcoin is a convincing candidate. Its weaknesses and risks belong in that assessment alongside its possibilities.
The machines do not decide what kind of money we want. That decision remains ours. That is precisely why we should make it before simply carrying the dependencies of today's monetary system into the next generation of technology.
Sources and further reading
- Bitcoin.org: Frequently Asked Questions — supply, consensus rules, control of the network and price risks.
- Bitcoin.org: About Bitcoin and its development — developers can propose changes but cannot force their adoption.
- European Central Bank: Two per cent inflation target — explanation of the medium-term monetary policy target.
- Lightning Labs: Lightning Network overview — payment channels and liquidity.
- Lightning Labs: Sending Payments — routes, fees and payment status.
- Lightning Labs: L402 protocol — paid access to digital services over Lightning.
- P.I.M.P. Services: Our own project and test reports from September 2026. The results described concern testnet trials. The proposed spending limits describe a design concept, not functionality demonstrated here.