Documentation Tweaks (#5967)

* Fix typographical error in document: add missing 'with' in 'put you in touch with the corresponding teams'

* Fixed date format error and spelling mistake: 1. Corrected invalid date format from '2022-90-17' to '2022-09-17' under 'DAO Wallet' section. 2. Changed 'singer' to 'signer' in the 'Signing transactions: Use the DAO Wallet' section.

* Fix typo: change 'singer' to 'signer'

* Fix grammatical and stylistic errors in documentation

* Correct spelling errors: 'Milwaulkee' to 'Milwaukee' and 'combanatorics' to 'combinatorics'

* Fix typographical error in documentation link

* Correct typo: change 'procedureal' to 'procedural' in #[spl_program_error] section

* Fix typo in Motivation section: change 'challeneges' to 'challenges'

* Fix typographical error in 'Motivation' section

Correct the misspelling of 'interpret' in the 'Motivation' section.

* wrong usage of variable 'other_value1' instead of 'other_value2' in the tutorial code

* Fix grammatical error: 'The class authority of will therefore hold the right to add a Twitter handle name.' should be 'The class authority will therefore hold the right to add a Twitter handle name.'

SECURITY.md

@@ -66,7 +66,7 @@ have been forked and deployed by prominent ecosystem projects, many of which
 have their own bug bounty programs.
 
 While we cannot guarantee a bounty from another entity, we can help determine who
-may be affected and put you in touch the corresponding teams.
+may be affected and put you in touch with the corresponding teams.
 
 <a name="process"></a>
 ## Incident Response Process

account-compression/sdk/README.md

@@ -1,7 +1,7 @@
 # `@solana/spl-account-compression`
 
 A TypeScript library for interacting with SPL Account Compression and SPL NoOp. 
-For more information, see the full [Solana account compression SDK doumentation](https://solana-labs.github.io/solana-program-library/account-compression/sdk/).
+For more information, see the full [Solana account compression SDK documentation](https://solana-labs.github.io/solana-program-library/account-compression/sdk/).
 
 ## Install
 

binary-option/README.md

@@ -1,10 +1,10 @@
 # Binary Option
 
-This protocol is a primitive version of a binary options. Participants can enter a long or short position depending on their conviction. (These sides are set completely arbitrarily). The eventual goal is to have a higher level program manage the pool and handle settlements with an oracle based voting approach. Every bet in the pool involves 2 parties (1 long and 1 short) each depositing some collateral. Because bets are made on binary event, the sum of collateral will be equal to a multiple of some power of 10 (`10 ** N` where `N` is configurable).
+This protocol is a primitive version of binary options. Participants can enter a long or short position depending on their conviction. (These sides are set completely arbitrarily). The eventual goal is to have a higher level program manage the pool and handle settlements with an oracle based voting approach. Every bet in the pool involves 2 parties (1 long and 1 short) each depositing some collateral. Because bets are made on a binary event, the sum of collateral will be equal to a multiple of some power of 10 (`10 ** N` where `N` is configurable).
 
-The module contains the Rust implementation of protocol as well as a Python client and test suite.
+The module contains the Rust implementation of the protocol as well as a Python client and test suite.
 
-Suppose we had a binary option on the winner of the 2021 NBA Finals (Phoenix Suns vs. Milwaulkee Bucks). At the time of writing this (July 9th, 2021), the moneyline spread is -190 Suns +170 Bucks. This backs out an implied probability of approximately 36% that the Bucks win the championship. Suppose our binary option was on the Bucks winning this series, and that it is denominated by some wrapped stablecoin WUSD (dollar pegged) where every contract settled to 10000 WUSD (`N = 4` corresponding to 1 cent granularity). You observe that someone is willing to go short Bucks for 10 contracts at 3000 WUSD (less than the estimated probability of 36%). You can take on the opposite trade by buying 10 long contracts on the Bucks for 3000.
+Suppose we had a binary option on the winner of the 2021 NBA Finals (Phoenix Suns vs. Milwaukee Bucks). At the time of writing this (July 9th, 2021), the moneyline spread is -190 Suns +170 Bucks. This backs out an implied probability of approximately 36% that the Bucks win the championship. Suppose our binary option was on the Bucks winning this series, and that it is denominated by some wrapped stablecoin WUSD (dollar pegged) where every contract settled to 10000 WUSD (`N = 4` corresponding to 1 cent granularity). You observe that someone is willing to go short Bucks for 10 contracts at 3000 WUSD (less than the estimated probability of 36%). You can take on the opposite trade by buying 10 long contracts on the Bucks for 3000.
 
 This invokes a `Trade` instruction with size 10, buy_price 3000, and sell_price 7000. Note that these prices must sum to 10000. As part of the protocol, you transfer 30000 WUSD into the binary option and the counterparty deposits 70000 (assuming that both parties start with 0 position). In return, 10 long tokens (minted by the contract) are added to your account, and 10 short tokens are minted to your counterparty's account.
 
@@ -20,7 +20,7 @@ contains information about program audits.
 ## Client Setup 
 First, clone down the repository (TODO publish to PyPI)
 
-Create a virtual environment and and install the dependencies in `client/requirements.txt`
+Create a virtual environment and install the dependencies in `client/requirements.txt`
 
 ```
 python3 -m virtualenv venv
@@ -47,7 +47,7 @@ python -m client.test
 
 `n_s` the number of long contracts owned by the seller
 
-We know from our college combanatorics/discrete math class that there are 3! = 6 ways to order 3 items. Let's list out all configurations of how these numbers can bet ordered from largest to smallest (assuming all distinct):
+We know from our college combinatorics/discrete math class that there are 3! = 6 ways to order 3 items. Let's list out all configurations of how these numbers can bet ordered from largest to smallest (assuming all distinct):
 
 ```
 1) n_b > n_s > n

docs/src/name-service.md

@@ -42,7 +42,7 @@ centralized, the creation of new classes is permissionless and as a class owner
 any kind of decentralized governance signing program could be used.
 
 - Twitter handles can be added as names of one specific name class. The class
-  authority of will therefore hold the right to add a Twitter handle name. This
+  authority will therefore hold the right to add a Twitter handle name. This
   enables the verification of Twitter accounts for example by asking the user to
   tweet their pubkey or a signed message. A bot that holds the private issuing
   authority key can then sign the Create instruction (with a metadata_authority

governance/NOTES.md

@@ -16,11 +16,11 @@ A DAO wallet is 1) PDA with no data, 2) derived from its governance account and
 
 If the intention is to manage a program, you should use the DAO wallet as the admin auth in your program
 
-*Note: as of 2022-90-17 the UI is not up-to-date and it is sill allowing users to create the deprecated asset specific governances.*
+*Note: as of 2022-09-17 the UI is not up-to-date and it is sill allowing users to create the deprecated asset specific governances.*
 
 ### Signing transactions: Use the DAO Wallet
 
-Right now both PDAs (DAO Wallet and governance account) can sign Txs. However some protocols assume the singer is also a payer or beneficiary and then only the DAO wallet can be used. For that reason it’s always better to use the DAO wallet as the authority because it behaves like any other wallet and works for all scenarios. The objective is to standardize on DAO Wallet as signer to eliminate confusion.
+Right now both PDAs (DAO Wallet and governance account) can sign Txs. However some protocols assume the signer is also a payer or beneficiary and then only the DAO wallet can be used. For that reason it’s always better to use the DAO wallet as the authority because it behaves like any other wallet and works for all scenarios. The objective is to standardize on DAO Wallet as signer to eliminate confusion.
 
 ### Wallet assets
 

governance/program/src/instruction.rs

@@ -422,7 +422,7 @@ pub enum GovernanceInstruction {
     /// transaction_hold_up time has passed The actual transaction being
     /// executed will be signed by Governance PDA the Proposal belongs to
     /// For example to execute Program upgrade the ProgramGovernance PDA would
-    /// be used as the singer
+    /// be used as the signer
     ///
     ///   0. `[]` Governance account
     ///   1. `[writable]` Proposal account

libraries/program-error/README.md

@@ -129,7 +129,7 @@ It can be cumbersome to ensure your program's defined errors - typically represe
 in an enum - implement the required traits and will print to the program's logs when they're
 invoked.
 
-This procedureal macro will give you all of the required implementations out of the box:
+This procedural macro will give you all of the required implementations out of the box:
 
 - `Clone`
 - `Debug`

libraries/tlv-account-resolution/README.md

@@ -96,7 +96,7 @@ provided to initialize directly from a set of given accounts.
 
 ## Motivation
 
-The Solana account model presents unique challeneges for program interfaces.
+The Solana account model presents unique challenges for program interfaces.
 Since it's impossible to load additional accounts on-chain, if a program requires
 additional accounts to properly implement an instruction, there's no clear way
 for clients to fetch these accounts.

libraries/type-length-value/README.md

@@ -74,7 +74,7 @@ other_value1.data = 2;
 let other_value2 = state.init_value::<MyOtherPodValue>(true).unwrap();
 assert_eq!(other_value2.data, 10);
 // Update it in-place
-other_value1.data = 4;
+other_value2.data = 4;
 
 // Later on, to work with it again, since we did _not_ allow repeating entries,
 // we can just get the first value we encounter.
@@ -94,7 +94,7 @@ let value2 = state.get_value_with_repetition::<MyOtherPodValue>(2).unwrap();
 ## Motivation
 
 The Solana blockchain exposes slabs of bytes to on-chain programs, allowing program
-writers to intepret these bytes and change them however they wish. Currently,
+writers to interpret these bytes and change them however they wish. Currently,
 programs interpet account bytes as being only of one type. For example, an token
 mint account is only ever a token mint, an AMM pool account is only ever an AMM pool,
 a token metadata account can only hold token metadata, etc.