On June 2, Fedimint shipped v0.11.2-alpha.1 on its stable releases branch, and buried inside a backport patch was a structural break: the project removed LNv2 functionality from recurringd v1, the daemon that powers recurring Lightning payments for Fedimint federations. Any operator still running v1 will lose that capability until they upgrade to v2. It is a hard deprecation dressed up as a maintenance release.
Recurringd is the piece of infrastructure that lets Fedimint users receive stable, inbound Lightning Address-style payments, the kind of thing a merchant or a content creator needs to collect tips or subscription fees without managing multiple UTXO states. Removing LNv2 from v1 is not a bug fix; it is a signal that v1 is no longer the canonical path forward. The release notes do not soft-pedal it: operators are instructed to use recurringd v2. In a low-fee environment like the current one (1–3 sat/vB on Mempool.space), federation operators can settle on-chain cheaply, which removes one friction point for the migration, but the migration itself is mandatory for anyone who promised users stable recurring payment endpoints.
But the real break is that this forces federation operators to think of recurring payments as a service layer, not as federation-level functionality. In v0.11.x, recurringd v1 with LNv2 was the default path. In v0.11.2-alpha.1, it does not exist anymore. Operators have to consciously choose v2. That might sound trivial until you realize it is exactly how Fedimint is now thinking about federation architecture: not as a monolith, but as a set of pluggable, versioned components. And the release proves it.
Shipped in the same patch are two experimental modules: MintV2 and WalletV2. They land as opt-in, disabled by default, and must be explicitly enabled at federation genesis. These are not tweaks to existing modules; they are the first public experimental next-generation modules Fedimint has shipped. MintV2 presumably handles minting logic in a new way; WalletV2 handles the on-federation wallet layer. What matters is the setup path: a federation operator now has to choose whether to lock in the new modules at genesis or stick with the current v1 architecture. That choice was not available before. It creates a fork in how federations are bootstrapped.
The technical surface area of v0.11.2-alpha.1 is wider than the headline suggests. The RoutingInfo struct gained a lightning_alias field; ChannelInfo gained an address field for the remote peer. The jemalloc allocator is now feature-gated (enabled by default but not forced on downstream code). The VerifyResponse preimage encoding changed to hex-encoded strings per LUD-21, replacing raw bytes. None of these are breaking changes for users, but they are signals of internal refactoring, the kind of churn you see when a project is preparing its infrastructure for a larger shift.
What to watch: whether new federation deployments adopt MintV2 and WalletV2 at setup. If adoption is near-zero, it means operators do not trust experimental modules at federation genesis, and Fedimint's modular architecture story stalls. If adoption picks up, it means federation operators are willing to lock in next-gen components early, betting that Fedimint can iterate on them without requiring a full federation migration. The recurringd v2 migration timeline matters too, if operators delay, it signals that changing payment infrastructure is operationally harder than Fedimint expects. And watch the fee environment: if fees spike above 10 sat/vB, on-chain settlement costs for federation snapshotting and withdrawal batches start to bite, which could slow adoption of new federation architectures that increase on-chain settlement frequency.