---
title: "Cross-chain governance and multi-chain execution"
url: "https://caper.network/wiki/dao-governance/concepts/fundamentals/cross-chain-governance"
updated: 2026-08-11
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Cross-chain governance and multi-chain execution

|  |  |
| --- | --- |
| **Topic** | How a DAO that votes on one chain executes decisions on another – and what the message carrier costs it |
| **Core problem** | Whatever transports a passed proposal inherits the DAO's authority. Forge the message and you are the governor. |
| **Pattern 1 – one voted-in bridge** | Uniswap picks a bridge per deployment by governance vote (Wormhole for BNB Chain, [Jan 2023](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0x6b8df360fdf73085b21fdf5eef9f85916fbde95621a3d454cb20fbe545ffc852)) |
| **Pattern 2 – consensus across bridges** | Aave's [a.DI](https://github.com/bgd-labs/aave-delivery-infrastructure) requires 3-of-4 or 2-of-3 independent adapters to agree on the routes where no canonical bridge exists |
| **Pattern 3 – exit through the rollup** | Arbitrum's DAO votes on L2 and executes via an L2→L1 message plus a challenge period: [≈37 days](https://docs.arbitrum.foundation/dao-constitution) for a Constitutional AIP |
| **Failure of record** | Nomad's August 2022 exploit stranded Uniswap deployments governance had already approved; both had to be re-legislated with a new bridge |
| **Caper's position** | Single-ledger. Vote, treasury and execution settle in one atomic transaction, so there is no carrier to trust or lose. |

**Cross-chain governance** is what a [DAO](/wiki/dao-governance/concepts/fundamentals/what-is-a-dao) needs when the chain it votes on is not the chain it controls. The token, the governor contract and the vote live in one place; the pools, the treasury positions or the protocol deployments live somewhere else. Between the two sits a message – and that message is the whole problem.

A passing vote is not an action. Something has to carry the result from the governor to the contract that will obey it, and whatever does the carrying holds the DAO's authority for the duration of the trip. If an attacker can forge a message that appears to come from the governor, they do not need tokens, delegates or a quorum; they are the governor. This page covers the three patterns in production, the failure that proved the point, and what each one actually costs.

## Pattern one: vote on the bridge itself

Uniswap's expansion to BNB Chain in early 2023 is the clearest case of a DAO treating its message transport as a governance decision rather than an implementation detail, because it held two separate votes: one on _whether_, one on _through what_.

The first temperature check, [“Should Uniswap v3 be deployed to BNB Chain?”](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0xa3c7247632d3a08e4e73a63867908d0cd4402f48fa673945f93e3197dee5450a), closed on 22 January 2023 with 20,066,279 UNI for and 4,928,281 against across 6,495 votes – 80.3% of the weight cast. The second, ten days later, asked [“Which bridge should Uniswap v3 use for cross-chain governance messaging between Ethereum and BNB Chain?”](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0x6b8df360fdf73085b21fdf5eef9f85916fbde95621a3d454cb20fbe545ffc852) and offered four answers. It closed on 31 January 2023 with 8,348 votes and 45,581,689 UNI of weight distributed as follows.

| Bridge | UNI weight | Share |
| --- | --- | --- |
| Wormhole | 28,403,915 | 62.3% |
| LayerZero | 17,173,339 | 37.7% |
| deBridge | 3,773 | <0.01% |
| Celer | 663 | <0.01% |

Read the second table as what it is: a token-weighted electorate choosing which third party may hold its protocol's admin authority on another chain. The DAO recognised the awkwardness immediately. In the same month the Uniswap Foundation opened a [Cross-Chain Bridge Assessment Process](https://gov.uniswap.org/t/cross-chain-bridge-assessment-process/20148) to fund an independent review – four engineers and a project manager, compensated at $300 and $200 per hour, explicitly barred from having "a vested interest in any bridge" – whose deliverable was a review that "identifies risk vectors to Uniswap governance, assigning them a risk level (Green, Yellow, Red)" and a recommendation on selecting providers, including "diversifying deployments across a set of trusted bridges (on a 1/n basis, or otherwise)."

## What happens when the carrier dies

Uniswap governance approved a v3 deployment on Gnosis Chain in April 2022, with Nomad as the governance bridge. On 1 August 2022 Nomad was drained of roughly $190 million after an upgrade initialised its trusted root to zero, making every message [provable by default](https://medium.com/nomad-xyz-blog/nomad-bridge-hack-root-cause-analysis-875ad2e5aacd). The deployment was never delivered.

Eleven months later the Gnosis team returned to the Uniswap forum to ask for the same decision again, noting that the deployment [“has been put on hold because the proposed bridge provider (Nomad) is no longer an option”](https://gov.uniswap.org/t/continue-the-uniswap-v3-deployment-on-gnosis-chain-with-different-bridge-provider/20724) and proposing Wormhole in its place. Moonbeam followed within a fortnight, describing itself and Gnosis as [“both communities … in limbo with an approved license but without a deployment”](https://gov.uniswap.org/t/continue-the-uniswap-v3-deployment-on-moonbeam-with-different-bridge-provider/20831).

This is the load-bearing lesson of cross-chain governance, and it is not about bridge security. Both DAOs had _already decided_. Quorum was met, the vote passed, the record stands. What expired was the transport, and because the decision could only be delivered through that transport, the decision expired with it. A DAO's proposal is durable exactly as long as the mechanism that carries it, and re-legislating an unchanged decision costs a fresh forum cycle, a fresh temperature check and a fresh on-chain vote – Uniswap ran that whole loop under the deadline of its v3 business-source licence expiring on 1 April 2023.

The corollary is a design question worth asking before a deployment, not after: if the bridge in this proposal is compromised or wound down, does the proposal fail closed, or does it need to be voted again? See [DAO tooling discontinuity](/wiki/dao-governance/concepts/analysis/dao-tooling-discontinuity) for the same failure in other parts of the stack.

## Pattern two: require several carriers to agree

Aave's answer is to stop trusting any single bridge. [a.DI (Aave Delivery Infrastructure)](https://github.com/bgd-labs/aave-delivery-infrastructure) describes itself as "a cross-chain communication abstraction layer for decentralised systems like the Aave DAO to communicate across networks, minimising the risk of underlying individual bridge provider failures, via consensus rules." Messages hub through Ethereum: a `CrossChainController` on Ethereum forwards to every governed network, and a message is only acted on once the required number of independent adapters have delivered an identical copy.

The consensus rule is per route, and the repository's deployment table publishes each one. Read on 11 August 2026, twenty-one non-Ethereum networks are listed:

- **3-of-4** – Polygon, in both directions.
- **2-of-3** – Avalanche (both directions), BNB Chain, Gnosis, Celo, Sonic and Plasma.
- **1-of-1** – the remaining fourteen: Arbitrum, Optimism, Base, Metis, Scroll, Polygon zkEVM, Linea, zkSync, Soneium, Ink, Bob, Mantle, MegaETH and X Layer.

Two thirds of the routes running at a single adapter looks careless until you notice which ones they are: every 1-of-1 destination is an Ethereum rollup, where the single adapter is that chain's own canonical L1→L2 messaging and the trust assumption is the rollup's proof system rather than an external validator set. The redundancy is concentrated exactly where no such path exists. The principle generalises past Aave: **require independent confirmations in proportion to how much of the carrier you have to trust**, and stop paying for redundancy where the carrier is already the chain itself.

The adapters are themselves governed. a.DI's own changelog lists Aave proposals that updated the CCIP adapters, refreshed the native bridge adapters, and migrated the LayerZero adapter to V2 and the Hyperlane adapter to V3. A DAO that adopts this pattern acquires a permanent maintenance obligation: its transport layer is a standing item on its agenda, and every adapter upgrade is a governance vote about its own ability to govern.

## Pattern three: leave through the rollup's own door

The Arbitrum DAO votes on Arbitrum One and cannot execute there. Its [Constitution](https://docs.arbitrum.foundation/dao-constitution) routes a passed Constitutional AIP out to Ethereum and back, and publishes the clock:

- **Phase 4 – L2 waiting period.** "a 3 day waiting period for actions related to the DAO Treasury and an 8 day waiting period for an L2-to-L1 Message," so that objectors can "initiate withdrawal of their funds or take other action on L2."
- **Phase 5 – the L2→L1 message.** "at least 1 challenge period of the rollup protocol" before the message finalises on Ethereum, "after any withdrawals initiated during or soon after the voting period have been recognized on L1."
- **Phase 6 – L1 waiting period.** A further three days, "so that users who initiated withdrawals or other L2-to-L1 messages have time to execute them on L1 before the AIP takes effect."
- **Phase 7 – implementation.** Execution "may happen on L1 or via a transaction sent from L1 to one or more Governed Chains."

End to end the Constitution budgets "37 days from the beginning of the temperature check in Phase 1 until an AIP is finally executed in Phase 7 for a Constitutional AIP, or 27 days for a Non-Constitutional AIP."

Nothing in that path trusts a third party – the carrier is the rollup's own proof system – and the whole cost lands in time. It is worth being precise about what the delay buys, because it is easy to mistake for procedural drag. Phases 4 and 6 are not review windows for the proposal; they are [exit windows](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) for the people it binds. The Constitution deliberately orders the clock so that a member who dislikes a passed AIP can complete a withdrawal to L1 _before_ the AIP takes effect. Trust-minimised cross-chain execution and a meaningful right of exit turn out to want the same delay, which is why [governance timelocks](/wiki/dao-governance/concepts/voting/governance-timelocks) and bridge finality end up on the same schedule.

## Designing one: the questions that actually decide it

Every cross-chain governance system answers the same six questions, and the answers are what distinguishes the three patterns above:

- **Where does authority originate?** The chain holding the token and the governor is the chain whose reorgs, censorship and outages become governance risk everywhere else.
- **What carries the message?** A canonical rollup bridge, an external validator set, or several of the latter in agreement.
- **How many independent carriers must agree?** One is a single point of failure unless that one is the chain itself.
- **Who can change the carrier?** If adapters are upgradeable, the upgrade key is a second governor. Aave routes those changes through the same DAO vote; that is the conservative answer.
- **How long does the trip take, and who is protected by the delay?** Time in the path is not waste if it is the window in which members can leave.
- **What happens to passed-but-undelivered proposals if the carrier dies?** Uniswap's answer, learned the expensive way, was to vote again.

Related reading: [on-chain vs off-chain governance](/wiki/dao-governance/concepts/fundamentals/on-chain-vs-off-chain-governance), [DAO security and governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), [who pays to execute a passed proposal](/wiki/dao-governance/concepts/analysis/proposal-execution-costs), and [security councils and emergency powers](/wiki/dao-governance/concepts/fundamentals/security-councils).

## How Caper approaches this

Caper does not solve cross-chain governance. It declines the problem, and the trade is worth stating in both directions.

A caper's vote, its treasury and its execution live on one ledger, and a passed proposal settles in a single atomic transaction. Verified against the contracts: a PAYOUT winner executes through `execute_proposal_payout`, which binds the frozen winning option and transfers from the treasury to the recipient recorded when the proposal was created – the source is explicit that the transfer "goes to the STORED, voted-on recipient, so no executor can redirect it," and a once-only guard means it cannot run twice. An INVEST winner runs entirely inside one method: the treasury's XRD is withdrawn, the target caper's tokens are bought and redeposited, and the XRD never reaches the worktop where it could be skimmed.

There is consequently no message in the path, no relayer, no adapter set to maintain, no consensus rule to tune, and no window in which a decision the members already made can be stranded by an unrelated protocol's failure. Nothing between the tally and the transfer can be exploited, deprecated or wound down, because there is nothing between them.

The cost is the plain one: a caper can act only on assets that exist on Radix. A DAO whose holdings span several chains needs one of the three patterns above, and should price the carrier accordingly. See [execution](/wiki/governance/execution) and [raising funds](/wiki/markets/raising-funds) for how a caper's treasury actually moves.

## References

- [Uniswap Snapshot – Temperature Check: Should Uniswap v3 be deployed to BNB Chain? (Jan 2023)](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0xa3c7247632d3a08e4e73a63867908d0cd4402f48fa673945f93e3197dee5450a)
- [Uniswap Snapshot – Temperature Check: Which bridge should Uniswap v3 use for cross-chain governance messaging between Ethereum and BNB Chain? (Jan 2023)](https://snapshot.box/#/s:uniswapgovernance.eth/proposal/0x6b8df360fdf73085b21fdf5eef9f85916fbde95621a3d454cb20fbe545ffc852)
- [Uniswap governance forum – Cross-Chain Bridge Assessment Process (Jan 2023)](https://gov.uniswap.org/t/cross-chain-bridge-assessment-process/20148)
- [Uniswap governance forum – Continue the Uniswap V3 deployment on Gnosis Chain with different bridge provider (Mar 2023)](https://gov.uniswap.org/t/continue-the-uniswap-v3-deployment-on-gnosis-chain-with-different-bridge-provider/20724)
- [Uniswap governance forum – Continue the Uniswap V3 deployment on Moonbeam with different bridge provider (Mar 2023)](https://gov.uniswap.org/t/continue-the-uniswap-v3-deployment-on-moonbeam-with-different-bridge-provider/20831)
- [bgd-labs/aave-delivery-infrastructure – a.DI specification, deployed addresses and per-route consensus rules](https://github.com/bgd-labs/aave-delivery-infrastructure)
- [The Arbitrum DAO Constitution – AIP phases, waiting periods and execution path](https://docs.arbitrum.foundation/dao-constitution)
- [Nomad – Bridge hack root cause analysis (Aug 2022)](https://medium.com/nomad-xyz-blog/nomad-bridge-hack-root-cause-analysis-875ad2e5aacd)