chore: remove redundant words in comment

docs/cip/README.md

@@ -379,7 +379,7 @@ Leios immediately enables use cases for high transaction volume and for more com
 
 #### High transaction volume
 
-Prototype simulations of the Leios protocol indicate that it can achieve at least 20 times the maximum throughput of the current Cardano mainnet. This amounts to approximately 2 MB/s or 1500 tx/s, assuming the current mean transaction size of 1400 bytes. The availability of Leios, however, would likely affect the characteristics of the mix of transactions, so the the maximum transaction rate could be higher or lower than this estimate. Whatever the specifics, Leios will enable transaction volumes that are orders of magnitude greater than Praos.
+Prototype simulations of the Leios protocol indicate that it can achieve at least 20 times the maximum throughput of the current Cardano mainnet. This amounts to approximately 2 MB/s or 1500 tx/s, assuming the current mean transaction size of 1400 bytes. The availability of Leios, however, would likely affect the characteristics of the mix of transactions, so the maximum transaction rate could be higher or lower than this estimate. Whatever the specifics, Leios will enable transaction volumes that are orders of magnitude greater than Praos.
 
 Aside from the general benefit of high capacity, several specific use cases could benefit.
 

docs/obsolete-report/leios-design.tex

@@ -1582,7 +1582,7 @@ \section{The Cardano mainnet: how fast is too fast?}
 might look like, and what the consequences would be and what mitigation might
 be possible.
 
-Suppose for the sake of argument that the system could be be run successfully
+Suppose for the sake of argument that the system could be run successfully
 at a rate of 5 input blocks per second, with each input block being 100kB.
 
 \paragraph{Disk space}

docs/technical-report-2.md

@@ -548,7 +548,7 @@ This discussion extends the section [Threat Model](./technical-report-1.md#threa
 - A smart contract at times have either *open* or *closed* participation. When a contract is open more than one party might be eligible to submit a transactions, but when it is closed only a specific party can submit a transaction. Auctions, lotteries, and liquidity pools typically are open contracts, though these could be formulated as hybrids. A zero-coupon bond or a European option might be a closed contract. Simple scripts could be open or closed. Transactions constructed by a single wallet and that do not spend from smart contracts could be considered closed because (presumably) only one party has the private keys necessary to spend the UTxOs. The distinction between open and closed UTxOs is important because the spender of a closed UTxO would typically have enough control of the situation that they could avoid creating a transaction that might conflict with others. Conversely, a spender of an open UTxO (in a script or smart contract) might not have sufficient information or control to avoid submitting a transaction that conflicts with transactions other users are submitting and which spend the same open UTxO.
 - *Equivocation* is when a block producer (IB, EB, or RB) or voter produces more than their entitled number of blocks or votes. For example, local sortition may entitle a node to produce one IB in a particular slot, but the node actually produces two different IBs in that slot and diffuses them to different downstream nodes: separately each IB is valid, but together they are not, so nodes will only adopt the IB that they receive first. The Leios protocol specifies that both the first block received and the first equivocation received both are diffused.
 - *Throughput loss* is when the overall capacity for non-conflicted transactions is reduced from the theoretical capability. Throughput is not considered lost if it is delayed and non-conflicted transactions originating from an adversary are not distinguished from those originating from honest parties. If an adversary pays for throughput, that throughput is not considered lost.
-- *Latency loss* is when there is an increase in the the average time from a transaction's acceptance in the memory pool to it recording on the ledger.
+- *Latency loss* is when there is an increase in the average time from a transaction's acceptance in the memory pool to it recording on the ledger.
 - *Front running* iFront-running occurs when a party submits a transaction after observing conflicting transactions in Input Blocks (IBs) or Endorser Blocks (EBs). If the newly submitted transaction is successful while the previously observed transaction(s) fail, the submitting party may gain an opportunity to extract value—for example, from decentralized exchanges (DEXes), liquidity pools, or oracle-sensitive dApps.
 - IB or EB *expiration* occurs when the block is not referenced by an EB or RB, respectively, before a timeout specified by the relevant Leios protocol parameter. Such expired blocks will never be included in the ledger.
 - *Grinding* occurs when an adversary attempts to manipulate VRF values in their favor using a trial-and-error process of crafting the entropy input into the VRF. See [CPS-21 "Ouroboros Randomness Manipulation"](https://cips.cardano.org/cps/CPS-0021) for details.