Funding a multisig treasury across networks

A multisig treasury can fund another network by approving a transfer or bridge transaction on its source chain and receiving the assets at a treasury address on the destination chain. The source approval and destination receipt are separate events, even when a bridge presents them as one route.

The treasury is funded only when the intended assets arrive at an address the signers can control on the destination network.

Start by defining the destination outcome: which network, token and receiving address the treasury needs. A bridge moves value between networks; a swap may also change the asset along the way. For a comparison of how apps weigh those combined steps, see Acrossbridge route choices for apps. The choice matters to treasury accounting because the token received may differ from the token sent, and fees can reduce the final amount.

How does a multisig send funds across networks?

The signers approve a transaction from the treasury on the source chain, then the bridge or transfer mechanism delivers assets on the destination chain. In an EVM multisig, that source transaction might call a bridge contract directly, or send assets to a separate wallet or service that initiates the route. The multisig’s approval threshold applies to the source-chain transaction; it does not automatically approve a later transaction on the destination chain.

The receiving address must be usable by the treasury on the destination network. A contract address seen on one network is not proof that the same contract is deployed and controlled there. Confirm the destination treasury deployment and its signer configuration before submitting funds. If the bridge route requires a separate recipient field, verify that address in the transaction proposal as well.

What should signers verify before approving?

Signers should review the complete route and compare it with the treasury’s intended receipt. The proposal should make clear which assets leave, which assets should arrive, who controls the recipient, and what happens if the route stops before completion. Check these items together:

• Source network, token and amount, including the transaction’s expected fees.
• Destination network and treasury address, verified against the treasury’s deployment and records.
• Destination asset and minimum acceptable amount if the route includes a swap.
• Route status and recovery path if delivery or a later swap does not complete.

Bridge and swap routes can have different settlement and recovery steps. A source-chain transaction marked successful confirms that the source network processed it; it does not, by itself, prove that the destination treasury received the expected token. Treasury records should therefore distinguish the proposal, source transaction, bridge status and destination receipt.

What happens after the destination transfer arrives?

Confirm the receipt on the destination network before treating the transfer as available treasury balance. Check the receiving address, token contract and amount, then record the destination transaction alongside the source proposal. If the receipt is in a different asset than planned, update the treasury record to reflect what arrived rather than the original transfer amount.

Also check whether the destination treasury has the network’s native asset for future transactions. A token balance alone may not cover the network fee required to move or use those tokens. The practical approach is to fund the treasury in the asset it needs, route it to a verified address, and reconcile the destination receipt before approving downstream spending.