Nomad Docs
  • Nomad 101
    • Funds Recovery
    • Introduction
    • Our Mission
    • Getting Started
  • The Nomad Protocol
    • Overview
    • Cross-chain Messaging
      • Lifecycle of a Message
    • Verification Mechanisms
      • Background on Verification
      • Native Verification
      • External Verification
      • Optimistic Verification
      • Comparing Mechanisms
    • Security
      • Root of Trust
        • Fraud
          • Optimistic Timeout Period
          • Fraud Recovery
        • App-Governed Root of Trust
        • Liveness Assumptions
      • Attack Vectors
        • Key Compromise
        • Economic Attacks
        • Smart Contract Bugs
      • Long-Term Security
        • Permissionless Watchers
        • Financial Controls
        • Cross-Domain MEV
    • Smart Contracts
      • Home
      • Replica
      • XAppConnectionManager
    • Off-chain Agents
      • Updater
      • Watchers
      • Relayer
      • Processor
  • Token Bridge
    • Overview
    • How to Bridge
      • Using Etherscan
      • Nomad Bridge App
      • Testnet Bridge App
    • Asset Issuers
      • Custom Representations
    • Deployed Tokens
      • Mainnet
      • Testnet
    • Smart Contracts
      • BridgeRouter
      • TokenRegistry
      • BridgeToken
      • BridgeMessage
    • Architecture
    • FAQ
  • Governance Bridge
    • Overview
    • Zodiac: Nomad Module
    • Smart Contracts
      • NomadModule
    • Architecture
  • Developers
    • Quickstart
      • Send Messages
      • Receive Messages
    • Environments
      • Domain (Chain) IDs
    • Application Developers
      • Building xApps
      • SDK
        • Contracts SDK
        • Typescript SDK
      • Examples
        • Ping Pong
        • Example Bridge GUI
        • xApp Example
      • Advanced
        • Router Pattern
    • Node Operators
      • Running Agents Guide
        • Troubleshooting
      • Running a Watcher
      • Agent Operations
      • Agent Gas Values
      • The Keymaster
    • Core Developers
      • Upgrade Setup
      • Deploying Contracts
        • Development
        • Production
  • Operational Security
    • Audits
    • Bug Bounty
    • Governance
    • Contracts
    • Agent Operations
  • Resources
    • Awesome Interoperability
    • Brand Kit
    • FAQ
    • Glossary
    • GitHub
    • Discord
    • Twitter
    • Website
Powered by GitBook
On this page
  • Governance: A Brief History
  • A better solution: Zodiac + Nomad
  1. Governance Bridge

Overview

PreviousFAQNextZodiac: Nomad Module

Last updated 2 years ago

While many people believe the "killer app" for interoperability is token bridges, we believe there is an equally important and exciting opportunity in enabling effective cross-chain governance. That's why Nomad partnered with Gnosis to create the (ZNM) - which gives DAOs/protocols access to an out-of-the-box cross-chain governance solution that is simple, trust-minimized, and standardized.

The sections below will provide context on the need for effective cross-chain governance, how DAOs/protocols have attempted to implement cross-chain governance to-date, and why the ZNM module is an improvement over other governance solutions available.

If you are interested in using Nomad for cross-chain governance, please reach to us at gm@nomad.xyz.

Governance: A Brief History

The Early Days of Decentralized Governance

Cross-chain governance is a pain point that DAOs are now beginning to experience as they expand beyond Ethereum. In order to understand how we arrived here, we need to look at recent history to understand the current governance landscape.

Following Compound's launch of $COMP in the summer of 2020 (DeFi Summer), many DeFi protocols/apps and DAOs began decentralizing ownership to their communities via a governance token. This ownership model allowed early users and believers of a protocol to become governance stakeholders and shepherd its growth through a DAO rather than a core team.

Compound's governance framework quickly became the status quo, and its still continues to serve as the gold standard for governance frameworks to this day. In large part, the playbook for governance is now straightforward, and many DAOs have adopted it successfully - enabling their token holders to propose, vote, and execute governance actions on-chain.

More Chains, More Problems

Initially, when most protocols launched decentralized token-based governance, they deployed these systems exclusively on Ethereum Mainnet.

Today, many of these DAOs are faced with a problem: their governance is deployed on one chain (typically Ethereum), but their protocol is deployed on many chains. This leads to a setup where the collective "brain" lives on one chain, with many "satellites" deployments that need to mirror the core deployment.

Governance on Ethereum has no way to communicate to Polygon or Optimism

In a multi-chain world, DAOs are effectively limited in their ability to govern their own protocols on different chains. Without some way to communicate the results of a governance vote to their satellite deployments, protocols become out of sync and inconsistent.

Attempted Solutions for Cross-Chain Governance

Many of the earliest DeFi protocols that decentralized to a community-governed DAO have experienced this pain directly. In order to govern multi-chain protocol deployments, DAOs have largely tried three strategies, each with pros and cons:

  1. Patching together existing solutions by chain — this strategy conforms governance proposals to the interface of the "canonical" bridge where each satellite deployment lives. For example, a Polygon deployment and Arbitrum deployment would each require a bespoke implementation and process to manage proposals over the respective bridges, as each was developed independently

    • Pros: leverages existing "canonical" bridges

    • Cons: more overhead and complexity to implement, no standardization

    • Pros: no external dependencies, standardized locally

    • Cons: major lift for an protocol/app core team to maintain, not standardized across protocols/apps

  2. Not worrying about decentralization — the last strategy is to simply not worry about decentralized cross-chain governance, and to use a multi-sig for governance of satellite deployments. In this approach, a protocol/app can avoid token governance entirely, or simply elect multi-sig key holders who are expected to mirror the flagship deployment's governance processes.

    • Pros: simple and straightforward

    • Cons: totally centralized and defeats the purpose of token-based governance

The fact is, none of these solutions satisfies the core need — trust-minimized, standardized, and simple to implement/maintain bridge for cross-chain governance.

A better solution: Zodiac + Nomad

If you are a contributor to a DAO or protocol/app that is considering cross-chain governance, please reach out to us via email (gm@nomad.xyz) to learn more about cross-chain governance and how Nomad can support your use case!

Rolling your own solution — some DAOs like Aave have , in an effort to standardize governance across their deployments. This requires building everything from scratch and managing the contracts and infrastructure to pass governance messages to each deployment.

We built (ZNM) because we believe cross-chain governance matters, and Nomad's protocol is uniquely designed (optimistic and security-first) to meet this use case better than any other interoperability solution out there. It's through understanding this problem that we teamed up with Gnosis to develop it (originally nicknamed "Gnomad" 😁).

The Zodiac Nomad Module provides an out-of-the-box solution for cross-chain governance that is simple, trust-minimized, and standardized. DAOs can leverage the ZNM anywhere Nomad are deployed to ensure executed governance proposals can be passed to all of their deployments.

To learn more about the ZNM, .

developed their own governance bridges
the Zodiac Nomad Module
messaging channels
check out the docs here
Zodiac Nomad Module
Governor Bravo design