The EXP.DAO Is a Revolutionary New Form Of Governance

As you are all well aware, Slock.it’s #TheDAO had a pretty rough week. What happened was that a member of The slockit DAO used a very clever loophole in the contract, coupled with another clever loophole that allowed the attacker to repeatedly send himself ether during a dao split. Basically, the intended purpose of the splitting method of the DAO was to allow for anyone who wanted to secede from The DAO the ability to do so by creating a child DAO, then making themselves the only curator, whitelisting their own address and then create a proposal to withdraw their own funds out. A pretty cumbersome exit strategy, but that is neither here nor there. The problem is, the attacker withdrew to a special contract that had a default function that re-entered The DAO to repeat the withdraw ad infinitum. This would of been ok except that the balance wasn’t updated until AFTER the send function went through, allowing the attacker the option to drain TheDAO completely.

This event has sparked a huge debate on how to handle the attacker, but that is not what we are focusing on here, how to react, but rather, how to prevent this from happening in the first place. The scope of the attack and damage could have been almost completely mitigated by using the methods explained in the Expanse Whitepaper;

Two words…

Compartmentalization and limits.

The Expanse DAO, as described in the whitepaper, is a system of parent and child divisions that are completely isolated from each other. At its most basic embodiment, there is mother division that has three child divisions. We named these divisions, the founders division, the collective division, and the board of directors division. Each child has the ability to submit an allowance proposal to its parent division. An allowance proposal can only be sent to a child, if 2/3rds of the siblings agree to the proposal.

So how would this have kept TheDAO from being looted?

Easy.

Example: Say there is a bad actor that creates a spending proposition with the collective division. The collective division is a direct democracy smart contract that has a balance of $1,000,000. A participant then submits a spending request but he knows of a spending loophole that will allow him to receive more than he should and he drains the collective of $1m.

That’s a terrible thing, the community just lost $1m. The Collective is now out of money, and all the other proposals can’t be funded anymore, complete mayhem. The only way this division can get more funding is if it submits an allowance proposal to the parent division, and the siblings agree to send more. But why would they spend more? That contract is inherently flawed. The whitepaper also outlines the need for an upgrade ability, so a contract can shed its old self to become new with updated code. Contract versioning, but that’s another post for another time.

We talked about compartmentalization now let’s talk about limits.

Imagine now for a moment, there is a bad actor extorting funds from the dao and somehow controls 2/3s of the other divisions. So he can pass allowance proposals himself. That sounds like worst case scenario. Indeed it would be hectic. The Expanse DAO will have failsafes in the form of limits both time limits and amount limits. First of all, child divisions can only request allowance from their parents once a month as determined by the amount of blocks in a month, and second of all, only at a max rate of some% of the total of their parents balance. So, each time they successful receive their allowance they lower the max amount they can receive next time. This adds buffers in place that give the community time to react without having to softfork or hardfork or spoon anything.

In conclusion, we can’t predict the future, we can only try and put out the safest, most well thought out code possible. With meticulous planning, and implemented failsafes like compartmentalization and limit constraints, we increase of our odds of successfully warding off unwanted behaviours that might compromise our projects and what we stand for.

Read more at http://expanse.tech