Fix typos (#1062)

README.md

@@ -24,10 +24,10 @@ For a much more detailed explanation of the economic design, including an hour-l
 - [System Design](https://github.com/reserve-protocol/protocol/blob/master/docs/system-design.md): The overall architecture of our system, and some detailed descriptions about what our protocol is _intended_ to do.
 - [Pause and Freeze States](https://github.com/reserve-protocol/protocol/blob/master/docs/pause-freeze-states.md): An overview of which protocol functions are halted in the paused and frozen states.
 - [Deployment Variables](https://github.com/reserve-protocol/protocol/blob/master/docs/deployment-variables.md) A detailed description of the governance variables of the protocol.
-- [Our Solidity Style](https://github.com/reserve-protocol/protocol/blob/master/docs/solidity-style.md): Common practices, details, and conventions relevant to reading and writing our Solidity source code, estpecially where those go beyond standard practice.
+- [Our Solidity Style](https://github.com/reserve-protocol/protocol/blob/master/docs/solidity-style.md): Common practices, details, and conventions relevant to reading and writing our Solidity source code, especially where those go beyond standard practice.
 - [Writing Collateral Plugins](https://github.com/reserve-protocol/protocol/blob/master/docs/collateral.md): An overview of how to develop collateral plugins and the concepts / questions involved.
 - [Building on Top](https://github.com/reserve-protocol/protocol/blob/master/docs/build-on-top.md): How to build on top of Reserve, including information about long-lived fork environments.
-- [MEV](https://github.com/reserve-protocol/protocol/blob/master/docs/mev.md): A resource for MEV searchers and others looking to interact with the deployed protocol programatically.
+- [MEV](https://github.com/reserve-protocol/protocol/blob/master/docs/mev.md): A resource for MEV searchers and others looking to interact with the deployed protocol programmatically.
 - [Rebalancing Algorithm](https://github.com/reserve-protocol/protocol/blob/master/docs/recollateralization.md): Description of our trading algorithm during the recollateralization process
 - [Changelog](https://github.com/reserve-protocol/protocol/blob/master/CHANGELOG.md): Release changelog
 
@@ -64,7 +64,7 @@ Deployed collateral plugin addresses and their configuration parameters can be f
 
 We have a `p0` and `p1` implementation for each contract in our core system. The `p0` version is our _specification_ prototype, and is intended to be as easy as possible to understand. The `p1` version should behave identically, except that it employs substantial optimizations and more complicated algorithms in order to achieve lower gas costs.
 
-We implement and maintain both of these systems in the name of correctness. Implementing p0 helps us to specify the exact intended behavior of the protocol without needing to deal simultaneously with gas optimization; maintaining equivalent behavior of both serves as a substantial extra form of testing. The behavior of each contract in `p1` should be _identical_ to the behavior of the corresponding contract in `p0`, so we can perform [differential testing](https://en.wikipedia.org/wiki/Differential_testing) between them - checking that they behave identicially, both in our explicit tests and in arbitrary randomized tests.
+We implement and maintain both of these systems in the name of correctness. Implementing p0 helps us to specify the exact intended behavior of the protocol without needing to deal simultaneously with gas optimization; maintaining equivalent behavior of both serves as a substantial extra form of testing. The behavior of each contract in `p1` should be _identical_ to the behavior of the corresponding contract in `p0`, so we can perform [differential testing](https://en.wikipedia.org/wiki/Differential_testing) between them - checking that they behave identically, both in our explicit tests and in arbitrary randomized tests.
 
 We thought `p0` and `p1` would end up being a lot more different than they ended up being. For the most part the contracts only really differ for `StRSR.sol`, and a little for `RToken.sol`.
 
@@ -83,7 +83,7 @@ P1 is the production version of the economic protocol.
 - Upgradable
 - Optimized for gas costs
 - No function call needs more than _O(lg N)_ time or space, and it's _O(1)_ where possible.
-  - Caveat: a function might be _O(k)_, where _k_ is the number of registered Assets or Collateral tokens; however, we take great care to make those loops efficient, and to avoid _O(k^2)_ behvior!
+  - Caveat: a function might be _O(k)_, where _k_ is the number of registered Assets or Collateral tokens; however, we take great care to make those loops efficient, and to avoid _O(k^2)_ behavior!
 - No user is ever forced to pay gas to process other users' transactions.
 
 ## Repository Structure

docs/collateral.md

@@ -97,7 +97,7 @@ interface ICollateral is IAsset {
 
   /// @dev refresh()
   /// Refresh exchange rates and update default status.
-  /// VERY IMPORTANT: In any valid implemntation, status() MUST become DISABLED in refresh() if
+  /// VERY IMPORTANT: In any valid implementation, status() MUST become DISABLED in refresh() if
   /// refPerTok() has ever decreased since last call.
 
   /// @return The canonical name of this collateral's target unit.
@@ -122,7 +122,7 @@ interface ICollateral is IAsset {
 Broadly speaking there are two ways a collateral can default:
 
 1.  Fast: `refresh()` detects a clear problem with its defi protocol, and triggers in an immediate default. For instance, anytime the `refPerTok()` exchange rate falls between calls to `refresh()`, the collateral should immediately default.
-2.  Slow: `refresh()` detects a error condition that will _probably_ recover, but which should cause a default eventually. For instance, if the Collateral relies on USDT, and our price feed says that USDT trades at less than \$0.95 for (say) 24 hours, the Collateral should default. If a needed price feed is out-of-date or reverting for a similar period, the Collateral should default.
+2.  Slow: `refresh()` detects an error condition that will _probably_ recover, but which should cause a default eventually. For instance, if the Collateral relies on USDT, and our price feed says that USDT trades at less than \$0.95 for (say) 24 hours, the Collateral should default. If a needed price feed is out-of-date or reverting for a similar period, the Collateral should default.
 
     In either of these cases, the collateral should first become `IFFY` and only move to `DISABLED` after the problem becomes sustained. In general, any pathway for default that cannot be assessed immediately should go through this delayed flow.
 

docs/deployment.md

@@ -2,7 +2,7 @@
 
 Mostly, this is about _test_ deployment, though the same elements should work to deploy to any network once configured.
 
-Real mainnet deployment, though, will entail an deployment checklist (see below) and serious operational security considerations (not yet articulated).
+Real mainnet deployment, though, will entail a deployment checklist (see below) and serious operational security considerations (not yet articulated).
 
 ## Configure Environment
 
@@ -146,7 +146,7 @@ First, clear any stale `*-tmp-*.json` deployment files if it's important for the
 
 Do NOT screenshare this part!
 
-It's important that nobody know the deployment key between steps 1 and 2 of the FacadeWrite: `phase3-rtoken/1_deploy_rtoken.ts` and `phase3-rtoken/2_deploy_governance.ts`. But beyond this, we do not require the deployment key to be highly secured. The key will need to hold a decent amount of ETH in order to pay for deployment (estimate: at minimum 3 ETH at 30 gwei) and we certainly do not want someone to come in and snipe our deployment between the FacadeWrite steps, causing us to have to start the FacadeWrite steps again.
+It's important that nobody knows the deployment key between steps 1 and 2 of the FacadeWrite: `phase3-rtoken/1_deploy_rtoken.ts` and `phase3-rtoken/2_deploy_governance.ts`. But beyond this, we do not require the deployment key to be highly secured. The key will need to hold a decent amount of ETH in order to pay for deployment (estimate: at minimum 3 ETH at 30 gwei) and we certainly do not want someone to come in and snipe our deployment between the FacadeWrite steps, causing us to have to start the FacadeWrite steps again.
 
 First, make sure you have golang setup on your machine. If you don't, here are the quick steps:
 

docs/dev-env.md

@@ -30,7 +30,7 @@ npm install -g yarn
 # Clone this repo
 git clone [email protected]:reserve-protocol/protocol.git
 
-# Install pacakges from npm (including Solidity dependencies)
+# Install packages from npm (including Solidity dependencies)
 cd protocol
 yarn
 
@@ -101,7 +101,7 @@ However, ensure that you do not change the value of `.husky/pre-push` in our sha
 
 ## Echidna
 
-We _have_ some tooling for testing with Echidna, but it is specically in `fuzz` branch of the repo. See that branch and our [echidna usage docs](using-echidna.md)
+We _have_ some tooling for testing with Echidna, but it is specifically in `fuzz` branch of the repo. See that branch and our [echidna usage docs](using-echidna.md)
 
 ## Test Deployment
 

docs/exhaustive-tests.md

@@ -1,6 +1,6 @@
 # Exhaustive Testing
 
-The exhaustive tests include `Broker.test.ts`, `Furnace.test.ts`, `RToken.test.ts`, `ZTradingExtremes.test.ts` and `ZZStRSR.test.ts`, and are meant to test the protocol when given permutations of input values on the extreme ends of the spectrum of possiblities.
+The exhaustive tests include `Broker.test.ts`, `Furnace.test.ts`, `RToken.test.ts`, `ZTradingExtremes.test.ts` and `ZZStRSR.test.ts`, and are meant to test the protocol when given permutations of input values on the extreme ends of the spectrum of possibilities.
 
 The env vars related to exhaustive testing are `EXTREME` and `SLOW`.
 

docs/mev.md

@@ -1,6 +1,6 @@
 # MEV
 
-This document is intended to serve as a resource for MEV searchers and others looking to interact with the deployed protocol programatically.
+This document is intended to serve as a resource for MEV searchers and others looking to interact with the deployed protocol programmatically.
 
 ## Overview
 
@@ -55,7 +55,7 @@ For a sample price curve, see [docs/system-design.md](./system-design.md#sample-
 
 #### GnosisTrade
 
-`GnosisTrade.sol` implements a batch auction on top of Gnosis's [EasyAuction](https://github.com/gnosis/ido-contracts/blob/main/contracts/EasyAuction.sol) platform. In general a batch auction is designed to minimize MEV, and indeed that's why it was chosen in the first place. Both types of auctions (batch + dutch) can be opened at anytime, but the expectation is that dutch auctions will be preferred by MEV searchers because they are more likely to be profitable.
+`GnosisTrade.sol` implements a batch auction on top of Gnosis's [EasyAuction](https://github.com/gnosis/ido-contracts/blob/main/contracts/EasyAuction.sol) platform. In general a batch auction is designed to minimize MEV, and indeed that's why it was chosen in the first place. Both types of auctions (batch + dutch) can be opened at any time, but the expectation is that dutch auctions will be preferred by MEV searchers because they are more likely to be profitable.
 
 However, if a batch auction is launched, an MEV searcher may still be able to profit. In order to bid in the auction, the searcher must call `function placeSellOrders(uint256 auctionId, uint96[] memory _minBuyAmounts, uint96[] memory _sellAmounts, bytes32[] memory _prevSellOrders, bytes calldata allowListCallData)`, providing an approval in advance. This call will escrow `_sellAmounts` tokens in EasyAuction for the remaining duration of the auction. Once the auction is over, anyone can settle the auction directly in EasyAuction via `settleAuction(uint256 auctionId)`, or by calling `settleTrade(IERC20 erc20)` on the `ITrading` instance in our system that started the trade (either BackingManager or a RevenueTrader).
 

docs/pause-freeze-states.md

@@ -45,7 +45,7 @@ The issuance-paused states indicates that RToken issuance should be paused, and
 
 ## Trading-pause
 
-The trading-paused state has significantly more scope than the issuance-paused state. It is designed to prevent against cases where the protocol may trade unneccesarily. Many other functions in addition to just `BackingManager.rebalance()` and `RevenueTrader.manageTokens()` are halted. In general anything that manages the backing and revenue for an RToken is halted. This may become neccessary to use due to (among other things):
+The trading-paused state has significantly more scope than the issuance-paused state. It is designed to prevent against cases where the protocol may trade unnecessarily. Many other functions in addition to just `BackingManager.rebalance()` and `RevenueTrader.manageTokens()` are halted. In general anything that manages the backing and revenue for an RToken is halted. This may become necessary to use due to (among other things):
 
 - An asset's `price()` malfunctions or is manipulated
 - A collateral's default detection has a false positive or negative
@@ -58,15 +58,15 @@ An important function of freezing is to provide a finite time for governance to
 
 ### `Furnace.melt()`
 
-It is necessary for `Furnace.melt()` to remain emabled in order to allow `RTokenAsset.refresh()` to update its `price()`. Any revenue RToken that has already accumulated at the Furnace will continue to be melted, but the flow of new revenue RToken into the contract is halted.
+It is necessary for `Furnace.melt()` to remain enabled in order to allow `RTokenAsset.refresh()` to update its `price()`. Any revenue RToken that has already accumulated at the Furnace will continue to be melted, but the flow of new revenue RToken into the contract is halted.
 
 ### `StRSR.payoutRewards()`
 
 It is necessary for `StRSR.payoutRewards()` to remain enabled in order for `StRSR.stake()` to use the up-to-date StRSR-RSR exchange rate. If it did not, then in the event of freezing there would be an unfair benefit to new stakers. Any revenue RSR that has already accumulated at the StRSR contract will continue to be paid out, but the flow of new revenue RSR into the contract is halted.
 
 ### `StRSR.stake()`
 
-It is important for `StRSR.stake()` to remain emabled while frozen in order to allow honest RSR to flow into an RToken to vote against malicious governance proposals.
+It is important for `StRSR.stake()` to remain enabled while frozen in order to allow honest RSR to flow into an RToken to vote against malicious governance proposals.
 
 ### `*.settleTrade()`
 

docs/recollateralization.md

@@ -38,7 +38,7 @@ As trades complete, the distance between the top and bottom of the BU price band
 
 In the optimistic case we assume we start with `basketsHeldBy(backingManager).top` basket units and deduct from this the balance deficit for each backing collateral in terms of basket units (converted optimistically). For deficits we assume the low sell price and high basket unit price. We assume no impact from maxTradeSlippage or minTradeVolume dust loss. Finally we add-in contributions from all surplus balances, this time assuming the high sell price and low basket unit price.
 
-Alltogether, this is how many BUs we would end up with after recapitalization if everything went as well as possible.
+Altogether, this is how many BUs we would end up with after recapitalization if everything went as well as possible.
 
 #### `basketRange.bottom`
 
@@ -52,7 +52,7 @@ The BU price band is used in order to determine token surplus/deficit: token sur
 
 This allows the protocol to deterministically select the next trade based on the following set of constraints (in this order of consideration):
 
-1. Always sell more than than the [`minTradeVolume`](system-design.md#minTradeVolume) governance param
+1. Always sell more than the [`minTradeVolume`](system-design.md#minTradeVolume) governance param
 2. Never sell more than the [`maxTradeVolume`](system-design.md#rTokenMaxTradeVolume) governance param
 3. Sell `DISABLED` collateral first, `SOUND` next, and `IFFY` last.
    (Non-collateral assets are considered SOUND for these purposes.)