DynaFed Series - Part 2 of 5

Most Bitcoin sidechains and Bitcoin bridges claim decentralization as a design goal. Very few have a mechanism to actually achieve it.

Part 1 of this series explained why static Bitcoin bridge federations are a dead end, they can't add signers, can't remove failed ones, and impose a hard ceiling on decentralization that no roadmap can overcome. But identifying the problem is only half the story. The harder question is: what does a credible path to progressive decentralization for a Bitcoin sidechain actually look like?

Why "launch decentralized" doesn't work

There's a tempting narrative in crypto: launch permissionless from day one and let the market sort it out. In practice, Bitcoin L2s and sidechains that launch fully open without the infrastructure to manage it tend to end up centralized anyway, captured by a few well-resourced operators while maintaining the appearance of openness.

Premature permissionlessness isn't decentralization. It's a different kind of fragility. If you can't verify who's signing, can't manage who enters and exits the signer set, and can't respond when operators fail, you have a system that looks decentralized on paper but operates with less accountability than a well-managed federation.

Real Bitcoin sidechain decentralization isn't about where you start. It's about whether the architecture supports verifiable, progressive expansion of the trust set over time.

How DynaFed enables progressive decentralization

DynaFed gives Botanix something almost no other federated Bitcoin bridge has: a working, repeatable mechanism for expanding the federation where every step is consensus-enforced and independently verifiable.

Here's what each federation expansion looks like:

1. A larger signer set (M2) is proposed, including new members alongside existing ones

2. New and existing members run Distributed Key Generation (DKG) - no single party ever holds the full private key

3. Each participant publishes their public key share on-chain, so anyone can verify the new aggregate key

4. M2 activates the moment the attestations are published on-chain, a hard fork the entire network explicitly opts into

5. A dual-peg grace period ensures deposits flow to both old and new addresses

6. A final sweep transfers remaining funds, and the old federation is retired

Botanix can use this process to grow the federation from 16 signers to 25, then to 30, then to 64 with each expansion a concrete, auditable step toward broader trust distribution. 

Every upgrade is verifiable, not a trust-me event

This is the part that matters most if you care about Bitcoin bridge trust minimization.

Most federation changes in the bridge space, when they happen at all, are off-chain ceremonies. Operators coordinate privately, generate new keys, and switch over. Users trust that it happened correctly. There's no on-chain record. No independent verification.

DynaFed makes every federation upgrade a first-class protocol event:

• DKG attestations are on-chain - the cryptographic proof that the key ceremony completed correctly is public

• The aggregate public key is independently computable - anyone can derive it from the published key shares

• Activation is a hard fork - the entire network must adopt the new rules. No partial adoption. No ambiguity about which signer set is in control

• The full migration history is auditable - every federation configuration, every transition, on-chain forever

The difference between DynaFed and an off-chain key rotation is the difference between "trust us, we upgraded the signers" and "here's the cryptographic proof verify it yourself."

The honest framing

DynaFed operates in a permissioned context today. Botanix Labs proposes federation configurations and coordinated upgrades. There's no on-chain governance vote for membership. This is deliberate, in the early stages of a Bitcoin sidechain, controlled and accountable expansion is more robust than premature openness.

But the mechanism is what matters. The same DynaFed migration that replaces a failed signer is the same process that adds ten new ones. Each upgrade is irreversible in the right direction: the signer set gets larger, the trust distribution gets wider, and the system gets harder for any single party to capture.

The static alternative, a fixed Bitcoin bridge federation that can never change, isn't more decentralized. It's frozen. And frozen isn't a decentralization strategy. It's the absence of one.

Decentralization is a direction

If your standard is "fully permissionless or nothing," DynaFed isn't there yet. But if your standard is "show me the mechanism, show me the verification, and show me that it actually gets more decentralized over time" - DynaFed is the most honest answer in the Bitcoin L2 space.

Every upgrade adds signers. Every transition is consensus-enforced. Every key is verifiable. The federation changes. The direction is always toward broader distribution. And every step is on-chain for anyone to audit.

That's not a promise. It's a protocol property.

Previous: Part 1 - Why Bitcoin Bridges Need Upgradeable Federations