Fedimint fired two release candidates in 24 hours. Beta.2 landed July 28; beta.3 followed on July 29. Both are tagged as pre-release notices on GitHub, which in open-source convention means the project is past the point where feedback changes the API, the breaking changes are locked, the code is in enforcement mode, and the only question left is how many edge cases the testers find before the stable tag.
The reason for the double-tap is architectural triage. Between beta.2 and beta.3, the team rewrote the gateway ecash withdrawal path to remove custom denomination handling. In beta.2, a `SpendEcashRequest` could specify which denominations the user wanted to receive. By beta.3, that parameter is gone. The gateway now calls `send_oob_notes` internally and decides denominations on behalf of the user. It is a simplification that cuts the surface area of the withdrawal API, but it also means every wallet builder currently accepting custom denomination parameters has broken code the moment v0.12.0 goes stable.
That pain point is compounded by a second breaking change: the standalone `lnurlp` binary is deleted. In its place, the `fedimint-lnurl` crate becomes the canonical implementation. Operators no longer run a separate binary; instead, they link the library into their code. It sounds like a cleanliness move, consolidating two pieces of code into one, but it changes who controls the LNURL generation flow. When it was a binary, an operator could fork it, patch it, or run an old version indefinitely. When it is a library crate, the operator is bound to whatever version their gateway code links against. The `LnurlResponse` serde format also changed to untagged, and URL fields switched from `Url` types to plain strings to avoid normalization surprises. Again: simple from an engineering standpoint, breaking for anyone relying on the old type signatures.
The third wedge is the `VerifyResponse` preimage encoding. It shifted from raw bytes to a hex-encoded string per LUD-21 spec, the Lightning URL spec that Fedimint uses to glue ecash withdrawals to Lightning payment hashes. A small change in isolation; cascading in an integrator's test suite. And then there is LNv2 recurring payments: the old `recurringd` v1 implementation is severed from the codebase entirely. Operators must migrate to `recurringdv2` or lose recurring payment functionality altogether. The new `RoutingInfo` struct in `fedimint-lnv2-common` carries a fresh `lightning_alias` field, which opens up better peer discovery for ecash-to-Lightning routes, a feature gain, but it also means any code that constructs a `RoutingInfo` without populating the new field will compile, run, and then fail silently when Lightning nodes try to route through that alias.
Two betas in one day is not chaos. It is the shape of a project that has consensus on what the API should be and is now just chasing correctness. The dummy module was stripped to a pure testing mock; the dummy server consensus logic was removed. Fedimint contributors are not second-guessing themselves, they are closing loops. The question now is adoption timeline. Major fedimint operators, Stably, Fedi, the community federations running their own guardian sets, will need to rewrite or port their integration code. The beta cycle gives them a window to do it before the lock-in. Once v0.12.0 stable drops, the breaking changes become permanent API surface. Watch for the stable tag itself, then watch the deployment velocity among major operators. If a federation does not deploy within 30 days of stable, they are either blocked on a bug or reluctant to incur the integration cost. Either answer tells the ecosystem something important about whether v0.12.0 is actually the route to production stability or just another milestone on a longer runway.