Fedimint: Federated Ecash Mints on Bitcoin
How Fedimint combines ecash privacy with federated custody to create community Bitcoin banks.
Bitcoin's public ledger creates a transparency problem: every transaction is visible to anyone with a block explorer. Fedimint addresses this by combining David Chaum's 1982 blind signature scheme with federated custody, producing a system where a group of trusted guardians collectively hold Bitcoin while issuing privacy-preserving ecash tokens to users. The result is something like a community Bitcoin bank: users deposit real bitcoin, receive blinded ecash notes, and transact with complete payer anonymity inside the federation.
The tradeoff is explicit. Fedimint is custodial. Users hand their bitcoin to a federation in exchange for IOUs. This stands in contrast to self-custodial approaches where users hold their own keys. Understanding where federated ecash fits in the broader Bitcoin Layer 2 landscape requires examining both the cryptographic elegance of Chaumian mints and the trust assumptions they introduce.
What Is Chaumian Ecash?
Chaumian ecash is a digital cash system proposed by cryptographer David Chaum in 1982, years before Bitcoin existed. The core innovation is blind signatures: a technique that lets a mint sign a token without seeing its contents, making it impossible to link issuance to redemption.
How Blind Signatures Work
The process works in four steps. A user generates a random secret (the note identifier) and applies a cryptographic blinding factor, producing a blinded message. The user sends this blinded message to the mint along with a deposit. The mint signs the blinded message with its private key for the appropriate denomination tier and returns the blinded signature. The user then removes the blinding factor, recovering a valid mint signature on the original, unblinded note.
When the user later redeems the note, the mint verifies its signature and checks a double-spend database. The signature is valid, the note has not been spent before, so the mint honors it. Crucially, the mint has no way to correlate this redemption with the original issuance: it signed a blinded version and never saw the underlying note. The anonymity set is every note of that denomination ever issued by the mint.
Why "ecash" matters: Unlike on-chain Bitcoin where every transaction is permanently recorded on a public ledger, ecash transactions leave no trace. The mint cannot build a transaction graph, cannot identify senders, and cannot link balances to users. This is privacy by design, not privacy by policy.
Denomination Tiers
Ecash mints use fixed denomination tiers (for example, 1 sat, 2 sats, 4 sats, 8 sats, and so on in powers of two). Each tier has its own signing key. When a user deposits 100 sats, the mint issues notes across multiple tiers that sum to 100. This design prevents the mint from tracking users by amount, since many users hold notes of the same denominations.
From Single Mint to Federation
Chaum's original DigiCash implementation (launched in 1989, bankrupt by 1998) relied on a single centralized mint. This created an obvious problem: the mint operator could steal all deposited funds, inflate the ecash supply, or be shut down by authorities. A single mint is a single point of failure.
Fedimint solves this by distributing the mint across multiple independent operators called guardians. These guardians collectively manage the Bitcoin held in custody using a threshold signature scheme, meaning no single guardian possesses the complete key material needed to spend funds. The federation uses a t-of-n model: for example, in a 3-of-4 federation, any three of four guardians must agree to sign a transaction.
Byzantine Fault Tolerance
Fedimint tolerates Byzantine faults according to the formula 3m + 1, where m is the number of faulty or malicious nodes the system can withstand. A 4-guardian federation tolerates 1 failure. A 7-guardian federation tolerates 2. A 10-guardian federation tolerates 3. If fewer than a quorum of guardians are online, consensus halts until enough return. No individual guardian can unilaterally access funds or manipulate the ecash supply.
| Federation Size | Threshold | Max Failures Tolerated | Quorum Needed |
|---|---|---|---|
| 4 guardians | 3-of-4 | 1 | 3 |
| 7 guardians | 5-of-7 | 2 | 5 |
| 10 guardians | 7-of-10 | 3 | 7 |
Consensus Mechanism
Guardians coordinate using AlephBFT, an asynchronous Byzantine fault-tolerant consensus protocol. Each guardian node runs three parallel tasks: an API server handling client requests, the AlephBFT protocol for inter-node communication, and a consensus processing engine that applies agreed-upon transactions. This design ensures that guardians reach identical state without relying on a leader or synchronized clocks.
How Deposits and Withdrawals Work
Peg-In: Depositing Bitcoin
To deposit, a user sends on-chain bitcoin to the federation's threshold multisig address. Once the transaction reaches sufficient confirmations, the federation guardians collectively issue ecash notes of equivalent value via blind signatures. The user now holds ecash IOUs redeemable for bitcoin. The on-chain UTXO is locked in the federation's custody.
Internal Transfers
Within a federation, users transact by passing ecash notes directly. Alice can send notes to Bob, who redeems them with the mint and receives freshly minted notes in return. No blockchain transaction occurs. Transfers are instant and private: the federation sees a redemption and a new issuance but cannot link them to the same payment.
Peg-Out: Withdrawing Bitcoin
To withdraw, a user submits ecash notes to the federation for redemption. The guardians verify the notes, check for double-spending, then construct and sign an on-chain Bitcoin transaction to the user's specified address. Alternatively (and more commonly), users withdraw via a Lightning gateway, which avoids the cost and delay of on-chain transactions.
Important distinction: Ecash notes are bearer instruments. Whoever holds a note can redeem it. If a user loses their notes (device failure, for example), the federation cannot recover them: the mint has no record of which notes belong to which user. Fedimint includes a backup mechanism through the federation, but users must configure it proactively.
Lightning Gateway Integration
Fedimint federations connect to the broader Lightning Network through specialized clients called Lightning gateways. A gateway is not a guardian: it is a regular federation user who also operates a Lightning node. A single gateway can serve multiple federations, and a single federation can be served by multiple gateways, creating redundancy and competition.
Sending via Lightning
When a federation user wants to pay a Lightning invoice, they lock ecash to a contract inside the federation. This contract contains the payment hash from the invoice. The gateway pays the invoice on the Lightning Network using its own liquidity. If the payment succeeds (the gateway obtains the preimage), the gateway sweeps the locked ecash. If it fails, the ecash returns to the user. The mechanism uses HTLCs extended one hop from Lightning into the federation.
Receiving via Lightning
To receive a Lightning payment, the user coordinates with a gateway to produce an invoice. When the gateway receives the Lightning payment, it credits the user with ecash inside the federation. This allows Fedimint users to receive payments from any Lightning wallet without the sender knowing or caring that the recipient is using a federated mint.
The Trust Model: Privacy vs. Custody
Fedimint's trust model is best understood as a deliberate tradeoff. Users gain strong transaction privacy (blind signatures make payments unlinkable) but give up self-custody of their bitcoin. The official documentation identifies five categories of risk.
Risk Categories
- Custodial risk: a quorum of guardians could collude to steal deposited bitcoin
- Debasement risk: the federation could issue more ecash than bitcoin it holds, inflating the supply
- Regulatory risk: authorities could force a federation to shut down or freeze funds
- Gateway censorship risk: Lightning gateways could refuse to route specific payments
- Availability risk: if too many guardians go offline, the federation halts
Fedimint's mitigation strategy centers on what the community calls "KYF" (Know Your Federation): users should only join federations run by people they personally know and trust. The idea is that a federation of family members, local community leaders, or colleagues provides stronger social accountability than an anonymous third-party custodian. The project describes this as "second-party custody": a middle ground between holding your own keys and trusting a corporation.
Fedimint vs. Other Privacy and Scaling Approaches
Several Bitcoin protocols compete for attention in the privacy and scaling space. Each makes different tradeoffs between custody, privacy, complexity, and trust assumptions.
| Property | Fedimint | Cashu | Lightning | On-Chain Bitcoin |
|---|---|---|---|---|
| Custody model | Federated (t-of-n) | Single mint operator | Self-custodial | Self-custodial |
| Privacy | Excellent (blind signatures) | Excellent (blind signatures) | Moderate (onion routing) | Low (public ledger) |
| Trust requirement | Guardian quorum | Single operator | Trustless (channels) | Trustless (PoW) |
| Speed | Sub-second (ecash) | Sub-second (ecash) | Seconds (HTLC routing) | 10+ minutes |
| Rug-pull risk | Requires quorum collusion | Single operator can rug | None | None |
| User complexity | Low (join federation) | Low (connect to mint) | Moderate (channels, liquidity) | Low (addresses) |
| Interoperability | Lightning via gateways | Lightning via mints | Native | Base layer |
Fedimint vs. Cashu
Both Fedimint and Cashu implement Chaumian ecash on Bitcoin, but their architectures diverge significantly. Cashu uses single-operator mints: simpler to deploy, easier to understand, but with all custodial risk concentrated in one party. Fedimint distributes that risk across a federation. Cashu is written in Python and designed for lightweight deployment. Fedimint is written in Rust with a modular architecture supporting custom consensus modules.
The practical implication: Cashu mints are faster to set up (a single server) but carry higher counterparty risk. Fedimint requires coordinating multiple guardians but offers stronger custodial guarantees. Both provide equivalent privacy properties through blind signatures.
Fedimint vs. Self-Custodial Layer 2s
The Lightning Network, Spark, Ark, and similar protocols take a fundamentally different approach: users retain custody of their bitcoin at all times. No federation holds your funds. No quorum of guardians can steal your deposits.
Lightning achieves this through bilateral payment channels secured by on-chain transactions and watchtowers. Spark uses statechain-based transfers with FROST threshold signatures, where operators participate in signing but cannot move funds without user consent. In both cases, users can always exit to Bitcoin L1 unilaterally.
Fedimint users cannot exit unilaterally. They must request a peg-out from the federation, and the federation must agree to process it. If a quorum of guardians refuses or goes offline permanently, deposited bitcoin is lost. This is the fundamental difference between custodial and self-custodial systems.
Technical Architecture
Module System
Fedimint is designed as a modular framework. The core protocol ships with three default modules: fedimint-wallet (on-chain deposits and withdrawals), fedimint-mint (ecash issuance and redemption), and fedimint-ln (Lightning Network integration). Developers can build custom modules that define their own consensus items and transaction types, extending federation functionality beyond simple ecash.
Client SDKs
The project provides client libraries in Rust, with additional bindings for Python, Go, and WebAssembly (enabling browser-based wallets). The SDK handles the complexity of blind signature generation, note management, and federation communication, exposing a higher-level API to wallet developers.
Federation Setup
Setting up a federation requires each guardian to run a Fedimint server node. Guardians perform a distributed key generation ceremony to create the threshold signing keys and ecash signing keys. Once established, the federation begins accepting deposits and issuing ecash. The Fedi application has simplified this process with guided federation creation tools.
Who Uses Fedimint?
Fedimint targets communities where trust relationships already exist but access to financial infrastructure is limited. Several real-world deployments illustrate the model.
- BitSacco in Kenya reinvents traditional Kenyan SACCOs (Savings and Credit Cooperative Organizations) using Fedimint, receiving a grant from the Human Rights Foundation
- Nonprofits including Refunite (refugee reunification) and The Kisaw Project (microloans in Sub-Saharan Africa) have explored Fedimint for financial inclusion
- The Fedi application (launched August 2024) provides a consumer-facing interface with chat, payments, and social features built on the Fedimint protocol
The common thread is communities where members know each other: villages, cooperatives, families, organizations. Fedimint's "Know Your Federation" philosophy works best when guardians are accountable to the community they serve.
Limitations and Open Questions
No Proof of Reserves
Fedimint currently lacks a trustless proof-of-reserves mechanism. Users cannot independently verify that the federation holds enough bitcoin to back all outstanding ecash. The federation could theoretically issue more ecash than bitcoin it holds (debasement), and users would have no way to detect this until a bank run occurs. This is the same problem that plagued traditional banks before reserve auditing standards.
Cross-Federation Interoperability
Each federation is an isolated system. Ecash notes from one federation are not valid in another. Users who need to move value between federations must go through Lightning gateways or on-chain transactions, adding friction and reducing privacy (since the Lightning payment or on-chain transaction is visible). Work on cross-federation atomic swaps is ongoing but not yet standardized.
Guardian Coordination
Running a federation requires ongoing coordination among guardians. Software updates, key management, server maintenance, and dispute resolution all require human coordination. If guardians lose interest, move, or have falling-outs, the federation's continuity is at risk. This operational overhead is often underestimated.
Where Fedimint Fits in the Bitcoin Stack
Fedimint occupies a specific niche: high-privacy transactions within trusted communities, with the explicit acceptance of custodial risk. It is not a replacement for self-custodial solutions and does not pretend to be. The project's own documentation is transparent about the tradeoffs, which is a point in its favor.
For users who prioritize privacy above all else and have a trusted community to form a federation with, Fedimint offers properties that no self-custodial system currently matches: complete unlinkability of payments with no on-chain footprint. For users who prioritize sovereignty and trustlessness, self-custodial Layer 2 protocols like Spark offer a different set of tradeoffs: users hold their own keys, can exit to L1 without permission, and never delegate custody, but transactions are visible to the protocol operators (though not publicly on-chain).
Different philosophies, different use cases: Fedimint prioritizes privacy through custodial tradeoffs. Self-custodial Layer 2s like Spark and Lightning prioritize sovereignty through transparency tradeoffs. Neither approach is universally superior: the right choice depends on the user's threat model and trust relationships.
Developers building on Bitcoin can explore self-custodial alternatives through the Spark SDK documentation, which provides tools for integrating instant, non-custodial Bitcoin and stablecoin transfers into applications. For a hands-on example of a Spark-powered wallet, see General Bread. For a deeper comparison of Bitcoin scaling approaches, see our Bitcoin second-layer scaling landscape overview.
This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.