Uniswap · Akkii4 · May 19, 2023 · May 25, 2023 · May 25, 2023 · May 25, 2023
diff --git a/docs/concepts/research.md b/docs/concepts/research.md
@@ -26,7 +26,7 @@ Authors: Guillermo Angeris, Hsien-Tang Kao, Rei Chiang, Charlie Noyes, Tarun Chi
 
 Authors: Guillermo Angeris, Tarun Chitra
 
-> Automated market makers, first popularized by Hanson's logarithmic market scoring rule (or LMSR) for prediction markets, have become important building blocks, called 'primitives,' for decentralized finance. A particularly useful primitive is the ability to measure the price of an asset, a problem often known as the pricing oracle problem. In this paper, we focus on the analysis of a very large class of automated market makers, called constant function market makers (or CFMMs) which includes existing popular market makers such as Uniswap, Balancer, and Curve, whose yearly transaction volume totals to billions of dollars. We give sufficient conditions such that, under fairly general assumptions, agents who interact with these constant function market makers are incentivized to correctly report the price of an asset and that they can do so in a computationally efficient way. We also derive several other useful properties that were previously not known. These include lower bounds on the total value of assets held by CFMMs and lower bounds guaranteeing that no agent can, by any set of trades, drain the reserves of assets held by a given CFMM.
+> Automated market makers, first popularized by Hanson's logarithmic market scoring rule (or LMSR) for prediction markets, have become important building blocks, called 'primitives,' for decentralized finance. A particularly useful primitive is the ability to measure the price of an asset, a problem often known as the pricing oracle problem. In this paper, we focus on the analysis of a very large class of automated market makers, called constant function market makers (or CFMMs) which includes existing popular market makers such as Uniswap, Balancer, and Curve, whose yearly transaction volume totals to billions of dollars. We give sufficient conditions such that, under fairly general assumptions, agents who interact with these constant function market makers are incentivize to correctly report the price of an asset and that they can do so in a computationally efficient way. We also derive several other useful properties that were previously not known. These include lower bounds on the total value of assets held by CFMMs and lower bounds guaranteeing that no agent can, by any set of trades, drain the reserves of assets held by a given CFMM.
 
 - [Improved Price Oracles: Constant Function Market Makers](https://arxiv.org/abs/2003.10001)
 

diff --git a/docs/contracts/universal-router/01-overview.md b/docs/contracts/universal-router/01-overview.md
@@ -4,7 +4,7 @@ title: Overview
 sidebar_position: 1
 ---
 
-The `UniversalRouter` is an ETH, ERC20, and NFT swap router, that can aggregate trades across protocols to give users access highly-flexible and personalised transactions. The contract is unowned, and is not upgradeable.
+The `UniversalRouter` is an ETH, ERC20, and NFT swap router, that can aggregate trades across protocols to give users access highly-flexible and personalized transactions. The contract is unowned, and is not upgradeable.
 
 The flexible command style allows us to provide users with:
 

diff --git a/docs/contracts/v1/guides/04-custom-linking.md b/docs/contracts/v1/guides/04-custom-linking.md
@@ -104,8 +104,8 @@ The Pool page is made up of 3 subroutes: `add-liquidity`, `remove-liquidity`, `c
 
 ## Custom Routes
 
-Custom token routes can still be used in combination with URL paramters. URL paramters are higher in the settings hierarchy than custom routes.
+Custom token routes can still be used in combination with URL parameters. URL parameters are higher in the settings hierarchy than custom routes.
 
-An example using custom token route and URL paramters.
+An example using custom token route and URL parameters.
 
 `https://app.uniswap.org/#/swap/0x0F5D2fB29fb7d3CFeE444a200298f468908cC942?exactField=input&exactAmount=10&use=v1`
diff --git a/docs/contracts/v1/guides/05-iframe-integration.md b/docs/contracts/v1/guides/05-iframe-integration.md
@@ -15,7 +15,7 @@ It can also be useful if your application requires users to acquire some token i
 
 # iframe vs. custom UI
 
-One benefit of an iframe integration is that the your site will automatically keep up with any improvements/additions to the v1.app.uniswap.org site. After the initital integration is setup no further work is needed to pull in updates as the exchange site is updated over time.
+One benefit of an iframe integration is that the your site will automatically keep up with any improvements/additions to the v1.app.uniswap.org site. After the initial integration is setup no further work is needed to pull in updates as the exchange site is updated over time.
 
 # Live Example
 

diff --git a/docs/contracts/v1/reference/03-interfaces.md b/docs/contracts/v1/reference/03-interfaces.md
@@ -78,7 +78,7 @@ interface UniswapExchangeInterface {
     function tokenToExchangeTransferInput(uint256 tokens_sold, uint256 min_tokens_bought, uint256 min_eth_bought, uint256 deadline, address recipient, address exchange_addr) external returns (uint256  tokens_bought);
     function tokenToExchangeSwapOutput(uint256 tokens_bought, uint256 max_tokens_sold, uint256 max_eth_sold, uint256 deadline, address exchange_addr) external returns (uint256  tokens_sold);
     function tokenToExchangeTransferOutput(uint256 tokens_bought, uint256 max_tokens_sold, uint256 max_eth_sold, uint256 deadline, address recipient, address exchange_addr) external returns (uint256  tokens_sold);
-    // ERC20 comaptibility for liquidity tokens
+    // ERC20 compatibility for liquidity tokens
     bytes32 public name;
     bytes32 public symbol;
     uint256 public decimals;

diff --git a/docs/contracts/v2/concepts/01-protocol-overview/02-ecosystem-participants.md b/docs/contracts/v2/concepts/01-protocol-overview/02-ecosystem-participants.md
@@ -5,7 +5,7 @@ title: Ecosystem Participants
 
 ![](./images/participants.jpg)
 
-The Uniswap ecosystem is primarily comprised of three types of users: liquidity providers, traders, and developers. Liquidity providers are incentivized to contribute [ERC-20](https://eips.ethereum.org/EIPS/eip-20) tokens to common liquidity pools. Traders can swap these tokens for one another for a fixed [0.30% fee](../advanced-topics/fees) (which goes to liquidity providers). Developers can integrate directly with Uniswap smart contracts to power new and exciting interactions with tokens, trading interfaces, retail experiences, and more.
+The Uniswap ecosystem is primarily comprised of three types of users: liquidity providers, traders, and developers. Liquidity providers are incentivize to contribute [ERC-20](https://eips.ethereum.org/EIPS/eip-20) tokens to common liquidity pools. Traders can swap these tokens for one another for a fixed [0.30% fee](../advanced-topics/fees) (which goes to liquidity providers). Developers can integrate directly with Uniswap smart contracts to power new and exciting interactions with tokens, trading interfaces, retail experiences, and more.
 
 In total, interactions between these classes create a positive feedback loop, fueling digital economies by defining a common language through which tokens can be pooled, traded and used.
 
@@ -19,7 +19,7 @@ Liquidity providers, or LPs, are not a homogenous group:
 
 - Token projects sometimes choose to become LPs to create a liquid marketplace for their token. This allows tokens to be bought and sold more easily, and unlocks interoperability with other DeFi projects through Uniswap.
 
-- Finally, some DeFi pioneers are exploring complex liquidity provision interactions like incentivized liquidity, liquidity as collateral, and other experimental strategies. Uniswap is the perfect protocol for projects to experiment with these kinds of ideas.
+- Finally, some DeFi pioneers are exploring complex liquidity provision interactions like incentivize liquidity, liquidity as collateral, and other experimental strategies. Uniswap is the perfect protocol for projects to experiment with these kinds of ideas.
 
 # Traders
 
@@ -33,7 +33,7 @@ There are a several categories of traders in the protocol ecosystem:
 
 - Smart contracts that execute trades on the protocol by implementing swap functionality (from products like DEX aggregators to custom Solidity scripts).
 
-In all cases, trades are subject to the same flat fee for trading on the protocol. Each is important for increasing the accuracy of prices and incentivizing liquidity.
+In all cases, trades are subject to the same flat fee for trading on the protocol. Each is important for increasing the accuracy of prices and incentivize liquidity.
 
 # Developers/Projects
 

diff --git a/docs/contracts/v2/concepts/02-core-concepts/02-pools.md b/docs/contracts/v2/concepts/02-core-concepts/02-pools.md
@@ -7,7 +7,7 @@ title: Pools
 
 # Introduction
 
-Each Uniswap liquidity pool is a trading venue for a pair of ERC20 tokens. When a pool contract is created, its balances of each token are 0; in order for the pool to begin facilitating trades, someone must seed it with an initial deposit of each token. This first liquidity provider is the one who sets the initial price of the pool. They are incentivized to deposit an equal _value_ of both tokens into the pool. To see why, consider the case where the first liquidity provider deposits tokens at a ratio different from the current market rate. This immediately creates a profitable arbitrage opportunity, which is likely to be taken by an external party.
+Each Uniswap liquidity pool is a trading venue for a pair of ERC20 tokens. When a pool contract is created, its balances of each token are 0; in order for the pool to begin facilitating trades, someone must seed it with an initial deposit of each token. This first liquidity provider is the one who sets the initial price of the pool. They are incentivize to deposit an equal _value_ of both tokens into the pool. To see why, consider the case where the first liquidity provider deposits tokens at a ratio different from the current market rate. This immediately creates a profitable arbitrage opportunity, which is likely to be taken by an external party.
 
 When other liquidity providers add to an existing pool, they must deposit pair tokens proportional to the current price. If they don’t, the liquidity they added is at risk of being arbitraged as well. If they believe the current price is not correct, they may arbitrage it to the level they desire, and add liquidity at that price.
 
@@ -34,7 +34,7 @@ Uniswap is unique in that it doesn’t use an order book to derive the price of
 
 Liquidity is typically represented by discrete orders placed by individuals onto a centrally operated order book. A participant looking to provide liquidity or make markets must actively manage their orders, continuously updating them in response to the activity of others in the marketplace.
 
-While order books are foundational to finance and work great for certain usecases, they suffer from a few important limitations that are especially magnified when applied to a decentralized or blockchain-native setting. Order books require intermediary infrastructure to host the orderbook and match orders. This creates points of control and adds additional layers of complexity. They also require active participation and management from market makers who usually use sophisticated infrastructure and algorithms, limiting participation to advanced traders. Order books were invented in a world with relatively few assets being traded, so it is not surprising they aren't ideal for an ecosystem where anyone can create their own token, and those tokens usually have low liquidity. In sum, with the infrastructural trade-offs presented by a platform like Ethereum, order books are not the native architecture for implementing a liquidity protocol on a blockchain.
+While order books are foundational to finance and work great for certain use cases, they suffer from a few important limitations that are especially magnified when applied to a decentralized or blockchain-native setting. Order books require intermediary infrastructure to host the orderbook and match orders. This creates points of control and adds additional layers of complexity. They also require active participation and management from market makers who usually use sophisticated infrastructure and algorithms, limiting participation to advanced traders. Order books were invented in a world with relatively few assets being traded, so it is not surprising they aren't ideal for an ecosystem where anyone can create their own token, and those tokens usually have low liquidity. In sum, with the infrastructural trade-offs presented by a platform like Ethereum, order books are not the native architecture for implementing a liquidity protocol on a blockchain.
 
 Uniswap focuses on the strengths of Ethereum to reimagine token swaps from first principles.
 

diff --git a/docs/contracts/v2/concepts/03-advanced-topics/03-understanding-returns.md b/docs/contracts/v2/concepts/03-advanced-topics/03-understanding-returns.md
@@ -3,7 +3,7 @@ id: understanding-returns
 title: Understanding Returns
 ---
 
-Uniswap incentivizes users to add liquidity to trading pools by rewarding providers with the fees generated when other users trade with those pools. Market making, in general, is a complex activity. There is a risk of losing money during large and sustained movement in the underlying asset price compared to simply holding an asset.
+Uniswap incentivize users to add liquidity to trading pools by rewarding providers with the fees generated when other users trade with those pools. Market making, in general, is a complex activity. There is a risk of losing money during large and sustained movement in the underlying asset price compared to simply holding an asset.
 
 # Risks
 

diff --git a/docs/contracts/v2/concepts/03-advanced-topics/06-research.md b/docs/contracts/v2/concepts/03-advanced-topics/06-research.md
@@ -25,7 +25,7 @@ Authors: Guillermo Angeris, Hsien-Tang Kao, Rei Chiang, Charlie Noyes, Tarun Chi
 
 Authors: Guillermo Angeris, Tarun Chitra
 
-> Automated market makers, first popularized by Hanson's logarithmic market scoring rule (or LMSR) for prediction markets, have become important building blocks, called 'primitives,' for decentralized finance. A particularly useful primitive is the ability to measure the price of an asset, a problem often known as the pricing oracle problem. In this paper, we focus on the analysis of a very large class of automated market makers, called constant function market makers (or CFMMs) which includes existing popular market makers such as Uniswap, Balancer, and Curve, whose yearly transaction volume totals to billions of dollars. We give sufficient conditions such that, under fairly general assumptions, agents who interact with these constant function market makers are incentivized to correctly report the price of an asset and that they can do so in a computationally efficient way. We also derive several other useful properties that were previously not known. These include lower bounds on the total value of assets held by CFMMs and lower bounds guaranteeing that no agent can, by any set of trades, drain the reserves of assets held by a given CFMM.
+> Automated market makers, first popularized by Hanson's logarithmic market scoring rule (or LMSR) for prediction markets, have become important building blocks, called 'primitives,' for decentralized finance. A particularly useful primitive is the ability to measure the price of an asset, a problem often known as the pricing oracle problem. In this paper, we focus on the analysis of a very large class of automated market makers, called constant function market makers (or CFMMs) which includes existing popular market makers such as Uniswap, Balancer, and Curve, whose yearly transaction volume totals to billions of dollars. We give sufficient conditions such that, under fairly general assumptions, agents who interact with these constant function market makers are incentivize to correctly report the price of an asset and that they can do so in a computationally efficient way. We also derive several other useful properties that were previously not known. These include lower bounds on the total value of assets held by CFMMs and lower bounds guaranteeing that no agent can, by any set of trades, drain the reserves of assets held by a given CFMM.
 
 - [Improved Price Oracles: Constant Function Market Makers](https://arxiv.org/abs/2003.10001)
 

diff --git a/docs/contracts/v2/reference/API/02-entities.md b/docs/contracts/v2/reference/API/02-entities.md
@@ -70,7 +70,7 @@ Information about a pair. Includes references to each token within the pair, vol
 ### User
 
 A user entity is created for any address that provides liquidity to a pool on Uniswap. This entity
-can be used to track open positions for users. LiquidyPosition entities can be referenced to get
+can be used to track open positions for users. LiquidityPosition entities can be referenced to get
 specific data about each position.
 
 | Field Name         | Value Type          | Description                                    |
@@ -79,7 +79,7 @@ specific data about each position.
 | liquidityPositions | [LiquidityPosition] | array of all liquidity positions user has open |
 | usdSwapped         | BigDecimal          | total USD value swapped                        |
 
-### LiquidityPositiion
+### LiquidityPosition
 
 This entity is used to store data about a user's liquidity position. This information, along with
 information from the pair itself can be used to provide position sizes, token deposits, and more.

diff --git a/docs/contracts/v2/reference/Governance/governance-reference.md b/docs/contracts/v2/reference/Governance/governance-reference.md
@@ -126,7 +126,7 @@ Delegate votes from the sender to the delegatee. Users can delegate to 1 address
 
 | Name      | Type      |                                                                                                                     |
 | :-------- | :-------- | :------------------------------------------------------------------------------------------------------------------ |
-| delegatee | `address` | The address to which msg.sender wishis to delegate their vote to                                                    |
+| delegatee | `address` | The address to which msg.sender wishes to delegate their vote to                                                    |
 | nonce     | `uint`    | The contract state required to match the signature. This can be retrieved from the contract’s public nonces mapping |
 | expiry    | `uint`    | The time when the signature expires. A block timestamp in seconds since the unix epoch.                             |
 | v         | `uint`    | The recovery byte of the signature.                                                                                 |

diff --git a/docs/contracts/v2/reference/smart-contracts/02-pair.md b/docs/contracts/v2/reference/smart-contracts/02-pair.md
@@ -94,7 +94,7 @@ Returns the address of the pair token with the higher sort order.
 function getReserves() external view returns (uint112 reserve0, uint112 reserve1, uint32 blockTimestampLast);
 ```
 
-Returns the reserves of token0 and token1 used to price trades and distribute liquidity. See [Pricing](../../concepts/advanced-topics/pricing). Also returns the `block.timestamp` (mod `2**32`) of the last block during which an interaction occured for the pair.
+Returns the reserves of token0 and token1 used to price trades and distribute liquidity. See [Pricing](../../concepts/advanced-topics/pricing). Also returns the `block.timestamp` (mod `2**32`) of the last block during which an interaction occurred for the pair.
 
 ## price0CumulativeLast
 

diff --git a/docs/contracts/v2/reference/smart-contracts/05-router01.md b/docs/contracts/v2/reference/smart-contracts/05-router01.md
@@ -212,7 +212,7 @@ function removeLiquidityETHWithPermit(
 ) external returns (uint amountToken, uint amountETH);
 ```
 
-Removes liquidity from an ERC-20⇄WETTH pool and receive ETH without pre-approval, thanks to [permit](pair-erc-20#permit).
+Removes liquidity from an ERC-20⇄WETH pool and receive ETH without pre-approval, thanks to [permit](pair-erc-20#permit).
 
 | Name           | Type      |                                                                                      |
 | :------------- | :-------- | :----------------------------------------------------------------------------------- |

diff --git a/docs/contracts/v2/reference/smart-contracts/06-router02.md b/docs/contracts/v2/reference/smart-contracts/06-router02.md
@@ -240,7 +240,7 @@ function removeLiquidityETHWithPermit(
 ) external returns (uint amountToken, uint amountETH);
 ```
 
-Removes liquidity from an ERC-20⇄WETTH pool and receive ETH without pre-approval, thanks to [permit](pair-erc-20#permit).
+Removes liquidity from an ERC-20⇄WETH pool and receive ETH without pre-approval, thanks to [permit](pair-erc-20#permit).
 
 | Name           | Type      |                                                                                      |
 | :------------- | :-------- | :----------------------------------------------------------------------------------- |

diff --git a/docs/contracts/v3/guides/governance/license-modifications.md b/docs/contracts/v3/guides/governance/license-modifications.md
@@ -1,5 +1,5 @@
 ---
-id: liscense-modifications
+id: license-modifications
 title: License Modifications
 ---