DynaFed Series -  Part 4 of 5

The first three parts of this series covered the why: why Bitcoin bridge federations need to be upgradeable, why that's the prerequisite for decentralization, and what security guarantees DynaFed provides during the process.

This part covers the how. The actual M1-to-M2 migration works every step, what it does, and what you can verify at each stage.

Understanding the mechanics matters because in a system that custodies real Bitcoin, the process is the security model. DynaFed's value isn't just that federation upgrades are possible. It's that every step is consensus-enforced, cryptographically verifiable, and designed so that funds are never at risk.

Step 1: Propose the new federation

The upgrade begins when Botanix publishes a new configuration listing the intended new signer set (M2). This configuration is bundled with updated node software, every participant in the network sees the proposed membership by upgrading to the new version.

At this stage, nothing has changed on-chain. It's a public declaration of intent: "We intend to switch to the following signer set at the upgrade." The existing federation (M1) continues operating normally.

Step 2: Distributed Key Generation

The proposed M2 members run a Distributed Key Generation (DKG) protocol to create the new multisig threshold key. This is the cryptographic foundation that makes the whole system work.

During DKG, each M2 participant generates a private share of the new signing key and communicates with the others through secure channels. When DKG completes, every M2 node holds one private share and crucially, no single party ever learns or holds the full private key. The group collectively knows the new aggregate public key, but no individual can sign alone.

This is the same threshold cryptography that secures the federation in normal operation. The difference is that DynaFed makes the output of this ceremony verifiable on-chain, not something users take on faith.

Step 3: On-chain attestation

After DKG completes, each M2 participant publishes their public key share on-chain as an attestation. This is the step that transforms a private key ceremony into a publicly verifiable event.

With these attestations available, any network participant can independently compute the final aggregated public key and validate that the corresponding peg-in destination address is legitimate. You don't need to trust the coordinator's announcement. You don't need to trust the signers' claim. The math is on-chain, and anyone can run it.

Step 4: Consensus activation

At a pre-agreed block height, the chain begins recognizing M2 as the authoritative federation. This is a hard fork - the entire network must adopt the updated consensus rules.

This is deliberately all-or-nothing. Nodes that haven't upgraded will diverge from the canonical chain. There's no scenario where half the network follows the old federation and half follows the new one. The network opts in collectively, or the activation doesn't happen.

This eliminates the most dangerous class of Bitcoin bridge migration failures: split-brain scenarios where different parts of the network disagree about which signer set is authoritative.

Step 5: Dual-peg grace period

The system enters a defined migration window during which deposits are accepted at both the old M1 address and the new M2 address. Users can send BTC to either one and have their deposit credited normally.

This protects users who haven't updated their deposit address. No funds are stranded. No deposits are lost because someone used a cached or bookmarked address. The protocol handles the transition, users don't need to know it's happening.

Meanwhile, the federation can begin consolidating UTXOs from M1 to M2, preparing for the final handover.

Step 6: Final sweep

After the grace period ends, the minting logic switches to accept deposits only from M2. All remaining Bitcoin held by M1 is swept into a single transaction sending those UTXOs to the M2 address. This sweep may include any pending peg-out payments.

Once confirmed on the Bitcoin mainnet with sufficient depth, the migration is complete. No funds remain under the old federation's control. M2 is the sole authority.

Step 7: Validator handover

The sidechain's validator set is formally updated: incoming M2 nodes are added as block producers and outgoing M1 nodes are retired. CometBFT supports live validator reconfiguration, so this change happens smoothly on-chain. The old federation nodes can safely shut down.

This is the part that separates DynaFed from every off-chain key rotation in the Bitcoin bridge space:

• Step 1: The proposed M2 membership is public - bundled with the node software update.

• Step 2: DKG produces a threshold key where no single party holds the full private key, the ceremony's success is proven by the attestations in Step 3

• Step 3: DKG attestations are on-chain and the aggregate public key is independently computable from published key shares

• Step 4: Activation is a hard fork - either the entire network adopted the new rules, or it didn't.

• Step 5: The dual-peg window is protocol-enforced, both addresses mint correctly during the grace period

• Step 6: The final sweep is a Bitcoin transaction - visible on-chain to anyone

• Step 7: The validator set change is on-chain - auditable in the sidechain's consensus history

At no point in this process does verification depend on trusting a coordinator's claim. The data is on-chain. The cryptography is public. The activation is consensus-enforced. If you want to know whether a DynaFed migration happened correctly, you can check for yourself.

One more thing: Botanix also operates an out-of-band recovery service for users who accidentally send funds to a deprecated M1 address after the grace period ends. It's not part of the core protocol, but it's an additional safety net ensuring simple user mistakes don't turn into permanent losses.

Previous: Part 3:  Zero Downtime. Zero Fund Risk.