(I am reposting a section of an earlier post, because I want to be able to refer to it in isolation)
Let me write my goal with respect to Maker as established when I started my personal stablecoin quest starting in late 2013 and reinforced when I quit my job to work help start the Maker project a little over a year ago.
My goal is to find a stablecoin system design that works "good enough" and then make changing the rules as hard as possible. The litmus test is whether adversarial governments ever use it to cooperate (deliberately or not).
"Smart contracts" should be called "dumb, durable software objects". I believe there could be an incentive compatible "contract" (dumb persistent software object) system that can create a token whose market price has low volatility relative to a reference asset/basket at scale. This is only possible because it eliminates some kind of deadweight loss, otherwise it can't "pay for itself" and survive. Think about how much bitcoin's POW costs. Bitcoin is somehow causing an effective net savings to the economy worth at least that much, or it would shrink and/or die from the massive recurring expense.
Maker is not intended to be a dynamic, intelligent system (e.g. a company offering a software service). It is a dumb mechanism that is a financial tool. In a vacuum it should be instantly out-competed because companies are made out of smart monkeys and not dumb software objects. Because of the fact that the stablecoin niche will likely be occupied by a natural monopoly, and provable "self-restraint" is the competitive factor, it can likely "compete" anyway, the analogy again being how Bitcoin magically isn't worth nothing.
Death is inevitable and obsolecense is the best way to go.
If the current MKR stakeholders do not view Maker this way, that making 100% of the business logic actually autonomous in reality is possible and desirable, my advice would be to delete the "undistributed" MKR and fund all operations with inflation-by-vote. That is where it would end up anyway, and this is more honest than claiming its supply changes are purely mechanical. Right now it takes 4 of 6 monkeys to agree (or get pwned) to make it whatever they want - everything else is a fragile shared illusion.
I will be formally proposing breaking the supply rules to enable vote-inflation (with the intent of having it NOT pass) to be simulated as a proper stake-vote to appease anyone feeling disenfranchised.
Going forward Maker users will inevitably face application-level "hard fork" dilemmas. If Maker is successful in any sense of the word then you can be sure any split will be brutal. Again, in the success scenario this coordination problem should work in favor of stability since 1) there is a dumb mechanism figured out that works "good enough" and 2) it is very convincing that at least this mechanism is not going to change: you can safely play long-term iterated games.
I am afraid that Maker could be overrun by stakeholders who vote in a way that will cause it to fail to bootstrap and will just turn into a thin veil around a traditional centralized institution. There is a certain existential risk in running any sort of "beta" where recapturing control is possible and where stakeholders are voting on how to spend each other's money.
Fortunately Dictator Rune was wise enough not to do a crowdsale and so that risk may not be high.
Even so, it is clear we need stronger "convergence intent signals" as there has been a kind of "culture creep" in what I think is the wrong direction.
I have two to offer.
The first is zandy's Sentinel stake-vote blog post, which establishes intent to end up in a voting system that "locks up" when MKR is actively traded as an investment asset but nobody can coordinate system-level updates.
The second is the introduction of Kelvin versioning for Maker system updates. In this system you use nonnegative integer versions and count down. The current system is officially version 957. The more versions you (carefully, strategically) choose to skip in an a successful update, the more champagne you can have. Version 0 should have redundant formal verification and users enjoying third-party insurance options - if it's still somehow killed, it's dead. Some version in between will have "peak monkey organization". There's always someone who will be better off in the short term if the system doesn't lock down. If the system is efficient, it should often be a slight majority of its users.
This post will not stop some group of future monkeys poking at keyboards from saying "Maker is now this instead of that" - we've done it once and everyone went with it (yes I am talking about a maker app fork, not the ethereum fork), who am I to tell future monkey leaders they can't just try to coordinate a migration? One major lesson of the TheDAO disaster is that arguing on the internet is a huge waste of time, so I remind future monkeys finding themselves genuinely unsure about which Maker fork to go with that life is short and cashing out and taking a vacation is always a good option.
While MKR can't have "terms", monkeys can have perceptions about what other monkeys are "supposed" to be doing. I hope my personal goals are clear and that they align with a majority of existing MKR holders.