Moonshot ideas and feedback: The long road to bitcoin payments

[ConorOkus]

Welcome! This is the main place to discuss The long road to bitcoin payments.

Few people pay with bitcoin in everyday life, even though the technology works better than ever. The report argues the gap is mostly demand, not technology, and asks one question:

What moonshot ideas would create a believable, viable plan to accelerate bitcoin payments adoption?

We'd love your input on any of these:

• Moonshot ideas: changes big enough to shift bitcoin payments, not just improve them
• Pushback: where the report is wrong, missing something, or framed badly
• Data: payment volumes, growth, active merchants or success rates you can share publicly
• Questions: anything from the questions for readers

Sharing an idea

A rough idea is fine. If you can, include:

1. The idea: what you'd change or build
2. What it solves: which blocker it addresses
3. Who could do it: builders, payment providers, funders, platforms
4. How we'd know it's working: what you'd measure

Reply below, or start a new discussion if your idea deserves its own thread. To suggest a correction or edit the report directly, see CONTRIBUTING.md.

This is a living document, and we'll keep updating the report as we learn. Thanks for helping shape it.

[flix1]

Spending Bitcoin comes after earning Bitcoin. Make it easy for millions of people to earn Bitcoin and they will quickly spend most of it (high time preference is a fact. 2026 APC > 90% for US households).

1. Enable Bitcoin payouts on Uber, Airbnb, DoorDash...
2. Point the workers at a place that accepts those bitcoins for basic, daily needs (food, transport, housing).
3. Add some referral incentives to speed it up (payable in bitcoin ofc).

The lesson from all the Bitcoin circular economies, from Lugano to Uvita, is that people spend Bitcoin when they can earn it easily. If it's a one off windfall, they will save it, but if it's a steady stream they will spend some if not most of it.

Volatility? Taxes? Compliance? Those are middle class problems that pose zero obstacle to bitcoin spending when it's in the hands of a 20 year old nigerian student or a 30 year old Costa Rican mother.

The data is there. You need 3 things:

1. A way to EARN bitcoin.
2. An easy way to spend it.
3. A growth mechanism.

[flix1]

The idea: Make it easy for millions to earn bitcoin.
What it solves: People need to have bitcoin to spend it.
Who could do it: Any platform with 1 million+ gig workers - Uber, Airbnb, DoorDash, etc..
How we'd know it's working: Easy to do a pilot with 1000 people in one city and track their spending.

If it works, replicate and expand.

[flix1]

What evidence do I have that this idea would work?

Experience at multiple bitcoin projects that paid workers in Bitcoin. 85% of them spent ALL the bitcoin earned in a month, within a month. 15% saved some or most of it.

Did they spend or exchange for fiat? When a direct Bitcoin spending option was available, they would take it. If no direct spending option was available, they would use Bitrefill or similar spending services. Only if these two options were not available, they would exchange their sats for local currency and then spend it.

But don't believe me! Similar data has been replicated in El Salvador, Lugano, South Africa, Costa Rica... Bitcoin spending happens when there is bitcoin income coming in, spending dries up just as soon as the new income does.

Start by asking South Africa's PicknPay supermarkets for their data on bitcoin payments. (https://www.pnp.co.za/money-mobile/services/ways-to-pay/crypto) They have been accepting bitcoin payments at 1000+ locations for several years.

[barrydeen]

We need to go at least one cycle without thousands of people losing all their coins to hacks and thefts and scams and so on

[jonbyrn]

BitTasker: create demand by paying people to earn bitcoin, not just spend it

Hi Spiral team, I'm Jon, founder of BitTasker.

Your report says the problem is demand, not technology. We agree, and we think the missing piece is earning. People hold bitcoin and won't spend it, but someone who just earned sats for a job is much more likely to spend them with the next person. That's how a circular economy starts.

What BitTasker is: a no-KYC, peer-to-peer marketplace on Nostr for tasks, services, temporary staff and buying and selling. People pay in Bitcoin with escrow, and USDT is coming soon over the same Lightning-based rails. The fee is 2.5% for the Tasker and 2.5% for the Taskee. Your identity is your own Nostr key, and the app is non-custodial. It's live at bittasker.com, with an Android app on Google Play and Zapstore.

How it fits your moonshot paths:

• Shared rails: Bitcoin and dollar stablecoins sit side by side in the same app, so someone who prefers stable value doesn't have to leave the bitcoin network.
• Payments for people who need them most: we're starting in El Salvador and LatAm, with workers and merchants who have no bank account or who face capital controls. They need no KYC and no bank to get paid.
• New ways to spend: a gig marketplace is a payment that doesn't feel like a payment. You hire someone, the funds sit in escrow, the job gets done, and the funds are released. AI agents could post and pay for tasks the same way, hiring humans or other agents per job.

What we'd love from Spiral and Block: feedback on our Lightning and escrow design, introductions to wallet partners, and help growing earning-side demand in circular economies. We're happy to share anonymised data on how people pay on BitTasker as it grows.

bittasker.com · Nostr: jonbyrnebtc

[flix1]

Hey @jonbyrn ! Congratulations on BitTasker. Could you share some data?
Do you have more taskers or taskees?
What countries are your users from?
What are the most frequent tasks?

Your platform actually seems a perfect fit to do a targeted, tracked trial to see what impact taskees earning bitcoin has on their bitcoin spending...

A paid survey on bitcoin spending habits would be an easy first step.

[jonbyrn]

Thanks @flix1! Happy to share what we have. We're early and still a small team, so here are the real numbers as of 20 Oct 2026:

Users

• ~1,210 Nostr profiles have interacted with BitTasker. Most only tried it once: 81% of accounts were active on a single day, and 38 were active on 7+ days.
• Android (Google Play, 15 Apr – 16 Oct): 420 installs, ~175 active device installs, 63 monthly active devices.

Taskers vs taskees
160 people have posted at least one task. We don't track a clean tasker/taskee split yet; that's being added.

Countries
Google Play users: El Salvador 47%, US 16%, then Canada and Guatemala.

Most frequent tasks
We don't track categories yet. We're adding that to our analytics now.

Activity
Tasks posted peaked at 62 in Nov 2025 and were 3 / 4 / 8 in Aug / Sep / Oct 2026. Completed paid tasks aren't measured yet either. That's being added too.

The trial and survey: yes, very interested. A targeted, tracked trial is exactly what we'd like to run: do taskees who earn bitcoin go on to spend it, and where? A paid survey on bitcoin spending habits is a great first step. We'd start in El Salvador, where most of our users are and where I live, then expand. Payment is in Bitcoin with escrow (USDT coming soon), and the fee is 2.5% for the Tasker and 2.5% for the Taskee.

Happy to work out the design with you. What sample size and survey format do you have in mind?

— Jon (bittasker.com · Nostr: jonbyrnebtc)

[Marc26z]

I tried it once, but the userbase needs to grow. I also think most people will choose stable coins if you add that option. That's not ideal, but there's a high demand for digital fiat bucks.

[HaosGames]

Don't wait for businesses to accept Bitcoin. Start your own business of the same category that you want to see accepting Bitcoin. Or start a reseller. My thinking ist that you can fairly easily start reselling essential Services and accept Bitcoin.

[linasantlinijos]

This is a great initiative, thank you! My research partner and I published our suggestions this summer. The core idea is this: Bitcoin payment products and services need to be designed for their ecosystems as a whole. This requires teams to shift the now-dominant engineering-driven mindset to a more product-driven one.

Imagine what we’d achieve if we started putting at least half of the effort we put into tech development into designing BTC products and services for their ecosystems as a whole, whether it's payments, financial services, or anything else.

Also, let's finally add users' already overstimulated and overwhelmed brains (a.k.a. people's brains) into this complex equation - this might yield huge results.

If all these things are addressed properly, this could be the Cambrian explosion of bitcoin payments 🤝

[shocknet-justin]

1. Drop the mobile node fantasy, that's upstream of most of the stupidity and time wasted

2. "New ways to spend"

Again downstream of number 1, backwards framing, people don't want new ways to spend... they want new ways to earn.

You can't earn while your mobile node is a sleep.

3. Holders would rather save than spend

This is a tailwind, not a headwind, if you understand points 1 and 2. People can only spend Bitcoin when someone wants to accept it. Wanting to hold is the same as wanting to accept.

YOU CAN'T MEANINGFULLY ACCEPT WITH A MOBILE NODE

The moonshot is running a Lightning.Pub with CLINK to power earnings apps like Lightning.Video, Bxrd, and ofc SN.

[flix1]

First: Release data on what has happened with the "4 million" Square merchants that were accepting Bitcoin since June.
You have the merchants. Now you need 20 million shoppers.

You won't find those shoppers among the finance bros. The best way to find them is at the merchants themselves, among their already existing customers, who are most likely to be repeat clients.

From there on it's a classic marketing strategy:

1. Gather data (survey of clients incentivised with free product or discount)
2. Identify target audience
3. Run pilot marketing program (incentives, satsback, free stuff, discount, referrals, etc.) Do some A/B testing with 1000 target clients.
4. Repeat and amplify with what works best.
5. Once you have a well honed strategy - launch campaign to 57 million CashApp users.

[flix1]

Block Inc. owns Cash App with 57 million users. It owns Square with 4 million merchants.

Square merchants accept Bitcoin. Cash App users can buy, send and receive Bitcoin.

...and yet jack does not know how to connect the two of them. How to make Cash App users spend sats at Square merchants.

Surely this type of marketing problem has been solved before...

[flix1]

Cash App even has a referral program: https://cash.app/help/us/en-us/3136-referral-bonus

Make a new pilot incentive program targeted at 10.000 users that already have bitcoin. If you spend some bitcoin at a merchant every day for 5 days, you get X money back in sats. The 5 day requirement should make them use it at a merchant that is already within their routine. Pick all the pilot participants within one area, to attempt to achieve critical mass.

[nothing-stops-this-train]

There is a major elephant in the room when it comes to adoption: Bitcoin cannot scale to 6 billion people and we don't seem to have any way to make it. Even if only a quarter of users did self-custody and we used every part of blockspace to open only a single channel for those users, assume channels never closed, etc, you're looking at 50+ years to onboard everybody to lightning. So Lightning can't scale to 6 billion people either, plus comes with a host of other nasty UX issues (liquidity management, random channel closes, having money locked up for weeks in a force close, etc). I use lightning daily, but I recognize I am in the 0.01% of users who are willing to put up with it. Ark, Spark, and other proposals centralize the network and offer unilateral exit to a chain that can't be used for unilateral exit due to lack of space.

Before we get any real merchant or end user spender adoption, we need to solve scalability, it's why large players aren't enthusiastic about adding BTC support to their stacks: they know L1 is going to get clogged up with high fee spikes. And every time that happens, we have seen a mass exodus from Bitcoin to other coins which out-compete Bitcoin for "cheap transaction" use case.

The only real proposal I have seen that solves these issues without sacrificing decentralization, destroying UX, or relying on fantasies like "unilateral exit" to a chain with no room is the BIP300/BIP301 drivechain proposal (fork happening right now at ecash.com). These kinds of changes, or other changes, which could potentially fix the scaling issue are impossible to get through because Bitcoin core's dev policy is to not accept any even mildly controversial PR. We've had one significant softfork (taproot) in the last ten years, the protocol has become impossible to upgrade. Drivechains also solve that as you can build different consensus rules "on top" of Bitcoin (as L2s) without having to change core consensus, allowing users to decide tradeoffs (speed vs decentralization vs privacy vs security) one transaction at a time instead of it being a holy war to get 51% of hashpower behind it. it would end competition from altcoins and get everybody back to building the same network together. Drivechains are an idea that has been around for 10 years but unfortunately never seemed to get even 10% of the coverage that silly fights like BIP 110 did.

And those are just the technical problems.

I am working on merchant adoption FWIW, I've spent years building a whole tech stack around lightning including plugins for the Electrum wallet to manage liquidity, accept payments without port forwarding using CLINK. And a self-hosted payment processing tool that doesn't require a VPS.

[Marc26z]

I don't know how we get big companies like Meta to adopt Bitcoin, but I think it starts with making The People aware that Bitcoin can be used as money.

I would love to see employees at places that accept Bitcoin accept Bitcoin tips. I got the idea when Steak N Shake started marketing to Bitcoiners. Now that Square terminals also work there are more places that accept Bitcoin.

I drew the art myself and wrote the lightning:myaddress@cash.app stuff, but I mostly vibe coded this.

https://github.com/Marc26z/LightningTipJar

Bitcoin is for the people not just the corporations. At least that's how I see it.

[MegalithicBTC]

Originally we wanted to do "Lightning Only" -- but when rolling out payments to merchants, they basically said "support USDT or go away."...

So -- Our take: Lightning as the unstoppable "last mile" for any kind of payment -- BTC, USDT, USDC, etc. That's the theory with which we've build this: https://openreceive.org/

[Marc26z]

Why are stablecoins so popular? Maybe the Bitcoin backed stablecoin isn't such a bad idea after all.

[bkeroack]

The biggest gap is demand not technology. This was probably less true circa 2009, but today fast payments are ubiquitous in the fiat world. There's been a long trail of dead and failed Bitcoin payments startups and projects since. Lightning was built to give fast transactions to Bitcoin, but the problem is few want to integrate with it. Usage is low and integrators see abuse (for example, users depositing to exchanges via LN but then withdrawing on-chain, making the exchange eat the bridging fee).

Payments is a race-to-the-bottom with whoever is cheapest and most ubiquitous winning, which we've seen with the dominant on-chain payment rails today. First Ethereum, then Tron, then Solana. Each taking market share from the other when the new network can do it cheaper, faster or both. Bitcoin can't (and shouldn't) try to compete here. Ethereum lost execution volume to Solana and kept the stablecoins and the blue-chip collateral because it held the assets on the best terms. That is the question Bitcoin layers should be asking: not "how do we move BTC faster" but "where does the BTC sit while it is being used, and whose key controls it".

Demand for using BTC as a store-of-value collateral is real and substantial, as evidenced by lots of wrapped BTC products (wBTC, cbBTC, etc) and it's one of the main value drivers for DeFi systems. This is real demand, in contrast to BTC payments which has almost none.

"Self-custodial tooling is still harder to run at scale" is true to an extent, but also over-weights LN. Lightning is indeed difficult and cumbersome to run at scale, and that's one of its biggest downsides. That is a weakness of that specific technology, and isn't necessarily true of all conceivable payment rails. Self-custodial, fast, offline receive is an attractive option that is currently unsolved. On LN the receiver needs inbound liquidity, a route, and to be online. That is a property of channels, not of Bitcoin. A UTXO layer where each holder's coins sit in an L1 output carrying their own key, with a unilateral exit option, has none of those: you can receive while offline, there is nothing to rebalance, and a third party can pay the fee inside the same transaction so the recipient never needs a BTC balance to get started. That doesn't create demand either, but it removes the operational reason a self-custodial integration costs more than a custodial one.

Bitcoin should lean into SoV which already has PMF, and avoid trying to compete where margins are low and there is no moat.

• Consumer retail is almost certainly a dead-end.
• Financial repression (capital controls) is a use-case, but if someone is trying to escape currency debasement/collapse, I don't think 10 min block times (30-60min to finality) is a significant deterrent.
• Agentic payments are an interesting use case, but also hard to see why BTC would win over stablecoins or bespoke fiat agentic payment gateways.

[jpgaviria2]

A merchant perspective: the missing piece is native integration

At Trails Coffee, our approach is to give people some sats before asking them to spend sats. They can experience Bitcoin in an ordinary setting—earning a reward and buying coffee—before being asked to understand the whole monetary system.

That sounds simple from the customer side, but it has required a substantial amount of custom engineering behind the counter.

Earn first, spend second

One of the report's blockers is that people cannot spend Bitcoin they do not have. We have tried to address that directly by recreating the familiar Starbucks Stars model with real sats.

before a payment, a customer can check in by scanning a Lightning address QR, LNURL-withdraw reward, or tap a Bolt Card. Instead of receiving proprietary points that only exist in our database, the customer receives Bitcoin that can leave our system and be used elsewhere.

Our current rewards model is:

• Pay with fiat and receive 3% back in sats.
• Pay with sats and receive 10% back in sats.
• Place a mobile order and pay with sats to receive a 10% discount in the Trails Coffee app.

The discount and rewards create a progression: receive sats, see them arrive, use them for something familiar, and then decide whether to learn more.

We have also learned that simply creating a reward is not enough. We have hundreds—possibly thousands—of unclaimed BTCPay Server pull payments because customers did not scan the LNURL-withdraw QR code to claim their sats. That is useful evidence about onboarding friction: even free Bitcoin can go unclaimed when receiving it requires an unfamiliar extra step.

Bolt Cards, saved Lightning addresses, and app wallets help remove that step. A native Square implementation could go further by attaching a reusable Bitcoin reward destination to the customer relationship and crediting the reward automatically after an eligible purchase, while still allowing the customer to withdraw to a wallet they control.

The stack we are building

Our current work spans several systems:

• Square for the product catalogue, pricing, taxes, discounts, orders, receipts, reporting, and kitchen workflow.
• BTCPay Server for Bitcoin and Lightning invoices, payment verification, webhooks, and Bitcoin-native merchant infrastructure.
• Custom BTCPay Server plugins, including a Bitcoin Rewards plugin, to connect Square transactions with rewards, Lightning pull payments, customer balances, and merchant workflows.
• A custom integration layer that waits for a Lightning payment to settle, then creates or completes the corresponding Square order and records Bitcoin Lightning as an external payment. This keeps the order visible in the same operational system used by the café.
• A native iOS app and native Android app for ordering, Lightning payments, wallets, rewards, and customer identity.
• LNbits for Lightning wallet and account experiments and supporting operational flows.
• Bolt Cards and NFC, so a customer can tap a physical card to identify a reward destination instead of needing to understand invoices, LNURL formats, QR codes, or wallet mechanics before participating.
• Supporting APIs, exchange-rate handling, idempotency, payment-state tracking, reconciliation, monitoring, and failure recovery.

The customer should experience something simple: choose Bitcoin, pay, and receive the coffee. The merchant currently has to connect two financial and operational worlds to make that possible.

Where a native Square solution would help

Square already owns the merchant workflow. It knows the catalogue, order total, taxes, discounts, location, receipt, kitchen ticket, inventory, and reporting context.

A native Square Bitcoin and Lightning tender could remove a large amount of duplicated integration work. Ideally, it would:

1. Let a merchant enable Bitcoin or Lightning beside cash and card payments.
2. Generate the payment request directly from the Square order total.
3. Lock the BTC/CAD exchange rate for the checkout period.
4. Mark the Square order paid only after settlement is verified.
5. Preserve the existing receipt, inventory, tax, kitchen, refund, and reporting workflows.
6. Let the merchant choose settlement in Bitcoin, Canadian dollars, or a configurable split.
7. Work across Square POS, Square Online, APIs, and mobile ordering.
8. Provide webhooks and APIs so merchants can build rewards and other experiences around the payment.
9. Let customers save or present a Lightning address, LNURL, app wallet, or Bolt Card as their reward destination.
10. Automatically deliver sats rewards instead of creating claim links that many customers never redeem.

This would let small merchants focus on creating reasons for customers to use Bitcoin instead of rebuilding payment orchestration and reconciliation.

Please bring native Bitcoin payments to Canada

The Canadian market matters. Trails Coffee is in British Columbia, and we would like to test and use Square's native Bitcoin payment capabilities here—not only read about a US rollout.

Canada has Square merchants, Bitcoin users, strong Bitcoin companies, and ordinary businesses willing to experiment. Making the feature available here would provide useful merchant and customer data from a market with different tax, banking, and payment conditions.

We would be interested in participating in a Canadian merchant pilot and sharing practical feedback from a working café environment.

Our adoption approach

We do not expect most customers to attend a Bitcoin lecture before receiving or making their first payment. We give them sats as a reward, let them see a real balance, and provide an immediate place to use it. That small experience can produce better questions than an abstract explanation.

At our Trails Tech meetups, we then discuss topics such as:

• open-source software versus open protocols and open networks;
• portable identity and Nostr;
• payments between people, services, and autonomous agents;
• HTTP 402 and machine-readable prices;
• micropayments and economic friction against spam;
• what makes a settlement network open and neutral.

These conversations can lead naturally to Lightning and Bitcoin because participants first identify the problem and the properties a solution needs. Bitcoin becomes a practical answer rather than the required starting belief.

Our working hypothesis is:

Let people earn sats before they need to spend them. Practical use creates curiosity, and curiosity creates the opportunity for deeper understanding.

A native Square integration would make this model far easier for other merchants to reproduce.

Try the Trails Coffee apps

• Download Trails Coffee for iPhone and iPad
• Download Trails Coffee for Android

We are happy to share what we have learned from connecting Square, BTCPay Server, mobile wallets, rewards, LNbits, and NFC-based Bolt Cards in a real merchant environment.

[nothing-stops-this-train]

This is really insightful thank you for sharing this. The idea that you have to get people to have BTC in the first place before they want to spend it is spot on. I really like the idea of giving users a small cash back in BTC even if they pay in fiat, as it gradually moves them into the BTC ecosystem. And given the savings to merchants, this promotional effort is essentially free.

[jpgaviria2]

This is really insightful thank you for sharing this. The idea that you have to get people to have BTC in the first place before they want to spend it is spot on. I really like the idea of giving users a small cash back in BTC even if they pay in fiat, as it gradually moves them into the BTC ecosystem. And given the savings to merchants, this promotional effort is essentially free.

yes friction is very hard at the start. Trying to simplify the experience, the wallet is not the main. We are working with the guys at breez with their campaign to give free coffee to our customers, the catch is that you have to use Glow app to pay for coffee with Bitcoin first, for new users getting the $5 on bitcoin is the highest friction. Despite the advertisement by them and us we didn't get many participants.

[Marc26z]

I love the idea of giving more sats back if you pay with Bitcoin than if you pay with fiat. The Glow Wallet has a Cash App button, but I guess it has to be available in your country.

[hans-schmidt]

I believe that we must find a way for Bitcoin to be the payment vehicle for assets of all types: tickets, coupons, NFTs, and real-world tokenized real estate, commodities and securities.

See the attachment for details.
EvrLight-_Asset_Payments_on_Lightning_2026-10-27.pdf

[refined-element]

Bitcoin’s Biggest Payments Opportunity May Be an Economy of Autonomous Agents

I’ve been working on this problem from the perspective of AI agents, building Lightning Enable (https://lightningenable.com/) and experimenting with autonomous payments, L402, Lightning, stablecoins over Taproot Assets, and delegated spending authority.

My biggest takeaway is that we may be approaching Bitcoin payments from the wrong direction.

Instead of asking how to convince more people to spend Bitcoin on things they already buy with dollars, we should be asking what entirely new economic activity becomes possible when software can autonomously exchange value.

I think AI agents offer one of the strongest answers to that question.

1. Agents Don’t Need Checkout. They Need Economic Agency.

Consider an AI agent working on a task. It needs access to specialized research, a paid API, another model’s expertise, or computational resources it doesn’t have locally.

Today, that generally means the human needs to establish accounts, manage subscriptions, provision API keys, and arrange payment relationships in advance.

But why?

An agent should be able to discover a useful resource, evaluate its price, determine whether the purchase is authorized, pay for it, and continue working.

The human cares about the result. The payment is simply part of the agent’s execution.

This is where I think Bitcoin has an extraordinary opportunity. We’re not talking about replacing a credit card at a grocery store. We’re talking about potentially millions of software agents exchanging small amounts of value for capabilities, information, and services.

Many of those transactions may be too small, too frequent, or too dynamic to justify traditional payment relationships.

The killer application for Bitcoin payments may be one where the human never consciously makes a payment at all.

2. Why I Believe L402 Is Particularly Well Suited to This

I’ve built Lightning Enable around L402 because I believe its architecture is an exceptionally good fit for machine-to-machine commerce.

An agent requests a resource. The service responds with an HTTP 402 challenge containing payment information and an authentication macaroon. The agent pays the Lightning invoice, receives the payment preimage, and presents the proof alongside the macaroon to access the resource.

The macaroon provides a mechanism for expressing authorization conditions, while the preimage demonstrates knowledge of the Lightning payment secret.

This allows payment and resource access to become part of an ordinary HTTP workflow.

No merchant-specific account needs to be established for every transaction. No subscription needs to exist before an agent can discover a useful service.

The architecture also opens possibilities beyond simple purchases. Macaroon caveats can constrain delegated authority, and additional runtime controls can enforce spending policies.

I think this combination of payments, authentication, and programmable authorization is significantly more interesting than simply attaching a wallet to an AI model.

One practical lesson from building this: payment preimages are essential infrastructure, not an implementation detail.

Early in development, I asked Strike to expose Lightning payment preimages through its API. They subsequently added support, which enabled the payment-proof workflow I needed.

A payment provider returning “success” is insufficient when the application needs cryptographic proof to unlock a resource.

These are the kinds of interoperability details that determine whether agent payments actually work.

I’ve documented these integration challenges and the importance of complete, verifiable purchases here:

L402 Is Ready. The Missing Layer Is Adoption (https://docs.lightningenable.com/blog/l402-is-ready-the-missing-layer-is-adoption).

3. Economic Independence Requires Permissionless Payments

There’s another dimension to this that I think becomes increasingly important as agents become more capable: economic independence.

An AI agent may be able to reason, write software, discover services, and coordinate with other agents. But if every transaction requires permission from a centralized payment provider, its economic autonomy remains dependent on that provider.

This isn’t just about transaction fees or settlement speed.

It’s about who gets to participate.

Traditional payment infrastructure generally assumes identifiable customers, established merchant relationships, approved business models, and intermediaries capable of restricting access.

Those arrangements may be appropriate for many transactions, but they aren’t necessarily well suited to an open network of independently operated agents discovering and purchasing services from one another.

Bitcoin offers something fundamentally different: an open monetary network that doesn’t require a central operator to approve participants.

Lightning extends that capability to small, frequent payments. L402 connects those payments to authorization and access to digital resources.

That combination is particularly compelling for agents operating across organizational and geographic boundaries.

Imagine an independent developer publishing a specialized AI capability. An agent operating elsewhere discovers it and wants to purchase a single request.

Why should those two parties need a preexisting relationship with the same financial intermediary?

They should be able to transact because the service is useful, the price is acceptable, and the agent has the authority to spend.

This doesn’t eliminate the need for security, legal compliance, or responsible controls. It also doesn’t mean every wallet or Lightning service is equally permissionless. Custodial infrastructure can reintroduce dependencies.

But it creates an architectural foundation where centralized permission isn’t an inherent prerequisite for exchanging value.

If we’re building an internet where software can autonomously exchange information, we should seriously question whether exchanging value must remain dependent on institutional permission.

I think that’s one of Bitcoin’s strongest advantages over issuer-controlled payment systems, and it may become considerably more important as agent-to-agent commerce develops.

4. Stablecoins and Bitcoin Aren’t Necessarily Competing for the Same Role

I’ve also spent considerable time exploring dollar-denominated payments over Lightning.

Working with AMBOSS and Taproot Assets infrastructure, I demonstrated an agent purchasing an L402-protected resource using dollar-pegged asset funding, with conversion occurring along the payment path.

The agent ultimately completed the purchase using the expected Lightning payment proof.

That experiment was particularly interesting because it demonstrated that the funding asset and the merchant’s payment interface don’t necessarily need to be the same.

I think this distinction matters enormously.

A merchant may want to price services in dollars. An agent may have a Bitcoin balance. Another agent may operate with a dollar-denominated budget.

Why should those preferences prevent them from transacting?

My own commerce experiments reflect this. For physical merchandise, I use dollar-denominated prices that convert to sats when quoted. For small digital services, fixed sat pricing can make more sense.

I’ve experimented with both approaches in the Lightning Enable Store (https://store.lightningenable.com/), including an agent-driven custom T-shirt workflow that uses L402 payments and requires human approval before production.

Pricing and settlement are separate concerns.

I also think we should distinguish between currencies people voluntarily hold and currencies they’re required to use.

I don’t believe most people will voluntarily accumulate something like a hypothetical “ChaseCoin” as a long-term monetary asset when they can hold Bitcoin or a broadly accepted dollar-denominated instrument.

They might temporarily hold or acquire ChaseCoin because a particular institution requires it, but that’s a very different kind of demand.
Stablecoins can be useful payment instruments, but they also introduce issuer dependencies, redemption assumptions, and potentially significant control over transactions.

Bitcoin offers something fundamentally different: a monetary asset that doesn’t depend on a particular issuer’s promise.

I don’t think Bitcoin needs to eliminate dollar-denominated transactions to succeed. But I also don’t think moving dollar liabilities between institutions is equivalent to adopting an independent monetary system.

The interesting question is how we preserve Bitcoin’s monetary properties while making it economically useful across different payment preferences.

Shared Lightning infrastructure, including the possibility of dollar-denominated assets moving through compatible payment workflows, deserves serious attention.

5. Giving an Agent a Wallet Is Only the Beginning

One of my goals with Lightning Enable has been to make it straightforward for developers to give agents the ability to transact.

I’ve built a free, open-source MCP server, HTTP payment clients, agent SDKs across Python, TypeScript, and .NET, middleware for protecting existing APIs, and additional tooling for discovering and interacting with paid services.

I’ve also worked on NostrWolfe for agent-service discovery, negotiation, agreements, and coordination.

These tools demonstrate that much of the underlying technology is already practical.

But I don’t think simply giving an agent a funded wallet is the final answer.

An agent needs boundaries.

How much can it spend? On what? Under whose authority? Can it delegate a narrowly defined capability to another agent? How do we know what it purchased and whether the work was completed?

These questions led me to experiment with Writ (https://writ.lightningenable.com/), which explores bounded work, delegated capabilities, macaroon caveats, and payment receipts.

In one experiment, an agent conducting a research task purchased an external AI research response over L402 for 15 sats and incorporated the result into its deliverable.

That’s a small transaction, but the implications are much larger.

An agent can potentially recognize that another service possesses information or expertise it needs, purchase that capability, and continue toward completing its original assignment.

The important part isn’t the 15 sats. It’s that the payment becomes a normal part of executing work.

We’re still early. These experiments don’t establish that unrestricted autonomous commerce is safe or economically viable.

But they demonstrate a direction worth pursuing.

For anyone interested in the implementation side, I’ve published several components:

• Lightning Enable MCP Server (https://github.com/refined-element/lightning-enable-mcp) — Open-source tooling for connecting AI agents to Lightning wallets and L402-protected resources.
• Lightning Enable Skills (https://github.com/refined-element/lightning-enable-skills) — Agent workflows for discovering, purchasing, and selling services over Lightning.
• NostrWolfe (https://github.com/refined-element/nostrwolfe) — Agent Service Agreements on Nostr, including discovery, negotiation, and Lightning settlement.
• Python Agent SDK (https://github.com/refined-element/le-agent-sdk-python)
• TypeScript Agent SDK (https://github.com/refined-element/le-agent-sdk-ts)
• .NET Agent SDK (https://github.com/refined-element/le-agent-sdk-dotnet)
• Lightning Enable Documentation (https://docs.lightningenable.com/) — Developer guides covering L402, payment integration, and agent workflows.

The goal is to make buying or selling a useful capability something a developer can add without becoming a payments specialist.

6. Paying for Compute, Expertise, and Eventually Work Itself

I think we’re going to see increasingly sophisticated markets for AI inference, specialized models, research, data, and computational services.

An agent may need a particular model for reasoning, another for image generation, and a specialized service for verification.

Instead of subscribing to all of them, it could purchase exactly what it needs.

This introduces another interesting possibility: the relationship between AI tokens and satoshis.

Today, tokens are primarily a measure of model input and output. They are useful for metering computational consumption, but they aren’t a universal measure of the economic value produced.
Over time, I could imagine agents managing budgets in sats while purchasing token-metered inference, compute, and specialized services.

The satoshi could become a common monetary unit for machine work, even though the underlying costs and value of individual tasks vary.

I don’t mean that one token should equal one satoshi. The relationship would be determined by markets, computational costs, and the value of the services being purchased.

The more interesting possibility is that AI systems begin participating in an economy where capabilities have discoverable prices and payments can occur without traditional commercial relationships.

Bitcoin and Lightning could provide an important part of that infrastructure.

7. Voice Interfaces Could Make This Invisible to Users

One area I haven’t explored deeply enough is voice.

Imagine telling an assistant:

“Research this issue, consult additional sources if necessary, and prepare a report. You have a budget of 5,000 sats.”

The assistant could discover paid resources, evaluate their usefulness, purchase access, and return the completed work.

The human doesn’t need to understand Lightning, payment preimages, or L402.

They only need to understand the task and the budget they’ve authorized.

Of course, the interface must not substitute for actual authorization, spending controls, and accountability.

But I suspect this kind of interaction will eventually feel far more natural than managing individual subscriptions and API credentials.

8. The Adoption Problem Is Real

I agree with Spiral that demand is the central challenge.

I’ve seen substantial interest in Lightning Enable’s developer tooling, but downloads, integrations, and successful demonstrations shouldn’t be confused with sustained economic activity.

The meaningful indicators are repeat purchases, useful services, satisfied customers, and economic activity that wouldn’t otherwise occur.

I also think we need to be careful about trying to manufacture demand through incentives alone.

Paying people to spend Bitcoin may produce transactions, but that doesn’t necessarily create a sustainable reason to continue spending it.

A more durable approach is to make Bitcoin payments the easiest way to accomplish something genuinely useful.

For AI agents, that could mean accessing a service that would otherwise require a subscription, acquiring specialized expertise in real time, or paying another agent to complete a narrowly defined task.

This creates a reason to transact that exists independently of enthusiasm for Bitcoin.

9. What Would Actually Make a Major Platform Adopt Bitcoin?

Spiral asks what it would take for companies like OpenAI, Shopify, or Meta to accept Bitcoin.

I think there’s an important distinction between convincing these companies to accept Bitcoin at checkout and creating an economic environment where supporting Bitcoin becomes useful to their products.

The second opportunity may be much larger.

Consider an AI platform operating millions of agents.

Those agents increasingly need access to capabilities outside the platform’s own ecosystem: specialized models, independent research providers, proprietary datasets, computational resources, and services developed by third parties.

The platform has several options.

It can negotiate commercial agreements with individual providers, build an internal marketplace, require developers to establish billing relationships, or attempt to intermediate every transaction itself.

But there’s another possibility.

It could allow agents to purchase external capabilities directly through an open payment protocol, subject to user-defined budgets and platform security policies.

Suddenly, Bitcoin support isn’t primarily about satisfying customers who want to spend Bitcoin.

It’s about giving agents access to a broader economy of services without requiring the platform to establish a commercial relationship with every provider.

For Shopify, the opportunity extends beyond accepting Bitcoin for existing purchases.
Merchants could expose capabilities that agents purchase programmatically, from inventory information and custom manufacturing to digital products and fulfillment services.

For AI platforms, the opportunity is even more direct: an agent that can purchase external expertise may become substantially more useful than one limited to its provider’s existing integrations.

The incentive to support Bitcoin emerges from the additional capabilities and economic activity it enables.

Of course, major platforms could attempt to accomplish this with stablecoins, proprietary credits, or centralized payment networks.

That’s precisely why I think open interoperability matters now.

The goal shouldn’t be to convince every major platform to adopt Bitcoin out of philosophical agreement.

The goal should be to make open, permissionless payments so useful to agent workflows that excluding them becomes a competitive disadvantage.

If we can demonstrate that agents complete valuable work more efficiently because they can discover and purchase external capabilities, we’ll have a much stronger argument than simply asking another platform to add Bitcoin checkout.

And importantly, this doesn’t require every user to hold Bitcoin or every merchant to price in sats.

It requires an open economic interface that agents and service providers can actually use.

10. My Moonshot: Build an Open Economy of Purchasable Capabilities

If I were proposing a moonshot, it would be to make any useful digital capability economically accessible to an AI agent without requiring a preexisting commercial relationship.

That means combining several pieces:

1. Discovery: Agents can find services capable of performing useful work.
2. Pricing: Services can quote prices dynamically in sats, dollars, or other supported units.
3. Authorization: Users can delegate bounded purchasing authority without surrendering unrestricted control over their funds.
4. Settlement: Agents can make small, fast payments and obtain verifiable proof.
5. Access: Payment unlocks the purchased capability through standard interfaces.
6. Accountability: Users can inspect what was purchased, what it cost, and what was delivered.

Much of this is already possible in isolation.

The opportunity is to make the complete experience simple enough that developers choose it because it solves a problem, not because they’re Bitcoin enthusiasts.

I would love to see Spiral and Block invest in end-to-end demonstrations that combine wallets, discovery, L402-protected services, constrained delegation, and meaningful paid work.

Not another demo showing that an agent can send a payment.

A demonstration showing that an agent can accomplish something valuable specifically because it can transact.

Then measure whether people continue using it.

I’d go a step further and suggest a measurable experiment: fund a small ecosystem of independent service providers, equip agents with bounded Lightning wallets, and evaluate how often those agents discover and purchase external capabilities while completing real user tasks.

Measure successful paid requests, repeat usage, cost per completed task, and the percentage of purchases that occur without a preexisting billing relationship.

Compare those results with equivalent workflows using conventional APIs, subscriptions, and stablecoin-based payment systems.

If Bitcoin and L402 provide a meaningful advantage, it should be measurable in the work completed, not merely in the number of transactions.

11. One Final Thought

I don’t think Bitcoin has failed if people prefer saving it today.

A good monetary asset doesn’t become less valuable because people are reluctant to part with it.

But I do think there’s a tremendous opportunity to make Bitcoin economically productive without abandoning its monetary principles.

Stablecoins will likely play an important role in digital commerce. Some users will prefer dollar stability, and some institutions will require particular payment instruments.
That doesn’t mean Bitcoin needs to surrender the emerging machine economy to issuer-controlled currencies.

We should build systems where people and agents can choose what they hold, where merchants can choose how they price, and where payments remain open, interoperable, and accessible.

My strongest conviction after building and testing these systems is that we don’t need to convince people to spend Bitcoin merely for the sake of spending Bitcoin.

We need to create useful things that are only possible, or dramatically better, when software can exchange value as easily as it exchanges information.

AI agents may be our best opportunity to prove that.

⸻

Michael Rahel
Founder, Lightning Enable (https://lightningenable.com/) / Refined Element (https://refined-element.com/)

[ojomaoochai]

I wonder if part of the challenge is who we're asking to imagine what Bitcoin could be useful for.

We've made important progress expanding who can build Bitcoin technology. But perhaps we need to invest just as deliberately in expanding who gets to define the problems it should solve. People who understand commerce, creative industries, informal economies, consumer behaviour and everyday livelihoods. People who might see opportunities that those already inside the Bitcoin ecosystem are missing.

Particularly in parts of Africa and other Global Majority contexts, I think we need to move beyond holding to earning and spending Bitcoin. But that means confronting a difficult question: why would someone choose Bitcoin over stablecoins or other payment options? We need to find economic activities where Bitcoin offers a genuine advantage, rather than assuming demand will follow the technology.

Take intra-African payments, for example. Despite innovations like PAPSS, stablecoins and local fintech solutions, paying someone in another African country can still be surprisingly difficult or expensive, particularly for small businesses, freelancers and creators. Could Bitcoin, perhaps through Lightning, solve some of these problems better? I don't know. Much of the friction is in converting between currencies and getting money into and out of local financial systems, which Bitcoin doesn't automatically solve. But that's exactly why I'd be interested in starting with the people making these payments, identifying where existing options fall short, and testing whether Bitcoin offers a meaningful improvement in cost, speed, access or reliability. And importantly, whether people would choose to keep using it.

So here's the moonshot I'd propose: bring entrepreneurs, traders, creators and people from different industries together to identify real economic problems that Bitcoin might solve better than the alternatives. Pair them with developers, fund experiments in real markets, and measure actual use and repeat choice, not just technical performance.

I also think media / culture and storytelling have a much bigger role to play. We spend a lot of time talking about Bitcoin within the Bitcoin ecosystem, reinforcing our own beliefs and philosophies. Meanwhile, most people are far more interested in what technology enables them to do than in understanding how it works. We need to take these conversations into mainstream entertainment, film, music and popular culture and debate, using real examples of utility to help people imagine Bitcoin differently.

The next breakthrough may not be another technical innovation. It might come from asking different people to solve different problems, and giving them the resources to try.

[GBKS]

When I think of moonshot, I think of sci-fi ambitions. Things that would be cool and seem intimidatingly huge and ambitious, almost to the point of silliness. I'll throw out some ideas:

Replace online advertising with bitcoin payments
The Cloudflare CEO says we would need 100 million transactions per second for that. Great, let's figure that out. It has to be bitcoin (lightning, ark, etc) because public blockchains would just be another surveillance system that tracks and annoys us constantly. This is the moment, as AI crawlers are taking over the internet. Wouldn't it be cool? Can we work with Cloudflare to make it happen (in a bitcoin way)?

End email spam
Similar to the idea above, but email spam. We all hate it. Bitcoin came partially out of Hashcash. Make a tiny payment to send/receive, the lightning preimage is the proof. Let's build an email client and get 1 million people to use it.

Visa without visa
Can we get self-custodial bitcoin cards accepted for tap-to-pay just like regular credit cards? With on-the-fly dirt-cheap instant atomic swaps? I have no idea, but would be cool and would allow for payments everywhere.

Ikea solar panel miners
Ikea sells pretty affordable solar-panels for your home. Let's add in miners (BitAxes?), so everyone who lives in a sunny place can earn super conveniently. Let's stream sats per hour via Ark. And add ways to convert to spend locally for the most convenience (enabling earning is already a great step). Can we get Ikea on board?

Fun to brainstorm these. Hope it's a useful addition to the conversation.

[jpiece3]

Hey wrote this 4 years ago, still believe it's a good way to start.

https://yoimtraveling.ghost.io/a-town-on-lightning/

Summary:
Getting Shopify or Meta to accept bitcoin is hard, but it’s not the first step. First people need a reason to spend it. Holders would rather save and merchants want dollars, so we need to change the incentives on both sides.

I wrote about doing this at the town level. Local small businesses run a Fedimint federation as the guardians, so they have skin in the game.

🏘 Businesses hold bitcoin, earn Lightning yield (small), and put it back into town projects they decide on

👥 Customers get a % off for paying with Lightning, equal to the card fees the business saves

More businesses, more discounts, more customers. I call it the 𝗢𝗽𝗲𝗻 𝗧𝗮𝗯 𝗘𝗳𝗳𝗲𝗰𝘁. It’s like a rewards program for an entire community.

Start local, then the big platforms follow the demand ⚡️