diff --git a/docs/Block.md b/docs/Block.md
new file mode 100644
index 0000000..b35642e
--- /dev/null
+++ b/docs/Block.md
@@ -0,0 +1,51 @@
+# Block
+
+A Block instance represents the information on a block in the bitcoin network.
+Note that creating it takes some computing power, as the tree of transactions
+is created or verified.
+
+Given a hexa or base64 string representation of the serialization of a block
+with its transactions, you can instantiate a Block instance. It will calculate
+and check the merkle root hash (if enough data is provided), but transactions
+won't neccesarily be valid spends, and this class won't validate them. A binary
+representation as a `Buffer` instance is also valid input for a Block's
+constructor.
+
+```javascript
+assert(Block.isValidHeader(data);
+assert(Block.isValidBlock(data);
+
+var block = new Block(hexaEncodedBlock);
+assert(block.id && block.hash && block.id === block.hash);
+assert(block.version === Block.CurrentVersion);
+assert(block.prevHash);
+assert(block.timestamp);
+assert(block.nonce);
+assert(block.size);
+assert(block.transactions[0] instanceof Transaction);
+```
+
+## Navigating through transactions
+
+The set of transactions in a block can be explored by iterating on the block's
+`transactions` member.
+
+```javascript
+for (var transaction in block.transactions) {
+  // ...
+}
+```
+
+It is also possible to explore a block's Merkle tree of transaction hashes.
+Head to the [Merkle tree](./DataStructures.html#MerkleTree) documentation for
+more information:
+
+```javascript
+var root = block.tree.root;
+assert(root instanceof bitcore.DataStructures.MerkleTree.Node);
+assert(root.hash === block.id);
+assert(root.isLeaf === false);
+assert(root.left instanceof bitcore.DataStructures.MerkleTree.Node);
+assert(root.right instanceof bitcore.DataStructures.MerkleTree.Node);
+assert(root.left.left.left.left.content === block.transactions[0]);
+```
diff --git a/docs/Crypto.md b/docs/Crypto.md
new file mode 100644
index 0000000..86d5b63
--- /dev/null
+++ b/docs/Crypto.md
@@ -0,0 +1,36 @@
+# Crypto
+
+The cryptographic primitives (ECDSA and HMAC) implementations in this package
+have been audited by:
+
+* The BitPay engineering team
+
+## random
+
+The `bitcore.Crypto.Random` namespace contains a single function, named
+`getRandomBuffer(size)` that returns a `Buffer` instance with random bytes. It
+may not work depending on the engine that bitcore is running on (doesn't work
+with IE versions lesser than 11).
+
+## bn
+
+The `bitcore.Crypto.BN` class contains a wrapper around
+[bn.js](https://github.com/indutny/bn.js), the bignum library used internally
+in bitcore.
+
+## point
+
+The `bitcore.Crypto.Point` class contains a wrapper around the class Point of
+[elliptic.js](https://github.com/indutny/elliptic.js), the elliptic curve
+library used internally in bitcore.
+
+## hash
+
+The `bitcore.Crypto.Hash` namespace contains a set of hashes and utilities.
+These are either the native `crypto` hash functions from `node.js` or their
+respective browser shims as provided by the `browserify` library.
+
+## ecdsa
+
+`bitcore.Crypto.ECDSA` contains a pure javascript implementation of the
+elliptic curve DSA signature scheme. 
diff --git a/docs/Encoding.md b/docs/Encoding.md
new file mode 100644
index 0000000..565c7a7
--- /dev/null
+++ b/docs/Encoding.md
@@ -0,0 +1,20 @@
+# Encoding
+
+The `bitcore.Encoding` namespace contains utilities for encoding information in
+common formats in the bitcoin ecosystem.
+
+## Base58
+
+Two classes are provided: `Base58` and `Base58Check`. The first one merely
+encodes/decodes a set of bytes in base58 format. The second one will also take
+the double `sha256` hash of the information and append the last 4 bytes of the
+hash as a checksum when encoding, and checking this checksum when decoding.
+
+## BufferReader & BufferWriter
+
+These classes are used internally to write information in buffers.
+
+## Varint
+
+The bitcore implementation uses a quite complex way of compressing integers
+representing the size of fields.
diff --git a/docs/Hierarchical.md b/docs/Hierarchical.md
new file mode 100644
index 0000000..44c0f6e
--- /dev/null
+++ b/docs/Hierarchical.md
@@ -0,0 +1,12 @@
+# Hierarichically Derived Keys
+
+Bitcore provides full support for
+[BIP32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki),
+allowing for many key management schemas that benefit from this property.
+Please be sure to read and understand the basic concepts and the warnings on
+that BIP before using these classes.
+
+## HDPrivateKey
+
+This class initially meant to share the interface of
+[PrivateKey](http://missing-link) but add the ability to derive new keys.
diff --git a/docs/Input.md b/docs/Input.md
new file mode 100644
index 0000000..135b6af
--- /dev/null
+++ b/docs/Input.md
@@ -0,0 +1 @@
+# Input
diff --git a/docs/Networks.md b/docs/Networks.md
new file mode 100644
index 0000000..40dff2c
--- /dev/null
+++ b/docs/Networks.md
@@ -0,0 +1,23 @@
+# Networks
+
+Bitcore provides support for both the main bitcoin network as well as for
+`testnet3`, the current test blockchain. We encourage the use of
+`Networks.livenet` and `Networks.testnet` as constants. Note that the library
+sometimes may check for equality against this object. Avoid creating a deep
+copy of this object and using that.
+
+## Setting the default network
+
+Most project will only need to work in one of either networks. The value of
+`Networks.defaultNetwork` can be set to `Networks.testnet` if the project will
+needs only to work on testnet (the default is `Networks.livenet`).
+
+## Network constants
+
+The functionality of testnet and livenet is mostly similar (except for some
+relaxed block validation rules on testnet). They differ in the constants being
+used for human representation of base58 encoded strings. These are sometimes
+referred to as "version" constants.
+
+## Source
+TODO: Include source here
diff --git a/docs/Opcode.md b/docs/Opcode.md
new file mode 100644
index 0000000..713d29c
--- /dev/null
+++ b/docs/Opcode.md
@@ -0,0 +1 @@
+# Opcode
diff --git a/docs/Output.md b/docs/Output.md
new file mode 100644
index 0000000..22e0f66
--- /dev/null
+++ b/docs/Output.md
@@ -0,0 +1 @@
+# Output
diff --git a/docs/Script.md b/docs/Script.md
new file mode 100644
index 0000000..b151bef
--- /dev/null
+++ b/docs/Script.md
@@ -0,0 +1 @@
+# Script
diff --git a/docs/Signature.md b/docs/Signature.md
new file mode 100644
index 0000000..e400025
--- /dev/null
+++ b/docs/Signature.md
@@ -0,0 +1 @@
+# Signature
diff --git a/docs/Transaction.md b/docs/Transaction.md
index cddee12..f8d6333 100644
--- a/docs/Transaction.md
+++ b/docs/Transaction.md
@@ -49,6 +49,7 @@ You can take a look at the javadocs for the [Transaction class here](link
 missing). This document will go over the expected high level use cases.
 
 * from(utxo)
+* fromMultisig(utxo, pubkeys, threshold)
 * change(address)
 * fee(amount)
 * usingStrategy(strategy)