Minor wording improvements

src/introduction/a-path-to-pos-zcash.md

@@ -4,7 +4,7 @@ The [TFL](./terminology.md#definition-tfl) design provides a possible first step
 
 ## The Zcash Tech-Tree
 
-There are multiple developer orgs working on different proposed features for Zcash. Some of these involve multiple large distinct upgrade steps, and several of these steps depend on other such steps. This could be represented as a directed-acyclic graph. We have begun referring to this space of possible future improvements as the *Zcash Tech-Tree*, taking inspiration from an analogous concept in gaming.[^tech-tree-history]
+There are multiple developer orgs working on different proposed features for Zcash. Some of these involve multiple large distinct upgrade steps, and several of these steps depend on other such steps. This could be represented as a directed acyclic graph. We have begun referring to this space of possible future improvements as the *Zcash Tech-Tree*, taking inspiration from an analogous concept in gaming.[^tech-tree-history]
 
 We envision a *proof-of-stake transition path* as one of the potential paths within this tech-tree which is the primary protocol focus of this proposal. An example visualization of this Zcash Tech-Tree might look like this:
 
@@ -19,7 +19,7 @@ Given that context, we envision a "path" within the Zcash Tech-Tree for transiti
 1. Transitioning from current Zcash PoW to a hybrid PoW/PoS system.
 2. Transitioning from a hybrid PoW/PoS system to pure PoS.
 
-Our primary motivation for proposing (at least) two steps is to minimize usability, safety, security, and ecosystem distruption during each step.
+Our primary motivation for proposing (at least) two steps is to minimize disruption to usability, safety, security, and the ecosystem during each step.
 
 With this approach, the Zcash Tech Tree with the [TFL](./terminology.md#definition-tfl) approach might look something like this:
 
@@ -31,8 +31,8 @@ With this approach, the Zcash Tech Tree with the [TFL](./terminology.md#definiti
 
 We are refining the design of TFL with several design goals. As we refine the design and make various trade-offs, we may not be able to achieve all of these goals.
 
-- We want minimal-to-no disruption for existing wallet use cases and UX. For example, nothing should change for the user flows for storing or transferring funds, the format of addresses, etc…
-- We want a security analysis of the proposed protocol to be as simple as possible _given_ existing security analyses of current Zcash.
+- We want minimal-to-no disruption for existing wallet use cases and UX. For example, nothing should change for the user flows for storing or transferring funds, the format of addresses, etc.
+- We want a security analysis of the proposed protocol to be as simple as possible given existing security analyses of current Zcash.
 - We want to enable new use cases around PoS that allow mobile shielded wallet users to earn a return on delegated ZEC.
 - We want to enable trust-minimized bridges and other benefits by providing a protocol with assured finality (see [Terminology: Protocol Concepts](../terminology.md#protocol_concepts)). 
 - We want to improve the _modularity_ of the consensus protocol, which has several loosely defined and related meanings, e.g.: it's possible to understand some consensus properties only given knowledge of a "component" of the protocol, and it's possible to implement consensus rules in modular code components with clean interfaces.