Maker Protocol Technical Docs
  • MakerDAO Technical Docs
  • Getting Started
    • Maker Protocol 101
  • Smart Contract Modules
    • Dai Module
      • Dai - Detailed Documentation
    • Core Module
      • Vat - Detailed Documentation
      • Spot - Detailed Documentation
    • Collateral Module
      • Join - Detailed Documentation
    • Liquidation 2.0 Module
    • System Stabilizer Module
      • Flapper - Detailed Documentation
      • Flopper - Detailed Documentation
      • Vow - Detailed Documentation
    • Oracle Module
      • Oracle Security Module (OSM) - Detailed Documentation
      • Median - Detailed Documentation
    • MKR Module
    • Governance Module
      • Spell - Detailed Documentation
      • Pause - Detailed Documentation
      • Chief - Detailed Documentation
    • Rates Module
      • Pot - Detailed Documentation
      • Jug - Detailed Documentation
    • Proxy Module
      • Proxy Actions - Detailed Documentation
      • Vote Proxy - Detailed Documentation
      • CDP Manager - Detailed Documentation
      • DSR Manager - Detailed Documentation
    • Flash Mint Module
    • Maker Protocol Emergency Shutdown
      • Emergency Shutdown for Partners
      • The Emergency Shutdown Process for Multi-Collateral Dai (MCD)
      • End - Detailed Documentation
      • ESM - Detailed Documentation
  • Glossary
    • MCD Glossaries
    • Smart Contract Annotations
  • Deployment Addresses
    • Maker Protocol Deployments
  • Security
    • Security for the Maker Protocol
  • Building on top of the Maker Protocol
    • Developer Guides and Tutorials
    • The Dai Javascript Library of the Maker Protocol
      • Getting started
      • Configuration
        • Plugins
      • Vault manager
      • Collateral types
      • Dai Savings Rate
      • Currency units
      • System data
      • Advanced
        • Transaction manager
        • DSProxy
        • Events
        • Using multiple accounts
        • Adding a new service
      • Single-Collateral Sai
        • Collateralized Debt Position
        • CDP Service
        • Price Service
        • System Status
        • Tokens
        • Token Conversion
        • Exchange Service
    • Pymaker
  • Keepers
    • The Auctions of the Maker Protocol
    • Auction Keepers
      • Auction Keeper Bot Setup Guide
    • Market Maker Keepers
      • Market Maker Keeper Bot Setup Guide
    • Cage Keeper
    • Simple Arbitrage Keeper
    • Chief Keeper
  • Command-line Interfaces
    • Seth
    • Multi Collateral Dai (MCD) CLI
    • Dai and Collateral Redemption during Emergency Shutdown
    • Emergency Shutdown (ES) CLI
  • Miscellaneous
    • Liquidations 1.2 System (Deprecated)
      • Cat - Detailed Documentation
      • Flipper - Detailed Documentation
    • SCD <> MCD Migration
    • Upgrading to Multi-Collateral Dai Guide
Powered by GitBook
On this page
  • 1. Introduction (Summary)
  • 2. Module Details
  • Governance Module Components Documentation
  • 3. Key Mechanism and Concepts
  • 4. Gotchas (Potential sources of user error)
  • 5. Failure Modes (Bounds on Operating Conditions & External Risk Factors)
Export as PDF
  1. Smart Contract Modules

Governance Module

The Maker Protocol's Governance Contracts

PreviousMKR ModuleNextSpell - Detailed Documentation

Last updated 5 years ago

  • Module Name: Governance Module

  • Type/Category: Governance —> Chief.sol, Pause.sol, Spell.sol

  • Contract Sources:

1. Introduction (Summary)

The Governance Module contains the contracts that facilitate MKR voting, proposal execution, and voting security of the Maker Protocol.

2. Module Details

The Governance Module has 3 core components consisting of the Chief, Pause and Spell contracts.

Governance Module Components Documentation

3. Key Mechanism and Concepts

Summary of the Governance Module Components

  • Chief - The Ds-Chief smart contract provides a method to elect a "chief" contract via an approval voting system. This may be combined with another contract, such as DSAuthority, to elect a ruleset for a smart contract system.

  • Pause - The ds-pause is a delegatecall based proxy with an enforced delay. This allows authorized users to schedule function calls that can only be executed once a predetermined waiting period has elapsed. The configurable delay attribute sets the minimum wait time that will be used during the governance of the system.

  • Spell - A DS-Spell is an un-owned object that performs one action or series of atomic actions (multiple transactions) one time only. This can be thought of as a one-off DSProxy with no owner (no DSAuth mixing, it is not a DSThing).

4. Gotchas (Potential sources of user error)

  • Chief

    • In general, when we refer to the "chief", it can be both addresses or people that represent contracts. Thus, ds-chief can work well as a method for selecting code for execution just as well as it can for realizing political processes.

    • IOU Token: The purpose of the IOU token is to allow for the chaining of governance contracts. In other words, this allows you to have a number of DSChief, DSPrism, or other similar contracts use the same governance token by means of accepting the IOU token of the DSChief contract before it is a governance token.

  • Pause

    • Identity & Trust: In order to protect the internal storage of the pause from malicious writes during plan execution, a delegatecall operation is performed in a separate contract with an isolated storage context (DSPauseProxy), where each pause has its own individual proxy. This means that plans are executed with the identity of the proxy. Thus when integrating the pause into some auth scheme, you will want to trust the pause's proxy and not the pause itself.

  • Spell

    • The spell is only marked as "done" if the CALL it makes succeeds, meaning it did not end in an exceptional condition and it did not revert. Conversely, contracts that use return values instead of exceptions to signal errors could be successfully called without having the effect you might desire. "Approving" spells to take action on a system after the spell is deployed generally requires the system to use exception-based error handling to avoid griefing.

5. Failure Modes (Bounds on Operating Conditions & External Risk Factors)

  • Chief

    • MKR users moving their votes from one spell to another: One of the biggest potential failure modes occurs when people are moving their votes from one spell to another. This opens up a gap/period of time when only a small amount of MKR is needed to lift a random hat.

  • Pause

    • There is no way to bypass the delay.

    • The code executed by the delegatecall cannot directly modify storage on the pause.

    • The pause will always retain ownership of it's proxy.

  • Spell

    • The main failure mode of the spell arises when there is an instance of the spell remaining uncast when it has an amount of MKR voting for it that later becomes a target.

Approval Voting: This type of voting is when each voter selects which candidates they approve of, with the top n "most approved" candidates being then elected. Each voter can cast up to n + k votes, where k equals some non-zero positive integer. Read more .

Implementations: If you are writing a front-end UI for this smart contract, please note that the address[] parameters that are passed to the etch and vote functions must be byte-ordered sets. Read more

Read more

Associated MCD System Diagram
Chief
Pause
Spell
Chief - Detailed Documentation
Pause - Detailed Documentation
Spell - Detailed Documentation
here
here.
here.