Botanix Labs
Apr 22, 2026
Over the last four parts, this series has covered why Bitcoin bridge federations need to be upgradeable, why that's the foundation for real decentralization, what DynaFed guarantees during a migration, and exactly how the M1-to-M2 process works. This final part answers the question that matters most: what does Botanix actually do with this capability?

DynaFed Series - Part 5 of 5
Over the last four parts, this series has covered why Bitcoin bridge federations need to be upgradeable, why that's the foundation for real decentralization, what DynaFed guarantees during a migration, and exactly how the M1-to-M2 process works.
This final part answers the question that matters most: what does Botanix actually do with this capability?
Where things stand today
Botanix launched with a founding federation of recognized industry participants including names like Galaxy, Fireblocks, Alchemy, XBTO, Antpool geographically distributed and running on diverse security hardware. Botanix Labs has relinquished direct operational control, transferring consensus to the node operators.
This is a permissioned federation. Botanix Labs coordinates upgrades and proposes new membership configurations. There's no on-chain governance vote for who becomes a signer. Every participant is known, identified, and accountable.
If you care about decentralization, this starting point should be familiar. It's how nearly every Bitcoin sidechain and federated bridge begins. The difference is what happens next.
The expansion path
With DynaFed, "what happens next" isn't a vague promise. It's a concrete, repeatable process:
16 → 25 → 30 → 64 signers through successive DynaFed migrations. Each expansion follows the same consensus-enforced process covered in Part 4 - DKG, on-chain attestation, hard fork activation, dual-peg grace period, final sweep.

Every step widens the trust set. Every step is auditable. And every step makes the federation harder for any single party including Botanix Labs to capture or control.
This is what separates DynaFed from every other federated Bitcoin bridge's "decentralization roadmap." The mechanism isn't waiting for a future software release. It's not dependent on a governance token launch. It's not blocked by an undefined technical breakthrough. It exists today, it works today, and each use of it is a verifiable step forward.
Maintaining federation health along the way
Expanding the signer set only works if the existing federation is healthy. A federation that's lost members, missed signing rounds, or accumulated unresponsive nodes isn't in a position to grow, it's in a position to fail.
DynaFed handles this too. The same migration mechanism that expands the federation is the same one that replaces underperforming signers. Nodes with frequent downtime can be swapped out. Operators who've left the ecosystem can be retired. The threshold is maintained, and the federation stays operational.
This creates a compounding effect: a healthy federation can be expanded. A larger federation is more resilient to individual failures. Greater resilience means more confidence for new participants to join. The cycle continues, each upgrade building on the stability of the last.
Without this maintenance capability, expansion is risky. You're adding new signers to a foundation that may already be cracking. DynaFed ensures the foundation is solid before you build higher.
The two-thirds rule: a feature, not a limitation
Every DynaFed activation requires a supermajority of the network to opt in via the hard fork upgrade. This is strict by design. It prevents any abrupt takeover by an unrelated set of nodes. It ensures that federation changes are genuine consensus events, not coups.
For anyone worried about a coordinator unilaterally swapping in a friendly signer set, this is the safeguard. Botanix Labs can propose a new configuration, but the network has to adopt it. If nodes don't upgrade, the activation doesn't happen. The coordinator proposes. The network decides.
This constraint slows things down. That's the point. Deliberate, verified expansion is how you build a federation that's genuinely distributed, not one that changed overnight and asked everyone to trust the result.
What permissionless actually requires
Let's be clear about what it takes to go from a permissioned federation to a fully permissionless one. It's not just about the number of signers. It requires:
Open participation: anyone meeting defined criteria can join as a signer without coordinator approval
Economic alignment: staking or bonding mechanisms that align incentives and penalize misbehavior
Automated rotation: protocol-level signer selection and rotation without manual coordination
Dispute resolution: on-chain mechanisms for challenging and removing bad actors

DynaFed doesn't deliver all of these today. What it delivers is the infrastructure layer that every one of these features requires. You can't have open participation without a mechanism for adding signers. You can't have automated rotation without a process for swapping them. You can't have dispute resolution without a way to remove them. DynaFed is the foundation. The permissionless features are what gets built on top.
The honest closer
Every federated Bitcoin bridge talks about decentralization. Almost none of them have a protocol-level mechanism to move in that direction.
DynaFed is that mechanism. It's live. It works. And every time it's used to expand the signer set, to replace a failed node, to onboard new participants the federation becomes wider, more distributed, and harder to capture.

Is Botanix permissionless today? No. Is there a working, verifiable, consensus-enforced process for getting there? Yes. And every step of that process is on-chain for anyone to audit.
That's not a roadmap slide. It's a protocol capability. And it's the most honest answer to the decentralization question that any federated Bitcoin sidechain can give.
Previous: Part 4: How a Federation Upgrade Actually Works - Step by Step