update

docs/get-started.md

@@ -1,17 +1,12 @@
 # Getting Started
 
-Below is a step-by-step guide on how to use the protocol in an example scenario. This guide includes a live demo that you can run on your own machine, with no special software required.
+Below is a step-by-step guide on how to use the protocol in an example scenario. This guide includes a live demo that you can run with no special software required.
 
-To run the demo, simply clone this repository, then run the following commands:
+You can run this demo in our live [replit instance](https://replit.com/@cscottdev/escrow-core#demo/api/contract/witness.ts) using the shell command:
 
-```sh
-npm install           # Install all package dependencies.
-npm run demo {chain}  # Run the demo using the provided chain.
-```
-
-> Note: The current chains available are `mutiny`, `signet`, and `testnet`. The default chain is `mutiny`.
+`yarn demo {chain}`
 
-Read more info about the demo [here](demo/README.md).
+The current chains available are `mutiny`, `signet`, and `testnet`. The default chain is `mutiny`
 
 ### Create a Client
 
@@ -33,7 +28,7 @@ const client_config = {
 const client = new EscrowClient(client_config)
 ```
 
-For more info on the `EscrowClient` class, [click here](docs/client.md).
+For more info on the `EscrowClient` class, [click here](wiki/client.md).
 
 ### Create a Signer
 
@@ -84,7 +79,7 @@ The `EscrowSigner` is built for insecure environments. All addresses are derived
 
 The signing key is also disposable, and can be tossed from memory once the contract and covenant are in place. All credentials generated by the signer are independently recoverable by the xpub.
 
-For more info on the `EscrowSigner` class, [click here](docs/signer.md).
+For more info on the `EscrowSigner` class, [click here](wiki/signer.md).
 
 ### Build a Proposal
 
@@ -175,11 +170,11 @@ Each endorsement provided to the server will tag the proposal with the signer's
 
 > Endorsing a proposal does not reveal which credential belongs to you.
 
-For more information on building a `proposal`, [click here](docs/proposal.md).
+For more information on building a `proposal`, [click here](wiki/proposal.md).
 
 ### Create a Contract
 
-Once you have a complete proposal, the next step is to create a [contract](docs/interfaces/contract.md#contractdata):
+Once you have a complete proposal, the next step is to create a [contract](data/contract.md#contractdata):
 
 ```ts
 // Request to create a contract from the proposal (and optional signatures).
@@ -192,11 +187,11 @@ const { contract } = res.data
 
 The contract begins in a `published` state, and is ready for funding. You can share the contract with others by advertising its unique identifier, the `cid`.
 
-For more info on how to use a contract, [click here](docs/contract.md).
+For more info on how to use a contract, [click here](wiki/contract.md).
 
 ### Deposit Funds
 
-To make a deposit, we start by requesting a deposit [account](docs/interfaces/deposit.md#depositaccount) from the escrow server:
+To make a deposit, we start by requesting a deposit [account](data/deposit.md#depositaccount) from the escrow server:
 
 ```ts
 // Define our deposit locktime.
@@ -247,7 +242,7 @@ if (!res.ok) throw new Error('failed')
 const { contract, deposit } = res.data
 ```
 
-> For more info on managing a `deposit`, [click here](docs/deposit.md).
+> For more info on managing a `deposit`, [click here](wiki/deposit.md).
 
 ### Settle a Contract
 
@@ -277,7 +272,7 @@ witness = a_signer.witness.sign(contract, template)
 witness = b_signer.witness.endorse(contract, witness)
 ```
 
-These statements are submitted to the contract, and evaluated by the CVM. If the statement is valid, then the CVM will update its [state](docs/interfaces/contract.md#statedata), and the server will deliver an updated contract:
+These statements are submitted to the contract, and evaluated by the CVM. If the statement is valid, then the CVM will update its [state](data/contract.md#statedata), and the server will deliver an updated contract:
 
 ```ts
 // Submit the completed statement to the contract.
@@ -303,4 +298,4 @@ console.dir(txdata, { depth : null })
 
 And that is it! The on-chain transaction will look like an anonymous coin-join of single-key spends, and it can be fee-bumped by any recipient of the contract funds using CPFP.
 
-For more information on contracts, the CVM, and settlement process, [click here](docs/contract.md).
+For more information on contracts, the CVM, and settlement process, [click here](wiki/contract.md).

docs/intro.md

@@ -26,7 +26,7 @@ The protocol is split into three phases: _negotiation_, _funding_, and _settleme
 
 ### Negotiation
 
-The first step is to negotiate and agree on a [proposal](docs/proposal.md) document. This is a human-readable document which contains all of the terms of the contract.
+The first step is to negotiate and agree on a [proposal](wiki/proposal.md) document. This is a human-readable document which contains all of the terms of the contract.
 
 It is written in JSON format, and designed for collaboration (much like a PSBT):
 
@@ -59,13 +59,13 @@ If desired, a third-party can host the proposal. The protocol is designed for th
 
 There is no specification placed on how to communicate the proposal between parties. There are many great protocols available, so feel free to use your favorite one!
 
-Once the terms have been decided, any member can deliver the final proposal to the escrow server. The server will validate all terms, then publish an open [contract](docs/contract.md) for funding.
+Once the terms have been decided, any member can deliver the final proposal to the escrow server. The server will validate all terms, then publish an open [contract](wiki/contract.md) for funding.
 
 > Note: The escrow server does not take part in negotiations. While BitEscrow may offer these services, the protocol is designed so that members can negotiate freely, without the server being involved.
 
 ### Funding
 
-To deposit funds into a contract, the funding party will first request a deposit [account](docs/deposit.md) from the server. This account uses a 2-of-2 multi-signature address with a time-locked refund path.
+To deposit funds into a contract, the funding party will first request a deposit [account](wiki/deposit.md) from the server. This account uses a 2-of-2 multi-signature address with a time-locked refund path.
 
 ```ts
 interface DepositAccount {
@@ -85,7 +85,7 @@ The funder independently verifies the account information, then sends their fund
 
 Once the transaction is in the mempool, the funder can then commit the funds by signing the contract's spending paths. These signatures authorize the contract to spend the deposit based on the contract terms.
 
-The combination of these signatures form a [covenant](docs/deposit.md) with the contract:
+The combination of these signatures form a [covenant](wiki/deposit.md) with the contract:
 
 ```ts
 interface CovenantData {
@@ -129,7 +129,7 @@ vm_state: {
 
 > Note : The `head` of the hash-chain is initialized using the contract's identifier (cid).
 
-Members of the contract can interact with the CVM by submitting a signed statement, called a [witness](docs/contract.md). Members use these statements to instruct the CVM to perform a basic set of operations.
+Members of the contract can interact with the CVM by submitting a signed statement, called a [witness](wiki/contract.md). Members use these statements to instruct the CVM to perform a basic set of operations.
 
 Each operation targets a spending path in the contract. Operations include `lock`, `release`, `close` and `dispute`: