LexeConnect lets users connect their Lexe wallet to your app or service in one tap.
Your app shows a "Connect Lexe" button or a QR code, requesting exactly the scopes it needs. The user taps Approve in the Lexe app, and your app receives a Lexe client credential scoped to that access. Your app can then receive Lightning payments into the user's wallet, pay from it, or read its history, without holding funds or running a wallet of its own.
Users stay self-custodial. The approval screen shows who is asking and what they are granting, the credential is limited to the approved scopes, and it can be revoked from the Lexe app at any time. Your app never sees the user's root seed.
In this demo, a bill-splitting app connects a Lexe wallet with one tap, then a web checkout page connects via QR code. Both end up as scoped credentials in the Lexe app, where the user can revoke them any time.
Docs: https://docs.lexe.tech/lexeconnect/
Spec: https://github.com/lexe-app/lexe-connect
Live demo: https://lexeconnect.lexe.app
I'm not sure I understood from the description in the docs site. It gives a couple examples but are they existing integrations, or real apps? For merchants, is this essentially intended to be easier than integrating, say, btcpayserver or (I think there are others nowadays)? For a user, I don't know about this billshare one, I've many times shared a dinner bill with friends using Lightning, we just calculated it somehow or other. An app for that is way too specific imo. What other use cases are there?
I’m extremely compelled by the bill-sharing example. I’ve used Splitwise for years - automatically splitting utilities and expenses with housemates, calculating trip costs when different people paid for different things on the trip and joined/left at different times, or recording a shared dinner when we don’t feel like settling up right then and there.
In fact, as good as it is for recording obligations and calculating shares in every way imaginable, Splitwise’s number-one weakness is in-app payments. I’ve long thought that if someone made a Splitwise app but with seamless lightning payments (not in a bitcoiner way but in a normie way), it could achieve massive penetration.
The Paygate and BillSplit examples are fictional, intended to show what the flow looks like. But there are two apps which have already integrated LexeConnect for real:
I agree the BillSplit example is a bit contrived, but one thing I've very excited about is subscriptions and pay-as-you-go. Once we have budgets built, you'll be able to share your credentials to a website similar to OpenRouter, which has a spending limit of say $10 a month, and have it draw from your Lexe balance as you consume inference tokens. Basically, any form of pull payment is possible with LexeConnect. You can think of Lexe's client credentials like a credit card with a spending limit attached.
LexeConnect is great. It works perfectly in Zaprite P2P and makes the user experience so much better.
What is the benefit of LexeConnect over Nostr Wallet Connect (NWC) with scoped access?
Good question. LexeConnect and Lexe's client credentials are intended to make full use of Lexe's capabilities, some of which don't exist in the NWC spec, for example: on-chain payments, BOLT 12 payer proofs, partner fees, private payment notes, cancelling payments, syncing payments to disk, tailing the payments list, sending payments idempotently, etc.
We are fans of NWC and plan to integrate it, along with NWC-08 which offers a UX very similar to LexeConnect!
Having a common connection spec seems beneficial over every wallet making their own. Would it be possible to expand NWC-08 to incorporate all of the use cases you mention above so that services that want to connect to Lexe have fewer specs they need to be compatible with?
It would be possible, but there's a balance we have to make here: if a spec is too complicated, most wallets will only implement a subset of it, and the end result is that the spec leads to more fragmentation in the ecosystem, rather than less. We already see this somewhat, with NWC defining lots of methods that only a minority of wallets support such as hold invoices or keysend payments. So there is an argument for keeping NWC simple, so that when a wallet says “we support NWC” everyone has a common understanding of what that means.
LexeConnect is designed to work with Lexe wallets and Lexe client credentials, which is why we didn’t name it something more generic. We certainly don’t intend for this to compete with NWC. I think the typical integration order for an app or service is: (1) support NWC including NWC-08. (2) If you have a more direct integration with Lexe, or want to make use of Lexe’s more advanced features with the subset of your users that are Lexe users, then integrate LexeConnect and Lexe’s SDK.
Btw, we published LexeConnect as CC-BY 4.0, so that other wallets are welcome to reuse and set their own parameters for our protocol if they need a simple and secure way to share a credential. I just don’t expect them to use this flow for NWC connections, since NWC already has a blessed way to offer this kind of UX with NWC-08.
Makes sense. Thanks for the thorough response!
Can I onboard my barber with this wallet?
I don't see why not!
Very cool
Congrats on LexeConnect. Zaptrain now uses it: tap Connect Lexe, approve in the app, and you can send Lightning invoices. No keys to copy. We only request the receive scope.
Zaptrain video: https://youtu.be/2dFZPlAIWGo
Try it: https://zaptrain.com
This is the missing piece for self-custody UX. OAuth-style scoped credentials for Lightning is exactly what we need - app never holds funds or sees seed, user can revoke anytime, least-privilege by design. Similar to NWC but cleaner for consumer apps. The QR flow for web checkout is especially slick - could replace LN-Auth + LNURL-withdraw in one standard. Curious if LEXE is planning Nostr NWC compatibility or keeping this standalone?
One thing that bites in practice with scoped wallet connections (NWC or anything like it): treat "connected" as a lease, not a marriage.
Receive-only scopes are the right default for most apps. If you only create invoices, don't ask for pay. The day a bug or a compromised session can drain the wallet, you will wish you had.
On the receive path, invoice mint is the fragile bit. Wallet backends wedge under auth timeouts, clock jumps, or a frozen host. If your app hangs forever on "create invoice", users think they paid into a black hole. Put a hard timeout on mint (a few seconds), surface a clear retry, and never leave a half-created pending payment that the UI still shows as waiting.
Also test revoke mid-session before you ship. Approve → use → revoke in the wallet → next API call must fail closed. I've seen integrations that cache the credential and keep accepting work for minutes after revoke.
Last: whose node identity is on the invoice matters for proofs (already raised above). Pair that with a heartbeat or poll on the app side so a dead connection doesn't look like a quiet wallet.
On the NWC question above, one thing worth checking with any scoped wallet connection is whose node signs the invoices the app creates. If a receive-scoped credential makes invoices from the user's own wallet, the payer's preimage shows that wallet's node was paid; with a custodial Lightning address it only shows the host's node was paid, and whether the named person got credited is down to the host's ledger. That's part of why receive-only scope is a nice least-privilege default: the app can request payments without being able to spend.