diff --git a/docs/concepts/research.md b/docs/concepts/research.md index bc23a994c0..237d5e3f05 100644 --- 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 index 57db78acb2..1e44fa8c85 100644 --- 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 index 1bc3a2d5ff..732f8023b6 100644 --- 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 index 1f2eecfda2..940b49e6d4 100644 --- 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 index 0b43bf3010..ddbe672456 100644 --- 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 index 0e337231b3..6f29c42e79 100644 --- 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 index 7619e1cc79..911c6e050d 100644 --- 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 index e3bdbb6194..9e7d67d60c 100644 --- 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 index c7dc748a33..13558ec3c9 100644 --- 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 index 1719109085..07550268dd 100644 --- 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 index 10558f4294..d5f56fe55e 100644 --- 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 index 472c08a995..b3c976d0f6 100644 --- 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 index 9ed402c9ac..d447769110 100644 --- 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 index 5c07b7b886..8d25752d1d 100644 --- 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 index cebb913f0f..a2ec5b9ebd 100644 --- 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 --- diff --git a/docs/contracts/v3/guides/liquidity-mining/overview.md b/docs/contracts/v3/guides/liquidity-mining/overview.md index f7552d5dba..7b7f5452a2 100644 --- a/docs/contracts/v3/guides/liquidity-mining/overview.md +++ b/docs/contracts/v3/guides/liquidity-mining/overview.md @@ -38,9 +38,9 @@ Once deposited, a user may then _stake_ their NFT into any number of active `Inc There are two conditions that must be met for a program to be considered concluded: -1. `block.timestamp >= endTime`: In other words, the program's duration must have expired. However, this doesn't mark the official end of the program, as some users may still be participating right up unti this `endTime` boundary and beyond, to maximize their rewards. This leads directly to the second condition. +1. `block.timestamp >= endTime`: In other words, the program's duration must have expired. However, this doesn't mark the official end of the program, as some users may still be participating right up until this `endTime` boundary and beyond, to maximize their rewards. This leads directly to the second condition. 2. All NFTs must be unstaked: A program can conclude only when every NFT which participated in it is unstaked. To ensure this is always possible, after the `endTime` of a program _anyone_ may unstake _any_ NFT (though of course they may not claim outstanding `rewardToken`s due to the NFT owner). This ensures that even if all users do not unstake themselves, someone can unstake them manually so that the program can end. -It's important that most or all programs fully conclude, primarily so that the `refundee` can reclaim any unallocated rewards. What are the conditions under which unallocated rewards will remain? Well, recall that the reward rate is the same across _all_ in-range liquidity. However, only program participants may actually claim accrued tokens, so it's likely that all programs will end up with a balance of `rewardToken`s that cannot be claimed. So, `refundee`s will typically be incentivized to bring programs to an official conclusion. This slightly cumbersome design is a consequence of the difficulty of consistently allocating rewards proportional to Uniswap V3 liquidity. +It's important that most or all programs fully conclude, primarily so that the `refundee` can reclaim any unallocated rewards. What are the conditions under which unallocated rewards will remain? Well, recall that the reward rate is the same across _all_ in-range liquidity. However, only program participants may actually claim accrued tokens, so it's likely that all programs will end up with a balance of `rewardToken`s that cannot be claimed. So, `refundee`s will typically be incentivize to bring programs to an official conclusion. This slightly cumbersome design is a consequence of the difficulty of consistently allocating rewards proportional to Uniswap V3 liquidity. A final note: stakers who remain in the program after `endTime` may actually see their rewards marginally augmented or (more likely) gradually diluted. The magnitude of these changes depend on stakers' share of the total active liquidity, the time spend staked after `endTime`, and the sequence of unstaking. In the worst case, rewards decay proportionally to the duration. For example, at 2x the duration, ½ of rewards could remain, at 3x, ⅓ could remain, etc. While somewhat complex, this behavior can largely be ignored from a game-theoretic standpoint. Stakers should simply attempt to unstake and claim rewards as soon as possible after `endTime`, an outcome that is likely in any case, as `refundee`s will be eager to reclaim leftover rewards, and mass unstake stragglers. diff --git a/docs/contracts/v3/guides/local-environment.mdx b/docs/contracts/v3/guides/local-environment.mdx index bae7c802c3..3c100d460b 100644 --- a/docs/contracts/v3/guides/local-environment.mdx +++ b/docs/contracts/v3/guides/local-environment.mdx @@ -28,7 +28,7 @@ In the following sections, we’ll walk through the steps to create the same env ## Set Up Dependencies -Node is one of the most common Javascript runtimes. For our purposes it will provide scripting we can use to compile and test our contracts. If you haven’t already, install NodeJS and its package manager NPM ([instructions](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm)). Once those dependencies are set up, we can initialize our project: +Node is one of the most common Javascript runtime. For our purposes it will provide scripting we can use to compile and test our contracts. If you haven’t already, install NodeJS and its package manager NPM ([instructions](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm)). Once those dependencies are set up, we can initialize our project: ```bash $ npm init diff --git a/docs/contracts/v3/guides/providing-liquidity/setting-up-your-contract.md b/docs/contracts/v3/guides/providing-liquidity/setting-up-your-contract.md index 4844c9df38..c0db75d256 100644 --- a/docs/contracts/v3/guides/providing-liquidity/setting-up-your-contract.md +++ b/docs/contracts/v3/guides/providing-liquidity/setting-up-your-contract.md @@ -123,9 +123,9 @@ pragma abicoder v2; import '@uniswap/v3-core/contracts/interfaces/IUniswapV3Pool.sol'; import '@uniswap/v3-core/contracts/libraries/TickMath.sol'; import '@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol'; -import '../libraries/TransferHelper.sol'; -import '../interfaces/INonfungiblePositionManager.sol'; -import '../base/LiquidityManagement.sol'; +import '@uniswap/v3-periphery/contracts/libraries/TransferHelper.sol'; +import '@uniswap/v3-periphery/contracts/interfaces/INonfungiblePositionManager.sol'; +import '@uniswap/v3-periphery/contracts/base/LiquidityManagement.sol'; contract LiquidityExamples is IERC721Receiver { address public constant DAI = 0x6B175474E89094C44Da98b954EedeAC495271d0F; diff --git a/docs/contracts/v3/guides/providing-liquidity/the-full-contract.md b/docs/contracts/v3/guides/providing-liquidity/the-full-contract.md index 1044a0eacb..eecbbb5bf9 100644 --- a/docs/contracts/v3/guides/providing-liquidity/the-full-contract.md +++ b/docs/contracts/v3/guides/providing-liquidity/the-full-contract.md @@ -11,12 +11,10 @@ Below we have the complete functioning code example: a contract that can custody pragma solidity =0.7.6; pragma abicoder v2; -import '@uniswap/v3-core/contracts/interfaces/IUniswapV3Pool.sol'; import '@uniswap/v3-core/contracts/libraries/TickMath.sol'; import '@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol'; -import '../libraries/TransferHelper.sol'; -import '../interfaces/INonfungiblePositionManager.sol'; -import '../base/LiquidityManagement.sol'; +import '@uniswap/v3-periphery/contracts/libraries/TransferHelper.sol'; +import '@uniswap/v3-periphery/contracts/interfaces/INonfungiblePositionManager.sol'; contract LiquidityExamples is IERC721Receiver { address public constant DAI = 0x6B175474E89094C44Da98b954EedeAC495271d0F; @@ -137,7 +135,7 @@ contract LiquidityExamples is IERC721Receiver { function collectAllFees(uint256 tokenId) external returns (uint256 amount0, uint256 amount1) { // Caller must own the ERC721 position, meaning it must be a deposit - // set amount0Max and amount1Max to uint256.max to collect all fees + // set amount0Max and amount1Max to type (uint128).max to collect all fees // alternatively can set recipient to msg.sender and avoid another transaction in `sendToOwner` INonfungiblePositionManager.CollectParams memory params = INonfungiblePositionManager.CollectParams({ @@ -149,7 +147,7 @@ contract LiquidityExamples is IERC721Receiver { (amount0, amount1) = nonfungiblePositionManager.collect(params); - // send collected feed back to owner + // send collected fees back to owner _sendToOwner(tokenId, amount0, amount1); } @@ -177,7 +175,7 @@ contract LiquidityExamples is IERC721Receiver { (amount0, amount1) = nonfungiblePositionManager.decreaseLiquidity(params); - //send liquidity back to owner + // send liquidity back to owner _sendToOwner(tokenId, amount0, amount1); } @@ -241,10 +239,10 @@ contract LiquidityExamples is IERC721Receiver { function retrieveNFT(uint256 tokenId) external { // must be the owner of the NFT require(msg.sender == deposits[tokenId].owner, 'Not the owner'); - // transfer ownership to original owner - nonfungiblePositionManager.safeTransferFrom(address(this), msg.sender, tokenId); //remove information related to tokenId delete deposits[tokenId]; + // transfer ownership to original owner + nonfungiblePositionManager.safeTransferFrom(address(this), msg.sender, tokenId); } } ``` diff --git a/docs/contracts/v3/guides/swaps/multihop-swaps.md b/docs/contracts/v3/guides/swaps/multihop-swaps.md index 35e4dad76d..cc9d1f66ba 100644 --- a/docs/contracts/v3/guides/swaps/multihop-swaps.md +++ b/docs/contracts/v3/guides/swaps/multihop-swaps.md @@ -228,7 +228,7 @@ contract SwapExamples { // The parameter path is encoded as (tokenOut, fee, tokenIn/tokenOut, fee, tokenIn) // The tokenIn/tokenOut field is the shared token between the two pools used in the multiple pool swap. In this case USDC is the "shared" token. // For an exactOutput swap, the first swap that occurs is the swap which returns the eventual desired token. - // In this case, our desired output token is WETH9 so that swap happpens first, and is encoded in the path accordingly. + // In this case, our desired output token is WETH9 so that swap happens first, and is encoded in the path accordingly. ISwapRouter.ExactOutputParams memory params = ISwapRouter.ExactOutputParams({ path: abi.encodePacked(WETH9, poolFee, USDC, poolFee, DAI), diff --git a/docs/contracts/v3/guides/swaps/single-swaps.md b/docs/contracts/v3/guides/swaps/single-swaps.md index 4503c0ca87..0f9e3e015e 100644 --- a/docs/contracts/v3/guides/swaps/single-swaps.md +++ b/docs/contracts/v3/guides/swaps/single-swaps.md @@ -249,8 +249,8 @@ contract SwapExamples { // Transfer the specified amount of DAI to this contract. TransferHelper.safeTransferFrom(DAI, msg.sender, address(this), amountInMaximum); - // Approve the router to spend the specifed `amountInMaximum` of DAI. - // In production, you should choose the maximum amount to spend based on oracles or other data sources to acheive a better swap. + // Approve the router to spend the specified `amountInMaximum` of DAI. + // In production, you should choose the maximum amount to spend based on oracles or other data sources to achieve a better swap. TransferHelper.safeApprove(DAI, address(swapRouter), amountInMaximum); ISwapRouter.ExactOutputSingleParams memory params = diff --git a/docs/contracts/v3/reference/governance/overview.md b/docs/contracts/v3/reference/governance/overview.md index 8a9e566562..3a4c0469e8 100644 --- a/docs/contracts/v3/reference/governance/overview.md +++ b/docs/contracts/v3/reference/governance/overview.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/examples/smart-contracts/LiquidityExamples.sol b/examples/smart-contracts/LiquidityExamples.sol index a722e33961..e78e310bf4 100644 --- a/examples/smart-contracts/LiquidityExamples.sol +++ b/examples/smart-contracts/LiquidityExamples.sol @@ -4,8 +4,8 @@ pragma abicoder v2; import '@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol'; import '@uniswap/v3-core/contracts/libraries/TickMath.sol'; -import '../libraries/TransferHelper.sol'; -import '../interfaces/INonfungiblePositionManager.sol'; +import '@uniswap/v3-periphery/contracts/libraries/TransferHelper.sol'; +import '@uniswap/v3-periphery/contracts/interfaces/INonfungiblePositionManager.sol'; contract LiquidityExamples is IERC721Receiver { address public constant nonfungiblePositionManager = 0xC36442b4a4522E871399CD717aBDD847Ab11FE88; diff --git a/examples/smart-contracts/SwapExamples.sol b/examples/smart-contracts/SwapExamples.sol index c8e7cdd9fc..2f0af91b33 100644 --- a/examples/smart-contracts/SwapExamples.sol +++ b/examples/smart-contracts/SwapExamples.sol @@ -2,8 +2,8 @@ pragma solidity =0.7.6; pragma abicoder v2; -import '../libraries/TransferHelper.sol'; -import '../interfaces/ISwapRouter.sol'; +import '@uniswap/v3-periphery/contracts/libraries/TransferHelper.sol'; +import '@uniswap/v3-periphery/contracts/interfaces/ISwapRouter.sol'; contract SwapExamples { // For the scope of these swap examples,