Euphoria Sandwich: 5 new lead devs, what Maker is not, and 30 new dapps.

New Lead Developers

Buckle up, we're about to have a Maker Lead Developer title ceremony. Please express condolences for these unfortunate folks:

reddit / steemit / github:

/u/ryepdx / @ryepdx / github.com/ryepdx

Known for quietly implementing critical ethereum application infrastructure and being a top 3 good-looking ethereum developer

/u/dbrock / @dbrock / github.com/dbrock

Or "the main who replaces your script with a shorter shell script"

/u/anodigitalog / @zandy / github.com/apmilen

Andy "relax, this will be easy" Milen

/u/mids106 / @mids106 / github.com/jorisbontje

The only actually responsible person in the room

/u/rainbreak / @rainy / github.com/rainbeam

Is a few sentences away from one of the most impressive titles known to man, "Fastest Maker Lead Developer Title Acquisition Man"

In exchange for showing tremendous initiative and finally firetruck-proofing the Maker project, I officially burden these developers with the Maker Lead Developer title.

Now on to a serious topic

Maker doesn't really have voting

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.

Now back to a more fun topic

"I don't care about Maker, but there are 30 other dapps??"

We will be highlighting one dapp, library, or package (a repository with a dappfile) each weekday from now until Devcon. The title is clickbait because most are not new, but rather freshly isolated building blocks which are direct or indirect dependencies for Maker and other Nexus clients. If there are any instances (ie something deployed, not pure code) they will be "public utilities", contracts with no benefactor except their direct users. By default we deploy to Morden, ETH, and now ETC, but they are chain-agnostic and we encourage creating canonical deployments of singleton dapps on other chains (consensys testnet comes to mind).

Expect turbulence as we will also be making a backwards-incompatible toolchain update and migrating everything mid-way.

Today is Day 0 is not a weekday so you don't get a dapp, but anyone interested should get familiar with dapple, which is the tool used to build/link/test/deploy dapple packages.

https://github.com/nexusdev/dapple