copy updates

Author: CodeWallet Engineering

README.md

@@ -4,7 +4,7 @@ Solana Sealevel runtime. These programs include clients to interact with the
 on-chain programs. The programs are deployed to the Mainnet-Beta cluster. We
 will graciously accept patches to ensure the programs here are secure and
 reliable but ask that you submit any security concerns privately by emailing
-secury@getcode.com.
+security@getcode.com.
 
 ## Audits
 
@@ -17,7 +17,7 @@ [email protected].
 
 The programs in this repository are built using the
 [Anchor](https://www.anchor-lang.com/) framework. Anchor is a framework for
-building on-chain programs for the Solana blockchain. It provides a convenient
+building on-chain programs for the Solana blockchain. It provides convenient
 Rust macros for declaring program instructions and a client library for
 interacting with the on-chain programs.
 
@@ -35,7 +35,7 @@ The clients are available in the following languages:
 * A `Go` client derived from the TypeScript client
 * The `IDL` for use with Anchor's client library or other clients
 
-The `TypeScript` client is generated from the IDL using solita. You are able to do
+The `TypeScript` client is generated from the IDL using [solita](https://github.com/metaplex-foundation/solita). You are able to do
 this as well by running `npm run build` in the client directory. 
 
 The `Go` client is derived from this by hand. There are tools to automate this
@@ -88,7 +88,7 @@ $ npm run build
 #### Testing
 
 We use more extensive tests internally. This repository only contains limited
-tests that and can be found in the `tests` directory. You're welcome to run
+tests that can be found in the `tests` directory. You're welcome to run
 these tests, but they are not exhaustive. We will be adding more tests in the
 future. Pull requests are welcome.
 

splitter-token/README.md

@@ -11,17 +11,18 @@
 
 Tokens are typically transferred atomically from source to destination in a
 single instruction. However, there are cases where it may be useful to split
-a transfer into two separate transfers. If not done properly, this could violate
-the non-custodial nature of the original transfer.
+a transfer into two separate transfers. However, if not done properly, this
+could violate the non-custodial nature of the original transfer.
 
-To address this, the Splitter token program enables users to split token
+To address this, the Splitter program enables users to split token
 transfers into two instructions while preserving the non-custodial nature of the
 transfer. The program allows anyone to create a treasury account that can be
 used to split transfers. The treasury account is owned by a trusted party who
 can approve the transfer.
 
-The Splitter token program gets its name from the fact that it splits a single
-transfer into two parts however, the amount itself does not change.
+The Splitter program gets its name from the fact that it splits a single
+transfer into two parts, one from the program to the destination, and one from
+the source to the program, where the amount itself does not change.
 
 ### Example Use Case
 
@@ -31,25 +32,26 @@ some cases, it may be beneficial to split the transfer into two parts. For
 instance, if Alice and Bob wish to use a common third party for the exchange
 instead of a direct transfer. In such cases, Alice can transfer 100 tokens to
 the third party, and the third party can then transfer 100 tokens to Bob. This
-is a two-step process, and the third party acts as a custodian of the funds.
+is a two-step process, and in this case the third party acts as a custodian of
+the funds.
 
 To make the process non-custodial, we need to ensure that the third party does
-not have any means of stealing the funds. The Splitter token program can help in
-this regard. The third party can create a treasury account that can be used to
-split the transfer into two parts without being a custodian of the transfer
-amount.
+not have any means of stealing the funds. The Splitter program has been created
+to help in this regard. The third party can create a treasury account that can
+be used to split the transfer into two parts without being a custodian of the
+transfer amount.
 
 The high-level process is as follows:
 
 1) The third party creates a Splitter treasury account and deposits at least 100
 tokens into it.
 
 2) Alice provides the third party with a signed transfer instruction from Alice
-to the Splitter treasury for 100 tokens. This transfer is conditional on a
-future proof-of-payment provided by the Splitter program, that the third party
-treasury has sent Bob the same amount (100 tokens). The third party puts this
-signed transaction aside for later, and it is not yet submitted to the
-blockchain.
+to the Splitter treasury for 100 tokens. This transfer is computationally
+conditional on a future proof-of-payment provided by the Splitter program, that
+the third party treasury has sent Bob the same amount (100 tokens). The third
+party puts this signed transfer transaction aside for later, and it is not yet
+submitted to the blockchain.
 
     Note: This is done indirectly through a token account that doesn't yet exist
     but its address can be calculated ahead of time. The token account can only
@@ -63,17 +65,17 @@ to write a proof-of-payment into a merkle tree.
     Note: Timelock accounts and durable nonces are useful here to ensure that Alice
     cannot move her tokens before the third party is able to get them.
 
-4) With the condition now being met, the third party then executes the transfer
-from Alice to the Splitter treasury account.
+4) With the condition now being met, the third party then submits the signed
+transfer transaction from Alice to the Splitter treasury account.
 
 5) The third party can now withdraw the 100 tokens from the treasury account.
 
-The key innovation of the Splitter token program is that both transfers can be
-signed at the same time without waiting for confirmation on-chain. If the
-condition of the destination being paid first is not met, then the source will
-not be debited. It is in the best interest of the third party to pay the
-destination before executing the conditional payment, as failure to do so would
-result in a loss of funds.
+The key innovation of the Splitter program is that both transfers can be signed
+at the same time without waiting for confirmation on-chain. If the condition of
+the destination being paid first is not met, then the source cannot not be
+debited. It is in the best interest of the third party to pay the destination
+before executing the conditional payment, as failure to do so would result in a
+loss of funds.
 
 It is important to note that the third party managing the treasury account has
 no control over the transfer other than to approve it. This design ensures that