AQUA Lightning Addresses Arrive

We’re excited to announce the arrival of AQUA 0.5.0! This release makes receiving Bitcoin so much easier. You can now receive Bitcoin through your own reusable Lightning Address ending in @aqua.net, and without having to specify an amount first. Share your address with a friend, add it to your profile or website, and incoming Lightning payments will automatically arrive in your AQUA Wallet. We also added support for deep links, and lowered the minimum amount of Lightning you can send from 1000 to 100 Sats.

Making Lightning Addresses work in self-custodial mobile wallets has always been a challenge. Building a reusable address system without turning AQUA into a custodial service required a unique approach: AQUA coordinates atomic swaps behind the scenes so incoming Lightning payments automatically arrive as L-BTC in your AQUA Wallet, while your keys and funds remain fully under your control.AQUA Lightning Addresses

We added Lightning Address support in AQUA following the LNURL specification and from the outside it looks quite simple: you have a user@aqua.net address, people send you Sats, Sats arrive. Underneath it though, there are some interesting design choices worth explaining, particularly around how we bind addresses to JAN3 Accounts and how we keep your wallet private from the backend.

Let’s take a look at how it all works.

How a Payment Reaches Your AQUA Wallet

At a high level, AQUA uploads a pool of fresh Liquid addresses to our backend. When a sender's wallet resolves user@aqua.net via LNURL, our backend pairs the request with one of those Liquid addresses and asks Boltz to create an atomic swap, handing Boltz the Liquid address and getting back a Lightning invoice, which we return to the sender. The sender pays the invoice over the Lightning Network, and Boltz settles the corresponding L-BTC straight to the recipient's AQUA Wallet on Liquid. Our backend never touches the funds. It only coordinates the flow.

Lightning Addresses + JAN3 Account

A Lightning Address quickly becomes part of your public payment identity. Friends save it. Clients invoice against it. Services route to it. Losing your phone shouldn't mean losing the address people already know, especially if it's a premium username you paid for.

That recovery requirement is the reason we bind user@aqua.net to your JAN3 Account rather than to a specific wallet or seed. The account is the stable anchor; the wallet behind it can change. In fact there may be cases where you want to bind your AQUA Lightning Address (and JAN3 Account) to a different wallet.

Wallet Fingerprints - A Signature Without Identity

The backend still has to know which wallet currently owns the address, without storing anything that would let us see what's inside it. To achieve that, we use the wallet fingerprint: a deterministic hash derived from the wallet's public key material. The AQUA Wallet computes the fingerprint locally and sends only the hash to our backend. We can recognize the same wallet across sessions and devices, but we can't derive a single one of its addresses. The fingerprint is opaque, one-way, and entirely uninformative regarding the wallet's contents.

Since the address is anchored to your JAN3 Account rather than to that fingerprint, you can re-bind it to a new wallet at any time. The new wallet registers its own fingerprint, supplies its own pool of fresh addresses, our backend overwrites the old ones, and from that moment on, every payment to user@aqua.net flows to your new wallet.

Keeping the Backend Topped Up

There's a practical consequence of not holding the wallet descriptor: our backend can't generate fresh receive addresses on its own. Each user’s AQUA Wallet has to keep us supplied. Every time the wallet connects, our backend signals how many addresses it wants to keep in reserve, and the wallet quietly hands over a fresh batch in the background.

If the wallet hasn't checked in for a while, say, a user installed AQUA, set up their address, and then didn't open the app for weeks, the pool can run low while payments keep arriving. In that case, our backend falls back to reusing existing addresses.

On the Bitcoin mainchain, that would be a real privacy problem. On Liquid it's a smaller one: Confidential Transactions blind amounts by default, so an observer can tell that an address received something, but not what or how much. It's not the privacy profile we'd choose for the happy path, but for an edge case we don't expect to hit often, it's a reasonable fallback and a much better one than asking the user to upload their wallet descriptor.

What About AQUA to AQUA?

When one AQUA user sends to another AQUA user’s Lightning Address, there’s no need to route the payment through Lightning, which would result in two swaps, with double the fees. Instead, AQUA can recognize Magic Routing Hints in the invoice and send the payment directly over Liquid instead. To the user, it still looks like a normal Lightning Address payment to user@aqua.net, but underneath it is just L-BTC moving directly between two AQUA wallets. This avoids unnecessary swaps, reduces fees, and makes AQUA-to-AQUA payments more efficient.

Premium Lightning Addresses

Every AQUA who signs into a JAN3 account gets a standard Lightning Address by default: random color + animal + number @aqua.net. Hidden among the namespace are six legendary animals: Dragon, Griffin, Pegasus, Phoenix, Unicorn, and Wyvern. These are exceptionally rare, so if you get one, you’ve got one of the special ones!

If you want a premium username, something shorter or something that reflects your identity, you can buy that as long as it’s available. We charge a small fee in Liquid Bitcoin to stop bots from claiming every interesting name in the namespace or hammering the endpoint with junk requests.

Wrapping Up

AQUA 0.5.0 is a big release, and we packed a lot into it. A sender on any Lightning wallet, anywhere in the world, can now pay user@aqua.net and have L-BTC land in a non-custodial Liquid wallet seconds later, without the sender knowing or caring about Liquid.

We also added deep link support, so AQUA can open Bitcoin, Lightning, Liquid, and LNURL payment links directly from QR codes, text, websites, and third-party apps. This makes payments smoother when a user receives a payment link outside AQUA, and improves interoperability with services like MoneyBadger that launch wallets using lightning: or app-specific links.

We also lowered the minimum amount you can send on Lightning from 1000 to 100 Sats, and added support for deep links, so AQUA can open payment links directly from other apps, websites, text, and QR codes.

For a complete list of changes, improvements, and fixes, read the full release notes on GitHub.