diff --git a/README.md b/README.md
index 8ba1034..aaa1414 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,6 @@
 # Shelter Protocol Documentation
 
-Welcome to Shelter Protocol documentation website!
+Welcome to Shelter Protocol documentation website, [shelterprotocol.net](https://shelterprotocol.net/)!
 
 ## 🧞 Commands
 
diff --git a/src/content/docs/en/message-processing.mdx b/src/content/docs/en/message-processing.mdx
index 7168ad8..2803554 100644
--- a/src/content/docs/en/message-processing.mdx
+++ b/src/content/docs/en/message-processing.mdx
@@ -51,7 +51,7 @@ It is up to developers to be aware of such possibilities and handle them accordi
 
 ### Contract & VM State
 
-Special keys on contract state are prefixed with `_`. These are managed by Shelter Protocol implementations and must not set by developers. Currently, two special keys are defined:
+Special keys on contract state are prefixed with `_`. These are managed by Shelter Protocol implementations and must not be set by developers. Currently, two special keys are defined:
 
 - `_vm` — is used to store various metadata critical to interpreting messages that also needs to be sync'd across clients. For example, `_vm.authorizedKeys` stores keys that are used to verify message signatures.
 - `_volatile` — This represents client-local information for contract related data like private keys. Implementations could store this information someplace else if they prefer. `_volatile` must not be shared publicly. For example, `_volatile.keys` is used to store private keys that decrypt messages. This attribute is not stored in [state snapshots](/en/state-snapshots) and never leaves the client device.
diff --git a/src/content/docs/en/multi-device.md b/src/content/docs/en/multi-device.md
index 5797383..0ed7aaf 100644
--- a/src/content/docs/en/multi-device.md
+++ b/src/content/docs/en/multi-device.md
@@ -38,7 +38,7 @@ The downside of this approach is that while we protect the secret key from being
 
 ### Unique Keys Per Device
 
-It is possible to use Shelter Protocol with a UKPD approach if desired.
+It is possible to use Shelter Protocol with a Unique Keys Per Device (UKPD) approach if desired.
 
 Shelter Protocol defines the following primitives for key management and key sharing:
 
diff --git a/src/content/docs/en/opcodes.md b/src/content/docs/en/opcodes.md
index 08eb1bb..8a9c59a 100644
--- a/src/content/docs/en/opcodes.md
+++ b/src/content/docs/en/opcodes.md
@@ -104,7 +104,7 @@ For example, every contract should have a `CSK` (`Contract Signing Key`, marked
 
 `"purpose"` is an array of strings that state the key's purpose. Typically this will be either `"sign"` (for signing messages), or `"enc"` for encrypting/decrypting messages, or it could be both. Other arbitrary values are allowed too if they are useful to protocol implementers.
 
-`"data"` is a JSON string specifying the public key itself (other types of keys, like encrypted secret keys, are stored under `meta.private`). Key data a JSON stringified array of the following structure:
+`"data"` is a JSON string specifying the public key itself (other types of keys, like encrypted secret keys, are stored under `meta.private`). Key data is a JSON stringified array of the following structure:
 
 ```
 [type, publicKey, secretKey]: [string, string, null] | [string, null, string]