diff --git a/Revault-Tx-Diagram.png b/Revault-Tx-Diagram.png
new file mode 100644
index 0000000..6e3ddc9
Binary files /dev/null and b/Revault-Tx-Diagram.png differ
diff --git a/introduction.md b/introduction.md
new file mode 100644
index 0000000..d1f1ff5
--- /dev/null
+++ b/introduction.md
@@ -0,0 +1,144 @@
+---
+header-includes:
+  - \hypersetup{colorlinks=true,
+            allbordercolors={0 0 0},
+            pdfborderstyle={/S/U/W 1}}
+---
+
+# Revault: A Multi-Party Bitcoin Vault Architecture
+
+The secure storage and transaction of funds is a big challenge to Bitcoin users and especially to companies managing a substantial amount of bitcoins. Traditional controls of expenses are hard to set-up with bitcoin due to its features: censorship-resistance, transaction irreversibility and psuedonymous addresses.
+
+Revault is a self-managed custody solution for multi-party holders (such as a company or their third party custodian) with strong theft mitigation from external parties and internal fund managers. Revault has several novel features; 
+
+- On-chain tiered access control, where stakeholders have primary control and an ability to safely delegate funds to managers
+- Ability to cancel managers' withdrawals from a vault (automatically based on pre-configured policy, or manually)
+- Ability to restrict managers' spending behaviours based on arbitrary policies
+- Physical coercion mitigation using a trapdoor mechanism to move all funds to a preset `emergency vault`
+- Ability to scale-up security investment simply by deploying more internal or external watchtowers.
+
+Revault can be tailor-fit to many organisational structures with custom multi-signature thresholds, time-lock periods, and feature sets. Users can set policies in-line with business logic. Users can start with a simple deployment and scale infrastructure as their security budget increases. 
+
+Contents:
+
+1. [Introduction to Revault](#introduction-to-revault)
+2. [Process and Revault Transaction Types](#process-and-revault-transaction-types)
+3. [Infrastructure and Feature Choice](#infrastructure-and-feature-choice)
+4. [Threat Model](#threat-model)
+
+## Introduction to Revault
+
+Revault is a custody solution with tiered access control. The bitcoins are co-owned by N stakeholders and are accessible with an N-of-N multi-signature. Portions of these bitcoins are delegated to M fund managers as-needed and are accessible with a K-of-M multi-signature but are subject to a set of _restrictive policies_. In practice, this delegation only allows the managers to follow pre-approved unvaulting and spending policies, thus retaining control at the stakeholder level. 
+
+The single-tiered multi-signature approach common today is subject to a trade-off between security (large number of signatures requried) and usability (low number of parties required). By comparison, Revault achieves practical usability through safe delegation to managers who handle the spending process without sacrificing on the security of a large multi-signature.
+
+In addition, Revault comes with an (optional) deterrent feature for emergency scenarios. Before deploying Revault, stakeholders set-up an _emergency vault_. At any time stakeholders can trigger their panic button and unilaterally transfer all bitcoin in custody to the emergency vault. For example if 2 of the 3 stakeholders are abducted or physically threatened, the remaining stakeholder can save funds from theft. This feature drastically reduces the likelihood that a coordinated attack on the stakeholders will be profitable and thus acts as a credible deterrent from physical coercion. 
+
+## Process and Revault Transaction Types
+
+![Revault Transaction Graph. ](Revault-Tx-Diagram.png)
+
+Funds enter custody through Deposit transactions (TXs) as unspent-transaction-outputs (UTXOs) locked to the `deposit output descriptor`, an N-of-N multi-signature among stakeholders. After receiving a deposit, the stakeholders exchange signatures for a set of 4 transactions which are _not broadcast_. These "pre-signed" transactions are used by stakeholders to control the flow of funds and enable the delegation and emergency deterrent features of Revault. As seen in the diagram, they include; Emergency, Unvault, Cancel and Unvault Emergency TXs. 
+
+The Emergency TX is the first to be signed. It would spend a deposit and pay to the `emergency output descriptor` which is a bitcoin script that is harder to unlock than `deposit output descriptor`. Keeping the `emergency output descriptor` private among stakeholders strengthens the emergency deterrent feature as attackers don't know how they would compromise the emergency vault.
+
+Then, stakeholders exchange signatures for the Cancel and Unvault Emergency TXs:
+
+- The Unvault Emergency TX would spend the Unvault TX to pay to the `emergency output descriptor`.
+- The Cancel TX would spend the Unvault TX to pay back to the `deposit output descriptor`.
+
+This way, funds are protected _before_ delegation to fund managers. Finally, the Unvault TX is signed. It spends the Deposit TX and pays to either:
+
+- the managers' K-of-M multi-signature + J cosigning servers + time-lock of X blocks, or 
+- to the stakeholders' N-of-N multi-signature without delay. 
+
+Managers can attempt to use the Spend TX to pay external wallets, but are forced to wait for the Unvault time-lock to expire before their transaction finalizes. During that delay period, a Cancel or Unvault Emergency TX can be broadcasted if the manager is breaching pre-defined policy. 
+
+Please check the complete specification of [transactions](transactions.md) for more details.
+
+## Infrastructure and Feature Choice
+
+Users can choose features to suit their needs. Different features require different infrastructure to operate. 
+
+First, there are base requirements common to all Revault deployments. Each stakeholder and manager controls a wallet and a signing device. An untrusted Coordinator server is used to route messages and thus enable wallets to update and synchronise their state.  
+
+- **Wallet**: an open-source software running with a bitcoind back-end used to keep track of the users' co-owned coins, transaction signatures, and to connect with a signing device and infrastructure servers.
+
+- **Signing Device**: a hardware module used to store private keys, public keys and wallet descriptors and to handle signing operations. As user verification is an important part of the Revault security model, such a device must allow the user to check the message integrity before signing it. 
+
+- **Coordinator server**: An always-online server used for efficient message routing among participants and other servers. Its primary use is for exchanging signatures and Spend TXs. 
+
+With these in place, stakeholders are able to delegate bitcoin to fund managers and manually broadcast Cancel, Emergency and Unvault-Emergency TXs. Fund managers will also be able to manually broadcast Cancel TXs to recover from mistakes. 
+
+Next, users who want additional features will require additional infrastructure components. Each stakeholder may control one or more watchtowers and/ or a co-signing server.
+
+- **Watchtower**: An always-online server that monitors the bitcoin network and chain, as well as polls the coordinator for Spend TXs to perform its responsibilities (automated unvault policy enforcement, automated spend policy enforcement, emergency deterrent). 
+
+- **Co-signing Server**: An always-online server that acts as a 'stupidly simple' anti-replay signing oracle: it will accept to sign any Spend TX, *but only once*. This is necessary to stop the managers from changing the Spend TX destination after the Unvault TX’s time-lock has expired. 
+
+Automatic unvault policy enforcement; requires a Watchtower. By default the Watchtower will broadcast a Cancel TX any time it detects an Unvault TX unless it adheres to a specific pre-configured unvault policy.
+
+Automatic spend policy enforcement; requires a Watchtower and Co-signing Server. By default the Watchtower will broadcast a Cancel TX any time it detects the Spend TX's parent Unvault TX unless it is made aware of the Spend TX in advance and that Spend TX adheres to a pre-configured spend policy. The co-signing server is a means to stop the managers from changing the Spend TX after the Unvault TX's time-lock has expired. 
+
+Automatic Emergency Deterrent: requires a *Watchtower* which monitors the bitcoin network and maintains multiple direct communication channels with the stakeholder. If the stakeholder triggers their panic button, a message is sent to the Watchtower which will broadcast all of its Emergency TXs and Unvault Emergency TXs. To further reduce the incentive of a theft attempt the broadcast of any Emergency TX associated with any vault triggers the broadcast of all Emergency TXs associated with all the remaining vaults.
+
+Please see [here](https://github.com/revault/practical-revault/blob/master/messages.md#processes) for a more detailed look at the processes in Revault. 
+
+The flexibility brought by the active defense mechanism allows any unvault or spending policy to be set and enforced by watchtowers. This therefore largely extends the scope of the possibilities compared to on-chain enforcement and is more in-phase with custodians’ needs.
+
+
+## Threat Model
+
+While Revault has been designed to fix (some of) the threats on existing custody protocols, it introduces new challenges and different assumptions. Revault aims to prevent theft with up to N-1 stakeholders' signing devices being compromised. Here we highlight different attack scenarios, trying to identify weaknesses in the design and finish with a set of security assumptions introduced when using Revault. For more detailed research, check the [Operational Risk Framework](https://github.com/revault/research/blob/master/risk_analysis/paper.pdf).
+
+### Emergency Deterrent Risk
+
+While the Emergency TX is the strongest mitigation in the Revault architecture, it introduces a potential risk of blackmail or losses derived from lack of business continuity (e.g. a block-and-short attack). An attacker (internal or external) getting hold of a single Emergency TX can threaten to push it to the Bitcoin network, triggering a push of all Emergency TXs by the watchtowers. The funds are not at risk in this scenario but getting the funds back online would be long and difficult. On the other hand, an important part of the security model (the deterrent)   is enforced by the pre-signed Emergency TXs being accessible.
+
+### Delegation Risk
+
+An "active defence" mechanism is used to restrict the behaviour of fund managers. Contrary to commonly deployed multi-signature wallets, it takes managers two transactions to spend funds. The first step encodes an on-chain time-lock. During this time, only a single honest watchtower is required to cancel given a breach of the unvault policy. It is expected and encouraged to deploy many watchtowers (at least one per stakeholder). 
+
+To by-pass the spend policy enforcement, an attacker would need to compromise all co-signing servers or to compromise all watchtowers. In the former case, an attacker could alter the Spend TX after the Unvault time-lock expires. In the latter case, a malicious Spend TX would not trigger the broadcast of a Cancel TX.
+
+### Denial-of-service Risk
+
+As a consequence of the N-1 resilience model, there are multiple attacks against the practical usage of the funds:
+
+- signing refusal by a stakeholder
+- unjustified Cancel TX push
+- unjustified Emergency TX push
+- taking down a co-signing server
+- taking down the coordinator
+
+In addition, if the network becomes highly congested, high feerates would trigger nodes to increase their minimum accepted feerate. Unvault TXs that are prepared with an initial 253 sat/kWU feerate could fail to be propagated sufficiently. Managers would lose access to funds delegated to them until stakeholders can re-sign Unvault TXs with a higher feerate. 
+
+### Key-tree Risk
+
+The usage of a BIP32 unhardened derivation introduce even more reliance of the signing devices security. Since the chaincodes are exchanged and stored on the wallets (running on untrusted online devices) of each participant, leaking a single child private key would be fatal to a participant's entire key-tree. Therefore the leak of a single child private key of all N stakeholders would be equivalent to the loss of all the funds. Using unhardened derivation implies that there is no partial loss of funds in case of a key leak by every stakeholder.
+
+### Transaction Fee Risk
+
+A fundamental issue arises with pre-signed transactions commiting to the feerate well in advance of the time of broadcast. The feerate is unpredictable and a transaction with a low feerate may not be included in a block in time. 
+
+The Unvault TXs have an additional output that allows dynamically allocating fees through child-pays-for-parent (CPFP). 
+
+The Cancel, Emergency and Unvault Emergency TXs aren't compatible with CPFP-carve out (FIXME: Why?), nor with ANYONECANPAY|ALL signatures (because this enables pinning attacks). The safest solution is to prepare multiple variants of the same transactions with a broad distribution of feerates, from typical to extreme and with many in-between. 
+
+
+### Underlying Assumptions
+
+#### Bitcoin
+
+- assume users can propagate revocation transactions to miners.
+- assume miners will mine the transaction paying the most feerate, regardless of any other (meta)data.
+- assume a significant hashrate to prevent reorgs of depth higher than the unvault time-lock length.
+
+#### Infrastructure
+
+- assume a proper ceremony (FIXME: link) as the root of trust for cryptographic protocols used.
+- assume a secure signing device allowing users to check the validity of the data being signed.
+- assume at least one honest cosigning server AND at least one honest online watchtower per stakeholder.
+- assume the N stakeholders’ keys to not all be compromised.
+- assume sufficient fees for Revault TXs such that operations aren't stalled. 
+- assume the Unvault TX output relative timelock to be high enough for an attack on the block space market to not be worth it.
\ No newline at end of file