Lightning vs Fedimint: Channel-Based and Federated Ecash Compared

Lightning Network vs Fedimint Overview

Lightning Network and Fedimint represent two fundamentally different approaches to scaling Bitcoin payments. Lightning uses peer-to-peer payment channels with onion routing to move bitcoin across a global network. Fedimint uses federated Chaumian ecash mints where guardians collectively custody bitcoin and issue blind-signed bearer tokens.

These two systems are not competitors: they are complementary layers that solve different problems. Lightning excels at trustless, self-custodial payments across the open internet. Fedimint excels at community-scoped custody with strong transaction privacy. Crucially, Fedimint federations connect to Lightning through gateway bridges, allowing ecash users to pay any Lightning invoice without leaving the Fedimint user experience.

For a broader view of how both fit into the Bitcoin scaling landscape, see our Fedimint federated ecash deep dive and the Lightning wallet comparison tool.

Privacy: Onion Routing vs Blind Signatures

Privacy is where Lightning and Fedimint diverge most sharply. Lightning uses Sphinx-based onion routing: each intermediary node knows only the previous hop and the next hop but cannot determine its position in the route or the total path length. Sender privacy is relatively strong because the originator of a payment looks identical to a forwarding node.

Receiver privacy is weaker. Standard BOLT 11 invoices embed the recipient's node public key, making the destination identifiable. Blinded paths (route blinding) and trampoline routing are being developed to address this, but adoption remains partial. Balance probing attacks, where an adversary sends intentionally-failing payments to infer channel balances, can map the network's liquidity distribution in under a minute per channel. Timing analysis across short routes (many Lightning payments traverse only 1-2 intermediaries) can further narrow the anonymity set.

Fedimint takes a fundamentally different approach. The federation signs ecash tokens using threshold blind signatures without ever seeing the token contents. The mint knows it issued a token and that a token was later redeemed, but it cannot link issuance to redemption. This is the core Chaumian ecash guarantee: within a federation, transactions are unlinkable. The federation cannot see which user holds specific tokens, cannot reconstruct transaction histories, and does not maintain individual account balances (there are no accounts). The tradeoff is that this privacy requires trusting a quorum of guardians with custody of the underlying bitcoin.

Peg-in and peg-out transactions remain visible on the Bitcoin blockchain, so privacy applies only to activity within the federation. Cross-federation payments routed through Lightning gateways inherit Lightning's privacy properties for the routed portion.

Custody Model and Trust Assumptions

Lightning is self-custodial by design. Users hold their own private keys and can unilaterally close channels to recover funds on-chain. The trust assumption is purely cryptographic: the counterparty in a payment channel cannot steal funds as long as the user (or their watchtower) monitors for outdated commitment transactions. No third party holds custody of the user's bitcoin at any point.

Fedimint uses federated custody. Bitcoin deposited into a federation is locked in a multisig wallet controlled by the guardian set. Fault tolerance follows the 3f+1 formula: a 4-guardian federation tolerates 1 malicious or offline guardian, 7 guardians tolerate 2, and 10 guardians tolerate 3. Users hold ecash bearer tokens rather than private keys to on-chain UTXOs. If a threshold of guardians collude or are compromised, user funds are at risk.

The practical impact depends on who the guardians are. In a community federation (a local savings group, a cooperative, a small business network), users know and trust the guardians personally. This is similar to how traditional credit unions or rotating savings groups operate: the trust is social and local rather than cryptographic and global.

Scalability and Performance

Lightning scales through a network of bilateral payment channels. As of mid-2026, the public Lightning Network comprises approximately 17,000 nodes with around 5,600 BTC in public channel capacity. The network recovered from a capacity dip in late 2025 (around 3,850 BTC) to surpass previous levels. Monthly Lightning transaction volume crossed $1 billion for the first time in February 2026. Including private channels, total capacity is estimated at over 12,000 BTC.

Lightning's scalability constraints are channel liquidity and routing: payments require a path with sufficient capacity at every hop, and large payments may need to be split across multiple paths. Each channel requires an on-chain funding transaction to open, which sets a floor on onboarding cost. Channel factories and splicing aim to reduce this overhead.

Fedimint scales differently. Within a federation, ecash transfers are simple database operations: the sender passes tokens to the recipient, who redeems them and receives freshly minted tokens. There is no routing, no channel capacity constraint, and no on-chain transaction for internal transfers. Throughput is bounded by the guardian consensus protocol (AlephBFT, an asynchronous Byzantine fault-tolerant protocol). A single federation can handle high transaction volumes within its membership.

The scalability limitation is scope: each federation is an isolated system. Cross-federation payments require routing through a Lightning gateway, inheriting Lightning's capacity constraints for the bridged portion. The total system scales horizontally by deploying more independent federations, each serving its own community.

User Experience

Lightning wallets have matured significantly since 2018, but the underlying complexity of channel management, inbound liquidity, and force closes remains. Users of non-custodial Lightning wallets must either manage channels directly or rely on a Lightning Service Provider (LSP) for just-in-time channel provisioning. Receiving a first payment requires inbound liquidity, which adds friction for new users. Custodial Lightning wallets (Wallet of Satoshi, Alby) simplify this but sacrifice the self-custody property.

Fedimint abstracts channel management entirely. Users interact with a balance of ecash tokens: sending and receiving within the federation works like a simple transfer with no routing decisions, no liquidity requirements, and no channel state to monitor. The onboarding flow is: join a federation (scan an invite code), deposit bitcoin (on-chain or via Lightning), and start transacting. The Fedi app, which went fully open source under AGPL on January 3, 2026, packages this into a consumer-facing interface with encrypted messaging and customizable community features.

The UX tradeoff is scope. A Fedimint user can transact freely within their federation, but paying someone outside requires a Lightning gateway hop. Lightning users can pay anyone on the network directly.

Fedimint-Lightning Gateway Interoperability

The Lightning gateway is what makes Lightning and Fedimint complementary rather than siloed. A gateway is a specialized Fedimint client paired with a Lightning node. It is not a guardian and has no special privileges in the federation consensus.

When a federation user pays a Lightning invoice, the process works as follows: the user locks ecash to an HTLC-style contract enforced by the federation. The gateway pays the Lightning invoice using its own channels, obtains the payment preimage, and presents it to the federation to claim the locked ecash. For incoming payments, the gateway funds the user's ecash balance in exchange for a preimage that it uses to settle the Lightning-side HTLC.

As of Fedimint v0.7.0, the gateway runs as a single process using LDK Node rather than requiring a separate Lightning node daemon. Multiple independent gateways can serve the same federation, providing redundancy and fee competition. The gateway is explicitly not a custodian: it cannot access federation funds and earns fees only by facilitating Lightning routes.

Community Trust Models

Lightning's trust model is individualistic. Each user manages their own keys, chooses their own channel partners, and bears full responsibility for operational security ( backups, watchtowers, fee management). This model works well for technically proficient users and organizations with dedicated infrastructure.

Fedimint's trust model is communal. A group of known guardians manages custody on behalf of a community. This mirrors how many communities already manage shared resources: through trusted local institutions rather than individual sovereignty. BitSacco in Kenya, for example, uses Fedimint to digitize traditional chama savings groups, where members already pool funds under community oversight.

Neither model is universally superior. The right choice depends on the user's technical capability, community context, and risk tolerance. Many users may participate in both: holding self-custodial Lightning capacity for sovereign spending while keeping a balance in a trusted community federation for everyday payments.

Technical Maturity Comparison

Lightning has a six-year head start in production deployment and a mature multi-implementation ecosystem. Fedimint is earlier in its lifecycle but benefits from a modular architecture that allows community-specific customization through its module system (Wallet, Mint, and Lightning modules).

When to Use Lightning vs Fedimint

Lightning is the better fit when:

• Self-custody is a hard requirement
• The user needs to pay recipients across the open internet
• The use case involves merchant point-of-sale or micropayments to many distinct parties
• Integration with the global Lightning payment network is the primary goal

Fedimint is the better fit when:

• A defined community needs shared custody with strong internal privacy
• Users lack the technical ability to manage channels and liquidity
• The majority of transactions occur within a closed group (savings circles, cooperatives, local commerce)
• Transaction privacy within the group is a priority

In practice, the two often work together. A community federation handles internal transfers with ecash privacy and simplicity, while Lightning gateways connect members to the broader Bitcoin payment network. Protocols like Spark add another dimension by enabling instant, low-fee Bitcoin and stablecoin transfers that interoperate with Lightning, giving users additional options for moving value across the Bitcoin ecosystem.

Frequently Asked Questions

Is Fedimint a replacement for the Lightning Network?

No. Fedimint and Lightning are complementary systems, not competitors. Fedimint federations use Lightning gateways to send and receive payments across the broader network. Lightning provides the global payment routing layer; Fedimint provides community-scoped custody and ecash privacy on top of it. Most Fedimint users interact with Lightning indirectly every time they pay someone outside their federation.

Is Fedimint self-custodial?

No. Fedimint uses federated custody, where a set of guardians collectively hold the bitcoin backing the federation's ecash supply. Users hold bearer tokens rather than private keys to on-chain UTXOs. The trust assumption is that a threshold of guardians will remain honest and available. This is trust-minimized (distributed across multiple parties) but not trustless in the way that holding your own Lightning channel keys is.

How does Fedimint privacy compare to Lightning privacy?

Within a federation, Fedimint provides stronger privacy than Lightning. Blind signatures ensure the federation cannot link token issuance to redemption, making transactions between members unlinkable. Lightning's onion routing protects sender identity from intermediary nodes but leaks receiver identity through invoices and is vulnerable to balance probing and timing analysis. Fedimint privacy applies only within the federation; cross-federation payments routed via Lightning inherit Lightning's privacy properties.

Can I use Fedimint and Lightning at the same time?

Yes. Fedimint users transact with ecash within their federation and use Lightning gateways for external payments. Many users maintain both a self-custodial Lightning wallet for sovereign spending and a Fedimint balance for everyday community payments. The gateway bridge makes this seamless: paying a Lightning invoice from within a federation looks identical to paying from a standard Lightning wallet.

How many guardians does a Fedimint federation need?

Fedimint follows the 3f+1 fault tolerance formula using AlephBFT consensus. A 4-guardian federation tolerates 1 fault, 7 guardians tolerate 2, and 10 guardians tolerate 3. Most community federations run with 4 to 7 guardians. Fewer guardians reduce operational complexity but increase risk; more guardians increase resilience but require broader coordination.

What happens if a Fedimint federation goes offline?

If enough guardians go offline to break the consensus threshold, the federation halts: no new ecash can be minted or redeemed, and gateway payments stop. Users' ecash tokens remain valid but cannot be redeemed until the federation recovers quorum. The underlying bitcoin remains locked in the federation's multisig wallet. If guardians permanently disappear beyond the fault tolerance threshold, funds may be unrecoverable. This is the core custodial risk of the federated model.

How does Fedimint differ from Cashu?

Both use Chaumian blind signatures to issue ecash tokens with identical privacy properties. The key difference is trust distribution: Cashu uses a single mint operator (one entity holds all custody), while Fedimint distributes custody across multiple guardians with threshold consensus. Fedimint is more resilient to a single point of failure. Cashu is simpler to deploy. For a detailed comparison, see our Bitcoin ecash implementation comparison.

This tool is for informational purposes only and does not constitute financial advice. Data is approximate and based on publicly available information as of mid-2026. Network statistics, software versions, and protocol capabilities change frequently. Always verify current data before making decisions.