Cross-chain governance is what 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.
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?”, 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?” 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 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)."
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. 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” 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”.
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 for the same failure in other parts of the stack.
Aave's answer is to stop trusting any single bridge. a.DI (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 and re-read unchanged on 3 September 2026, twenty-one non-Ethereum networks are listed:
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.
The Arbitrum DAO votes on Arbitrum One and cannot execute there. Its Constitution routes a passed Constitutional AIP out to Ethereum and back, and publishes the clock:
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 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 and bridge finality end up on the same schedule.
All three patterns carry a decision from the chain where the vote happens to the chain it controls. Aragon's multichain governance plugin moves the vote instead, so that holders can vote where transactions are cheap (Aragon, November 2023). Holders bridge the DAO's token to ZKsync Era using LayerZero's Omnichain Fungible Token standard, which burns the token on one chain and mints it on the other; they vote there; and LayerZero relays the result back to the DAO on its home chain, whose permission system can then act on several chains.
In September 2024 Aragon released a second version, called Toucan, and made voting on ZKsync free to the voter through a paymaster, a contract that pays another account's gas, funded by Aragon (Aragon). It said it was exploring storage proofs with RISC Zero, which would let the home chain read the votes directly and remove the bridge.
Agora's multichain governor module, announced in November 2024, reads balances instead of moving tokens. A holder votes once on the governor's chain; the governor asks LayerZero's lzRead to read the holder's voting power on each chain where the token lives and return a single total, and each DAO chooses which, and how many, of LayerZero's verifier networks must attest to the read (Agora). No token is bridged, and each chain's token needs only the standard ERC20Votes interface.
In both designs a carrier now delivers the vote count, or the balances behind it, rather than the decision, so a forged count would pass a proposal the holders did not pass. The questions below apply to that leg of the trip unchanged.
Every cross-chain governance system answers the same six questions, and the answers are what distinguishes the three patterns above:
Related reading: on-chain vs off-chain governance, DAO security and governance attacks, who pays to execute a passed proposal, and security councils and emergency powers.
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 and raising funds for how a caper's treasury actually moves.