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
  1. Developers
  2. Core Developers

Upgrade Setup

We will use the UpgradeBeacon pattern to implement three upgradable contract types: Home, Replica, and GovernanceRouter.

Each upgradable contract will have:

  • Proxy

    • the permanent address of the contract that external entities interact with

    • holds the storage of the contract

    • uses the logic specified by Implementation

    • uses delegatecall to forward contract calls from Proxy → UpgradeBeacon → Implementation

  • UpgradeBeacon

    • stores the (mutable) address of the Implementation

    • forwards delegatecalls to the Implementation

    • accepts new Implementation addresses from its Controller (thereby performing upgrades for all Proxies)

  • Implementation

    • specifies the logic of the contract

    • code is the same as a normal, non-upgradable contract implementation (though it should use upgrade-safe storage)

Each of the three UpgradeBeacon contracts will share a the same Controller — the contract with the power to perform upgrades.

The Controller contract will have two roles: controller and saver.

  • controller

    • is a transferrable role that should be performing upgrades in almost every case.

    • will be set to the GovernanceRouter Proxy, so that the Governance xApp ultimately controls the upgrades of the entire system. Note that this creates a circular dependency which makes upgrades of the GovernanceRouter Implementation particularly sensitive.

  • saver

    • is a transferrable(?) role that is responsible for recovering the system in a catastrophic failure case. Actions performed by the saver will be subject to a timelock enforced by the Controller contract.

    • will be set to a multisig contract where the signatories are a set of known / trusted community members. the signatories for the saver multisig be the same on every chain

PreviousCore DevelopersNextDeploying Contracts

Last updated 2 years ago

Diagrams

Upgrade Setup Diagram 1
Upgrade Setup Diagram 2
#