Merge remote-tracking branch 'smblee/bryan-12-04-upgrade_to_docusauru…

…s_v3' into bryan-01-14-redesign

* smblee/bryan-12-04-upgrade_to_docusaurus_v3: (22 commits)
  update v4 docs to be compliant with v3 styling, update margin
  docs: add Soneium and Ink v4 deployments (Uniswap#876)
  docs: update home index links for v4 (Uniswap#874)
  docs: update protocol intro with v4 references (Uniswap#872)
  docs: clean up unused imports and update v4 whitepaper link (Uniswap#868)
  docs: update READ.ME with v4 references (Uniswap#871)
  docs: update homepage guides for v4 (Uniswap#870)
  docs: add v4 updates to Uniswap Protocol Overview and Hooks to Protocol Concepts (Uniswap#869)
  docs: first draft for the v4 sdk tech reference, overview tbd (Uniswap#858)
  docs: update avalanche explorer (Uniswap#866)
  Update gas-optimization.md (Uniswap#860)
  docs: add all mainnet deployments for v4 (Uniswap#864)
  Update 05-range-orders.md (Uniswap#861)
  Update Celo-Deployments.md (Uniswap#862)
  v4 docs: UI enhancements, broken links, lowercase letters fixes and content updates (Uniswap#854)
  Fix Guide on Minting Position (Uniswap#859)
  Update 01-overview.md (Uniswap#852)
  docs: v4 hooks guides optimizations (Uniswap#844)
  StateView & Flash Accounting guides added (Uniswap#848)
  Update `decrease-liquidity.md` to fix a bug in the demo code (Uniswap#856)
  ...

README.md

@@ -2,13 +2,12 @@
 
 This web application contains all documentation for Uniswap products. It is built using [Docusaurus 2](https://v2.docusaurus.io/), a modern static website generator.
 
-
 # Project Layout
 
 ### Uniswap documentation is broken down into four sections:
-- Concepts - General Uniswap information or concepts useful for using Uniswap products, such as *Liquidity* and *Fees*
-- Contracts - Uniswap smart contracts such as the V3 Contracts or *Permit2*
-- SDKs - Uniswap integrations such as the *v3-sdk* and the *Swap Widget*
+- Concepts - General Uniswap information or concepts useful for using Uniswap products, such as *Hooks* and *Fees*
+- Contracts - Uniswap smart contracts including *v4*, *v3*, *UniswapX*, *Universal Router*, *Permit2*, *v2*, and *v1*
+- SDKs - Uniswap integrations such as the *v4-sdk*, *v3-sdk* and the *Swap Widget*
 - APIs - The Uniswap APIs such the *Subgraph API*
 
 ### Each item in a section should include the following:
@@ -27,7 +26,7 @@ A product overview should address points such as:
 - Where does the source code of the product live?
 - Where does the code artifact live (eg *npm*) and how does someone integrate with it?
 
-A good example is the [V3 Smart Contracts](./docs/contracts/v3/overview.md).
+A good example is the [v4 Smart Contracts](./docs/contracts/v4/overview).
 
 ### Guides
 > Guides should follow the **Principles of a Good Guide**:
@@ -48,10 +47,10 @@ A good example is the [V3 Smart Contracts](./docs/contracts/v3/overview.md).
 By implementing these consistent principles Uniswap will have docs that are easy to understand and produce reusable code for its community.
 
 
-A good example is the [V3 SDK Guides](./docs/sdk/v3/guides/01-quick-start.md).
+A good example is the [v3 SDK Guides](./docs/sdk/v3/guides/01-background.md).
 
 ### Technical References
-This should contain the technical reference for the exported interfaces. A good example is the [V3 SDK](./docs/sdk/v3/reference/overview).
+This should contain the technical reference for the exported interfaces. A good example is the [v4 SDK](./docs/sdk/v4/overview).
 These files can be created using the [guides below](#how-to-create-a-technical-reference).
 
 # Contributing to Uniswap Docs
@@ -124,7 +123,7 @@ If you don't have those, one for the Engineering Managers should be able to help
 - Edit config.json file if needed:
     - Start url from updated website
     - Sitemap url from updated website: eg for docs: https://docs.uniswap.org/sitemap.xml
-    - Use "v3-docs" as the index name
+    - Use "v4-docs" as the index name
 - [Install](https://www.docker.com/products/docker-desktop/) and start running Docker Desktop
 - Install jq `brew install jq`
 - Run `docker run -it --env-file=.env -e "CONFIG=$(cat ./config.json | jq -r tostring)" algolia/docsearch-scraper`

blog/gas-optimization.md

@@ -84,7 +84,7 @@ This test allows us to see [every change](https://github.com/Uniswap/v3-core/pu
 
 Now that the basics of the concepts are covered, how do you decide where to spend your time optimizing?
 
-First, it’s important to understand what changes are relevant and what changes are not. A gas difference of 50 gas on a call that costs 100k gas is typically below the bar of relevance. However, several 50 gas optimizations, called multiple times per transaction, can add up to a 1% savings for a user action. The important thing here is the context: if you are saving 50 gas in a function that typically costs 1000 gas, you are saving 5% in that function. You should separate your code into function boundaries and measure at those boundaries. We do this with the many libraries in the Uniswap V3 codebase.
+First, it’s important to understand what changes are relevant and what changes are not. A gas difference of 50 on a call that costs 100k gas is typically below the bar of relevance. However, several 50 gas optimizations, called multiple times per transaction, can add up to a 1% savings for a user action. The important thing here is the context: if you are saving 50 gas in a function that typically costs 1000 gas, you are saving 5% in that function. You should separate your code into function boundaries and measure at those boundaries. We do this with the many libraries in the Uniswap V3 codebase.
 
 Context is also relevant for where to spend your time in a codebase. For example, we know the majority of users will interact with Uniswap via calls to swap. So we should focus our energy primarily on the swap function.
 

docs/api/subgraph/guides/subgraph-example.md

@@ -6,7 +6,7 @@ sidebar_position: 3
 
 # Subgraph Query Examples
 
-This doc will teach you how to query Uniswap V3 analytics by writing GraphQL queries on the subgraph. You can fetch data points like :
+This doc will teach you how to query Uniswap v3 analytics by writing GraphQL queries on the subgraph. You can fetch data points like :
 
 - [collected fees for a position](#general-position-data)
 - [current liquidity](#pool-data) of a pool
@@ -16,7 +16,7 @@ and much more. Below are some example queries. To run a query copy and paste it
 
 ## Global Data
 
-Global data refers to data points about the Uniswap v3 protocol as a whole. Some examples of global data points are total value locked in the protocol, total pools deployed, or total transaction counts. Thus, to query global data you must pass in the Uniswap V3 Factory address `0x1F98431c8aD98523631AE4a59f267346ea31F984` and select the desired fields. Reference the full [factory schema](https://github.com/Uniswap/v3-subgraph/blob/main/schema.graphql#L1) to see all possible fields.
+Global data refers to data points about the Uniswap v3 protocol as a whole. Some examples of global data points are total value locked in the protocol, total pools deployed, or total transaction counts. Thus, to query global data you must pass in the Uniswap v3 Factory address `0x1F98431c8aD98523631AE4a59f267346ea31F984` and select the desired fields. Reference the full [factory schema](https://github.com/Uniswap/v3-subgraph/blob/main/schema.graphql#L1) to see all possible fields.
 
 ### Current Global Data
 
@@ -226,7 +226,7 @@ swaps(orderBy: timestamp, orderDirection: desc, where:
 
 ## Token Data
 
-Input the the token contract address to fetch token data. Any token that exists in at least one Uniswap V3 pool can be queried. The output will aggregate data across all v3 pools that include the token.
+Input the the token contract address to fetch token data. Any token that exists in at least one Uniswap v3 pool can be queried. The output will aggregate data across all v3 pools that include the token.
 
 ### General Token Data
 

docs/api/subgraph/overview.md

@@ -15,7 +15,7 @@ Each version of Uniswap has its own dedicated subgraph, and governance contracts
 
 Each subgraph has a dedicated endpoint for querying data, as well as a page on [The Graph explorer](https://thegraph.com/explorer) that exposes the schema and available fields to query.
 
-##### V3 (Mainnet)
+##### v3 (Mainnet)
 
 - [Subgraph](https://thegraph.com/explorer/subgraphs/5zvR82QoaXYFyDEKLZ9t6v9adgnptxYpKpSbxtgVENFV?view=Query&chain=arbitrum-one)
 - Graphql Endpoint: `https://gateway.thegraph.com/api/<YOUR_API_KEY_HERE>/subgraphs/id/5zvR82QoaXYFyDEKLZ9t6v9adgnptxYpKpSbxtgVENFV`

docs/concepts/governance/07-changelog.md → docs/archived/07-changelog.md

@@ -1,6 +1,7 @@
 ---
 id: changelog
 title: Changelog
+hidden: true
 ---
 
 | Date            | Abstract                                                 | Transaction                                                                                             | Sybil Reference                         |

docs/concepts/glossary.md

@@ -50,15 +50,15 @@ Digital assets that are stored in a Uniswap pool contract, and are able to be tr
 
 ## Mid Price
 
-The price between the available buy and sell prices. In Uniswap V1 and V2, this is the ratio of the two ERC20 token reserves. In V3, this is the ratio of the two ERC20 token reserves available within the current active tick.
+The price between the available buy and sell prices. In Uniswap v1 and v2, this is the ratio of the two ERC20 token reserves. In V3, this is the ratio of the two ERC20 token reserves available within the current active tick.
 
 ## Observation
 
 An instance of historical price and liquidity data of a given pair.
 
 ## Pair
 
-A smart contract deployed from a Uniswap V1 or V2 factory contract that enables trading between two ERC20 tokens. Pair contracts are now called Pools in V3.
+A smart contract deployed from a Uniswap v1 or v2 factory contract that enables trading between two ERC20 tokens. Pair contracts are now called Pools in v3.
 
 ## Periphery
 

docs/concepts/governance/01-overview.md

@@ -7,10 +7,14 @@ title: Overview
 
 [`governance`](https://github.com/Uniswap/governance)
 
+<!-- 
+
 ## Documentation
 
 For reference material on the Uniswap Governance system please see [Governance Reference](../../../contracts/v3/reference/governance/overview.md).
 
+ -->
+
 ## UNI Address
 
 `UNI` is deployed at `0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984` on the Ethereum [mainnet](https://etherscan.io/address/0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984), and the [Ropsten](https://ropsten.etherscan.io/address/0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984), [Rinkeby](https://rinkeby.etherscan.io/address/0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984), [Görli](https://goerli.etherscan.io/address/0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984), and [Kovan](https://kovan.etherscan.io/address/0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984) testnets. It was built from commit [ab22c08](https://github.com/Uniswap/governance/commit/ab22c084bacb2636a1aebf9759890063eb6e4946).

docs/concepts/governance/02-process.md

@@ -13,7 +13,7 @@ Uniswap Governance takes place in several venues. Each serves its own particular
 
 A Discourse-hosted forum for governance-related discussion. Community members must register for an account before sharing or liking posts. New members must read 4 topics and a combined 15 posts over the course of at least 10 minutes before they may  post themselves.
 
-2. [_Snapshot_](https://snapshot.org/#/uniswapgovernance.eth)
+2. [_Snapshot_](https://snapshot.box/#/s:uniswapgovernance.eth)
 
 A simple voting interface that allows users to signal sentiment off-chain. Votes on Snapshot are weighted by the number of UNI delegated to the address used to vote.
 
@@ -42,7 +42,7 @@ _Timeframe_: 5 days
 
 _Quorum_: 10M UNI
 
-_Form_: [Snapshot Poll](https://snapshot.org/#/uniswapgovernance.eth)
+_Form_: [Snapshot Poll](https://snapshot.box/#/s:uniswapgovernance.eth)
 
 The purpose of the Temperature Check is to signal community sentiment on a proposal prior to moving towards an onchain vote.
 
@@ -52,7 +52,7 @@ To create a Temperature Check:
 
 2. Create and post this version of the proposal in the [Governance Forum](https://gov.uniswap.org/) with the title “Temperature Check — [Your Title Here]”. Include a link to the RFC post. You will update the post to include a link to the Snapshot poll after you’ve posted that.
 
-3. Create a [Snapshot poll](https://snapshot.org/#/uniswap). The voting options should consist of those which have gained support in the RFC Phase. This poll can be either binary or multiple choice but must include a `No change` option. Set the poll duration to 5 days. Include a link to the Forum Temperature Check post.
+3. Create a [Snapshot poll](https://snapshot.box/#/s:uniswapgovernance.eth). The voting options should consist of those which have gained support in the RFC Phase. This poll can be either binary or multiple choice but must include a `No change` option. Set the poll duration to 5 days. Include a link to the Forum Temperature Check post.
 
 4. Update the Forum post with a link to the Snapshot Poll.
 
@@ -90,26 +90,8 @@ Timeframe: 7 days
 
 _Quorum_: 40M UNI
 
-Form: [Snapshot Poll](https://snapshot.org/#/uniswap)
+Form: [Snapshot Poll](https://snapshot.box/#/s:uniswapgovernance.eth)
 
 In the future, the community governance process above may need to undergo additional changes to continue to meet the needs of the Uniswap community. While an onchain vote is not required to change the majority of this process, a clear display of community support and acceptance is important for process changes to have legitimacy.
 
 Thus, changes to all off-chain community governance processes should be voted on through an off-chain Snapshot vote. There should be a 7-day voting period and 40M UNI quorum.
-
-## Governance Glossary
-
-- **UNI:** An ERC-20 token that designates the weight of a user's voting rights. The more UNI a user has in their wallet, the more weight their delegation or vote on a proposal holds.
-
-- **Delegation:** UNI holders cannot vote or create proposals until they delegate their voting rights to an address. A UNI holder can delegate to one address at a time, including their own address. Note that delegation does not lock tokens; it simply adds votes to the chosen delegation address.
-
-- **Proposal:** A proposal is executable code that modifies the governance contract or treasury and how they work. To create a proposal, a user must have at least 0.10% (1M UNI) of all UNI delegated to their address. Proposals are stored in the "proposals" mapping of the Governor smart contract. All proposals are subject to a ~7-day voting period. If the proposer does not maintain their vote weight balance throughout the voting period, anyone may cancel the proposal.
-
-- **Threshold:** The amount of UNI that must be delegated to an address to take a given action. Currently, the only action with a threshold is posting an onchain vote.
-
-- **Quorum:** In order for a vote to pass,  4% of all UNI (40M) must vote in favor. Votes against and abstentions do not count towards a quorum. The purpose of the quorum is to ensure that the only measures that pass have adequate voter participation.
-
-- **Voting:** Users can vote for or against single proposals once they have voting rights delegated to their address. Votes can be cast while a proposal is in the "Active" state. Votes can be submitted immediately using "castVote" or submitted later with "castVoteBySig" (For more info on castVoteBySig and offline signatures, see EIP-712). If the majority of votes (and a 4% quorum of UNI) vote for a proposal, the proposal may be queued in the Timelock.
-
-- **Voting Period:** Once a proposal has been created, Uniswap community members will have a seven day period (the Voting Period) to cast their votes.
-
-- **Timelock:** All governance proposals must sit in the Timelock for a minimum of 2 days, after which they can be executed.

docs/concepts/protocol/concentrated-liquidity.md

@@ -1,7 +1,7 @@
 ---
 id: concentrated-liquidity
 title: Concentrated Liquidity
-sidebar_position: 1
+sidebar_position: 6
 ---
 
   <div>

docs/concepts/protocol/fees.md

@@ -1,7 +1,7 @@
 ---
 id: fees
 title: Fees
-sidebar_position: 2
+sidebar_position: 3
 ---
 
 ## Swap Fees

docs/concepts/protocol/hooks.md

@@ -0,0 +1,34 @@
+---
+id: hooks
+title: Hooks
+sidebar_position: 1
+---
+
+## Introduction
+
+Uniswap v4 inherits all of the capital efficiency gains of Uniswap v3 while introducing major architectural improvements. 
+
+The key innovations are the Hook System and Singleton Architecture, which together enable unprecedented protocol customization and gas optimization.
+
+## Hooks
+
+Hooks allow developers to customize and extend the behavior of liquidity pools. They are external smart contracts that can be attached to individual pools to intercept and modify the execution flow at specific points during pool-related actions.
+
+The logic is executed before and/or after major operations such as pool creation, liquidity addition and removal, swapping, and donations.
+
+Through these hook functions, developers can build sophisticated features like custom AMMs with different pricing curves, yield farming protocols, advanced trading features including limit orders, dynamic fee strategies, and custom oracle implementations. Each pool can have one hook (though a hook can serve multiple pools), hooks are optional and specified during pool creation, and developers can implement any combination of hook functions based on their needs.
+
+## Singleton Architecture
+
+The hook system in v4 is built on top of a revolutionary architectural change known as the singleton design. Unlike previous versions where each pool was a separate smart contract, v4 manages all pools through a single contract called the [PoolManager](/contracts/v4/concepts/PoolManager). This architectural innovation brings several key improvements:
+
+- **Efficient Pool Creation**: Pools are created as state updates rather than contract deployments, significantly reducing gas costs
+- **Gas Optimization**: Multi-hop swaps and complex operations are streamlined through a single contract
+- **Flash Accounting**: Token balances are tracked internally and settled at the end of transactions, minimizing transfers
+- **Native ETH Support**: Direct ETH trading without the need to wrap to WETH, improving user experience
+
+These core features are just the beginning of what's possible with Uniswap v4. 
+
+To explore all features including flash accounting, native ETH support, dynamic fees, and custom accounting, check out the [v4 whitepaper](https://uniswap.org/whitepaper-v4.pdf). 
+
+For technical implementations and detailed guides, visit the [v4 technical documentation](/contracts/v4/concepts/overview).

docs/concepts/protocol/integration-issues.md

@@ -1,7 +1,7 @@
 ---
 id: integration-issues
 title: Token Integration Issues
-sidebar_position: 6
+sidebar_position: 7
 ---
 
 Fee-on-transfer and rebasing tokens will not function correctly on v3.

docs/concepts/protocol/oracle.md

@@ -1,7 +1,7 @@
 ---
 id: oracle
 title: Oracle
-sidebar_position: 3
+sidebar_position: 4
 ---
 
 :::note

docs/concepts/protocol/range-orders.md

@@ -1,14 +1,14 @@
 ---
 id: range-orders
 title: Range Orders
-sidebar_position: 4
+sidebar_position: 5
 ---
 
 Customizable liquidity positions, along with single-sided asset provisioning, allow for a new style of swapping with automated market makers: the range order.
 
 In typical order book markets, anyone can easily set a limit order: to buy or sell an asset at a specific predetermined price, allowing the order to be filled at an indeterminate time in the future.
 
-With Uniswap V3, one can approximate a limit order by providing a single asset as liquidity within a specific range. Like traditional limit orders, range orders may be set with the expectation they will execute at some point in the future, with the target asset available for withdrawal after the spot price has crossed the full range of the order.
+With Uniswap v3, one can approximate a limit order by providing a single asset as liquidity within a specific range. Like traditional limit orders, range orders may be set with the expectation they will execute at some point in the future, with the target asset available for withdrawal after the spot price has crossed the full range of the order.
 
 Unlike some markets where limit orders may incur fees, the range order maker generates fees while the order is filled. This is due to the range order technically being a form of liquidity provisioning rather than a typical swap.
 
@@ -32,7 +32,7 @@ The nature of AMM design makes some styles of limit orders possible, while other
 
 > The Current price of a DAI / ETH pool is 1,500 DAI / ETH. You expect that ETH will rebound after it drops to 1,000 at the next market downturn, so you would like to place a range order swapping DAI to ETH at the price of 1,000 DAI / ETH. This is possible, as the price space below the spot price is denominated in the lower-priced asset, DAI. You can provide DAI at the price of 1,000 DAI / ETH, which will be swapped for ETH when the spot price of ETH drops past 1,000 DAI / ETH.
 
-As the above examples show, in Uniswap V3, the two paired assets in a given pool are separated above and below the spot price, with the higher price asset available above the spot price and the lower-priced asset below.
+As the above examples show, in Uniswap v3, the two paired assets in a given pool are separated above and below the spot price, with the higher price asset available above the spot price and the lower-priced asset below.
 
 The following examples show limit order styles that are unable to be replicated due to the separation of assets in price space.
 

docs/concepts/protocol/swaps.md

@@ -1,7 +1,7 @@
 ---
 id: swaps
 title: Swaps
-sidebar_position: 5
+sidebar_position: 2
 ---
 
 ## Introduction