fixing docs
diff --git a/docs/d-ta-overview.md b/docs/d-ta-overview.md
index 8a042a6..2e80e12 100644
--- a/docs/d-ta-overview.md
+++ b/docs/d-ta-overview.md
@@ -4,7 +4,9 @@
 sidebar_label: D-TA Overview
 ---
 ### VERSION: ALPHA RELEASE
-NOTES: The Alpha Release of the D-TA is not for production use. 
+
+:::important The Alpha Release of the D-TA is not for production use.
+:::
 
 #### Release Schedule:
 
diff --git a/docs/dta-details/api.md b/docs/dta-details/api.md
index 6f5eadf..f5fc86f 100644
--- a/docs/dta-details/api.md
+++ b/docs/dta-details/api.md
@@ -4,18 +4,18 @@
 sidebar_label: API
 ---
 
-Open-api specifications are provided for the core "vanilla" Milagro D-TA HTTP REST services and for both the shipped plugins: Bitcoin Address and Safeguard Secret
+Open-API specifications are provided for the core "vanilla" Milagro D-TA HTTP REST services and for both the shipped plugins: Bitcoin Wallet Security and Safeguard Secret.
 
-* [Standard API](https://raw.githubusercontent.com/apache/incubator-milagro-dta/develop/open-api.yaml) Here it is in a [Swagger UI](/swagger/index.html)   
-* [Bitcoin Plugin API](https://raw.githubusercontent.com/apache/incubator-milagro-dta/develop/pkg/bitcoinplugin/open-api.yaml)   
+* [Standard API](https://raw.githubusercontent.com/apache/incubator-milagro-dta/develop/open-api.yaml) The [Swagger UI is available at this link.](/swagger/index.html)   
+* [Bitcoin Wallet Security Plugin API](https://raw.githubusercontent.com/apache/incubator-milagro-dta/develop/pkg/bitcoinplugin/open-api.yaml)   
 * [Safeguard Secret API](https://raw.githubusercontent.com/apache/incubator-milagro-dta/develop/pkg/safeguardsecret/open-api.yaml)   
 
 
 ## Testing The API
 
-(This assumes that your local DTA is running on port 5556 as described in the [quick start guide](/docs/dta-details/quickstart)
+This assumes that your local DTA is running on port 5556 as described in the [quick start guide](/docs/dta-details/quickstart).
 
-Instructions for installing Swagger UI can be found [here](https://github.com/swagger-api/swagger-ui/blob/master/docs/usage/installation.md)
+Instructions for installing Swagger UI can be found [here](https://github.com/swagger-api/swagger-ui/blob/master/docs/usage/installation.md).
 
 For example...
 
@@ -30,7 +30,9 @@
 
 Paste the URL of one of the API docs above into the text box at the top of the screen. 
 
-Have fun!
+Please let us know your comments by subscribing to dev@milagro.apache.org by sending an email to dev-subscribe@milagro.apache.org.
+
+
 
 
 
diff --git a/docs/dta-details/d-ta-plugins.md b/docs/dta-details/d-ta-plugins.md
index 239c2dc..a4d9091 100644
--- a/docs/dta-details/d-ta-plugins.md
+++ b/docs/dta-details/d-ta-plugins.md
@@ -4,16 +4,20 @@
 sidebar_label: Plugins Overview
 ---
 
-The out-of-the-box Milagro D-TA doesn't do much: a Principal gets a public key from a Master Fiduciary and at a later date can request the corresponding secret key. (Although it does this in a hard-to-hack, and fully auditable way). However this basic capability unlocks a huge range of potential uses cases. Some use cases relate to the Prinicpal i.e. what the keys can be used for, and some relate to the Master Fiduciary i.e. how the seret key is kept safe (a.k.a. custody). Th open source "vanilla" Milagro is an attempt to engage a wider community to make the communication between these parties as robust as possible, the plugin framework enables developers to extend the Milagro D-TA's core capability and apply it to solve real world problems.
+The out-of-the-box Milagro D-TA doesn't do much: a Principal's D-TA gets a public key from a Fiduciary's D-TA, and at a later date, can request the corresponding secret key. It is simple conceptually, but the core operation does this in a hard-to-hack, and fully auditable way. 
+
+However, this basic capability unlocks a huge range of potential uses cases. Some use cases relate to the Principal i.e. what the keys can be used for, and some relate to the Fiduciary i.e. how the secret key is kept safe (a.k.a. custody). 
+
+The open source "vanilla" Milagro is an attempt to engage a wider community to make the communication between these parties as robust as possible, and the plugin framework enables developers to extend the Milagro D-TA's core capability and apply it to solve real world problems.
 
 Out of the box the Milagro D-TA comes with two plugins:
-1. **EncryptAThing** - allows the principal to use the public key to encrypt a string, then get the secret key back from the Master Fiduciary D-TA and decrypt it
+1. **Safeguard Secret** - allows the Principal to use a public key obtained from the Fiduciary's D-TA to encrypt a string using ECIES, then obtain the secret key back from the Fiduciary's D-TA to decrypt the same string.
 
-2. **BitCoin Address** - uses the public key to generate a Bitcoin address and then constructs the corresponding secret key only when it is needed (this is a neat trick using elliptic curve magic).
+2. **Bitcoin Wallet Security** - uses the public key to generate a Bitcoin address and then constructs the corresponding secret key only when it is needed (this is a neat trick using elliptic curve magic).
 
 ***A Note About Security***
 
-The point of these plugins is to show you how the framework works and encourage you to develop your own, they do not (out of the box) provide a secure way to store your secret keys. The key pair seed is stored only in the Master Fiduciary's onboard database - there are obviously better ways do this, contact a Milagro D-TA compatible Custodial Service Provider to find out how...
+The point of these plugins is to show you how the framework works and encourage you to develop your own. They do not (out of the box) provide a secure way to store your secret keys. The key pair seed is stored only in the Fiduciary's onboard database - this is not how you should be doing it in production. Future releases will provide guidance on securing these seeds via PKCS#11 integrations and tie-ins to service providers.
 
 ## Approach
 The Milagro D-TA plugin framework has been designed with following assumptions:
@@ -28,16 +32,16 @@
 
 * **One-at-a-Time**
 
-   Each Milagro D-TA server can only run one plugin at a time. We considered how to allow multiple plugins to interoperate but this produces significant operational and security concerns. (We'd really appreciate your thoughts about that). Of course if you run a pair of servers as Principal and Master Fiduciary then they can each run different plugins
+   Each Milagro D-TA server can only run one plugin at a time. We considered how to allow multiple plugins to interoperate but this produces significant operational and security concerns. Of course if you run a pair of servers, (example: as Principal and Fiduciary) then they can each run different plugins.
 * **No New Endpoints**
 
     You can only write plugins to support the [Standard Endpoints](http://localhost:3000/swagger/). This probably seems quite restrictive but we think it is important that Milagro D-TA operates within a defined scope and in a predictable way. The Milagro D-TA is about the distributed management of key pairs, we are concerned that if the plugin framework allowed developers to add endpoints such as *GET fastfood/burger?orderby=mostTasty* then Milagro would just become a cool implementation of [Go kit](https://gokit.io/) and it would become impossible for users and integrators to predict what it will do. **However...**
-    * **Let's Talk** As a community we're excited to add new features to the Milagro D-TA. Propose your new endpoint as a feature (or even submit a PR) and we'll collectively consider adding it
-    * **Let's Fork** Go ahead and fork the Milagro D-TA. (But remember that the Milagro D-TA is basically a communication protcol so keep it compatible with other Milagro users)
+    * **Let's Talk**: As a community we're excited to add new features to the Milagro D-TA. Propose your new endpoint as a feature (or even submit a PR) and we'll collectively consider adding it.
+    * **Let's Fork**: Go ahead and fork the Milagro D-TA. (But remember that the Milagro D-TA is basically a communication protocol so keep it compatible with other Milagro users).
 
 * **Extensions** 
 
-   Although we restrict what endpoints Milagro provides we give you a highly flexible way to define what data each endpoint accepts and returns via the **extensions** JSON prop. For example the safeguardsecret plugin extends the POST /order endpoint like this:
+   Although we restrict what endpoints Milagro provides we give you a highly flexible way to define what data each endpoint accepts and returns via the **extensions** JSON prop. For example the Safeguard Secret plugin extends the POST /order endpoint like this:
    ```
     POST /order
     
diff --git a/docs/dta-details/encrypted-envelope.md b/docs/dta-details/encrypted-envelope.md
index c44acc2..e4d7dc6 100644
--- a/docs/dta-details/encrypted-envelope.md
+++ b/docs/dta-details/encrypted-envelope.md
@@ -4,37 +4,39 @@
 sidebar_label: Encrypted Envelope
 ---
 
-The Milagro D-TA enables Principals (who required secrets to be safeguarded) to communicate with Fiduciaries (who provide a Custodial servce). To facilitate this transaction communication between the parties must be secure i.e. can only be read by the intended recipient and attibutable i.e. can be cryptographically verified to have been signed by known actors. The Milagro D-TA provides a this mechansim using an "encrypted envelope" format.
+The Milagro D-TA enables Principals (who require secrets to be safeguarded) to communicate with Fiduciaries who provide custodian services for those secrets. To facilitate these transactions communication between the parties must be secure i.e., must have privacy, authentication, non-repudiation and message integrity. The Milagro D-TA delivers this using its "Encrypted Envelope" messaging format.
 
-:::tip The Milagro D-TA Encrypted Evelope format is conceptually similar to S/Mime
-For more information about S/MIME[click here](https://en.wikipedia.org/wiki/S/MIME)
+:::tip The Milagro D-TA Encrypted Envelope format is conceptually similar to S/MIME and its cryptographic message format.
+For more information about [S/MIME, click here](https://en.wikipedia.org/wiki/S/MIME).
 :::
 
 ## Overview
 
-1. The message consists of a header and body
-2. The message body can be plain text or encrypted with an aes key.
-3. The aes key for decrypting cyphertext is "encapsulated" i.e. encrypted using each recipient's public key
-4. The sender signs the message
-5. The meassge header contains a list of each recipient's encrypted version of the key
-6. The message is pushed to IPFS and the IPFS address hash is sent to the recipients
-7. The recipients read the message and verify the signature
-7. Only recipients with the matching secret keys can decrypt the aes key and use it to read the encrypted message bodies
+1. The message consists of a header and body.
+2. The message body is encrypted with an AES key.
+3. The AES key for decrypting ciphertext is "encapsulated" i.e. encrypted using each recipient's public key.
+4. The sender signs the message.
+5. The message header contains a list of each recipient's encrypted version of the key.
+6. The message is pushed to IPFS and the IPFS address hash is sent to the recipients.
+7. The recipients verify the signature and then read the message.
+7. Only recipients with the matching secret keys can decrypt the AES key and use it to read the encrypted message bodies.
 
 ![Figure 3](/img/dta/Envelope.png)
 
 :::note Post Quantum Cryptography
-At the time of writing the Milagro D-TA uses a cryptography library from the [NIST Post-Quantum Cryptography Standardisation Project](https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Round-2-Submissions).
+At the time of writing the Milagro D-TA implements cryptographic routines from the [NIST Post-Quantum Cryptography Standardization Project](https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Round-2-Submissions).
 * [SIKE](https://sike.org/) - key encapsulation
-However this are currently under review
+This implementation is currently under review.
 :::
 
 :::note digital signatures
-Currently, the Milagro D-TA uses [BLS signatures](https://en.wikipedia.org/wiki/Boneh–Lynn–Shacham) to sign encrypted envelopes.
+Milagro D-TAs use [BLS signatures](https://en.wikipedia.org/wiki/Boneh–Lynn–Shacham) to sign encrypted envelopes.
 :::
 
-## Multpart Messages
-The Milagro DTA encrypted envelope is designed to facilitate a dialogue between the Principal and Fiduciary. Requests and responses are appended to the original document and published back to IPFS wich returns new HASH address. In this way an immutable copy of each transaction is maintained, but the intended recipients can view the entire history of the transaction (if they have the required decryption keys) can be seen within each update, providing additional assurance and verification and reducing round trips to IPFS. 
+## Multipart Messages
+The Milagro D-TA's Encrypted Envelopes are designed to facilitate a dialogue between the Principal, Fiduciary and Beneficiaries. Requests and responses are appended to the original document and published back to IPFS which returns new HASH address. 
+
+In this way, an immutable copy of each transaction is maintained, but the intended recipients can view the entire history of the transaction if they have the required decryption keys. Each message can be seen within each update, providing additional assurance and verification and reducing round trips to IPFS. 
 
 
 
diff --git a/docs/dta-details/identity-documents.md b/docs/dta-details/identity-documents.md
index 6550b62..181b904 100644
--- a/docs/dta-details/identity-documents.md
+++ b/docs/dta-details/identity-documents.md
@@ -3,15 +3,14 @@
 title: Identity Documents
 sidebar_label: Identity Documents
 ---
-The first problem that Milagro DTA aims to solve is how actors in the system can identify and trust each other. In order to participate in the Milagro DTA safeguarding process each actor must publish a set of public keys into IPFS. The IPFS hash for an identity documents is then the ID for each actor.
+The first problem that a Milagro D-TA aims to solve is how entities in the system can identify and trust each other. In order to participate in the Milagro D-TA ecosystem each entity must publish a set of public keys into IPFS. The IPFS hash for an identity documents is then the ID for each entity running a D-TA.
 
-In order to create an identity document Milagro DTA provides the following endpoint.
+In order to create an identity document Milagro D-TA provides the following endpoint.
 
-[POST: /identity](http://localhost:3000/swagger/index.html#/identity/createIdentity)
-An Identity Document contains public keys for signing and key encapsulation. 
+[POST: /identity](http://localhost:3000/swagger/index.html#/identity/createIdentity) - An Identity Document contains public keys for signing and key encapsulation. 
 
-:::note The Milagro DTA communication protocol uses protobufs for serialisation. 
-[Click here for more information about Protocol Buffers](https://developers.google.com/protocol-buffers/)
+:::note The Milagro DTA communication protocol uses protobufs for serialization. 
+[Click here for more information about Protocol Buffers](https://developers.google.com/protocol-buffers/).
 :::
 
 The definition of an identity document is:
@@ -27,11 +26,9 @@
 
 ```
 
+* `AuthenticationReference` refers to Milagro's out of the box [oAuth integration](authentication.md).
 
-
-* `AuthenticationReference` refers to Milagro's out of the box [oAuth integration](authentication.md)
-
-The node that is used to create an identity document will store the seed and secret keys associated with the Identity. In RC1 these are stored as a JSON file in the key value store:
+The node that is used to create an Identity Document will store the seed and secret keys associated with the Identity. In the RC1 release these will be stored as a JSON file in the key value store:
 
 ```json
 //IdentitySecrets - keys required for decryption and signing
diff --git a/docs/dta-details/ipfs.md b/docs/dta-details/ipfs.md
index 5396d18..1e8d510 100644
--- a/docs/dta-details/ipfs.md
+++ b/docs/dta-details/ipfs.md
@@ -4,10 +4,10 @@
 sidebar_label: IPFS
 ---
 
-The Milagro D-TA aims to provide an auditable record of all interactions between actors in the system. It is vital that all the actors in the system can refer to an agreed record of these transactions in case of dispute or in response to requests from third parties such as law enforcement, audit or compliance.  The Milagro D-TA creates immutable, secure and attributable records of every interaction that occurs in the lifecycle of the actors and their dealings with secrets. We do this using the Inter Planetary File System - [IPFS](https://ipfs.io/).
+The Milagro D-TA aims to provide an auditable record of all interactions between actors in the system. It is vital that all the actors in the system can refer to an agreed record of these transactions in case of dispute or in response to requests from third parties such as law enforcement, audit or compliance organizations.  The Milagro D-TA creates immutable, secure and attributable records of every interaction that occurs in the lifecycle of entities and their dealings with secrets. We do this using the Inter Planetary File System - [IPFS](https://ipfs.io/).
 
-IPFS is a globally distributed peer-to-peer file system - think GitHub meets BitTorrent. When a file is written (SET) into your local IPFS node a hash of the document is returned, you can then GET the document using that address. If somebody else who is running an IPFS tries to GET the same hash address the file will be pulled from your node to theirs. If the document is changed in way the hash will change. In this way a immutability and peer-to-peer consensus is achieved.
+IPFS is a globally distributed peer-to-peer file system - think GitHub meets BitTorrent. When a file is written (SET) into your local IPFS node a hash of the document is returned, you can then GET the document using that address. If somebody else who is running an IPFS tries to GET the same hash address the file will be pulled from your node to theirs. If the document is changed in way the hash will change. In this way, an immutability and peer-to-peer consensus is achieved.
 
-:::note We appreciate feedback regarding this approach
-If more complex multi-party consensus is required we could implement something like [Paxos](https://understandingpaxos.wordpress.com/), [Raft](https://raft.github.io/), [Tendermint](https://tendermint.com/)
+:::note We appreciate feedback regarding this approach.
+For more complex consensus requirements, the Milagro D-TA will be implementing [Tendermint](https://tendermint.com/) in following releases.
 :::
diff --git a/docs/dta-details/quickstart.md b/docs/dta-details/quickstart.md
index 19842e7..e8ef3dd 100644
--- a/docs/dta-details/quickstart.md
+++ b/docs/dta-details/quickstart.md
@@ -5,7 +5,7 @@
 ---
 
 ## Docker
-The easiest way to see a D-TA in action is to run it in a Docker container. The default settings will run a single D-TA that acts as Principal, Master Fiduciary and Beneficiary. The default settings include an embedded IPFS node connected to a private IPFS network and an embedded "Bolt" database. This will get you up and running quickly but is **not recommended for production use!**
+The easiest way to see a D-TA in action is to run it in a Docker container. The default settings will run a single D-TA that acts as Principal, Fiduciary and Beneficiary. The default settings include an embedded IPFS node connected to a private IPFS network and an embedded "Bolt" database. This will get you up and running quickly but is **not for production use!**
 
 Please see the repo's [README](https://github.com/apache/incubator-milagro-dta) for alternative build instructions.
 
@@ -40,17 +40,19 @@
 
 The Milagro D-TA comes with two additional plugins out-of-the box, which are intended to demonstrate how it can be extended.
 
+### Safeguard Secret
+
+The Safeguard Secret plugin encrypts a string with the public key using [ECIES](https://medium.com/asecuritysite-when-bob-met-alice/generating-an-encryption-key-without-a-pass-phrase-meet-ecies-bbea1787d846) and decrypts it when the Fiduciary's D-TA returns the secret key.
+
 **To Run Safeguard Secret**
-
-The Safeguard Secret plugin encrypts a string with the public key and decrypts it when the Master Fiduciary returns the secret key.
-
 ```
 docker run -it -p 5556:5556 milagrodta -service safeguardsecret
 ```
+### Bitcoin Wallet Security
 
-**To Run Bitcoin Wallet**
+A Bitcoin Wallet uses a public key (derived from a private key) to create a Bitcoin address. To spend funds from that address, the private key is needed. Insufficient security of private keys has let to billions of dollars in theft. The Principal's Bitcoin Wallet Security plugin receives one half of the public key from the Fiduciary to ultimately create the wallet address. To spend the funds, the Fiduciary D-TA returns a secret to the Beneficiary's D-TA. A process adds this secret to one that is resident within the Principal's D-TA to materialize the wallet's private key.
 
-Bitcoin Wallet uses the public key to create a Bitcoin address. When you want to spend your bitcoins you can get the secret key from the Master Fiduciary
+**To Run Bitcoin Wallet Security**
 ```
 docker run -it -p 5556:5556 milagrodta -service bitcoinwallet
 ```
@@ -68,11 +70,10 @@
 1. **Identity Endpoints** - that support creation and retrieval of [identity documents](dta-details/identity-documents.md)
 2. **Order Endpoints** 
     1. Creates orders for new public keys
-    2. Requests for secret keys to be revealed (redeemed)
+    2. Requests for secret keys to be transferred
     3. Allows orders to be searched and listed
 3. **Fulfillment RPC** - these are the server-to-server remote procedure calls that enable a Principal D-TA to communicate with a Master Fiduciary D-TA
 
-
 ### Example - To create a new Identity
 
 ```