Manna Bitcoin Wallet across three Bitcoin rails

Three payment rails sit behind one screen here: on-chain Bitcoin, Lightning, and Liquid, plus the merchant point-of-sale that settles into all three. Manna is self-custodial and, per its own description, open source — so there is no central ledger to query and no login to broker. The records a partner wants live on public networks and inside a seed the owner controls. That changes the integration question from "who do we ask for an API key" to "which protocols do we speak, and what does the owner consent to share." Both are things we build.

For most buyers the practical job is reconciliation: a merchant running Manna's point-of-sale wants every Bitcoin sale to land in their books with a proof attached, across whichever rail the customer paid on. That is reachable today. A watch-only descriptor plus open-protocol decoding covers on-chain and Lightning history without anyone handing over spend control; Liquid amounts come into focus only when the blinding key is shared. We say below where each rail is clean and where it stays opaque.

Payment surfaces worth reaching

The wallet names its rails plainly. Mapped to what an integrator actually does with each:

Routes into the payment data

Three apply here, and they compose rather than compete.

Open-protocol implementation

Manna speaks documented, public protocols: on-chain Bitcoin, BOLT11/LNURL on Lightning, and Liquid. We implement the same ones against an Esplora- or Electrum-style index for chain data and standard LNURL resolution for Lightning Addresses. Reachable: every public-network flow the wallet participates in. Durability is high because the specs are open and stable; a Lightning Address spec and the surrounding LNURL flows are published openly. We stand up the indexer access and the resolver as part of the build.

Consented watch-only access

An extended public key or output descriptor — and, for Liquid, the blinding key — lets us read full history and live balance with zero ability to move funds. This is the cleanest route for a single merchant or a treasury. The owner shares read-only material during onboarding; we wire the sync and a re-derivation pass so new addresses in the wallet's gap limit are picked up.

Authorized protocol analysis of the app's own traffic

The point-of-sale lifecycle — invoice issued, customer pays, confirmation — is partly app-specific, including any Lightning service-provider calls the wallet makes. Where the owner authorizes it, we observe and document that traffic to model the POS state machine precisely. Effort is medium and it needs a re-check when the app's front end shifts; we account for that in maintenance.

For a reconciliation build the watch-only descriptor and open-protocol decoding carry the bulk of the work, and we reach for traffic analysis only to nail down the POS-specific invoice lifecycle. If the goal is a live merchant feed rather than history, the Lightning and on-chain settlement events become the spine of the design and Liquid is wired in once blinding keys are on the table.

A worked example: watch-only read across two rails

Illustrative, and confirmed in shape during builds of this kind — exact index endpoints and the wallet's descriptor format are settled against the consenting wallet during the engagement.

# 1. On-chain: read confirmed receives from a consented watch-only descriptor
GET /descriptor/{wpkh_xpub}/txs        # Esplora/Electrum-style index
-> [
     { "txid": "…", "vout": 0,
       "value_sats": 145000,
       "status": { "confirmed": true, "block_time": 1733500000 } }
   ]

# 2. Lightning: resolve a Manna POS Lightning Address, then verify settlement
GET https://<domain>/.well-known/lnurlp/{user}   # LNURL-pay metadata
-> { "callback": "https://…", "minSendable": 1000, "maxSendable": 100000000 }

# after payment, settlement is proven by the preimage:
verify(preimage, payment_hash) == sha256(preimage) == payment_hash

# 3. Liquid is confidential — amounts need the blinding key, else:
#    { "rail": "liquid", "amount": null, "note": "blinded; unblinding key not provided" }

def normalize(sale):
    # one ledger row per sale, rail-tagged, proof attached
    return {
        "sale_id": sale.id,
        "rail": sale.rail,                 # onchain | lightning | liquid
        "amount_sats": sale.amount_sats,   # null if Liquid and unblinded
        "proof": sale.preimage or sale.txid,
        "settled_at": sale.block_time or sale.htlc_time,
    }

Error handling is explicit about the rail: an unblinded Liquid entry is returned with a null amount and a note rather than a guessed figure, and an on-chain receive below the agreed confirmation count is held as pending, not settled.

What lands in your repo

Tied to Manna's actual surfaces, a typical delivery includes:

• An OpenAPI specification for a normalized payment-history and balance read across all three rails, with the POS sale record as a first-class type.
• A protocol and auth-flow report covering the watch-only descriptor read, LNURL-pay resolution, the preimage settlement proof, and Liquid unblinding where keys are shared.
• Runnable source for the core reads — descriptor scan, Lightning Address resolution, settlement verification, and the sale-normalizer above — in Python or Node.js.
• Automated tests against fixture transactions for each rail, including the confidential-Liquid path and the below-confirmation pending case.
• Interface documentation plus data-retention guidance, since payment data carries customer footprints.

Authorization and the privacy line

No banking aggregation regime governs this — Manna is a self-custodial wallet, not a deposit institution, so the dependable basis for access is the wallet owner's own consent, not a regulator's data-sharing mandate. That consent is concrete: a watch-only descriptor and, for Liquid, an unblinding key, each read-only and each revocable by rotating the wallet. Spend authority never enters the picture. Where the merchant point-of-sale captures customer or vendor personal data, GDPR-style data minimization applies, and we treat it that way: we read only the rails and time windows the engagement needs, log what was accessed, keep consent records, and work under an NDA where the owner asks. Crypto activity can also touch AML or Travel-Rule obligations downstream at exchanges and processors; that sits with those parties, but our records are structured so a compliant counterparty can use them.

Build notes we account for

Two specifics on this app that shape how we scope the work:

• Liquid's confidential transactions mean a chain scan alone returns blinded amounts. We design the Liquid path around the blinding key from the start, and where it is not shared the integration reports those entries as opaque instead of silently dropping or fabricating them — so the ledger stays honest.
• Self-custody means new addresses are derived continuously inside a gap limit, and a static address list goes stale. We build the descriptor scan to walk the derivation path and re-derive ahead of the gap limit, so receives to fresh addresses are not missed as the wallet is used.
• The point-of-sale invoice can settle on any of three rails, each with a different proof shape — txid and confirmations on-chain, preimage on Lightning. We normalize the proof per rail at write time so downstream accounting does not have to branch on rail.

Access — index endpoints, the consenting descriptor, any traffic capture — is arranged with the owner during onboarding; the build runs against that consenting wallet or a test wallet we seed for the purpose.

Where teams point this

• A merchant accounting tool that reconciles every Manna POS sale into double-entry books, rail-tagged, with proof retained.
• A treasury dashboard reading watch-only balances across on-chain, Lightning, and Liquid for a vendor holding funds in the wallet.
• A fulfilment trigger that fires the moment a Lightning preimage verifies, instead of waiting on a manual check.

Screens we worked from

Store screenshots, opened while mapping the surfaces above.

How this was put together

Mapped on 2026-06-07 from the app's Google Play listing and its site at mannabitcoin.com for the self-custodial, three-rail and point-of-sale claims, then cross-read against the open Lightning Address specification and Boltz's published material on Lightning–Liquid atomic swaps to confirm how the rails interoperate. Where a detail is not public — the wallet's exact descriptor format, its Lightning service provider — it is settled against the consenting wallet, not asserted here.

• Manna Bitcoin Wallet on Google Play
• mannabitcoin.com
• Lightning Address specification (LNURL-pay)
• Boltz — non-custodial Bitcoin / Lightning / Liquid swaps

Mapped by the OpenBanking Studio integration desk, June 2026.

The wider self-custody wallet field

Same category, named for context and keyword reach — not ranked. A unified integration treats these the way it treats Manna: read the open rails, respect the owner's consent.

• Phoenix Wallet — self-custodial Lightning wallet that auto-manages channels; holds Lightning payment history under owner keys.
• Breez — runs a Lightning node on-device with managed channels; per-payment records sit locally.
• Bitkit — on-chain and Lightning in one self-custodial app with manual channel control.
• Zeus Wallet — non-custodial Lightning app with an embedded node and an LSP, holding node-level payment state.
• Bull Bitcoin Mobile — uses Liquid and the Boltz protocol for non-custodial swaps to Lightning.
• Muun — open-source non-custodial wallet abstracting channel management across on-chain and Lightning.
• Xverse — self-custody Bitcoin platform with integrated Lightning support.
• Blockstream Green — added Lightning–Liquid swaps via Boltz; holds on-chain and Liquid balances.
• EttaWallet — open-source non-custodial Bitcoin and Lightning wallet focused on usability.

Questions integrators ask about Manna

Manna is self-custodial — what is there to integrate if there is no account on a server?

The value moves on public networks. On-chain Bitcoin history is readable from the wallet's output descriptor, Lightning payments leave preimage proofs, and the merchant point-of-sale records each sale. We implement the same protocols and, with the owner's watch-only keys, reconstruct balances and history without ever holding spend authority.

Can you read Liquid amounts, given confidential transactions hide them?

Only with the blinding keys. Liquid confidential transactions blind both amount and asset type, so a plain chain scan shows nothing useful. When the wallet owner shares the unblinding key as part of the engagement, we decode amounts per asset; without it, Liquid activity stays opaque and we say so rather than guess.

How would you reconcile Manna point-of-sale payments into our accounting system?

Each POS sale produces a Lightning invoice or an on-chain address with a settlement event. We map that lifecycle — invoice issued, paid, confirmed — and emit one normalized record per sale that your ledger can ingest, keeping the payment preimage or transaction id as proof.

Do you need our seed phrase to build this?

No. A watch-only descriptor or extended public key is enough to read history and balances, and it cannot move funds. Spend authority never leaves the owner. The app name and what you want from its payment data are the real starting points; access and any keys are arranged with you.

Source delivery starts at $300, billed only after the integration is in your hands and you are satisfied with it; the hosted option runs per call with nothing paid up front. Either way the build cycle is one to two weeks. Tell us the app and what you need from its payment data on our contact page and we take it from there.