# [DRAFT] Proposal for a New Spell Architecture at MakerDAO

Author(s): @amusingaxl
Contributors:

## Motivation

Spell crafting is one of the most challenging aspects in MakerDAO.

Currently spells take the form of monolithic smart contracts. Depending on the contents of the Executive Spell of a given week, they can become huge pieces of **unaudited code** with **root access** to the Maker Protocol. In other words, every week MakerDAO contributors produce a new smart contract that can brick the entire system in case there is a bug.

To prevent catastrophic failures, spell crafting is a **very** resource intensive task. There is always an engineer responsible for the crafting the spell (most of the time a Protocol Engineering member), but other members or teams might required to collaborate on the same spell. Different people collaborating on the same handful of source code files usually leads to **merge conflicts**, which can be bad productivity sinkholes.

After the spell is considered ready, it needs to be reviewed by at least 2 different engineers, which are required to go through [several checklists]([https://](https://github.com/makerdao/pe-checklists/tree/master/spell)) manually to see if nothing was missed. During review there can still be some back and forth regarding the exact content.

Finally once everyone involved agrees on the spell code, it need to be deployed, verified and then scheduled for execution.

While the herculean efforts of the teams involved, especially GovAlpha and Protocol Engineering, have brought us this far without major problems, the [Law of Large Numbers](https://https://en.wikipedia.org/wiki/Law_of_large_numbers) is not on our favor here.

With the upcoming changes related to the End Game™ and the need of having more teams from the broader Maker ecosystem being able to make changes to the Maker Protocol and also to SubDAOs, the current process can be seen as not scalable, as it is expensive and error prone.

## The Status Quo

Currently the MCD Governance Module has 3 major on-chain components:

- **Chief**: (a.k.a. `MCD_ADM`) a `DSChief` contract that handles the "election" of a _spell_.
- **Pause**: (a.k.a `MCD_PAUSE`) a `DSPause` contract that handles the execution of a _spell_ through a `delegatecall` after an enforced delay.
- **Spell**: a bespoke un-owned contract that encapsulates actions to be performed within the Maker Protocol.

Source: [MakerDAO Docs](https://docs.makerdao.com/smart-contract-modules/governance-module).

Before any spell is written, the process starts with [Governance Polls](https://vote.makerdao.com/polling), that serves as a signaling mechanism for proposals. Polls have a limited duration and if they receive enough support, they can be selected

A spell that has the most MKR support in the **Chief** at a given time can be permissionlessly `lift`ed to receive the `hat`. Once it gets the hat, the spell can be `schedule`d and, after the **governance delay**, it can be `cast` (executed). After being cast, the spell is marked as `done` to prevent replay attacks.

MKR holders express their support for spells on-chain through the `vote` methods from the **Chief** contract. The support is weighted by the amount of MKR the holder has locked into the **Chief**. The [current **Chief** contract](https://etherscan.io/address/0x0a3f6849f78076aefadf113f5bed87720274ddc0#readContract#F3) allows each holder to support up to 5 different spells at once with all their MKR, meaning they do not have to split their MKR among the different spells.

One interesting property of such system is that in case a MKR holder does not want to support a new spell, they can simply leave their MKR bound to another old, but already executed spell that they previously voted for. Inertia in this case is in favor of not making changes to the protocol.

In case a bad spell ends up with the hat, be it because of a governance attack or due to a bug in the spell being discovered only after it has been `schedule`d, Maker Governance can act to `drop` it during the governance delay. To make this task easier, one can leverage tools like [`protego`](https://github.com/makerdao/protego), which can be `lift`ed to receive the `hat` and used to permissionlessly `drop` such spell.

... TODO ...

## Wishlist

Below are some ideas for a new mechanism for making changes to the Maker Protocol that is less reliant on central parties, such as core unit members. The idea is inline with the goals of the End Game™.

### Spell Crafting

- Common operations within the protocol can captured into **"primitives"**.
- Currently the jargon used is _spell actions_, but to keep within the spirit of the weird names, we could call them something like **_potions_**.
- Each _potion_ is a well defined action (or set thereof) to be performed within the protocol.
- Examples of _potion_: "Onboarding a new type of collateral", "Paying a delegate", "Modifying the debt ceiling of a collateral", etc.
- Each _potion_ has a clear effect in the overall state of the protocol that can be asserted, preferably in an automated fashion.
- Common types of _potions_ should have well-known **factory** contracts that can receive all required parameters and produce a valid smart contract that can later be incorporated into a spell.
- There should be a UI connected to the common potion factory contracts to allow non-technical people to create them.
- Primitives ("potions") are bundled together as a spell.
- A set of potions executed atomically would compose a spell.
- Ideally a spell should be a [commutative Monoid](https://encyclopediaofmath.org/wiki/Monoid) over potions, meaning that:
1. Potions can be arbitrarily grouped 2-by-2 for execution (associativity).
2. There exists an _identity_ potion (identity).
3. The order of execution of different potions does not matter (commutativity).
- Informally this means that potions should ideally be independent among themselves.
- Potions can be executed in any order. If a potion depends on the result of a different potion, it means that the set of operations composing them should be grouped into a single one.
- A spell can be a simple contract that simply iterates over and executes its potions.
- There should be a UI that allows non-technical people to bundle potions into a spell.
- Spells should be atomic.
- If any of the potions fail to execute, the entire spell must revert.
- Potions should be self-contained and predictable.
- The pre and post-conditions for each individual potion must be clearly defined.
- There should be enough safe-guards around potions (maybe a "base" potion from which the other ones are derived) to avoid common pitfalls.
- Potions do not "leak" to other potions, meaning they can be independently tested at any time.
- One instance where this might be harder than it sounds: two independent potions are to increase the debt ceiling of two unrelated collateral types. Debt ceiling increase can or cannot also increase the global debt ceiling.
- Potion test should not be coded with absolute debt ceilings in mind, but ensuring that the global debt ceiling changes by the expected amount after the potion execution.

### Spell Voting

- Anyone should be allowed to submit a spell for voting.
- Currently there is a spell whitelist controlled centrally by GovAlpha.
- To prevent spamming and other malicious activities, the spell **_bundler_** must commit assets to it (i.e.: stake some MKR to back the bundle).
- If the spell is correct and reflects the expected output, the _bundler_ receive their stake back plus some reward from the protocol.
- There must be a time window through which anyone can "challenge" a spell by providing an competing spell after commiting assets to it.
- If there is a challenge, the dispute must be solved:
- By some sort of committee composed of reputable and knowledgeable members of the Maker Community that can decide which competing spell is the correct one.
- By outsourcing decision to some specialized on-chain dispute resolution mechanism such as [Kleros](https://kleros.io/) or [Aragon](https://court.aragon.org/).
- The decision should **not** be based on a staking war (i.e.: the most voted spell wins), but from a technical perspective relative to the outcome of the polls that have already been voted.
- This is important to prevent reverting decisions that has already been made (i.e.: someone dislikes the result of a poll and decides to bring more MKR to the table to revert it before execution).
- In case of competing spells, the winner bundler receives their stake back plus all other competing bundlers' stake plus some reward from the protocol.
- This provides the right cryptoeconomic incentives to bundlers. If they misbehave, most likely they will lose money.
- Submit a bad spell? Someone will challenge it and get your stake.
- Challenge a good spell? The original bundler get your stake.
- The amount to required be staked when creating a spell is something that should be defined through some cryptoeconomic model.
- If it is too low, it will not succeed preventing spams and malicious activity.
- If it is too high, people will not be incentivized to create spells.
- Opposed to the current fluid spell supporting mechanism, the spell staking needs to be time-bound and immutable during that time frame to work properly.
- Effectively this would turn Governance Polls into the primary governance driver, while the spell staking mechanism would enforce that the decisions that have been made previously are honored.
- Executive Votes as they exist today would probably be superfluous.

### Spell Execution

... TODO ...