### Contracts

Now that we've explored the ideas of a **Contract**, **Contract Enforcement**, and a **Decision Tree**, we can better understand what makes a Vault Tree Contract unique.

#### Vaults

Vault Tree Contracts are made by assembling simple structures called **Vaults**.

A vault is like a digital lock box that stores a single unambiguous piece of information. This piece of information is needed to continue the execution of a contract beyond a certain event.

The light bulb should turn on when you realize that vaults can hold not only valuable external information, but the **keys to other vaults**.

#### Contract Properties

Like regular contracts, Vault Tree Contracts are still modeled as a Decision
Tree of events and outcomes. Unlike regular contracts, they have the added
benefit of being a **Distributed Cryptographic Contract**. This means: 

* To each event in the contract we add a corresponding vault 
* A contract becomes a structured collection of vaults
* Each Vault encrypts a piece of secret information. This can be external
information such as a _URL_ or a _Bitcoin Wallet Address_. More often, a vault will contain the unlocking key to another vault in the contract.
* The way in which the contract author **chooses to structure** the releationship between vaults, will determine how the contract is **Enforced**.

#### Complete Contracts

Because Vault Tree Contracts should be **self-enforcing** and **programatically executable**, they are by convention [complete contracts].

In the context of the interpreting library this means the following:

* Each **Leaf Vault** in the graph should unlock a set of conditions that represents an acceptable contract **Outcome**.
* There does not exist any combination of conditions that would ultimately fail to unlock a leaf vault.

[complete contracts]: http://en.wikipedia.org/wiki/Complete_contract

#### Contracts as JSON Files

Just as a common contract is often written on a piece of paper, a Vault Tree contract is typed into a single text file that can be copied and distributed to anyone.

We chose the [JSON] file format for respresenting contracts. JSON is becoming the mainstream internet serialization format and can be easily read by both humans and computers.

[JSON]: www.json.org


### Vaults

We discussed earlier how Vault Tree contracts are just a collection of vaults
arranged to enforce the terms of the contract.

Let's take a look at an example vault:

```javascript
"bob_random_vault_key": {
  "fill_with": "RANDOM_NUMBER",
  "lock_with": "KEY['bob_vault_key']",
  "unlock_with": "KEY['alice_vault_key']",
  "contents": "rSGrWGL4mEYtpuIaWO/iVGXAA5UUyLeeImSV3SBXzb+C7DW3"
}
```

It's important to keep in mind that, **every** vault follows this format. This convention for representing a vault should be sufficient to build any type of simplistic or sophisticated contract.

#### Vault Id

The **Vault Id** can be thought of as both the name and the **Unique** identifier of the vault.

In this case we have:

```
"bob_random_vault_key"
```

Try to give meaningful names that give insight into the locked contents held within the vault. Also, by convention vault names should begin with the name of the vault owner.

A vault owner is the contract party that is responsibily for filling and locking the vault. In this simple case we have **bob**, but in an employment contract for example, we may have vault owners named **employer** and **employee**.

It is the responsibility of the contract author to assign vault owners in such a way that there are no contract [moral hazards] or [perverse incentives].

[moral hazards]: http://en.wikipedia.org/wiki/Moral_hazard
[perverse incentives]: http://en.wikipedia.org/wiki/Perverse_incentive

#### Fill With

The **fill_with** field identifies the source of the [Plaintext] contents of the
vault. It can be:

* a value generated by the Vault Tree library.
* external information that is brought into the contract.
* the contents of anther vault.

In the example above, the Vault Tree interpreter knows to generate a simple random number, and place it into the vault.

[Plaintext]: http://en.wikipedia.org/wiki/Plaintext 

#### Lock With

The **lock_with** field identifies the source of the vault's **Locking Key**. 


#### Unlock With

The **unlock_with** field naturally identifies the source of the vault's **Unlocking Key**.

It may not be obvious, but the reference to the Unlocking key does not necessarily need to be the same as the reference to the **Locking Key**. Here are some examples of where this could be the case: 

* The same key is used to lock and unlock the vault, but copies of this key are
* held in two separate vaults. Take a look at the **Block Chain Key Transfer**
* contract to see a good example of this.
* Vault Tree supports the notion of an **Asymmetric Vault** through the _DSL Keyword_

```
DH_KEY
```

An Asymmetric Vault is locked and unlocked with the help of a [Public-Private](http://en.wikipedia.org/wiki/Public-key_cryptography) keypair. Vault Tree's underlying cryptographic library makes this possible by implementing a cutting edge variant of the [ECDH] key exchange protocol.  

[ECDH]: http://en.wikipedia.org/wiki/Elliptic_curve_Diffie%E2%80%93Hellman

#### Contents

As you would expect, this field references the encrypted contents of the vault. In the example above you can see the _Base 64_ encoded ciphertext:

```
"contents": "rSGrWGL4mEYtpuIaWO/iVGXAA5UUyLeeImSV3SBXzb+C7DW3"
```
Here are some items to keep in mind:

* Vaults are either **Empty** or **Closed**, this corresponds to either a **Blank Value** or a **Ciphertext Value**
* If we want everyone to have access to the contents we simply lock the closed vault with a known public value. For a description on how to do this in practice see the _DSL Keyword_

```
UNLOCKED
```