BlueMatt's Blog On Building a Bitcoin for Everyone

Open-Source Agents Need to Get Serious About Payments

This post originally appeared as a part of Spiral’s newsletter.

At this point, we can all agree that AI agents are more capable than humans at many basic tasks. We might not want to admit it, but like the fact that your phone knows more about you than your spouse, facts are facts. However, a huge bottleneck to agentic domination remains: agents still can’t reliably buy things. Whether it’s a domain for their lobster-themed religion (a real thing that no Spiral team members subscribe to) or a flight to an upcoming conference, modern internet payment systems are built on technologies that are actively hostile to agents or, indeed, any bots.

This isn’t news. In fact, many companies from Visa to Stripe to Coinbase to Google and OpenAI, are all developing “agentic payments standards” and pushing their adoption. This leaves us at a critical juncture: as large AI labs start to offer hosted agent services, the payment standards they are pushing will not be open to anyone to implement. Whether they use proprietary, hosted models (or not), locally hosted and open-source agents allow for greater exploration and competition in the agent marketplace. If open agents don’t get serious about integrating and driving adoption of open payment rails, they’ll ultimately be boxed out, leaving only a few players allowed to build the agents we all use.

Nearly every payments industry player is trying to position itself to own the platform for agentic payments. Visa is working on an “Intelligent Commerce” product that is as yet undefined but focuses on keeping humans in the payments loop, limiting agents’ ability to act autonomously. OpenAI and Stripe announced the Agentic Commerce Protocol (ACP), an “open standard” that requires permission to implement and lacks major pieces in its specification. Google, on the other hand, announced AP2 and Coinbase announced an extension of it for crypto called x402. AP2 and x402 may be the furthest along in public-agency payment designs, but they only represent an API structure on which payment APIs for specific payment methods can be built. After x402’s announcement, the GitHub repo was flooded with PRs to support the payment APIs for every random token and blockchain you’ve never heard of.

A high-level API, like AP2, that supports every payment scheme, doesn’t actually solve anything, of course, because an LLM doesn’t actually care about specific APIs. Your agent doesn’t care if the API is REST, XML-RPC, or even something built on hand-rolled cryptography. It’s perfectly capable of calling anything that can be sufficiently specified.

What does matter is having funds available for a compatible payment method. A spec that allows for any payment method, when clients will only implement and have funds available for one or two, and merchants will similarly only accept one or two, solves absolutely nothing; payments will always fail due to a lack of payment method overlap. The x402 maintainers appear to have recognized this, and Coinbase is specifically pushing for USDC on the Base blockchain, where Coinbase conveniently collects all the interest on the tokens people are using to pay. Similarly, ACP only allows multiple payment schemes in theory, documenting only sharing credit card numbers with trusted merchants who’ve presumably signed agreements with Stripe and OpenAI.

Meanwhile, Google’s commitment to the crypto-first x402 world appears quite limited. They only tacitly endorsed it as an extension in their AP2 announcement, and haven’t appeared to make any moves towards stablecoins or any other crypto-anything since. And why would they? Google is planning to spend over 175 billion dollars this year, much of it on AI-related initiatives. Given that AI will eventually drive a nontrivial portion of total consumer spend, becoming the payment gateway for that and cutting out Visa to take that sweet 2% of every transaction for themselves would be a great way to see good returns on their investment.

On the flip side, open-source agent developers are still stuck in a “why can’t I just give my agent my credit card number and call it a day?” world. This doesn’t work for a few reasons. First of all, the chargeback mess from people declaring charges fraudulent because their agent shared their credit card number with a scam site, or even because their agent made a purchase they ultimately didn’t want, would bring Visa’s network to its knees. More importantly, the internet’s payment systems are built on a substantial investment in anti-bot technologies, captchas, and tons of effort to ensure bots can’t buy things. Whether an agent is acting on behalf of a human or not, these technologies don’t simply go away, and removing them from existing payment systems would expose merchants to the unacceptable fraud and chargebacks that led to their creation in the first place.

Given that the existing internet needs to upgrade to support agentic payments by offering purchasing paths that aren’t filled with captchas and bot detection anyway, the opportunity is wide open for new agentic payment rails to be built. As Google, OpenAI, and others start adding purchase integrations directly into their chat or hosted agent interfaces, they will be forced to focus on direct merchant integrations with those that offer purchase APIs without bot-hostile limitations. Whether they handle their own payment processing without Visa’s fees or require specific payment integrations and negotiated contracts, the net effect will be that only agents at the large AI labs can buy things.

This leaves open-source and local agents in a lurch. For an agent to be maximally useful, it needs the ability to buy things, but with merchants focused on building integrations with the proprietary payment methods pushed by the large AI labs, agents running other software will be left hobbled. Even when a few large labs control the best models, payments that drive vendor lock-in ensure there can’t be material competition (or creativity) in new agent form factors and use cases.

Given the headline-grabbing announcements about Stripe’s APIs now having options for USDC-on-Base x402, the devs not still stuck on credit cards appear to believe that we’ll live in a world where Coinbase owns both the platform that much of future commerce will happen on (Base) as well as all the revenue from interest on the float for them (in the form of USDC interest). This is rather naive—Stripe has APIs to accept many forms of payment, and merchants haven’t yet materially moved to enable accepting any specific one, let alone turn off much of their existing anti-fraud and anti-bot technologies to allow agents to use it. More importantly, Stripe has also partnered with OpenAI for ACP, offering proprietary agentic payments outside of x402.

It’s time for a serious attempt at open payments for open agents. Whatever you think of bitcoin, it was, in fact, made for this. Payments that are not built around third-party gatekeepers, unsustainable chargeback systems, and inevitable KYC roadblocks are exactly what open agents need. Stablecoins are great, but many businesses, especially internationally, simply aren’t going to accept the future of commerce being built on a platform where one company gets all the interest revenue and a single private key can arbitrarily seize funds.

While nascent, there are already a decent number of global merchants that accept bitcoin, whether for domains or VPS services that might enable agents to be self-hosted, or even for flights and gift cards at major retailers. Of course, some of those remain agent-incompatible due to widespread captchas and the internet’s general hostility towards bots, but some work fine. Better yet, there are many payment processors and wallets that hold dollars but make and accept payments in bitcoin, converting between dollars and bitcoin when needed to avoid any exposure to bitcoin’s price volatility (one of the main arguments for stablecoins to begin with).

Unlike nearly every other payment method, the fact that bitcoin wallets can be created without jumping through KYC hoops that explicitly prevent bots, be funded from many different sources (or even receive funding through an agent charging for services it offers), and work without requiring a human-negotiated and signed contract with a company or without fully trusting a single company (or single private key) to stay online and not seize your funds makes bitcoin the only compelling option for open AI agents to build on. Some have already started the work, with Moneydevkit and the L402 protocol leading the way on agentic wallet integrations, but there’s a lot more work to be done.

Agents should be reaching out to merchants with anti-bot websites and asking them to support agentic commerce (with payment methods that don’t expose them to fraud or chargebacks) instead of simply failing and waiting for everyone to build support for proprietary agentic commerce payment rails. Open agent tooling needs to push open payment methods by default, rather than ceding the ground to large AI labs that will ultimately box them out. And, most of all, we all need to use the only open payment method available, free of trusted third parties or vested interests.

Self-Custody Found Dead in Miami Condo

This post originally appeared as a part of Spiral’s newsletter.

When we started Spiral, we had no interest in being another place where a handful of bitcoin developers wrote open-source software they found interesting. Our mandate was to have a larger impact on bitcoin by making it more open and accessible to everyone in a way that neither individual open-source contributors nor unstructured open-source development had before. This meant picking the hardest problem in bitcoin and throwing all we had at it.

After taking stock of the issues facing bitcoin, we concluded that the toughest but most important problem remained building a good experience around self-custody. To truly make bitcoin electronic cash, there had to be a decentralized, private option that offered instant, cheap transactions, genuinely competing with centralized and custodial platforms.

Making Self-Custody Work

Lightning, at least if we built the infrastructure for many competing wallets to flourish, was the only remotely practical candidate that checked all the boxes. We recognized, of course, that there was simply no path to meaningful adoption for something that required a new physical device, a server, or always-on connectivity. With all the challenges that brings, we needed to enable easy Lightning integration in mobile apps.

While we built, Lightning hype came and went. Many individuals spawned nodes and let them wither before shutting them down. Lightning was the future, it seemed. But when it arrived, it wasn’t perfect, so it was a disappointment. Despite this, we continued because a more compelling, decentralized, private, and self-custodial option didn’t exist. On the other hand, much of the bitcoin community, especially bitcoin developers, pivoted. Where there was once an obsession with peer-to-peer decentralized technologies that provide the best experience possible without compromising on bitcoin’s ideals, there is now only corner-cutting.

Trust Implies Centralization

It’s worth first discussing why open-source bitcoin developers, for the first ten years of bitcoin’s life, so rarely cut corners. In my very first post on this blog, I wrote about why decentralization matters. It is, ultimately, key to nearly all of the features that drive interest in and adoption of bitcoin; if we give up on decentralization, we lose the properties that make bitcoin bitcoin. Ultimately, when only highly centralized wallets exist, the inevitable outcome for bitcoin is that it becomes universally KYC and offers no censorship resistance.

Maybe the most pernicious issue is trust. Not only is the ability to transact without trusted intermediaries a key goal of bitcoin, but increasing adoption of trusted systems drives centralization, as trust does not scale. While it’s perfectly reasonable for many bitcoiners to use trusted intermediaries (leaning on trust, after all, makes many things more efficient), there will never be a world with many trusted options.

While a small group of people trusting a service run by a friend is possible, scaling this model to enough trusted services that it can be meaningfully considered “decentralized” is far-fetched. Instead, when counterparty trust is required, we inevitably see massive centralization as people prefer larger entities due to their accumulated social capital. For example, we see this in the financial system, where the vast majority of customer accounts and deposits are centralized in the top handful of institutions, and the long tail of banks and credit unions has comparatively little use.

Given all the excitement around bitcoin finding its “everyday money” moment, it’s no surprise that many are seeking to deliver the absolute best experience, centralization and trust be damned. But sadly, when the competition cuts corners, those who might not otherwise feel compelled to are forced to as well—the most trusted option is generally the most efficient. This seems to have created a vicious cycle where there are only a handful of systems bitcoin wallets are based on, but all of them require enough trust to be irredeemably centralized.

In this domain, Lightning’s lack of required counterparty trust (or at least its ability to operate without counterparty trust) means that it’s possible for there to be self-custody Lightning wallets that are truly peer-to-peer. But here, too, in the search for an ideal and reliable experience, every competitive mobile Lightning wallet relies on a centralized LSP.

The LSP Bottleneck

This centralized LSP isn’t just a theoretical chokepoint for regulatory overhead; it has become one in practice. Many are unwilling to operate an LSP because of perceived regulatory risk. At the same time, this regulatory risk applies equally (and often substantially more) to every other centralized bitcoin wallet technology; startups with new technologies are usually more willing to take on the risk, while those building carefully and deliberately are not. Worse, regulators have increasingly been referencing centralization, not (only) control, when talking about who has KYC and AML obligations. When this view inevitably comes into regulatory force, bitcoiners everywhere will be left picking up the pieces, with a fully-KYC bitcoin being the nearly-guaranteed outcome.

If every centralized wallet backend is required, in practice, to operate with full KYC and AML, any remaining non-compliant backends will increasingly be pushed underground. Bitcoiners migrating to use fully-trusted, often fully-custodial systems operated by anonymous third-parties is obviously absurd, which leaves every trusted system that sees use in practice compliant and antithetical to bitcoin’s principles. This may leave some bitcoin in decentralized cold-storage, but when the only platforms through which bitcoin can be transacted are entirely KYC and AML, such bitcoin is effectively value-less; what is the point of a bitcoin in self-custody if you can’t use it? You might as well keep your bitcoin on paper with an ETF. The only option with any hope is to build on systems that do not require counterparty trust, which can thus decentralize without resulting in substantial theft of funds.

While the push to deliver a flawless experience is generally positive, it can also lead to short-term reliance on centralized providers for liquidity or other features. There must be a clear plan for eventual decentralization to avoid long-term risks. At the same time, these centralized providers can play a useful role by demonstrating demand and attracting new entrants, making them an important step toward that decentralized future.

Relying on trusted services with no decentralized future cannot be our answer. With a new, highly-trusted wallet backend being announced weekly, the bitcoin community’s excitement for existential risk is maddening. While the marketplace will invariably reward the best customer experience, those who know better owe it to bitcoin to discourage this trend, let alone stop building it. The fact that only reckless trusted backends are willing to take regulatory risk isn’t exactly surprising, but this demands an answer from the bitcoiners doing so—why not take less risk and steer towards a sustainable bitcoin?

The Builder’s Responsibility

To the many bitcoin engineers working hard every day to build a future they believe in, how will you decentralize it?