├── images ├── forum-impact-tag.png ├── voting-portal-impact-tag.png ├── governance-tracker-impact-tag.png ├── exec-transaction-verification-1.png ├── exec-transaction-verification-2.png ├── exec-transaction-verification-3.png ├── exec-transaction-verification-4.png ├── exec-transaction-verification-5.png ├── exec-transaction-verification-6.png ├── exec-transaction-verification-7.png └── governance-dashboard-impact-tag.png ├── .gitignore ├── parameter-index ├── collateral-auction │ ├── images │ │ ├── readme.md │ │ └── cut-and-step.png │ ├── param-max-auction-drawdown.md │ ├── param-proportional-kick-incentive.md │ ├── param-flat-kick-incentive.md │ ├── param-max-auction-duration.md │ ├── param-auction-price-function.md │ ├── param-local-liquidation-limit.md │ ├── param-breaker-price-tolerance.md │ └── param-auction-price-multiplier.md ├── vault-risk │ ├── param-rwa-agreement.md │ ├── param-debt-floor.md │ ├── param-debt-ceiling.md │ ├── param-liquidation-penalty.md │ └── param-stability-fee.md ├── surplus-auction │ ├── param-surplus-cooldown.md │ ├── param-surplus-lot-size.md │ └── param-surplus-slippage-tolerance.md ├── debt-auction │ ├── param-bid-size.md │ ├── param-initial-lot-size.md │ ├── param-min-bid-decrease-flop.md │ ├── param-lot-size-increase.md │ ├── param-debt-auction-delay.md │ ├── param-auction-duration-flop.md │ └── param-bid-duration-flop.md ├── archive │ ├── param-min-bid-increase-flap.md │ ├── param-auction-duration-flap.md │ ├── param-surplus-auction-limit.md │ └── param-bid-duration-flap.md └── core │ ├── param-global-debt-ceiling.md │ ├── param-global-liquidation-limit.md │ ├── param-gsm-pause-delay.md │ └── param-system-surplus-buffer.md ├── governance ├── how-to-vote.md ├── easy-governance-frontend.md ├── scope-advisory-councils.md ├── voting-in-makerdao.md ├── off-chain-governance.md ├── practical-guide-voting.md ├── approval-voting-guide.md ├── atlas.md ├── impact-estimations.md ├── scopes-and-artifacts.md ├── weekly-governance-cycle.md ├── executive-transaction-verification.md ├── monthly-governance-cycle.md └── emergency-shutdown.md ├── delegation ├── delegate-metric-tracking.md ├── what-is-delegation.md ├── mkr-holder-how-to-delegate.md ├── alignment-conservers.md ├── aligned-delegates.md ├── avc.md └── delegate-expiration.md ├── protocol-status ├── calls-calendar.md ├── governance-calendar.md └── protocol-and-dao-status.md ├── misc └── discords.md ├── README.md ├── needs-rewrite ├── what-is-delegation.md ├── delegate-metric-tracking.md └── mips.md ├── module-index ├── module-lerp.md ├── module-emergency-shutdown.md ├── module-psm.md ├── module-flash-mint-module.md └── module-token-streaming.md ├── work-in-progress └── hashing.md ├── meta └── writing-guide.md └── SUMMARY.md /images/forum-impact-tag.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sky-ecosystem/governance-manual/HEAD/images/forum-impact-tag.png -------------------------------------------------------------------------------- /images/voting-portal-impact-tag.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sky-ecosystem/governance-manual/HEAD/images/voting-portal-impact-tag.png -------------------------------------------------------------------------------- /images/governance-tracker-impact-tag.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sky-ecosystem/governance-manual/HEAD/images/governance-tracker-impact-tag.png -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | public 2 | .cache 3 | node_modules 4 | *.DS_Store 5 | *DS_Store 6 | *.env 7 | *.swp 8 | yarn-error.log 9 | package-lock.json 10 | -------------------------------------------------------------------------------- /images/exec-transaction-verification-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sky-ecosystem/governance-manual/HEAD/images/exec-transaction-verification-1.png -------------------------------------------------------------------------------- /images/exec-transaction-verification-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sky-ecosystem/governance-manual/HEAD/images/exec-transaction-verification-2.png -------------------------------------------------------------------------------- /images/exec-transaction-verification-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sky-ecosystem/governance-manual/HEAD/images/exec-transaction-verification-3.png -------------------------------------------------------------------------------- /images/exec-transaction-verification-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sky-ecosystem/governance-manual/HEAD/images/exec-transaction-verification-4.png -------------------------------------------------------------------------------- /images/exec-transaction-verification-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sky-ecosystem/governance-manual/HEAD/images/exec-transaction-verification-5.png -------------------------------------------------------------------------------- /images/exec-transaction-verification-6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sky-ecosystem/governance-manual/HEAD/images/exec-transaction-verification-6.png -------------------------------------------------------------------------------- /images/exec-transaction-verification-7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sky-ecosystem/governance-manual/HEAD/images/exec-transaction-verification-7.png -------------------------------------------------------------------------------- /images/governance-dashboard-impact-tag.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sky-ecosystem/governance-manual/HEAD/images/governance-dashboard-impact-tag.png -------------------------------------------------------------------------------- /parameter-index/collateral-auction/images/readme.md: -------------------------------------------------------------------------------- 1 | Put images related to Collateral Auctions in this folder 2 | 3 | >Page last reviewed: - 4 | >Next review due: - 5 | 6 | -------------------------------------------------------------------------------- /parameter-index/collateral-auction/images/cut-and-step.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/sky-ecosystem/governance-manual/HEAD/parameter-index/collateral-auction/images/cut-and-step.png -------------------------------------------------------------------------------- /governance/how-to-vote.md: -------------------------------------------------------------------------------- 1 | # Video Guide To Voting In The Maker Protocol 2 | 3 | The following video is a guide to voting in the Maker Protocol: 4 | 5 | {% embed url="https://vimeo.com/649207489" %} 6 | 7 | 8 | >Page last reviewed: 2022-11-21 9 | >Next review due: 2023-11-21 10 | -------------------------------------------------------------------------------- /delegation/delegate-metric-tracking.md: -------------------------------------------------------------------------------- 1 | # Delegate Metric Tracking 2 | 3 | {% hint style="info" %} 4 | Sorry! We haven't been able to publish documentation on this topic yet. Please check back soon. 5 | {% endhint %} 6 | 7 | >Page last reviewed: 2023-08-26 8 | >Next review due: 2023-10-26 9 | 10 | -------------------------------------------------------------------------------- /delegation/what-is-delegation.md: -------------------------------------------------------------------------------- 1 | # What is Delegation? 2 | 3 | {% hint style="info" %} 4 | Sorry! We haven't been able to publish documentation on this topic yet. Please check back soon. 5 | {% endhint %} 6 | 7 | 8 | >Page last reviewed: 2023-08-26 9 | >Next review due: 2023-10-26 10 | 11 | -------------------------------------------------------------------------------- /governance/easy-governance-frontend.md: -------------------------------------------------------------------------------- 1 | # Easy Governance Frontend 2 | 3 | {% hint style="info" %} 4 | Sorry! We haven't been able to publish documentation on this topic yet. Please check back soon. 5 | {% endhint %} 6 | 7 | 8 | >Page last reviewed: 2023-08-26 9 | >Next review due: 2023-10-26 10 | 11 | -------------------------------------------------------------------------------- /governance/scope-advisory-councils.md: -------------------------------------------------------------------------------- 1 | # Scope Advisory Councils 2 | 3 | {% hint style="info" %} 4 | Sorry! We haven't been able to publish documentation on this topic yet. Please check back soon. 5 | {% endhint %} 6 | 7 | 8 | >Page last reviewed: 2023-08-26 9 | >Next review due: 2023-10-26 10 | 11 | -------------------------------------------------------------------------------- /delegation/mkr-holder-how-to-delegate.md: -------------------------------------------------------------------------------- 1 | # Video Guide To Delegating MKR 2 | 3 | The following video outlines how to delegate MKR to a delegate in the Maker Protocol: 4 | 5 | {% embed url="https://www.youtube.com/embed/_BX5VvAvzUs" %} 6 | 7 | >Page last reviewed: 2022-09-29 8 | >Next review due: 2023-09-29 9 | 10 | -------------------------------------------------------------------------------- /protocol-status/calls-calendar.md: -------------------------------------------------------------------------------- 1 | # MakerDAO Calls Calendar 2 | 3 | The following is an embed of the Official MakerDAO Calls Calendar which is maintained by the GovAlpha Core Unit. Please note all times are in Coordinated Universal Time (UTC). You may add events to your own personal Google Calendar using the button in the bottom-right. 4 | 5 | {% embed url="https://calendar.google.com/calendar/embed?src=makerdao.com_3efhm2ghipksegl009ktniomdk%40group.calendar.google.com&ctz=UTC&hl=en" %} 6 | -------------------------------------------------------------------------------- /protocol-status/governance-calendar.md: -------------------------------------------------------------------------------- 1 | # MakerDAO Governance Calendar 2 | 3 | The following is an embed of the Official MakerDAO Governance Calendar which is maintained by the GovAlpha Core Unit. Please note all times are in Coordinated Universal Time (UTC). You may add events to your own personal Google Calendar using the button in the bottom-right. 4 | 5 | {% embed url="https://calendar.google.com/calendar/embed?src=bdf4un05hpg0611lg3ieue4t3c%40group.calendar.google.com&ctz=UTC&hl=en" %} 6 | -------------------------------------------------------------------------------- /misc/discords.md: -------------------------------------------------------------------------------- 1 | # Maker-Related Discord Servers 2 | 3 | **Official** 4 | * [MakerDAO](https://discord.gg/RBRumCpEDH) 5 | 6 | **Core Units/Ecosystem Actors** 7 | * [Dewiz](https://discord.gg/uvXJqP5fnJ) 8 | * [Growth](https://discord.gg/e4gGVU5CJY) 9 | * [Jetstream](https://discord.gg/g2N9MmhCEY) 10 | * [Oracles (Chronicle)](https://discord.gg/D8qQTEHQHJ) 11 | * [Sustainable Ecosystem Scaling/Powerhouse](https://discord.gg/hMrfhqEFb2) 12 | * [TechOps](https://discord.gg/9tCTbRC4) 13 | 14 | **Ecosystem** 15 | * [Oasis.app](https://discord.gg/oasisapp) 16 | * [Defisaver](https://discord.com/invite/XGDJHhZ) 17 | 18 | **Endgame** 19 | * [Endgame](https://discord.gg/2YwznMCxEd) 20 | 21 | >Page last reviewed: 2022-12-02 22 | >Next review due: 2023-12-02 23 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | --- 2 | description: >- 3 | This set of documents intends to acquaint MKR Holders with the voting process and to serve as reference material for them to consult during the day-to-day operation of the protocol. 4 | --- 5 | 6 | # Maker Operational Manual 7 | 8 | ## More MakerDAO Documentation 9 | * [Governance](https://manual.makerdao.com/) @ manual.makerdao.com **<-- You are here** 10 | * [Technical](https://docs.makerdao.com/) @ docs.makerdao.com 11 | * [Collateral Onboarding](https://collateral.makerdao.com/) @ collateral.makerdao.com 12 | * [MIPs Portal](https://mips.makerdao.com/) @ mips.makerdao.com 13 | * [Endgame](https://endgame.makerdao.com/) @ endgame.makerdao.com 14 | 15 | >Page last reviewed: 2023-02-27 16 | >Next review due: 2023-08-27 17 | 18 | -------------------------------------------------------------------------------- /governance/voting-in-makerdao.md: -------------------------------------------------------------------------------- 1 | # Introduction to voting in MakerDAO 2 | MakerDAO is a decentralized autonomous organization whose governance process controls various aspects of the Maker Protocol. On-chain voting requires MKR tokens. MKR holders have the sole authority to enact changes to the system through voting. 3 | 4 | Voting is calculated by a weighted voting system, where voting power is proportional to the amount of MKR tokens cast. For example, if 50 stakeholders hold a total of 600 MKR and vote for proposal A, while 100 stakeholders hold a total of 400 MKR and vote for proposal B, then Proposal A would win with 60% of the vote. The number of stakeholders who voted for a proposal does not change the result. 5 | 6 | Off-chain voting takes place on the [Maker Forum](https://forum.makerdao.com) and on-chain voting takes place on the [Governance Portal](https://vote.makerdao.com/). 7 | 8 | >Page last reviewed: 2022-09-29 9 | >Next review due: 2023-09-29 10 | -------------------------------------------------------------------------------- /governance/off-chain-governance.md: -------------------------------------------------------------------------------- 1 | # Off-Chain Governance 2 | 3 | {% hint style="info" %} 4 | Since subDAOs can arbitrarily set up their own forms of internal off-chain governance, this article will restrict itself to the off-chain governance of Maker Core. 5 | {% endhint %} 6 | 7 | Off-chain governance is a form of governance that does not involve tokens or blockchain interaction. It allows more people to participate in improving the protocol by freely exchanging ideas and gathering feedback. This can be used to support and inform future on-chain governance. 8 | 9 | Off-chain governance can be conducted in: 10 | 11 | - The [MakerDAO forum](forum.makerdao.com/), usually under the [Ecosystem Discussion category](https://forum.makerdao.com/c/ecosystem-discussions/89). The forum also allows for creation of polls to gauge community sentiment. 12 | - The [MakerDAO Discord server](https://discord.gg/RBRumCpEDH). 13 | 14 | When engaging in off-chain governance, it is important to prioritize courtesy and common sense. MakerDAO encourages respectful and inclusive discussions, and constructive feedback. 15 | 16 | 17 | >Page last reviewed: 2023-05-23 18 | >Next review due: 2023-07-23 19 | -------------------------------------------------------------------------------- /needs-rewrite/what-is-delegation.md: -------------------------------------------------------------------------------- 1 | # What is Delegation? 2 | 3 | Delegation is a mechanism through which MKR Holders can entrust their voting power to one or more chosen delegates. These delegates can then vote using the MKR delegated to them. Delegates have no ability to access the MKR delegated to them directly. 4 | 5 | MKR Holders are always able to vote on proposals directly if they do not wish to delegate their MKR tokens. 6 | 7 | MakerDAO has two varieties of delegates. 8 | 9 | ## Recognized Delegates 10 | Recognized Delegates are whitelisted by the Governance Facilitators of MakerDAO. They must meet requirements for consistent participation in votes, and communication with the community. 11 | 12 | In exchange for meeting these requirements, Recognized Delegates are compensated in DAI and are featured more prominently on voting frontends. 13 | 14 | Recognized Delegates act as a bridge between vote outcomes and other actors by actively and transparently communicating with the MakerDAO community. 15 | 16 | ## Shadow Delegates 17 | Shadow Delegates are permissionless, with no requirements or responsibilities beyond those they have agreed on directly with holders who delegate to them. 18 | 19 | >Page last reviewed: 2022-10-26 20 | >Next review due: 2023-10-26 21 | 22 | -------------------------------------------------------------------------------- /governance/practical-guide-voting.md: -------------------------------------------------------------------------------- 1 | # Practical guide to on-chain voting 2 | This section explains how users can vote using their MKR. 3 | 4 | ### Voting in On-Chain Polls 5 | 6 | Voting in On-Chain Polls can be done using MKR in the voters wallet, or MKR the voter has deposited in the Maker Protocol Governance Contract. 7 | 8 | ### Voting in Executive Proposals 9 | 10 | Voting on an Executive Proposal can only be done by a user that has deposited MKR in the Maker Protocol Governance Contract. 11 | 12 | ### Costs of voting 13 | Voting takes place on Ethereum mainnet, and the transaction fees will depend on the congestion of the Ethereum blockchain. On-Chain Poll votes can be batched and submitted in a single transaction. 14 | 15 | ### Delegation 16 | MKR holders may also delegate their MKR and allow the delegate to vote on their behalf. More information on delegation can be found [here](../delegation/what-is-delegation.md). 17 | 18 | 19 | _Historic note: Previously, the voting portal offered linked wallet voting which allowed users to separate voting power from ownership power of the MKR tokens deposited. This structure is no longer supported for new users. However, the voting portal still supports functionality for users with existing linked wallet contracts._ 20 | 21 | >Page last reviewed: 2022-10-31 22 | >Next review due: 2023-10-31 23 | 24 | -------------------------------------------------------------------------------- /parameter-index/vault-risk/param-rwa-agreement.md: -------------------------------------------------------------------------------- 1 | # RWA Agreement 2 | 3 | >**Alias:** Asset Document Hash 4 | >**Parameter Name:** `doc` 5 | >**Containing Contract:** `MIP21_LIQUIDATION_ORACLE` 6 | >**Scope:** MIP21/Ilk (RWA) 7 | >**Technical Docs:** [MIP21](https://mips.makerdao.com/mips/details/MIP21) 8 | 9 | ## Description 10 | 11 | Real-World Asset (RWA) Vaults are dependent on a contractual arrangement, the RWA Agreement. The RWA Agreement parameter allows the Maker Protocol to record an [IPFS](https://ipfs.tech) hash that links to the actual contract documentation. Each deal will have individual contract documentation, and the documentation format may change from deal to deal. 12 | 13 | ## Purpose 14 | By recording the contents of the RWA Agreement to the blockchain, a clear and transparent record of legal agreements made by the RWA Core Unit is available. This transparency benefits governance and will be useful in the event of any disputes with borrowers. 15 | 16 | This parameter is only used in RWA vaults using the MIP21-defined vault structure. 17 | 18 | ## Changes 19 | Modifying the RWA Agreement can be done through a manual process that requires an executive vote. Changes to the RWA Agreement are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 20 | 21 | Maker Governance should make changes to the parameter to reflect changes in the underlying contractual documentation. 22 | 23 | Maker Governance should not change the parameter unless there has been a change in the underlying contractual documentation. 24 | 25 | ## Considerations 26 | As MakerDAO is not a legal entity, the actual use of the contractual documentation may be limited. 27 | 28 | >Page last reviewed: 2022-11-08 29 | >Next review due: 2023-11-08 30 | 31 | -------------------------------------------------------------------------------- /governance/approval-voting-guide.md: -------------------------------------------------------------------------------- 1 | # Approval Voting Guide for MakerDAO 2 | 3 | Approval Voting is a form of voting used to identify a consensus option among a group of voters. Voters may already be familiar with Approval Voting from Signal Requests on the Maker Forum. Voters can select multiple options they agree with without needing to rank them, which enables polls to determine a consensus winner. 4 | 5 | The DUX Core Unit has recently added functionality for Approval Voting to the [voting portal](https://vote.makerdao.com/), allowing the use of Approval Voting for on-chain voting at MakerDAO. 6 | 7 | Our Approval Voting implementation can be configured to require the winner to receive majority support, or to declare the option with the most support the winner, regardless of whether or not it received a majority. 8 | 9 | When voting on an Approval Vote, voters should select **all** options with which they agree. There is no penalty for choosing multiple options. However, it is legitimate to only vote for one option if there is only one option that the voter wishes to support. 10 | 11 | Voters cannot vote for "Abstain" and other options. If a voter wishes to Abstain, that should be the voter's only selection - the UI will enforce this. 12 | 13 | We have the option to stop people from voting for the "Reject" option in combination with other poll options. However, the use case for this is limited, and if this restriction is in place, GovAlpha will indicate it in the poll text. 14 | 15 | If you have questions about Approval Voting and its use at MakerDAO, please get in touch with GovAlpha. 16 | 17 | For further information on Approval Voting, see the [Wikipedia article](https://en.wikipedia.org/wiki/Approval_voting). 18 | 19 | >Page last reviewed: 2022-10-10 20 | >Next review due: 2023-10-10 21 | 22 | -------------------------------------------------------------------------------- /delegation/alignment-conservers.md: -------------------------------------------------------------------------------- 1 | # Alignment Conservers 2 | 3 | {% hint style="warning" %} 4 | This documentation describes functionality and processes that MakerDAO is in the process of implementing. Be aware that parts may be inaccurate or out of date. 5 | {% endhint %} 6 | 7 | An Alignment Conserver (AC) is a guardian of the [Maker Atlas](../governance/atlas.md). They must preserve the Atlas and oppose any entities threatening it. 8 | 9 | ## Types 10 | 11 | There are two types of Alignment Conservers: [AVC](avc.md) Members and [Aligned Delegates](aligned-delegates.md). 12 | 13 | The Arbitration Scope gives recognition to each type of Alignment Conserver if they meet the requirements. Ecosystem Actors that become recognized as a type of Alignment Conserver may not assume any other ecosystem role, including that of a different type of Constitutional Conserver. 14 | 15 | ## Purpose 16 | 17 | The Maker Atlas is designed to safeguard the interests of MKR holders. By preserving and protecting the Atlas from changes, Alignment Conservers function as guardians of MKR holders' interests. 18 | 19 | Alignment Conservers may never change the Atlas or governance dynamics unless they do it within the Atlas processes and frameworks. During Pregame, AVC Members are allowed and encouraged to help refine the Maker Atlas. 20 | 21 | ## Eligibility Requirements 22 | To be eligible, Alignment Conservers must make a public pledge committing to: 23 | - Preserve the Atlas 24 | - Oppose and publicly expose all forms of corruption, organizational drifts, and other threats to the Atlas 25 | 26 | Alignment Conservers must be anonymous. During Pregame, anonymity is encouraged but not required. 27 | 28 | An Alignment Conserver can be **derecognized** if it acts against the pledge or against any of the requirements attached to their type. 29 | 30 | If the breach is *mild*, the Alignment Conserver receives a warning, which is recorded by the Arbitration Scope Framework. There are no further consequences for *first-time* breaches. 31 | 32 | If the breach is *severe*, the Alignment Conserver is derecognized and no longer receives the privileges attached to the Alignment Conserver role. 33 | 34 | >Page last reviewed: 2023-08-03 35 | >Next review due: 2023-11-03 -------------------------------------------------------------------------------- /module-index/module-lerp.md: -------------------------------------------------------------------------------- 1 | # Linear Interpolation 2 | 3 | 4 | >**Alias:** `lerp` 5 | >**Contract Name:** `dss-lerp` 6 | >**Scope:** One instance for each parameter 7 | >**Technical docs:** [link](https://github.com/makerdao/dss-lerp) 8 | 9 | ## Description 10 | 11 | The Linear Interpolation Module (`lerp`) allows a governance parameter to be changed linearly over a fixed period of time. 12 | 13 | ## Purpose 14 | 15 | The primary purpose of the `lerp` module is to enable Governance to change a parameter gradually using only a single executive vote. The duration over which the parameter is changed, the starting value, and final value of the parameter can be chosen for each instance of the lerp module. 16 | 17 | ## Execution 18 | The `lerp` contract has one method called tick(), which is permissionless and can be called by anyone. This updates the target parameter to be whatever value it should be at that moment. If the elapsed time is longer than the duration, calling tick() will finish the `lerp` by changing `done` to true and set the parameter to the end value. 19 | 20 | 21 | ## Key Parameters 22 | 23 | Each `lerp` factory invocation creates a new contract which has the following properties: 24 | 25 | ### target 26 | The target contract in which a parameter is being changed. 27 | 28 | ### what 29 | The name of the parameter being changed. 30 | 31 | ### startTime 32 | The starting time of this lerp instance. 33 | 34 | ### start 35 | The starting value of that parameter. 36 | 37 | ### end 38 | The ending value of that parameter. 39 | 40 | ### duration 41 | The duration over which this lerp instance will run for. 42 | 43 | ### done 44 | This refers to whether the given `lerp` instance is finished or not. 45 | 46 | 47 | 48 | ## Trade-offs 49 | 50 | Typically, the start and end parameters are adjusted to represent the current state and the desired state for the protocol. Hence, a longer `duration` results in the parameter being suboptimal for a longer period of time. On the other hand, more gradual changes are desirable as the protocols users can adapt more easily. 51 | 52 | 53 | ## Considerations 54 | 55 | When `lerp` is used to determine allocation of protocol earnings, such as setting the System Surplus Buffer, Governance should ensure that the desired rate of increase is not larger than the expected protocol earnings. If the desired rate is too high, the `lerp` has no effect. 56 | 57 | >Page last reviewed: 2022-09-18 58 | >Next review due: 2023-09-18 59 | 60 | -------------------------------------------------------------------------------- /governance/atlas.md: -------------------------------------------------------------------------------- 1 | # Atlas Immutable Alignment Artifact 2 | 3 | {% hint style="warning" %} This documentation describes planned functionality and processes that MakerDAO has not yet implemented. Be aware that parts may be inaccurate or out of date. {% endhint %} 4 | 5 | The [Atlas Immutable Alignment Artifact (Atlas)](https://mips.makerdao.com/mips/details/MIP101) is the foundational set of rules that govern MakerDAO. It provides a high-level description of the DAO, its actors, incentives, and work areas. Together with the [Scope Bounded Mutable Alignment Artifacts (Scope Artifacts)](scopes-and-artifacts.md), the Atlas defines the operational framework of the DAO. 6 | 7 | The Atlas is currently unfinished but active. Once the Endgame State is reached, the Atlas will become immutable. 8 | 9 | ## Structure 10 | 11 | The Atlas comprises seven broad thematic sections further broken down into articles and subarticles: 12 | 13 | - [0: Definitions](https://mips.makerdao.com/mips/details/MIP101#0-definitions) 14 | - [1: The Atlas](https://mips.makerdao.com/mips/details/MIP101#1-the-atlas) 15 | - [2: The Governance Scope](https://mips.makerdao.com/mips/details/MIP101#2-the-governance-scope-gov), further defined in [MIP113: Governance Scope Bounded Mutable Alignment Artifact](https://mips.makerdao.com/mips/details/MIP113) 16 | - [3: The Support Scope](https://mips.makerdao.com/mips/details/MIP101#3-the-support-scope), further defined in [MIP106: Support Scope Bounded Mutable Alignment Artifact](https://mips.makerdao.com/mips/details/MIP106) 17 | - [4: The Protocol Scope](https://mips.makerdao.com/mips/details/MIP101#4-the-protocol-scope), further defined in [MIP107: Protocol Scope Bounded Mutable Alignment Artifact](https://mips.makerdao.com/mips/details/MIP107) 18 | - [5: The Stability Scope](https://mips.makerdao.com/mips/details/MIP101#6-constitutional-delegates-cds-), further defined in [MIP104: Stability Scope Bounded Mutable Alignment Artifact](https://mips.makerdao.com/mips/details/MIP104) 19 | - [6: The Accessibility Scope](https://mips.makerdao.com/mips/details/MIP101#6-the-accessibility-scope), further defined in [MIP106: Support Scope Bounded Mutable Alignment Artifact](https://mips.makerdao.com/mips/details/MIP106) 20 | 21 | ## Interactions 22 | 23 | The Atlas represents the ultimate authority for governing the DAO and overrules all other Alignment Artifacts. It contains strict principles for the interpretation of its contents. All actors within the MakerDAO ecosystem must adhere to the contents of the Atlas. 24 | 25 | Each Scope Artifact must adhere to the Scope Boundaries defined in the Atlas. 26 | 27 | >Page last reviewed: 2023-08-04 28 | >Next review due: 2023-11-04 -------------------------------------------------------------------------------- /needs-rewrite/delegate-metric-tracking.md: -------------------------------------------------------------------------------- 1 | # Delegate Metric Tracking 2 | 3 | The GovAlpha Core Unit (GOV-001) tracks metrics relating to the voting activities of Recognized Delegates. These are useful to both current and prospective delegators in gauging how active and consistent Recognized Delegates have been. Calculations are made over a 120-day rolling window and the metrics currently tracked for Recognized Delegates centre on participation in on-chain voting and communication by Recognized Delegates regarding their voting choices. 4 | 5 | These metrics can be seen on the delegate cards on the [voting portal](https://vote.makerdao.com/delegates). In addition, a further breakdown of each Recognized Delegate's participation metric is available on their [metric pages](https://vote.makerdao.com/delegates) on the voting portal - here is an example of what a metric page looks like. 6 | 7 | ![Delegate Metrics (2)](https://user-images.githubusercontent.com/90220256/199079179-3d04ae92-8be4-4328-aea9-3af1361b6423.png) 8 | 9 | ## Participation Metric 10 | 11 | For Participation, a score of 100% would mean that a Delegate has voted in all possible polls over the shorter of 1) the previous 120 days, or 2) since becoming a Recognized Delegate. GovAlpha tracks Participation in Governance Polls and Executive Polls separately, then combines them to form an overall participation rating. 12 | 13 | Note that if Recognized Delegates choose not to support an Executive Vote and communicate this clearly, this will be counted as participating in the relevant Executive Vote. This is because there is no option to vote "No" to an Executive Vote. 14 | 15 | ## Communication Metrics 16 | 17 | For Communication, GovAlpha tracks how Recognized Delegates have communicated their votes. Recognized Delegates are rewarded with a higher score for providing the reasoning behind their voting decisions. 18 | 19 | For example, a score of 100% would mean a Recognized Delegate communicated all of their voting decisions AND gave reasons for reaching these decisions over the shorter of 1) the previous 120 days, or 2) since becoming a Recognized Delegate. On the other hand, a score of 50% would indicate a Delegate communicated their decisions but did not provide any reasoning for these decisions. Their scores for each vote are combined to give an overall communication rating. 20 | 21 | ## Spreadsheet 22 | 23 | GovAlpha maintains a publicly accessible spreadsheet that tracks Recognized Delegate metrics. This can be seen [here](https://docs.google.com/spreadsheets/d/1E-VBZFN_N7cj60-wMze2yR1fBDWVs_QoPn-aS5Y-1pM/edit#gid=1415939965). 24 | 25 | >Page last reviewed: 2022-10-26 26 | >Next review due: 2023-10-26 27 | 28 | -------------------------------------------------------------------------------- /governance/impact-estimations.md: -------------------------------------------------------------------------------- 1 | # Impact Estimations 2 | 3 | 4 | The Governance Facilitators apply impact estimations to active governance items (e.g. Scope amendments and risk parameter changes). The goal of these estimations is to provide Alignment Conservers and the wider community with an idea of how important it is that they pay attention to a given governance item given limited time. 5 | 6 | Impact estimations currently have a single dimension, giving the Governance Facilitator's estimate on the magnitude of the impact a given governance item could have on the Maker Protocol and MakerDAO. A `low`, `medium`, or `high` impact score is assigned to active governance items. 7 | 8 | ## Guidelines 9 | 10 | The following guidelines are used when creating estimations. 11 | 12 | **Likely High Impact** 13 | * Anything that adds or removes concretely identifiable risk to the Maker Protocol are likely to be marked as `high` impact. 14 | * Anything the DAO is doing for the first time is likely to be marked as `high` impact. 15 | * Anything that adds or removes a non-trivial amount of DAI from the surplus buffer are likely to be marked as `high` impact. 16 | * Core Unit onboarding and offboarding are likely to be marked as `high` impact. 17 | * Anything that permanently changes governance processes or structures within MakerDAO are likely to be marked as `high` impact. 18 | 19 | **Likely Medium Impact** 20 | * Items that may lead to later decisions that add or remove risk and/or add or remove a non-trivial amount of DAI from the surplus buffer are likely to be marked as `medium` impact. 21 | * Anything that adds or removes a trivial amount of money from the surplus buffer are likely to be marked as `medium` impact. 22 | 23 | **Likely Low Impact** 24 | * Minor wording changes and/or fixes to existing MIPs are likely to be marked as `low` impact. 25 | 26 | If there is any doubt about a given estimation, it is generally rounded up. 27 | 28 | 29 | ## Usage 30 | 31 | [Governance tracker spreadsheet](https://docs.google.com/spreadsheets/d/1LWNlv6hr8oXebk8rvXZBPRVDjN-3OrzI0IgLwBVk0vM/edit#gid=0) 32 | ![](../images/governance-tracker-impact-tag.png) 33 | 34 | [Forum](https://forum.makerdao.com/) posts for RFC MIPs and Signal Requests 35 | ![](../images/forum-impact-tag.png) 36 | 37 | [Voting portal](https://vote.makerdao.com) 38 | ![](../images/voting-portal-impact-tag.png) 39 | 40 | [Governance Dashboard](https://governance-metrics-dashboard.vercel.app/tracker) 41 | ![](../images/governance-dashboard-impact-tag.png) 42 | 43 | ## Disclaimer 44 | 45 | These estimates should be used as a guide and not as a source of truth. Community members remain responsible for any actions they take on the basis of these estimates. 46 | 47 | >Page last reviewed: 2023-02-27 48 | >Next review due: 2023-08-27 -------------------------------------------------------------------------------- /parameter-index/collateral-auction/param-max-auction-drawdown.md: -------------------------------------------------------------------------------- 1 | # Max Auction Drawdown 2 | 3 | >**Alias:** Maximum Auction Drawdown 4 | >**Parameter Name:** `cusp` 5 | >**Containing Contract:** `MCD_CLIP_$ILK` 6 | >**Scope:** Vault Type (Ilk) 7 | >**Technical Docs:** [Liquidations 2.0](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Max Auction Drawdown is the maximum percentage drop in collateral price during a collateral auction before the auction is reset. 'Collateral price' in this context refers to the collateral _auction price_ rather than the collateral _market price._ Collateral auctions use a falling price auction, where the price starts high and decreases according to the [Auction Price Function](param-auction-price-function.md) until it has dropped by the Max Auction Drawdown percentage parameter. 12 | 13 | If a collateral auction starts at a collateral price of $100, and the Max Auction Drawdown is set to 70%, the auction will be reset if the auction collateral price reaches $30. 14 | 15 | The Max Auction Drawdown parameter overlaps with the [Max Auction Duration](param-max-auction-duration.md) parameter in that an auction will need to be reset once either maximum is exceeded. 16 | 17 | ## Purpose 18 | 19 | This parameter primarily exists to prevent collateral auctions from continuing past the point of sanity and auctioning off collateral at far below market price in the event of an unforeseen issue that prevents bids. It is redundant with the Max Auction Duration parameter and allows Maker Governance to decide whether to set the lowest price directly or implicitly via the Auction Price Function and Max Auction Duration parameters. 20 | 21 | ## Trade-offs 22 | 23 | Setting this parameter too low may result in collateral auctions selling collateral for below market price in the event of unforeseen disruptions that prevent bids. 24 | 25 | On the other hand, setting this parameter too high may delay successful auction resolution due to the auction being reset too frequently. Frequent resets also result in the protocol paying out additional kick incentives (both [proportional](param-proportional-kick-incentive.md) and [flat](param-flat-kick-incentive.md)). 26 | 27 | ## Changes 28 | 29 | Adjusting a Max Auction Drawdown parameter for a specific vault type is a manual process that requires an executive vote. Changes to Max Auction Drawdown parameters are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 30 | 31 | ## Considerations 32 | 33 | Max Auction Drawdown is based on the starting auction price (`top`), which is equal to the OSM price multiplied by the [Auction Price Multiplier (`buf`)](../param-auction-price-multiplier.md). 34 | 35 | Auction resets can only take place when either the Max Auction Drawdown parameter or the Max Auction Duration parameter are exceeded. 36 | 37 | >Page last reviewed: 2022-11-07 38 | >Next review due: 2023-11-07 39 | 40 | -------------------------------------------------------------------------------- /governance/scopes-and-artifacts.md: -------------------------------------------------------------------------------- 1 | # Scopes and Scope Artifacts 2 | 3 | {% hint style="warning" %} This documentation describes ongoing changes in functionality and processes. Be aware that parts may be inaccurate or out of date. {% endhint %} 4 | 5 | ## Overview 6 | 7 | A Scope is a broad area of focus for products, protocol-related work, and/or governance in MakerDAO. All work done within the Maker Ecosystem must fall under one of the five Scopes. 8 | 9 | Every Scope has a Scope Bounded Mutable Aligment Artifact, also referred to as Scope Artifact. These are frameworks that contain the rules for all work, governance, and other processes that take place under that Scope. Scope Artifacts can be amended through [MIP102c2 subproposals](https://mips.makerdao.com/mips/details/MIP102#MIP102c2). 10 | 11 | ## Modification of Scope Artifact 12 | 13 | Scope Artifacts are modifiable within the constraints of Scope Boundaries that are immutably defined in the Maker Atlas. 14 | Scope Artifacts include *strengthening elements*, which ossify over time, and *mutable elements*, which are elements related to governance, budget elements, and template elements that may require regular updates. 15 | 16 | Scope Artifacts must include a ruleset for the ossification of mutable elements. Any **significant** change to the Scopes should take long and should allow enough time for feedback. 17 | 18 | Any change made to a Scope Artifact must aim to improve one or more of the following desirable features of the Maker Ecosystem. 19 | - Decentralization 20 | - Autonomous operation 21 | - Future-proofing 22 | - Resilience 23 | - Clarity of instructions 24 | - Simplicity of protocol 25 | 26 | ## Governance 27 | 28 | Each Scope has a [Scope Advisory Council](scope-advisory-councils.md). Councils carry out advisory work related to improving the content of the Scope Artifacts. Councils consist of members who must fulfill certain requirements and have been approved by Maker Governance. 29 | 30 | ## List of Scopes 31 | 32 | The Maker Protocol has five Scopes. They are: 33 | 34 | 1. **Governance (GOV):** Codifies rules that regulate the critical balance of power processes defined in the Maker Atlas, and adjudicate on appeals processes related to misalignment in the ecosystem. 35 | 2. **Support (SUP):** Codifies rules that regulate various tasks of ecosystem support, including governance process infrastructure and management, SubDAO ecosystem support, Public Good Purpose System. 36 | 3. **Protocol (PRO):** Codifies rules related to the core technical MakerDAO protocol. 37 | 4. **Stability (STA)** Codifies the rules related to managing the core stablecoin product, Dai, and supporting factors related to financial stability, such as surplus buffer and decentralized asset reserve. 38 | 5. **Accessibility (ACC):** Codifies rules related to accessibility and distribution efforts, and regulates user-facing frontends of MakerDAO Core and SubDAOs. 39 | 40 | 41 | >Page last reviewed: 2023-08-03 42 | >Next review due: 2023-11-03 43 | -------------------------------------------------------------------------------- /parameter-index/surplus-auction/param-surplus-cooldown.md: -------------------------------------------------------------------------------- 1 | # Smart Burn Engine Cooldown 2 | 3 | >**Alias:** N/A 4 | >**Parameter Name:** `hop` 5 | >**Containing contract:** `MCD_FLAP` 6 | >**Scope:** System 7 | >**Technical Docs:** N/A 8 | 9 | ## Description 10 | The Smart Burn Engine Cooldown or `hop` parameter controls the amount of time that must elapse between activations of the Smart Burn Engine. It is defined in seconds. 11 | 12 | The Smart Burn Engine can be triggered when: 13 | 14 | _Time elapsed since last activation >= Smart Burn Engine Cooldown_ 15 | 16 | {% hint style="info" %} 17 | 18 | **Example** 19 | 20 | _Time Since Last Activation_ = 90 seconds 21 | _Smart Burn Engine Cooldown_ = 100 seconds 22 | 23 | 1. Keeper A attempts to trigger the Smart Burn Engine, but the transaction fails. 24 | 2. 10 seconds pass. 25 | 3. Keeper A may now succesfully trigger the Smart Burn Engine 26 | 27 | {% endhint %} 28 | 29 | ## Purpose 30 | 31 | The Smart Burn Engine Cooldown parameter allows Maker Governance to tune the frequency of Smart Burn Engine actions in order to achieve better efficiency. 32 | 33 | ## Trade-offs 34 | 35 | Increasing the Smart Burn Engine Cooldown will decrease the frequency of Smart Burn Engine purchases. This can allow for lower gas expenditure but will usually need higher lot sizes. 36 | 37 | Reducing the Smart Burn Engine Cooldown will increase the frequency of Smart Burn Engine purchases. This can be useful in low liquidity situations when paired with a smaller lot size. If this is being done by the Keeper Network, this will lead to increased gas costs for Maker as the gas costs of the Keeper Network are funded by the Protocol. 38 | 39 | ## Changes 40 | Adjusting the Smart Burn Engine Cooldown parameter is a manual process that requires an executive vote. Changes to the Smart Burn Engine Slippage Tolerance are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 41 | 42 | In general the goal when tweaking this parameter is to partner changes to the Smart Burn Engine Lot Size to balance the frequency and size of Smart Burn Engine purchases to hit the target purchase rate defined in the [Stability Scope](https://mips.makerdao.com/mips/details/MIP104#9-surplus-buffer-and-smart-burn-engine). 43 | 44 | **Why increase this parameter?** 45 | 46 | The main reason for Maker Governance to increase the Smart Burn Engine Cooldown is to balance increases in the Smart Burn Engine Lot Size, leading to bigger purchases happening less frequently. 47 | 48 | **Why decrease this parameter?** 49 | 50 | The main reason for Maker Governance to decrease the Smart Burn Engine Cooldown is to balance reductions in the Smart Burn Engine Lot Size, leading to smaller purchases happening more frequently. 51 | 52 | ## Considerations 53 | 54 | As triggering the Smart Burn Engine is permissionless, incorrectly setting the Smart Burn Engine Cooldown may lead to more or less Dai being spent to purchase MKR, depending on whether the Smart Burn Engine Cooldown was set too high or too low. 55 | 56 | >Page last reviewed: 2023-08-07 57 | >Next review due: 2024-08-07 -------------------------------------------------------------------------------- /parameter-index/debt-auction/param-bid-size.md: -------------------------------------------------------------------------------- 1 | # Debt Auction Bid Size 2 | 3 | >**Alias:** N/A 4 | >**Parameter Name:** `sump` 5 | >**Containing Contract:** `MCD_VOW` 6 | >**Scope:** System 7 | >**Technical Docs:** [Vow Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/system-stabilizer-module/vow-detailed-documentation) 8 | 9 | ## Description 10 | Debt auctions are used to recapitalize the system by minting and auctioning off MKR for a fixed amount of Dai. In this process, keepers bid on how little MKR they are willing to accept for the fixed Dai amount they have to pay at auction settlement. For any debt auction, the fixed amount of Dai to be covered is determined by the Debt Auction Bid Size parameter (`sump`). 11 | 12 | 13 | ## Purpose 14 | Changing the Debt Auction Bid Size parameter allows Maker Governance to minimize the total MKR minted while ensuring that the protocol does not remain in an undercollateralized state for too long. 15 | 16 | 17 | ## Trade-offs 18 | A small Debt Auction Bid Size would result in an auction being triggered more quickly when the protocol is undercollateralized. If the protocol is quickly recollateralized, this may improve user confidence in Dai. A small Debt Auction Bid Size also means that gas costs for the auction would decrease the profit that keepers receive. In the event of a large system debt, this could also result in many parallel auctions, and keepers may not be able to participate in all of them. Both of these could result in uncompetitive auctions with more MKR minted than necessary. 19 | 20 | A large Debt Auction Bid Size keeps the protocol undercollateralized for longer. Furthermore, keepers may find it harder to organize sufficient capital to participate in the debt auction if this parameter is too large. This lack of competition could result in more MKR minted. In the extreme case, too large a Debt Auction Bid Size would prevent debt auctions from taking place. However, when this parameter is large, the gas costs paid by the keepers to participate in the auction are small relative to their profit. In the case of large system debt, there would also be fewer auctions running in parallel and, therefore, a higher participation rate among keepers. Both of these could result in more competitive bids and decrease the amount of MKR minted. 21 | 22 | 23 | ## Changes 24 | Adjusting the Debt Auction Bid Size parameter is a manual process that requires an executive vote. Changes to the Debt Auction Bid Size are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 25 | 26 | **Why increase this parameter?** 27 | Maker Governance may wish to increase the Debt Auction Bid Size if gas costs for keepers are too high or if the number of debt auctions that may occur in parallel is too large. 28 | 29 | **Why decrease this parameter?** 30 | Maker Governance may wish to decrease the Debt Auction Bid Size if there is insufficient keeper participation or to keep the protocol undercollateralized for a shorter duration. 31 | 32 | >Page last reviewed: 2022-11-14 33 | >Next review due: 2023-11-14 34 | 35 | 36 | 37 | 38 | 39 | 40 | -------------------------------------------------------------------------------- /parameter-index/debt-auction/param-initial-lot-size.md: -------------------------------------------------------------------------------- 1 | # Debt Auction Initial Lot Size 2 | 3 | >**Alias:** N/A 4 | >**Parameter Name:** `dump` 5 | >**Containing Contract:** `MCD_VOW` 6 | >**Scope:** System 7 | >**Technical Docs:** [Vow Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/system-stabilizer-module/vow-detailed-documentation) 8 | 9 | 10 | ## Description 11 | 12 | Debt Auctions are used to recapitalize the system by minting and auctioning off MKR for a fixed amount of Dai. In this process, keepers bid on how little MKR they are willing to accept for the fixed Dai amount they have to pay at auction settlement. The starting amount of MKR in these auctions is determined by the Debt Auction Initial Lot Size parameter. 13 | 14 | A lower amount of MKR than the initial lot size may be bid by auction participants. If there are no bids by the time the auction reaches its end, the Debt Auction Initial Lot Size will be increased when the auction is restarted. This increase is determined by the [Debt Auction Lot Size Increase](param-lot-size-increase.md) parameter (`pad`). 15 | 16 | 17 | ## Purpose 18 | 19 | Changing the Debt Auction Initial Lot Size parameter allows Maker Governance to minimize the total MKR minted by ensuring competitive auctions and minimizing gas costs for auction participants. 20 | 21 | 22 | ## Trade-offs 23 | 24 | A small Debt Auction Initial Lot Size would result in auctions having to be restarted ("`kick`ed") many times before they become interesting to keepers. This would result in the protocol remaining undercollateralized for a long period and also result in additional gas costs due to multiple restarts. 25 | 26 | A large Debt Auction Initial Lot Size could result in large amounts of MKR minted if there are insufficient participants in the auctions. If there are sufficient participants, however, a sufficiently large Debt Auction Initial Lot Size would ensure that auctions do not need to be restarted multiple times. This saves gas costs for keepers and keeps the protocol in an undercollateralized state for a shorter duration. 27 | 28 | 29 | ## Changes 30 | 31 | Adjusting the Debt Auction Initial Lot Size parameter is a manual process that requires an executive vote. Changes to the Debt Auction Initial Lot Size are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 32 | 33 | **Why increase this parameter?** 34 | Maker Governance may wish to increase the Debt Auction Initial Lot Size if debt auctions have to be repeatedly restarted before keepers are able to submit profitable bids. 35 | 36 | **Why decrease this parameter?** 37 | Maker Governance may wish to decrease the Debt Auction Initial Lot Size if there is a risk of insufficient keeper participation, resulting in a risk of high amounts of MKR being minted. 38 | 39 | ## Considerations 40 | 41 | This parameter should be tuned in conjunction with the [Debt Auction Lot Size Increase](param-lot-size-increase.md) parameter (`pad`), which has similar consequences when increased or decreased as the Debt Auction Initial Lot Size parameter. 42 | 43 | >Page last reviewed: 2022-11-16 44 | >Next review due: 2023-11-16 45 | 46 | 47 | 48 | -------------------------------------------------------------------------------- /protocol-status/protocol-and-dao-status.md: -------------------------------------------------------------------------------- 1 | # Protocol and DAO Status 2 | 3 | ### [MakerBurn](https://makerburn.com/) 4 | 5 | Displays a plethora of information about the Maker Protocol and MakerDAO, including burn rate, revenues, expenses and more. 6 | 7 | ### [Maker @ BlockAnalitica](https://maker.blockanalitica.com/) 8 | 9 | Risk stats and insight into the Maker Protocol. Especially useful when prices are dropping and you want to check out liquidations. 10 | 11 | ### [DAI Stats](https://daistats.com/) 12 | 13 | Shows an overview of the current state of the Maker Protocol. Including total DAI minted against each collateral type, current Stability Fee and DSR settings, and the current system surplus / debt. 14 | 15 | ### [Governance Tracking Sheet](https://docs.google.com/spreadsheets/d/1LWNlv6hr8oXebk8rvXZBPRVDjN-3OrzI0IgLwBVk0vM/edit#gid=0) 16 | 17 | Regularly updated governance status dashboard for MakerDAO. Find out what's being voted, discussed or is pending further action. 18 | 19 | ### [Governance Dashboard](https://www.makerdao-governance-dashboard.com/) 20 | 21 | Unified dashboard containing useful stats and charts about governance and delegation, an improved UI for GovAlpha's governance tracker and a delegates section to keep track of delegates comments regarding on-chain polls and executive votes. 22 | 23 | ### [Strategic Finance Directory](https://dune.com/stratfi/maker-stratfi-directory) 24 | 25 | Directory for the Dune dashboards created and maintained by Steakhouse Financial. 26 | 27 | ### [Delegates @ vote.makerdao.com](https://vote.makerdao.com/delegates?network=mainnet) 28 | 29 | Provides a list of all MakerDAO delegates. Includes profiles, contact information and voting history as appropriate. 30 | 31 | ### [MCD Voting Tracker](https://tracker-gov.makerdao.network/) 32 | 33 | Keeps track of current and historical votes and shows analytics. Useful to find out the outcome of a particular proposal or poll, find out how many and which addresses voted in it, and the distribution of MKR over time. It also includes a section for Protocol Parameters where you can find the historical changes in the protocol. 34 | 35 | ### [MCD Vaults Tracker](https://tracker-vaults.makerdao.network/) 36 | 37 | Keeps track of current and historical vaults and shows analytics. Useful to find out the status of an ilk or specific vault, including the actions done related to it. 38 | 39 | ### [Unified Auctions](https://auctions.makerdao.network/) 40 | 41 | Unified landing page for all auction types (Collateral, Debt and Surplus Auctions). Allows participation in Collateral Auctions using Flash Loans. Improves security, transparency and accessibility of the Maker Protocol by providing and maintaining auction services through open-source development. 42 | 43 | ### [DAI Auctions](https://daiauctions.com/#) 44 | 45 | Shows current auction parameters and the status of auctions that have triggered within the last few days. Useful to show how liquidations are going, and give a rough idea of keeper participation. Especially useful in emergency situations in which a large amount of DAI debt has been liquidated. 46 | 47 | ### [Data API](https://data-api.makerdao.network/redoc) 48 | 49 | A RESTful API that covers multiple domains including vaults, liquidations, governance votes and protocol parameters. 50 | 51 | >Page last reviewed: 2022-10-12 52 | >Next review due: 2023-04-12 53 | 54 | -------------------------------------------------------------------------------- /delegation/aligned-delegates.md: -------------------------------------------------------------------------------- 1 | # Aligned Delegates 2 | 3 | {% hint style="warning" %} 4 | This documentation describes functionality and processes that MakerDAO is in the process of implementing. Be aware that parts may be inaccurate or out of date. 5 | {% endhint %} 6 | 7 | Aligned Delegates (ADs) are anonymous [Alignment Conservers (AC)](alignment-conservers.md) who operate as delegates. They use [Protocol Delegation Modules (PDMs)](https://mips.makerdao.com/mips/details/MIP101#2-6-1-protocol-delegation-modules-pdms-) to enable MKR holders to delegate their MKR voting power to them. ADs vote with the delegated MKR to implement the Aligned Governance Strategy of the [Aligned Voter Committees (AVCs)](avc.md) they are affiliated with. 8 | 9 | 10 | ## Overview 11 | 12 | ADs must aim to support AVCs by: 13 | - Providing governance information and research material 14 | - Helping with the design and improvement of Scope Improvement Articles 15 | - Researching relevant happenings in the Maker ecosystem 16 | - Writing elements for Aligned Scope Proposals to capture intent of the AVCs and the Scope Advisory Councils 17 | - Provide feedback on AVC governance strategy documents 18 | 19 | 20 | ADs do not take part in the creation of AVC strategies, they only execute them. This helps to mitigate the risk of a delegate's misalignment in relation to MKR holders. 21 | 22 | ADs must not engage with other ecosystem actors or in operational activities. They are not allowed to compensate MKR holders that delegate to them. 23 | 24 | ## Becoming an AD 25 | 26 | Anyone can use the PDMs to set up an account to become a delegate. A PDM can be upgraded into an Aligned Delegate PDM by activating Governance Strategy Links (GSLs). Each GSL establishes a link between an AVC and an AD. Once linked by a GSL, the AD is required to vote according to the Aligned Governance Strategy of the AVC, unless doing so would result in misaligned actions. 27 | 28 | ADs must be linked to at least two AVCs through GSLs. ADs are displayed prominently in the EGF as followers of a AVC's Strategy, as long as they have two GSLs. 29 | 30 | ## Compensation 31 | 32 | A number of top ADs in terms of delegated MKR are eligible for receiving compensation from the Maker Protocol. These eligible ADs fall into two categories based on MKR delegated: 33 | 34 | - Prime Constitutional Delegates (PCDs) 35 | - Reserve Constitutional Delegates (RCDs) 36 | 37 | PCDs receive a larger fraction of the total compensation than RCDs. 38 | 39 | In addition to having a high amount of delegated MKR, there are further requirements that ADs must fulfill in order to be compensated, namely: 40 | 41 | 1. Participating regularly in CVC Subcommittee Meetings 42 | 2. Maintaining active links to two AVCs 43 | 3. Voting actively on Governance Polls and Executive Votes 44 | 4. Communicating their reasoning behind their votes to the community 45 | 46 | While the third and fourth requirements, when not fully met, may result in reduced compensations, the first and second requirements are hard — i.e., failure to meet them results in no compensation. 47 | 48 | --- 49 | 50 | More details on compensation and eligibility can be found in [Article 2.6.3 in the Maker Atlas](https://mips.makerdao.com/mips/details/MIP101#2-6-3-aligned-delegate-income-and-participation-requirements). 51 | 52 | >Page last reviewed: 2023-08-03 53 | >Next review due: 2023-11-03 -------------------------------------------------------------------------------- /parameter-index/archive/param-min-bid-increase-flap.md: -------------------------------------------------------------------------------- 1 | # Surplus Auction Minimum Bid Increase 2 | 3 | >**Alias:** N/A 4 | >**Parameter Name:** `beg` 5 | >**Containing Contract:** `MCD_FLAP` 6 | >**Scope:** System 7 | >**Technical Docs:** [Flapper Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/system-stabilizer-module/flap-detailed-documentation) 8 | 9 | 10 | ## Description 11 | During surplus auctions, excess DAI within the system is auctioned off in fixed lots for MKR. In this process, keepers bid increasing amounts of MKR for a fixed amount of DAI. MKR received this way is burned by the Maker Protocol. 12 | 13 | New MKR bids must be higher than the current MKR bid by at least an amount determined by the Surplus Auction Minimum Bid Increase or `beg`. The Surplus Auction Minimum Bid Increase is given in terms of a minimum percentage increase on the current bid. 14 | 15 | In practice the Surplus Auction Minimum Bid Increase represents both: 16 | * The maximum profit that keepers can make when bidding in Surplus Auctions. 17 | * The maximum slippage MakerDAO is willing to accept during auctions to ensure sufficient keeper participation. 18 | 19 | {% hint style="info" %} 20 | 21 | **Example** 22 | 23 | _Surplus Auction Minimum Bid Increase_ = 5% 24 | _Surplus Auction Lot Size_ = 1,000 DAI 25 | 26 | 1. A DAI Surplus Auction is triggered, accepting bids of MKR in exchange for 1,000 DAI. 27 | 2. Keeper A bids to pay 10 MKR in exchange for 1,000 DAI. 28 | 3. Keeper B must bid at least 10.5 MKR in exchange for the 1,000 DAI, a 5% increase. 29 | 30 | {% endhint %} 31 | 32 | ## Purpose 33 | The Surplus Auction Minimum Bid Increase parameter allows Maker Governance to ensure that keepers are sufficiently incentivized to bid in surplus auctions. 34 | 35 | ## Trade-offs 36 | A small Surplus Auction Minimum Bid Increase helps to increase the amount of MKR burned as bids will be closer to the market value of MKR. However, if it is too small, it can result in low keeper participation due to lack of perceived profit. If only a single keeper participates in an auction it can lead to significant losses for the Maker Protocol. 37 | 38 | A large Surplus Auction Minimum Bid Increase ensures high keeper participation as there is an opportunity for a larger profit. It also helps to balance other costs to the keeper when making a bid, such as the effect of the price volatility of MKR over the duration of the auction, and the cost of gas when making a bid. 39 | 40 | ## Changes 41 | Adjusting the Surplus Auction Minimum Bid Increase parameter is a manual process that requires an executive vote. Changes to the Surplus Auction Minimum Bid Increase are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 42 | 43 | **Why increase this parameter?** 44 | 45 | This parameter should be increased to increase keeper participation in surplus auctions. 46 | 47 | **Why decrease this parameter?** 48 | 49 | This parameter should be decreased to increase auction efficiency i.e. winning bid price vs. market price of MKR. 50 | 51 | ## Considerations 52 | The gas cost to `kick` (trigger) a surplus auction is non-trivial. If the Surplus Auction Minimum Bid Increase is too small, surplus auctions may not be triggered by any keeper because they are required to accept a fixed cost for an uncertain return. 53 | 54 | >Page last reviewed: 2022-11-09 55 | >Next review due: 2023-11-09 56 | 57 | -------------------------------------------------------------------------------- /governance/weekly-governance-cycle.md: -------------------------------------------------------------------------------- 1 | # The Weekly Governance Cycle 2 | 3 | The Weekly Governance Cycle is formalized by [MIP16](https://mips.makerdao.com/mips/details/MIP16) and provides a predictable weekly framework for Maker Governance decisions. 4 | 5 | The Weekly Governance Cycle works in conjunction with the Monthly Governance Cycle ([MIP51](https://mips.makerdao.com/mips/details/MIP51)). It permits recurring decisions to be made that require quicker action than is allowed by the Monthly Governance Cycle. 6 | 7 | ### Weekly Governance Cycle Overview 8 | 9 | ![weekly_monthly-gov](https://github.com/makerdao/mips/blob/master/MIP16/weekly_governance_cycle.png?raw=true) 10 | 11 | ### Weekly Governance Cycle Definitions ([MIP16c1](https://mips.makerdao.com/mips/details/MIP16#MIP16c1)) 12 | 13 | - A **Weekly Poll** is a non-binding Governance Poll that determines the weekly Executive Vote contents. Weekly Polls cannot change system parameters independently; they merely dictate what will be included in the next Executive Vote. 14 | - A **Non-Standard Weekly Poll** is a non-binding Weekly Poll that contains arbitrary time-sensitive decisions. These polls need to be expedited through the Maker governance process via a separate vote. The use of Non-Standard Weekly Polls is exclusive to Facilitators, given that they have already established a high level of trust with the community. The use of Non-Standard Weekly Polls is limited to situations where the Weekly Governance Cycle is determined to operate too slowly to be usable. An example of such a poll might be the Risk Core Unit ([RISK-001](https://mips.makerdao.com/mips/details/MIP39c2SP2)) Facilitator proposing urgent parameter changes for a collateral type due to an abrupt change in market conditions, or a vulnerability that has been detected. 15 | - Ratified Facilitators (a list can be found [here](https://mips.makerdao.com/mips/details/MIP38#MIP38c2)) are authorized by Maker Governance to interact with the Weekly Cycle. Facilitators may submit Non-Standard Weekly Polls that are related to their Core Unit Mandate. If necessary, and if it is related to their Core Unit Mandate, Facilitators can skip the Non-Standard Weekly Polls and include logic directly into the weekly Executive Vote. 16 | 17 | --- 18 | 19 | ### Weekly Governance Cycle Breakdown ([MIP16c2](https://mips.makerdao.com/mips/details/MIP16#MIP16c2)) 20 | 21 | **Monday, week 1** 22 | 23 | - Every Monday, the weekly cycle begins and includes standard recurring decisions proposed in the form of a weekly poll. The poll will run for three days. 24 | 25 | **Friday, week 1** 26 | 27 | - The Arbitration or Ecosystem Facilitators will confirm the Executive Vote contents and deliver the spell copy to the Governance Security Advisory Council. The Governance Security Advisory Council will prepare and review a spell on the Goerli testnet. 28 | 29 | **Monday, week 2** 30 | 31 | - The Governance Security Advisory Council will deploy the Goerli spell and begin writing the mainnet spell. 32 | 33 | **Tuesday, week 2** 34 | 35 | - The Governance Security Advisory Council will deploy the mainnet spell. 36 | 37 | **Wednesday, week 2** 38 | 39 | - The Arbitration or Ecosystem Facilitators will add the Executive Vote to the voting portal and communicate this to the MakerDAO Community. The Weekly Executive Vote has an expiration of thirty days. 40 | 41 | >Page last reviewed: 2023-07-13 42 | >Next review due: 2024-07-13 43 | -------------------------------------------------------------------------------- /parameter-index/core/param-global-debt-ceiling.md: -------------------------------------------------------------------------------- 1 | # Global Debt Ceiling 2 | 3 | >**Alias:** Global Debt Ceiling 4 | >**Parameter Name:** `Line` 5 | >**Containing contract:** `MCD_VAT` 6 | >**Scope:** System 7 | >**Technical Docs:** [Vat Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/core-module/vat-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Global Debt Ceiling, or `Line`, parameter allows Maker Governance to set a maximum total amount of DAI that can be minted by users of the Maker Protocol. If a user tries to mint DAI and the amount of new DAI minted would put the total amount of DAI minted above the Global Debt Ceiling, the transaction will fail and no DAI will be minted. 12 | 13 | Additionally, vault types have a [Debt Ceiling](../vault-risk/param-debt-ceiling.md) (`ilk.line`) parameter that is not covered in this entry. For a user to mint DAI from their vault, there must be space available in both the vault type's Debt Ceiling and the Global Debt Ceiling. 14 | 15 | ## Purpose 16 | 17 | The purpose of the Global Debt Ceiling is to act as an upper bound on the amount of DAI in circulation. If a failure elsewhere in the Maker Protocol results in unbacked DAI being minted, the Global Debt Ceiling will cap the loss in value. 18 | 19 | ## Trade-offs 20 | 21 | If the Global Debt Ceiling is set too low, it will prevent DAI from being minted. This is a bad experience for vault users, and may also cause the DAI peg to break upward if DAI demand increases but DAI supply cannot increase. 22 | 23 | If the Global Debt Ceiling is set too high, then the Maker Protocol will have increased losses in the event of a bug or exploit that mints unbacked DAI. 24 | 25 | ## Changes 26 | 27 | Adjusting the Global Debt Ceiling parameter can be done through a manual process that requires an executive vote. Changes to the Global Debt Ceiling are subject to the [GSM Pause Delay](param-gsm-pause-delay.md). 28 | 29 | Generally speaking, the Global Debt Ceiling does not need to be manually managed by Maker Governance. The Protocol Engineering Core Unit includes changes to the parameter in executive proposals such that it approximately equals the sum of the debt ceilings of each vault type. 30 | 31 | The Global Debt Ceiling is also automatically adjusted to account for debt ceiling changes that occur via the [Debt Ceiling Instant Access Module](../../module-index/module-dciam.md). The Debt Ceiling Instant Access Module allows the Debt Ceiling of a given Vault type to be adjusted instantly according to certain hard-coded rules and parameters. When this occurs, the Global Debt Ceiling will change by the same amount. 32 | 33 | ## Considerations 34 | 35 | The Global Debt Ceiling will not prevent DAI from accruing in the [System Surplus Buffer](param-system-surplus-buffer.md) from stability fees. Therefore, the overall DAI supply can still increase despite the Global Debt Ceiling being reached. 36 | 37 | Maker Governance should exercise caution when reducing the debt ceiling of collateral types; this may lead to an unintended situation where the Global Debt Ceiling is below the overall DAI supply, thus preventing further DAI from being minted. 38 | 39 | If [Emergency Shutdown](https://docs.makerdao.com/smart-contract-modules/shutdown) is triggered, DAI cannot be minted regardless of the Global Debt Ceiling. 40 | 41 | >Page last reviewed: 2022-11-02 42 | >Next review due: 2023-11-02 43 | 44 | -------------------------------------------------------------------------------- /parameter-index/surplus-auction/param-surplus-lot-size.md: -------------------------------------------------------------------------------- 1 | # Smart Burn Engine Lot Size 2 | 3 | >**Alias:** N/A 4 | >**Parameter Name:** `bump` 5 | >**Containing contract:** `MCD_VOW` 6 | >**Scope:** System 7 | >**Technical Docs:** [Vow Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/system-stabilizer-module/vow-detailed-documentation) 8 | 9 | ## Description 10 | The Smart Burn Engine Lot Size or `bump` parameter controls the amount of DAI that is exchanged for MKR each time the Smart Burn Engine is triggered. 11 | 12 | The Smart Burn Engine can be triggered when: 13 | 14 | _Surplus DAI > [Maximum System Surplus](../core/param-system-surplus-buffer.md) (`hump`) + Smart Burn Engine Lot Size (`bump`)_ 15 | 16 | {% hint style="info" %} 17 | 18 | **Example** 19 | 20 | _Maximum System Surplus_ = 50 million DAI 21 | _Smart Burn Engine Lot Size_ = 10,000 DAI 22 | 23 | 1. The current System Surplus reaches 50 million DAI. 24 | 2. Keeper A attempts to trigger the Smart Burn Engine, but the transaction fails. 25 | 3. The current System Surplus reaches 50,010,000 DAI. 26 | 4. Keeper A successfully triggers the Smart Burn Engine and exchanges 10,000 DAI for MKR. 27 | 28 | {% endhint %} 29 | 30 | ## Purpose 31 | 32 | The Smart Burn Engine Lot Size parameter allows Maker Governance to tune the frequency and accessibility of Smart Burn Engine actions in order to achieve better efficiency. 33 | 34 | ## Trade-offs 35 | 36 | Increasing the Smart Burn Engine Lot Size will result in fewer auctions - leading to less overall gas expenditure. However, a larger Smart Burn Engine Lot Size may mean there is insufficient liquidity for the Smart Burn Engine to complete its planned actions. 37 | 38 | Reducing the Smart Burn Engine Lot Size will result in a greater number of auctions. These events will occur more frequently. However, a higher number of events leads to a higher fixed cost as the protocol funds the Keeper Network that will reliably call these events. 39 | 40 | ## Changes 41 | Adjusting the Smart Burn Engine Lot Size parameter is a manual process that requires an executive vote. Changes to the Smart Burn Engine Lot Size are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 42 | 43 | In general the goal when tweaking this parameter is to trade-off costs of running keepers against the liquidity available in the pool and the risk of sandwich attacks. 44 | 45 | **Why increase this parameter?** 46 | 47 | The main reason for Maker Governance to increase the Smart Burn Engine Lot Size is to reduce the overall number of actions. Fewer auctions reduces the gas cost for keepers as there are fewer transactions taking place. Since Maker funds the Keeper Network, this saves the protocol money in the long-term as there is less gas to subsidise. 48 | 49 | **Why decrease this parameter?** 50 | 51 | The main reason for Maker Governance to decrease the Smart Burn Engine Lot Size is if there is to reduce the required liquidity for each action. If the parameter is set too high, the slippage will be too high and the auction will not proceed. 52 | 53 | ## Considerations 54 | 55 | The Smart Burn Engine Lot Size must be greater than 0 DAI. 56 | 57 | As triggering the Smart Burn Engine is permissionless, incorrectly setting the Smart Burn Engine Lot Size may expose the Protocol to sandwich attacks. 58 | 59 | >Page last reviewed: 2023-08-01 60 | >Next review due: 2024-08-01 61 | 62 | -------------------------------------------------------------------------------- /parameter-index/vault-risk/param-debt-floor.md: -------------------------------------------------------------------------------- 1 | # Debt Floor 2 | 3 | >**Alias:** Dust, Minimum Debt 4 | >**Parameter Name:** `dust` 5 | >**Containing Contract:** `MCD_VAT` 6 | >**Scope:** Vault Type (Ilk) 7 | >**Technical Docs:** [Vat Detailed Documenation](https://docs.makerdao.com/smart-contract-modules/core-module/vat-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Debt Floor parameter controls the minimum amount of DAI that can be minted using a specific vault type for an individual vault. If a user tries to mint DAI and the amount of DAI minted would not put the vault's amount of DAI minted above its Debt Floor, the transaction will fail and no DAI will be minted. Likewise, if a user attempts to pay back debt such that their debt will equal less than the Debt Floor and greater than zero, the transaction will fail and no DAI will be paid back. 12 | 13 | Each vault type has its own Debt Floor that can be adjusted by Maker Governance. Note that the Debt Floor applies to each individual vault, rather than to vaults in aggregate. This differs from the Debt Ceiling. 14 | 15 | ## Purpose 16 | 17 | The primary purpose of the Debt Floor is to prevent users from creating multiple vaults with very low debt amount and collateral. Keepers may be reluctant to liquidate smaller vaults because the reward is low in comparison to the gas costs of liquidation and bidding in the subsequent auction. This is a problem because the Maker Protocol relies on prompt liquidations to prevent the accrual of bad debt. 18 | 19 | ## Trade-offs 20 | 21 | Increasing the Debt Floor limits the minimum size of vaults such that Keepers can profitably liquidate vaults where the collateralization ratio has dropped beneath the liquidation ratio. 22 | 23 | However, increasing the Debt Floor harms vault usage. Setting the Debt Floor too high can exclude users with less capital from using Maker Vaults completely. 24 | 25 | Additionally, the higher the Debt Floor is set, the harder it becomes to test the vault functionality of the Maker Protocol without risking significant capital. 26 | 27 | ## Changes 28 | 29 | Adjusting the Debt Floor parameter for a specific vault type is a manual process that requires an executive vote. Changes to Debt Floor parameters are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 30 | 31 | **Why increase this parameter?** Maker Governance may wish to increase this parameter if gas prices on the Ethereum network have been at sustained high rates. This indicates that Keepers may have trouble liquidating small vaults because the cost of gas will exceed the relative reward of bidding on collateral in the case of smaller vaults. 32 | 33 | **Why decrease this parameter?** Maker Governance may wish to decrease this parameter if they wish to make Maker Vaults more attractive to use for those with a smaller amount of capital. 34 | 35 | Alternatively, if gas prices on the Ethereum network have dropped to consistently lower rates, it may be possible to lower the Debt Floor parameter for a vault type without negatively impacting liquidations. 36 | 37 | ## Considerations 38 | 39 | Vaults with a debt amount lower than the current Debt Floor will not be able to draw or payback additional DAI unless it puts their total debt over the Debt Floor, or drops it to zero. However, they will not be forcibly liquidated or suffer any immediate negative consequences. 40 | 41 | >Page last reviewed: 2022-11-08 42 | >Next review due: 2023-11-08 43 | 44 | -------------------------------------------------------------------------------- /delegation/avc.md: -------------------------------------------------------------------------------- 1 | # Aligned Voter Committees (AVC) 2 | 3 | {% hint style="warning" %} This documentation describes ongoing changes in functionality and processes. Be aware that parts may be inaccurate or out of date. {% endhint %} 4 | 5 | Aligned Voter Committees (AVCs) are organized groups of MKR holders who have a shared strategic vision for the Maker protocol whose members are [Alignment Conservers](alignment-conservers.md). 6 | 7 | AVCs have two main tasks in governance: 8 | 1. To propose modifications to the [Scope Artifacts](../governance/scopes-and-artifacts.md) to strengthen them over time. 9 | 2. To ensure that all [Aligned Delegates (ADs)](aligned-delegates.md) that are affiliated with them, execute the AVC's strategic vision when voting on governance issues. 10 | 11 | ## Overview 12 | 13 | Each AVC produces an Aligned Governance Strategy document and five Aligned Scope Artifact documents with proposed updates to the Scope Artifact of each Scope. The Aligned Governance Strategy document provides general guidelines for how Aligned Delegates that follow their governance strategy should vote. 14 | 15 | The documents produced by the AVCs abstract away the minutiae of day-to-day governance. Since Aligned Delegates execute AVC strategies, they allow MKR Holders to be reasonably informed and secure with regard to the general direction of the chosen delegate. 16 | 17 | According to their own strategy, AVCs fall somewhere in a spectrum that goes from **Hawk** to **Dove**: 18 | - Hawkish AVCs focus more on short-term income and asset accumulation, tending to prefer higher spreads and lower budgets 19 | - Dovish AVCs focus more on long-term growth and innovation, tending to prefer lower spreads and higher budgets 20 | - Balanced AVCs try to find a middle ground between the two 21 | 22 | The Hawk/Dove is a continuous spectrum, so many different hawkish or dovish AVCs can exist that are more or less balanced. 23 | 24 | 25 | ## Eligibility Requirements 26 | 27 | In order for a voter committee to be considered an AVC, its members must be Alignment Conservers (AC) and verified MKR holders. 28 | 29 | To become Active AVCs, AVCs are subject to additional eligibility requirements. For each quarterly governance cycle they must: 30 | - Create one Aligned Governance Strategy document and five Aligned Scope Proposals 31 | - Hold two AVC Subcommittee meetings for each scope 32 | 33 | The [Governance Scope](https://mips.makerdao.com/mips/details/MIP113) recognizes Active AVCs. It can revoke this recognition anytime the AVC fails to meet all eligibility requirements. 34 | 35 | ## Member Participation Rewards 36 | 37 | Member Participation Rewards is a compensation scheme available to AVC members. It considers their participation in each scope. 38 | To be eligible for compensation, AVC members must: 39 | - Attend the two AVC Subcommittee Meetings 40 | - Co-author the Aligned Governance Strategy 41 | 42 | AVC Members who fulfill these eligibility requirements will then be ordered by verified MKR ownership amounts, and those with the highest MKR balances are eligible for compensation. 43 | 44 | 45 | ## Visibility 46 | 47 | The [Easy Governance Frontends (EGFs)](../governance/easy-governance-frontend.md) display AVCs on a list that ranks them by their voter weight. The voter weight is calculated by adding the verified MKR holdings of members plus the MKR delegated to delegates that follow the AVC's Governance Strategy. 48 | 49 | >Page last reviewed: 2023-08-03 50 | >Next review due: 2023-11-03 51 | -------------------------------------------------------------------------------- /parameter-index/debt-auction/param-min-bid-decrease-flop.md: -------------------------------------------------------------------------------- 1 | 2 | # Min Bid Decrease (Flop) 3 | 4 | >**Alias:** Minimum Bid Decrease 5 | >**Parameter Name:** `beg` 6 | >**Containing Contract:** `MCD_FLOP` 7 | >**Scope:** System 8 | >**Technical Docs:** [Flop Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/system-stabilizer-module/flop-detailed-documentation) 9 | 10 | ## Description 11 | 12 | Debt auctions are used to recapitalize the system by minting and auctioning off MKR for a fixed amount of Dai. In this process, keepers bid a reducing amount of MKR they are willing to accept for the fixed amount of DAI they have to pay at auction settlement. 13 | 14 | During debt auctions, new MKR bids must be lower than the current MKR bid by at least an amount determined by the Debt Auction Min Bid Decrease (`beg`). The Debt Auction Min Bid Decrease is given in terms of a minimum percentage decrease on the current bid. 15 | 16 | In practice the Debt Auction Min Bid Decrease represents both: 17 | * The maximum profit that keepers can make when bidding in Debt Auctions. 18 | * The maximum slippage MakerDAO is willing to accept during auctions to ensure sufficient keeper participation. 19 | 20 | {% hint style="info" %} 21 | 22 | **Example** 23 | 24 | _Debt Auction Min Bid Decrease_ = 5% 25 | _Debt Auction Initial Lot Size_ = 100 MKR 26 | _Debt Auction Bid Size_ = 1000 DAI 27 | 28 | 1. An MKR Auction is triggered starting at 100 MKR. 29 | 2. Keeper A bids to receive 100 MKR in exchange for their 1000 DAI. 30 | 3. Keeper B must bid at most 95 MKR in exchange for their 1000 DAI, a 5% decrease. 31 | 32 | {% endhint %} 33 | 34 | ## Purpose 35 | 36 | The Debt Auction Bid Decrease parameter allows Maker Governance to ensure that keepers are sufficiently incentivized to bid in debt auctions. 37 | 38 | ## Trade-offs 39 | 40 | A small Debt Auction Min Bid Decrease helps to reduce the amount of MKR minted in a debt auction as bids will be closer to the market value of MKR. However, if it is too low it can result in low keeper participation due to lack of perceived profit. If only a single keeper participates in an auction it can lead to significant losses for the Maker Protocol, and potentially Dai Holders. 41 | 42 | A large Debt Auction Min Bid Decrease ensures high keeper participation as there is an opportunity for a larger profit. It also helps to balance other costs to the keeper when making a bid, such as the effect of the price volatility of MKR over the duration of the auction, and the cost of gas when making a bid. 43 | 44 | ## Changes 45 | 46 | Adjusting the Debt Auction Min Bid Decrease parameter is a manual process that requires an executive vote. Changes to the Debt Auction Min Bid Decrease are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 47 | 48 | **Why increase this parameter?** 49 | This parameter should be increased to increase keeper participation in Debt Auctions. 50 | 51 | **Why decrease this parameter?** 52 | This parameter should be decreased to increase auction efficiency, i.e., winning bid price vs. market price of MKR. 53 | 54 | ## Considerations 55 | 56 | The gas cost to `kick` (trigger) a debt auction is non-trivial. If the Debt Auction Min Bid Decrease is too low, debt auctions may not be triggered by any keeper because they are required to accept a fixed cost for an uncertain return. 57 | 58 | "Front-running" may be an issue in debt auctions. 59 | 60 | >Page last reviewed: 2022-11-14 61 | >Next review due: 2023-11-14 62 | 63 | 64 | 65 | -------------------------------------------------------------------------------- /parameter-index/collateral-auction/param-proportional-kick-incentive.md: -------------------------------------------------------------------------------- 1 | # Proportional Kick Incentive 2 | 3 | >**Alias:** Proportional Kick Incentive 4 | >**Parameter Name:** `chip` 5 | >**Containing Contracts:** `MCD_CLIP_$ILK` 6 | >**Scope:** Vault Type (Ilk) 7 | >**Technical Docs:** [Liquidations 2.0](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Proportional Kick Incentive parameter represents a reward in DAI paid to the keepers that trigger collateral liquidation auctions in the Maker Protocol. 12 | 13 | The Proportional Kick Incentive is set as a percentage and represents a portion of DAI based on the debt of the vault that is being liquidated. The DAI is rewarded for each liquidation auction at the point the auction is triggered. 14 | 15 | Each vault type has its own Proportional Kick Incentive that may be adjusted separately by Maker Governance. 16 | 17 | ## Purpose 18 | 19 | The Proportional Kick Incentive exists to ensure that auctions are triggered quickly and reliably even in times of high gas fees on the Ethereum blockchain. 20 | 21 | ## Trade-offs 22 | 23 | Having a large Proportional Kick Incentive parameter should cause the liquidation auctions of large vaults to trigger quickly and reliably. However, this incentive directly cuts into the revenue of the Maker Protocol. 24 | 25 | Setting the parameter too low may result in liquidation auctions not being triggered quickly enough to avoid a net loss for the Maker Protocol. 26 | 27 | If this parameter is set higher than the Liquidation Penalty for vaults, it provides an opportunity for attackers to exploit the system by liquidating their own vaults to harvest the DAI incentive. 28 | 29 | ## Changes 30 | 31 | Adjusting a Proportional Kick Incentive parameter is a manual process that requires an executive vote. Changes to a Proportional Kick Incentive are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 32 | 33 | **Why increase this parameter?** 34 | 35 | Increasing a Proportionate Kick Incentive may be desirable when gas prices are high enough to discourage keepers from kicking auctions quickly and reliably. 36 | 37 | Having quick and reliable liquidations decreases the chances of accruing bad debt when the price of a collateral asset is falling. 38 | 39 | **Why decrease this parameter?** 40 | 41 | It is important that this parameter be reasonably lower than the Liquidation Penalty to make auction-related attacks less attractive to malicious actors. 42 | 43 | Governance may want to reduce this parameter if it determines that it is 'overpaying' keepers that trigger liquidations. 44 | 45 | ## Considerations 46 | 47 | The Proportional Kick Incentive parameter should be set such that: `Proportional Kick Incentive < Liquidation Penalty` 48 | 49 | The combination of liquidations incentives should be set such that the following is true: `Flat Kick Incentive + Proportional Kick Incentive < Liquidation Penalty + Liquidation Gas Costs + Vault Creation Gas Costs`. 50 | 51 | If both the Proportional Kick Incentive and the [Flat Kick Incentive](param-flat-kick-incentive.md) are non-zero. A keeper triggering a valid liquidation will receive both. 52 | 53 | Resetting a failed auction will also award the triggering keeper the Proportional Kick Incentive. 54 | 55 | The funds for the Proportional Kick Incentive are removed from the surplus buffer and may trigger MKR minting if there is no DAI available within the surplus buffer. 56 | 57 | >Page last reviewed: 2022-11-16 58 | >Next review due: 2023-11-16 59 | 60 | -------------------------------------------------------------------------------- /parameter-index/debt-auction/param-lot-size-increase.md: -------------------------------------------------------------------------------- 1 | # Debt Auction Lot Size Increase 2 | 3 | >**Alias:** N/A 4 | >**Parameter Name:** `pad` 5 | >**Containing Contract:** `MCD_FLOP` 6 | >**Scope:** System 7 | >**Technical Docs:** [Flop Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/system-stabilizer-module/flop-detailed-documentation) 8 | 9 | ## Description 10 | Debt Auctions are used to recapitalize the system by minting and auctioning off MKR for a fixed amount of DAI. In this process, keepers bid on how little MKR they are willing to accept for the fixed Dai amount they have to pay at auction settlement. The starting amount of MKR in these auctions is determined by the [Debt Auction Initial Lot Size](param-initial-lot-size.md) parameter (`dump`). 11 | 12 | A lower amount of MKR than the initial lot size may be bid by auction participants. If no bids are made before the auction reaches its end, the Debt Auction Initial Lot Size will be increased when the auction is restarted. This increase is determined by the Debt Auction Lot Size Increase parameter. 13 | 14 | {% hint style="info" %} 15 | 16 | **Example** 17 | 18 | _Debt Auction Initial Lot Size_ = 100 MKR 19 | _Debt Auction Lot Size Increase_ = 50% 20 | 21 | 1. An MKR Auction is triggered starting at 100 MKR and fails to receive any bids. 22 | 2. The MKR Auction is restarted at 150 MKR and fails to receive any bids. 23 | 3. The MKR Auction is restarted at 225 MKR, and successfully receives bids. 24 | 25 | {% endhint %} 26 | 27 | ## Purpose 28 | Changing the Debt Auction Lot Size Increase parameter allows Maker Governance to minimize the total MKR minted by ensuring competitive auctions and minimizing gas costs for auction participants. 29 | 30 | 31 | ## Trade-offs 32 | A small Debt Auction Lot Size Increase would result in auctions having to be restarted (`kick`ed) many times before they become interesting to keepers. This would result in the protocol remaining undercollateralized for a long period and also result in additional gas costs due to multiple restarts. 33 | 34 | A large Debt Auction Lot Size Increase could result in large amounts of MKR minted if there are insufficient participants in the auctions. On the other hand, if there are sufficient participants, a sufficiently large Debt Auction Lot Size Increase would ensure that auctions do not need to be restarted multiple times. This saves gas costs for keepers and keeps the protocol in an undercollateralized state for a shorter duration. 35 | 36 | 37 | ## Changes 38 | Adjusting the Debt Auction Lot Size Increase parameter is a manual process that requires an executive vote. Changes to the Debt Auction Lot Size Increase are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 39 | 40 | **Why increase this parameter?** 41 | Maker Governance may wish to increase the Debt Auction Lot Size Increase if debt auctions have to be repeatedly restarted before keepers are able to submit profitable bids. 42 | 43 | **Why decrease this parameter?** 44 | Maker Governance may wish to decrease the Debt Auction Lot Size Increase if there is a risk of insufficient keeper participation resulting in a risk of high amounts of MKR being minted. 45 | 46 | 47 | ## Considerations 48 | This parameter should be tuned in conjunction with the [Debt Auction Initial Lot Size](param-initial-lot-size.md) parameter, which has similar consequences when increased or decreased as the Debt Auction Lot Size Increase parameter. 49 | 50 | >Page last reviewed: 2022-11-14 51 | >Next review due: 2023-11-14 52 | 53 | 54 | 55 | 56 | 57 | -------------------------------------------------------------------------------- /parameter-index/collateral-auction/param-flat-kick-incentive.md: -------------------------------------------------------------------------------- 1 | # Flat Kick Incentive 2 | 3 | >**Alias:** Flat Kick Incentive 4 | >**Parameter Name:** `tip` 5 | >**Containing Contracts:** `MCD_CLIP_$ILK` 6 | >**Scope:** Vault Type (Ilk) 7 | >**Technical Docs:** [Liquidations 2.0](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Flat Kick Incentive parameter represents a reward in DAI paid to the keepers that trigger collateral liquidation auctions in the Maker Protocol. 12 | 13 | The Flat Kick Incentive is a fixed amount of DAI that is rewarded for each liquidation auction at the point the auction is triggered. 14 | 15 | Each vault type has its own Flat Kick Incentive that may be adjusted separately by Maker Governance. 16 | 17 | ## Purpose 18 | 19 | The purpose of this parameter is to offset the gas cost of triggering vault liquidations if gas costs on the Ethereum blockchain increase to the point where liquidations are not being triggered promptly. 20 | 21 | ## Trade-offs 22 | 23 | Increasing the Flat Kick Incentive parameter should cause auctions to be triggered more reliably even for smaller vaults where the amount of collateral up for auction may not be attractive for keepers. In turn, having auctions trigger reliably for smaller vaults may allow governance to maintain a lower Debt Floor. 24 | 25 | However, if this parameter is set higher than the gas cost to both create and liquidate vaults, it provides an opportunity for attackers to exploit the system by liquidating their own vaults to harvest the DAI incentive. 26 | 27 | A further trade-off is that the funds for this parameter are removed from the surplus buffer, meaning that liquidations of very small vaults may cost governance more than it gains through the [Liquidation Penalty](../vault-risk/param-liquidation-penalty.md). 28 | 29 | ## Changes 30 | 31 | Adjusting a Flat Kick Incentive parameter is a manual process that requires an executive vote. Changes to a Flat Kick Incentive are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 32 | 33 | **Why increase this parameter?** 34 | 35 | Governance may consider increasing the Flat Kick Incentive for a vault type if high gas prices are preventing the liquidation of smaller vaults within that vault type. 36 | 37 | **Why decrease this parameter?** 38 | 39 | Governance may consider decreasing the Flat Kick Incentive for a vault type if smaller vaults are being liquidated reliably. 40 | 41 | A decrease to this parameter should be **strongly** considered when in combination with the [Proportional Kick Incentive](param-proportional-kick-incentive.md) and the Liquidation Penalty the farming of liquidation incentives is a viable option for attackers. 42 | 43 | ## Considerations 44 | 45 | The Flat Kick Incentive parameter should be set such that: `Flat Kick Incentive < Liquidation Gas Costs + Vault Creation Gas Costs` 46 | 47 | The combination of liquidations incentives should be set such that the following is true: `Flat Kick Incentive + Proportional Kick Incentive < Liquidation Penalty + Liquidation Gas Costs + Vault Creation Gas Costs`. 48 | 49 | If both the Flat Kick Incentive and the Proportional Kick Incentive are non-zero. A keeper triggering a valid liquidation will receive both. 50 | 51 | Resetting a failed auction will also award the triggering keeper the Flat Kick Incentive. 52 | 53 | The funds for the Flat Kick Incentive are removed from the surplus buffer and may trigger MKR minting if there is no DAI available within the surplus buffer. 54 | 55 | >Page last reviewed: 2022-11-16 56 | >Next review due: 2023-11-16 57 | 58 | -------------------------------------------------------------------------------- /parameter-index/collateral-auction/param-max-auction-duration.md: -------------------------------------------------------------------------------- 1 | # Max Auction Duration 2 | 3 | >**Alias:** Maximum Auction Duration 4 | >**Parameter Name:** `tail` 5 | >**Containing Contracts:** `MCD_CLIP_$ILK` 6 | >**Scope:** Vault Type (Ilk) 7 | >**Technical Docs:** [Liquidations 2.0](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Max Auction Duration parameter sets the maximum time that can elapse before an auction needs to reset for a particular vault type. Expressed in seconds, this parameter determines when an auction can no longer settle and must be reset. 12 | 13 | If the Max Auction Duration is set to 9,000 seconds for a given vault type, then any auction in the liquidations system for that vault type that has been running for more than 2.5 hours will not be able to settle and will need to be reset. 14 | 15 | The Max Auction Duration parameter overlaps with the [Max Auction Drawdown](param-max-auction-drawdown.md) parameter in that an auction will need to be reset once either maximum is exceeded. 16 | 17 | ## Purpose 18 | 19 | The Max Auction Duration parameter exists to prevent auctions from continuing for longer than Maker Governance wishes. It is redundant with the Max Auction Drawdown parameter and allows Maker Governance to decide whether to set the maximum duration directly or implicitly via the [Auction Price Function](param-auction-price-function.md) and Max Auction Drawdown parameters. 20 | 21 | The Max Auction Duration would need to be used if the Auction Price Function for a vault type was entirely flat (offering a fixed price redemption), which may be true when liquidating stablecoin collateral. 22 | 23 | ## Trade-offs 24 | 25 | A large Max Auction Duration increases the amount of time that keepers have to bid in the auction before it needs to be reset. On the other hand, having a shorter duration means relying more heavily on the swift participation of keepers within collateral auctions. 26 | 27 | If auctions are too short, there is a risk of liquidations not ending profitably before a reset is required. This may be negative depending on the settings for the [Flat Kick Incentive](param-flat-kick-incentive.md) and the [Proportional Kick Incentive](param-proportional-kick-incentive.md) because these incentives are paid to keepers at each reset. 28 | 29 | The trade-offs to this parameter are heavily tied to the Auction Price Function parameter, as the shape of the curve may heavily affect the desired auction length. 30 | 31 | ## Changes 32 | 33 | Adjusting a Max Auction Duration parameter for a specific vault type is a manual process that requires an executive vote. Changes to Max Auction Duration parameters are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 34 | 35 | ## Considerations 36 | 37 | Auction resets can only take place when either the Max Auction Duration parameter or the Max Auction Drawdown parameter are exceeded. 38 | 39 | During an [Emergency Shutdown](https://docs.makerdao.com/smart-contract-modules/shutdown), new auctions are halted, but the [Four-Stage Liquidations Circuit Breaker](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation#four-stage-liquidation-circuit-breaker) determines if ongoing auctions can be reset or not. If only one additional level of the circuit breaker is triggered, the Max Auction Duration will still be used to check eligibility for auction reset, but under the most severe level of the Liquidations Circut breaker no resets can be performed, thus limiting the effectiveness of the parameter. 40 | 41 | >Page last reviewed: 2022-11-07 42 | >Next review due: 2023-11-07 43 | -------------------------------------------------------------------------------- /parameter-index/surplus-auction/param-surplus-slippage-tolerance.md: -------------------------------------------------------------------------------- 1 | # Smart Burn Engine Slippage Tolerance 2 | 3 | >**Alias:** N/A 4 | >**Parameter Name:** `want` 5 | >**Containing contract:** `MCD_FLAP` 6 | >**Scope:** System 7 | >**Technical Docs:** N/A 8 | 9 | ## Description 10 | The Smart Burn Engine Slippage Tolerance or `want` parameter controls the amount of deviation between the oracle price of MKR and the price obtained by the Smart Burn Engine. It is one of the parameters that defined whether or not the Smart Burn Engine can be triggered. 11 | 12 | The Smart Burn Engine can be triggered when: 13 | 14 | _MKR_Purchased >= Oracle_Price * Smart_Burn_Engine_Lot_Size * want_ 15 | 16 | {% hint style="info" %} 17 | 18 | **Example** 19 | 20 | *Smart Burn Engine Lot Size* = 10,000 DAI 21 | *Smart Burn Engine Slippage Tolerance* = 0.98 22 | *Oracle Price* = 1,000 DAI/1 MKR 23 | 24 | 1. MKR purchase per Oracle should be 10 MKR for 10,000 DAI. 25 | 2. Uniswap purchase must result in *at least* 9.8 MKR being purchased or the transaction will fail. 26 | 27 | {% endhint %} 28 | 29 | ## Purpose 30 | 31 | The Smart Burn Engine Slippage Tolerance parameter allows Maker Governance to tune the frequency and accessibility of Smart Burn Engine actions in order to achieve better efficiency. 32 | 33 | ## Trade-offs 34 | 35 | Increasing the Smart Burn Engine Slippage Tolerance will allow greater slippage when the Smart Burn Engine is activated - this increases the probability of trades executing, but also increases the risk the purchases being frontrun and/or sandwiched and could potentially lead to a poor deal for the Protocol. 36 | 37 | Reducing the Smart Burn Engine Slippage Tolerance will reduce the allowed slippage. This means that the price of purchases will be closer to the oracle price, but it may also result in purchases not happening if the Uniswap price deviates from the oracle price too much. If the `want` is very small, it would be possible to prevent the Smart Burn Engine from making purchases by deliberately moving the price of the pool out of the range of the Smart Burn Engine Slippage Tolerance. 38 | 39 | ## Changes 40 | Adjusting the Smart Burn Engine Slippage Tolerance parameter is a manual process that requires an executive vote. Changes to the Smart Burn Engine Slippage Tolerance are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 41 | 42 | In general the goal when tweaking this parameter is to trade-off of making sure that there is a steady stream of purchases of MKR against the risks of sandwich attacks against the Smart Burn Engine resulting in less efficient purchases. 43 | 44 | **Why increase this parameter?** 45 | 46 | The main reason for Maker Governance to increase the Smart Burn Engine Slippage Tolerance is if it is too restrictive and preventing purchases from happening. 47 | 48 | **Why decrease this parameter?** 49 | 50 | The main reason for Maker Governance to decrease the Smart Burn Engine Slippage Tolerance is if there is an excessive amount of sandwiching happening. If the parameter is set too high, MEV bots and other participants will be able to abuse the Smart Burn Engine to make risk-free profit at the detriment of the Maker Protocol. 51 | 52 | ## Considerations 53 | 54 | As triggering the Smart Burn Engine is permissionless, incorrectly setting the Smart Burn Engine Slippage Tolerance may expose the Protocol to sandwich attacks. 55 | 56 | The Smart Burn Engine Slippage Tolerance only applies when the price of MKR in the Uniswap pool is *worse* than the oracle price. It will not prevent purchases when the pool price is > `want`% *better* than the oracle price. 57 | 58 | >Page last reviewed: 2023-08-01 59 | >Next review due: 2024-08-01 60 | 61 | -------------------------------------------------------------------------------- /parameter-index/collateral-auction/param-auction-price-function.md: -------------------------------------------------------------------------------- 1 | # Price Function 2 | 3 | >**Alias:** Price Curve 4 | >**Parameter Name:** `calc` 5 | >**Containing Contracts:** `MCD_CLIP_$ILK` 6 | >**Scope:** Vault Type (Ilk) 7 | >**Technical Docs:** [Liquidations 2.0](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) 8 | 9 | 10 | ## Description 11 | 12 | The Auction Price Function is the mathematical function that determines how the collateral price changes over time during a collateral auction. Collateral auctions use a falling price auction, where the price starts high and decreases according to the function defined in this parameter. 13 | 14 | Auction Price Functions are implemented as smart contracts exposing specific interface functions. An Auction Price Function contract may have additional parameters that allow Maker Governance to adjust certain aspects of the function. 15 | 16 | Each vault type may have its own Auction Price Function, though in practice they may share the same Auction Price Function contract. 17 | 18 | ## Purpose 19 | 20 | This parameter exists to control the shape of the price curve used when auctioning collateral from liquidated vaults. 21 | 22 | ## Price Curves 23 | 24 | ### Exponential Stair Step 25 | 26 | #### cut 27 | Controls the 'depth' of each step in the function. A smaller cut means a smoother line, a large one means more pronounced steps. 28 | 29 | This is a multiplicative factor. For example, 0.99 equates to a 1% price drop. 30 | 31 | #### step 32 | Controls the length of time between price drops. A smaller step means a smoother line, a large one means more pronounced steps. This is defined in seconds. 33 | 34 | ![Exponential Stair Step Auction](https://github.com/makerdao/governance-manual/blob/main/parameter-index/collateral-auction/images/cut-and-step.png?raw=true) 35 | 36 | ### Linear Decrease 37 | 38 | In an auction utilizing a Linear Decrease Auction Price Function, the auction will start at a price defined by the Auction Price Multiplier. The price will decrease linearly over time until it reaches zero. The time that it takes for an auction to reach zero is controlled by the `tau` parameter. 39 | 40 | #### tau 41 | A value expressed in seconds which controls how long it takes for the price of a Linear Decrease auction to reach zero. This controls the rate of fall in the price of the collateral being auctioned. A higher `tau` will result in a slower reduction in the price of collaterals, whereas a lower `tau` will cause faster falls in price. 42 | 43 | The Linear Decrease function is also bounded by the [Maximum Auction Duration](param-max-auction-duration.md) parameter. This can be used to set a lower bound on the price accepted by the Maker Protocol. Once this value has been reached, the price will stop falling. Keepers can restart the auction from the initial price at this point. 44 | 45 | ## Trade-offs 46 | 47 | Having control over the parameters of the Auction Price Function allows Governance to fine-tune the performance of auctions to best fit changing market conditions. A non-optimal setting could result in auctions resolving less quickly or in collateral being auctioned off at a lower price. 48 | 49 | An auction price falling too quickly may lead to a situation where keepers are not able to bid before the auction ends. 50 | 51 | An auction price falling too slowly may increase the auction slippage and could potentially cause bad debt. 52 | 53 | ## Changes 54 | 55 | Adjusting an Auction Price Function parameter is a manual process that requires an executive vote. Changes to an Auction Price Function are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 56 | 57 | >Page last reviewed: 2022-11-10 58 | >Next review due: 2023-11-10 59 | -------------------------------------------------------------------------------- /module-index/module-emergency-shutdown.md: -------------------------------------------------------------------------------- 1 | # Emergency Shutdown 2 | 3 | >**Alias:** ESM 4 | >**Contract Name:** `MCD_ESM` 5 | >**Scope:** System 6 | >**Technical Docs:** [link](https://docs.makerdao.com/smart-contract-modules/shutdown/emergency-shutdown-module) 7 | 8 | ## Description 9 | 10 | 11 | The Emergency Shutdown Module allows users to deposit MKR into the module to perform an emergency shutdown of the Maker Protocol. 12 | 13 | When MKR holders have deposited enough MKR to the Emergency Shutdown Module, if the Emergency Shutdown Module has the appropriate authorization over the `End` contract, the emergency shutdown process can be triggered permissionlessly by calling the `fire` function. 14 | 15 | MKR deposited to the module is not retrievable and should be considered burned. 16 | 17 | ## Purpose 18 | 19 | The Emergency Shutdown Module allows MKR holders to trigger the emergency shutdown process, allowing the Maker Protocol to wind down, with DAI holders able to redeem DAI for underlying collateral. It is intentionally designed to allow a minority of MKR token holders to intervene against the wishes of a (potentially malicious) majority. 20 | 21 | The Emergency Shutdown Module was designed with certain scenarios in mind, such as to prevent a malicious governance attack or to mitigate critical bugs. 22 | 23 | ## Key Parameter 24 | 25 | ### Minimum Threshold (`min`) 26 | 27 | The minimum threshold parameter controls how much MKR must be deposited to the Emergency Shutdown Module before emergency shutdown may be triggered. 28 | 29 | ### Example 30 | 31 | Suppose Governance has set the minimum threshold of MKR required to trigger emergency shutdown as 100,000 MKR. In that case, emergency shutdown cannot be initiated until at least 100,000 MKR has been deposited to the Emergency Shutdown Module. 32 | 33 | ## Trade-offs 34 | 35 | Suppose the minimum threshold parameter is set to too low a value. In that case, the Maker Protocol is potentially vulnerable to emergency shutdown being performed by an actor, or group of actors, in possession of enough MKR to perform an emergency shutdown. This vulnerability is particularly relevant when a large amount of MKR is available to borrow from DeFi protocols. Theoretically, a user could borrow enough MKR to trigger emergency shutdown and open shorts on MKR; in this scenario, the attacker would expect that the price of MKR would fall following emergency shutdown, allowing the attacker to close their loans for a profit without endangering their collateral too much. 36 | 37 | Suppose the minimum threshold parameter is set too high. In that case, it becomes increasingly economically challenging to perform an emergency shutdown and may leave the protocol unable to respond to critical bugs or governance attacks. This difficulty is because MKR deposited to the Emergency Shutdown Module is not retrievable and should be considered burned by depositors. 38 | 39 | ## Considerations 40 | 41 | Triggering the Emergency Shutdown Module is not subject to the GSM Pause Delay. 42 | 43 | Maker Governance can effectively turn off the Emergency Shutdown Module by removing its authorization to trigger an emergency shutdown. This can also be achieved by raising the minimum threshold to a value greater than the amount of MKR in circulation. 44 | 45 | Delegate contracts are unable to interact with the Emergency Shutdown Module. Therefore, there is no risk of a delegate depositing their delegated MKR into the Emergency Shutdown Module. 46 | 47 | If the protocol is restarted, Governance might choose to mint MKR to reward MKR holders depositing MKR into the Emergency Shutdown Module to encourage good-faith actors to act in a manner beneficial to the protocol. However, this is not guaranteed and requires a degree of trust in Governance of the restarted protocol. 48 | 49 | >Page last reviewed: 2022-08-31 50 | >Next review due: 2023-08-31 51 | -------------------------------------------------------------------------------- /governance/executive-transaction-verification.md: -------------------------------------------------------------------------------- 1 | 2 | # Executive Transaction Verification 3 | 4 | The transaction that you sign when voting on an executive proposal should use one of the following methods. 5 | 6 | ## Method A - Vote(bytes32) 7 | 8 | This method is the most common and is almost always what you'll see when interacting with a voting front-end. 9 | 10 | This method takes a single parameter, a bytes32 representing a _slate_. 11 | 12 | | Prefix | Method | Data | 13 | |--------|----------|---------------------------------------------------------------------| 14 | | 0x | a69beaba | 64 character hexadecimal slate | 15 | | 0x | a69beaba | c74a4375635bd53ac4d2911e80e815dd5e520080d53015b1c840b44a80844a00 | 16 | 17 | ### Step 1 - Finding the Slate 18 | 19 | The first step here is locating the _slate_. A _slate_ represents a collection of addresses (almost always executive spell contracts) that are voted for as a group. This grouping of voted addresses is a consequence of the executive voting system and its support for approval voting. Slates are also used to represent single addresses within the Maker Protocol governance contract. 20 | 21 | Using metamask, check the data and hex tabs: 22 | 23 | ![exec-transaction-verification-1](../images/exec-transaction-verification-1.png) 24 | 25 | ![exec-transaction-verification-2](../images/exec-transaction-verification-2.png) 26 | 27 | ## Step 2 - Checking the Slate 28 | 29 | Once you have located the 64-character hexadecimal string that represents the slate, you should check it against the contents of the slate in the [DSChief](https://etherscan.io/address/0x0a3f6849f78076aefadf113f5bed87720274ddc0#readContract) contract. 30 | 31 | ![exec-transaction-verification-3](../images/exec-transaction-verification-3.png) 32 | 33 | Using etherscan, you can navigate to read-method 17, 'slates'. There are two input fields. 34 | 1. For the first field you should enter the slate address you identified in step 1. You should prefix the string with 0x. 35 | 2. The the second field you should first enter 0. 36 | 37 | In the below example, the spell address we intended to vote for is: **0xd498E7DEE467d1eb6Ed3933e579c427E168b6E6c**. 38 | 39 | Etherscan should display a spell address that matches the spell address of the proposal which you have selected using the Voting Portal UI. 40 | 41 | ![exec-transaction-verification-4](../images/exec-transaction-verification-4.png) 42 | 43 | Next, you should increment the second input field and query until you see an error message. 44 | 45 | ![exec-transaction-verification-5](../images/exec-transaction-verification-5.png) 46 | 47 | **You are voting in favor of all addresses that appear prior to this error message being given permission over the core Maker Protocol contracts.** 48 | 49 | ## Method B - Vote(address[]) 50 | 51 | This method is used more rarely, usually only when you are the first person to vote on a new address or set of addresses. 52 | 53 | The structure of the transaction data is a little more variable than for method A. However it should: 54 | * Start with **0xed081329** 55 | * Contain one or more Ethereum addresses separated by strings of zeros. 56 | 57 | ### Step 1 - Check Addresses 58 | 59 | The first and only step here is to check that addresses present in the transaction data match the addresses that you intend to vote for. 60 | 61 | In the below example the spell address used is: **0x9f8f72aa9304c8b593d555f12ef6589cc3a579a2**. 62 | 63 | Using metamask, check the data and hex tabs: 64 | 65 | ![exec-transaction-verification-6](../images/exec-transaction-verification-6.png) 66 | 67 | ![exec-transaction-verification-7](../images/exec-transaction-verification-7.png) 68 | 69 | **You are voting in favor of all addresses that appear in this transaction data being given permission over the core Maker Protocol contracts.** 70 | 71 | -------------------------------------------------------------------------------- /parameter-index/archive/param-auction-duration-flap.md: -------------------------------------------------------------------------------- 1 | # Auction Duration (Flap) 2 | 3 | >**Alias:** N/A 4 | >**Parameter Name:** `tau` 5 | >**Containing Contract:** `MCD_FLAP` 6 | >**Scope:** System 7 | >**Technical Docs:** [Flap Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/system-stabilizer-module/flap-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Surplus Auction Duration parameter allows governance to control the maximum lifetime of a Surplus Auction. A surplus auction can end before this maximum duration is reached if the Bid Duration timer expires without any additional bids. 12 | 13 | Surplus auctions are used to auction off excess DAI in fixed lots for a variable bid of MKR, which is then burned. In this process, keepers bid the amount of MKR they are willing to pay for a fixed amount of DAI. 14 | 15 | {% hint style="info" %} 16 | 17 | **Example** 18 | 19 | _Surplus Bid Duration_ = 300 seconds 20 | _Surplus Auction Duration_ = 24 hours 21 | 22 | 1. A surplus auction is triggered and 3 hours pass with no bid. 23 | 2. Keeper A bids 10 MKR in exchange for 100 DAI at the 3-hour mark. 24 | 3. Keeper B has 300 seconds in which to offer a more attractive bid or else Keeper A will win the auction. 25 | 4. Keeper B bids 11 MKR in exchange for 100 DAI at 23 hours and 59 minutes into the auction. 26 | 5. Keeper A has 60 seconds to offer a more attractive bid or else Keeper B will win the auction. 27 | 28 | {% endhint %} 29 | 30 | ## Purpose 31 | 32 | The Surplus Auction Duration parameter allows Maker Governance to adjust the maximum duration for surplus auctions in order to ensure robust keeper participation. 33 | 34 | ## Trade-offs 35 | 36 | The Surplus Auction Duration makes a trade-off between ensuring enough time for keepers to deploy their capital while limiting their market risk. A larger Surplus Auction Duration gives keepers more time to participate in auctions. A smaller Surplus Auction Duration means that keepers are less likely to be affected by negative price movements of the MKR token during the auction process. Maximizing the number of participating bidders results in more efficient auctions and more MKR being burned. 37 | 38 | However, too large a Surplus Auction Duration could result in a situation where there are many auctions happening simultaneously. On the other hand, if the Surplus Auction Duration is too small, then keepers may not have sufficient time to organize their resources and place bids. Either of these situations could result in inefficient auctions that reduce the amount of MKR burned. 39 | 40 | ## Changes 41 | 42 | Adjusting the Surplus Auction Duration parameter is a manual process that requires an executive vote. Changes to the Surplus Auction Duration are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 43 | 44 | **Why increase this parameter?** 45 | Maker Governance may wish to increase the Surplus Auction Duration to encourage greater participation if too few keepers are participating in surplus auctions. 46 | 47 | **Why decrease this parameter?** 48 | Maker Governance may wish to decrease the Surplus Auction Duration if the auctions are so long that keepers almost always make losses. Additionally, if there are too many overlapping auctions, it may be desirable to decrease this parameter. 49 | 50 | ## Considerations 51 | 52 | Surplus Auction Duration is always lower-bounded by the [Surplus Auction Bid Duration](param-bid-duration-flap.md), i.e., the time period that must pass before the latest successful bid wins the auction. If it is set lower than the Surplus Auction Bid Duration, it will render that parameter unnecessary since the auction will end before a bid expires. 53 | 54 | For example, if Surplus Auction Bid Duration is 1 hour and Surplus Auction Duration is 30 minutes, then the auction will only last 30 minutes, making the Surplus Auction Bid Duration irrelevant. 55 | 56 | >Page last reviewed: 2022-11-18 57 | >Next review due: 2023-11-18 58 | 59 | -------------------------------------------------------------------------------- /parameter-index/collateral-auction/param-local-liquidation-limit.md: -------------------------------------------------------------------------------- 1 | # Local Liquidation Limit 2 | 3 | >**Alias:** Local Liquidation Limit 4 | >**Parameter Name:** `hole` 5 | >**Containing Contract:** `MCD_DOG` 6 | >**Scope:** Vault Type (Ilk) 7 | >**Technical Docs:** [Liquidations 2.0](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Local Liquidation Limit sets the maximum amount of DAI debt for which collateral auctions can be active at any one time within a particular vault type. When the total DAI value of auctions exceeds this maximum for a particular vault type, no more collateral can be auctioned using that vault type until others are completed. 12 | 13 | Each vault type has a separate Local Liquidation Limit. If auctions from ETH-A liquidations fill the ETH-A Local Liquidation Limit, no further auctions can be triggered on the ETH-A vault, but liquidations on the WBTC-A vault could still go to auction. 14 | 15 | ## Purpose 16 | 17 | Much like the [Global Liquidation Limit](../core/param-global-liquidation-limit.md), the Local Liquidation Limit parameter exists to prevent an excess of a particular collateral type from overwhelming Keepers or the broader market liquidity for a collateral token. While the implementation of Liquidations 2.0 settles many concerns about Keeper Liquidity, the collateral purchased at auction still has to be sold in the broader market. 18 | 19 | In the case of a collateral that has multiple vault types, the Local Liquidation Limit helps prevent riskier vault types from accelerating a market selloff that could trigger cascading liquidations in other vault types sharing the same collateral asset. 20 | 21 | ## Trade-offs 22 | 23 | While the Local Liquidation Limit provides an added measure of safety for individual vault types, setting an appropriate limit is quite difficult. If this parameter is set too high, a major collateral decline or exploit within a particular vault could quickly result in an unacceptable level of bad debt within the system. 24 | 25 | The main risk of setting the Global Liquidation Limit parameter too low is that a backlog of undercollateralized positions could build-up, leading to the accrual of bad debt that is above market rates by the time it goes to auction. This scenario becomes more dangerous to the protocol the longer it occurs (such as in a prolonged decline in multiple collateral assets.) 26 | 27 | ## Changes 28 | 29 | Adjusting a Local Liquidation Limit parameter is a manual process that requires an executive vote. Changes to the Local Liquidation Limits are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 30 | 31 | **Why increase this parameter?** 32 | 33 | The primary reason to increase a Local Liquidation Limit would be confidence in a vault type's risk configuration combined with plenty of market liquidity for the underlying collateral asset. Provided there is enough liquidity, the community may wish to raise the Local Liquidation Limit to prevent a situation where the protocol is not able to auction off unsafe positions quickly enough. 34 | 35 | **Why decrease this parameter?** 36 | 37 | Conversely, the primary reason to decrease the Local Liquidation Limit is a concern for the liquidity of an underlying collateral type or the other risk parameters of a vault type. If there are concerns about the liquidity of Maker Keepers or the broader market to absorb the large sell orders prompted by liquidations, one response may be to lower the Local Liquidation Limit for vault types backed by collateral assets that have less market liquidity. 38 | 39 | ## Considerations 40 | 41 | During an [Emergency Shutdown](https://docs.makerdao.com/smart-contract-modules/shutdown), no new collateral auctions may be started. All auctions underway during an emergency shutdown would have been subject to the Local Liquidation Limit parameters with no special considerations. 42 | 43 | >Page last reviewed: 2022-11-16 44 | >Next review due: 2023-11-16 45 | 46 | -------------------------------------------------------------------------------- /work-in-progress/hashing.md: -------------------------------------------------------------------------------- 1 | # Hashing Proposals 2 | 3 | In the Governance Process, all copy for Polls and Executive Proposals is hashed to verify their validity. This gives MKR Voters the ability to confirm that the contents displayed on the [Voting Portal](https://vote.makerdao.com/) are the same contained in the onchain code. With Governance proposals requiring a high degree of coordination, taking the hash of a proposal is one way to verify its validity. 4 | 5 | ## Why hashing? 6 | 7 | Hash functions are one of the core cryptographic tools that make work on the blockchain possible. Hashes are particularly useful for verification as the same data will always produce the same hash, but the resulting hash cannot be used to reverse engineer the original data. 8 | 9 | However, this one-way relationship between the data and the hash is only protected when the data is unique. Hash databanks for common phrases are used in password attacks, but given that even the slightest change to the input data results in a wildly different hash, the technology allows users to verify that the data they are viewing is exactly the same as advertised. 10 | 11 | Another common use of hash functions is to verify downloaded files. A user can get the expected hash of a file from a trusted source and run a hash algorithm on the file to ensure it has not been tampered with before opening. Likewise, any onchain proposal can have its hash verified before MKR holders submit their vote. 12 | 13 | ## How are proposals hashed? 14 | 15 | MakerDAO uses the Keccak256 hash function to generate hashes for the Executive Proposals. This is the hashing function that the Ethereum blockchain uses internally, but since we are just displaying the hash onchain any function could have been chosen. 16 | 17 | For polls, MakerDAO utilizes IPFS Hash. As long as the end-user knows what hashing algorithm has been used, they can independently verify the contents. 18 | 19 | The process for Polls and Executives varies slightly, but both depend on the [MakerDAO Community Repo](https://github.com/makerdao/community). The contents from a specific commit make up the hash, and as long as the correct commit is used to compare to the hash onchain the same result will be returned. 20 | 21 | ### Executive Process 22 | 23 | Executive Proposals are slightly more difficult to verify as the hashed version will not be the most recent commit by nature of the workflow. 24 | 25 | This is because the spell address is added to the copy of every Executive Proposal in the GitHub Repo, but this can only be done once the hash of the copy has been generated and added to the code. 26 | 27 | As a result, the hash the appears in the code of an executive proposal is generated from the last GitHub commit before the Spell Address is added into the copy. 28 | 29 | This is the hash that will appear in the code of any Governance-sanctioned Executive Proposal. Since any changes, no matter how slight, will completely change the resulting hash function, coordination takes place between Governance and Spell-crafters so the onchain proposal contains the hash of the executive copy that is displayed on the voting portal. 30 | 31 | ### Polling Process 32 | 33 | Hashing for onchain-polls is a simpler process. When a poll is created through the voting portal, it is submitted onchain and hashed automatically through the [front end code](https://github.com/makerdao/governance-portal-v2/blob/bf8c8008e21e76e6c48ad052477aeda142b985f6/pages/polling/create.tsx). This code sends the information to the Log of the poll creation, and can be viewed on Etherscan. 34 | 35 | ![image](https://user-images.githubusercontent.com/75535017/141056352-823c1e49-ad3e-4c8e-a2c5-de7c08f99798.png) 36 | *A poll example showing the data transmitted onchain.* 37 | 38 | 39 | ## How can the hashes be verified? 40 | 41 | For an in-depth view on how to verrify Executive Proposals, please see [$insert-page-link-here](). 42 | 43 | For onchain polls, users have a variety of options. IPFS uses [multihash](https://github.com/multiformats/multihash), so users could add any of the linked repositories to their local environment and run the hash algorithm. This output would be compared to the Log of the transaction for the specific poll. 44 | -------------------------------------------------------------------------------- /governance/monthly-governance-cycle.md: -------------------------------------------------------------------------------- 1 | # Monthly Governance Cycle 2 | 3 | The Monthly Governance Cycle is defined in [MIP51](https://mips.makerdao.com/mips/details/MIP51) and provides a predictable monthly cadence by which governance decisions are made. 4 | 5 | The Monthly Governance Cycle is predominantly used for the introduction of new MIPs or MIP subproposals into the Maker Protocol. Examples of such changes could include: 6 | 7 | * The addition of a new Core Unit to the Maker Protocol 8 | * The adjustment of an existing Core Unit's operating budget 9 | 10 | Proposals submitted into the Monthly Governance Cycle must follow the guidelines defined in [MIP0](https://mips.makerdao.com/mips/details/MIP0). 11 | 12 | ## Governance Cycle Overview 13 | 14 | ![Gov Cycle](https://user-images.githubusercontent.com/53664591/114054203-8c7de580-9887-11eb-90da-0431b051fff3.png) 15 | 16 | *Note: Time is inclusive and based on UTC (Coordinated Universal Time) and the Gregorian calendar.* 17 | 18 | ## Governance Cycle Breakdown ([MIP51c1](https://mips.makerdao.com/mips/details/MIP51#MIP51c1)) 19 | 20 | The first Monday of each calendar month marks the beginning of the Monthly Governance Cycle. 21 | 22 | ### Week 1 23 | 24 | **Week 1, Monday through Wednesday** 25 | 26 | - MIP Authors move their proposals to **Formal Submission**. This phase lasts for 3 days. 27 | - Proposals must be moved into the [Formal Submission](https://forum.makerdao.com/c/mips/fs/16) subcategory on the MakerDAO forums under the [Maker Improvement Proposal](https://forum.makerdao.com/c/mips/14) category. 28 | - MIP Authors should inform [MIP Editors](https://forum.makerdao.com/g/MIP-Editors) of the status change via commonly used communications channels. 29 | 30 | **Week 1, Thursday** 31 | 32 | - Governance Facilitators perform the **Submission Review** as part of the weekly Governance and Risk meeting and communicate which of the proposed MIPs are in accordance with guidelines (defined in the [MIP0](https://mips.makerdao.com/mips/details/MIP0) Framework). 33 | - The Governance Facilitators must come to consensus on whether each submission should move forward to a Ratification Poll. 34 | - Governance Facilitators may consider blocking a proposal if they believe that moving forward to a Ratification Poll would negatively affect community cohesion. 35 | - If the Governance Facilitators prevent a proposal from moving to a Ratification Poll, they must clearly communicate their reasons for doing so via the official [forum](https://forum.makerdao.com). 36 | - In the event the Governance Facilitators abuse this power **they should be removed from their positions via any method Maker Governance determines is appropriate**. 37 | - MIPs that meet the guidelines and are not found objectionable by Governance Facilitators will continue to the Ratification Poll stage. 38 | 39 | ### Week 2 40 | 41 | **Week 2, Monday** 42 | 43 | - The Governance Facilitators publish the set of **Ratification Polls**. The format of these is defined in [MIP51c2](https://mips.makerdao.com/mips/details/MIP51#MIP51c2). 44 | - Ratification Polls are published to the [community GitHub](https://github.com/makerdao/community/tree/master/governance/polls), submitted on-chain and appear on the official [voting portal](https://vote.makerdao.com/). 45 | - Ratification Polls will run for two weeks. 46 | 47 | ### Week 4 48 | 49 | **Week 4, Monday** 50 | 51 | - The Ratification polls conclude, and each proposal or set of proposals is marked as either Accepted or Rejected by the MIP Editors. 52 | 53 | **Week 4, Thursday** 54 | 55 | - The Governance Facilitators do a **Governance Cycle Review** as part of the weekly Governance and Risk meeting in which they summarize and discuss the Governance Cycle with the community. 56 | - The Governance Facilitators also discuss the upcoming Governance Cycle and potential submissions with the community. 57 | 58 | --- 59 | 60 | ### Calendar Exceptions ([MIP51c4](https://mips.makerdao.com/mips/details/MIP51#MIP51c4)) 61 | 62 | Due to the multitude of cultural and religious holidays occurring in and around the month of December, there will be no Monthly Governance Cycle in December. 63 | 64 | >Page last reviewed: 2022-10-25 65 | >Next review due: 2023-10-25 -------------------------------------------------------------------------------- /parameter-index/core/param-global-liquidation-limit.md: -------------------------------------------------------------------------------- 1 | # Global Liquidation Limit 2 | 3 | >**Alias:** Global Liquidation Limit 4 | >**Parameter Name:** `Hole` 5 | >**Containing Contract:** `MCD_DOG` 6 | >**Scope:** System 7 | >**Technical Docs:** [Liquidation 2.0 Module](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Global Liquidation Limit sets the maximum amount of DAI debt for which collateral auctions can be active at any one time. When the total DAI value of auctions exceeds this maximum, no new auctions can begin until others are completed. 12 | 13 | The Global Liquidation Limit holds across all vault types. If auctions from ETH-A liquidations fill the Global Liquidation Limit, no further auctions can be triggered on the ETH-A vault or the WBTC-A vault. 14 | 15 | ## Purpose 16 | 17 | The purpose of the Global Liquidation Limit is to prevent the amount of collateral up for auction from exceeding what the market can handle and incurring unacceptable slippage. While the implementation of Liquidations 2.0 settles many concerns about Keeper liquidity, the collateral purchased at auction still has to be sold off in the broader market. 18 | 19 | The Global Liquidation Limit also performs an important role during a malicious attack on the protocol, preventing a large percentage of collateral from being moved into auctions at one time. 20 | 21 | ## Trade-offs 22 | 23 | While the Global Liquidation Limit provides some safety for the system, setting an appropriate limit may be difficult. If this parameter is set too high, the wider market may be overwhelmed and the collateral auctions may incur more slippage than is desirable. 24 | 25 | In addition to concerns noted above, having a Global Liquidation Limit that is too high during a time of major volatility could create such a demand for DAI that the peg breaks high, causing further issues with users attempting to avoid liquidation. 26 | 27 | The main risk of setting the Global Liquidation Limit parameter too low is that a backlog of undercollateralized positions could build-up, leading to the accrual of bad debt that is above market rates by the time it goes to auction. This scenario gets more dangerous to the protocol the longer it occurs (such as in a prolonged decline in multiple collateral assets.) 28 | 29 | ## Changes 30 | 31 | Adjusting the Global Liquidation Limit parameter is a manual process that requires an executive vote. Changes to the Global Liquidation Limit are subject to the [GSM Pause Delay](param-gsm-pause-delay.md). 32 | 33 | **Why increase this parameter?** 34 | 35 | The primary reason to increase the Global Liquidation Limit would be confidence in the underlying collateral auction system and the DAI liquidity available in the market. If the broader market has strong cross-collateral liquidity and DAI liquidity, an increase to the Global Liquidation Limit could allow for unsafe positions to be liquidated more quickly and help protect the protocol during steep market declines. 36 | 37 | **Why decrease this parameter?** 38 | 39 | Conversely, the primary reason to decrease the Global Liquidation Limit is a concern for the underlying collateral auction system. If there are concerns about the liquidity accessible to Keepers or the broader market's ability to absorb large sell orders without significant slippage, then lowering the Global Liquidation Limit may be advisable. 40 | 41 | ## Considerations 42 | 43 | The [Liquidations 2.0](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) system allows the Global Liquidation Limit to be set at a higher level than Liquidations 1.2 because the Dutch Auction format allows for instant settlement, enabling the use of Flash Loans by Maker Keepers. However, because auctions can have near-instant settlement, the Global Liquidation Limit no longer acts as a rate-limit on auctions as it did in Liquidations 1.2. 44 | 45 | During an Emergency Shutdown, no new collateral auctions may be started. All auctions underway during an [Emergency Shutdown](https://docs.makerdao.com/smart-contract-modules/shutdown) would have been subject to the Global Liquidation Limit parameter with no special considerations. 46 | 47 | >Page last reviewed: 2022-11-04 48 | >Next review due: 2023-11-04 49 | -------------------------------------------------------------------------------- /parameter-index/archive/param-surplus-auction-limit.md: -------------------------------------------------------------------------------- 1 | # Surplus Auction Limit 2 | 3 | >**Alias:** N/A 4 | >**Parameter Name:** `lid` 5 | >**Containing Contract:** `MCD_FLAP` 6 | >**Scope:** System 7 | >**Technical Docs:** [Flapper Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/system-stabilizer-module/flap-detailed-documentation) 8 | 9 | 10 | ## Description 11 | During surplus auctions, excess DAI within the system is auctioned off in fixed lots for MKR. In this process, keepers bid on how much MKR they are willing to pay for a fixed amount of DAI. MKR received this way is burned. 12 | 13 | To avoid flooding the system with too many simultaneous auctions, the maximum amount of DAI that can be auctioned at any given point in time is limited. The parameter that sets this limit is the Surplus Auction Limit or `lid` parameter. 14 | 15 | {% hint style="info" %} 16 | 17 | **Example** 18 | 19 | _Surplus Auction Limit_ = 30,000 DAI 20 | _Surplus Auction Lot Size_ = 10,000 DAI 21 | 22 | 1. Three DAI Surplus Auctions (A, B and C) are triggered, accepting bids of MKR in exchange for 10,000 DAI. 23 | 2. The amount of DAI in Surplus Auction now equals the Surplus Auction Limit. 24 | 3. Keeper A attempts to start Surplus Auction D, but the transaction fails. 25 | 3. Surplus Auction A concludes, and the amount of DAI in Surplus Auction now equals 20,000 DAI. 26 | 4. Keeper A may now start Surplus Auction D. 27 | 28 | {% endhint %} 29 | 30 | ## Purpose 31 | Changing the Surplus Auction Limit allows Maker Governance to strike a reasonable tradeoff between efficient auctions and the rate at which protocol profits are directed towards burning MKR. 32 | 33 | 34 | ## Trade-offs 35 | 36 | A small Surplus Auction Limit restricts the number of simultaneous flap auctions to a small number. This decreases the probability of there being auctions with insufficient participants. When auctions have enough participants, there is a low probability of winning MKR bids being significantly below market price. 37 | 38 | However, if the Surplus Auction Limit is too low and the protocol is making a large amount of profit on average, this may result in excess DAI remaining in the surplus buffer instead of being used to burn MKR. 39 | 40 | 41 | A large Surplus Auction Limit allows for more parallel surplus auctions. This increases the potential rate at which protocol profits can be used to burn MKR. If the protocol profits are high on average, then more parallel auctions are also needed to occur to buy back and burn MKR at a fast enough rate. Finally, under certain specific scenarios where the protocol makes large profits and MKR price is simultaneously low (such as liquidations due to a market crash), a large Surplus Auction Limit could result in more MKR being burned. 42 | 43 | On the other hand, if the Surplus Auction Limit is too large, it can lead to highly inefficient auctions due to too many auctions. In particular, past examples such as [Flappy Friday](https://forum.makerdao.com/t/flappy-friday-clip-and-flap-analysis/12790) have shown that too many simultaneous flap auctions can result in zero MKR bids winning the auction due to a lack of competition. 44 | 45 | 46 | 47 | ## Changes 48 | Adjusting the Surplus Auction Limit is a manual process that requires an executive vote. Changes to the Surplus Auction Limit are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 49 | 50 | **Why increase this parameter?** 51 | This parameter should be increased to increase the number of potential parallel auctions. This could be when the average protocol profits are high enough that more parallel auctions are necessary. 52 | 53 | 54 | **Why decrease this parameter?** 55 | This parameter should be decreased to avoid too many simultaneous auctions resulting in uncompetitive MKR bids. 56 | 57 | 58 | 59 | ## Considerations 60 | The Surplus Auction Limit should be at least as high as the `lot` amount for a single auction. Otherwise, no auctions will take place. 61 | 62 | If the amount of Dai on auction (`fill`) is less than the Surplus Auction Limit, then a new auction can be started even if that puts the total DAI on auction above the Surplus Auction Limit. At that point, no further auctions can be started. In other words, the maximum Dai on auction can be almost one `lot` higher than the Surplus Auction Limit. 63 | 64 | >Page last reviewed: 2022-11-09 65 | >Next review due: 2023-11-09 66 | 67 | -------------------------------------------------------------------------------- /parameter-index/debt-auction/param-debt-auction-delay.md: -------------------------------------------------------------------------------- 1 | # Debt Auction Delay 2 | 3 | >**Alias:** Flop Delay 4 | >**Parameter Name:** `wait` 5 | >**Containing Contract:** `MCD_VOW` 6 | >**Scope:** System 7 | >**Technical Docs:** [Vow Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/system-stabilizer-module/vow-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Debt Auction Delay parameter (`wait`) defines how much time must pass after a vault has been liquidated before any corresponding debt is marked as bad debt. 12 | 13 | If a corresponding Collateral Auction does not clear the debt and any associated penalty fees within the Debt Auction Delay, the remaining debt will be considered bad debt. This can happen either if the Collateral Auction does not raise enough Dai to cover the total debt despite all collateral being sold, or if the auction does not finish within the Debt Auction Delay. 14 | 15 | Initially, the Surplus Buffer will cover the bad debt; however, if the system accrues enough bad debt to exhaust the Surplus Buffer, the system will trigger a Debt Auction where MKR is minted and sold to cover the balance. 16 | 17 | {% hint style="info" %} 18 | 19 | **Example** 20 | 21 | _Debt Auction Delay_ = 2 hours 22 | _Current Surplus Buffer Amount_ = 30 million DAI 23 | 24 | 1. User A has an ETH vault with 100 million DAI debt. 25 | 2. User A's vault is liquidated and a collateral auction is triggered. 26 | 3. 100 million DAI debt is subtracted from the Surplus Buffer, resulting in -70 million DAI. 27 | 3. The collateral auction recovers 40 million DAI, which is added to the Surplus Buffer, resulting in -30 million DAI. 28 | 5. 2 hours from the time of liquidation, Debt Auctions are triggered for the outstanding 30 million DAI of bad debt. 29 | 30 | {% endhint %} 31 | 32 | ## Purpose 33 | 34 | The Debt Auction Delay exists to provide time for Keepers to bid on liquidated vaults via Collateral Auctions. If the Debt Auction Delay is set to zero, each liquidation would instantly trigger a Debt Auction, as well as a Collateral Auction, which would mint unnecessary amounts of MKR. 35 | 36 | ## Trade-offs 37 | 38 | If the Debt Auction Delay is set too low, the system may prematurely commence a Debt Auction before the corresponding Collateral Auction has been completed. For example, this can occur if the Debt Auction Delay is set to a lower value than the [Max Auction Duration](../collateral-auction/param-max-auction-duration.md) of Collateral Auctions. In this situation, it is conceivable that Keepers might cover outstanding debt within the remaining time, and the Debt Auction is therefore unnecessary. This scenario could lead to the Surplus Buffer being drained or to excess MKR being minted. 39 | 40 | If the Debt Auction Delay is set too high, then it will prevent Debt Auctions from occurring. This will prevent undercollateralized Dai being removed from the system. By allowing Dai to remain undercollateralized, confidence in Dai could be undermined. 41 | 42 | ## Changes 43 | 44 | Adjusting the Debt Auction Delay is a manual process that requires an executive vote. Changes to the Debt Auction Delay are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 45 | 46 | **Why increase this parameter?** 47 | 48 | Debt Auction Delay should be increased if the Max Auction Duration of Collateral auctions is increased to prevent unnecessary Debt Auctions. It might also be increased if a large number of Debt Auctions are expected to take place, to ensure Keepers have enough Dai capital to bid on the MKR being auctioned. 49 | 50 | **Why decrease this parameter?** 51 | 52 | The Debt Auction Delay might be decreased if it is taking too long for Debt Auctions to commence, leaving the system undercollateralized for longer than acceptable. This could impact Dai users and undermine confidence in Dai. 53 | 54 | ## Considerations 55 | 56 | Given that Debt Auctions can occur before the corresponding Collateral Auction has been completed, it is wise to ensure that `Debt Auction Delay > Max Auction Duration` to allow Collateral auctions time to complete. 57 | 58 | In theory, Maker Governance can arbitrarily extend the Debt Auction Delay, thus preventing Debt Auctions from occurring indefinitely. 59 | 60 | In [Emergency Shutdown](https://docs.makerdao.com/smart-contract-modules/shutdown), all Debt Auctions are cancelled, and the Debt Auction Delay is therefore nullified. 61 | 62 | >Page last reviewed: 2022-11-09 63 | >Next review due: 2023-11-09 64 | 65 | 66 | 67 | -------------------------------------------------------------------------------- /needs-rewrite/mips.md: -------------------------------------------------------------------------------- 1 | # MIPs 2 | 3 | ## What is a MIP? 4 | 5 | A Maker Improvement Proposal (MIP) is a document that regulates and defines the behavior of Maker Governance, MakerDAO, or the Maker Protocol. They are standardized documents voted upon by Maker Governance. MIPs can be amended and removed. 6 | 7 | The [Maker Improvement Proposal Framework (MIP0)](https://mips.makerdao.com/mips/details/MIP0) defines the Maker Improvement Proposals (MIPs) Framework for all subsequent MIPs to utilize. 8 | 9 | ## Current State 10 | 11 | The MIP Framework currently consists of 17 MIPs. Recent changes introduced by [the Endgame](https://endgame.makerdao.com/endgame/overview) have deprecated a large batch of MIPs (hence the seemingly haphazard numbering) and locked the framework in place by disallowing the creation of new MIPs. However, the existing MIPs can be amended. 12 | 13 | ## List of MIPs 14 | 15 | The MIP Framework currently comprises 17 MIPs, out of which five (marked with an asterisk) have been set to be deprecated. 16 | 17 | | MIP | Description | 18 | |--|--| 19 | | [MIP0: Maker Improvement Proposal Framework](https://mips.makerdao.com/mips/details/MIP0) | Defines the Maker Improvement Proposals (MIPs) Framework for all subsequent MIPs to utilize | 20 | | [MIP16: The Weekly Governance Cycle](https://mips.makerdao.com/mips/details/MIP16) | Defines and formalizes the Weekly Governance Cycle to provide a predictable weekly framework for Maker governance decisions | 21 | | [MIP24: Emergency Response](https://mips.makerdao.com/mips/details/MIP24) | Defines emergency and urgent situations for the Maker protocol, as well as the process for handling them | 22 | | [* The Core Unit Framework MIP Set (MIP38, MIP39, MIP40, MIP41)](https://mips.makerdao.com/mips/list?mipsetMode=true) | The Core Unit Framework MIP Set is a set of MIPs that defines the structure of Core Units | 23 | | [MIP51: Monthly Governance Cycle](https://mips.makerdao.com/mips/details/MIP51) | Defines a monthly Governance Cycle that provides a predictable framework for Maker governance decisions | 24 | | [* MIP55: Special Purpose Fund](https://mips.makerdao.com/mips/details/MIP55) | MIP55 defines Special Purpose Funda (SPFs), a tool used to fulfill a narrow, specific, or temporary objective where approved funds are locked in escrow | 25 | | [MIP62: Collateral Offboarding Process](https://mips.makerdao.com/mips/details/MIP62) | Defines how to notify users of Maker vaults of collateral offboarding | 26 | | [MIP101: Maker Atlas Immutable Alignment Artifact](https://mips.makerdao.com/mips/details/MIP101) | Defines the Atlas, which is the foundational set of rules that underpins the Scope Artifacts | 27 | | [MIP102: Endgame MIP Amendment and Removal Process](https://mips.makerdao.com/mips/details/MIP102) | Defines processes for the amendment and removal of accepted MIPs for the purposes of implementing the Endgame | 28 | | [MIP104: Stability Scope Bounded Mutable Alignment Artifact](https://mips.makerdao.com/mips/details/MIP104) | Defines the Stability Scope, which covers the management of the Dai Stablecoin. The Dai Stablecoin must be a permissionless and useful currency available to anyone. Its stability and risk must be managed to generate as much value for MakerDAO and public good as possible | 29 | | [MIP106: Support Scope Bounded Mutable Alignment Artifact](https://mips.makerdao.com/mips/details/MIP106) | Defines the Support Scope, which covers rules that regulate various tasks of ecosystem support, including governance process infrastructure and management, SubDAO and Ecosystem Actor support, and the Public Good Purpose System | 30 | | [MIP107: Protocol Scope Bounded Mutable Alignment Artifact](https://mips.makerdao.com/mips/details/MIP107) | Defines the Protocol Scope, which covers all processes related to developing and maintaining NewChain and its core protocol, modules and smart contract ecosystem, and its bridges to other blockchains, etc. | 31 | | [MIP108: Accessibility Scope Bounded Mutable Alignment Artifact](https://mips.makerdao.com/mips/details/MIP108) | Defines the Accessibility Scope, which covers accessibility and distribution efforts, and regulates user-facing frontends of MakerDAO Core and SubDAOs | 32 | | [MIP113: Governance Scope Bounded Mutable Alignment Artifact](https://mips.makerdao.com/mips/details/MIP113) | Defines the Governance Scope, which covers rules that regulate the critical balance of power, and adjudicate on appeals processes related to misalignment in the ecosystem | 33 | 34 | >Page last reviewed: 2023-05-22 35 | >Next review due: 2023-07-22 36 | 37 | 38 | 39 | 40 | -------------------------------------------------------------------------------- /parameter-index/debt-auction/param-auction-duration-flop.md: -------------------------------------------------------------------------------- 1 | 2 | # Debt Auction Duration 3 | 4 | >**Alias:** N/A 5 | >**Parameter Name:** `tau` 6 | >**Containing Contract:** `MCD_FLOP` 7 | >**Scope:** System 8 | >**Technical Docs:** [Flop Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/system-stabilizer-module/flop-detailed-documentation) 9 | 10 | ## Description 11 | The Debt Auction Duration parameter allows governance to control the maximum lifetime of a Debt Auction. A Debt Auction can end before this maximum duration is reached if the [Bid Duration](param-bid-duration-flop.md) timer expires without any additional bids. 12 | 13 | Debt Auctions are used to recapitalize the Maker Protocol by minting and auctioning off MKR for a fixed amount of DAI. In this process, Keepers bid the amount of MKR they are willing to accept for a fixed amount of DAI that they provide. 14 | 15 | {% hint style="info" %} 16 | 17 | **Example** 18 | 19 | _Debt Auction Bid Duration_ = 300 seconds 20 | _Debt Auction Duration_ = 24 hours 21 | 22 | **Scenario 1 - Limited by Bid Duration** 23 | 1. A Debt Auction has been triggered and 3 hours pass with no bid. 24 | 2. Keeper A offers to take 20 MKR in exchange for 100 DAI at the 3-hour mark. 25 | 3. Keeper B has 300 seconds in which to offer a more attractive bid or else Keeper A will win the auction. 26 | 27 | 28 | **Scenario 2 - Limited by Auction Duration** 29 | 1. A Debt Auction has been triggered and 23 hours and 59 minutes pass with no bid. 30 | 2. Keeper A offers to take 20 MKR in exchange for 100 DAI at 23 hours and 59 minutes into the auction. 31 | 3. Keeper B has 60 seconds in which to offer a more attractive bid or else Keeper A will win the auction. 32 | 33 | {% endhint %} 34 | 35 | ## Purpose 36 | The Debt Auction Duration parameter allows Maker Governance to adjust the maximum duration for debt auctions in order to ensure robust keeper participation. It also helps to ensure a predictable time frame for the protocol to recover from an undercollateralized state. 37 | 38 | ## Trade-offs 39 | The Debt Auction Duration makes a trade-off between ensuring enough time for keepers to deploy their capital while limiting their market risk. A larger Debt Auction Duration gives keepers more time to participate in auctions. A smaller Debt Auction Duration means that keepers are less likely to be affected by negative price movements of the MKR Token during the auction process. Maximizing the number of participating bidders helps ensure that auctions are efficient and less MKR is minted. 40 | 41 | A Debt Auction Duration that is too large could result in a situation where there are many auctions happening simultaneously. If the Debt Auction Duration is too small, then keepers may not have sufficient time to organize their resources and place bids. Either of these situations could result in inefficient auctions that increase the amount of MKR that is minted. 42 | 43 | The parameter will also have an effect on how long it takes to recapitalize the Maker Protocol in the event that the protocol ends up with bad debt, which may be important depending on the severity of the situation. 44 | 45 | ## Changes 46 | Adjusting the Debt Auction Duration parameter is a manual process that requires an executive vote. Changes to the Debt Auction Duration are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 47 | 48 | **Why increase this parameter?** 49 | Maker Governance may wish to increase the Debt Auction Duration if too few keepers are participating in debt auctions to encourage greater participation. 50 | 51 | **Why decrease this parameter?** 52 | Maker Governance may wish to decrease the Debt Auction Duration if the auctions are so long that keepers almost always make losses. If there are too many overlapping auctions, it may be desirable to decrease this parameter. 53 | 54 | ## Considerations 55 | Debt Auction Duration is always lower bounded by the Debt Auction Bid Duration i.e. the time period before which a bid expires. If it is set lower than the Debt Auction Bid Duration, it will render that parameter unnecessary since the auction will end before a bid expires. 56 | 57 | For example, if Debt Auction Bid Duration is 1 hour and Debt Auction Duration is 30 minutes, then the auction will only last 30 minutes, making the Debt Auction Bid Duration irrelevant. 58 | 59 | The [Surplus Auction Duration](../surplus-auction/param-auction-duration-flap.md) parameter fulfills the same role as this parameter in Surplus Auctions. 60 | 61 | >Page last reviewed: 2022-12-05 62 | >Next review due: 2023-12-05 63 | 64 | -------------------------------------------------------------------------------- /parameter-index/archive/param-bid-duration-flap.md: -------------------------------------------------------------------------------- 1 | # Bid Duration (Flap) 2 | 3 | >**Alias:** N/A 4 | >**Parameter Name:** `ttl` 5 | >**Containing Contract:** `MCD_FLAP` 6 | >**Scope:** System 7 | >**Technical Docs:** [Flap Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/system-stabilizer-module/flap-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Surplus Auction Bid Duration parameter allows governance to control how soon after a successful bid a Surplus Auction will end. Further bids reset this timer, extending the auction. A surplus auction can extend up to a maximum time which is set by the [Surplus Auction Duration](param-auction-duration-flap.md) parameter at which point the auction will end regardless of the Bid Duration timer. 12 | 13 | Surplus auctions are used to auction off excess DAI in fixed lots for a variable bid of MKR, which is then burned. In this process, keepers bid on how much MKR they are willing to pay for a fixed amount of DAI. 14 | 15 | {% hint style="info" %} 16 | 17 | **Example** 18 | 19 | _Surplus Bid Duration_ = 300 seconds 20 | _Surplus Auction Duration_ = 24 hours 21 | 22 | 1. A surplus auction is triggered and 3 hours pass with no bid. 23 | 2. Keeper A bids 10 MKR in exchange for 100 DAI at the 3-hour mark. 24 | 3. Keeper B has 300 seconds in which to offer a more attractive bid or else Keeper A will win the auction. 25 | 4. Keeper B bids 11 MKR in exchange for 100 DAI at 23 hours and 59 minutes into the auction. 26 | 5. Keeper A has 60 seconds to offer a more attractive bid or else Keeper B will win the auction. 27 | 28 | {% endhint %} 29 | 30 | ## Purpose 31 | 32 | Adjusting the Surplus Auction Bid Duration parameter allows Maker Governance to maximize the total MKR burned by ensuring sufficient competition among keepers. 33 | 34 | ## Trade-offs 35 | 36 | When bidding, keepers take a risk that the MKR-DAI price will change negatively (for them) during the auction's duration. If this happens, they can lose money. 37 | 38 | A small Surplus Auction Bid Duration lessens the risk that the market will move while the auction is in progress. Since the risk is lower, keepers can submit more aggressive bids which can result in more MKR being burned. However, if the Surplus Auction Bid Duration is too small, there may not be enough time for keepers to organize funds and participate in such auctions. In the extreme case, an auction with only one bidder will result in arbitrarily low MKR bids and a loss of value for the Maker Protocol. 39 | 40 | A small Surplus Auction Bid Duration also increases the risk of a more severe loss of value in the case of blockchain congestion. Rising gas prices may lock out keepers either due to technical issues or due to the additional fixed cost of gas. 41 | 42 | A larger Surplus Auction Bid Duration gives keepers more time to participate in auctions, hopefully encouraging a higher number of bidders. However, if the Surplus Auction Bid Duration is too large, there may be bids for minimal amounts of MKR to safeguard against price volatility during the Surplus Auction Bid Duration period. Realistically priced bids would only appear when the auction end (determined by the [Surplus Auction Duration](param-auction-duration-flap.md)) is closer than the Surplus Auction Bid Duration period. In situations where the price of MKR is dropping, this would lead to less MKR being burned than with a smaller Surplus Auction Bid Duration. 43 | 44 | ## Changes 45 | 46 | Adjusting the Surplus Auction Bid Duration parameter is a manual process that requires an executive vote. Changes to the Surplus Auction Bid Duration are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 47 | 48 | **Why increase this parameter?** 49 | Maker Governance may wish to increase the Surplus Auction Bid Duration to encourage greater participation if they are concerned about blockchain congestion or if too few keepers are participating in surplus auctions. 50 | 51 | **Why decrease this parameter?** 52 | Maker Governance may wish to decrease the Surplus Auction Bid Duration if keepers are submitting low bids due to volatility in the price of MKR during the Surplus Bid Duration period. 53 | 54 | ## Considerations 55 | 56 | Surplus Auction Bid Duration is always upper-bounded by the [Surplus Auction Duration](param-auction-duration-flap.md). If it is set higher than the total auction duration, it will have no effect. 57 | 58 | The [Debt Auction Bid Duration](../debt-auction/param-auction-duration-flop.md) parameter fulfills the same role as this parameter in Debt Auctions. 59 | 60 | 61 | >Page last reviewed: 2022-11-18 62 | >Next review due: 2023-11-18 63 | -------------------------------------------------------------------------------- /parameter-index/debt-auction/param-bid-duration-flop.md: -------------------------------------------------------------------------------- 1 | # Bid Duration (Flop) 2 | 3 | >**Alias:** N/A 4 | >**Parameter Name:** `ttl` 5 | >**Containing Contract:** `MCD_FLOP` 6 | >**Scope:** System 7 | >**Technical Docs:** [Flop Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/system-stabilizer-module/flop-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Debt Auction Bid Duration parameter (`ttl`) allows governance to control how soon after a successful bid a Debt Auction will end. Further bids reset this timer, extending the auction. A debt auction can extend up to a maximum time which is set by the [Flop Duration](param-auction-duration-flop.md) parameter, at which point the auction will end regardless of the Bid Duration timer. 12 | 13 | Debt auctions are used to recapitalize the system by minting and auctioning off MKR for a fixed amount of Dai. In this process, keepers bid on how little MKR they are willing to accept for a fixed amount of Dai that they provide. 14 | 15 | {% hint style="info" %} 16 | 17 | **Example** 18 | 19 | _Debt Auction Bid Duration_ = 300 seconds 20 | _Debt Auction Duration_ = 24 hours 21 | 22 | **Scenario 1 - Limited by Bid Duration** 23 | 1. A Debt Auction has been triggered and 3 hours pass with no bid. 24 | 2. Keeper A offers to take 20 MKR in exchange for 100 DAI at the 3-hour mark. 25 | 3. Keeper B has 300 seconds in which to offer a more attractive bid or else Keeper A will win the auction. 26 | 27 | 28 | **Scenario 2 - Limited by Auction Duration** 29 | 1. A Debt Auction has been triggered and 23 hours and 59 minutes pass with no bid. 30 | 2. Keeper A offers to take 20 MKR in exchange for 100 DAI at 23 hours and 59 minutes into the auction. 31 | 3. Keeper B has 60 seconds in which to offer a more attractive bid or else Keeper A will win the auction. 32 | 33 | {% endhint %} 34 | 35 | ## Purpose 36 | 37 | Adjusting the Debt Auction Bid Duration parameter allows Maker Governance to minimize the total MKR minted by ensuring sufficient competition among Keepers. 38 | 39 | ## Trade-offs 40 | 41 | When bidding, Keepers take a risk that the MKR-DAI price will change negatively (for them) during the auction's duration; if this happens, they can lose money. 42 | 43 | A small Debt Auction Bid Duration means that keepers take less risk that the market will move while the auction is in progress. Since the risk is lower, keepers can submit more aggressive bids which can result in less MKR being minted. However, if the Debt Auction Bid Duration is too small, there may not be enough time for keepers to organize funds and participate in such auctions before they conclude. In the extreme, an auction with only one bidder will result in arbitrarily high MKR bids and a loss of value for the Maker Protocol. 44 | 45 | A small Debt Auction Bid Duration also increases the risk of a more severe loss of value in the case of blockchain congestion: Rising gas prices may lock out keepers either due to technical issues or due to the additional fixed cost of gas. 46 | 47 | A larger Debt Auction Bid Duration gives keepers more time to participate in auctions, hopefully encouraging a higher number of bidders. If the Debt Auction Bid Duration is too large, there may be bids for very high amounts of MKR to safeguard against price volatility during the Debt Auction Bid Duration period. Realistically priced bids would only appear when the auction end (determined by the [Auction Duration](param-auction-duration-flop.md) is closer than the Debt Auction Bid Duration period. In situations where the price of MKR is dropping, this would lead to more MKR being minted than with a smaller Debt Auction Bid Duration. 48 | 49 | ## Changes 50 | 51 | Adjusting the Debt Auction Bid Duration parameter is a manual process that requires an executive vote. Changes to the Flop Bid Duration are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 52 | 53 | **Why increase this parameter?** 54 | 55 | Maker Governance may wish to increase the Debt Auction Bid Duration if too few keepers are participating in debt auctions to encourage greater participation or if they are concerned about blockchain congestion. 56 | 57 | **Why decrease this parameter?** 58 | 59 | Maker Governance may wish to decrease the Debt Auction Bid Duration if keepers are submitting high bids due to volatility in the price of MKR during the Debt Auction Bid Duration period. 60 | 61 | ## Considerations 62 | 63 | Debt Auction Bid Duration is always upper-bounded by the total [Debt Auction Duration](param-auction-duration-flop.md). If it is set higher than the total auction duration, then it will have no effect. 64 | 65 | >Page last reviewed: 2022-11-16 66 | >Next review due: 2023-11-16 67 | 68 | 69 | 70 | 71 | -------------------------------------------------------------------------------- /delegation/delegate-expiration.md: -------------------------------------------------------------------------------- 1 | # Delegate Expiration 2 | 3 | MakerDAO's vote delegation system is based on VoteDelegate smart contracts, which can be generated by anyone through the Governance Portal by sending a transaction to the VoteDelegateFactory contract on Ethereum mainnet. VoteDelegate contracts expire annually by design, which requires both delegates and their delegators to migrate periodically. 4 | 5 | ## Expiration by design 6 | 7 | VoteDelegate contracts expire by design, as a means to protect the Maker protocol against stale MKR tokens participating in Maker governance. The design protects the Maker protocol against the following scenarios, for example: 8 | 9 | * A delegate with significant voting power turning malicious and with 'passive' MKR being delegated to them 10 | * A large delegator loses access to their wallet and now their MKR tokens are 'stuck' in a delegate contract without a way to undelegate, which can lead to unforeseen consequences in case of a delegate turning malicious 11 | 12 | VoteDelegate contracts expire exactly 365 days after its creation. The exact expiry date and time can be found on a delegate's profile page on the Governance Portal. This applies to both Recognized Delegates and Shadow Delegates. 13 | 14 | ## Migration for delegates 15 | Recognized Delegates that own a VoteDelegate contract that's nearing expiration will be shown a prominent banner on the Governance Portal, prompting the delegate to migrate. The banner will redirect them to [the migration page for delegates](https://vote.makerdao.com/migration/delegate). 16 | The delegate will be required to prepare a new address for creating the renewed delegate contract, since an address can only own one delegate contract (expired or not). The migration steps are as follows: 17 | 18 | * Step 1. Undelegate any of their own MKR holdings from their delegate contract 19 | * Step 2. Prepare a different Ethereum address that they own, that they will use to generate a new delegate contract. 20 | * Step 3. Submit this address through the Governance Portal UI to have it verified and linked to their prior delegate contract. This process might require the delegate to wait for a few hours since it involves some manual steps. NOTE: For users of the Gnosis Safe multisig wallet, the process will involve posting an on-chain transaction which needs to be manually shared with the MakerDAO DUX team through Discord. 21 | * Step 4. Connect this new Ethereum address to the Governance Portal, and click the banner to continue the migration process. You'll be asked to navigate to the account page and generate a new delegate contract. Once created, the migration is essentially completed. 22 | * Step 5. Delegate any of their own MKR holdings to the new delegate contract. 23 | * Step 6. Encourage their delegators to migrate their delegated MKR. 24 | Once a delegate successfully finished their migration, their old and new addresses are linked and the Governance Portal UI will display their prior delegate profile in aggregation. Their prior profile markdown, performance metrics, voting history and commenting history will be visible on their new delegate contract profile page. A successful migration also triggers migration prompts for their delegators who still have MKR delegated to the old delegate contract. 25 | 26 | The links between the old and new delegate contract owner addressess can be found in a [mapping file](https://github.com/makerdao/governance-portal-v2/blob/master/modules/migration/delegateAddressLinks.ts) on the GitHub repository. This mapping file is used by the Governance Portal to show the metadata of Recognized Delegates on all their associated old and new delegate contracts. The file is also used by various other teams (eg. DIN). This file can be considered the source of truth for determining which EOAs (user-owned addressess) are associated with a Recognized Delegate. The file is open-source and can be viewed by anyone. 27 | 28 | ## Migration for delegators 29 | 30 | Delegators that have delegated MKR to a delegate contract which has been migrated OR expired will be shown a prominent banner on the Governance Portal, prompting the delegator to migrate. On [the migration page for delegators](https://vote.makerdao.com/migration/delegator) all expired and about-to-expire delegate contracts are shown, including the total MKR amount delegated by the user. It also displays the renewed delegate contracts. 31 | 32 | Through the UI the delegators are guided through the process of undelegating from the old contracts, and delegating to the new contracts. Note: This also involved creating token approval transactions in case a user is delegating/undelegating from a VoteDelegate contract the first time. 33 | 34 | >Page last reviewed: 2022-07-13 35 | >Next review due: 2023-07-13 36 | 37 | 38 | -------------------------------------------------------------------------------- /parameter-index/collateral-auction/param-breaker-price-tolerance.md: -------------------------------------------------------------------------------- 1 | # Breaker Price Tolerance 2 | 3 | >**Alias:** Breaker Price Tolerance 4 | >**Parameter Name:** `tolerance` 5 | >**Containing Contract:** `CLIPPER_MOM` 6 | >**Scope:** Vault Type (Ilk) 7 | >**Technical Docs:** - 8 | 9 | ## Description 10 | 11 | The Breaker Price Tolerance parameter is a tool for mitigating the risk of a major move in the next OSM price for a particular vault type. The Breaker Price Tolerance is expressed as a number between zero and one. Practically, this parameter allows anyone to trigger a circuit breaker that halts new liquidation auctions if the following equation is true: 12 | 13 | ```text 14 | next_oracle_price < current_oracle_price * breaker_price_tolerance 15 | ``` 16 | 17 | The right side of the equation represents the minimum acceptable price for the next OSM reading. Any price below that product could result in the breaker being called for affected vault types. 18 | 19 | It may be easier to understand this parameter in terms of the maximum percentage drop allowed: 20 | 21 | ```text 22 | (1 - (breaker_price tolerance)) * 100 = Maximum Percentage Drop 23 | ``` 24 | 25 | If Governance feels the protocol should be protected from a 40% drop in a particular vault type, then the appropriate setting for the Breaker Price Tolerance parameter is 0.6. 26 | 27 | In the above example, anything past a 40% decline from the current OSM price could result in the breaker being triggered, preventing liquidations. 28 | 29 | Note that the breaker is not automatic and needs to be triggered by some entity (either human or bot). 30 | 31 | ## Purpose 32 | 33 | The Breaker Price Tolerance is designed to protect against a sharp decline in the OSM price feed. Liquidations 2.0 increases the severity of attacks on the OSM price feed because of the switch to falling price auctions. Because auctions start at their highest price point and move downward, catastrophic losses may occur if the auction were to start significantly below market rates. 34 | 35 | While this parameter is designed to combat an Oracle attack, it also offers a further safety net during a legitimate market downturn. 36 | 37 | ## Trade-offs 38 | 39 | Like many parameters, Governance should avoid setting the Breaker Price Tolerance too far in either extreme. 40 | 41 | If set too high this parameter becomes too sensitive, risking breaker shut-offs during normal market movements and adding a risk of collateral continuing to fall while liquidations are prematurely paused. This may result in significant bad debt for the Maker Protocol. 42 | 43 | Conversely, setting the Breaker Price Tolerance too low is similar to not having one in the first place. Because the starting price for each auction is based on the OSM price, bad debt can accrue quickly if there is a sharp decline in the OSM price feed combined with a Breaker Price Tolerance that is set too low. 44 | 45 | ## Changes 46 | 47 | Adjusting the Breaker Price Tolerance parameter is a manual process that requires an executive vote. Changes to the Breaker Price Tolerance are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 48 | 49 | **Why increase this parameter?** 50 | 51 | The Breaker Price Tolerance parameter should be increased when Governance wants to limit the percentage drop of a particular asset before the breaker can be called. That at its most extreme (setting this parameter to 1.0), any price drop would enable the calling of the breaker. The closer the Breaker Price Tolerance parameter is set to one, the more likely it is that the breaker can be called. 52 | 53 | **Why decrease this parameter?** 54 | 55 | If Governance wishes to allow for more price volatility from a particular vault type, a decrease in the Breaker Price Tolerance parameter can be pursued. As the Breaker Price Tolerance parameter approaches zero, the underlying collateral would need to experience almost a 100% drawdown before liquidations can be halted. 56 | 57 | ## Considerations 58 | 59 | Re-enabling liquidation auctions on a vault type after the breaker has been triggered requires an executive vote. Importantly though, re-enabling liquidation auctions _does not_ require governance to wait for the GSM Pause Delay. 60 | 61 | If the conditions for its execution are satisfied and the breaker is triggered, it will set the liquidation stage for the vault type to 1 (new liquidations disabled) as per the [Four-Stage Liquidation Circuit Breaker](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation#four-stage-liquidation-circuit-breaker). 62 | 63 | During an [Emergency Shutdown](https://docs.makerdao.com/smart-contract-modules/shutdown), the Breaker Price Tolerance parameter is not relevant as no new auctions may be triggered. 64 | 65 | >Page last reviewed: 2022-11-07 66 | >Next review due: 2023-11-07 67 | 68 | 69 | -------------------------------------------------------------------------------- /meta/writing-guide.md: -------------------------------------------------------------------------------- 1 | # Writing Guide 2 | 3 | This guide intends to inform authors of the most effective way to write for the Maker Operational Manual, and other documentation. 4 | 5 | ## User Needs 6 | 7 | ### Identifying Needs 8 | 9 | Everything we publish should meet a user need. A user need is what somebody wants to achieve when they visit our documentation. Ideally, this should be based on evidence and not assumption. 10 | 11 | It can be easy to make assumptions about users that may be wrong. Users will have different levels of knowledge and education, backgrounds and needs from our documentation. 12 | 13 | To help define your users’ needs, put yourself in the position of the user. Ask yourself who they are, what they need, and why they need it. This will improve your understanding of what they want or need to achieve when visiting our documentation. 14 | 15 | When writing and structuring documentation, think about how a user need could be met. Try not to include a solution when defining your user need. It can prevent you from finding a better way of meeting the user need.  16 | 17 | ### Meeting Needs 18 | 19 | Users want to be able to find the information they need as quickly as possible. 20 | 21 | You should prioritise the most important things your users need to know by using the inverted pyramid structure. 22 | 23 | People do not usually read content unless they are looking for information, so if what you have written does not meet the user need, you can probably leave it out. You do not need to tell them everything or overwhelm them with information. 24 | 25 | ## Structuring Content 26 | 27 | **Place information in order of importance to the user.** 28 | 29 | The most important information in our documentation must be at the start – this is called frontloading. 30 | 31 | We use the inverted pyramid to achieve this, placing information in order of importance on the page. This is the best practice style when writing documentation. 32 | 33 | The main information of the content – who, why, what, where, when and how – appears in the first paragraphs so that most users will see it. 34 | 35 | The inverted pyramid structure is: 36 | 37 | 1. most important information 38 | 2. important details 39 | 3. other general or background information 40 | 41 | ### Paragraphs and Sentences 42 | 43 | As with the overall structure, each paragraph and sentence should be frontloaded with the most important information at the start. 44 | 45 | When writing documentation, your paragraphs should: 46 | 47 | * have no more than four sentences that follow a logical order 48 | * begin with the most important information for that paragraph, meaning readers can skim through the information 49 | * make complete sense on their own 50 | * cover one subject 51 | 52 | Individual sentences should be no longer than 25 words. If they are any longer, they may need to be divided into two. 53 | 54 | ## Plain English 55 | 56 | Everything we publish should be in plain English. This means using clear language that all readers can understand. 57 | 58 | Research shows that most people prefer sentences written in plain English. This includes expert users with a high level of specialist knowledge. The more complex the issue, the greater the preference for plain language. 59 | 60 | ### Be concise 61 | * limit each paragraph to four short sentences 62 | * stick to one idea or theme per paragraph 63 | * avoid complicated sentence structures 64 | * break up large blocks of text with subheadings 65 | 66 | 67 | ### Write simply 68 | 69 | Do not use formal or long words when easy or short words will do. If you cannot avoid technical terms, explain them in the text or on a glossary page. You should also ensure that any acronyms or abbreviations are written out in full for the first use in each section. 70 | 71 | ### Use the active voice 72 | Always use the active voice, not the passive. This is when the subject of the sentence is doing something, rather than having something done to them. 73 | 74 | The active voice makes sentences shorter and clearer. 75 | 76 | ### Be clear 77 | Sentences that can be read in several different ways may be misleading. 78 | 79 | Make sure that there is no ambiguity in your writing, and that your meaning is clear. 80 | 81 | **Bad** 82 | “Taylor worked on the development stage of the project and is now part of the policy group with responsibility for legislation.” 83 | 84 | The sentence reads as though the policy group is responsible for legislation. In fact, it is Taylor. 85 | 86 | **Good** 87 | “Taylor worked on the development stage of the project and is now part of the policy group, where she has responsibility for legislation.” 88 | 89 | ### Editing tools 90 | 91 | [Hemingway Editor](https://hemingwayapp.com/) is an online tool that gives your writing a readability grade. It will report on its complexity and make suggestions for improvements. Aim for grade 9. -------------------------------------------------------------------------------- /module-index/module-psm.md: -------------------------------------------------------------------------------- 1 | # Peg Stability 2 | 3 | >**Alias:** PSM 4 | >**Contract Name:** `DssPsm` 5 | >**Scope:** Each PSM interacts with a single underlying vault type. 6 | 7 | ## Description 8 | 9 | A Peg Stability Module allows users to swap a given collateral type directly for DAI at a fixed rate, rather than borrowing DAI. The PSM contract was designed with stablecoin collateral in mind, allowing users to swap other stablecoins for DAI at a fixed rate to aid with keeping DAI pegged to 1 dollar. 10 | 11 | A PSM operates similarly to a regular vault type with a zero stability fee and a liquidation ratio of 100% that can only be accessed through a user-facing smart contract containing the relevant swap functions. Unlike the case with regular vaults, users of PSM don't retain ownership of the asset and borrow DAI, instead they swap the asset directly for DAI. 12 | 13 | As an example, given the existence of a USDC-backed PSM, a user would be able to swap 100 USDC for 100 DAI \(minus fees\) using the USDC-backed PSM without taking on any debt or needing to manage a Maker vault. 14 | 15 | ## Purpose 16 | 17 | The PSM contract was primarily created to help keep the DAI peg close to $1 during times where DAI demand outstrips DAI supply. 18 | 19 | Initially, low liquidation ratio stablecoin vaults were used for this purpose, but this solution proved difficult for Governance to administer due to the risk of stability fees pushing vaults below the 100% collateralization ratio. 20 | 21 | The PSM contract allows Governance to collect fees on stablecoins at the point of swap, rather than over time. 22 | 23 | ## Trade-offs 24 | 25 | A PSM creates the same danger as low liquidation ratio stablecoin vault types: the Maker Protocol will take on a large amount of stablecoin collateral at times where DAI demand outstrips DAI supply. This is usually cited to be a risk due to the centralization of other stablecoins and the possibility of regulatory action targeting Maker specifically. The risk of regulatory action may be slightly greater with a PSM than the alternative because the stablecoin collateral created through a PSM is effectively owned by the Maker Protocol, rather than being owned by a user using it as collateral for a loan of DAI. 26 | 27 | Additionally, the Maker Protocol bears the risk of the underlying collateral stablecoin losing its peg \(though this is no different from regular vault-types with stablecoin collateral.\) 28 | 29 | On the other hand, a PSM offers several advantages: 30 | 31 | * Increased DAI stability due to the instant arbitrage opportunity when the DAI price diverges from the price of the collateral type underlying the PSM. 32 | * Fees are taken upfront on each swap to and from DAI. Because a PSM has no slippage, it's able to attract respectable trading volume. 33 | * There is no requirement to micromanage parameters \(via governance actions\) to ensure continued functioning, in contrast to low liquidation ratio stablecoin vaults. 34 | 35 | ## Key Parameters 36 | 37 | Under the hood, a PSM is just a wrapper contract around a privileged vault type in the Maker Protocol. All the parameters that apply to vault types also apply to a PSM. However, a stablecoin PSM should always have a Stability Fee of 0% and a Liquidation Ratio of 100%. 38 | 39 | ### Debt Ceiling \(line\) 40 | 41 | The Debt Ceiling refers to the maximum amount of debt the PSM can accrue. 42 | 43 | Note that although users do not have a debt when using the PSM to trade between DAI and the collateral asset, the Maker Protocol _does_ accrue a DAI debt which is backed by the asset users trade into the PSM in exchange for DAI. 44 | 45 | ### Fee In \(tin\) 46 | 47 | The percentage fee applied when trading the collateral asset into the PSM in exchange for DAI. 48 | 49 | ### Fee Out \(tout\) 50 | 51 | The percentage fee applied when trading DAI into the PSM in exchange for the collateral asset. 52 | 53 | ## User Interaction 54 | 55 | Users can directly call the swap functions on a PSM contract, but it is hoped that PSMs will be integrated into DEX aggregators such that trades will take place when a PSM can offer the best market price. 56 | 57 | ## Considerations 58 | 59 | It's important to note that the amount of trades a PSM can offer is limited by its debt ceiling and the currently deposited amount of collateral tokens. A PSM cannot offer DAI in trade if its debt ceiling has been reached. Likewise, a PSM cannot offer the collateral asset in trade if no collateral tokens exist inside the PSM. 60 | 61 | A PSM is a regular vault type with the exception that it can only be accessed by a specific wrapper contract. The wrapper contract defines trading functions to users and levies the trading fees set by Governance. 62 | 63 | A PSM is only really possible with an asset that is pegged to the same asset as DAI. Offering 1-to-1 swaps requires a liquidation ratio of 100%. If a PSM with a non-stable asset is attempted, it would run the risk of becoming undercollateralized as soon as the market price of the collateral asset decreased. 64 | 65 | >Page last reviewed: 2022-09-18 66 | >Next review due: 2023-09-18 67 | 68 | -------------------------------------------------------------------------------- /parameter-index/vault-risk/param-debt-ceiling.md: -------------------------------------------------------------------------------- 1 | # Debt Ceiling 2 | 3 | >**Alias:** N/A 4 | >**Parameter Name:** `line` 5 | >**Containing Contract:** `MCD_VAT` 6 | >**Scope:** Vault Type (Ilk) 7 | >**Technical Docs:** [Vat Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/core-module/vat-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Debt Ceiling parameter controls the maximum amount of DAI that can be minted using a specific vault type across all vault users. If a user tries to mint DAI and the amount of DAI minted would put the vault type's amount of DAI minted above its Debt Ceiling, the transaction will fail and no DAI will be minted. 12 | 13 | Each vault type has its own Debt Ceiling that can be adjusted by Maker Governance. Note that the Debt Ceiling applies collectively to all vaults created using a specific vault type, rather than to individual vaults. 14 | 15 | Additionally, there is a [Global Debt Ceiling](../core/param-global-debt-ceiling.md) parameter that is not covered in this entry. For a user to mint DAI from their vault, there must be space available in both the vault type's Debt Ceiling and the Global Debt Ceiling. 16 | 17 | 18 | ## Purpose 19 | 20 | The primary purpose of the Debt Ceiling parameter is to allow Governance to control the amount of DAI that can be created using a certain vault type. Controlling the amount of DAI minted from a vault type limits the risk exposure to the collateral used within that vault type. It also limits the risk from the combination of system parameters that are used within a vault type - for example, a very low [liquidation ratio](param-liquidation-ratio.md) combined with high [stability fees](param-stability-fee.md). 21 | 22 | ## Trade-offs 23 | 24 | Increasing the Debt Ceiling parameter for a vault type allows more DAI to be minted using that vault type. In most cases, this is positive as Maker Governance will almost always want more DAI to exist as long as the price peg to $1 can be maintained. 25 | 26 | However, increasing the Debt Ceiling and allowing DAI to be collateralized heavily by a single asset increases the risk from a black swan event that is localized to that asset. 27 | 28 | Having a large amount of 'open space' between the Debt Ceiling for a vault type and the current amount of DAI minted using that vault type represents a risk. In the event of a significant drop in the price of the collateral used within this vault type, holders of that collateral can shift the loss onto the Maker protocol by minting DAI and leaving Maker to deal with the bad collateral. This risk is known as the 'OSM Timing Attack' because it is only possible due to the one hour delay on price updates from the OSM (Oracle Security Module.) 29 | 30 | Leaving a large amount of 'open space' in the Debt Ceiling for a vault type also means that the DAI supply can change rapidly in a way that may harm the DAI price peg. 31 | 32 | ## Changes 33 | 34 | Adjusting the Debt Ceiling parameter for a specific vault type is a manual process that requires an executive vote. Changes to Debt Ceiling parameters are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 35 | 36 | Some vaults use the [Debt Ceiling Instant Access Module (DC-IAM)](../../module-index/module-dciam.md) that can change the debt ceiling parameter according to pre-set parameters without requiring an executive vote or being subject to the GSM Pause Delay. 37 | 38 | **Why increase a Debt Ceiling parameter?** 39 | 40 | The primary reason for increasing the Debt Ceiling for a vault type is to allow more DAI to be minted using that vault type. This is usually positive, because it means additional fees captured by the protocol, and increased DAI supply. 41 | 42 | This reason is usually only valid if it is predicted that the current Debt Ceiling will be reached and will prevent further minting. 43 | 44 | **Why decrease a Debt Ceiling parameter?** 45 | 46 | The primary reason for decreasing the Debt Ceiling for a Vault type is to decrease the risk and impact of the 'OSM Timing Attack' described above. 47 | 48 | A Debt Ceiling can also be lowered below the currently utilized amount of debt for the vault type to deprecate or temporarily prevent DAI from being minted using that vault type. 49 | 50 | The parameter can also be used to encourage diversification between vault types that are based on similar assets. For example, decreasing the Debt Ceiling on PSM-USDC-A could be used to shift stablecoin usage towards PSM-GUSD-A or PSM-PAX-A. 51 | 52 | The Debt Ceiling might also be lowered as an attempt to affect monetary policy, though in the past Maker Governance has preferred to use the stability fee for this purpose. 53 | 54 | ## Considerations 55 | 56 | The Debt Ceiling for a vault type can be exceeded as stability fees accrue to vaults within that vault type. 57 | 58 | If a Debt Ceiling parameter for a vault type is dropped below the current amount of DAI minted using that vault type, this does not have any negative effects beyond preventing further mints from vaults using that vault type. 59 | 60 | >Page last reviewed: 2022-11-08 61 | >Next review due: 2023-11-08 62 | 63 | -------------------------------------------------------------------------------- /parameter-index/collateral-auction/param-auction-price-multiplier.md: -------------------------------------------------------------------------------- 1 | # Auction Price Multiplier 2 | 3 | >**Alias:** 4 | >**Parameter Name:** `buf` 5 | >**Containing Contracts:** `MCD_CLIP_$ILK` 6 | >**Scope:** Vault Type (Ilk) 7 | >**Technical Docs:** [Liquidations 2.0](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) 8 | 9 | 10 | ## Description 11 | 12 | The Auction Price Multiplier parameter is a multiplier that is applied to the starting price of a collateral auction. 13 | 14 | Each vault type has its own Auction Price Multiplier that can be adjusted by Maker Governance separately. This multiplier is intended to be greater than 1.0x because Liquidations 2.0 uses falling price auctions. This means that it is generally preferable for the auction price to begin above the market price and then fall to the correct value over some amount of time. 15 | 16 | {% hint style="info" %} 17 | 18 | **Example** 19 | 20 | _Auction Price Multiplier_ = 1.6x 21 | _OSM Price at Liquidation_ = $100 22 | 23 | 1. User A owns a vault with a liquidation price of $120. 24 | 2. The ETH OSM receives a price update for $100 and liquidation of User A's vault takes place. 25 | 3. An auction of User A's collateral begins with a starting price of $160 due to the _Auction Price Multiplier_ of 1.6x. 26 | 27 | {% endhint %} 28 | 29 | ## Purpose 30 | 31 | In the general case, when falling price collateral auctions commence, the Auction Price Multiplier stops the Maker Protocol from beginning the auction lower than the current market price. An ideal outcome for the Maker Protocol is for collateral auctions to start slightly above the market price and then fall to the market price as quickly as possible. 32 | 33 | ## Trade-offs 34 | 35 | In a situation where a drop in collateral prices triggers liquidations but is swiftly followed by an increase in collateral prices, the Protocol runs the risk of starting an auction at a lower price than the market price. This is bad for the vault holder because the collateral will be sold at a discount. If this discount exceeds the liquidation penalty, this can also be bad for the Maker Protocol. An Auction Price Multiplier greater than 1.0x reduces the likelihood of this situation, as the starting auction price is artificially increased. 36 | 37 | The advantage of the Auction Price Multiplier greater than 1.0x is best illustrated with an example. 38 | 39 | {% hint style="info" %} 40 | 41 | **Example** 42 | 43 | ETH drops from $1000 to $800 and liquidations are triggered for User A's vault. 44 | 45 | Due to the OSM (Oracle Security Module), these liquidations are delayed by one hour. In that one hour, the ETH price then increases to $900. 46 | 47 | _ETH OSM Price at Liquidation_ = $800 48 | _ETH Market Price during Auction_ = $900 49 | 50 | **Scenario 1 - 1.0x Mulitplier** 51 | 52 | _Starting Auction Price_ = $800 53 | 54 | 1. Collateral Auction for User A's ETH begins at a price of $800. 55 | 2. Auction sells User A's ETH at a price of $800, $100 below the ETH market price. 56 | 3. Vault owner has lost a larger percentage of their collateral in the auction. 57 | 58 | **Scenario 2 - 1.2x Multiplier** 59 | 60 | _Starting Auction Price_ = $960 61 | 62 | 1. Collateral Auction for User A's ETH begins at a price of $960. 63 | 2. Auction price drops over time and reaches $900. 64 | 3. Auction sells User A's ETH at a price close to $900, the market price. 65 | 66 | {% endhint %} 67 | 68 | 69 | The downside to a higher Auction Price Multiplier is that, in a situation where the market price of a collateral type _continues_ to drop, the falling price auction may never reach the market price before it expires. In this situation, the sale of the collateral is delayed and the result is an overall worse price than if the Auction Price Multiplier had been lower. 70 | 71 | This negative effect of the Auction Price Multiplier can be mitigated by setting an [Auction Price Function](param-auction-price-function.md) that complements the multiplier. For example, by setting a higher Auction Price Multiplier in combination with an exponentially decreasing Auction Price Function. 72 | 73 | ## Changes 74 | 75 | Adjusting an Auction Price Multiplier parameter for a specific vault type is a manual process that requires an executive vote. Changes to Auction Price Multiplier parameters are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 76 | 77 | **Why increase this parameter?** 78 | 79 | An Auction Price Multiplier parameter might be increased for a specific vault type if in the general case auctions were starting at prices below the market price. 80 | 81 | **Why decrease this parameter?** 82 | 83 | An Auction Price Multiplier parameter might be decreased for a specific vault type if in the general case auctions were being regularly reset due to the price reaching the [Max Auction Drawdown](max-auction-drawdown.md) price. 84 | 85 | ## Considerations 86 | 87 | The Starting Price for an auction is calculated using the OSM (Oracle Security Module) price feed multiplied by the Auction Price Multiplier. 88 | 89 | >Page last reviewed: 2022-11-10 90 | >Next review due: 2023-11-10 91 | -------------------------------------------------------------------------------- /parameter-index/core/param-gsm-pause-delay.md: -------------------------------------------------------------------------------- 1 | # GSM Pause Delay 2 | 3 | >**Alias:** GSM, Pause, Governance Security Delay 4 | >**Parameter Name:** `delay` 5 | >**Containing Contract:** `MCD_PAUSE` 6 | >**Scope:** System 7 | >**Technical Docs:** [Pause Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/governance-module/pause-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The GSM (Governance Security Module) Pause Delay parameter sets the minimum amount of time after an executive vote has passed before changes will come into effect in the Maker Protocol. Once an executive spell passes, the GSM Pause Delay must pass before the changes within that executive spell can affect the Maker Protocol. The Maker Protocol only has one GSM Pause Delay, and all parameter changes are subject to it. 12 | 13 | It is possible to move functionality outside of the GSM Pause Delay; however, this requires additional engineering work. In the past, this has been enabled for functionality that allowed Maker Governance to freeze or unfreeze the oracle prices, and freeze or unfreeze liquidations without waiting for the delay to elapse. A list of exceptional functionality can be found on the [GSM exceptions](../../governance/gsm-exceptions.md) page. 14 | 15 | The GSM Pause Delay is usually expressed in terms of hours. 16 | 17 | ## Purpose 18 | 19 | This parameter primarily exists to protect users of the Maker Protocol from a governance attack by malicious MKR Holders. In the event of a malicious proposal passing through governance, DAI Holders and Vault users would have a chance to sell their DAI or close their Vaults before the changes become active in the Maker Protocol. Additionally, this gives a minority of MKR a chance to cancel the malicious change or gracefully shutdown the Maker Protocol using the [Emergency Shutdown Module](https://docs.makerdao.com/smart-contract-modules/shutdown). 20 | 21 | It also gives users a chance to opt-out of the protocol in the event of non-malicious but disagreeable changes. 22 | 23 | ## Trade-offs 24 | 25 | A longer GSM Pause Delay gives non-malicious MKR Holders and users of the protocol more time to become aware of and react to a governance attack on the Maker Protocol. It also gives users additional time to opt-out in the event of non-malicious but disagreeable changes to the protocol, such as an increase in Liquidation Ratios that might cause the liquidation of a user's Vault. 26 | 27 | However, having a longer GSM also enforces a slower reaction time on Maker Governance as a whole, which creates risk in the event of time-critical issues such as: 28 | 29 | * Extreme market volatility. 30 | * Technical issues in the Maker Protocol. 31 | * Attack on the Oracles. 32 | * Extreme network congestion. 33 | 34 | Any of the above situations may require swift action from governance; however, the swiftest response still requires the GSM Pause Delay to pass before the changes go live in the Maker Protocol. 35 | 36 | ## Changes 37 | 38 | Adjusting the GSM Pause Delay parameter is a manual process that requires an executive vote. Changes to the GSM Pause Delay are subject to the pre-change GSM Pause Delay. 39 | 40 | **Why increase this parameter?** An increase to the GSM Pause Delay parameter should be considered if the risk of governance attack is considered especially high for whatever reason. In the past, the GSM Pause Delay has been increased due to the risk from flash loans combined with increasing liquidity of the MKR token on the open market. 41 | 42 | **Why decrease this parameter?** A decrease should be considered if time-critical governance actions are projected to be needed in the near future. For example, if extreme market volatility is expected, it may be beneficial to reduce the GSM Pause Delay temporarily to allow Governance to better react to the changing conditions. 43 | 44 | A decrease could also be considered if the risk of governance attack has been shown to be minimal. 45 | 46 | It is probably not advisable to reduce the GSM Pause Delay to zero permanently because it leaves the Maker Protocol vulnerable to Governance attacks. 47 | 48 | ## Considerations 49 | 50 | The main consideration when setting this parameter is how much time is required to rally a sufficient amount of MKR to cancel a malicious governance proposal in the event of a governance attack. 51 | 52 | In the event of a critical technical vulnerability being discovered and responsibly disclosed to the MakerDAO Protocol Engineering Core Unit, the [dark spell mechanism](https://mips.makerdao.com/mips/details/MIP15) may be employed to fix the exploit. The dark spell mechanism was introduced to help mitigate the risk of technical fixes being made to the protocol while subject to the GSM Pause Delay. If a technical fix to a critical vulnerability does not become active immediately, the vulnerability can be exploited before the fix goes live. 53 | 54 | The GSM Pause Delay does not apply to the [Emergency Shutdown Module](https://docs.makerdao.com/smart-contract-modules/shutdown). 55 | 56 | The GSM Pause Delay does not apply to 'cancel' spells (executive spells that cancel an existing executive vote that has passed but is awaiting the expiry of the GSM Pause Delay before it becomes active.) 57 | 58 | >Page last reviewed: 2022-11-04 59 | >Next review due: 2023-11-04 60 | 61 | -------------------------------------------------------------------------------- /parameter-index/core/param-system-surplus-buffer.md: -------------------------------------------------------------------------------- 1 | # Maximum System Surplus 2 | 3 | >**Alias:** Surplus Auction Buffer 4 | >**Parameter Name:** `hump` 5 | >**Containing Contract:** `MCD_VOW` 6 | >**Scope:** System 7 | >**Technical Docs:** [Vow Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/system-stabilizer-module/vow-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Maximum System Surplus parameter controls the maximum amount of DAI that can accrue to the protocol's balance from revenue before FLAP auctions are triggered. As revenue comes in, the total amount of DAI inside the System Surplus Buffer increases until it reaches: 12 | 13 | * Maximum System Surplus (`hump`) + Surplus Lot Size (`bump`)* 14 | 15 | At that point, a FLAP auction can be triggered and DAI is auctioned off for MKR. This purchased MKR is then burned. 16 | 17 | The Maker Protocol only has one System Surplus Buffer and the stability fees from all vaults accrue to it. Other revenues may also be deposited into the buffer by governance or external actors. 18 | 19 | The Maximum System Surplus is expressed in absolute rather than relative terms, so 1,000,000 DAI rather than 1% of the Total DAI Debt. 20 | 21 | ## Purpose 22 | 23 | In general, whenever the Maker Protocol accrues sufficient value in DAI, MKR is bought and burnt. Likewise, every time the system loses money (bad debt), it mints MKR, sells it, and buys DAI. The primary purpose of the System Surplus Buffer is to reduce the frequency that this occurs. This is beneficial to the protocol because each time an auction takes place (whether FLAP or FLOP), the auction is not perfectly efficient and the protocol loses some percentage of the auctioned value. 24 | 25 | In addition, the buffer provides a reserve of DAI which may be used by governance to fund the operations of Core Units and Oracle feeds without requiring the minting of MKR. 26 | 27 | ## Trade-offs 28 | 29 | Increasing the Maximum System Surplus allows the Maker Protocol to accrue a larger reserve of DAI before burning MKR. This larger reserve provides greater security for the protocol in the event of bad debt. 30 | 31 | However, while the buffer is not full FLAP auctions do not take place, and MKR is not burned. This means that Maker Governance is not being rewarded for its efforts during this time. 32 | 33 | Additionally, DAI in the System Surplus Buffer is not circulating in the market. This means that holding large amounts of DAI in the System Surplus Buffer will increase upwards pressure on the DAI peg. 34 | 35 | On the other hand, maintaining too low of a Maximum System Surplus means that FLOP auctions are more likely to take place in the event of bad debt. This makes it more likely that the supply of MKR will increase and dilute the value of current MKR Holders. 36 | 37 | ## Changes 38 | 39 | Adjusting the Maximum System Surplus parameter is a manual process that requires an executive vote. Changes to the Maximum System Surplus are subject to the [GSM Pause Delay](param-gsm-pause-delay.md). 40 | 41 | **Why increase this parameter?** 42 | 43 | The primary reason for increasing the Maximum System Surplus is minimizing the risk of MKR minting in the case of a market event leading to bad debt. In general, the larger the total DAI debt, the larger the Maximum System Surplus should be to balance the risk from volatile collateral. 44 | 45 | Another reason to increase the Maximum System Surplus is if for whatever reason it is beneficial to prevent the burning of MKR for a certain time. 46 | 47 | **Why decrease this parameter?** 48 | 49 | The primary reason for decreasing the Maximum System Surplus when the buffer is full would be to use the DAI currently in the buffer to buy and burn MKR. Alternatively, if the buffer was not full, Governance may choose to decrease the buffer to restart the continuous MKR burn arising from the buffer overflow. 50 | 51 | Another reason to decrease the Maximum System Surplus might be if the risk from the collateral portfolio decreases, either due to reduced DAI debt across all vaults, or the portfolio of collateral backing DAI becoming more stable and less risky on average. 52 | 53 | ## Considerations 54 | 55 | Care should be taken when decreasing the Maximum System Surplus parameter while the buffer is full. Decreasing the size of the buffer will trigger FLAP auctions for the amount of outstanding DAI that no longer fits within the new buffer. Large numbers of FLAP auctions at once have the potential to overwhelm auction keepers and result in the protocol buying MKR at a higher than market price. 56 | 57 | DAI can be pulled out of the Maker Protocol by Maker Governance by using the `suck` method as part of an executive vote. DAI `suck`ed from the protocol in this way will be deducted from the System Surplus Buffer and will trigger MKR mints if more DAI is `suck`ed than exists in the System Surplus Buffer. 58 | 59 | The System Surplus Buffer is not made up of ERC-20 DAI tokens. Rather, it is a number derived by subtracting the Maker Protocol's liabilities from its assets. At [Emergency Shutdown](https://docs.makerdao.com/smart-contract-modules/shutdown) the value represented by the system surplus goes to DAI holders in the form of a greater share of the collateral backing DAI. 60 | 61 | >Page last reviewed: 2022-11-04 62 | >Next review due: 2023-11-04 63 | 64 | -------------------------------------------------------------------------------- /governance/emergency-shutdown.md: -------------------------------------------------------------------------------- 1 | # Emergency Shutdown 2 | 3 | ## Overview 4 | 5 | An important security feature of the Maker Protocol is the ability to perform an Emergency Shutdown of the protocol. This allows the system to shut down gracefully and makes underlying collateral available for redemption by DAI holders and vault owners in a fair manner. The main goals of Emergency Shutdown are to ensure that 6 | 1. Vault owners with excess collateral in their vaults are able to fully withdraw that excess collateral. 7 | 2. DAI holders are then entitled to a pro-rata share of remaining collateral assets. Depending on what the protocol's total assets are worth, each unit of DAI may be worth less than $1. 8 | 3. Race conditions are avoided so that no matter when DAI holders and Vault owners choose to redeem their collateral, the collateral they are entitled to remains unchanged. 9 | 10 | {% hint style="warning" %} 11 | 12 | While all reasonable effort has been made to ensure the accuracy and currency of this page, the authors are not smart contract developers, and changes to the Emergency Shutdown procedure may be made by Maker Governance at any time (subject to the GSM Pause Delay). 13 | 14 | {% endhint %} 15 | 16 | ## Activation 17 | 18 | Emergency Shutdown is a last-resort measure that shuts down the protocol. Example situations where it can be used is to defend the protocol against a high-severity attack or if MKR holders believe the protocol cannot be made solvent through debt auctions. 19 | 20 | The process of Emergency Shutdown starts with MKR holders depositing MKR into the [Emergency Shutdown Module (ESM)](../module-index/module-emergency-shutdown.md). Emergency Shutdown is triggered when MKR deposited to the ESM exceeds the minimum threshold parameter. 21 | 22 | The protocol may also be shut down through a regular Executive Vote. Unlike triggering the ESM, this type of shutdown would be subject to the [GSM Pause Delay](../parameter-index/core/param-gsm-pause-delay.md) imposed by the Governance Security Module and is more likely to be used in the case of major technical upgrades. 23 | 24 | ## Sequence of events 25 | 26 | 1. Once Emergency Shutdown has been activated, the following items take effect immediately: 27 | * The ability to create vaults, generate DAI from existing vaults, or repay borrowed DAI to vaults is disabled. 28 | * All debt and surplus auctions can be permisionlessly disabled. 29 | * The DAI Savings Rate and all stability fees are set to zero. 30 | * All price oracles are frozen to their current reference prices. 31 | * Vault owners may still withdraw any excess collateral from their vaults but cannot repay DAI debt to retrieve the remaining collateral. 32 | 2. Once Emergency Shutdown has been activated, a cooldown period is needed to allow any ongoing collateral auctions to conclude. Once all collateral auctions finish, the system can calculate the collateral that can be assigned to the remaining DAI in circulation. 33 | 3. Each unit of DAI is entitled to withdraw a pro-rata share of collateral from each collateral type. Users may either continue to hold their DAI or transfer it to other wallets until it is used to redeem the underlying basket of collateral. 34 | 35 | ## Redeployment 36 | 37 | Since the Maker Protocol is open source and decentralized, anyone can redeploy the system. Ideally, the parameters of redeployment should depend on the reason for the Emergency Shutdown, and should not be altered unilaterally and arbitrarily. 38 | 39 | It is likely that the Maker Community will decide on whether redeployment is appropriate and if so, MKR holders will vote on a redeployment with the appropriate configuration. 40 | 41 | ## Considerations 42 | 43 | DAI is no longer soft pegged to 1 USD after Emergency Shutdown, as it is now tied to the value of a fixed amount of underlying collateral. Such a depegging could result in significant disruption across the wide DeFi ecosystem due to many other dapps that use DAI with the assumption that it is pegged to 1 USD. 44 | 45 | DAI holders need to manually redeem their DAI for the underlying collateral. The process is not automatic. It is likely that there will be secondary markets where DAI can be traded for specific assets rather than the underlying basket of collateral. 46 | 47 | Vault owners must manually withdraw any excess collateral from their vaults. 48 | 49 | MKR tokens may or may not have value after the system is shut down. If the protocol is relaunched and the community decides to do so, existing MKR holders, including those who burned their MKR by depositing them into the ESM, may receive governance tokens of the relaunched protocol. The relaunched protocol may even continue to use existing MKR tokens. 50 | 51 | Real-world Assets are represented by RWA tokens and DAI holders may redeem DAI for the RWA tokens. The RWA tokens represent a fractional share of the corresponding real-world asset. 52 | 53 | ## Detailed Documentation 54 | 55 | Additional technical documentation about how Emergency Shutdown works can be found in the following links. 56 | * [Emergency Shutdown Module documentation](https://docs.makerdao.com/smart-contract-modules/emergency-shutdown-module) 57 | * [End - Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/shutdown/end-detailed-documentation) 58 | * [MakerDAO Technical Docs](https://docs.makerdao.com/). 59 | 60 | >Page last reviewed: 2022-12-11 61 | >Next review due: 2023-12-11 62 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Table of Contents 2 | 3 | * [Maker Operational Manual](README.md) 4 | 5 | ## Governance Elements 6 | * [Atlas](governance/atlas.md) 7 | * [Scopes and Artifacts](governance/scopes-and-artifacts.md) 8 | * [Scope Advisory Councils](governance/scope-advisory-councils.md) 9 | 10 | ## Resources 11 | * [Status and Dashboards](protocol-status/protocol-and-dao-status.md) 12 | * [Common Abbreviations and Acronyms](protocol-status/acronyms.md) 13 | * [Discord Servers](misc/discords.md) 14 | * [MakerDAO Calls Calendar](protocol-status/calls-calendar.md) 15 | * [MakerDAO Governance Calendar](protocol-status/governance-calendar.md) 16 | * [Easy Governance Frontend](governance/easy-governance-frontend.md) 17 | 18 | ## Governance Processes 19 | * Governance Cycle 20 | * [Monthly Governance Cycle](governance/monthly-governance-cycle.md) 21 | * [Weekly Governance Cycle](governance/weekly-governance-cycle.md) 22 | * [Voting](governance/voting-in-makerdao.md) 23 | * [Practical Guide to Voting](governance/practical-guide-voting.md) 24 | * [Gasless Poll Voting](governance/gasless-poll-voting.md) 25 | * [On-Chain Governance](governance/on-chain-governance.md) 26 | * [Approval Voting Guide](governance/approval-voting-guide.md) 27 | * [Video Guide To Voting In The Maker Protocol](governance/how-to-vote.md) 28 | * Executive Vote Considerations 29 | * [Executive Audit](governance/executive-audit.md) 30 | * [Executive Transactions](governance/executive-transaction-verification.md) 31 | * [GSM Exceptions](governance/gsm-exceptions.md) 32 | * Off-Chain 33 | * [Off-Chain Governance](governance/off-chain-governance.md) 34 | * [Impact Estimations](governance/impact-estimations.md) 35 | * [Emergency Shutdown](governance/emergency-shutdown.md) 36 | 37 | ## Delegation 38 | * Overview 39 | * [What is delegation](delegation/what-is-delegation.md) 40 | * Entities 41 | * [Alignment Conservers](delegation/alignment-conservers.md) 42 | * [Aligned Voter Committees](delegation/avc.md) 43 | * [Aligned Delegates](delegation/aligned-delegates.md) 44 | * For MKR Holders 45 | * [MKR Holders Guide to Delegation](delegation/mkr-holder-guide.md) 46 | * [Delegate Metric Tracking](delegation/delegate-metric-tracking.md) 47 | * [Delegate Contract Migration](delegation/delegate-expiration.md) 48 | 49 | ## Parameter Index 50 | 51 | * Core 52 | * [Governance Pause Delay](parameter-index/core/param-gsm-pause-delay.md) 53 | * [Maximum System Surplus](parameter-index/core/param-system-surplus-buffer.md) 54 | * [Dai Savings Rate](parameter-index/core/param-dai-savings-rate.md) 55 | * [Global Liquidation Limit](parameter-index/core/param-global-liquidation-limit.md) 56 | * [Global Debt Ceiling](parameter-index/core/param-global-debt-ceiling.md) 57 | * Vault Risk 58 | * [Stability Fee](parameter-index/vault-risk/param-stability-fee.md) 59 | * [Debt Ceiling](parameter-index/vault-risk/param-debt-ceiling.md) 60 | * [Liquidation Ratio](parameter-index/vault-risk/param-liquidation-ratio.md) 61 | * [Liquidation Penalty](parameter-index/vault-risk/param-liquidation-penalty.md) 62 | * [Debt Floor](parameter-index/vault-risk/param-debt-floor.md) 63 | * [RWA Agreement](parameter-index/vault-risk/param-rwa-agreement.md) 64 | * Smart Burn Engine 65 | * [Smart Burn Engine Lot Size](parameter-index/surplus-auction/param-surplus-lot-size.md) 66 | * [Smart Burn Engine Cooldown](parameter-index/surplus-auction/param-surplus-cooldown.md) 67 | * [Smart Burn Engine Slippage Tolerance](parameter-index/surplus-auction/param-surplus-slippage-tolerance.md) 68 | * Collateral Auction 69 | * [Auction Price Function](parameter-index/collateral-auction/param-auction-price-function.md) 70 | * [Auction Price Multiplier](parameter-index/collateral-auction/param-auction-price-multiplier.md) 71 | * [Local Liquidation Limit](parameter-index/collateral-auction/param-local-liquidation-limit.md) 72 | * [Max Auction Drawdown](parameter-index/collateral-auction/param-max-auction-drawdown.md) 73 | * [Max Auction Duration](parameter-index/collateral-auction/param-max-auction-duration.md) 74 | * [Breaker Price Tolerance](parameter-index/collateral-auction/param-breaker-price-tolerance.md) 75 | * [Proportional Kick Incentive](parameter-index/collateral-auction/param-proportional-kick-incentive.md) 76 | * [Flat Kick Incentive](parameter-index/collateral-auction/param-flat-kick-incentive.md) 77 | * Debt Auction 78 | * [Debt Auction Minimum Bid Decrease](parameter-index/debt-auction/param-min-bid-decrease-flop.md) 79 | * [Debt Auction Duration](parameter-index/debt-auction/param-auction-duration-flop.md) 80 | * [Debt Auction Bid Duration](parameter-index/debt-auction/param-bid-duration-flop.md) 81 | * [Debt Auction Delay](parameter-index/debt-auction/param-debt-auction-delay.md) 82 | * [Debt Auction Bid Size](parameter-index/debt-auction/param-bid-size.md) 83 | * [Debt Auction Initial Lot Size](parameter-index/debt-auction/param-initial-lot-size.md) 84 | * [Debt Auction Lot Size Increase](parameter-index/debt-auction/param-lot-size-increase.md) 85 | 86 | 87 | ## Module Index 88 | * [Peg Stability](module-index/module-psm.md) 89 | * [Debt Ceiling Instant Access](module-index/module-dciam.md) 90 | * [Token Streaming](module-index/module-token-streaming.md) 91 | * [DAI Direct Deposit](module-index/module-dai-direct-deposit.md) 92 | * [Flash Mint](module-index/module-flash-mint-module.md) 93 | * [Linear Interpolation](module-index/module-lerp.md) 94 | * [Emergency Shutdown](module-index/module-emergency-shutdown.md) 95 | -------------------------------------------------------------------------------- /module-index/module-flash-mint-module.md: -------------------------------------------------------------------------------- 1 | # Flash Mint 2 | 3 | >**Alias:** Flash 4 | >**Contract Name:** MCD_FLASH 5 | >**Scope:** System 6 | >**Technical Docs:** [link](https://docs.makerdao.com/smart-contract-modules/flash-mint-module) 7 | 8 | ## Description 9 | 10 | The Flash Mint Module allows anyone to permisionlessly mint DAI as long as it is paid back in the same transaction. This is commonly known as a Flash Loan. 11 | 12 | Users can combine Flash Loans with other smart contract functions to perform powerful multi-step transactions across multiple decentralized exchanges (DEX). Multi-step transactions of this nature have many uses, including arbitrage and improving user experience when creating leveraged positions. 13 | 14 | ### Example 15 | 16 | To demonstrate how this works in practice, we will imagine DAI trades at 1.02 DAI/USDC at DEX-1 and 0.98 DAI/USDC at DEX-2. Using the Flash Mint Module, a user could arbitrage this price difference as follows: 17 | 18 | * Mint 1000 DAI using the Flash Mint Module 19 | * Exchange 1000 DAI for 1020 USDC at DEX-1 20 | * Exchange 1020 USDC for ~1040 DAI at DEX-2 21 | * Pay 1000 DAI back to the Flash Mint Module and has made a profit of ~40 DAI 22 | 23 | The above example ignores gas fees for simplicity. In reality, flash loan arbitrage must account for gas fees in order to be profitable. 24 | 25 | ## Purpose 26 | 27 | The Flash Mint Module adds DAI Flash Loans to the Maker Protocol, under the control of Maker Governance. There are several advantages to this which are listed below. 28 | 29 | ## Benefits 30 | 31 | There are several benefits offered to the Maker Protocol and broader Dai ecosystem by the Flash Mint Module: 32 | 33 | * Improved Flash Loan liquidity - other providers of Flash Loans are reliant on the market supply of DAI in order to provide Flash Loan capability. Because the Maker Protocol is able to mint DAI, Flash Loans can theoretically be of infinite size. Because DAI is burned at the end of the transaction this does not affect the collateralization of DAI. 34 | * Market efficiency of DAI is improved by Flash Loan arbitrage - a secondary effect of this could be increased liquidity in DAI markets and Peg stability as deviations from the Peg will be more susceptible to arbitrage. 35 | * The ability to borrow large sums increases the utility of Flash Loans to identify exploits in DeFi protocols - by exposing exploits and attack vectors, the DeFi ecosystem can be made more robust. 36 | * The Flash Mint Module encourages further integration between the Maker Protocol and other Decentralized Apps - DEX aggregators can use it to ensure their users get the best prices available, or Vault automation systems can utilize Flash Loans to leverage and deleverage Vaults. 37 | * Income for The Maker Protocol - The Maker Protocol can charge Minting Fees on Flash Loans that use the Flash Mint Module. Minting Fees have the potential to be an alternative source of revenue for the Maker Protocol. Typically, fees charged on Flash Loans are in the order of 0-0.1%. 38 | * The Flash Mint Module is permissionless, meaning anyone can use it. Similarly, it makes access to arbitrage opportunities possible for more users as it is no longer capital dependent. 39 | 40 | ## Drawbacks 41 | 42 | Flash Loans are potent tools, but they also carry some risk. For example, they can be used as an attack vector against DeFi protocols. In addition, it is theoretically possible to mint extremely high amounts of DAI if unrestricted, potentially destabilizing some DeFi protocols. 43 | 44 | ## Key Parameters 45 | 46 | There are two key parameters in the Flash Mint Module that are controlled by Maker Governance. Changes to these parameters are a manual process that requires an executive vote. Changes to these parameters are subject to the GSM Pause Delay. 47 | 48 | ### Debt Ceiling (`line`) 49 | 50 | The Debt Ceiling refers to the maximum amount of Flash Loaned DAI that a user can mint in a single transaction. 51 | 52 | The higher this value, the greater the potential for profit from arbitrage opportunities and for exploits to cause losses for DeFi protocols. 53 | 54 | If the Debt Ceiling is too low, the potential applications of the Flash Mint Module will be lower in number, as potential profit will be lower. As a result, users may look to alternative sources of DAI Flash Loans if they provide more generous Debt Ceilings. 55 | 56 | ### Minting Fee (`toll`) 57 | 58 | The Minting Fee is an optional fee that the Maker Protocol can charge to users of Flash Loans. Users must repay the Minting Fee simultaneously as they repay the principle of the Flash Loan. For example, a Flash Loan of 1000 DAI with a Minting Fee of 0.1% will require 1001 DAI to be paid back at the end of the transaction. 59 | 60 | Minting Fees can be a source of revenue for the Maker Protocol but will decrease the profits of Flash Loan users. 61 | 62 | If alternative sources of DAI Flash Loans charge lower or no fees, users may choose to use them rather than the Flash Mint Module. 63 | 64 | ## User Interaction 65 | 66 | The Flash Mint Module conforms to ERC1356. Therefore, users can use the reference borrower implementation from the ERC1356 spec. It requires the user to have the technical ability to work with Solidity, or access to a UI that is able to build and execute the desired transaction. 67 | 68 | ## Considerations 69 | 70 | Fees accrued through the Flash Mint Module are transferred to the Surplus Buffer upon completion of the transaction. 71 | 72 | >Page last reviewed: 2022-09-18 73 | >Next review due: 2023-09-18 74 | 75 | -------------------------------------------------------------------------------- /parameter-index/vault-risk/param-liquidation-penalty.md: -------------------------------------------------------------------------------- 1 | # Liquidation Penalty 2 | 3 | >**Alias:** Liquidation Penalty 4 | >**Parameter Name:** `chop` 5 | >**Containing Contract:** `MCD_DOG` 6 | >**Scope:** Vault Type (Ilk) 7 | >**Technical Docs:** [Liquidations 2.0](https://docs.makerdao.com/smart-contract-modules/dog-and-clipper-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Liquidation Penalty parameter controls the fee vault owners must pay when their position is liquidated due to insufficient collateral. For a vault holder to receive any collateral back from the liquidations process, the debt and Liquidation Penalty must be covered by the collateral auction. 12 | 13 | Each vault type has its own Liquidation Penalty that can be adjusted by Maker Governance. Note that the Liquidation Penalty applies collectively to all vaults created using a specific vault type, rather than to individual vaults. 14 | 15 | The Liquidation Penalty is expressed as a percentage of collateral rather than a fixed amount. 16 | 17 | {% hint style="info" %} 18 | 19 | **Example** 20 | 21 | _Liquidation Penalty_ = 13% 22 | _User A's Debt_ = 100 DAI 23 | 24 | 1. User A has an ETH Vault with 100 DAI debt. 25 | 2. User A is liquidated due to a fall in ETH price. 26 | 3. A collateral auction is triggered for User A's vault. 27 | 4. The collateral auction aims to recover 113 DAI using the collateral in User A's ETH vault. 28 | 29 | {% endhint %} 30 | 31 | ## Purpose 32 | 33 | Generally, the Liquidation Penalty may be thought of as a fee to incentivize proper collateralization for vault owners. As a risk parameter, its primary function is to ensure the system does not accumulate unbacked DAI. The Liquidation Penalty gives vault users an added incentive to keep their positions over-collateralized while providing the system additional revenue to mitigate potential losses due to liquidations. The Liquidation Penalty also plays an important role acting as a deterrent against liquidation-related attacks by adding some friction to the liquidation process. 34 | 35 | ## Trade-offs 36 | 37 | The larger the Liquidation Penalty is, the more vault users are incentivized to keep their position safely funded. Having more heavily collateralized positions makes the DAI ecosystem safer. 38 | 39 | However, larger Liquidation Penalties increase risk to vault users. As a result, the cost of borrowing through MakerDAO may be too great or users may choose to leave their vaults more heavily collateralized. This would reduce the attractiveness of the Maker Protocol in comparison to competitors and may reduce DAI generation. 40 | 41 | The higher the Liquidation Penalty, the less likely it is that a vault user will have collateral left over after a liquidation event. While appropriate to incentivize proper vault maintenance, the Liquidation Penalty can cause a risk to the system when set too low, and discourage DAI generation if set too high. 42 | 43 | ## Changes 44 | 45 | Adjusting the Liquidation Penalty parameter is a manual process that requires an executive vote. Changes to the Liquidation Penalty are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 46 | 47 | **Why increase a Liquidation Penalty Parameter?** 48 | 49 | Increasing the Liquidation Penalty should result in more revenue for the system during liquidation events. While there are fiscal considerations tied to this parameter, the main reason to increase the Liquidation Penalty is due to the risk or perceived risk of a collateral type during liquidation. Collateral that is less desired or riskier to hold due to price fluctuation may lead to an increase in the Liquidation Penalty to account for potential losses due to inefficient auctions. 50 | 51 | When increasing this parameter care should be given to PR and communication. Vault users that are unaware of a increase may feel victimized if they are then liquidated and lose more collateral than they expected. 52 | 53 | **Why decrease a Liquidation Penalty Parameter?** 54 | 55 | Decreasing the Liquidation Penalty should result in less system revenue during liquidation events while increasing the chances that vault owners receive collateral back after liquidation. While there may be business reasons to decrease this parameter, the main reason to decrease the Liquidation Penalty would be confidence in the auction system. Decreasing the Liquidation Penalty ultimately decreases the expected cost of maintaining a vault position, leading to more incentive for DAI creation. 56 | 57 | ## Considerations 58 | 59 | As this parameter directly affects the risk of vault holders and the system, changes to the Liquidation Penalty parameter should always be done with great care. 60 | 61 | The Liquidation Penalty should always be higher than the sum of liquidation rewards (`tip` and `chip`) so as to prevent the farming of incentives, a practice whereby an attacker purposely liquidates their own vaults in order to reap the liquidation rewards. 62 | 63 | Particularly important to vault holders is the notion that the Liquidation Penalty represents the minimum loss during a liquidation event, not the maximum. As vault holders will only receive collateral back in excess of the debt liquidated and the Liquidation Penalty, there is no guarantee the auction of collateral will be enough to cover both. 64 | 65 | During an [Emergency Shutdown](https://docs.makerdao.com/smart-contract-modules/shutdown), no new collateral auctions may be started. All auctions underway during an emergency shutdown will be subject to the Liquidation Penalty parameter with no special considerations. 66 | 67 | >Page last reviewed: 2022-11-04 68 | >Next review due: 2023-11-04 69 | 70 | -------------------------------------------------------------------------------- /parameter-index/vault-risk/param-stability-fee.md: -------------------------------------------------------------------------------- 1 | # Stability Fee 2 | 3 | >**Alias:** N/A 4 | >**Parameter Name:** `duty` 5 | >**Containing Contract:** `MCD_JUG` 6 | >**Scope:** Vault Type (Ilk) 7 | >**Technical Docs:** [Jug Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/rates-module/jug-detailed-documentation) 8 | 9 | ## Description 10 | 11 | The Stability Fee parameter is an annual percentage fee charged on the DAI generated on vaults. It is expressed as an annual percentage yield but it is charged on a per-block basis in DAI. The DAI from this fee is minted, added to the DAI debt for the vault, and then transferred into the Surplus Buffer which is under the control of Maker Governance. 12 | 13 | Each vault type has its own Stability Fee that can be adjusted by Maker Governance. Note that the Stability Fee applies collectively to all vaults created using a specific vault type. 14 | 15 | {% hint style="info" %} 16 | 17 | **Example** 18 | 19 | _ETH-A Stability Fee_ = 4% 20 | 21 | 1. User A opens an ETH-A vault and generates 100 DAI. 22 | 2. One year passes, during which the ETH-A Stability Fee remains at 4%. 23 | 3. User A's vault debt is now 104 DAI. 24 | 25 | {% endhint %} 26 | 27 | ## Purpose 28 | 29 | The primary purpose of the Stability Fee parameter is to compensate the Maker Protocol for the risk it takes being exposed to changes in the price of the collateral used to back the generated DAI. 30 | 31 | The Stability Fee is also the largest source of revenue for the Maker Protocol and should be expected to be used to: 32 | 33 | * Pay for the operational expenses of running and growing the Maker Protocol. 34 | * Pay for the operation of the Oracle feeds. 35 | * Buy and burn MKR to remove it from the total supply, indirectly compensating Maker Governance for operating the Maker Protocol and acting as the lender of last resort. 36 | 37 | ## Trade-offs 38 | 39 | In theory modifying the Stability Fee for a vault type will impact the number of vault users that are willing to use that vault type, with increases reducing the amount of DAI generated, and decreases increasing the amount of DAI generated. 40 | 41 | However, it is open to debate just how much of an effect Stability Fee modifications have on user behavior. Other, more significant factors play into a user's decision to maintain a vault, including market conditions and the competitive landscape. 42 | 43 | In practice, large modifications to Stability Fees have had measurable effects on user behavior, while the impact of smaller changes is less clear. 44 | 45 | Higher Stability Fees may temporarily or permanently increase the revenue from a particular vault type, depending on the level of user response to the Stability Fee change. 46 | 47 | Likewise, lower Stability Fees may temporarily or permanently decrease the revenue from a particular vault type, depending on the level of user response to the Stability Fee change. 48 | 49 | ## Changes 50 | 51 | Adjusting a Stability Fee parameter is a manual process that requires an executive vote. Changes to Stability Fee parameters are subject to the [GSM Pause Delay](../core/param-gsm-pause-delay.md). 52 | 53 | The Maker Open Market Committee has been empowered by Maker Governance to propose rate changes based on monetary policy, risk, and competitive landscape. The operations, membership, and historic proposals of this committee can be found on the [Maker Governance Forum](https://forum.makerdao.com/tag/rates-working-group). 54 | 55 | **Why increase a Stability Fee parameter?** 56 | 57 | The primary reason to increase a Stability Fee parameter is one of monetary policy. If the price of DAI is less than $1, this indicates that the DAI supply should be reduced. The Stability Fee is usually the first parameter that Governance contemplates changing if DAI supply needs to be reduced. 58 | 59 | Alternatively, a Stability Fee for a vault type might be increased if Maker Governance does not feel that the protocol is being adequately compensated for the risk from that particular vault type. 60 | 61 | A Stability Fee might also be increased if Maker Governance determines that it needs additional capital to operate or grow effectively and does not expect an increased Stability Fee to negatively affect the DAI peg. 62 | 63 | Finally, a Stability Fee might be increased if no viable competitors are offering lower rates than the Maker Protocol and Maker Governance feels that higher fees can be charged without negatively impacting the DAI peg. 64 | 65 | **Why decrease a Stability Fee parameter?** 66 | 67 | The primary reason to decrease a Stability Fee parameter is also one of monetary policy. If the price of DAI is greater than $1, this indicates that the DAI supply should be increased. The Stability Fee is usually the first parameter that Governance contemplates changing if DAI supply needs to be increased. 68 | 69 | Alternatively, a Stability Fee for a vault type might be decreased if Maker Governance feels that the level of risk from that vault type has decreased. 70 | 71 | Finally, a Stability Fee might be decreased if competitors are offering lower rates than the Maker Protocol and Maker Governance wishes to retain or increase market share. 72 | 73 | ## Considerations 74 | 75 | The Stability Fee parameter has a lower bound of 0%, it cannot be negative. 76 | 77 | Absent active management by a vault user, the accrual of Stability Fees can push a vault's Collateralization Ration below the [Liquidation Ratio](param-liquidation-ratio.md), which will allow it to be liquidated. 78 | 79 | A Global Stability Fee parameter also exists within the Maker Protocol. In practice, this has not been used because it adds unnecessary complexity to the governance process and Stability Fee calculation. 80 | 81 | 82 | >Page last reviewed: 2022-11-25 83 | >Next review due: 2023-11-25 84 | 85 | -------------------------------------------------------------------------------- /module-index/module-token-streaming.md: -------------------------------------------------------------------------------- 1 | # Token Streaming 2 | 3 | >**Alias:** Vesting Module, Vest 4 | >**Contract Names:** `MCD_VEST_MKR`, `MCD_VEST_MKR_TREASURY`,`MCD_VEST_DAI` 5 | >**Scope:** System 6 | >**Technical docs:** TBD 7 | 8 | ## Description 9 | 10 | The Token Streaming Modules allow the streaming of tokens from the Maker Protocol to Core Units or individuals. Between them they support: 11 | * Scheduling - Set start and end dates for the stream. 12 | * Cliff Vesting - Set a date before which funds cannot be claimed. 13 | * Third-party revocation - Designate a third party who has permission to cancel the stream of funds. 14 | * Minted MKR - One version of the contract (`MCD_VEST_MKR`) supports streaming purpose-minted MKR tokens. 15 | * Minted DAI - One version of the contract (`MCD_VEST_DAI`) supports streaming purpose-minted DAI tokens. 16 | * Any ERC20 - One version of the contract (`MCD_VEST_MKR_TREASURY`) supports streaming any ERC20 (though the source address must have the requisite tokens.) 17 | 18 | The recipients of the streamed funds can call a function on the relevant smart contract and receive some or all of the funds that have been vested at the point the function is called. 19 | 20 | ## Examples 21 | 22 | ### Core Unit Budgets 23 | 1. Maker Governance has agreed on a 3 month budget for the GovAlpha Core Unit which totals 120,000 DAI. 24 | 2. As part of an executive vote, governance confirms the setup of a DAI token stream using DssVestSuckable with the above parameters. 25 | 3. After 24 hours, GovAlpha will be able to claim `120,000 / 90 = ~1,333` DAI from the vesting contract. 26 | 4. After 45 days, GovAlpha will be able to claim an additional ~58,666 DAI from the vesting contract. 27 | 5. After 90 days, GovAlpha will be able to claim the rest of the DAI (~60,000) from the vesting contract. 28 | 29 | ### MKR Vesting 30 | 31 | 1. Maker Governance has agreed to reward a contributor with 200 MKR with a length of 12 months and a cliff period of 6 months. 32 | 2. As part of an executive vote, governance confirms the setup of an MKR token stream using DssVestMintable with the above parameters. 33 | 3. Prior to 6 months passing, the contributor will not be able to redeem any MKR from the vesting contract. 34 | 4. Once 6 months have expired, the contributor will be able to redeem 100 MKR from the vesting contract. 35 | 5. After an additional month has passed, the contributor will be able to claim ~16.67 MKR from the vesting contract. 36 | 6. After 12 months have passed, the contributor will be able to claim the remainder of the MKR. 37 | 38 | ## Purpose 39 | 40 | The Token Streaming Modules provide several advantages to governance: 41 | * Provision of a secure mechanism to reward contributors to the Maker Protocol over time. 42 | * Doesn't allow the recipient to access all the tokens up-front, reducing the risk of losing funds due to poor performance or malicious behavior. 43 | * Reduction of Governance overhead regarding compensation for contributors. 44 | * On-chain visibility of governance's budget commitments of DAI and MKR, increasing transparency. 45 | * Enabling user control over the claiming of vested tokens. 46 | * It allows governance to credibly commit to the intention to fund DAI or MKR at a future date by moving the required action to *preventing* a distribution, rather than *approving* a distribution. 47 | 48 | ## Trade-offs 49 | 50 | DssVest should be compared to manual transfers of the DAI and MKR tokens. 51 | 52 | DssVest allows MKR holders to vote on issues of token distribution less often, which streamlines governance, however, it also requires more attention to continued operations from MKR holders, as tokens will continue to stream until fully allocated or stopped by a further governance action. 53 | 54 | ## Key Parameters 55 | 56 | Parameters for DssVest are upon the deployment of a new stream. The primary parameters are: 57 | - Target Address - The recipient of the tokens. 58 | - Start Date - The date to begin streaming tokens. 59 | - End date - The date to end the token stream. 60 | - Amount - The number of tokens to stream to the recipient. 61 | - Cliff Date - The date after which tokens become accessible to the recipient. 62 | 63 | ## User Interaction 64 | 65 | DssVest allows recipients to claim streamed tokens at their discretion. This involves: 66 | 67 | 1. Locating the relevant token contract. MakerDAO contracts are listed [here](https://chainlog.makerdao.com/). They are listed as: 68 | `MCD_VEST_DAI` - To get DAI minted from the Maker Protocol. 69 | `MCD_VEST_MKR` - To get MKR minted from the Maker Protocol. 70 | `MCD_VEST_MKR_TREASURY` - - To get MKR transferred from the Maker Protocol treasury. 71 | 72 | 2. Call the `vest` function, passing the appropriate stream ID as a parameter. Stream IDs can be found on several prominent MakerDAO status front-ends. 73 | 74 | 3. Optionally pass a second parameter indicating the number of tokens to receive from the stream. The absence of this parameter will result in all eligible tokens being transferred to the recipient. 75 | 76 | ## Considerations 77 | 78 | Once a vesting stream has reached its end date, the streamed tokens cannot be revoked and users can independently redeem their tokens. The exception to this is if governance revokes permissions over the entire contract, revoking all streams and access to unclaimed funds by the former recipients. 79 | 80 | If a stream is revoked at a future date, it will continue streaming up until that date. 81 | 82 | When using the DAI Vesting contract, funds remain in the surplus buffer until a transfer is triggered by the recipient. This means any unused funds can be used to protect the protocol, however, also the contract carries the danger of MKR minting if a recipient collects funds from DssVestSuckable while the system surplus buffer does not contain sufficient funds. 83 | 84 | >Page last reviewed: 2022-11-07 85 | >Next review due: 2023-11-07 86 | 87 | --------------------------------------------------------------------------------