Fedimint is open-source software and a protocol that lets a group of guardians, called a federation, run a shared payment system. It issues e-cash: digital tokens intended to be redeemed for bitcoins from its reserve. Users hold those tokens, not independent authority to sign withdrawals from the reserve.
Imagine Anna uses a wallet connected to a local federation and Petr accepts its e-cash at his café. Their payment need not create a separate Bitcoin transaction for every coffee. The apps handle digital tokens issued by a shared mint. The actual bitcoins remain in the federation’s reserve; Anna and Petr transfer tokens between them. Fedimint provides the building blocks, guardians operate a particular federation, and the wallet is Anna’s interface to it. These are different things. The standard modules handle Bitcoin, Lightning Network and e-cash; additional modules can provide other services. Each federation has its own operations and reserves, and its tokens are not automatically accepted by all the others. Even when its guardians agree on an action, Bitcoin’s rules still apply. [1] [2]
A federation aims to keep important operations from depending on a single operator. With an illustrative 3-of-4 threshold, issuing a token requires three valid signature shares from four guardians. One unavailable guardian still leaves enough shares; two do not. But three cooperating share holders can also produce signatures without the remaining guardian’s consent. Dividing authority does not itself guarantee honesty or sufficient reserves. This is Counterparty risk: dependence on people or organizations that might fail to pay. Threshold e-cash signing and Multisig, shared authority over the Bitcoin reserve, also serve different purposes. Check their actual rules in the chosen federation. [3] [4]
When Anna deposits bitcoin directly through the blockchain, the public history of confirmed transactions, her wallet app supplies proof of the relevant output, which the federation must accept under its rules. Each output records an amount and the conditions for spending it. Withdrawal reverses the process: the federation constructs and signs a Bitcoin transaction from its reserve. A token alone gives Anna no key that lets her withdraw the reserve without the others. That is a crucial difference from Self-Custody, holding the keys used to sign Bitcoin payments yourself. Payment still requires available guardians, enough funds, fees and the required confirmations. Fast transfers inside the system do not promise equally fast withdrawals of any amount. [4] [7]
E-cash privacy relies on a Blind Signature. The client first mathematically hides the particular token, requests a signature, then removes the blinding. The result is verifiable, but the mint cannot use the token alone to link its later redemption to a specific issuance request. For technically curious readers, the documentation describes threshold BLS signatures on BLS12-381, not FROST as the token signature. The client combines enough valid shares into one verifiable signature. Each denomination has its own key, so hiding token identity does not hide the denomination tiers being issued from the mint. [3]
Petr can check that a token bears a valid federation signature. This does not tell him whether someone redeemed it already. Digital data can be copied, and Anna might still have the same token. The federation therefore records spent token identifiers, called nonces, and rejects reuse. A recipient needs a successful exchange for fresh tokens instead of relying on a promise that another copy will not be used. A genuine signature, an unspent token and sufficient Bitcoin reserves are three separate questions. Checking one does not answer all three. [3]
If the café accepts an ordinary Lightning Network payment, a gateway can arrange the transfer. It connects the federation to Lightning and needs liquidity, meaning available funds, on both sides. The gateway need not be a federation guardian. Documentation for the V2 module describes contracts that make releasing funds conditional on the payment and a preimage, a secret value revealed when its condition is fulfilled. Failed payments have recovery paths under the relevant contract, but that does not guarantee continuous availability. A failed gateway or insufficient liquidity can stop a payment even when the mint works. [5]
A blind signature prevents the mint from using the token alone to link its issuance to its later redemption. It does not erase all other traces. The recipient may know Anna paid, a gateway sees information needed to handle the Lightning payment, and an observer may compare timing or amounts. Network connection data may offer another clue. Always ask what should be hidden from whom: a mint guardian, the café, a gateway or a network observer. More private token circulation does not automatically anonymize every deposit, withdrawal and interaction between people. [3] [5]
A lost phone need not mean lost tokens if the app supports properly configured recovery. The documented design uses a master secret value from which the app can recalculate its required data, encrypted snapshots and available federation history. The exact procedure depends on the app and version; it is not simply entering a Bitcoin Seed Phrase into any wallet. Before relying on the service, test client recovery and a small bitcoin withdrawal separately. A backup helps recover lost data, but cannot refill an empty reserve or compel enough guardians to cooperate. [6] [4]
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, Blind Signature, Cashu.