Improving Security and Efficiency in Bitcoin Custody on Botanix

In the blockchain world, decentralization is not just a buzzword, but the foundation of trust and value. Bitcoin is a vivid embodiment of this principle: by minimizing reliance on any single party, it creates a network in which anyone can participate and verify data, and no centralized authority can dictate the rules. This quality of trustlessness and censorship resistance gives Bitcoin its strength as credibly scarce digital money. The Bitcoin protocol sacrifices some convenience and throughput in order to preserve decentralization and its value. For example, strict limits on block size and script functionality ensure that the network remains decentralized, functional, and is not overloaded with excessive functionality as in the case of smart contracts, preserving its baseline design since genesis.

At the same time, these constraints limit Bitcoin's capacity to support Bitcoin Finance natively, including higher-throughput payments, programmable settlement, and more complex financial primitives. As a result, scalable Bitcoin Finance requires additional layers that extend functionality without weakening Bitcoin's trust and decentralization guarantees.

But in the case of Botanix, which aims to enable Bitcoin Finance through an EVM-compatible execution layer anchored to Bitcoin, evolution is necessary to ensure decentralization, improve functionality, resilience, and security as it grows. The Botanix sidechain was initially launched with a traditional fixed multisig federation - a defined group of validators that jointly sign peg-in and peg-out operations on Bitcoin. Although this "static federation" initially worked, in the long term it carries risk: if one participant's key is lost or a node becomes unavailable, there is no built-in mechanism to replace it. Moreover, the federation cannot adapt or expand without a hard-fork or launching a new chain.

DynaFed (Dynamic Federation) addresses this by turning the static multisig into an upgradable one. DynaFed lets the federation add, remove, or swap signers on the fly without halting the chain or risking user funds. This is achieved by treating the federation configuration as a consensus-upgradeable component with strict safeguards.

Core Benefits of DynaFed

DynaFed's core benefit is that the network never needs to pause or reset when the validator set changes. Crucially, moving from the old federation (M1) to the new federation (M2) isn't a quiet off-chain keyholder rotation - it's a consensus-level transition that the network must explicitly adopt. M2 only becomes authoritative once validators upgrade and begin following the rules that recognize the new federation at the agreed activation height. This is a hard-fork, and the entire network adopts the new rules, avoiding a "fork wars" scenario where different parts of the network disagree on which federation is in effect.

By design, DynaFed maintains the same trust assumptions as the original federation, while adding flexibility. In the existing Botanix model, the federation members are permissioned validators chosen by Botanix Labs (the federation coordinator). DynaFed does not introduce on-chain voting or staking to pick new members - instead, Botanix publishes an updated membership list (M2) off-chain, and then the protocol mechanisms execute the transition. The system assumes all validators are known and identified, so that they can be held accountable and (if needed) hand over keys for recovery.

• No downtime or chain restart. Because the upgrade happens on-chain through normal consensus (block by block), the Botanix sidechain never needs to stop producing blocks. Validators continue signing and blocks continue finalizing throughout the migration.

• Fund security and continuity. User funds are never at risk of being frozen. During the transition both the old and new multisig addresses can receive peg-ins, so people can keep depositing bitcoin normally. Because the M2 key is created via DKG and then confirmed through on-chain attestations, the network can verify that the new aggregate public key is the authentic output of the key ceremony.

• Smooth member rotation. DynaFed makes it possible to add new signers or remove old ones gradually. A misbehaving or failed node can be swapped out by replacing it in M2 (while preserving the 2/3 threshold with the rest). Crucially, the old keys do not need to remain active for peg-outs during the transition - the protocol's secret-share and voting steps migrate control safely.

Stages of migration from M1 to M2

The DynaFed breaks the upgrade into a series of coordinated steps on-chain. In broad strokes, the sidechain starts with federation M1, then transitions over time to a new M2. Each step is consensus-enforced and carefully sequenced:

1. Propose the new federation (M2) and distribute config. Botanix (the coordinator) publishes a new configuration file listing both the current M1 members and the incoming M2 members. In practice, this configuration is bundled with the upgraded node software. At this stage nothing has changed on-chain yet; it's just announcing the candidate for the new group.

2. Run Distributed Key Generation for M2. The nodes in the proposed M2 begin a distributed key generation (DKG) protocol to create the new multisig key. Each M2 node generates a private share of the new threshold key so that no one ever learns the full private key. After the DKG completes, each M2 participant publishes its public key share on-chain, enabling any network participant to compute the final aggregated public key and validate that it matches the peg-in destination address.

3. Activate M2 once the attested key is computable. After participants publish their on-chain attestations, the network can deterministically compute the M2 aggregate public key. Activation is driven by the consensus rules themselves - when conditions are met at the agreed activation height, the chain begins treating M2 as the authoritative federation.

4. Validate and commit the new key. Once activation conditions are met, the M2 key is officially live. Any network participant can independently compute and validate the final aggregated public key from on-chain attestations, serving as cryptographic proof that the DKG completed successfully.

5. Begin migration (dual-peg grace period). The minting logic is updated to accept peg-in deposits to both the old M1 gateway address and the new M2 address. Users can continue sending BTC to either address and have their deposits credited normally. Meanwhile, the federation can gradually move liquid UTXOs from M1 to M2 to prepare for the final sweep.

6. Final sweep transaction. After the grace period ends, the bridge/minting contract is switched to accept deposits only from the new M2 address. All remaining bitcoin held by the old M1 address is then swept into a single transaction sending those UTXOs to the M2 change address. Once this sweep is confirmed on the Bitcoin mainnet, the migration is complete.

7. Activate M2 validators and shut down M1. The sidechain's validator set is updated to the new M2 group: incoming nodes are added as block validators and outgoing nodes are removed. Afterward, the old M1 nodes are no longer needed and can safely turn off.

Throughout the process, the chain never stops producing blocks and never loses user funds. All consensus steps are recorded on-chain, so honest nodes can always audit that the upgrade followed the rules.

Note: Botanix Labs may operate an additional, out-of-band recovery service to help users recover funds mistakenly sent to a deprecated peg-in address after a migration. While not part of DynaFed's core consensus mechanics, it's an extra safety net aligned with Botanix's goal of protecting users.

Considerations and Limitations

DynaFed introduces powerful flexibility, but it does so in a permissioned context. Botanix Labs remains the federation coordinator (the rules explicitly exclude any on-chain voting for membership), and each migration proposal is an off-chain decision by the coordinator. The two-thirds overlap rule is strict: any upgrade must have a supermajority of the entire network to opt in (via the hard-fork upgrade), so activating M2 is ultimately a consensus decision rather than a signer-overlap requirement. This constraint isn't a flaw but a security feature - it prevents any abrupt takeover by an unrelated set of nodes.

Conclusion

DynaFed is a crucial evolution for the Botanix sidechain's security model. It transforms the federation from a brittle, one-shot multisig into a consensus-upgradable custody system. The M1 to M2 migration workflow allows federation membership and keys to rotate on the live chain in a coordinated, consensus-driven upgrade, preserving continuity and keeping the custody layer verifiable throughout the transition. Users never experience downtime and never risk losing funds simply because a validator changed.

This also enables gradual expansion of the federation. Botanix may initially operate with 16 signers and subsequently scale to 25, 30, or up to 64 signers through successive updates, thereby increasing decentralization over time. In each case, the dynamic update can be done without endangering funds or interrupting service. DynaFed makes the sidechain much more robust: it can onboard new validators, retire old ones, and recover from unforeseen incidents, all while Bitcoin pegging continues uninterrupted.

Welcome to the dynamic era of Botanix - an important step toward lifting key bottlenecks in Bitcoin Finance.