Stake Ventures Inc.

Simple Convention for Human Readable Terms for Smart Contracts

2016-06-29T17:40:56Z

In the Ethereum world "Smart Contracts" refer to code. On its own a Smart Contract doesn't necessarily create a legally binding contract. A Contract is neither code, nor a PDF file nor a printed signed document.

A legally enforceable contract describes a (1) relationship between 2 or more parties (2) with rights and obligations attached which (3) is enforceable by a governmental authority.

A contract can be written down on paper or (sometimes) be based on a verbal understanding. Verbal understandings as well as Smart Contracts can be problematic because they may not include all of the terms necessary to address future potential problems.

A human readable contract document is particularly useful because it can describe the relationship in language that the parties understand. It also allow gives non-parties such as external dispute resolution systems (judges, arbitrators, reddit etc.) a roadmap of the expected relationship between the parties. This can used afterwards to clean things up if something bad happens.

Smart contracts are particularly useful when they are able to automate components of human readable contracts and, in doing so, avoiding conflicts that human language and human agreements can sometimes cause.

Software code isn't perfect, however. Indeed, as we’ve seen recently, Smart Contracts can suffer from many of the same problems that verbal contracts have, because smart contract code doesn't include all of the terms that traditional written contracts might include (indemnity, termination, are a few examples).

“But Pelle, Smart Contracts contain all the rules of the contract.”

If we look at Smart Contracts as just code that may be correct. However if it is intended to serve as a legally enforceable contract, the expectations about it may often be more important than what is written down and in code.

One limitation Smart Contracts currently face is their inability to monitor and enforce off-chain obligations. But it can’t express what happens off chain. I expected 10 sacks of Coffee delivered on August 1st and you didn't deliver. It also can’t express every single possible failure case in the future, such as unexpected bugs or regulatory attack.

Scope: Provide a simple technical foundation that business and legal minds can build on

Solidity and Ethereum need a framework that allow lawyers, business people and developers to work together to make it easier to create legally enforceable Smart Contracts.

To that end, I've created this proposal and example code that begins to allow this, with the specific aim of helping Solidity and Ethereum developers do what we’re good at and let lawyers and business people do what they are good at.

This proposal can easily be added to any new Solidity smart contract. It can be done at various levels. At the minimum add the first step.

1. Upload your terms to IPFS and store the hash at a known place

This is simply adding the convention of adding a single line of code to your Solidity contract:

contract FancyDAO {
  bytes32 public terms = 0x28678b42f7fcf403009f1805e4e...;
}

Now wallets and other third party code can always extract the terms for your Smart Contract.

IPFS is a distributed protocol allowing you to store any static data. It is a great complement to Ethereum.

For more advanced functionality you can use my new Solidity library SolidTerms.

2. Add Acceptance

In many cases publishing the terms alone is fine. You maybe be able to get away with saying something like: “Sending Ether to this smart contract means you’ve accepted the terms”.

But particular when dealing with money it is often a good idea to have a firm procedure of recording acceptance of the contract.

To avoid you writing your own I have written this simple Abstract Contract Acceptable that implements this.

import "Acceptable.sol";
contract FancyDAO is Acceptable {
 bytes32 public terms = 0x28678b42f7fcf403009f1805e4e...;

 function split(...) hasAccepted public {
   ...
 }
}

This adds an accepted mapping to the contract and a public function called accept(bytes32 _terms).

Once a user through their wallet calls accept it is recorded on the blockchain.

The library also adds a nice little modifier called hasAccepted that you can use on your own functions. This requires acceptance to be able to call the given function.

Did you notice that the accept(bytes32 _terms) function takes a parameter? It requires the user to present the same IPFS hash of the terms. This is primarily to encourage the wallet user interface to actually load and show the user the terms.

3. Add change management

Sometimes contracts need to change and the terms behind them as well.

You could write your own, but if we have a common interface, third party tools can be created allowing non technical people to update the terms in a simple transparent manner.

I have a simple abstract contract here Changeable that will allow you to add this with very little code to your own Smart Contracts

import "Acceptable.sol";
contract FancyDAO is Acceptable, Changeable {
 bytes32 public terms = 0x28678b42f7fcf403009f1805e4e...;

 // Override this method to decide who can change therms
 function canProposeChange() constant returns(bool) {
   return (msg.sender == offerer );
 }
// Adds the following function to be called from a GUI with changed terms
// function proposeChange(bytes32 _terms) {};

// Now you can ensure that the function caller has always accepted the latest version
function split(...) hasAcceptedLatest public {
   ...
 }
}

4. Standard Events

It would be useful to have a set of standard events that auditing tools and wallets can listen to.

Here are the 3 most basic events I think are necessary:

// Event created when agreement is reached (active)
event AgreementReached (
  bytes32 indexed terms
);
// Event to be created when terms are accepted by a single party
event TermsAccepted(
  address indexed accepter,
  bytes32 indexed terms
);
// Event to be created if Terms are changed
event TermsChanged(
  address indexed changer,
  bytes32 indexed terms
);

Example implementations

Here are 3 more complete examples:

TermsOfService A simple complete Terms of Service implementation that can be used in your own Smart Contracts
SimpleAgreement An example of a 2 party negotiable contract. An offerer invites the invitee and they both can change the contract until they both accept it. This could be used as the basis for a sales or consulting contract.
RicardoCoin Is an example of adding the TermsOfService contract to a really simple token issuance contract.

Isn’t this a Ricardian Contract?

Well I’m glad you asked. This is indeed my interpretation of a Ricardian Contract. I have another article drafted on why Ricardian Contracts are awesome. So watch this space.

Format of Terms

Lawyers would probably instinctively post a PDF file of the terms to IPFS and use that. I would recommend against that as it would be useful that they can easily be viewed in a mobile app or web browser. So I would personally recommend plain text, markdown or html.

An IPFS hash can actually point to a folder. So you could have multiple files as part of your terms.

Technical note regarding storing IPFS hashes in Smart Contracts

IPFS hashes are 34 byte Base58 encoded MultiHash strings. We can easily store 34 bytes in a dynamic byte array in Ethereum, but it is more efficient to store them as a fixed byte32 value.

There may be many of these both in transaction calls, contract storage and events. So I think we might as well save the gas The first 2 bytes just tell MultiHash what kind of algorithm it is.

In javascript you can convert the hex back to IPFS like this:

var bs58 = require('bs58');
function hex2ipfshash(hash) {
 return bs58.encode(new Buffer("1220" + hash.slice(2), 'hex'))
}

function ipfs2hex(ipfshash) {
 return "0x" + new Buffer(bs58.decode(ipfshash).slice(2)).toString('hex');
}

I will shortly release a small javascript library for wallet and dApp developers to use. This will include the above functions as well as extract the full terms of any SmartContract that supports the basic conventions outlined above.

Thanks to Stephen Palley and Ian Grigg for reviewing this. Neither my writing nor their review should be considered legal advice.

Robot handshake image copyright: alperium / 123RF Stock Photo

Crisis based forking can pierce the Decentralized Veil of Ethereum

2016-06-17T18:01:13Z

A large vulnerability has been found in The DAO and someone is at the time of writing funneling all it’s Ether out.

A proposal has been made for the various Ethereum implementations to:

Create a Soft Fork to freeze funds in any DAO sharing the same code as The DAO. This would stop funds being released while giving the community time to correctly implement the next step
A hard fork allowing people to get their funds out

On the sound of it to most smart compassionate people in particular programmers, this sounds like a good solution. However it introduces certain major risks:

Pierces the decentralized veil of Ethereum

What does this mean? A corporation is a legal fiction, separated from its share holders from a legal liability standpoint. This separation is known in law as the corporate veil.

If shareholders don’t follow official governance procedures and treat the companies property as their own they can lose the legal protection of this veil. This is known as Piercing the corporate veil.

Ethereum and Bitcoin have their own veil protecting the developers and promoters. You could call it the “veil of decentralization”. Core developers can not be held legally liable through this, since the code is run by independent miners and written by multiple code implementations.

These same developers are now coming up with and promoting a fix that is unrelated to the protocol itself. By doing so they are unintentionally opening the possibility of “The veil of Decentralization” being pierced.

In other words they are setting precedence for future interventions and even more worrying introducing personal liability for themselves in these cases in the future.

Where before there was plausible deniability if someone lost funds, now they have said we have the ability to act if there is enough pressure.

For a developer this may not make sense, but this is exactly the kind of hole a lawyer will go for in the future.

Converts a large but limited liability by investors in to a unlimited liability for Ethereum core team

As it stands the current legal liability is primarily on the investors. Securities lawyers and regulators would have a pretty good case in court that the promoters of The DAO (Slock.it UG) and it's principals are also liable.

Creating this takes the pressure off of those 2, but adds a large potential future liability onto the Ethereum Foundation and Vitalik Buterin instead. Which is a shame as they are only trying to help out the investors.

Turning Ethereum into a semi-permissioned ledger

No, this does not mean we need to show ID to be able to have an Ethereum account. It does mean that there is precedence for blacklisting code and accounts in the future.

Now we have shown that we can blacklist code we have unintentionally opened the flood gate.

Moral Hazard

The DAO’s developers and investors were warned repeatedly of the risks of releasing a large piece of code without some sort of investment cap.

I wrote the following a couple weeks before the launch:

It may seem clever to call it "The DAO". Yet it also takes the fate of "The DAO" and forever more taints any future DAO's with it. Let's say there is flaw in the code and all funds invested are lost for ever. Or a group of hackers get a bunch of naive investors investing via data fields on exchanges to sign over control to them. Or any number of other possible failures. Now the word "DAO" will forever be tainted with this failure. This is not just academic. Bitcoin was tainted by association with MTGox. Just imagine if MTGox had been called "The Bitcoin Company"? They would have been free to call it that. But it would have done even more harm to bitcoin that it has. The DAO a Rebel Without a Cause

To which Stephan Tual from Slock.it wrote:

Unencumbered by a centralized control structure and at the center of arguably the most exciting technology development of the decade, The DAO will initially set its sights on the Blockchain + IoT economy but is ultimately free to engage on any product or services it may desire. With such powerful attributes, it’s no wonder this DAO is called The DAO. Slock.it UG commits to “The DAO”

Ironically same Stephan Tual is begging for what is really a centralized fix.

The arrogance of both was very similar to the arrogance of wall street before the crash in 2007.

A fork to protect them is very similar to a bank bailout. It creates Moral Hazard.

MTGox taught the Bitcoin world a lot of lessons. These lessons were important to be had by individual investors as well.

If the promoters and investors are able to go unscathed away, it is very likely that none of them have learned from this experience.

Nassim Taleb argues in Anti-Fragile that pretty much all that happened up to the Wall Street crash was due to such lack of Skin in the Game.

Decision making in DAOs through voting or buying

2016-05-17T15:42:58Z

Direct voting does not work well outside small groups that know each other. Think New England town meetings, a group of business partners.

The traditional way to get around this in a large group is through representative democracy. Once in a while we vote in a small group of people that can vote between themselves.

Shareholder votes are not important in traditional companies

In traditional companies this normally works by the shareholders just accepting the current board or insiders proposals for board members. Actually it probably happens mostly through inaction by shareholders. Every now and again you will get share holder fight, but it’s the exception not the rule.

Most shareholders are quite happy with this, because they actually made their original decision when they bought the share in the first place. In public markets the real voting happens when people buy or sell the shares.

You can look at shareholder voting as a final safety for investors, allowing them to kick out the board. Even though it rarely happens.

Direct democracy in “The DAO” with 18,191 anonymous voters

Now in “The DAO” we have an experiment containing at the time of writing $130M worth of Ethereum and 18,191 Token Holders. It is based entirely on the idea of ballot voting proposals.

Dan Larimer writes pointedly about his experiences creating a similar experiment with Bitshares. It is pretty hard to see how it can possibly work. Maybe no proposals will ever be voted through.

Use a market based approach instead

I have been working on DAO like ideas for over 15 years and my idea was always about having lots of DAO’s each working on well defined problems.

Real voting on the success of projects in free markets (and the true wisdom of the crowds) comes from people buying and refraining from buying.

Ethereum allows us to have an unlimited amount of small and large DAO’s, but each focusing on solving a specific problem.

If I believe in the team, the problem and the solution I can buy in. If I don’t I don’t buy. Thats how markets work, and how it should work with DAO’s.

It may be clever from a technical standpoint to emulate traditional institutions using Ethereum Smart Contracts. But if you’re implementing a broken system, you just have a broken system implemented on Ethereum.

Does traditional voting still have a place in DAOs?

It absolutely does. The founding team should be able to vote. Maybe at some point they decide to create an external board for oversight? They should be able to vote as well. This external board could create trust in the project for potential token buyers.

A potential fix for The DAO - A dynamic market driven board

I am a big believer in the ideas of Nassim Taleb about anti-fragility. He is also a proponent of many of small experiments instead of a couple of large ones.

Another thing he believes in is skin in the game. Decision makers need to risk their own money.

So you could create a fluid market driven board by simply having a minimum requirement of say 5% of tokens to be able to vote. At the same time increase quorum to 50% of all of these token holders.

This may seem counter intuitive but it would allow a small group of knowledgeable investors buy enough tokens on the free markets to make decisions that matter. Small token holders would simply vote by buying and selling their tokens.

Balance Sheets and Blockchains

2016-05-10T17:05:35Z

Balance sheets are useful terms from accounting showing a snapshot of the financial state of a company. Balance sheets consists generally of 3 columns:

Assets
Liabilities
Equity

These map directly to the Rights and Obligations I rambled on about a couple of weeks ago.

An Asset is a Right and a Liability is an Obligation, just with numbers assigned to it. The Equity I will get to shortly.

As an example here is Apple’s latest balance sheet in a simplified form:

Assets	Liabilities	Equity
305,277,000	174,820,000	130,457,000

For more details see theFull Quarterly Balance Sheet for Apple

This breaks down to what accountants call the Balance Sheet equation:

assets - liabilities = equity

Essentially it is a simple way of getting an overview of the current value of a business. Equity is the current value of the business as owned by the shareholders.

Blockchains are ledgers

Everyone knows that Blockchains are ledgers, but a lot people don’t know what ledgers are.

Essentially ledgers are long lists of transactions between accounts. The transactions are added up to create balances.

Creating a balance sheet is thus pretty simple. Adding up any debts and any assets.

Bitcoin’s balance sheet

Traditional currency accounting has a central issuer that issues currency. All currency issued is a liability on it’s balance sheet which is balanced against assets held somewhere. Traditionally gold now often USD. With Fractional Reserve banking this is a lot more complex, so I won’t go into that now.

Bitcoin does not have an issuer unless you count as some people do Bitcoin as a DAO (Decentralized Autonomous Organization).

So what would be a helpful way of creating a balance sheet for Bitcoin?

Bitcoin’s current circulation is roughly BTC 15.5M.

Using the traditional currency balance sheet:

Assets	Liabilities	Equity
0	15.5M	(15.5M)

This is based on the fact that Bitcoin itself does not have any assets. I’m not sure this is the correct way of modeling it.

Maybe if we look at it as a DAO it makes more sense:

Assets	Liabilities	Equity
15.5M	0	15.5M

I’m still not 100% happy with it, but I think that is the best way of squeezing bitcoin the currency into a traditional balance sheet.

Balance sheets for Bitcoin Addresses

As I mentioned in the Rights and Obligations article you either own Bitcoin or you don’t in it’s simplest form. This would mean that any bitcoin owned by anyone would just be an asset:

Assets	Liabilities	Equity
BTC 1	0	BTC 1

So if you look at any address on a blockchain explorer it is pretty easy to work out it’s balance sheet.

What about the Equity? Well a Bitcoin address is not an identity it is just an account. An account has an owner. That owner may or may not be known. But the Equity is the owners share of the account. Which in Bitcoin is always the same as the Balance.

Ethereum Smart Contracts

Ethereum Smart Contracts introduce the concept of obligations into the blockchain world. Therefore we must also talk about liabilities now.

In my previous Escrow Smart Contract example the Smart Contract controls funds sent to it by a buyer to send on to a seller.

Assets	Liabilities	Equity
ETH 1000	ETH 1000	0

The contract has a balance of 1000 ETH, but those 1000 ETH are owed to the seller, thus it has 0 equity itself.

Token Contracts

Basic Token Contracts with a central issuer are in some respect just centralized currencies. The issuer holds the funds but the token holders are owed some sort of value.

For the token holders each token issued is essentially an asset, which is why us old timers in the Crypto space used to call these Asset contracts instead of tokens.

In the following example I am drastically over simplifying this by having an ETH denominated Token Contract to show the basic accounting.

1000 people have each bought 10 ETH’s worth of our ETHR token:

Assets	Liabilities	Equity
ETH 10,000	ETH 10,000	0

Again you can see zero equity in this approach, the value is transparent in the contract.

Floating exchanges rates means risk

Where things start getting complicated is if you decide to issue USD denominated tokens instead of ETH denominated tokens.

Lets say your token holders bought with ETH when the USD/ETH price was $5 and now the price is $10.

Assets	Liabilities	Equity
ETH 10,000	ETH 5000	ETH 5000

You as the issuer have now made ETH 5000 in equity.

But what happens if the price dropped instead? Your token holders bought at $10 and the price is now worth $5.

Assets	Liabilities	Equity
ETH 10,000	ETH 20,000	(ETH 10,000)

Oops disaster. Now your token holders want to get their money out and you now need to find ETH 10,000.

This is where we need some level of off-blockchain integration. This kind of risk is pretty easy to manage in the “real-world” essentially you would just immediately sell the ETH for USD and keep it in an USD account.

But of-course this is not visible on Ether.Camp, so you will need some kind of legal contract promising off blockchain enforcement of your promises.

The DAO Balance Sheet

All the talk at the moment is about the poorly named The DAO which at the time of writing has issued 371.96M tokens each sold for 1/100 of an ETH.

There are many discussions of what a DAO is, but for the sake of accounting purposes I will define a DAO an organization whose ownership is defined by tokens. This is very similar to a traditional Corporation and the accounting is also very similar.

So at the time of writing the balance sheet of the particular instance of a DAO currently called “The DAO” looks like this:

Assets	Liabilities	Equity
ETH 3.72M	0	ETH 3.72M

The SmartContract allows any token holder to take out their share of current equity at any point.

The balance sheet gets more complex when Proposals starts being approved. I am currently researching this and will write a more in-depth article about it later.

But to give an example, The DAO could invest a lump sum into a business in exchange for future rewards.

This would lower the liquid ETH assets by the lump sum amount and replace it on the balance sheet with a longer term asset, called Reward Tokens. I’m still trying to understand how Reward Tokens work. But the valuation of them will be important in the future.

Balance Sheets of regular Ethereum Addresses

Regular Ethereum Addresses are similar to Bitcoin Addresses in that they can only contain Assets. We need Smart Contracts to manage Liabilities.

Unlike Bitcoin Addresses they can contain many types of assets. So an Ethereum Address may have bought 10,000 “The DAO” tokens.

This address would currently have a balance sheet looking like this:

Assets	Liabilities	Equity
ETH 100	0	ETH 200
THEDAO 10,000	0

Mind you the valuation of DAO token will change in the future. Valuation of assets is a complex issue.

There is a fundamental price which is the Stock Holders Equity and there is a market price. In Apple’s example above if you divide the Equity by the amount of issued shares you will probably not get the same number as Apple’s current stock price.

So while it is currently simple to calculate The DAO’s equity value. Future Market price will take into account future revenue, management, risk and sentimental thoughts into account.

A useful tool

The Balance Sheet is only one of the 3 traditional corner stone reports in accounting. The others being the Income Statement (aka Profit/Loss) and the Cashflow Statement.

Balance Sheets can also seem the most abstract and the hardest to understand. Yet it proves a really useful tool for us, in particular in understanding and analyzing Smart Contracts.

Counter-Party risk on block chains

2016-05-03T14:26:48Z

In my previous article I talked about Rights and Obligations and how they apply to blockchains.

If you have the right to someone’s obligation there may be a risk that the other party can’t (or won’t) comply. This is called Counter-Party risk.

A simple example of counter-party risk is if you lend money to your nephew who lives on his parents couch playing computer games all day long, there is a risk he doesn’t pay it back.

Differences in counter-party risk explains the differences in prices for currencies and shares. It also explains why different levels of risk provides different interest rates, both for personal loans and for individual country’s bond rates.

There are whole industries of rating agencies that are supposed to analyze this risk and allow people to take this risk into account.

Counter party risk in personal banking

As mentioned in the previous article a bank account is defined by an agreement between you and the bank.

As a depositor your bank balance is an Asset (or a right) and for your bank it is a Liability (or an obligation).

Of the money the bank owes you is invested elsewhere. Such as in loans to individuals or more complex structures.

In the case of an individual loan. The right holder is now the bank and is an asset on their balance sheet and is a liability (or an obligation) for the borrower.

In theory as the depositor you are now affected by the counter party risk involved with your bank lending money to another individual.

Assuming the bank If they do fine and people trust what they are doing the whole system works well. When it doesn’t it is mainly because the bank does not handle it’s own counter party risk well.

In this case we start seeing bank runs as we saw recently in Kenya and on a larger scale in Cyprus. The depositors who were not able to access their funds, felt counter-party risk up front and personal.

Systemic Risk

We have only talked about the simple basic Rights and Obligations here. But in the traditional financial system the basic Right and Obligation between me and my bank is protected by many layers of other Rights and Obligations.

Settlement Networks
Correspondence banks
Rating agencies
Custodial services
Central Banks
National governments

We don’t see these directly but we are all affected by them. When there is a risk in the system itself and the interaction between all it’s parties, it is called a systemic risk.

The end result is that the safety of money in a personal savings account in Germany, can and has been affected by mortgage holders in Florida.

Counter-Party and Systemic Risks in Bitcoin

The counter party risk is thus the trust in the bitcoin system itself. Every now and again people loose trust in the bitcoin system and the price falls, then it proves yet again that it survived and the price rises. You could also call this systemic risk.

Another kind of Systemic Risk in Bitcoin are when exchanges and wallet services are hit by fraud and hackers. See what happened at MTGox as a great example. This caused the bitcoin price to plunge even though there was no problem with Bitcoin itself.

Counter-Party risk in Ethereum

If a smart contract is entirely determined by the rules of the code and has no concept of rights outside the Ethereum network, there is no Counter Party risk.

There is still the same Systemic Counter-Party risk that Bitcoin has. You could also argue that the success or failure of a large scale Smart Contract on Ethereum could affect the value of Ethereum, even though it strictly speaking is not directly related.

Counter-Party risk in Smart Contracts with external obligations

Any right being promised that requires someone to do something outside the Ethereum system has a counter-party risk. It is the same kind of counter-party risk as found in traditional financial instruments, only with fewer institutions to help enforce them.

If there is an external obligation there is an implied legal contract. It would be best to have some sort of human readable contract documenting the rules and even determining which venue (court, arbitration etc.) any disagreements should be dealt in.

I am trying to work out good mechanisms for doing this, but I think it would be a good idea to a human readable contract stored on IPFS with the IPFS hash stored in the Smart Contract.

Technical risk in Smart Contract

Smart Contracts are written by humans and like any other program things go wrong.

As programmers we learn from this, fix the code and deploy a new version.

This is much harder to do with Smart Contracts. They have to be specifically written to be able updateable. A lot of work in the Ethereum community is being spent on solving this problem.

Until this problem is solved, the best way of using smart contracts are for solving small isolated problems and having short lifetimes.

Fraud in Smart Contract

There is also a fraud risk in Smart Contracts. Someone can easily write bad code to defraud rights holders.

Vitalik points out this example of underhanded solidity where the programmer in plain site pays out all the funds to himself instead of the rights holders.

These are problems that we can mostly solve, but it will take a while for the tools to be created. Ether.Camp are doing possibly the greatest job in this space right now, through their contract auditing tools and their excellent Blockchain Paparazzi posts.

I would recommend for the time being only dealing with smart contracts after checking them out on Ether.Camp first.

Systemic risk in Smart Contracts

When we have many collections of rights and obligations tied up as in some of the more complex proposals for Smart Contracts, we start running into the same unintentional systemic risks as found in the traditional financial system.

Lets say your Smart Contract is well written, but it relies on external Smart Contracts to work. This means there is a greater risk involved.

This is fine and one of the great potentials of Ethereum is the idea of Smart Contracts interacting. It is just important to take these risks into consideration.

Small Composeable Contracts vs Jumbo Kitchen Sink contracts

Don’t try to do too much in a single contract. Make sure there is a mechanism for fairly replacing external contracts. Also make it sure to have a mechanism to be able to shut the contract down fairly and return funds. When I say fairly, it still needs to respect the rights and obligations of each party.

Instead of having one large contract managing many different kinds of Option contracts. It would be better to have each Option Contract be it’s own Smart Contract.