penumbra-zone · hdevalence · Dec 11, 2023 · Dec 9, 2023 · Dec 9, 2023 · Dec 9, 2023
diff --git a/docs/guide/src/dev/protobuf.md b/docs/guide/src/dev/protobuf.md
@@ -7,7 +7,7 @@ are relevant:
   * `proto/penumbra/**/*.proto`, the developer-authored spec files
   * `crates/proto/src/gen/*.rs`, the generated Rust code files
   * `proto/go/**/*.pb.go`, the generated Go code files
-  * `tools/proto-compiler/`, the build logic for generated the Rust code files
+  * `tools/proto-compiler/`, the build logic for generating the Rust code files
 
 We use [buf] to auto-publish the protobuf schemas at
 [buf.build/penumbra-zone/penumbra][protobuf], and to generate Go and Typescript packages.

diff --git a/docs/guide/src/pd/install.md b/docs/guide/src/pd/install.md
@@ -4,7 +4,7 @@ Download prebuilt binaries from the [Penumbra releases page on Github](https://g
 Make sure to use the most recent version available, as the version of `pd` must
 match the software currently running on the network.
 
-Make sure choose the correct platform for your machine. After downloading the `.tar.xz` file,
+Make sure to choose the correct platform for your machine. After downloading the `.tar.xz` file,
 extract it, and copy its contents to your `$PATH`. For example:
 
 ```

diff --git a/docs/guide/src/pd/join-testnet.md b/docs/guide/src/pd/join-testnet.md
@@ -241,7 +241,7 @@ First fetch your existing validator definition from the chain:
 pcli validator definition fetch --file validator.toml
 ```
 
-Then make any changes desired and **make sure to increase by `sequence_number` by at least 1!**
+Then make any changes desired and **make sure to increase `sequence_number` by at least 1!**
 The `sequence_number` is a unique, increasing identifier for the version of the validator definition.
 
 After updating the validator definition you can upload it again to update your validator metadata on-chain:

diff --git a/docs/protocol/src/concepts/batching_flows.md b/docs/protocol/src/concepts/batching_flows.md
@@ -28,7 +28,7 @@ allowing value flows to be batched over any time interval from 1 block up to the
 length of an epoch. We propose epoch boundaries on the order of 1-3 days.
 
 At the beginning of each epoch, the validator set performs distributed key
-generation for to produce a decryption key jointly controlled by the
+generation to produce a decryption key jointly controlled by the
 validators (on an approximately stake-weighted basis) and includes the
 encryption key in the first block of the epoch.
 

diff --git a/docs/protocol/src/crypto/flow-encryption/dkg.md b/docs/protocol/src/crypto/flow-encryption/dkg.md
@@ -117,7 +117,7 @@ on the delay between the start of a new epoch and the completion of the DKG as
 
 This could potentially be pipelined by including each participant's commitments for the next epoch (the commitments $a_{ij}*G$ from FROST) in the block data at one of the last blocks of the previous epoch. *Round 2* of FROST could occur during the vote extensions phase of the epoch transition block.
 
-***NOTE***: FROST requries private communication channels for round 2, thus we
+***NOTE***: FROST requires private communication channels for round 2, thus we
 must assign validators encryption keys, perform key agreement, and encrypt
 round 2 communications before placing them in the vote extension. This can be
 accomplished using ECDH with `decaf377`, and an AEAD cipher (though

diff --git a/docs/protocol/src/crypto/flow/ideal.md b/docs/protocol/src/crypto/flow/ideal.md
@@ -51,7 +51,7 @@ the specific instantiation.
 
 ###### `FlowEnc/Encrypt`
 
-This an algorithm run by users. On input an encryption key $D$ and the opening
+This is an algorithm run by users. On input an encryption key $D$ and the opening
 $(v, \widetilde{v})$
 to a Pedersen commitment $C$, this algorithm outputs a
 ciphertext $E = \operatorname{Enc}(v)$ and a proof $\pi_{\operatorname{Enc}}$ which establishes that

diff --git a/docs/protocol/src/governance.md b/docs/protocol/src/governance.md
@@ -36,7 +36,7 @@ proposer at the end of voting.
 From the proposer's point of view, the lifecycle of a proposal begins when it is
 _submitted_ and ends when it the deposit is _claimed_. During the voting period, the proposer may
 also optionally _withdraw_ the proposal, which prevents it from passing, but does not prevent it
-from being slashed. This is usually used when a proposal has been superceded by a revised
+from being slashed. This is usually used when a proposal has been superseded by a revised
 alternative.
 
 <picture>

diff --git a/docs/protocol/src/ibc.md b/docs/protocol/src/ibc.md
@@ -30,7 +30,7 @@ In order to support the IBC protocol, Penumbra adds a single additional Action
 * `Acknowledgement`
 
 These datagrams are implemented as protocol buffers, with the enclosing
-`IBCAction` type using profobuf's `OneOf` directive to encapsulate all possible
+`IBCAction` type using protobuf's `OneOf` directive to encapsulate all possible
 IBC datagram types.
 
 # Transfers into Penumbra

diff --git a/docs/protocol/src/zswap/swap.md b/docs/protocol/src/zswap/swap.md
@@ -164,7 +164,7 @@ potential places to try to correlate amounts:
 - Each epoch discloses the net amount of newly bonded stake for each validator;
 - Liquidity pool deposits disclose the precise type and amount of newly
   deposited reserves;
-- Liquidity pool deposits disclose the precise type and amount of newly
+- Liquidity pool withdrawals disclose the precise type and amount of newly
   withdrawn reserves;
 
 The existence of the swap mechanism potentially makes correlation by amount more

diff --git a/docs/rustdoc/README.md b/docs/rustdoc/README.md
@@ -12,4 +12,4 @@ like so:
 REGENERATE_INDEX=1 ./deployments/scripts/rust-docs
 ```
 
-and then commiting the changes, if any, to `docs/rustdoc/index.html`.
+and then committing the changes, if any, to `docs/rustdoc/index.html`.