Fix: typos

docs/counterfactual-delegation.md

@@ -3,7 +3,7 @@ title: Counterfactual Delegations
 sidebar_label: Counterfactual Delegations
 ---
 
-The Delegatable Framework, architected by [Dan Finlay](https://twitter.com/danfinlay) and [Rick Dudley](https://twitter.com/AFDudley0), inspired by exisiting [Object Capabilities](https://en.wikipedia.org/wiki/Object-capability_model) and [Capability](https://en.wikipedia.org/wiki/Capability-based_security) security models, is a scalable peer-to-peer access control system for EVM compute environments.
+The Delegatable Framework, architected by [Dan Finlay](https://twitter.com/danfinlay) and [Rick Dudley](https://twitter.com/AFDudley0), inspired by existing [Object Capabilities](https://en.wikipedia.org/wiki/Object-capability_model) and [Capability](https://en.wikipedia.org/wiki/Capability-based_security) security models, is a scalable peer-to-peer access control system for EVM compute environments.
 
 > Capability-based security is a concept in the design of secure computing systems, one of the existing security models. A capability (known in some systems as a key) is a communicable, unforgeable token of authority. It refers to a value that references an object along with an associated set of access rights. A user program on a capability-based operating system must use a capability to access an object.
 >
@@ -25,27 +25,27 @@ Caveat enforcers enable transaction-level limiters using on-chain information li
 
 ### What is counterfactual?
 
-The Delegatable framework use counterfactual assertions to unlock on-chain capabilities.
+The Delegatable framework uses counterfactual assertions to unlock on-chain capabilities.
 
 > A counterfactual explanation describes a causal situation in the form: “If X had not occurred, Y would not have occurred”
 
-As stated by Christoph Molnar in ["Interpretable Machine Learning: 9.2 Counterfactual Explanations"](https://christophm.github.io/interpretable-ml-book/counterfactual.html) the term counterfactual, in the world of computer science, pertains to conditional logic operator statements. It's the classic _"If this, than that."_ statement formally defined in terms of `contradictions` and `hypotheticals` used to declare the `TRUE`-ness of a computed `statement`.
+As stated by Christoph Molnar in ["Interpretable Machine Learning: 9.2 Counterfactual Explanations"](https://christophm.github.io/interpretable-ml-book/counterfactual.html) the term counterfactual, in the world of computer science, pertains to conditional logic operator statements. It's the classic _"If this, then that."_ statement formally defined in terms of `contradictions` and `hypotheticals` used to declare the `TRUE`-ness of a computed `statement`.
 
 **Basic Examples**
 
-If `Alice` doesn't have off-chain signature `X` than `Alice` can't execute on-chain action `B`.
+If `Alice` doesn't have off-chain signature `X` then `Alice` can't execute on-chain action `B`.
 
-If on-chain condition `Z` is not satisfied than off-chain signature `T` can't be executed.
+If on-chain condition `Z` is not satisfied then off-chain signature `T` can't be executed.
 
-If Delegation `M` is not revoked than Invocation `N` can be executed.
+If Delegation `M` is not revoked then Invocation `N` can be executed.
 
 **How It Works**
 
 The Delegatable framework uses off-chain `assertions` to unlock on-chain access controls.
 
 In other words, it's not possible to look at the blockchain, and _discover_ what accounts, have what permissions, because the `state` is only known to the involved parties; **opposite to most of today's EVM based access control systems.**
 
-If the permission is not intended to be executed in the immediate future, than most smart contracts will use an on-chain delegation system, for managing access controls. While,this is a _perfectly fine approach_, it does have limitations. Plus, the conditional logic operators (timestamp, blockNumber, etc..) have to be included at protocol smart contract level, which is not ideal, if we're striving for modularity and separation of concerns. **And, _yes_, we are striving for modularity and separation of concerns.**
+If the permission is not intended to be executed in the immediate future, then most smart contracts will use an on-chain delegation system, for managing access controls. While this is a _perfectly fine approach_, it does have limitations. Plus, the conditional logic operators (timestamp, blockNumber, etc..) have to be included at protocol smart contract level, which is not ideal, if we're striving for modularity and separation of concerns. **And, _yes_, we are striving for modularity and separation of concerns.**
 
 **Resources**
 

docs/eip712-signed-typed-data.md

@@ -5,7 +5,7 @@ sidebar_label: EIP712 Signed-Typed Data
 
 The Delegatable framework uses the EIP712 signed-typed data specification for signing Delegations and Invocations.
 
-EIP712 core benefits are human-readable and machine-verifiable data structures. In other words, Users can more easily understand what they're signing (and the side-effects) and we can still process the signature on-chain, for minimal additional gas-costs.
+EIP712 core benefits are human-readable and machine-verifiable data structures. In other words, Users can more easily understand what they're signing (and the side effects) and we can still process the signature on-chain, for minimal additional gas-costs.
 
 If you are not familiar with the EIP712 specification it's recommended to review the following resources:
 

docs/getting-started.md

@@ -44,6 +44,6 @@ git clone [email protected]:delegatable/delegatable-eth.git
 
 ## Contributing
 
-Interested in contributing the the Delegatable smart contract framework?
+Interested in contributing to the Delegatable smart contract framework?
 
 Create a pull request and/or open an issue and start getting involved today.