Fix links, PR Template, spelling

.github/PULL_REQUEST_TEMPLATE.md

@@ -18,7 +18,7 @@ Before we can merge this PR, please make sure that all the following items have
 checked off. If any of the checklist items are not applicable, please leave them but
 write a little note why.
 
-- [ ] Targeted PR against correct branch (master)
+- [ ] Targeted PR against correct branch (main)
 - [ ] Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
 - [ ] Wrote unit tests
 - [ ] Updated relevant documentation in the code

CONTRIBUTING.md

@@ -33,7 +33,7 @@ All other branches should be assumed to be miscellaneous feature development bra
 All downstream users of the library should be using tagged versions of the library pulled from cargo.
 
 ## How to work on a fork
-Please skip this section if you're familiar with contributing to opensource github projects.
+Please skip this section if you're familiar with contributing to open source github projects.
 
 First fork the repo from the github UI, and clone it locally.
 Then in the repo, you want to add the repo you forked from as a new remote. You do this as:

README.md

@@ -32,7 +32,7 @@ First, checkout the `main` branch in the repository.
 ### Exercise 1: Merkle Tree Example
 
 We'll design a simple circuit for checking a Merkle tree membership path for a given leaf.
-Open [`merkle-tree-example/README.md`](./merkle-tree-example/src/README.md).
+Open [`merkle-tree-example/README.md`](./merkle-tree-example/README.md).
 
 ### Exercise 2: Validating a single transaction
 

merkle-tree-example/src/README.md → merkle-tree-example/README.md

@@ -36,7 +36,7 @@ Let's go over this incantation part-by-part.
 
 We similarly allocate the leaf as a public input variable, and allocate the parameters of the hash as "constants" in the constraint system. This means that these parameters are "baked" into the constraint system when it is created, and changing these parameters would result in a different constraint system. Finally, we allocate the membership path as a private witness variable.
 
-Now, we must  fill in the blanks by addng constraints to check the membership path. Go ahead and follow the hint in `constraints.rs` to complete this task.
+Now, we must  fill in the blanks by adding constraints to check the membership path. Go ahead and follow the hint in `constraints.rs` to complete this task.
 
 ## Testing our constraints
 

rollup/README.md

@@ -14,7 +14,7 @@ At a high level, the constraint system for batch verification works as follows:
   (1) Check a Merkle Tree path wrt initial root that demonstrates the existence of the sender's account.
   (2) Check a Merkle Tree path wrt initial root that demonstrates the existence of the receiver's account.
   (3) Verify the signature in the transaction with respect to the sender's public key.
-  (4) Verify that sender.balance >= tx.amont (i.e., sender has sufficient funds).
+  (4) Verify that sender.balance >= tx.amount (i.e., sender has sufficient funds).
   (5) Compute new balances for both the sender and the receiver.
   (6) Check a Merkle Tree path wrt final root for the new sender balance.
   (7) Check a Merkle Tree path wrt final root for the new receiver balance.

simple-payments/README.md

@@ -39,6 +39,6 @@ We use a simple custom implementation of Schnorr signatures over the prime order
 Our implementation uses the Merkle tree of [`ark-crypto-primitives`](https://docs.rs/ark-crypto-primitives/0.3.0/ark_crypto_primitives/merkle_tree/index.html). This is the same tree that we saw in the `merkle-tree-example` step. In our system, the concrete underlying hash function is the Pedersen hash function, as implemented in the [`ark-crypto-primitives` crate](https://docs.rs/ark-crypto-primitives/0.3.0/ark_crypto_primitives/crh/pedersen/index.html). This hash is implemented over the prime-order subgroup of the Jubjub curve.
 
 
-## Code walkthrough
+## Code walk-through
 
 To get an overview of important data structures as well as their associated methods, run `cargo doc --open --no-deps`.