Luma began with a deceptively simple question:
Can an AI agent help someone buy something with Bitcoin or an RGB asset—without ever being trusted to spend their money?
We think the answer is yes. And after building, breaking, and rebuilding the system across regtest, Signet, wallets, Lightning channels, merchants, and mobile hardware, we’re more convinced than ever that this is an architecture worth pursuing.
This is what we built, what we learned, and why we’re optimistic about what comes next.
The First Question: Can an Agent Help Without Holding the Keys?
The first experiment was RGB402: an HTTP 402-style purchase flow for Bitcoin and RGB assets.
Then came Alice, Bob, and Carol—three independent wallets running on real regtest Bitcoin and RGB Lightning nodes, with channels, invoices, inventory, human approval, and settlement that both sides could verify.
Alice and Bob proved the first milestone: wallet-to-wallet transfers worked.
Carol changed the project.
Carol ran a real merchant: her own node, products, orders, and receipts. Alice bought a coffee for 5 R402USD. Bob bought a sandwich for 8. Balances moved. Carol received the asset. Every purchase crossed a human approval boundary before exactly one payment went out.
That gave us the rule Luma now stands on:
prepare → reserve → human approval → execute once → settle → reconcile
The agent can understand intent, find a merchant, inspect a product, read an invoice, and prepare a transaction. But it cannot change the recipient, amount, or asset after approval. It cannot approve its own transaction. And an uncertain network response never becomes a second payment.
That is the core idea:
Luma is not an AI with a Bitcoin wallet bolted on. It is a system where agents reason about money without ever holding authority over it.
We Put the Node Inside the Phone
No consumer should have to run a separate RGB Lightning node. So we moved the node into the wallet.
Each installation now owns its keys, RGB state, channel state, and payment journal. Shared infrastructure can provide Bitcoin and indexer access, RGB transport, liquidity, discovery, and agent services—but it cannot sign for the user.
The Android build has progressed from local regtest to public Signet, with Bitcoin Core, Electrs, RGB transport, TLS endpoints, an agent gateway, and our own LSP. Phones connect directly. No USB. No adb reverse. No pretending the phone is a development machine.
The division of responsibility is simple:
The phone owns authority.
The network supplies connectivity and liquidity.
The merchant publishes commerce intent.
The agent helps the user decide.
The wallet enforces what can actually happen.
That last line matters most. The wallet is not just an interface. It is the enforcement boundary.
Plenty Broke—and That Was the Point
A research prototype that never breaks is usually not testing enough. Luma broke in useful ways, and each failure sharpened the design.
We learned that:
- A healthy container does not mean a wallet can pay.
- A running node does not mean an unlocked wallet.
- On-chain sats are not Lightning liquidity.
- Owning an RGB asset does not mean it is usable in a channel.
- A connected peer is not a usable channel.
- A UI saying “Opening” is not the node saying “ready.”
Mobile added its own lessons. Testing JavaScript configuration is not enough; what matters is what actually made it into the APK—the network, Electrs endpoint, RGB proxy, LSP identity, and expected RGB contract. Native ABI compatibility, WDK, Bare, and the RGB Lightning addon form their own failure boundary.
Recovery is the hardest problem of all.
Restoring keys without channel monitors, RGB state, and journals is a dangerous partial recovery. A live Lightning/RGB wallet must be recovered as one economic state machine—not merely as a twelve-word seed.
We have demonstrated an isolated recovery capsule. We have not claimed that it proves production recovery. That distinction matters, and we intend to keep making it.
Where Luma Stands Today
The research prototype works.
It has demonstrated BTC and RGB Lightning settlement, wallet-to-wallet payments, agent-assisted purchasing, merchant products and orders, human-readable recipient discovery, human-controlled approval, L402-style paid resources, and exact-once payment with reconciliation.
The mobile product is behind the prototype, but it is increasingly real. The embedded node runs on physical Android hardware and public Signet, with our own LSP path, payment addresses, merchant publication, and mobile checkout.
What we have not yet earned is the word “production.”
We still need repeatable phone-to-phone BTC and RGB settlement, merchant-side receipt verification from phones, robust channel lifecycle handling, and credible loss-and-restore tests.
But the bigger question has already been answered:
Is this architecture worth continuing? Yes.
What We Should Open-Source
Our instinct is: not everything, and not nothing.
For a non-custodial wallet, verifiability is the product. People should be able to inspect what gets signed, how payments are prepared, what requires approval, how duplicate execution is blocked, how state is persisted, how invoices and RGB assets are validated, what leaves the device, and what the server can and cannot do.
Those are custody claims—not implementation details.
Open first
- The Alice/Bob/Carol prototype and RGB402 experiments
- The reproducible regtest environment
- Protocol interfaces and the payment state machine
- Safe example configs, acceptance tests, and architecture documentation
- Enough of the mobile wallet engine to reproduce the custody boundary
Keep private for now
- Production mobile UX
- Merchant growth and ranking
- Catalog normalization and discovery
- Agent orchestration prompts and evaluations
- Liquidity allocation and rebalancing heuristics
- Fraud, risk, routing, and abuse-prevention systems
- Infrastructure and monitoring
- Unreleased recovery techniques
- Partner and issuer integrations
The principle is straightforward:
Open the mechanisms that prove user sovereignty. Protect the mechanisms we compete with.
Trade Secrets, Handled Honestly
An LSP is not a secret. Neither are RGB channels, embedded nodes, merchant discovery, or agents buying things. Guarding those would only create false confidence.
The real advantage lies in how well the pieces work together:
- Predicting and allocating liquidity
- Turning vague human intent into a bounded economic proposal
- Ranking merchants
- Normalizing Shopify and WooCommerce catalogs
- Optimizing routing
- Reconciling failures without double payment
- Spotting risky behavior
- Eventually making recovery safe for ordinary users
But there is one hard line:
Key security and payment authorization must never depend on secrecy.
They should hold even if an attacker knows exactly how the system works.
The Road Ahead
1. Freeze and publish the prototype
Make Alice, Bob, Carol, and RGB402 a clean, reproducible reference implementation. Keep the evidence—and the failures. Document what was actually demonstrated, not what merely sounds good.
2. Finish the mobile proof
Two fresh phones. Independent seeds and node identities. Real Signet BTC. Allocation UTXOs. Luma-provided liquidity. BTC and RGB payments in both directions. A merchant purchase with buyer approval and seller receipt. Restart a phone and repeat. Interrupt a payment on purpose and prove reconciliation never pays twice.
Until then, it stays experimental.
3. Make liquidity invisible
Nobody should need to understand inbound capacity or channel topology to buy a coffee. The LSP should watch payment demand and arrange liquidity around users and merchants.
That is a business in itself: commerce creates payment demand, payment demand creates liquidity demand, and capital providers fill it.
4. Turn merchants into the network
Create a store or import a Shopify/WooCommerce catalog. Normalize products and give each one a machine-readable purchase path. Humans browse. Agents discover the same inventory programmatically.
Then a user can say:
“Find this, keep it under $40, pay in USDT if the merchant accepts it, otherwise ask me before using BTC.”
The agent discovers and prepares. The wallet authorizes and settles.
That is the part that could matter beyond “another Bitcoin wallet.”
5. Replace demo assets with real money
R402USD and LUSD are demos, not stablecoins. Real USDT-style assets need an issuer-approved RGB contract, a legitimate acquisition path, and real liquidity.
If issuer-backed stablecoins reach RGB and Lightning, this machinery could coordinate real dollar commerce on Bitcoin rails.
Luma May Not Stay Luma
We like the name. It is light, approachable, and has served us well as a codename.
But it is crowded. A quick search turns up a Luma Bank, a Luma financial OS, a Luma POS app, and a Luma non-custodial crypto product. That creates trouble with discoverability, app stores, domains, trademarks, and customer confusion.
So Luma is the codename, not a commitment.
What matters is the idea:
Agentic commerce on Bitcoin, where agents participate in economic decisions without owning the authority to spend.
If a more distinctive, ownable name appears, we will change it before distribution—not after.
What We Actually Discovered
We thought we were building an AI-enabled RGB wallet.
Then an agentic Bitcoin wallet.
Then Carol made it an agentic merchant wallet.
Then mobile and the LSP widened it again.
The real opportunity looks like an open Bitcoin/RGB economic layer beneath a proprietary consumer and merchant commerce network.
Wallets create payment demand. Merchants create commerce demand. Agents create discovery and automation. LSPs supply connectivity. Liquidity providers supply capital. Issuers supply credible assets.
And Luma—or whatever it eventually becomes—coordinates all of it without becoming the custodian of anyone’s money.
That is far bigger than a hackathon entry. And there is far more left to prove.
So the discipline stays the same:
Don’t claim it works because the UI says it works.
Prove it at the wallet. Prove it at the node. Prove it at the merchant. Record the evidence. Then build the next layer.
Top comments (0)