Glossary

Fedimint

A federated custody and payment protocol for Bitcoin communities, using threshold cryptography to create community-run Bitcoin banks.

Key Takeaways

  • Fedimint is a federated custody protocol where multiple guardians hold bitcoin in a threshold multisig wallet and issue Chaumian eCash tokens for private, internal transfers.
  • The privacy model uses blind signatures: the federation signs eCash tokens without knowing who holds them, so it cannot track individual balances or transaction histories within the mint.
  • Fedimint connects to the Lightning Network through gateways, giving community members access to Layer 2 payments without running their own Lightning nodes or managing channels.

What Is Fedimint?

Fedimint (a portmanteau of "federated" and "mint") is an open-source protocol that enables communities to operate their own Bitcoin banks. A group of trusted individuals called guardians collectively custody bitcoin deposits and issue privacy-preserving eCash tokens backed 1:1 by those deposits. Users interact with eCash inside the federation rather than with raw bitcoin, gaining strong privacy guarantees and simplified payments.

The protocol was created by Eric Sirion in 2021 (originally called MiniMint) and builds on David Chaum's 1982 blind signature scheme. On October 3, 2021, Sirion made the first-ever eCash purchase on Bitcoin: buying a coffee at Paralelni Polis in Prague using MiniMint connected to the Lightning Network. The protocol was later renamed to Fedimint and has since grown into a broader ecosystem including the Fedi application and community deployments in Kenya, South Africa, and Portugal.

Fedimint occupies a unique position in the Bitcoin custody spectrum. Rather than full self-custody (where individuals manage their own keys) or third-party custody (where a company holds funds), Fedimint introduces "community custody": trusting a distributed group of people you know personally. For a deeper exploration of federated eCash concepts, see the Fedimint and federated eCash research article.

How It Works

Fedimint's architecture combines three core components: federated custody through threshold multisig, Chaumian eCash for privacy, and Lightning gateways for external payments.

Federation Setup

A federation consists of four or more guardians, each running their own Fedimint server. The guardians hold user bitcoin in a threshold signature wallet that requires a quorum to authorize any movement of funds. Common configurations include 3-of-4 or 4-of-7 setups.

The federation uses AlephBFT, an asynchronous Byzantine Fault Tolerant consensus protocol. A federation of N nodes can tolerate up to f faulty or malicious nodes where N ≥ 3f + 1. In a 4-guardian federation, one guardian can fail or act maliciously without disrupting operations. In a 7-guardian federation, the threshold rises to two.

Peg-In: Depositing Bitcoin

  1. The user sends bitcoin to the federation's on-chain multisig address
  2. The federation verifies the deposit reaches sufficient confirmations
  3. The user generates a random token and applies a blinding factor to it, creating a "blinded" version
  4. The federation signs the blinded token without seeing the actual value
  5. The user unblinds the signed token, obtaining a valid eCash note with the federation's signature

This blind signature process is the core privacy mechanism. The federation never learns which user received which eCash note, making it impossible to track balances or transaction patterns within the mint. For more on how blind signatures power eCash systems, see the Chaumian eCash on Bitcoin research article.

Internal Transfers

Moving value between federation members is straightforward: the sender gives eCash notes to the receiver, who redeems them with the federation and receives freshly minted notes. The federation verifies the signature is valid and that the note has not been spent before (preventing double-spending), but it cannot link the redeemed note back to its original issuance.

Lightning Integration

Fedimint connects to the Lightning Network through Lightning gateways: specialized clients paired with Lightning nodes. Gateways are not guardians and do not participate in federation consensus. A single gateway can serve multiple federations.

For outbound payments (a federation user paying a Lightning invoice):

  1. The user locks eCash to an HTLC enforced by the federation
  2. The gateway pays the Lightning invoice using its own node
  3. The gateway receives the payment preimage upon successful payment
  4. The gateway uses the preimage to claim the locked eCash from the federation

For inbound payments (someone paying a federation user via Lightning):

  1. The gateway receives the Lightning payment
  2. The gateway issues eCash to the user within the federation
  3. The user reveals a preimage that the gateway uses to settle the Lightning payment

Modular Architecture

Fedimint is designed as a general framework for federated applications. Core functionality is implemented through pluggable modules:

# Core Fedimint Modules
fedimint-wallet   # On-chain Bitcoin peg-in and peg-out
fedimint-mint     # eCash issuance and redemption (blind signatures)
fedimint-ln       # Lightning payment contracts via gateways

# Each module defines its own:
# - Input and output types
# - Consensus items
# - State management
# Cross-module transactions are supported
# (e.g., converting on-chain BTC to eCash in a single atomic tx)

Developers can build custom modules on top of Fedimint consensus, extending federations with functionality like stablecoin support, lending, or governance systems.

Privacy Model

Fedimint's privacy guarantees come from the Chaumian blind signature scheme. Within the federation, the following properties hold:

  • The federation does not know any individual user's balance
  • The federation cannot determine who was issued a specific eCash note
  • The federation cannot determine who redeemed a specific eCash note
  • The federation cannot trace any note's transaction history
  • The anonymity set for any note is the entire set of notes of that denomination ever issued by the federation

These properties are significantly stronger than what most Bitcoin Layer 2 solutions offer. Standard Lightning payments reveal payment amounts and timing to routing nodes via onion routing, and on-chain transactions are fully transparent. For a broader look at Bitcoin privacy approaches, see the Bitcoin privacy landscape research article.

Privacy does have boundaries: on-chain peg-ins and peg-outs are visible on the Bitcoin blockchain. Lightning payments through gateways expose payment information to the gateway operator. The privacy benefits apply only to activity within the federation.

Use Cases

Community Banking for Underserved Populations

Communities without reliable access to traditional banking can use Fedimint to create their own financial infrastructure. BitSacco in Kenya uses Fedimint to power digital savings groups (called chamas), enabling peer-to-peer payments and fiat-to-bitcoin conversion for communities that traditional banks do not serve. Bitcoin Ekasi in South Africa and Free Madeira in Portugal represent similar community-driven deployments.

Community Savings Groups

Organizations with existing trust relationships (churches, villages, cooperatives, or online communities) can operate federations to pool savings with distributed custody. Multiple guardians from the community manage funds collectively, preventing any single person from absconding with deposits while keeping the group self-sovereign.

Privacy-Preserving Bitcoin Access

Users who want strong transaction privacy without the complexity of CoinJoin coordination or running their own Lightning node can deposit bitcoin into a federation and transact using eCash. The blind signature scheme provides privacy automatically, without requiring technical expertise from the user.

Simplified Lightning Access

Running a Lightning node requires managing channels, liquidity, and uptime. Through Fedimint's Lightning gateways, federation members can send and receive Lightning payments without any of this operational overhead. The gateway handles all Lightning complexity on behalf of the community. For context on Lightning infrastructure challenges, see the Lightning service providers research article.

Fedimint vs. Other Approaches

FeatureFedimintCashuLiquid Network
Custody modelFederated (threshold multisig)Single mint operatorFederated sidechain
Privacy mechanismBlind signatures (eCash)Blind signatures (eCash)Confidential Transactions
Trust distributionDistributed across guardian quorumConcentrated in one operatorBlockstream-managed functionaries
BlockchainNone (eCash tokens)None (eCash tokens)Own sidechain
Target scaleSmall to medium communitiesFriends, family, small groupsInstitutional, exchange-level
Unilateral exitNoNoNo

For a detailed comparison of federated sidechain approaches, see the Liquid Network research article. For more on how threshold signatures work across Bitcoin protocols, see the FROST threshold signatures explainer.

Risks and Considerations

Custodial Risk

Despite the distributed trust model, Fedimint is custodial. If a quorum of guardians colludes or if enough guardian keys are compromised, deposited bitcoin can be stolen. Users cannot exit unilaterally: they must request a peg-out, and the federation must process it. If a quorum of guardians goes permanently offline, deposited bitcoin is lost.

Debasement Risk

Because of the blind signature privacy model, there is no way to publicly audit a federation's reserves. A malicious quorum could theoretically issue more eCash than bitcoin held, effectively inflating the supply. Users must trust the guardians not to debase the currency. This is an inherent tradeoff of the Chaumian eCash design: the same properties that provide privacy also prevent external auditability.

No Unilateral Exit

Unlike protocols such as Spark, where users retain the ability to exit to the Bitcoin base layer without counterparty cooperation, Fedimint users depend entirely on the federation to process withdrawals. This is a fundamental tradeoff of the federated custody model versus true self-custody solutions.

Federation Scope Limitations

Privacy guarantees hold only within a single federation. The anonymity set is limited to the federation's user base, which may be small in community deployments. Cross-federation transfers require going through Lightning or on-chain, which reintroduces transparency.

Gateway Trust

Lightning gateways are separate service providers that can selectively refuse to process payments or go offline. While multiple gateways can serve a federation (providing some redundancy), users must trust that at least one gateway will remain available and honest for Lightning payments to function.

Why It Matters

Fedimint addresses a real gap in the Bitcoin ecosystem: many people around the world cannot practically manage their own keys, run their own nodes, or navigate Lightning channel management. Rather than pushing these users toward large centralized custodians, Fedimint lets communities build their own financial infrastructure using trust relationships that already exist.

The protocol demonstrates that the tradeoffs between custody, privacy, and usability are not binary. By distributing trust across a known group and using Chaumian eCash for privacy, Fedimint creates a middle ground that may serve populations who currently lack access to both traditional banking and self-sovereign Bitcoin tooling. As the Layer 2 landscape continues evolving with solutions like Spark, Lightning, Liquid, and Fedimint, each protocol serves a different point on the custody and privacy spectrum.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.