Timechain Wiki

Fedimint

9 min read

Fedimint is a federated chaumian-ecash protocol on top of Bitcoin and Lightning that lets small communities run their own custodial "mints" backed by a federation of guardians. Users deposit Bitcoin into the federation's pooled wallet; the federation issues blinded ecash tokens that the holder can spend privately within the mint or redeem for Bitcoin or Lightning. The federation runs Byzantine Fault Tolerant consensus among guardians (typically 4-15) using a threshold signature scheme — t-of-n where t-1 dishonest guardians cannot steal funds. The architecture deliberately introduces federation-level custodial trust in exchange for substantial UX gains: instant in-mint payments, strong recipient privacy (the federation cannot link payer to payee), and no per-user Lightning channel management. Conceived by Eric Sirion and Obi Nwosu and developed by the Fedi team and broader community, multiple federations are in production as of 2026, with growth in remittance corridors, community-bank deployments, and emerging-market communities. The protocol is a deliberate trade — trust-minimization for usability at the community-scale custody layer.

Why this note matters

Fedimint represents a deliberate design choice that the Bitcoin maximalist position has internal disagreement about: trading trust-minimization for usability at the community-scale federation layer. The Lightning-integration architecture preserves Bitcoin-denominated value flow (Fedimint mints are denominated in Bitcoin via Lightning), but the federation-guardian trust model is structurally different from self-sovereign Bitcoin holding.

Understanding Fedimint is important for engaging the broader Layer-2 trust-spectrum: pure self-custody → Lightning self-sovereignty → Lightning-with-LSPs → Fedimint federation → custodial wallet. Each step on the ladder trades trust-minimization for usability; Fedimint occupies a specific intermediate position with its own design considerations.

The chaumian-ecash architecture

Fedimint uses the Chaumian ecash construction (David Chaum, 1983) at its core:

  1. Deposit. Alice deposits Bitcoin into the federation’s pooled wallet via Lightning. The federation issues Alice blinded ecash tokens — cryptographic notes that the federation has signed but the federation does not know who holds them.
  2. Private transfer. Alice transfers ecash tokens to Bob by simply giving him the tokens. The transfer is off-protocol from the federation’s perspective; the federation does not see the transfer.
  3. Redemption. Bob redeems his ecash tokens with the federation in exchange for Bitcoin or Lightning. The federation verifies the ecash tokens are valid (the federation’s signature is present and the tokens have not been previously redeemed) and pays out.
  4. Privacy. The federation knows who deposited (Alice) and who redeemed (Bob) but cannot link the two — the blinding ensures the ecash token Bob redeems is cryptographically unlinkable to the token Alice originally received.

The privacy property is strong. Within a Fedimint mint, the federation cannot construct a transfer graph between depositors and redeemers. This is structurally better privacy than Lightning’s onion-routing provides — Lightning’s hop-level privacy is good but the LSP at routing endpoints sees substantial information; Fedimint’s federation-level privacy is structurally stronger.

The trust assumption. The privacy guarantee depends on the federation’s honest behavior in following the chaumian protocol. A compromised or coerced federation could in principle log all interactions and reconstruct the transfer graph. The privacy is operational-trust-bearing, not cryptographic-absolute.

The federation and guardian architecture

A Fedimint federation consists of a small group of “guardians” (typically 4-15 entities) who collectively run the mint:

  • Threshold signing. Most federation operations require a threshold of guardians (typically t-of-n where t > n/2) to sign. This means an honest majority of guardians can prevent any single guardian (or minority of guardians) from acting maliciously.
  • Byzantine Fault Tolerant consensus. Guardians run a BFT consensus protocol (HBBFT — Honey Badger BFT, in the current implementation) to agree on state transitions, ecash issuance, and redemption events.
  • Guardian operations. Each guardian operates infrastructure: a hardware-rooted signing key, network-accessible communication with other guardians, and software that participates in the consensus protocol.

The federation is small by design. Unlike Liquid’s federation of ~65 entities or Bitcoin’s globally-distributed miner-set, Fedimint federations are intended for community-scale deployment — a town, a remittance corridor, a Bitcoin-aligned business consortium. The small size enables community-trust dynamics that wouldn’t scale to global federations.

Federation governance. Different Fedimint federations have different governance models. Some are operated by a single organization with multiple guardians under common operational control; others are operated by genuinely independent guardians with separate operational responsibilities. The trust profile varies significantly across federations.

Lightning integration

Fedimint is designed to integrate tightly with Lightning. The federation typically operates one or more Lightning nodes that handle inbound deposits and outbound redemptions:

  • Inbound deposit. Alice sends a Lightning payment to the federation; the federation issues Alice ecash equivalent to the Lightning amount received.
  • Outbound redemption. Bob redeems ecash and the federation sends a Lightning payment to Bob’s destination of choice. The destination can be any Lightning-compatible address (BOLT11 invoice, Lightning Address, etc.).
  • Inter-mint transfers via Lightning. Two Fedimint federations can settle between themselves via Lightning payments, enabling cross-mint Bitcoin-denominated value flow.

The Lightning integration is what makes Fedimint a Bitcoin-denominated rather than altcoin-style system. The mint’s underlying value is Bitcoin (held in the federation’s pool wallet); ecash tokens are 1:1 backed claims on that Bitcoin (modulo federation fees and exchange-rate dynamics for non-BTC-denominated mints).

The custody-and-trust transition. From the holder’s perspective, the trust transition happens at the deposit moment. Once Alice deposits Bitcoin into the federation and receives ecash, Alice is in federation custody. Alice can redeem at any time (subject to the federation’s continued operation) and recover Bitcoin via Lightning.

Community-bank and remittance use cases

Fedimint’s principal deployed use cases:

Community-bank Bitcoin custody. A small community (a town, a remittance corridor, an aligned-community organization) operates a federation that custodies the community’s Bitcoin pooled. Community members hold ecash that represents claims on the pool; the federation handles base-layer-Bitcoin-and-Lightning logistics on behalf of the community.

Examples include:

  • El Salvador deployments — community Bitcoin mints operated by Bitcoin Beach Wallet and others, providing remittance-corridor and small-business-payment infrastructure
  • African remittance corridors — community-operated federations in Ghana, Kenya, and South Africa serving regional Bitcoin-aligned communities
  • Bitcoin-aligned business consortia — federations operated jointly by Bitcoin-business communities for shared Bitcoin-custody operations

Privacy-enhancing payment infrastructure. Users who want strong recipient privacy (better than Lightning’s hop-level privacy) for specific use cases. The custodial trust is accepted in exchange for the privacy improvement.

Reduced-friction Lightning access. Holders for whom Lightning self-sovereignty is operationally too complex can use a Fedimint mint to access Lightning-equivalent UX without managing channels, watchtowers, or inbound-liquidity. The Fedimint federation operates the Lightning infrastructure; the holder holds ecash.

Tradeoffs and design choices

Federated trust vs trust-minimization. Fedimint deliberately introduces federation-level custodial trust in exchange for UX improvements. The Bitcoin maximalist position has internal disagreement about the legitimacy of this tradeoff at scale. One disposition treats Fedimint as a legitimate intermediate tool for holders for whom pure self-sovereignty is operationally infeasible; a stricter position treats Fedimint with more skepticism.

Small-federation vs large-federation governance. Fedimint federations are small by design (4-15 guardians). This enables community-trust dynamics but limits each federation’s geographic and demographic reach. Scaling Fedimint at global scale would require either many small federations or larger federations that lose the community-trust dynamic. The architecture has been deliberately community-scoped.

Lightning-dependence vs Lightning-alternative. Fedimint depends on Lightning for Bitcoin-denominated value flow. As Lightning’s network state evolves (per The Lightning Network and Lightning Network operational critiques), Fedimint’s value-flow infrastructure evolves with it. Alternative integration paths (direct on-chain integration; integration with other Layer-2 systems) are technically possible but not deployed at scale.

Chaumian privacy vs auditability. The chaumian-ecash construction provides strong recipient privacy but makes the federation’s total ecash issuance harder to audit externally. Periodic Proof of Reserves attestations substitute for direct auditability; the trust profile remains federation-bearing.

Guardian compromise risk. A federation in which guardians are compromised or coerced could in principle steal user funds (via threshold signing of unauthorized transactions) or violate privacy (via logging interactions). The BFT consensus protects against minority compromise; majority compromise is the structural risk. Community-scale federations have community-monitoring dynamics that partially mitigate this.

Substantive analytical critique of federation-as-quasi-custodian risk lives in Custody concentration risks; the broader self-custody-discipline framework is in Self-custody configuration ladder.

Open questions for further development

  • What is the right equilibrium between Fedimint and self-sovereign Lightning? Different users have different operational capabilities; the ladder of self-custody disciplines has multiple legitimate rungs.
  • How does Fedimint scale to large numbers of federations? Inter-federation coordination (via Lightning) is operational but the meta-level architecture for hundreds or thousands of federations is unsettled.
  • What is the appropriate regulatory framing? Fedimint federations are structurally custodial; how regulatory authorities classify them is jurisdiction-specific and evolving.
  • How does Fedimint interact with KYC leakage dynamics? Community-scale federations may have less KYC pressure than global custodians but are not exempt from regulatory attention as they scale.
  • What is the long-run security and operational profile of community-operated federations? Operational mistakes, guardian-key compromises, federation-failure scenarios — these are real but under-tested empirically.

Canonical sources for this note

Foundational design

  • Eric Sirion (et al.), original Fedimint design (2022-2023): fedi.xyz and github.com/fedimint/fedimint
  • Fedimint specification: fedimint.org
  • Various conference presentations and blog posts by Eric Sirion and Obi Nwosu

Cryptographic primitives

  • David Chaum, “Blind Signatures for Untraceable Payments” (1983) — the chaumian-ecash construction
  • HBBFT (Honey Badger BFT) consensus protocol (Andrew Miller et al., 2016)

discussion references

Graph View

Backlinks