Fedimint is a modular protocol for federated applications whose payment modules connect Bitcoin, Lightning Network and blind-signed e-cash. Users hold tokens of a particular federation, not their own key to each underlying bitcoin output.
Fedimint names software and a protocol. A selected guardian group operates a particular federation; the client app is another layer. Default modules provide a bitcoin wallet, mint and Lightning. Federation consensus is not Bitcoin consensus, and separate federations do not automatically share tokens or reserves. [Fedimint — Project overview] [Fedimint — Architecture]
The mint signs blinded requests; the client combines threshold signature shares and removes blinding. Current technical documentation describes BLS on BLS12-381, not FROST as the e-cash signature. Each denomination has its own key: blinding does not mean the mint cannot see the denomination tiers being issued. [Fedimint — Threshold Blind Signatures]
A signature can be verified against the federation key without establishing that the note remains unspent. The federation records spent nonces and rejects repeat spending. When copyable data are handed over, the receiver needs successful reissuance into fresh notes; merely receiving a string does not eliminate a race with another copy. [Fedimint — Threshold Blind Signatures]
An illustrative 3-of-4 issuance threshold requires three valid shares: one unavailable guardian still leaves the threshold possible, two do not. Three cooperating share holders can create signatures; cryptography alone ensures neither honesty nor backing. Verify both the e-cash threshold and bitcoin reserve authority in the specific configuration. [Fedimint — Threshold Blind Signatures] [Fedimint — Wallet Module]
For an on-chain deposit, the client proves an output accepted by the federation module. For withdrawal, the federation prepares and signs a bitcoin transaction from its reserve. An e-cash holder has no automatic unilateral signing right over that output. Guardian availability, reserves, fees and required confirmations remain redemption conditions. [Fedimint — Wallet Module]
A gateway connects the federation to Lightning and holds liquidity on both sides. V2 module documentation describes payment contracts and preimages; the gateway is not automatically a federation guardian. An unavailable or illiquid gateway can prevent payment even when the mint works. A Lightning interface does not prove instant withdrawal of any amount. [Fedimint — Lightning Module V2]
Blind signatures protect the cryptographic link between issuance and later redemption of a note. They do not remove timing and amount correlations, network metadata or information visible to counterparties and gateways. Distinguish observers and payment stages; a private note does not imply anonymous deposits and withdrawals. [Fedimint — Threshold Blind Signatures] [Fedimint — Lightning Module V2]
The recovery design uses the client root secret, encrypted snapshots and accessible federation history; support depends on application and version. It is not ordinary Bitcoin seed import into any wallet. Recovering notes and testing withdrawal are different checks: even a correct backup cannot restore missing reserves or the required guardians’ cooperation. [Fedimint — Client E-cash Backup and Recovery] [Fedimint — Wallet Module]
For the clearest picture, read this entry together with Cashu, Chaumian eCash, Lightning Network, Multisig, Counterparty risk, Self-custody. The reverse links also lead from Chaumian eCash, Cashu.