How to Design a Fork-Contingent Treasury Management Plan

A fork-contingent treasury management plan is a strategic framework for a DAO or protocol to protect its assets and maintain operational continuity in the event of a contentious network fork. Unlike planned upgrades, contentious forks—like the Ethereum/Ethereum Classic or Bitcoin/Bitcoin Cash splits—create uncertainty over which chain will retain the "canonical" status, community, and economic value. Without a pre-defined plan, a treasury holding native assets (e.g., ETH, SOL) can be instantly duplicated on both chains, forcing rushed, reactive decisions that may lead to loss of funds, governance paralysis, or support for the "losing" chain. This guide outlines the principles and actionable steps to create a resilient plan.

The core principle is asset neutrality and verifiable execution. Your plan should not predict which fork will "win"; instead, it should define clear, on-chain verifiable rules for how treasury assets are managed on both resulting chains. This involves three key components: custody strategy (how to secure forked assets), governance activation (how to decide on post-fork actions), and liquidity provisioning (how to ensure the DAO has usable funds). For example, a plan might stipulate that 100% of forked assets on Chain A are locked in a timelock contract for 30 days, while assets on Chain B are made available immediately for a specific emergency budget, with all parameters decided before the fork occurs.

Designing the plan requires mapping your treasury's exposure. Start by cataloging all assets: native chain tokens (highest risk), bridged assets (dependent on bridge operator policies), and non-native assets (like stablecoins on Layer 2s, which may not fork). For native tokens, use multi-signature wallets or smart contracts like Safe{Wallet} with a defined threshold of signers. Crucially, the signer set and transaction policies must be established on the original chain to be inherited by the fork. A common mistake is relying on a governance token vote after the fork, as the token itself will be duplicated, making a clear outcome impossible.

The governance mechanism to enact the plan must be pre-programmed and fork-agnostic. This often means using a conditional token lock or fork detection oracle. For instance, you could deploy a smart contract that holds a portion of the treasury. This contract uses an oracle (like Chainlink or a decentralized court like UMA) to detect a persistent fork after a certain block height. Based on the oracle's report, the contract automatically executes predefined actions: releasing funds, swapping assets, or extending a lock-up. This removes subjective, post-fork debate and ensures the community's pre-fork intent is executed trustlessly on both chains.

Finally, communicate and test the plan. The finalized strategy should be ratified by an on-chain governance vote on the main chain, providing legitimacy. The full technical specification, including smart contract addresses and multisig configurations, must be publicly documented. Consider running a simulated fork on a testnet to validate the behavior of your custody setup and any automated contracts. A well-designed fork-contingent plan transforms a potential crisis into a managed event, protecting the treasury's value and allowing the DAO to make strategic decisions about supporting either chain without the pressure of imminent financial loss.

A fork-contingent treasury management plan is a formal strategy for a decentralized organization to navigate a potential blockchain split. Its primary goals are to preserve treasury value, ensure operational continuity, and uphold governance legitimacy across any resulting chains. This is not just a technical checklist; it's a governance and risk mitigation framework. Key components include defining trigger events, establishing multisig signer policies, creating asset distribution rules, and outlining post-fork governance procedures. Without such a plan, a DAO risks asset loss, protocol paralysis, and community fragmentation during a high-stakes network event.

The first step is risk assessment and scenario planning. Identify the types of forks your protocol must prepare for: a contentious hard fork (e.g., Ethereum/ETC), a planned upgrade fork, or a user-activated soft fork. For each scenario, model the impact on your treasury's major assets: native tokens (e.g., ETH on Ethereum), bridged assets (e.g., USDC via LayerZero), and LP positions. Determine which smart contracts, oracles, and infrastructure will be affected. This analysis directly informs the fork activation triggers documented in your plan, such as a specific block height or a governance vote passing a supermajority threshold.

Treasury asset segmentation and key management are critical. The plan must specify the custody of assets on each potential fork chain. For native tokens, this often involves pre-determining a multisig configuration (e.g., 5-of-9 signers) that is replicated on both chains, with clear instructions for signers to follow the plan's rules. For complex DeFi positions, the plan should authorize a technical committee to execute a pre-approved unwinding or migration strategy. A common best practice is to use deterministic address derivation, ensuring the same multisig wallet address exists on both forks, controlled by the same entity, to prevent loss of access.

The plan must be ratified by governance before a fork occurs. This involves a formal snapshot vote or on-chain proposal to adopt the Fork Contingency Plan as an official appendix to the DAO's governing documents. The vote should establish the plan's authority, designate the emergency multisig signers, and delegate execution power to a specified committee or role. This pre-approval is essential; attempting to coordinate a response during the chaos of an active fork is inefficient and risky. The ratified document should be publicly accessible, like the Lido Fork Management Strategy.

Finally, establish clear post-fork governance and communication protocols. The plan should define how the DAO will determine its "canonical" chain, often through a follow-up governance vote. It must outline a process for reconciling treasury balances and communicating decisions to users and integrators. This includes updating front-ends, indexers, and oracle configurations. A successful plan turns a potential crisis into a managed transition, preserving the protocol's value and community trust across both chains, as demonstrated by protocols that navigated forks like Ethereum Classic and Bitcoin Cash.

A fork-contingent treasury plan is a proactive governance and operational framework designed to protect a protocol's assets and functionality in the event of a chain split. Unlike simple multi-signature setups, it anticipates the unique challenges of forks: - Asset duplication (the same keys control funds on both chains) - Governance paralysis (disagreement over which chain is 'legitimate') - Operational divergence (smart contracts may behave differently). The core principle is sovereignty through preparation, not reaction. Leading DAOs like Uniswap and Aave have had to navigate these waters, making structured planning essential for any protocol holding significant on-chain value.

The first technical step is key and access management. Relying solely on a single set of multi-sig signers is a critical risk, as they unilaterally control the duplicated treasury on the forked chain. A resilient plan employs a multi-chain governance module. This involves deploying a dedicated smart contract (e.g., using a framework like Zodiac's Reality Module) that allows token holders on each resulting chain to vote independently to authorize a new set of signers for the treasury on that chain. This ensures the community following each fork retains control of its respective assets, preventing hostile takeovers.

Smart contract architecture must be fork-aware. Treasury management contracts should not hardcode chain-specific assumptions like block times, finality, or oracle addresses. Use abstracted interfaces and upgradeable proxies (e.g., OpenZeppelin's TransparentUpgradeableProxy) to allow for post-fork adjustments. For example, a contract using Chainlink oracles must have a governance-controlled function to update the oracle address on a new fork, as price feeds will diverge. Example code snippet for an updatable oracle:

solidityCopy
address public oracleAddress;
function updateOracle(address _newOracle) external onlyGovernance {
    oracleAddress = _newOracle;
}

Liquidity and asset strategy is equally crucial. Holding assets in cross-chain bridges or wrapped tokens (e.g., wETH on L2s) introduces bridge dependency risk—if the bridge pauses or takes sides in a fork, assets may be frozen. The plan should mandate holding a significant portion of the treasury in the native gas token on its primary chain and in non-bridged, canonical assets (like native USDC on its origin chain). Furthermore, liquidity provision (LP) positions should be structured to be unwindable on either potential fork, avoiding reliance on AMM contracts that may not be deployed or functional identically on both chains.

Finally, the plan must be codified in governance. This involves a pre-written, executable proposal that details the steps to: 1) Activate the fork-contingency module, 2) Ratify new signer sets via chain-specific votes, 3) Execute critical contract updates (oracles, bridges), and 4) Rebalance core asset holdings. This proposal should be stored in an immutable location like IPFS or Arweave, with its hash recorded on-chain. Regular fork drills, simulating the execution of this plan, ensure operational readiness. The goal is not to prevent forks but to ensure the treasury and protocol remain under community control, no matter how the network evolves.

A standard multi-sig wallet like Gnosis Safe operates identically on every chain. In a fork scenario, the same transaction could be valid and executed on both the original chain and the new fork, potentially draining the treasury on one side. A fork-aware multi-sig prevents this by embedding chain-specific validation logic into its core execution. This is typically achieved by checking a unique, immutable chain identifier within the smart contract's execution context, such as the block.chainid in Solidity or the CHAIN_ID opcode in the EVM.

The core design involves overriding the standard transaction execution flow. Instead of proceeding directly, the contract first verifies the current chainid against a pre-configured list of authorized chains stored in the contract's state. For example, a DAO might pre-approve Ethereum Mainnet (chainId: 1) and an authorized L2 (chainId: 10 for Optimism). Any transaction submitted on an unrecognized chain (like a new, contentious fork with chainId: 10001) would automatically revert. This creates a fail-safe default where funds are locked on unauthorized chains until the DAO governance explicitly votes to adopt the new fork.

Implementation requires modifying the executeTransaction function in your multi-sig contract. A basic Solidity snippet for a fork-aware check might look like this:

solidityCopy
function executeTransaction(
    address to,
    uint256 value,
    bytes calldata data,
    bytes32 salt
) public onlyOwner returns (bool) {
    uint256 currentChainId = block.chainid;
    require(authorizedChains[currentChainId], "ForkAwareMultiSig: Unauthorized chain");
    // ... proceed with signature verification and execution
}

The authorizedChains mapping is set at deployment and can only be updated via a multi-sig transaction itself, ensuring governance control.

Beyond simple allow/deny logic, advanced designs can implement fork-contingent routing. This allows a single transaction proposal to specify different destination addresses or calldata for different chain IDs. For instance, after a fork, a treasury might need to bridge assets back to the canonical chain or deploy new contracts on the forked network. The multi-sig can store these contingent instructions and execute the correct one based on the runtime chainid, automating the post-fork strategy defined by governance.

Key deployment considerations include using immutable variables for the initial authorized chain list to prevent a rogue governance takeover on a new fork from reconfiguring the contract. Additionally, the contract must be deployed at the same address on all authorized chains, which can be achieved using the CREATE2 opcode with a deterministic salt. This ensures a consistent interface and verification process for signers across all networks. Tools like the Safe{Core} Protocol are beginning to explore native fork-awareness features.

The primary trade-off is increased complexity and gas costs for each transaction due to the extra chainid check and storage read. However, for managing substantial DAO treasuries often exceeding millions of dollars, this overhead is negligible compared to the security benefit. It transforms the multi-sig from a passive tool into an active fork contingency enforcer, ensuring the community's post-fork capital allocation strategy is executed precisely as mandated by governance votes.

A fork-contingent treasury contract is a stateful smart contract that encodes a DAO's asset allocation strategy directly on-chain. Its core logic defines how funds are distributed between different asset classes (e.g., stablecoins, native tokens, LP positions) and, critically, how that allocation shifts in response to a chain fork. The contract's state—its current holdings and the active allocation rules—is publicly verifiable, eliminating reliance on opaque multisig decisions. We'll build this using Solidity, with a structure that separates the allocation policy from the asset custody.

The contract architecture centers on a ForkStatus enum and a mapping to AllocationRule structs. The ForkStatus can be STABLE, SOFT_FORK_PENDING, or HARD_FORK_OCCURRED. Each AllocationRule defines maximum percentage allocations for different asset types (like maxStablecoinPercent, maxNativeTokenPercent). A key function, updateAllocationForForkStatus(ForkStatus newStatus), allows a designated governance module (e.g., a DAO's token voting contract) to switch the active rule set based on perceived network risk. This function should include a timelock and emit a clear event for transparency.

Here is a simplified code skeleton for the core data structures and state-changing function:

solidityCopy
enum ForkStatus { STABLE, SOFT_FORK_PENDING, HARD_FORK_OCCURRED }

struct AllocationRule {
    uint8 maxStablecoinPercent; // e.g., 60 for 60%
    uint8 maxNativeTokenPercent;
    uint8 maxLiquidityPoolPercent;
    // ... other asset caps
}

contract ForkContingentTreasury {
    ForkStatus public currentForkStatus;
    mapping(ForkStatus => AllocationRule) public rules;
    address public governance;

    event ForkStatusUpdated(ForkStatus newStatus, uint256 timestamp);

    function updateAllocationForForkStatus(ForkStatus newStatus) external {
        require(msg.sender == governance, "Unauthorized");
        currentForkStatus = newStatus;
        emit ForkStatusUpdated(newStatus, block.timestamp);
    }
}

The actual asset rebalancing would be triggered by separate, permissioned rebalance() functions that compare current holdings against the active AllocationRule.

Integrating with DeFi primitives is essential for execution. The treasury contract should hold function stubs that interact via secure patterns: using safeTransfer for ERC-20s, interacting with verified DEX router contracts (like Uniswap V3's SwapRouter) for swaps, and depositing into audited lending markets (like Aave's LendingPool). All such external calls must be hardcoded to specific, immutable contract addresses on the canonical chain to prevent manipulation during a fork. Consider using a registry pattern to manage these external dependencies, which can be updated via governance during peacetime.

Security and transparency are enforced through on-chain verifiability. Anyone can audit the contract's:

• Current ForkStatus and active AllocationRule.
• Full balance of all held assets via balanceOf calls.
• History of all ForkStatusUpdated events.
• Permissioned roles (the governance address). This design ensures the DAO's treasury strategy is not a subjective promise but an executable, verifiable program. The final step is extensive testing on a forked mainnet environment, simulating fork scenarios to ensure the rebalancing logic executes as intended without introducing new vulnerabilities.

A fork-contingent treasury management plan is a set of pre-defined, on-chain rules that automatically govern how a protocol's treasury assets are allocated in the event of a chain split. The core challenge is encoding the nuanced, often qualitative decisions of a community—its social consensus—into deterministic smart contract code. This involves moving beyond simple technical triggers (like a specific block height) to incorporate signals that reflect collective human agreement, such as token holder votes, governance proposal outcomes, or the adoption metrics of a new chain.

The first design decision is selecting the consensus signal that will trigger the treasury split. Common mechanisms include: - A snapshot vote of the native governance token holders. - The outcome of an on-chain governance proposal executed via a tool like Compound's Governor or OpenZeppelin Governor. - A multi-sig execution based on a pre-agreed social consensus from forums like Discord or Commonwealth. The chosen signal must be trust-minimized and resistant to manipulation, ensuring the split reflects the genuine will of the protocol's stakeholders and not a short-term attack.

Once the trigger is defined, the logic for asset allocation must be encoded. This specifies what percentage of each treasury asset (e.g., ETH, stablecoins, protocol tokens) is claimable by users or contracts aligned with each fork. A common pattern is a proportional split based on the final governance vote. For example, if 80% of voters support Fork A, then 80% of the treasury's DAI could be allocated to a ForkATreasury contract. This requires an on-chain asset registry and logic for calculating and distributing shares.

Implementation typically involves a ForkResolution smart contract. This contract would: 1. Accept and validate the consensus signal (e.g., verify a passed governance proposal ID). 2. Calculate the allocation ratios for each recognized fork. 3. For each asset in the registry, transfer the appropriate amount to a designated vault or distributor contract for each fork. It's critical that this contract has no upgradeability after deployment to prevent post-fork manipulation, and its ownership should be renounced or placed in a time-locked, community-controlled contract.

Consider a DAO with a treasury on Ethereum that faces a potential fork. The community ratifies a plan stating: "If a governance proposal to recognize Fork B passes with >66% approval, 40% of the treasury's USDC and 10% of its staked ETH will be allocated to Fork B's designated contract." This social rule is encoded into a ForkResolution contract that polls the DAO's Governor contract. Upon execution, it automatically pulls the specified assets from the treasury's Gnosis Safe and streams them to the fork's contract, enforcing the community's will without requiring further trust in individual signers.

The core of testing a fork-contingent plan is simulating the exact conditions of a network split. This requires using a mainnet fork—a local or testnet copy of the live Ethereum state—rather than a generic testnet like Goerli. Tools like Hardhat, Foundry's forge create --fork-url, or Tenderly allow you to fork the mainnet at a specific block. You then deploy your smart contracts and treasury management scripts to this forked environment, which contains real token balances, DeFi positions, and oracle prices, providing a realistic simulation sandbox.

Your primary test suite must validate the fork detection and asset segregation logic. Write tests that simulate the chain split event. For example, using Foundry, you can write a Solidity test that calls your determineCanonicalChain() function after forking from a block before a contentious upgrade and then again from a block after, asserting the correct outcome. Crucially, test the execution of splitTreasuryAssets() by checking that token balances are correctly divided according to your predefined rules and that all transfers succeed without leaving funds in a vulnerable, indeterminate state.

Beyond unit tests, conduct integration simulations for the full contingency workflow. Script the entire sequence: 1) Fork detection, 2) Multi-sig pause and governance activation, 3) Asset segregation execution, and 4) Post-fork reallocation. Monitor for edge cases like sudden liquidity loss in forked DEX pools, oracle failures on the minority chain, or gas price spikes. Tools like Ganache for forking or Tenderly Simulations are ideal for these dry runs, allowing you to inspect every transaction state change and gas cost without financial risk.

Finally, establish a pre-mortem and go/no-go checklist. Before mainnet deployment, the team should review: Are all dependency addresses (oracles, bridges, DEX routers) correctly configured for fork detection? Are the multi-sig timelocks and thresholds set? Has the simulation been run on a recent mainnet fork block? Documenting and signing off on these items turns your tested code into a reliable, executable emergency procedure, ensuring your treasury can navigate a chain split with minimal manual intervention and maximal asset security.

To move from theory to practice, begin by formalizing your plan in a governance proposal. This proposal should detail the specific on-chain conditions that will trigger the treasury split, such as a snapshot of token holders at a predetermined block height. Crucially, it must specify the execution mechanism, whether it's a custom smart contract, a multi-signature wallet script, or a tool like SafeSnap. Documenting this process transparently builds trust with your community and ensures all stakeholders understand the protocol's continuity plan.

Next, conduct a dry run or simulation on a testnet. Deploy your forking contract (e.g., a modified version of a token distributor) and execute the planned steps with a subset of treasury assets. Test edge cases: what happens if a major holder sells before the snapshot? How are LP positions or vested tokens handled? Tools like Tenderly or Foundry's fork testing are invaluable here. This simulation validates your technical approach and reveals unforeseen complexities before mainnet deployment.

Finally, establish a maintenance and review schedule. Blockchain ecosystems evolve rapidly; a plan written today may need updating in six months. Schedule quarterly reviews to assess: - Changes in treasury composition (new asset types, protocol integrations). - Evolution of forking tools and best practices (e.g., new Safe modules). - Shifts in the broader regulatory landscape. Treat your contingency plan as a living document, ensuring it remains a robust defense against existential protocol risk and a clear roadmap for your community's potential future.