DynaFed Series - Part 3 of 5

The previous two parts of this series made the case for why Bitcoin bridge federations need to be upgradeable for decentralization and for resilience. But upgradeability introduces its own question, and it's the first one any security-minded person should ask:

What happens to my funds during the upgrade?

It's a fair concern. Cross-chain bridge hacks have drained billions from users;  from Ronin's $624M exploit to Harmony's $100M key compromise. In most of those cases, the vulnerability wasn't exotic. It was mundane: compromised private keys, weak multisig thresholds, or upgrade processes that gave attackers an opening. Bridge security fails when the machinery around key management is fragile.

So if DynaFed lets Botanix change its federation, the security guarantees during that change need to be airtight. Here's what DynaFed actually guarantees.

The chain never stops

During a DynaFed migration, the Botanix sidechain keeps producing blocks the entire time. There's no maintenance window. No pause. No restart. Validators continue signing, transactions continue processing, and users continue transacting as if nothing is happening.

This matters because downtime during a Bitcoin bridge upgrade is a single point of failure. If the chain pauses while keys are being rotated, there's a window where the system is vulnerable to coordination failures, to timing attacks, or simply to user confusion. DynaFed eliminates that window entirely. The upgrade happens through normal consensus, block by block.

Deposits keep flowing to both addresses

One of the biggest fund safety risks during any bridge federation change is the handover period. If the bridge switches from one multisig address to another, what happens to deposits sent to the old address? On most bridges, if they can even change their federation the answer is "hope users got the memo."

DynaFed handles this with a dual-peg grace period. During the transition, the minting logic accepts deposits to both the old (M1) and the new (M2) federation address. Users can send BTC to either one and have their deposit credited normally. No funds are stranded. No deposits are lost because someone used a cached address.

This dual-peg window runs for a defined period, giving the ecosystem time to update while the protocol guarantees continuity. Only after the grace period ends does the system switch exclusively to the new address and a final sweep moves all remaining BTC from the old federation to the new one.

The new key is verifiable

This is the Bitcoin bridge security property that separates DynaFed from every off-chain key rotation.

When the new federation (M2) is created, each participant runs Distributed Key Generation and publishes their public key share on-chain as an attestation. From those published shares, anyone on the network can independently compute and validate the final aggregate public key and confirm that the peg-in destination address is legitimate.

You don't need to trust Botanix Labs' announcement. You don't need to trust the signers' claim that DKG happened correctly. The cryptographic proof is on-chain, and anyone can verify it. This is the difference between "we changed the keys, here's a blog post" and verifiable, on-chain key attestation that any node can audit.

Activation is all-or-nothing

DynaFed activations are hard forks. The entire network must adopt the new consensus rules recognizing the updated federation. There's no partial rollout, no silent upgrade, no scenario where some nodes follow the old signer set and others follow the new one.

This eliminates the most dangerous class of bridge upgrade failures: split-brain scenarios where different parts of the network disagree about which federation is authoritative. With DynaFed, the network opts in collectively on on-chain attestation validation or the activation doesn't happen. No ambiguity. No fork wars.

What this means in practice

During any DynaFed migration, here's what holds true:

• Chain operation: Blocks produced continuously. Zero downtime.

• Deposits: Accepted at both old and new addresses throughout the transition.

• Withdrawals: Processed normally by the active federation.

• Key verification: New aggregate public key is independently computable from on-chain attestations.

• Activation: Consensus-enforced hard fork. The entire network opts in or it doesn't happen.

• Fund transfer: Final sweep moves all remaining BTC to the new federation after the grace period.

• Recovery: Botanix may operate an out-of-band recovery service if deposits mistakenly are sent to a deprecated address after migration.

Every step is on-chain. Every key is auditable. And at no point during the process are user funds frozen, at risk, or dependent on trusting a private handoff.

That's what Bitcoin bridge security looks like when the upgrade process is designed as a first-class protocol feature- not an afterthought bolted on later.

Previous: Part 2:  Decentralization Isn't a Launch Feature. It's a Process.