/ smart-contracts

AMIX The American Information Exchange

AMIX

Split Contracts

When people contracted with each other through the AMIX system, they expressed the contract in two parts: one that both human and the AMIX software could understand, and that the AMIX software could enforce; and the other as free form text only for humans to interpret, but unforgeably attached to the first part.

For example, Alice and Bob may have committed to a mini-consulting contract for Bob to deliver to Alice a document answering certain questions Alice needs answered. The automated part of the contract might say

• Alice is to pay Bob $100 on delivery of the deliverable
• Alice is to pay Bob $500 on acceptance of the deliverable
• Alice has 30 days to evaluate the deliverable

The free form text expresses the question Bob is to answer, and that answers to these questions constitute an acceptable deliverable.

Later, when Bob delivers a document as a deliverable, Bob is making a claim that this deliverable meets the criteria described. At this point, Bob is assured by Amix of receiving the $100, whether or not Amix can collect the corresponding $100 from Alice. (Ideally, such a risk-bearing intermediary would be a separate party from a contract-host, but AMIX bundled these together.)

When Alice looks at the deliverable, she may hit an "approved" button, in which case Bob likewise gets $500. If 30 days go by without Alice taking any action, then she has implicitly approved, and Bob still gets $500. Alternatively, Alice may reject by making a claim that the deliverable does not meet the description. This claim directly conflicts with the claim Bob made by providing the deliverable. The text of the agreement, the text of the deliverable, and the two conflicting claims can now go to human arbitration.

Why is the Contract Smart?

This systems lacks many of the attributes all of us are interested in building. However, its power came from embodying a complex contractual relationships in computational material. This power would not follow just from having a strongly secure untraceable payment system.

Current contracts are passive pieces of paper, only to be interpreted by humans. The phrase "possession is nine tenths of the law" means that current physical location and control is a huge bias in resolving a dispute. Why? In the absence of costly arbitration, we are left with such possession as the outcome.

In normal consulting, if Alice doesn't pay Bob, chances are Bob's screwed. Alice's lack of payment is inaction, not action, and can not obviously be treated as a factual claim that could be challenged. By contrast, in our the above contract, Alice must act and claim in order to not pay. Inspired by AMIX, one might instead say

Behavior will be nine tenths of the law

When the contracting parties cannot turn the entire contract into computationally enforced behavior, they can instead design a split contract--a set of computational behaviors that bias the outcomes, with the remaining non-computational part of the contract being designed to work in the context of those biases.

Beyond Amix

On the down side, AMIX was a non-distributed insecure system that took a conventional stance for dealing the jurisdictional issues. In particular, AMIX knew the true names of its customers.

AMIX was also non-extensible. It had one extraordinarily well designed smart contract, but if customers of AMIX wanted to write new code to embody a new contractual relationship, AMIX couldn't help them. (These aren't criticisms -- AMIX did everything described above in late 80s/early 90s, before the web. It was extraordinary.)

So what are we trying to enable with E? A good approximation is a strongly secure, completely decentralized, richly extensible AMIX. E especially shines as a language for clearly expressing complex contractual relationships.

For example, at the Sun Labs Webmart project (one of the ancestors of E) we created and deployed a lightweight market institution to solve the scarcity of an individual rooftop satellite receiver dish. The dish was bought as a resource for the lab as a whole, but it could only be pointed in one direction at a time. How should this right to point be allocated? We created a futures market in time slices, built from distributed capabilities.

Starting with an object representing the ability to control the satellite, a small amount of code was able to create derivative rights, in layers, building up to tradable exclusive rights to command the dish during future time slots. These rights could be exchanged via reusable escrow exchange agents and auctions, neither of which knew about futures, much less satellite dishes. We expect to be posting simple E code for escrow-exchange, auctions, futures, etc on the ERights.org site soon.

See the Agoric Open Systems papers for many ideas about use of fine-grained markets in computation. We believe there's a smooth spectrum

• from agoric computational markets for computational agents,
• through fully automated contracts with human decision makers -- like the Sun Labs futures market,
• to the split contracts (partially smart, partially human arbitrated) of AMIX.

We expect E to cover this spectrum, but this time we're focusing on split contracts first.