diff --git a/.custom-words.txt b/.custom-words.txt
index b8d6bd4..bea225f 100644
--- a/.custom-words.txt
+++ b/.custom-words.txt
@@ -1,7 +1,4 @@
 ACL
-CBOR
-IPLD
-iff
 ACLs
 AlicePhone
 AliceRoot
@@ -14,6 +11,7 @@ BCP
 BT
 Bluesky
 BxZ
+CBOR
 CIDs
 CIDv
 CNAME
@@ -42,6 +40,7 @@ HEHYSF
 HMACs
 Haus
 Holmgren
+IPLD
 Invoker's
 Irakli
 JSON
@@ -103,6 +102,7 @@ autonumber
 baz
 bene
 blockchain
+cachability
 cid
 codec
 codecs
@@ -115,6 +115,7 @@ crypto
 cryptographically
 del
 delegable
+delegationChain
 delegator
 dereference
 disambiguates
@@ -142,6 +143,7 @@ getUcan
 hawaii
 hoc
 https
+iff
 init
 inlining
 interconnectivity
diff --git a/README.md b/README.md
index 93cebb2..c00943a 100644
--- a/README.md
+++ b/README.md
@@ -27,9 +27,9 @@ This specification describes the semantics and serialization format for [UCAN] d
   
 # 1. Introduction
 
-UCAN Delegation is a certificate capability system with runtime-extensiblity, ad hoc caveats, cachability, and focused on ease of use and interoperabilty. Delegations act as a proofs for [UCAN Invocation]s.
+UCAN Delegation is a certificate capability system with runtime-extensibility, ad hoc caveats, cacheability, and focused on ease of use and interoperability. Delegations act as a proofs for [UCAN Invocation]s.
 
-Delegation provides a way to "transfer authority without transferring cryptograhic keys". As an authorization system, it is more interested in "what" can be done than a list of "who can do what". For more on how Delegation fits into UCAN, please refer to the [high level spec][UCAN].
+Delegation provides a way to "transfer authority without transferring cryptographic keys". As an authorization system, it is more interested in "what" can be done than a list of "who can do what". For more on how Delegation fits into UCAN, please refer to the [high level spec][UCAN].
 
 # 2. Delegation (Envelope)
 
@@ -458,7 +458,7 @@ If _any_ of the following criteria are not met, the UCAN MUST be considered inva
 
 ## 5.1 Time Bounds
 
-A UCAN's time bounds MUST NOT be considered valid if the current system time is before the `nbf` field or after the `exp` field. This is called the "validity period." Proofs in a chain MAY have different validity periods, but MUST all be valid at execution-time. This has the effect of making a delegtaion chain valid between the latest `nbf` and earliest `exp`.
+A UCAN's time bounds MUST NOT be considered valid if the current system time is before the `nbf` field or after the `exp` field. This is called the "validity period." Proofs in a chain MAY have different validity periods, but MUST all be valid at execution-time. This has the effect of making a delegation chain valid between the latest `nbf` and earliest `exp`.
 
 ``` js
 // Pseudocode