So Slock.it could raise money, obviously. A common complaint right around when Slock.it launched the DAO was that Slock.it planned to offer the first funding proposal on it but only provided a brief 2-week period for review and debate before the voting started. It had the appearance of an attempt at railroading the crowdfunding process for a quick payoff.

Fortunately cooler heads uncovered the problems and spoke out, putting the brakes on. Now it's a big learning experience for the ~23,000 people who blindly jumped on the hypetrain and put money into a flawed investment vehicle. You'd think the first 7 years of Bitcoin would have taught people a lesson that this technology is risky, but dollar signs in the eyes tend to obscure hindsight I guess.

I haven't touched ETH or the DAO personally, but it is unfair to label every investment in them irrational. Over the past 5 years cryptocurrencies have provided multiple opportunities to convert, say, $10k into $100k or even $1M within a year or two; once your networth exceeds a certain amount, risking 1-2% of it on an opportunity like that is arguably wise - i.e. would be worth repeating - even if it does fail spectacularly.

It is certainly true that as long as that reasoning delivers 10-100x+ returns to some of the people some of the time, a giant fount of speculative money will continue to moisten a lot of scammers, con artists, and insufficiently-careful SW developers though.

A contract should present an interface that includes a declaration of its behavior. The declared behavior should be well defined, and if a bug in the implementation is discovered, the contract should be updatable to fix the bug. There could even be futures expressing the probability that a contract will be found to have a bug.

The willingness of participants to use a contract would depend on the chances that something about the interface is bug-prone, untested, etc.

As long as bugs do not result in reversal of money flow, the incentives seem to align properly toward a well-defined approach for declarative contracts.

[1] https://intelligence.org/

The first part, a "declaration of...[future] behaviour," is basically a normal contract.

There ought to be a way to have highly vetted primitives. In meatspace legalese, boilerplate words and phrases are the closest we get to this... once a contract (or open source license, etc.) has been through litigation, its vulnerabilities become better known.

If a dispute gets decided the "wrong" way because a few clarifying words were absent, the contract is modified and future deals use the new contract.

Doing this is a tradeoff. On the one hand it lets you fix bugs and vulnerabilities, on the other your users have to trust you not to abuse your power.

1) a significant delay between the announcement of an upgrade and the actual upgrade (enforced by the blockchain)

2) a mechanism to opt-out or cash out before the upgrade happens