PIP-0032A: final edits

PIP/PIP-0032A.md

@@ -17,13 +17,13 @@ A minor protocol change is proposed to enable atomic swap capability within the
 
 ## Motivation
 
-Atomic swaps are a smart-contract technology that enable the exchange of one cryptocurrency for another without using intermediaries, such as 3rd party exchanges.  Atomic swaps occur as events within the respective blockchains and between the exchanging parties only in a cryptographically secure manner.  Atomic Swaps are a fundamental building block for implementation of decentralized exchanges, such as the planned Pascal DEX. 
+Atomic swaps are a smart-contract technology that enable the exchange of one cryptocurrency for another without using intermediaries, such as 3rd party exchanges.  Atomic swaps occur as smart-contract events within the respective blockchains involving only the exchanging parties in a cryptographically secure manner.  Atomic swaps are the fundamental building block for decentralized exchanges (DEX). 
 
-An atomic swap is performed using a type of smart-contract known as a _Hash-Locked-Time-Contract_ (HLTC). The "Hash-Lock" aspect of an HLTC requires that the funds within the contract be locked by a hash and that they only be unlocked by revealing the pre-image of that hash. The "Time-Contract" aspect of an HLTC requires that the contract be exclusively assigned to the other party for a fixed, public and immutable period of time. The time-contract enables the party to unlock the funds within the time-frame without risk of being preempted by any other party. 
+An atomic swap is performed using a type of smart-contract known as a _Hash-Locked-Time-Contract_ (HLTC). The "Hash-Locked" aspect of an HLTC requires that the funds within the contract be locked by a hash and that they only be unlocked by revealing the pre-image of that hash. The "Time-Contract" aspect of an HLTC requires that the contract be exclusively assigned to the other party for a fixed, public and immutable period of time. This time lock enables the party to unlock the funds within the time-frame without risk of being preempted by any other party. 
 
-By using two matching HLTC's on two independent blockchains, cross-chain atomic swaps of cryptocurrency between those blockchains is possible without the involvement of intermediaries.  Since PascalCoin already implements "Time-Contracts" in the form of [in-protocol PASA exchange][2], only the "Hash-Locked" aspect of HLTCs require implementation.
+By using two matching HLTC's on two independent blockchains, cross-chain atomic swaps of cryptocurrency can be performed, without the involvement of intermediaries.  Since PascalCoin already implements "Time-Contracts" in the form of [in-protocol PASA exchange][2], only the "Hash-Locked" aspect of HLTCs require implementation.
 
-The proposal here is to introduce the feature of "Hash Locked" accounts such that when combined with in-protocol PASA exchange, an HLTC is achived suitable for cross-chain atomic swaps. With this simple change, the following cross-chain atomic swap work-flow is enabled:
+The proposal here is to introduce the feature of "Hash Locked" accounts such that when combined with in-protocol PASA exchange, an HLTC is achieved suitable for cross-chain atomic swaps. With this simple change, the following atomic swap work-flow is enabled:
 
 ### Atomic Swap Work-flow
 
@@ -118,11 +118,11 @@ end;
 ## Rationale
 
 As there are many approaches for implementing atomic swaps and HLTCs in PascalCoin, this PIP is post-fixed with "A" to allow alternative approaches "B", "C" and so on. 
-However, PIP-0032A is by far the simplest and least impactful approach that naturally compliments the [in-protocol pasa exchange][2] features established in Version 2. 
+However, PIP-0032A is by far the simplest and least impactful approach that naturally compliments the [in-protocol PASA exchange][2] features established in Version 2. 
 
-In many ways, this change completes that functinality to enable cross-chain PASA exchange. It is least impactful since it does not require changing signature logic for client-side libraries (such as JPpascalCoin/NPascalCoin/SBX/FlutterLib). 
+In many ways, this proposal completes that functionality to enable "cross-chain exchange". It is the least impactful approach since it does not require changing the signature logic of client-side libraries such as JPascalCoin/NPascalCoin/SBX/FlutterLib/etc. 
 
-Due to the low cost vs the significant benefits, this proposal is recommended for V5 implementation.
+In conclusion, due to the low cost vs the significant benefits of this change, this proposal is recommended for V5 implementation.
 
 ## Backwards Compatibility