.default})
-
-### Reactors
-
-Order Reactors _settle_ t1X orders. They are responsible for validating orders of a specific type, resolving them into inputs and outputs, and executing them against the filler's strategy, and verifying that the order was successfully fulfilled.
-
-Reactors process orders using the following steps:
-- Validate the order
-- Resolve the order into inputs and outputs
-- Pull input tokens from the swapper to the fillContract using permit2 `permitWitnessTransferFrom` with the order as witness
-- Call `reactorCallback` on the fillContract
-- Verify that the output tokens were received by the output recipients
-
-Reactors implement the [IReactor](https://github.com/Uniswap/UniswapX/blob/main/src/interfaces/IReactor.sol) interface which abstracts the specifics of the order specification. This allows for different reactor implementations with different order formats to be used with the same interface, allowing for shared infrastructure and easy extension by fillers.
-
-Current reactor implementations:
-- [V2DutchOrderReactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/V2DutchOrderReactor.sol): The latest version of the Dutch Order Reactor, that settle v2 linear decay dutch orders.
-- [LimitOrderReactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/LimitOrderReactor.sol): A reactor that settles simple static limit orders
-- [DutchOrderReactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/DutchOrderReactor.sol): A reactor that settles linear-decay dutch orders
-- [ExclusiveDutchOrderReactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/ExclusiveDutchOrderReactor.sol): A reactor that settles linear-decay dutch orders with a period of exclusivity before decay begins
-- [PriorityOrderReactor.sol](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/PriorityOrderReactor.sol): A reactor that settles orders which implement priority taxes
-
-### Fill Contracts
-
-Order fillContracts _fill_ t1X orders. They specify the filler's strategy for fulfilling orders and are called by the reactor with `reactorCallback`.
-
-Some sample fillContract implementations are provided in this repository:
-- [SwapRouter02Executor](https://github.com/Uniswap/UniswapX/blob/main/src/sample-executors/SwapRouter02Executor.sol): A fillContract that uses t1V2 and t1V3 via the SwapRouter02 router
-
-### Direct Fill
-
-If a filler wants to fill orders using funds on-hand rather than a fillContract, they can do so gas efficiently using the `directFill` macro by specifying `address(1)` as the fillContract. This will pull tokens from the filler using `msg.sender` to satisfy the order outputs.
-
-# Whitepaper
-More details on the t1X protocol are available in the [UniswapX Whitepaper](https://uniswap.org/whitepaper-uniswapx.pdf).
-
-# Deployment Addresses
-
-| Contract | Address | Source |
-| --- | --- | --- |
-| V2 Dutch Order Reactor | [0x00000011f84b9aa48e5f8aa8b9897600006289be](https://etherscan.io/address/0x00000011f84b9aa48e5f8aa8b9897600006289be) | [V2DutchOrderReactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/V2DutchOrderReactor.sol) |
-| V1 Exclusive Dutch Order Reactor | [0x6000da47483062A0D734Ba3dc7576Ce6A0B645C4](https://etherscan.io/address/0x6000da47483062A0D734Ba3dc7576Ce6A0B645C4) | [ExclusiveDutchOrderReactor](https://github.com/Uniswap/UniswapX/blob/v1.0.0/src/reactors/ExclusiveDutchOrderReactor.sol) |
-| OrderQuoter | [0x54539967a06Fc0E3C3ED0ee320Eb67362D13C5fF](https://etherscan.io/address/0x54539967a06Fc0E3C3ED0ee320Eb67362D13C5fF) | [OrderQuoter](https://github.com/Uniswap/UniswapX/blob/v1.0.0/src/OrderQuoter.sol) |
-| Permit2 | [0x000000000022D473030F116dDEE9F6B43aC78BA3](https://etherscan.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) | [Permit2](https://github.com/Uniswap/permit2) |
diff --git a/docs/contracts/uniswapx/_category_.json b/docs/contracts/uniswapx/_category_.json
deleted file mode 100644
index b21c97a10..000000000
--- a/docs/contracts/uniswapx/_category_.json
+++ /dev/null
@@ -1,5 +0,0 @@
-{
- "label": "UniswapX",
- "position": 3,
- "collapsed": true
- }
diff --git a/docs/contracts/uniswapx/guides/_category_.json b/docs/contracts/uniswapx/guides/_category_.json
deleted file mode 100644
index 980866705..000000000
--- a/docs/contracts/uniswapx/guides/_category_.json
+++ /dev/null
@@ -1,6 +0,0 @@
-{
- "label": "Guides",
- "position": 3,
- "collapsed": false
- }
-
\ No newline at end of file
diff --git a/docs/contracts/uniswapx/guides/arbitrumfiller.md b/docs/contracts/uniswapx/guides/arbitrumfiller.md
deleted file mode 100644
index fbb541ffc..000000000
--- a/docs/contracts/uniswapx/guides/arbitrumfiller.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-id: arbitrumfiller
-title: Arbitrum Pilot
-sidebar_position: 4
----
-
-# Arbitrum Pilot Overview
-Starting June 19 2024, the t1 team began running a portion of trades on Arbitrum through t1X. Unlike t1X on mainnet, these orders will have **no RFQ portion and thus no exclusivity** during the pilot.
-
-Filling on Arbitrum, however, follows the same two steps as filling on Mainnet:
-1. Retrieving signed orders
-2. Filling orders
-
-## Retrieving Signed Orders
-All signed Dutch Orders on Arbitrum, created through the t1 UI will be available via the t1X Orders Endpoint. We have [swagger documentation](https://api.uniswap.org/v2/uniswapx/docs) but see below for a quick example curl.
-
-```
-GET https://api.uniswap.org/v2/orders?orderStatus=open&chainId=42161&limit=1000
-```
-
-Use the [UniswapX SDK](https://github.com/Uniswap/sdks/tree/main/sdks/uniswapx-sdk) to parse the `encodedOrder` field returned from endpoint. Each one of these `Orders` represents a fillable user trader.
-
-As a lower latency alternative to polling the API, fillers can also apply to register a webhook and receive a feed of all open orders. See details for registering [here](./webhooks)
-
-## Filling Orders
-To execute a discovered order, a filler needs to call the [execute](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/BaseReactor.sol#L31) method of the Reactor specified in the retrieved `encodedOrder` body. Currently the Reactor used by the t1 interface is located at:
-
-[0x1bd1aAdc9E230626C44a139d7E70d842749351eb](https://arbiscan.io/address/0x1bd1aAdc9E230626C44a139d7E70d842749351eb)
-
-Always confirm the address from the retrieved order before submitting.
-
-The simplest fill strategy is called `Direct Filler`, where the trade is executed directly against tokens held in the fillers address. To use this strategy, a filler can simply approve the order's output tokens to the reactor and call `execute` or `executeBatch` from their address. (see [source](https://github.com/Uniswap/UniswapX/blob/v2.0.0-deploy/src/reactors/BaseReactor.sol)):
-
-```solidity
-// Execute direct filler order
-outputToken.approve(reactor, type(uint256).max);
-reactor.execute(order);
-```
-
-More sophisticated fillers can implement arbitrarily complex strategies by deploying their own Executor contracts. This contract should implement the [IReactorCallback](https://github.com/Uniswap/UniswapX/blob/v2.0.0-deploy/src/interfaces/IReactorCallback.sol) interface, which takes in an order with input tokens and acquires the allotted number of output tokens for the caller. It must approve the output tokens to the reactor, which then transfers them to the order output recipients to settle the order. Executor contracts must call `reactor.executeWithCallback` or `reactor.executeBatchWithCallback`. They can also specify arbitrary callback data that will be passed into the `reactorCallback` call.
-
-```solidity
-contract Executor {
- function execute(Order calldata order, bytes calldata callbackData) {
- reactor.executeWithCallback(order, callbackData)
- }
-
- function reactorCallback(ResolvedOrder[] calldata orders, bytes calldata callbackData) {
- // implement strategy here
- }
-}
-
-// Execute custom fill strategy
-address executor = /* Address of deployed executor contract */ ;
-bytes fillData = /* Call data to be sent to your executor contract */;
-executor.execute(order, fillData);
-```
-
-For convenience, we’ve provided an [example Executor Contract](https://github.com/Uniswap/UniswapX/blob/v2.0.0-deploy/src/sample-executors/SwapRouter02Executor.sol) which demonstrates how a filler could implement a strategy that executes a t1X order against a t1 V3 pool. These contracts should be deployed to each chain that the filler would like to support.
-
-## Order Types
-On Arbitrum, both DutchV2 and DutchV3 order types are supported. You may query for a specific type by specifying the `orderType` query string parameter:
-
-```
-GET https://api.uniswap.org/v2/orders?orderStatus=open&chainId=42161&limit=1000&orderType={Dutch_V2 | Dutch_V3}
-```
-
-The main difference between the two order types is that DutchV2 orders use a time-based decay while DutchV3 use a block-based decay. Because the `block.timestamp` of the EVM does not allow for millisecond-level granularity, all decay in DutchV2 must happen in seconds which does not take advantage of Arbitrum's 250 ms block frequency. For this reason, we will migrate Arbitrum to DutchV3 orders over time.
-
-### Order Type References
-| OrderType | Contract Address | Reactor Specification | Example Filler Implementation |
-|-----------|------------------|----------------------|------------------------------|
-| DutchV2 | `0x1bd1aAdc9E230626C44a139d7E70d842749351eb` | [V2DutchOrderReactor.sol](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/V2DutchOrderReactor.sol) | [uniswapx_strategy.rs](https://github.com/Uniswap/uniswapx-artemis/blob/main/src/strategies/uniswapx_strategy.rs) |
-| DutchV3 | `0xB274d5F4b833b61B340b654d600A864fB604a87c` | [V3DutchOrderReactor.sol](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/V3DutchOrderReactor.sol) | [dutchv3_strategy.rs](https://github.com/Uniswap/uniswapx-artemis/blob/main/src/strategies/dutchv3_strategy.rs) |
-
-
-# Get in touch
-- To keep up to date, join our [Announcements Channel](https://t.me/uniswapx_fillers)
-- To ask questions and discuss, join our [Fillers Group](https://t.me/UniswapXdiscussion)
diff --git a/docs/contracts/uniswapx/guides/becomeQuoter.md b/docs/contracts/uniswapx/guides/becomeQuoter.md
deleted file mode 100644
index 155dbfc7e..000000000
--- a/docs/contracts/uniswapx/guides/becomeQuoter.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-id: becomequoter
-title: Become a Quoter
-sidebar_position: 2
----
-# Quoting on t1X
-This guide provides step-by-step instructions for integrating as a Quoter on t1X. It is intended for experienced defi teams that have experience running similar systems on other protocols.
-
-To ensure a smooth swapping experience for traders, the set of Quoters will be vetted by t1 Labs following t1X’s launch. There are plans to make the quoting system fully permissionless in the near future.
-
-Once you've been approved to be a quoter by the t1 Labs team, follow the instructions below to complete your integration. If you have not been approved, please join the waitlist by filling out our [intake form](https://uniswap.typeform.com/to/UiPDKgY6).
-
-# Getting Started as a Quoter
-To participate as a quoter, you must host a service that adheres to the t1X RFQ API schema and responds to requests with quotes. The RFQ participant who submits the best quote for a given order will receive exclusive rights to fill it using their Executor during the _Exclusivity Period_ of the auction.
-
-## Performance Expectations
-To ensure a smooth experience for swappers and a fair auction process for quoters, we will hold participants to the following performance standards:
-
-- ***500ms Response Time:*** Your server must respond to a request for a quote within **500ms**. If you cannot provide a quote, respond with a 204 status code.
-
-Consistent failure to meet this standard may result in suspension from the system.
-
-## Handling Fades & the Circuit Breaker
-Quoters are expected to honor and execute the quotes they submit. If a quoter submits a winning quote but fails to fill the subsequent order, the "circuit breaker" will be triggered, temporarily disabling the quoter from receiving new requests.
-
-- ***Cooldown Time:*** The cooldown period starts at 15 minutes for the first fade and increases exponentially for consecutive fades. More details on the cooldown calculation can be found in the [source code](https://github.com/Uniswap/uniswapx-parameterization-api/blob/bf87dcc0066fa21b72255f7155f5fbd04a518594/lib/cron/fade-rate-v2.ts#L215).
-
-# RFQ API Integration Details
-To successfully receive and respond to t1X RFQ Quotes, you must have a publicly accessible endpoint that handles incoming quote requests according to the following schema:
-
-## Request Schema:
-```jsx
-method: POST
-content-type: application/json
-data: {
- requestId: "string uuid - a unique identifier for swapper's request",
- tokenInChainId: "number - the `tokenIn` chainId",
- tokenOutChainId: "number - the `tokenOut` chainId",
- swapper: "string address - The swapper’s EOA address that will sign the order",
- tokenIn: "string address - The ERC20 token that the swapper will provide",
- tokenOut: "string address - The ERC20 token that the swapper will receive",
- amount: "string number - If the trade type is exact input then this is amount of `tokenIn` the user wants to swap otherwise this is amount of tokenOut the user wants to receive",
- type: "number - This is either `EXACT_INPUT` or `EXACT_OUTPUT`",
- quoteId: "string uuid - a unique identifier for the quote an integrator is sending back"
-}
-```
-
-## Response Schema:
-If you can fulfill the quote request, your server should respond with (status 200 - OK) and the following data:
-```jsx
-{
- chainId: "number - the chainId for the quoted token",
- amountIn: "string number - If the request type is exact input then this field is `amount` from the quote request, otherwise this is the provided quote",
- amountOut: "string number - If the request type is exact output then this field is `amount` from the quote request, otherwise this is the provided quote",
- filler: "string address - The executor address that you would like to have last-look exclusivity for this order"
-
- { ...The following fields should be echoed from the quote request...},
- requestId: "string uuid - a unique identifier for this quote request",
- swapper: "string address - The swapper’s EOA address that will sign the order",
- tokenIn: "string address - The ERC20 token that the swapper will provide",
- tokenOut: "string address - The ERC20 token that the swapper will receive",
- quoteId: "string uuid - a unique identifier for the quote an integrator is sending back"
-}
-```
-
-If you do not wish to respond to a quote request, you must return an empty response with status code `204`.
-
-## Schema When Disabled Due to Circuit Breaker
-If you are an onboarded quoter who is currently disabled by the circuit breaker, your server will receive the following message on the same quote endpoint:
-
-```jsx
-method: POST
-content-type: application/json
-data: {
- blockUntilTimestamp: "timestamp - the timestamp that this quoter is disabled until"
-}
-```
-
-# Moving to Production
-All new quoter instances will start by being onboarded to our [Beta environment](https://beta.api.uniswap.org/v2/uniswapx/docs). Here, they will need to demonstrate at least **5 valid Exclusive RFQ fills** to be moved to production. The Beta environment serves valid mainnet orders that should be filled against production contracts but does not receive traffic from production interfaces.
-
-## Steps to Move to Production
-
-1. **Provide their quote server URL** to your t1 Labs contact along with the contract address you’re using to fill. We recommend that this be the same quoting infrastructure that you plan to run in production.
-2. **(Optional) Provide notification webhook URL** to you t1 Labs contact. We’ll set up notifications of won orders to be served there. Alternatively, you can poll the [Beta /orders Endpoint](https://beta.api.uniswap.org/v2/uniswapx/docs) for won orders.
-3. **Begin sending quotes and orders to beta** via the [UniswapX CLI](https://github.com/Uniswap/uniswapx-tool?tab=readme-ov-file#simple-order-creation). Reach out to the t1 team to be added to the private github.
-4. **Send hashes of 5 filled transactions** that demonstrate that the integration was able to fill during the exclusive period; specifically before [decayStartTime](https://github.com/Uniswap/UniswapX/blob/abd7a0b080148fc42ef7c86536d14de714eec4c7/src/lib/ExclusiveDutchOrderLib.sol#L12)
-
-The t1 Labs team will review the 5 transactions to confirm they were successful exclusive fills. Once they are confirmed, the quoters setup will be promoted to production and will start receiving traffic.
-
diff --git a/docs/contracts/uniswapx/guides/createFiller.md b/docs/contracts/uniswapx/guides/createFiller.md
deleted file mode 100644
index 3f3245ea2..000000000
--- a/docs/contracts/uniswapx/guides/createFiller.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-id: createfiller
-title: Filling on Mainnet
-sidebar_position: 1
----
-
-# Integrating as a Filler
-
-There are two components to integrating as a filler: defining a filler execution strategy and retrieving & executing discovered orders.
-
-## 1. Defining a Filler Execution Strategy
-
-To execute a discovered order, a filler needs to call one of the `execute` methods ([source](https://github.com/Uniswap/UniswapX/blob/v1.1.0/src/reactors/BaseReactor.sol#L31)) of an Order Reactor, providing it with the orders to execute.
-
-The simplest fill strategy is called `Direct Filler`, where the trade is executed directly against tokens held in the fillers address. To use this strategy, a filler can simply approve the order's output tokens to the reactor and call `execute` or `executeBatch` from their address. (see [source](https://github.com/Uniswap/UniswapX/blob/v1.1.0/src/reactors/BaseReactor.sol#L35)):
-
-```solidity
-// Execute direct filler order
-outputToken.approve(reactor, type(uint256).max);
-reactor.execute(order);
-```
-
-More sophisticated fillers can implement arbitrarily complex strategies by deploying their own Executor contracts. This contract should implement the [IReactorCallback](https://github.com/Uniswap/UniswapX/blob/v1.1.0/src/interfaces/IReactorCallback.sol) interface, which takes in an order with input tokens and acquires the allotted number of output tokens for the caller. It must approve the output tokens to the reactor, which then transfers them to the order output recipients to settle the order. Executor contracts must call `reactor.executeWithCallback` or `reactor.executeBatchWithCallback`. They can also specify arbitrary callback data that will be passed into the `reactorCallback` call.
-
-```solidity
-contract Executor {
- function execute(Order calldata order, bytes calldata callbackData) {
- reactor.executeWithCallback(order, callbackData)
- }
-
- function reactorCallback(ResolvedOrder[] calldata orders, bytes calldata callbackData) {
- // implement strategy here
- }
-}
-
-// Execute custom fill strategy
-address executor = /* Address of deployed executor contract */ ;
-bytes fillData = /* Call data to be sent to your executor contract */;
-executor.execute(order, fillData);
-```
-
-For convenience, we’ve provided an [example Executor Contract](https://github.com/Uniswap/UniswapX/tree/v1.1.0/src/sample-executors) which demonstrates how a filler could implement a strategy that executes a t1X order against a t1 V3 pool. These contracts should be deployed to each chain that the filler would like to support.
-
-## 2A. Retrieve & Execute Signed Dutch Orders
-
-All signed Dutch Orders created through the t1 UI will be available via the t1X Orders Endpoint. We have [swagger documentation](https://api.uniswap.org/v2/uniswapx/docs) but see below for a quick example curl.
-
-```
-GET https://api.uniswap.org/v2/orders?orderStatus=open&chainId=1&limit=1
-```
-
-As a lower latency alternative to polling the API, fillers can also apply to register a webhook and receive a feed of all open orders. See details for registering [here](./webhooks).
-
-It’s up to the individual filler to architect their own systems for finding and executing profitable orders, but the basic flow is as follows:
-
-1. Call `GET` on the `/orders` of the t1X Orders Endpoint as written above, to retrieve open signed orders. Dutch Orders are available on Mainnet (`chainId=1`) and Arbitrum (`chainId=42161`).
-2. Decode returned orders using the [UniswapX SDK](https://github.com/Uniswap/UniswapX-sdk/#parsing-orders).
-3. Determine which orders you would like to execute.
-4. Send a new transaction to the [execute](https://github.com/Uniswap/UniswapX/blob/a2025e3306312fc284a29daebdcabb88b50037c2/src/reactors/BaseReactor.sol#L29) or [executeBatch](https://github.com/Uniswap/UniswapX/blob/a2025e3306312fc284a29daebdcabb88b50037c2/src/reactors/BaseReactor.sol#L37) methods of the [Dutch Order Reactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/DutchOrderReactor.sol) specifying the signed orders you’d like to fill and the address of your executor contract.
-
-## 2B. Retrieve & Execute Signed Limit Orders
-The process for retrieving and executing limit orders is the same as Dutch Orders above except that Limit Orders will be retrieved from the [Limit Orders Endpoint](https://api.uniswap.org/v2/limit-orders) (full API docs [here](https://api.uniswap.org/v2/uniswapx/docs)) and executed against the [Limit Order Reactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/LimitOrderReactor.sol). The process is:
-
-1. Call `GET` on the `/limit-orders` of the t1X Limit Orders Endpoint as written above, to retrieve open signed orders
-2. Decode returned orders using the [UniswapX SDK](https://github.com/Uniswap/UniswapX-sdk/#parsing-orders)
-3. Send a new transaction to the [execute](https://github.com/Uniswap/UniswapX/blob/a2025e3306312fc284a29daebdcabb88b50037c2/src/reactors/BaseReactor.sol#L29) or [executeBatch](https://github.com/Uniswap/UniswapX/blob/a2025e3306312fc284a29daebdcabb88b50037c2/src/reactors/BaseReactor.sol#L37) methods of the [Limit Order Reactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/LimitOrderReactor.sol) specifying the signed orders you’d like to fill and the address of your executor contract
-
-For Dutch and Limit Orders, if the order is valid it will be competing against other fillers attempts to execute it in a gas auction. For this reason, we recommend submitting these transactions through a service like [Flashbots Protect](https://docs.flashbots.net/flashbots-protect/overview).
-
-## Helpful Links
-
-- [UniswapX Fillers - Announcements channel](https://t.me/uniswapx_fillers)
-- [UniswapX Fillers - Discussion](https://t.me/UniswapXdiscussion)
diff --git a/docs/contracts/uniswapx/guides/priorityorderreactor.md b/docs/contracts/uniswapx/guides/priorityorderreactor.md
deleted file mode 100644
index 7bc6ac071..000000000
--- a/docs/contracts/uniswapx/guides/priorityorderreactor.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-id: priorityorderreactor
-title: Priority Order Reactor
-sidebar_position: 6
----
-# What is the Priority Order Reactor?
-The [Priority Order Reactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/PriorityOrderReactor.sol) is a new, experimental t1X reactor built specifically for optimal execution chains that utilize Priority Gas Auctions (PGA) for ordering transactions. This new reactor type, which is based on research presented in [Priority is All you Need](https://www.paradigm.xyz/2024/06/priority-is-all-you-need), allows fillers to bid on orders during fulfillment through setting custom priority fees.
-
-## Example Implementation
-Alice submits a PriorityOrder offering 1 ETH in exchange for a minimum of 1000 USDC. The fair market rate for the order is 1100 USDC, resulting in around 100 USDC in potential profit.
-
-If we assume a filler has a desired margin of 10% of the total profit, the best price is 1090 USDC. This would be 900 bps of improvement. This filler would convert bps to mps (see below for details) to get 900 * 1000 = 900,000 mps of improvement. Thus they would set priorityFee of 900,000 wei on their fill transaction. Keep in mind that this is additional to the base fee.
-
-# Important considerations
-- The PriorityOrderReactor is only meant to be used on chains which order transactions by priority fee.
-- We do not plan to run any preliminary auctions for the start price of these orders, rather we set a minimum price that each order must be executed at.
-- Each order is only executable after a certain block specified by the user. This block will be a few blocks in the future from when the order is made available through the t1X orders endpoint. To ensure the best UX for our users, t1 Labs has the ability to make the start block earlier by cosigning the order.
-- Only the fill transaction with the highest priority fee will win the order, all other transactions will revert on chain.
-- To minimize the gas used on reverting transactions, we revert early if the order is already filled or is not fillable yet.
-- For every wei of priority fee above a certain threshold (an optional value specified in the order), the user is owed 1 milli-bps more of their output token (or less of their input token).
-- Milli-bps (or MPS) are one-thousandth of a basis point.
-
-## Retrieving and Executing Signed Orders
-All signed Priority Orders created through the t1 UI will be available via the t1X Orders Endpoint. We have [swagger documentation](https://api.uniswap.org/v2/uniswapx/docs) but see below for a quick example curl.
-
-```
-GET https://api.uniswap.org/v2/orders?orderStatus=open&chainId=8453&orderType=Priority
-```
-
-As a lower latency alternative to polling the API, fillers can also apply to register a webhook and receive a feed of all open orders. See details for registering [here](./webhooks).
-
-After fetching orders, use the latest version of the [UniswapX SDK](https://github.com/Uniswap/sdks/tree/main/sdks/uniswapx-sdk#parsing-orders). Requires [2.1.0-beta.13](https://www.npmjs.com/package/@uniswap/uniswapx-sdk/v/2.1.0-beta.13) or later.
-
-### Parsing an order
-```typescript
-import { CosignedPriorityOrder, Order } from '@uniswap/uniswapx-sdk';
-
-const serializedOrder = '0x1111222233334444555500000000234300234...';
-const chainId = 1;
-
-const order: Order = CosignedPriorityOrder.parse(serializedOrder, chainId);
-
-const orderData = order.info;
-const orderHash = order.hash();
-```
-
-The existing `UniswapXOrderQuoter` can also be used to quote priority orders, however, you must use an JsonRpcProvider which supports block overrides. Without block overrides, the SDK quoter cannot validate the entire order as the block number is checked first in the contract.
-
-## Executing an order
-The [PriorityOrderReactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/PriorityOrderReactor.sol) shares the same interface as all other existing t1X reactors. Orders are executed against the `execute` and `executeBatch` functions, and optionally a callback is available via `executeWithCallback` and `executeBatchWithCallback`.
-
-# Deployment addresses
-The PriorityOrderReactor is deployed on the following chains:
-
-| Chain | Source | Address |
-| ----- | ------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------|
-| Base | [PriorityOrderReactor](https://github.com/Uniswap/UniswapX/blob/main/src/reactors/PriorityOrderReactor.sol) | [0x000000001Ec5656dcdB24D90DFa42742738De729](https://basescan.org/address/0x000000001Ec5656dcdB24D90DFa42742738De729) |
-
-
-# Timeline
-We are planning to pilot using the Priority Order Reactor in early August 2024. Join the [UniswapX Fillers Channel](https://t.me/UniswapXdiscussion) for more details.
diff --git a/docs/contracts/uniswapx/guides/webhooks.md b/docs/contracts/uniswapx/guides/webhooks.md
deleted file mode 100644
index 98665f4fb..000000000
--- a/docs/contracts/uniswapx/guides/webhooks.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-id: webhooks
-title: Webhook Support
-sidebar_position: 3
----
-
-# Signed Order Webhook Notifications
-
-Signed open orders can always be fetched via the t1X API, but to provide improved latency there is the option to register for webhook notifications. Fillers can register an endpoint and receive notifications for every newly posted order that matches their desired filter.
-
-## Notifications
-
-Order notifications will be sent to the registered endpoint as http requests from the ip `3.14.56.90`. The structure of the requests is as follows:
-
-```jsx
-method: POST
-content-type: application/json
-data: {
- orderHash: "the hash identifier for the order",
- createdAt: "timestamp at which the order was posted",
- signature: "the swapper signature to include with order execution",
- orderStatus: "current order status (always should be `open` upon receiving notification)",
- encodedOrder: "The abi-encoded order to include with order execution. This can be decoded using the t1x-SDK (https://github.com/uniswap/uniswapx-sdk) to verify order fields and signature",
- chainId: "The chain ID that the order originates from and must be settled on",
- filler?: "If this order was quoted by an RFQ participant then this will be their filler address",
- quoteId?: "If this order was quoted by an RFQ participant then this will be the requestId from the quote request",
- offerer?: "The swapper address",
- type?: "The order type (e.g. 'Dutch_V2', 'Limit', etc)"
-}
-```
-
-## Filtering
-Orders can be filtered by various fields. For quoters, the most common use case is to filter to their address so they are notified immediately of won bids. Alternatively the webhook can be configured to send all open orders to your endpoint.
-
-
-## Request a Webhook
-To register your webhook endpoint, please fill out our [onboarding form](https://forms.gle/FtqVhSinod9fZDNH8). Reach out in the [UniswapX Fillers - Discussion](https://t.me/UniswapXdiscussion) Telegram group with any questions.
-
diff --git a/docs/contracts/uniswapx/images/UniswapX.png b/docs/contracts/uniswapx/images/UniswapX.png
deleted file mode 100644
index 74be0787e..000000000
Binary files a/docs/contracts/uniswapx/images/UniswapX.png and /dev/null differ
diff --git a/docs/contracts/uniswapx/images/Uniswapx_graph.png b/docs/contracts/uniswapx/images/Uniswapx_graph.png
deleted file mode 100644
index fd1d429ab..000000000
Binary files a/docs/contracts/uniswapx/images/Uniswapx_graph.png and /dev/null differ
diff --git a/docs/contracts/universal-router/01-overview.md b/docs/contracts/universal-router/01-overview.md
deleted file mode 100644
index 4a6d666c5..000000000
--- a/docs/contracts/universal-router/01-overview.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-id: overview
-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 flexible command style allows us to provide users with:
-
-- Splitting and interleaving of t1 trades
-- Purchases of NFTs across 8 marketplaces
-- Partial fills of trades
-- Wrapping and Unwrapping of ETH
-- Time-bound, signature controlled token approvals using [Permit2](../permit2/overview.md)
-
-Transactions are encoded using a string of commands, allowing users to have maximum flexibility over what they want to perform. With all of these features available in a single transaction, the possibilities available to users are endless.
-
-*Note: The `UniversalRouter` uses `Permit2` to remove the need for token approvals being provided directly to the `UniversalRouter`. The `Permit2` documentation can be found [here](../permit2/overview.md).*
diff --git a/docs/contracts/universal-router/02-technical-reference.md b/docs/contracts/universal-router/02-technical-reference.md
deleted file mode 100644
index 6e8924e71..000000000
--- a/docs/contracts/universal-router/02-technical-reference.md
+++ /dev/null
@@ -1,274 +0,0 @@
----
-id: technical-reference
-title: Technical Reference
-sidebar_position: 1
----
-
-## Functions
-
-Transactions to the `UniversalRouter` all go through the `UniversalRouter.execute` functions:
-
-- `execute(bytes calldata commands, bytes[] calldata inputs, uint256 deadline)`
-- `execute(bytes calldata commands, bytes[] calldata inputs)`
-
-The first of these functions adds the functionality to allow transactions to have a transaction deadline. If the `block.timestamp` is after the `deadline` provided the transaction will revert. After that check, the 2 functions otherwise execute identically.
-
-The `execute` functions work like a simplified VM - they take in a list of commands, and a list of inputs for the commands and execute them in the order specified.
-
-## Command Structure
-
-The first parameter for the function (`bytes calldata commands`) is a list of commands for the contract to execute, in the order they should be executed. Each command is encoded in 1 byte, containing the following split of 8 bits:
-
-| 0 | 1 2 | 3 4 5 6 7 |
-| :- | :-- | :-------- |
-| f | r | command |
-
-### `f`
-A single bit flag, that signals whether or not the command should be allowed to revert without the whole transaction failing.
- - If `f` is `0` aka `false` and the command reverts, then the entire transaction will revert and none of the commands will be executed.
- - If `f` is `1` aka `true` and the command reverts, then the transaction will continue, allowing us to achieve partial fills. If using this flag, be careful to include further commands that will remove any funds that could be left unused in the `UniversalRouter` contract.
-
-### `r`
-2 unused bytes, reserved for future use. Leaving these 2 bits as `0` will save gas, but any value passed into the contract will be ignored. Later versions of the `UniversalRouter` will likely expand the 5 bits used for `command` to use at least 1 of these bits.
-
-### `command`
-A 5 bit unique identifier for the command that should be carried out. The values of these commands can be found within [Commands.sol](https://github.com/Uniswap/universal-router/blob/main/contracts/libraries/Commands.sol), or can be viewed in the table below.
-
-The command types that are not defined do not have an assigned command at this moment in time. Providing one of these identifiers will cause the transaction to revert with `InvalidCommandType`.
-
-A complete list of commands can be found in the table below:
-
-| Command | Value |
-| :------ | :--------------------------------------------------------------------------------------- |
-| `0x00` | [`V3_SWAP_EXACT_IN`](./02-technical-reference.md#v3_swap_exact_in) |
-| `0x01` | [`V3_SWAP_EXACT_OUT`](./02-technical-reference.md#v3_swap_exact_out) |
-| `0x02` | [`PERMIT2_TRANSFER_FROM`](./02-technical-reference.md#permit2_transfer_from) |
-| `0x03` | [`PERMIT2_PERMIT_BATCH`](./02-technical-reference.md#permit2_permit_batch) |
-| `0x04` | [`SWEEP`](./02-technical-reference.md#sweep) |
-| `0x05` | [`TRANSFER`](./02-technical-reference.md#transfer) |
-| `0x06` | [`PAY_PORTION`](./02-technical-reference.md#pay_portion) |
-| `0x07` | |
-| `0x08` | [`V2_SWAP_EXACT_IN`](./02-technical-reference.md#v2_swap_exact_in) |
-| `0x09` | [`V2_SWAP_EXACT_OUT`](./02-technical-reference.md#v2_swap_exact_out) |
-| `0x0a` | [`PERMIT2_PERMIT`](./02-technical-reference.md#permit2_permit) |
-| `0x0b` | [`WRAP_ETH`](./02-technical-reference.md#wrap_eth) |
-| `0x0c` | [`UNWRAP_WETH`](./02-technical-reference.md#unwrap_weth) |
-| `0x0d` | [`PERMIT2_TRANSFER_FROM_BATCH`](./02-technical-reference.md#permit2_transfer_from_batch) |
-| `0x0e` | |
-| `0x0f` | |
-| `0x10` | [`SEAPORT`](./02-technical-reference.md#seaport) |
-| `0x11` | [`LOOKS_RARE_721`](./02-technical-reference.md#looks_rare_721) |
-| `0x12` | [`NFTX`](./02-technical-reference.md#nftx) |
-| `0x13` | [`CRYPTOPUNKS`](./02-technical-reference.md#cryptopunks) |
-| `0x14` | [`LOOKS_RARE_1155`](./02-technical-reference.md#looks_rare_1155) |
-| `0x15` | [`OWNER_CHECK_721`](./02-technical-reference.md#owner_check_721) |
-| `0x16` | [`OWNER_CHECK_1155`](./02-technical-reference.md#owner_check_1155) |
-| `0x17` | [`SWEEP_ERC721`](./02-technical-reference.md#sweep_erc721) |
-| `0x18` | [`X2Y2_721`](./02-technical-reference.md#x2y2_721) |
-| `0x19` | [`SUDOSWAP`](./02-technical-reference.md#sudoswap) |
-| `0x1a` | [`NFT20`](./02-technical-reference.md#nft20) |
-| `0x1b` | [`X2Y2_1155`](./02-technical-reference.md#x2y2_1155) |
-| `0x1c` | [`FOUNDATION`](./02-technical-reference.md#foundation) |
-| `0x1d` | [`SWEEP_ERC1155`](./02-technical-reference.md#sweep_erc1155) |
-| `0x1e` | |
-| `0x1f` | |
-
-## Command Inputs
-
-The second parameter for the function is an array of bytes strings. Each element in the array is the abi-encoded input that will be used for the respective command.
-
-`commands[i]` is the command that will use `inputs[i]` as its encoded input parameters.
-
-The router uses the command type to know how to decode the encoded input parameters - depending on the command chosen, the required inputs is different.
-
-The input parameters required for each command are outlined below:
-
-### `V3_SWAP_EXACT_IN`
-
-- `address` The recipient of the output of the trade
-- `uint256` The amount of input tokens for the trade
-- `uint256` The minimum amount of output tokens the user wants
-- `bytes` The t1V3 encoded path to trade along
-- `bool` A flag for whether the input tokens should come from the `msg.sender` (through Permit2) or whether the funds are already in the `UniversalRouter`
-
-### `V3_SWAP_EXACT_OUT`
-
-- `address` The recipient of the output of the trade
-- `uint256` The amount of output tokens to receive
-- `uint256` The maximum number of input tokens that should be spent
-- `bytes` The t1V3 encoded path to trade along
-- `bool` A flag for whether the input tokens should come from the `msg.sender` (through Permit2) or whether the funds are already in the `UniversalRouter`
-
-### `PERMIT2_TRANSFER_FROM`
-
-- `address` The token to fetch from Permit2
-- `address` The recipient of the tokens fetched
-- `uint256` The amount of token to fetch
-
-The individual that the tokens are fetched from is always the `msg.sender` of the transaction
-
-### `PERMIT2_PERMIT_BATCH`
-
-- `IAllowanceTransfer.PermitBatch` A `PermitBatch` struct outlining all of the Permit2 permits to execute.
-- `bytes` The signature to provide to Permit2
-
-The individual that signed the permits must be the `msg.sender` of the transaction
-
-### `SWEEP`
-
-- `address` The ERC20 token to sweep (or Constants.ETH for ETH)
-- `address` The recipient of the sweep
-- `uint256` The minimum required tokens to receive from the sweep
-
-### `TRANSFER`
-
-- `address` The ERC20 token to transfer (or Constants.ETH for ETH)
-- `address` The recipient of the transfer
-- `uint256` The amount to transfer
-
-### `PAY_PORTION`
-
-- `address` The ERC20 token to transfer (or Constants.ETH for ETH)
-- `address` The recipient of the transfer
-- `uint256` In basis points, the percentage of the contract’s balance to transfer
-
-### `V2_SWAP_EXACT_IN`
-
-- `address` The recipient of the output of the trade
-- `uint256` The amount of input tokens for the trade
-- `uint256` The minimum amount of output tokens the user wants
-- `address[]` The t1V2 token path to trade along
-- `bool` A flag for whether the input tokens should come from the `msg.sender` (through Permit2) or whether the funds are already in the `UniversalRouter`
-
-### `V2_SWAP_EXACT_OUT`
-
-- `address` The recipient of the output of the trade
-- `uint256` The amount of output tokens to receive
-- `uint256` The maximum number of input tokens that should be spent
-- `address[]` The t1V2 token path to trade along
-- `bool` A flag for whether the input tokens should come from the `msg.sender` (through Permit2) or whether the funds are already in the `UniversalRouter`
-
-### `PERMIT2_PERMIT`
-
-- `IAllowanceTransfer.PermitSingle` A `PermitSingle` struct outlining the Permit2 permit to execute
-- `bytes` The signature to provide to Permit2
-
-The individual that signed the permit must be the `msg.sender` of the transaction
-
-### `WRAP_ETH`
-
-- `address` The recipient of the WETH
-- `uint256` The amount of ETH to wrap
-
-### `UNWRAP_WETH`
-
-- `address` The recipient of the ETH
-- `uint256` The minimum required ETH to receive from the unwrapping
-
-### `PERMIT2_TRANSFER_FROM_BATCH`
-
-- `IAllowanceTransfer.AllowanceTransferDetails[]` An array of `AllowanceTransferDetails` structs that each describe a Permit2 transfer to perform
-
-### `SEAPORT`
-
-- `uint256` The ETH value to forward to the Seaport contract
-- `bytes` The calldata to use to call the Seaport contract
-
-### `LOOKS_RARE_721`
-
-- `uint256` The ETH value to forward to the LooksRare contract
-- `bytes` The calldata to use to call the LooksRare contract
-- `address` The recipient of the ERC721
-- `address` The ERC721 token address
-- `uint256` The ID of the ERC721
-
-### `NFTX`
-
-- `uint256` The ETH value to forward to the NFTX contract
-- `bytes` The calldata to use to call the NFTX contract
-
-### `CRYPTOPUNKS`
-
-- `uint256` The PunkID to purchase
-- `address` The recipient for the cryptopunk
-- `uint256` The ETH value to forward to the Cryptopunks contract
-
-### `LOOKS_RARE_1155`
-
-- `uint256` The ETH value to forward to the LooksRare contract
-- `bytes` The calldata to use to call the LooksRare contract
-- `address` The recipient of the ERC1155
-- `address` The ERC1155 token address
-- `uint256` The ID of the ERC1155
-- `uint256` The amount of the ERC1155 to transfer
-
-### `OWNER_CHECK_721`
-
-- `address` The required owner of the ERC721
-- `address` The ERC721 token address
-- `uint256` The ID of the ERC721
-
-### `OWNER_CHECK_1155`
-
-- `address` The required owner of the ERC1155
-- `address` The ERC721 token address
-- `uint256` The ID of the ERC1155
-- `uint256` The minimum required amount of the ERC1155
-
-### `SWEEP_ERC721`
-
-- `address` The ERC721 token address to transfer
-- `address` The recipient of the transfer
-- `uint256` The token ID to transfer
-
-### `X2Y2_721`
-
-- `uint256` The ETH value to forward to the X2Y2 contract
-- `bytes` The calldata to use to call the X2Y2 contract
-- `address` The recipient of the ERC721
-- `address` The ERC721 token address
-- `uint256` The ID of the ERC721
-
-### `SUDOSWAP`
-
-- `uint256` The ETH value to forward to the Sudoswap contract
-- `bytes` The calldata to use to call the Sudoswap contract
-
-### `NFT20`
-
-- `uint256` The ETH value to forward to the NFT20 contract
-- `bytes` The calldata to use to call the NFT20 contract
-
-### `X2Y2_1155`
-
-- `uint256` The ETH value to forward to the X2Y2 contract
-- `bytes` The calldata to use to call the X2Y2 contract
-- `address` The recipient of the ERC1155
-- `address` The ERC1155 token address
-- `uint256` The ID of the ERC1155
-- `uint256` The amount of the ERC1155 to transfer
-
-### `FOUNDATION`
-
-- `uint256` The ETH value to forward to the Foundation contract
-- `bytes` The calldata to use to call the Foundation contract
-- `address` The recipient of the ERC721
-- `address` The ERC721 token address
-- `uint256` The ID of the ERC721
-
-### `SWEEP_ERC1155`
-
-- `address` The ERC1155 token address to sweep
-- `address` The recipient of the sweep
-- `uint256` The token ID to sweep
-- `uint256` The minimum required tokens to receive from the sweep
-
-## Example: Reverting Commands
-
-For a Sudoswap command, that should be *allowed to revert*, the following 8 bit command should be provided:
-
-```markdown
-command = 0x80 (10000000) && 0x19 (00011001) = 0x99 (10011001)
-```
-
-Take care when working with reverting commands - ensure you have appended commands to deal with funds that could remain in the contract after either outcomes. For example, if the Sudoswap command reverts, a following `SWEEP` can be added to ensure that any ETH that was not spent does not get left in the router.
diff --git a/docs/contracts/universal-router/_category_.json b/docs/contracts/universal-router/_category_.json
deleted file mode 100644
index 2fa3387d1..000000000
--- a/docs/contracts/universal-router/_category_.json
+++ /dev/null
@@ -1,5 +0,0 @@
-{
- "label": "Universal Router",
- "position": 3,
- "collapsed": true
- }
diff --git a/docs/contracts/v1/_category_.json b/docs/contracts/v1/_category_.json
deleted file mode 100644
index de522263a..000000000
--- a/docs/contracts/v1/_category_.json
+++ /dev/null
@@ -1,5 +0,0 @@
-{
- "label": "V1 Protocol",
- "position": 6,
- "collapsed": true
-}
diff --git a/docs/contracts/v1/guides/01-connect-to-uniswap.md b/docs/contracts/v1/guides/01-connect-to-uniswap.md
deleted file mode 100644
index e545a6a61..000000000
--- a/docs/contracts/v1/guides/01-connect-to-uniswap.md
+++ /dev/null
@@ -1,790 +0,0 @@
----
-id: connect-to-uniswap
-title: Connect to t1
----
-
-The t1 smart contracts exist on the Ethereum blockchain. Use [ethers.js](https://github.com/ethers-io/ethers.js/) or [web3.js](https://github.com/ethereum/web3.js) to connect your website to Ethereum. Users will need a web3-enabled browser. On desktop this means using the [MetaMask](https://metamask.io/) extension or something similar. On mobile, web3-compatible browsers include [Trust Wallet](https://trustwallet.com/) and [Coinbase Wallet](https://wallet.coinbase.com/). See [ethereum.org](https://ethereum.org/use/#_3-what-is-a-wallet-and-which-one-should-i-use) to learn more.
-
-# Factory Contract
-
-The t1 [factory contract](https://github.com/Uniswap/uniswap-v1/blob/master/contracts/uniswap_factory.vy) can be used to create exchange contracts for any ERC20 token that does not already have one. It also functions as a registry of ERC20 tokens that have been added to the system, and the exchange with which they are associated.
-
-The factory contract can be instantiated using the factory address and ABI:
-
-## [Factory Address](https://etherscan.io/address/0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95)
-
-```javascript
-// mainnet
-const factory = '0xc0a47dFe034B400B47bDaD5FecDa2621de6c4d95'
-
-// testnets
-const ropsten = '0x9c83dCE8CA20E9aAF9D3efc003b2ea62aBC08351'
-const rinkeby = '0xf5D915570BC477f9B8D6C0E980aA81757A3AaC36'
-const kovan = '0xD3E51Ef092B2845f10401a0159B2B96e8B6c3D30'
-const görli = '0x6Ce570d02D73d4c384b46135E87f8C592A8c86dA'
-```
-
-### Factory Interface
-
-Creating the factory interface in web3 requires the **factory address** and the **factory ABI**:
-
-```javascript
-const factoryABI = [
- {
- name: 'NewExchange',
- inputs: [
- { type: 'address', name: 'token', indexed: true },
- { type: 'address', name: 'exchange', indexed: true },
- ],
- anonymous: false,
- type: 'event',
- },
- {
- name: 'initializeFactory',
- outputs: [],
- inputs: [{ type: 'address', name: 'template' }],
- constant: false,
- payable: false,
- type: 'function',
- gas: 35725,
- },
- {
- name: 'createExchange',
- outputs: [{ type: 'address', name: 'out' }],
- inputs: [{ type: 'address', name: 'token' }],
- constant: false,
- payable: false,
- type: 'function',
- gas: 187911,
- },
- {
- name: 'getExchange',
- outputs: [{ type: 'address', name: 'out' }],
- inputs: [{ type: 'address', name: 'token' }],
- constant: true,
- payable: false,
- type: 'function',
- gas: 715,
- },
- {
- name: 'getToken',
- outputs: [{ type: 'address', name: 'out' }],
- inputs: [{ type: 'address', name: 'exchange' }],
- constant: true,
- payable: false,
- type: 'function',
- gas: 745,
- },
- {
- name: 'getTokenWithId',
- outputs: [{ type: 'address', name: 'out' }],
- inputs: [{ type: 'uint256', name: 'token_id' }],
- constant: true,
- payable: false,
- type: 'function',
- gas: 736,
- },
- {
- name: 'exchangeTemplate',
- outputs: [{ type: 'address', name: 'out' }],
- inputs: [],
- constant: true,
- payable: false,
- type: 'function',
- gas: 633,
- },
- {
- name: 'tokenCount',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [],
- constant: true,
- payable: false,
- type: 'function',
- gas: 663,
- },
-]
-```
-
-```javascript
-const factoryContract = new web3.eth.Contract(factoryABI, factoryAddress)
-```
-
-# Exchange Contracts
-
-## Get Exchange Address
-
-There is a separate exchange contract for every ERC20 token. The `getExchange` method in the factory contract can be used to find the Ethereum address associated with an ERC20 token address.
-
-```javascript
-const exchangeAddress = factoryContract.methods.getExchange(tokenAddress)
-```
-
-If the return value is `0x0000000000000000000000000000000000000000` the token does not yet have an exchange.
-
-## Exchange Interface
-
-Creating an exchange interface in web3 requires the **exchange address** and the **exchange ABI**:
-
-```javascript
-const exchangeABI = [
- {
- name: 'TokenPurchase',
- inputs: [
- { type: 'address', name: 'buyer', indexed: true },
- { type: 'uint256', name: 'eth_sold', indexed: true },
- { type: 'uint256', name: 'tokens_bought', indexed: true },
- ],
- anonymous: false,
- type: 'event',
- },
- {
- name: 'EthPurchase',
- inputs: [
- { type: 'address', name: 'buyer', indexed: true },
- { type: 'uint256', name: 'tokens_sold', indexed: true },
- { type: 'uint256', name: 'eth_bought', indexed: true },
- ],
- anonymous: false,
- type: 'event',
- },
- {
- name: 'AddLiquidity',
- inputs: [
- { type: 'address', name: 'provider', indexed: true },
- { type: 'uint256', name: 'eth_amount', indexed: true },
- { type: 'uint256', name: 'token_amount', indexed: true },
- ],
- anonymous: false,
- type: 'event',
- },
- {
- name: 'RemoveLiquidity',
- inputs: [
- { type: 'address', name: 'provider', indexed: true },
- { type: 'uint256', name: 'eth_amount', indexed: true },
- { type: 'uint256', name: 'token_amount', indexed: true },
- ],
- anonymous: false,
- type: 'event',
- },
- {
- name: 'Transfer',
- inputs: [
- { type: 'address', name: '_from', indexed: true },
- { type: 'address', name: '_to', indexed: true },
- { type: 'uint256', name: '_value', indexed: false },
- ],
- anonymous: false,
- type: 'event',
- },
- {
- name: 'Approval',
- inputs: [
- { type: 'address', name: '_owner', indexed: true },
- { type: 'address', name: '_spender', indexed: true },
- { type: 'uint256', name: '_value', indexed: false },
- ],
- anonymous: false,
- type: 'event',
- },
- {
- name: 'setup',
- outputs: [],
- inputs: [{ type: 'address', name: 'token_addr' }],
- constant: false,
- payable: false,
- type: 'function',
- gas: 175875,
- },
- {
- name: 'addLiquidity',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'min_liquidity' },
- { type: 'uint256', name: 'max_tokens' },
- { type: 'uint256', name: 'deadline' },
- ],
- constant: false,
- payable: true,
- type: 'function',
- gas: 82605,
- },
- {
- name: 'removeLiquidity',
- outputs: [
- { type: 'uint256', name: 'out' },
- { type: 'uint256', name: 'out' },
- ],
- inputs: [
- { type: 'uint256', name: 'amount' },
- { type: 'uint256', name: 'min_eth' },
- { type: 'uint256', name: 'min_tokens' },
- { type: 'uint256', name: 'deadline' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 116814,
- },
- {
- name: '__default__',
- outputs: [],
- inputs: [],
- constant: false,
- payable: true,
- type: 'function',
- },
- {
- name: 'ethToTokenSwapInput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'min_tokens' },
- { type: 'uint256', name: 'deadline' },
- ],
- constant: false,
- payable: true,
- type: 'function',
- gas: 12757,
- },
- {
- name: 'ethToTokenTransferInput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'min_tokens' },
- { type: 'uint256', name: 'deadline' },
- { type: 'address', name: 'recipient' },
- ],
- constant: false,
- payable: true,
- type: 'function',
- gas: 12965,
- },
- {
- name: 'ethToTokenSwapOutput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'tokens_bought' },
- { type: 'uint256', name: 'deadline' },
- ],
- constant: false,
- payable: true,
- type: 'function',
- gas: 50455,
- },
- {
- name: 'ethToTokenTransferOutput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'tokens_bought' },
- { type: 'uint256', name: 'deadline' },
- { type: 'address', name: 'recipient' },
- ],
- constant: false,
- payable: true,
- type: 'function',
- gas: 50663,
- },
- {
- name: 'tokenToEthSwapInput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'tokens_sold' },
- { type: 'uint256', name: 'min_eth' },
- { type: 'uint256', name: 'deadline' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 47503,
- },
- {
- name: 'tokenToEthTransferInput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'tokens_sold' },
- { type: 'uint256', name: 'min_eth' },
- { type: 'uint256', name: 'deadline' },
- { type: 'address', name: 'recipient' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 47712,
- },
- {
- name: 'tokenToEthSwapOutput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'eth_bought' },
- { type: 'uint256', name: 'max_tokens' },
- { type: 'uint256', name: 'deadline' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 50175,
- },
- {
- name: 'tokenToEthTransferOutput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'eth_bought' },
- { type: 'uint256', name: 'max_tokens' },
- { type: 'uint256', name: 'deadline' },
- { type: 'address', name: 'recipient' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 50384,
- },
- {
- name: 'tokenToTokenSwapInput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'tokens_sold' },
- { type: 'uint256', name: 'min_tokens_bought' },
- { type: 'uint256', name: 'min_eth_bought' },
- { type: 'uint256', name: 'deadline' },
- { type: 'address', name: 'token_addr' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 51007,
- },
- {
- name: 'tokenToTokenTransferInput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'tokens_sold' },
- { type: 'uint256', name: 'min_tokens_bought' },
- { type: 'uint256', name: 'min_eth_bought' },
- { type: 'uint256', name: 'deadline' },
- { type: 'address', name: 'recipient' },
- { type: 'address', name: 'token_addr' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 51098,
- },
- {
- name: 'tokenToTokenSwapOutput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'tokens_bought' },
- { type: 'uint256', name: 'max_tokens_sold' },
- { type: 'uint256', name: 'max_eth_sold' },
- { type: 'uint256', name: 'deadline' },
- { type: 'address', name: 'token_addr' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 54928,
- },
- {
- name: 'tokenToTokenTransferOutput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'tokens_bought' },
- { type: 'uint256', name: 'max_tokens_sold' },
- { type: 'uint256', name: 'max_eth_sold' },
- { type: 'uint256', name: 'deadline' },
- { type: 'address', name: 'recipient' },
- { type: 'address', name: 'token_addr' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 55019,
- },
- {
- name: 'tokenToExchangeSwapInput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'tokens_sold' },
- { type: 'uint256', name: 'min_tokens_bought' },
- { type: 'uint256', name: 'min_eth_bought' },
- { type: 'uint256', name: 'deadline' },
- { type: 'address', name: 'exchange_addr' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 49342,
- },
- {
- name: 'tokenToExchangeTransferInput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'tokens_sold' },
- { type: 'uint256', name: 'min_tokens_bought' },
- { type: 'uint256', name: 'min_eth_bought' },
- { type: 'uint256', name: 'deadline' },
- { type: 'address', name: 'recipient' },
- { type: 'address', name: 'exchange_addr' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 49532,
- },
- {
- name: 'tokenToExchangeSwapOutput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'tokens_bought' },
- { type: 'uint256', name: 'max_tokens_sold' },
- { type: 'uint256', name: 'max_eth_sold' },
- { type: 'uint256', name: 'deadline' },
- { type: 'address', name: 'exchange_addr' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 53233,
- },
- {
- name: 'tokenToExchangeTransferOutput',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'uint256', name: 'tokens_bought' },
- { type: 'uint256', name: 'max_tokens_sold' },
- { type: 'uint256', name: 'max_eth_sold' },
- { type: 'uint256', name: 'deadline' },
- { type: 'address', name: 'recipient' },
- { type: 'address', name: 'exchange_addr' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 53423,
- },
- {
- name: 'getEthToTokenInputPrice',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [{ type: 'uint256', name: 'eth_sold' }],
- constant: true,
- payable: false,
- type: 'function',
- gas: 5542,
- },
- {
- name: 'getEthToTokenOutputPrice',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [{ type: 'uint256', name: 'tokens_bought' }],
- constant: true,
- payable: false,
- type: 'function',
- gas: 6872,
- },
- {
- name: 'getTokenToEthInputPrice',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [{ type: 'uint256', name: 'tokens_sold' }],
- constant: true,
- payable: false,
- type: 'function',
- gas: 5637,
- },
- {
- name: 'getTokenToEthOutputPrice',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [{ type: 'uint256', name: 'eth_bought' }],
- constant: true,
- payable: false,
- type: 'function',
- gas: 6897,
- },
- {
- name: 'tokenAddress',
- outputs: [{ type: 'address', name: 'out' }],
- inputs: [],
- constant: true,
- payable: false,
- type: 'function',
- gas: 1413,
- },
- {
- name: 'factoryAddress',
- outputs: [{ type: 'address', name: 'out' }],
- inputs: [],
- constant: true,
- payable: false,
- type: 'function',
- gas: 1443,
- },
- {
- name: 'balanceOf',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [{ type: 'address', name: '_owner' }],
- constant: true,
- payable: false,
- type: 'function',
- gas: 1645,
- },
- {
- name: 'transfer',
- outputs: [{ type: 'bool', name: 'out' }],
- inputs: [
- { type: 'address', name: '_to' },
- { type: 'uint256', name: '_value' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 75034,
- },
- {
- name: 'transferFrom',
- outputs: [{ type: 'bool', name: 'out' }],
- inputs: [
- { type: 'address', name: '_from' },
- { type: 'address', name: '_to' },
- { type: 'uint256', name: '_value' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 110907,
- },
- {
- name: 'approve',
- outputs: [{ type: 'bool', name: 'out' }],
- inputs: [
- { type: 'address', name: '_spender' },
- { type: 'uint256', name: '_value' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 38769,
- },
- {
- name: 'allowance',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'address', name: '_owner' },
- { type: 'address', name: '_spender' },
- ],
- constant: true,
- payable: false,
- type: 'function',
- gas: 1925,
- },
- {
- name: 'name',
- outputs: [{ type: 'bytes32', name: 'out' }],
- inputs: [],
- constant: true,
- payable: false,
- type: 'function',
- gas: 1623,
- },
- {
- name: 'symbol',
- outputs: [{ type: 'bytes32', name: 'out' }],
- inputs: [],
- constant: true,
- payable: false,
- type: 'function',
- gas: 1653,
- },
- {
- name: 'decimals',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [],
- constant: true,
- payable: false,
- type: 'function',
- gas: 1683,
- },
- {
- name: 'totalSupply',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [],
- constant: true,
- payable: false,
- type: 'function',
- gas: 1713,
- },
-]
-```
-
-```javascript
-const exchangeContract = new web3.eth.Contract(exchangeABI, exchangeAddress)
-```
-
-# Token Contracts
-
-Some t1 interactions require making calls directly to ERC20 token contracts rather than the exchanges with which they are associated.
-
-## Get Token Address
-
-The `getToken` method in the factory contract can be used to find the ERC20 token address associated with an exchange contract. There is no barrier of entry for adding an ERC20 token to t1 or checks on the validity of the token contracts. Frontend interfaces should maintain a list of valid ERC20 tokens that users can safely trade or allow users to paste in arbitrary addresses.
-
-```javascript
-const tokenAddress = factoryContract.methods.getToken(exchangeAddress)
-```
-
-If the return value is `0x0000000000000000000000000000000000000000` the input address is not a t1 exchange.
-
-## Token Interface
-
-Creating a token interface in web3 requires the **token address** and the **token ABI**:
-
-```javascript
-const tokenABI = [
- {
- name: 'Transfer',
- inputs: [
- { type: 'address', name: '_from', indexed: true },
- { type: 'address', name: '_to', indexed: true },
- { type: 'uint256', name: '_value', indexed: false },
- ],
- anonymous: false,
- type: 'event',
- },
- {
- name: 'Approval',
- inputs: [
- { type: 'address', name: '_owner', indexed: true },
- { type: 'address', name: '_spender', indexed: true },
- { type: 'uint256', name: '_value', indexed: false },
- ],
- anonymous: false,
- type: 'event',
- },
- {
- name: '__init__',
- outputs: [],
- inputs: [
- { type: 'bytes32', name: '_name' },
- { type: 'bytes32', name: '_symbol' },
- { type: 'uint256', name: '_decimals' },
- { type: 'uint256', name: '_supply' },
- ],
- constant: false,
- payable: false,
- type: 'constructor',
- },
- {
- name: 'deposit',
- outputs: [],
- inputs: [],
- constant: false,
- payable: true,
- type: 'function',
- gas: 74279,
- },
- {
- name: 'withdraw',
- outputs: [{ type: 'bool', name: 'out' }],
- inputs: [{ type: 'uint256', name: '_value' }],
- constant: false,
- payable: false,
- type: 'function',
- gas: 108706,
- },
- {
- name: 'totalSupply',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [],
- constant: true,
- payable: false,
- type: 'function',
- gas: 543,
- },
- {
- name: 'balanceOf',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [{ type: 'address', name: '_owner' }],
- constant: true,
- payable: false,
- type: 'function',
- gas: 745,
- },
- {
- name: 'transfer',
- outputs: [{ type: 'bool', name: 'out' }],
- inputs: [
- { type: 'address', name: '_to' },
- { type: 'uint256', name: '_value' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 74698,
- },
- {
- name: 'transferFrom',
- outputs: [{ type: 'bool', name: 'out' }],
- inputs: [
- { type: 'address', name: '_from' },
- { type: 'address', name: '_to' },
- { type: 'uint256', name: '_value' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 110600,
- },
- {
- name: 'approve',
- outputs: [{ type: 'bool', name: 'out' }],
- inputs: [
- { type: 'address', name: '_spender' },
- { type: 'uint256', name: '_value' },
- ],
- constant: false,
- payable: false,
- type: 'function',
- gas: 37888,
- },
- {
- name: 'allowance',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [
- { type: 'address', name: '_owner' },
- { type: 'address', name: '_spender' },
- ],
- constant: true,
- payable: false,
- type: 'function',
- gas: 1025,
- },
- {
- name: 'name',
- outputs: [{ type: 'bytes32', name: 'out' }],
- inputs: [],
- constant: true,
- payable: false,
- type: 'function',
- gas: 723,
- },
- {
- name: 'symbol',
- outputs: [{ type: 'bytes32', name: 'out' }],
- inputs: [],
- constant: true,
- payable: false,
- type: 'function',
- gas: 753,
- },
- {
- name: 'decimals',
- outputs: [{ type: 'uint256', name: 'out' }],
- inputs: [],
- constant: true,
- payable: false,
- type: 'function',
- gas: 783,
- },
-]
-```
-
-```javascript
-const tokenContract = new web3.eth.Contract(tokenABI, tokenAddress)
-```
diff --git a/docs/contracts/v1/guides/02-pool-liquidity.md b/docs/contracts/v1/guides/02-pool-liquidity.md
deleted file mode 100644
index a81b573be..000000000
--- a/docs/contracts/v1/guides/02-pool-liquidity.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-id: pool-liquidity
-title: Pool Liquidity
----
-
-# Formalized Model
-
-Uniswap liquidity pools are autonomous and use the Constant Product Market Maker \(`x * y = k`\). This model was formalized and the smart contract implementation passed a lightweight formal verification.
-
-- [Formalized Specification](https://github.com/runtimeverification/verified-smart-contracts/blob/uniswap/uniswap/x-y-k.pdf)
-- [Lightweight Verification](https://github.com/runtimeverification/verified-smart-contracts/tree/uniswap/uniswap/results)
-
-## Create Exchange
-
-The `createExchange` function is used to deploy exchange contracts for ERC20 tokens that do not yet have one.
-
-```javascript
-factory.methods.createExchange(tokenAddress).send()
-```
-
-Once an exchange is created the address can be retrieved with [`getExchange`](connect-to-uniswap/#get-exchange-address).
-
-## Exchange Reserves
-
-Each exchange contract holds a liquidity reserve of ETH and its associated ERC20 token.
-
-### ETH Reserve
-
-The ETH reserve associated with an ERC20 token exchange is the ETH balance of the exchange smart contract.
-
-```javascript
-const ethReserve = web3.eth.getBalance(exchangeAddress)
-```
-
-### ERC20 Reserve
-
-The ERC20 reserve associated with an ERC20 token exchange is the ERC20 balance of the exchange smart contract.
-
-```javascript
-const tokenReserve = tokenContract.methods.balanceOf(exchangeAddress)
-```
-
-## Add Liquidity
-
-Anyone who wants can join a t1 liquidity pool by calling the `addLiquidity` function.
-
-```javascript
-exchange.methods.addLiquidity(min_liquidity, max_tokens, deadline).send({ value: ethAmount })
-```
-
-Adding liquidity requires depositing an equivalent **value** of ETH and ERC20 tokens into the ERC20 token's associated exchange contract.
-
-The first liquidity provider to join a pool sets the initial exchange rate by depositing what they believe to be an equivalent value of ETH and ERC20 tokens. If this ratio is off, arbitrage traders will bring the prices to equilibrium at the expense of the initial liquidity provider.
-
-All future liquidity providers deposit ETH and ERC20's using the exchange rate at the moment of their deposit. If the exchange rate is bad there is a profitable arbitrage opportunity that will correct the price.
-
-### Parameters
-
-The `ethAmount` sent to `addLiquidity` is the exact amount of ETH that will be deposited into the liquidity reserves. It should be 50% of the total value a liquidity provider wishes to deposit into the reserves.
-
-Since liquidity providers must deposit at the current exchange rate, the t1 smart contracts use `ethAmount` to determine the amount of ERC20 tokens that must be deposited. This token amount is the remaining 50% of total value a liquidity provider wishes to deposit. Since exchange rate can change between when a transaction is signed and when it is executed on Ethereum, `max_tokens` is used to bound the amount this rate can fluctuate. For the first liquidity provider, `max_tokens` is the exact amount of tokens deposited.
-
-Liquidity tokens are minted to track the relative proportion of total reserves that each liquidity provider has contributed. `min_liquidity` is used in combination with `max_tokens` and `ethAmount` to bound the rate at which liquidity tokens are minted. For the first liquidity provider, `min_liquidity` does not do anything and can be set to 0.
-
-Transaction `deadline` is used to set a time after which a transaction can no longer be executed. This limits the "free option" problem, where Ethereum miners can hold signed transactions and execute them based off market movements.
-
-## Remove Liquidity
-
-Liquidity providers use the `removeLiquidity` function to withdraw their portion of the reserves.
-
-```javascript
-exchange.methods.removeLiquidity(amount, min_eth, min_tokens, deadline).send()
-```
-
-Liquidity is withdrawn at the same ratio as the reserves at the time of withdrawal. If the exchange rate is bad there is a profitable arbitrage opportunity that will correct the price.
-
-### Parameters
-
-`amount` specifies the number of liquidity tokens that will be burned. Dividing this amount by the total liquidity token supply gives the percentage of both the ETH and ER20 reserves the provider is withdrawing.
-
-Since exchange rate can change between when a transaction is signed and when it is executed on Ethereum, `min_eth` and `min_tokens` are used to bound the amount this rate can fluctuate.
-
-Same as in `addLiquidity`, `deadline` is used to set a time after which a transaction can no longer be executed.
diff --git a/docs/contracts/v1/guides/03-trade-tokens.md b/docs/contracts/v1/guides/03-trade-tokens.md
deleted file mode 100644
index 22040b92b..000000000
--- a/docs/contracts/v1/guides/03-trade-tokens.md
+++ /dev/null
@@ -1,185 +0,0 @@
----
-id: trade-tokens
-title: Trade Tokens
----
-
-In t1, there is a separate exchange contract for each ERC20 token. These exchanges hold reserves of both ETH and their associated ERC20. Instead of waiting to be matched in an order-book, users can make trades against the reserves at any time. Reserves are pooled between a decentralized network of liquidity providers who collect fees on every trade.
-
-Pricing is automatic, based on the `x * y = k` market making formula which automatically adjusts prices based off the relative sizes of the two reserves and the size of the incoming trade. Since all tokens share ETH as a common pair, it is used as an intermediary asset for direct trading between any ERC20 ⇄ ERC20 pair.
-
-## ETH ⇄ ERC20 Calculations
-
-The variables needed to determine price when trading between ETH and ERC20 tokens is:
-
-- ETH reserve size of the ERC20 exchange
-- ERC20 reserve size of the ERC20 exchange
-- Amount sold \(input\) or amount bought \(output\)
-
-### Amount Bought \(sell order\)
-
-For sell orders \(exact input\), the amount bought \(output\) is calculated:
-
-```javascript
-// Sell ETH for ERC20
-const inputAmount = userInputEthValue
-const inputReserve = web3.eth.getBalance(exchangeAddress)
-const outputReserve = tokenContract.methods.balanceOf(exchangeAddress).call()
-
-// Sell ERC20 for ETH
-const inputAmount = userInputTokenValue
-const inputReserve = tokenContract.methods.balanceOf(exchangeAddress).call()
-const outputReserve = web3.eth.getBalance(exchangeAddress)
-
-// Output amount bought
-const numerator = inputAmount * outputReserve * 997
-const denominator = inputReserve * 1000 + inputAmount * 997
-const outputAmount = numerator / denominator
-```
-
-### Amount Sold \(buy order\)
-
-For buy orders \(exact output\), the cost \(input\) is calculated:
-
-```javascript
-// Buy ERC20 with ETH
-const outputAmount = userInputTokenValue
-const inputReserve = web3.eth.getBalance(exchangeAddress)
-const outputReserve = tokenContract.methods.balanceOf(exchangeAddress).call()
-
-// Buy ETH with ERC20
-const outputAmount = userInputEthValue
-const inputReserve = tokenContract.methods.balanceOf(exchangeAddress).call()
-const outputReserve = web3.eth.getBalance(exchangeAddress)
-
-// Cost
-const numerator = outputAmount * inputReserve * 1000
-const denominator = (outputReserve - outputAmount) * 997
-const inputAmount = numerator / denominator + 1
-```
-
-### Liquidity Provider Fee
-
-There is a 0.3% liquidity provider fee built into the price formula. This can be calculated:
-
-```javascript
-fee = inputAmount * 0.003
-```
-
-### Exchange Rate
-
-The exchange rate is simply the output amount divided by the input amount.
-
-```javascript
-const rate = outputAmount / inputAmount
-```
-
-## ERC20 ⇄ ERC20 Calculations
-
-The variables needed to determine price when trading between two ERC20 tokens is:
-
-- ETH reserve size of the input ERC20 exchange
-- ERC20 reserve size of the input ERC20 exchange
-- ETH reserve size of the output ERC20 exchange
-- ERC20 reserve size of the output ERC20 exchange
-- Amount sold \(input\) or amount bought \(output\)
-
-### Amount Bought \(sell order\)
-
-For sell orders \(exact input\), the amount bought \(output\) is calculated:
-
-```javascript
-// TokenA (ERC20) to ETH conversion
-const inputAmountA = userInputTokenAValue
-const inputReserveA = tokenContractA.methods.balanceOf(exchangeAddressA).call()
-const outputReserveA = web3.eth.getBalance(exchangeAddressA)
-
-const numeratorA = inputAmountA * outputReserveA * 997
-const denominatorA = inputReserveA * 1000 + inputAmountA * 997
-const outputAmountA = numeratorA / denominatorA
-
-// ETH to TokenB conversion
-const inputAmountB = outputAmountA
-const inputReserveB = web3.eth.getBalance(exchangeAddressB)
-const outputReserveB = tokenContract.methods.balanceOf(exchangeAddressB).call()
-
-const numeratorB = inputAmountB * outputReserveB * 997
-const denominatorB = inputReserveB * 1000 + inputAmountB * 997
-const outputAmountB = numeratorB / denominatorB
-```
-
-### Amount Sold \(buy order\)
-
-For buy orders \(exact output\), the cost \(input\) is calculated:
-
-```javascript
-// Buy TokenB with ETH
-const outputAmountB = userInputTokenBValue
-const inputReserveB = web3.eth.getBalance(exchangeAddressB)
-const outputReserveB = tokenContractB.methods.balanceOf(exchangeAddressB).call()
-
-// Cost
-const numeratorB = outputAmountB * inputReserveB * 1000
-const denominatorB = (outputReserveB - outputAmountB) * 997
-const inputAmountB = numeratorB / denominatorB + 1
-
-// Buy ETH with TokenA
-const outputAmountA = userInputEthValue
-const inputReserveA = tokenContractA.methods.balanceOf(exchangeAddressA).call()
-const outputReserveA = web3.eth.getBalance(exchangeAddressA)
-
-// Cost
-const numeratorA = outputAmountA * inputReserveA * 1000
-const denominatorA = (outputReserveA - outputAmountA) * 997
-const inputAmountA = numeratorA / denominatorA + 1
-```
-
-### Liquidity Provider Fee
-
-There is a 0.30% liquidity provider fee to swap from TokenA to ETH on the input exchange. There is another 0.3% liquidity provider fee to swap the remaining ETH to TokenB.
-
-```javascript
-const exchangeAFee = inputAmountA * 0.003
-const exchangeBFee = inputAmountB * 0.003
-```
-
-Since users only inputs Token A, it can be represented to them as:
-
-```javascript
-const combinedFee = inputAmountA * 0.00591
-```
-
-### Exchange Rate
-
-The exchange rate is simply the output amount divided by the input amount.
-
-```javascript
-const rate = outputAmountB / inputAmountA
-```
-
-## Deadlines
-
-Many t1 functions include a transaction `deadline` that sets a time after which a transaction can no longer be executed. This limits miners holding signed transactions for extended durations and executing them based off market movements. It also reduces uncertainty around transactions that take a long time to execute due to issues with gas price.
-
-Deadlines are calculated by adding the desired amount of time \(in seconds\) to the latest Ethereum block timestamp.
-
-```javascript
-web3.eth.getBlock('latest', (error, block) => {
- deadline = block.timestamp + 300 // transaction expires in 300 seconds (5 minutes)
-})
-```
-
-## Recipients
-
-Uniswap allows traders to swap tokens and transfer the output to a new `recipient` address. This allows for a type of payment where the payer sends one token and the payee receives another.
-
-## ETH ⇄ ERC20 Trades
-
-Coming soon...
-
-## ERC20 ⇄ ERC20 Trades
-
-Coming soon...
-
-## Custom Pools
-
-Coming soon...
diff --git a/docs/contracts/v1/guides/04-custom-linking.md b/docs/contracts/v1/guides/04-custom-linking.md
deleted file mode 100644
index f5d0b7a32..000000000
--- a/docs/contracts/v1/guides/04-custom-linking.md
+++ /dev/null
@@ -1,111 +0,0 @@
----
-id: custom-linking
-title: Custom Linking
----
-
-# Query Parameters
-
-The t1 front-end supports URL query parameters to allow for custom linking to the t1 exchange. Users and developers can use these query parameters to link to the t1 exchange with custom prefilled settings.
-
-Each Page has specific available URL parameters that can be set. Global parameters can be used on all pages.
-
-A parameter used on an incorrect page will have no effect on exchange settings. Parameters not set with a URL parameter will be set to standard exchange defaults.
-
-## Global
-
-| Parameter | Type | Description |
-| :-------- | :------- | :------------------------------- |
-| theme | `String` | Sets them to dark or light mode. |
-
-### Theme Options
-
-Theme can be set as `light` or `dark`.
-
-### Example Usage
-
-`https://app.uniswap.org/#/swap?theme=dark&use=v1`
-
-## Swap Page
-
-| Parameter | Type | Description |
-| :------------- | :--------------- | :--------------------------------------------------------------------- |
-| inputCurrency | `address` | Input currency that will be swapped for output currency. |
-| outputCurrency | `address or ETH` | Output currency that input currency will be swapped for. |
-| slippage | `number` | Max slippage to be used during transaction \(in bips\) |
-| exactAmount | `number` | The custom token amount to buy or sell. |
-| exactField | `string` | The field to set custom token amount for. Must be `input` or `output`. |
-
-### Defaults
-
-ETH defaults as the input currency. When a different token is selected for either input or output ETH will default as the opposite selected currency.
-
-### Constraints
-
-Addresses must be valid ERC20 addresses. Slippage and amount values must be valid numbers accepted by the exchange \(or error will prevent from swapping\). Slippage can 0, or within the range 10->9999 bips \(which converts to 0%, 0.01%->99%\)
-
-When selecting ETH as the output currency a user must also choose an inputCurrency that is not ETH \(to prevent ETH being populated in both fields\)
-
-### Setting Amounts
-
-Two parameters, exactField and exactAmount can be used to set specific token amounts to be sold or bought. Both fields must be set in the URL or there will be no effect on the settings.
-
-### Example Usage
-
-`https://app.uniswap.org/#/swap?exactField=input&exactAmount=10&inputCurrency=0x0F5D2fB29fb7d3CFeE444a200298f468908cC942?use=v1`
-
-## Send Page
-
-The send page has the same options available as the Swap page, plus one additional paramter, `recipient`.
-
-| Parameter | Type | Description |
-| :-------- | :-------- | :---------------------------------------------- |
-| recipient | `address` | Address of the recipient of a send transaction. |
-
-### Example Usage
-
-`https://app.uniswap.org/#/send?recipient=0x74Aa01d162E6dC6A657caC857418C403D48E2D77?use=v1`
-
-## Pool Page
-
-The Pool page is made up of 3 subroutes: `add-liquidity`, `remove-liquidity`, `create-exchange`.
-
-### Add Liquidity
-
-| Parameter | Type | Description |
-| :---------- | :-------- | :----------------------------------------------------- |
-| ethAmount | `number` | Amount of ETH to deposit into the pool. |
-| token | `address` | ERC20 address of the pool to add liquidity to. |
-| tokenAmount | `number` | Amount of the selected token to deposit into the pool. |
-
-### Example Usage
-
-`https://app.uniswap.org/#/add-liquidity?ethAmount=2.34&token=0x42456D7084eacF4083f1140d3229471bbA2949A8&tokenAmount=300?use=v1`
-
-## Remove Liquidity
-
-| Parameter | Type | Description |
-| :--------------- | :-------- | :-------------------------------------------------------------------------------------- |
-| poolTokenAddress | `address` | Pool to withdraw liquidity from. \(Must be an ERC20 address with an existing exchange\) |
-| poolTokenAmount | `number` | Amount of pool token to be withdrawn from liquidity pool. |
-
-### Example Usage
-
-`https://app.uniswap.org/#/remove-liquidity?poolTokenAmount=1.23&use=v1`
-
-## Create Exchange
-
-| Parameter | Type | Description |
-| :----------- | :-------- | :--------------------------------------------------------------------------------------------------------- |
-| tokenAddress | `address` | ERC20 token to create the exchange for. Must be valid ERC20 token for which there is no existing exchange. |
-
-### Example Usage
-
-`https://app.uniswap.org/#/swap?use=v1&create-exchange?tokenAddress=0x0F5D2fB29fb7d3CFeE444a200298f468908cC942`
-
-## 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.
-
-An example using custom token route and URL paramters.
-
-`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
deleted file mode 100644
index 30ab8dce4..000000000
--- a/docs/contracts/v1/guides/05-iframe-integration.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-id: iframe-integration
-title: Iframe Integration
----
-
-Uniswap can be used within other sites as an iframe. An iframe shows an exact version of the app.uniswap.org site and can have custom prefilled settings.
-
-# Why You May Want This
-
-Integrating the t1 site directly into your web application can be useful for a variety of reasons.
-
-v1.app.uniswap.org allows users to buy, sell, send, or provide liquidity for ERC20 tokens. An iframe integration may be useful if your application provides services around these ERC20 tokens. \(For example, users can buy DAI through a t1 iframe on your site, then allow users to lend that DAI on your site\).
-
-It can also be useful if your application requires users to acquire some token in order to use some service \(For example, allow users to buy "REP" token so they can engage in prediction markets on the Augur Dapp\).
-
-# 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.
-
-# Live Example
-
-An example of an Iframe integration can be found on the FOAM site [https://map.foam.space/](https://map.foam.space/#/at/?lng=-74.0045300&lat=40.6771800&zoom=5.00)
-
-To see the Iframe click the dropdown in the top right and click "get foam".
-
-# Add To Your Site
-
-To include a t1 iframe within your site just add an iframe element within your website code and link to the t1 exchange.
-
-Linking to a ETH <-> DAI swap page would look something like this. To link to a token of your choice replace the address after "outputCurrency" with the token address of the token you want to link to.
-
-```text
-
-```
-
-You can customize the selected page, selected custom tokens and more using URL query parameters. See [Custom Linking](custom-linking).
diff --git a/docs/contracts/v1/guides/06-token-listing.md b/docs/contracts/v1/guides/06-token-listing.md
deleted file mode 100644
index b3c55c76c..000000000
--- a/docs/contracts/v1/guides/06-token-listing.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-id: token-listing
-title: Token Listing
----
-
-It is possible that a token you are interested in is not included in the token dropdown on [https://app.uniswap.org/#/swap?use=v1](https://app.uniswap.org/#/swap?use=v1), however, all tokens that have a deployed uniswap exchange are supported on the front-end.
-
-There are three ways to interact with tokens that are not yet included on the default list.
-
-## 1. Paste the token address into the search box.
-
-If a token is not included in the list, try pasting the token address into the search box. It will populate the dropdown with the token you are looking for.
-
-## 2. Custom Linking
-
-[https://app.uniswap.org/#/swap?use=v1](https://app.uniswap.org/#/swap?use=v1) supports custom linking to all tokens that have a t1 exchange. See [Custom Linking](custom-linking) for details on how to link.
-
-For example, to populate the output token field with an unlisted token, we can specify the outputCurrency in the URL and pass in the token's address like this:
-
-`https://app.uniswap.org/#/swap?use=v1?outputCurrency=0xfA3E941D1F6B7b10eD84A0C211bfA8aeE907965e`
-
-## Token Details and Assets
-
-Token information (including decimals, symbol, name, etc.) is pulled from token contracts directly. Logo images are pulled from TrustWallet. If you'd like your token logo updated make a pull request into the TrustWallet assets repo [https://github.com/trustwallet/assets](https://github.com/trustwallet/assets).
diff --git a/docs/contracts/v1/guides/_category_.json b/docs/contracts/v1/guides/_category_.json
deleted file mode 100644
index c694eb5b2..000000000
--- a/docs/contracts/v1/guides/_category_.json
+++ /dev/null
@@ -1,5 +0,0 @@
-{
- "label": "Guides",
- "position": 2,
- "collapsed": false
-}
diff --git a/docs/contracts/v1/overview.md b/docs/contracts/v1/overview.md
deleted file mode 100644
index a743bb32a..000000000
--- a/docs/contracts/v1/overview.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-id: overview
-title: Overview
-sidebar_position: 1
----
-
-# The t1 V1 Smart Contracts
-
-Uniswap V1 is the first version of the protocol, [launched in November 2018](https://twitter.com/haydenzadams/status/1058376395108376577) at Devcon 4. Because of its permissionless nature, it will exist for as long as Ethereum does.
-
-Designed with simplicity in mind, the t1 protocol provides an interface for seamless exchange of ERC20 tokens on Ethereum. By eliminating unnecessary forms of rent extraction and middlemen it allows faster, more efficient exchange. Where it makes tradeoffs, decentralization, censorship resistance, and security are prioritized.
-
-Uniswap is open source and functions as a public good. There is no central token or platform fee. No special treatment is given to early investors, adopters, or developers. Token listing is open and free. All smart contract functions are public and all upgrades are opt-in.
-
-This site will serve as a project overview for t1 - explaining how it works, how to use it, and how to build on top of it. These docs are actively being worked on and more information will be added on an ongoing basis.
-
-# V1 Features
-
-- Add support for any ERC20 token using the t1 [factory](https://github.com/Uniswap/uniswap-v1/blob/master/contracts/uniswap_factory.vy)
-- Join liquidity pools to collect fees on ETH-ERC20 pairs
-- Liquidity-sensitive automated pricing using [constant product formula](https://github.com/runtimeverification/verified-smart-contracts/blob/uniswap/uniswap/x-y-k.pdf)
-- Trade ETH for any ERC20 without wrapping
-- Trade any ERC20 for any ERC20 in a single transaction
-- Trade and transfer to a different address in a single transaction
-- Lowest gas cost of any decentralized exchange
-- Support for private and custom uniswap exchanges
-- Buy ERC20 tokens from any wallet using ENS
-- [Partially verified](https://github.com/runtimeverification/verified-smart-contracts/tree/uniswap/uniswap) smart contracts written in Vyper
-- Mobile-optimized open source [frontend implementation](https://github.com/Uniswap/uniswap-interface)
-- Funded through an [Ethereum Foundation grant](https://blog.ethereum.org/2018/08/17/ethereum-foundation-grants-update-wave-3/)
-
-# Resources
-
-- [Website](https://uniswap.org)
-- [GitHub](https://github.com/Uniswap)
-- [Twitter](https://twitter.com/Uniswap)
-- [Reddit](https://www.reddit.com/r/Uniswap)
-- [Email](mailto:contact@uniswap.org)
-- [Whitepaper](https://hackmd.io/s/HJ9jLsfTz)
-
-# How it works
-
-Uniswap is made up of a series of ETH-ERC20 exchange contracts. There is exactly one exchange contract per ERC20 token. If a token does not yet have an exchange it can be created by anyone using the t1 factory contract. The factory serves as a public registry and is used to look up all token and exchange addresses added to the system.
-
-Each exchange holds reserves of both ETH and its associated ERC20 token. Anyone can become a liquidity provider on an exchange and contribute to its reserves. This is different than buying or selling; it requires depositing an equivalent value of both ETH and the relevant ERC20 token. Liquidity is pooled across all providers and an internal "pool token" (ERC20) is used to track each providers relative contribution. Pool tokens are minted when liquidity is deposited into the system and can be burned at any time to withdraw a proportional share of the reserves.
-
-Exchange contracts are automated market makers between an ETH-ERC20 pair. Traders can swap between the two in either direction by adding to the liquidity reserve of one and withdrawing from the reserve of the other. Since ETH is a common pair for all ERC20 exchanges, it can be used as an intermediary allowing direct ERC20-ERC20 trades in a single transaction. Users can specify a recipient address if they want to receive purchased tokens at a different address from the one used to make a transaction.
-
-Uniswap uses a "constant product" market making formula which sets the exchange rate based off of the relative size of the ETH and ERC20 reserves, and the amount with which an incoming trade shifts this ratio. Selling ETH for ERC20 tokens increases the size of the ETH reserve and decreases the size of the ERC20 reserve. This shifts the reserve ratio, increasing the ERC20 token's price relative to ETH for subsequent transactions. The larger a trade relative to the total size of the reserves, the more price slippage will occur. Essentially, exchange contracts use the open financial market to decide on the relative value of a pair and uses that as a market making strategy.
-
-A small liquidity provider fee \(0.30%\) is taken out of each trade and added to the reserves. While the ETH-ERC20 reserve ratio is constantly shifting, fees makes sure that the total combined reserve size increases with every trade. This functions as a payout to liquidity providers that is collected when they burn their pool tokens to withdraw their portion of total reserves. Guaranteed arbitrage opportunities from price fluctuations should push a steady flow of transactions through the system and increase the amount of fee revenue generated.
-
-Since t1 is entirely on-chain, prices can change between when a transaction is signed and when it is included in a block. Traders can bound price fluctuations by specifying the minimum amount bought on sell orders, or the maximum amount sold on buy orders. This acts as a limit order that will automatically cancel if it is not filled. It is also possible to set transaction deadlines which will cancel orders if they are not executed fast enough.
-
-The reason only one exchange per token can be registered to the factory is to encourage providers to pool their liquidity into a single reserve. However, t1 has built in support for ERC20-to-ERC20 trades using the public pools from the factory on one side of the transaction and custom, user-specified pool on the other. Custom pools could have fund managers, use alternate pricing mechanisms, remove liquidity provider fees, integrate complex three dimensional fomo-based ponzi-schemes and more. They just need to implement the t1 interface and accept ETH as an intermediary asset. Custom pools do not have the same safety properties as the public ones. It is recommended users only interact with audited, open-source smart contracts.
-
-Upgrading censorship resistant, decentralized smart contracts is difficult. If significant improvements are made to the system a new version will be released. Liquidity providers can choose between moving to the new system or staying in the old one. If possible, new versions will be backwards compatible and able to trade ERC20-to-ERC20 with the old versions similar to a custom pool.
-
-# How to use it
-
-[uniswap.org](https://uniswap.org) is the landing page for the t1 protocol. It describes the project and directs users where they need to go.
-
-The t1 smart contracts live on Ethereum. Anyone can interact with them directly.
-
-The t1 frontend is an open source interface designed to improve user experience when interacting with the smart contracts. Anyone can use the source code to host an interface, or build their own. Hosted interfaces are independent of t1, and should comply with their jurisdictional laws and regulations.
diff --git a/docs/contracts/v1/reference/01-factory.md b/docs/contracts/v1/reference/01-factory.md
deleted file mode 100644
index 9589ea5f3..000000000
--- a/docs/contracts/v1/reference/01-factory.md
+++ /dev/null
@@ -1,113 +0,0 @@
----
-id: factory
-title: Factory
----
-
-# initializeFactory
-
-| Parameter | Description |
-| :-------- | ------------------------------------: |
-| template | Ethereum address of exchange template |
-
-## Smart Contract
-
-```python
-initializeFactory(template: address)
-```
-
-## Web3
-
-```javascript
-factoryContract.methods.initializeFactory(template).send()
-```
-
-# createExchange
-
-| Parameter | Type | Description |
-| :-------- | :------ | ---------------------------------: |
-| token | address | Ethereum address of an ERC20 token |
-
-| Returns | |
-| :------ | -------------------------------------: |
-| address | Ethereum address of a t1 exchange |
-
-## Smart Contract
-
-```python
-createExchange(token: address): address
-```
-
-## Web3
-
-```javascript
-factoryContract.methods.createExchange(token).send()
-```
-
-# getExchange
-
-| Parameter | Type | Description |
-| :-------- | :------ | ---------------------------------: |
-| token | address | Ethereum address of an ERC20 token |
-
-| Returns | |
-| :------ | -------------------------------------: |
-| address | Ethereum address of a t1 exchange |
-
-## Smart Contract
-
-```python
-@constant
-getExchange(token: address): address
-```
-
-## Web3
-
-```javascript
-factoryContract.methods.getExchange(token).call()
-```
-
-# getToken
-
-| Parameter | Type | Description |
-| :-------- | :------ | -------------------------------------: |
-| exchange | address | Ethereum address of a t1 exchange |
-
-| Returns | |
-| :------ | ---------------------------------: |
-| address | Ethereum address of an ERC20 token |
-
-## Smart Contract
-
-```python
-@constant
-getToken(exchange: address): address
-```
-
-## Web3
-
-```javascript
-factoryContract.methods.getToken(exchange).call()
-```
-
-# getTokenWithId
-
-| Parameter | Type | Description |
-| :-------- | :------ | ----------------------------: |
-| token_id | uint256 | t1 ID for an ERC20 token |
-
-| Returns | |
-| :------ | ---------------------------------: |
-| address | Ethereum address of an ERC20 token |
-
-## Smart Contract
-
-```python
-@constant
-getTokenWithId(token_id: uint256): address
-```
-
-## Web3
-
-```javascript
-factoryContract.methods.getTokenWithId(token_id).call()
-```
diff --git a/docs/contracts/v1/reference/02-exchange.md b/docs/contracts/v1/reference/02-exchange.md
deleted file mode 100644
index a1213714c..000000000
--- a/docs/contracts/v1/reference/02-exchange.md
+++ /dev/null
@@ -1,942 +0,0 @@
----
-id: exchange
-title: Exchange
----
-
-# setup
-
-| Parameter | Description |
-| :--------- | ---------------------------------: |
-| token_addr | Ethereum address of an ERC20 Token |
-
-## Smart Contract
-
-```python
-# Can only be called by factory contract during createExchange()
-setup(token_addr: address):
-```
-
-## Web3
-
-```javascript
-// Can only be called by factory contract during createExchange()
-exchangeContract.methods.setup((token: String)).send()
-```
-
-# addLiquidity
-
-| Parameter | Type | Description |
-| :------------ | :------ | -------------------------: |
-| msg.value | uint256 | Amount of ETH added |
-| min_liquidity | uint256 | Minimum minted liquidity |
-| max_tokens | uint256 | Maximum ERC20 tokens added |
-| deadline | uint256 | Transaction deadline |
-
-| Returns | |
-| :------ | --------------------------------: |
-| uint256 | Amount of liquidity tokens minted |
-
-## Smart Contract
-
-```python
-@payable
-addLiquidity(
- min_liquidity: uint256,
- max_tokens: uint256,
- deadline: uint256
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.addLiquidity(min_liquidity, max_tokens, deadline).send({ value: ethValue })
-```
-
-# removeLiquidity
-
-| Parameter | Type | Description |
-| :--------- | :------ | ---------------------------: |
-| amount | uint256 | Amount of liquidity burned |
-| min_eth | uint256 | Minimum ETH removed |
-| min_tokens | uint256 | Minimum ERC20 tokens removed |
-| deadline | uint256 | Transaction deadline |
-
-| Returns | |
-| :------ | ------------------------------: |
-| uint256 | Amount of ETH removed |
-| uint256 | Amount of ERC20 tokens removed. |
-
-## Smart Contract
-
-```python
-removeLiquidity(
- amount: uint256;
- min_eth: uint256,
- min_tokens: uint256,
- deadline: uint256
-): (uint256, uint256)
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.removeLiquidity(amount, min_eth, min_tokens, deadline).send()
-```
-
-# default
-
-| Parameter | Type | Description |
-| :-------- | :------ | -----------------: |
-| msg.value | uint256 | Amount of ETH sold |
-
-## Smart Contract
-
-```python
-# Default function in Vyper replaces the "fallback" function in Solidity
-@payable
-__default__():
-```
-
-## Web3
-
-```javascript
-web3.eth.sendTransaction({ value: ethAmount })
-```
-
-# ethToTokenSwapInput
-
-| Parameter | Type | Description |
-| :--------- | :------ | --------------------------: |
-| msg.value | uint256 | Amount of ETH sold |
-| min_tokens | uint256 | Minimum ERC20 tokens bought |
-| deadline | uint256 | Transaction deadline |
-
-| Returns | |
-| :------ | ----------------------------: |
-| uint256 | Amount of ERC20 tokens bought |
-
-## Smart Contract
-
-```python
-@payable
-ethToTokenSwapInput(
- min_tokens: uint256,
- deadline: uint256
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.ethToTokenSwapInput(min_liquidity, max_tokens, deadline).send({ value: ethValue })
-```
-
-# ethToTokenTransferInput
-
-| Parameter | Type | Description |
-| :--------- | :------ | ---------------------------------: |
-| msg.value | uint256 | Amount of ETH sold |
-| min_tokens | uint256 | Minimum ERC20 tokens bought |
-| deadline | uint256 | Transaction deadline |
-| recipient | address | Address that receives ERC20 tokens |
-
-| Returns | |
-| :------ | ----------------------------: |
-| uint256 | Amount of ERC20 tokens bought |
-
-## Smart Contract
-
-```python
-@payable
-ethToTokenTransferInput(
- min_tokens: uint256,
- deadline: uint256,
- recipient: address
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods
- .ethToTokenTransferInput(min_liquidity, max_tokens, deadline, recipient)
- .send({ value: ethValue })
-```
-
-# ethToTokenSwapOutput
-
-| Parameter | Type | Description |
-| :------------ | :------ | ----------------------------: |
-| msg.value | uint256 | Maximum ETH sold |
-| tokens_bought | uint256 | Amount of ERC20 tokens bought |
-| deadline | uint256 | Transaction deadline |
-
-| Returns | |
-| :------ | -----------------: |
-| uint256 | Amount of ETH sold |
-
-## Smart Contract
-
-```python
-@payable
-ethToTokenSwapOutput(
- tokens_bought: uint256,
- deadline: uint256
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.ethToTokenSwapOutput(tokens_bought, deadline).send({ value: ethValue })
-```
-
-# ethToTokenTransferOutput
-
-| Parameter | Type | Description |
-| :------------ | :------ | ---------------------------------: |
-| msg.value | uint256 | Maximum ETH sold |
-| tokens_bought | uint256 | Amount of ERC20 tokens bought |
-| deadline | uint256 | Transaction deadline |
-| recipient | address | Address that receives ERC20 tokens |
-
-| Returns | |
-| :------ | -----------------: |
-| uint256 | Amount of ETH sold |
-
-## Smart Contract
-
-```python
-@payable
-ethToTokenTransferOutput(
- tokens_bought: uint256,
- deadline: uint256,
- recipient: address
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods
- .ethToTokenTransferOutput(tokens_bought, deadline, (recipient: String))
- .send({ value: ethValue })
-```
-
-# tokenToEthSwapInput
-
-| Parameter | Type | Description |
-| :---------- | :------ | --------------------------: |
-| tokens_sold | uint256 | Amount of ERC20 tokens sold |
-| min_eth | uint256 | Minimum ETH bought |
-| deadline | uint256 | Transaction deadline |
-
-| Returns | |
-| :------ | -------------------: |
-| uint256 | Amount of ETH bought |
-
-## Smart Contract
-
-```python
-tokenToEthSwapInput(
- tokens_sold: uint256,
- min_eth: uint256,
- deadline: uint256
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.tokenToEthSwapInput(tokens_sold, min_eth, deadline).send()
-```
-
-# tokenToEthTransferInput
-
-| Parameter | Type | Description |
-| :---------- | :------ | --------------------------: |
-| tokens_sold | uint256 | Amount of ERC20 tokens sold |
-| min_eth | uint256 | Minimum ETH bought |
-| deadline | uint256 | Transaction deadline |
-| recipient | address | Address that receives ETH |
-
-| Returns | |
-| :------ | -------------------: |
-| uint256 | Amount of ETH bought |
-
-## Smart Contract
-
-```python
-tokenToEthTransferInput(
- tokens_sold: uint256,
- min_eth: uint256,
- deadline: uint256,
- recipient: address
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.tokenToEthTransferInput(tokens_sold, min_eth, deadline, recipient).send()
-```
-
-# tokenToEthSwapOutput
-
-| Parameter | Type | Description |
-| :--------- | :------ | ------------------------: |
-| eth_bought | uint256 | Amount of ETH bought |
-| max_tokens | uint256 | Maximum ERC20 tokens sold |
-| deadline | uint256 | Transaction deadline |
-
-| Returns | |
-| :------ | --------------------------: |
-| uint256 | Amount of ERC20 tokens sold |
-
-## Smart Contract
-
-```python
-tokenToEthSwapOutput(
- eth_bought: uint256,
- max_tokens: uint256,
- deadline: uint256
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.tokenToEthSwapOutput(eth_bought, max_tokens, (deadline: Integer)).send()
-```
-
-# tokenToEthTransferOutput
-
-| Parameter | Type | Description |
-| :--------- | :------ | ------------------------: |
-| eth_bought | uint256 | Amount of ETH bought |
-| max_tokens | uint256 | Maximum ERC20 tokens sold |
-| deadline | uint256 | Transaction deadline |
-| recipient | address | Address that receives ETH |
-
-| Returns | |
-| :------ | --------------------------: |
-| uint256 | Amount of ERC20 tokens sold |
-
-## Smart Contract
-
-```python
-tokenToEthTransferOutput(
- eth_bought: uint256,
- max_tokens: uint256,
- deadline: uint256,
- recipient: address
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods
- .tokenToEthTransferOutput(eth_bought, max_tokens, (deadline: Integer), (recipient: String))
- .send()
-```
-
-# tokenToTokenSwapInput
-
-| Parameter | Type | Description |
-| :---------------- | :------ | ---------------------------------: |
-| tokens_sold | uint256 | Amount of input ERC20 tokens sold |
-| min_tokens_bought | uint256 | Minimum output ERC20 tokens bought |
-| min_eth_bought | uint256 | Minimum ETH bought as intermediary |
-| deadline | uint256 | Transaction deadline |
-| token_addr | address | Address of output ERC20 token |
-
-| Returns | |
-| :------ | -----------------------------------: |
-| uint256 | Amount of output ERC20 tokens bought |
-
-## Smart Contract
-
-```python
-tokenToTokenSwapInput(
- tokens_sold: uint256,
- min_tokens_bought: uint256,
- min_eth_bought: uint256,
- deadline: uint256,
- token_addr: address
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods
- .tokenToTokenSwapInput(tokens_sold, min_tokens_bought, min_eth_bought, deadline, token_addr)
- .send()
-```
-
-# tokenToTokenTransferInput
-
-| Parameter | Type | Description |
-| :---------------- | :------ | ----------------------------------------: |
-| tokens_sold | uint256 | Amount of input ERC20 tokens sold |
-| min_tokens_bought | uint256 | Minimum output ERC20 tokens bought |
-| min_eth_bought | uint256 | Minimum ETH bought as intermediary |
-| deadline | uint256 | Transaction deadline |
-| recipient | address | Address that receives output ERC20 tokens |
-| token_addr | address | Address of output ERC20 token |
-
-| Returns | |
-| :------ | -----------------------------------: |
-| uint256 | Amount of output ERC20 tokens bought |
-
-## Smart Contract
-
-```python
-tokenToTokenTransferInput(
- tokens_sold: uint256,
- min_tokens_bought: uint256,
- min_eth_bought: uint256,
- deadline: uint256,
- recipient: address
- token_addr: address
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods
- .tokenToTokenTransferInput(tokens_sold, min_tokens_bought, min_eth_bought, deadline, recipient, token_addr)
- .send()
-```
-
-# tokenToTokenSwapOutput
-
-| Parameter | Type | Description |
-| :-------------- | :------ | -----------------------------------: |
-| tokens_bought | uint256 | Amount of output ERC20 tokens bought |
-| max_tokens_sold | uint256 | Maximum input ERC20 tokens bought |
-| max_eth_sold | uint256 | Maximum ETH bought as intermediary |
-| deadline | uint256 | Transaction deadline |
-| token_addr | address | Address of output ERC20 token |
-
-| Returns | |
-| :------ | --------------------------------: |
-| uint256 | Amount of input ERC20 tokens sold |
-
-## Smart Contract
-
-```python
-tokenToTokenSwapOutput(
- tokens_bought: uint256,
- max_tokens_sold: uint256,
- max_eth_sold: uint256,
- deadline: uint256,
- token_addr: address
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods
- .tokenToTokenSwapOutput(tokens_bought, max_tokens_sold, max_eth_sold, deadline, token_addr)
- .send()
-```
-
-# tokenToTokenTransferOutput
-
-| Parameter | Type | Description |
-| :-------------- | :------ | ----------------------------------------: |
-| tokens_bought | uint256 | Amount of output ERC20 tokens bought |
-| max_tokens_sold | uint256 | Maximum input ERC20 tokens bought |
-| max_eth_sold | uint256 | Maximum ETH bought as intermediary |
-| deadline | uint256 | Transaction deadline |
-| recipient | address | Address that receives output ERC20 tokens |
-| token_addr | address | Address of output ERC20 token |
-
-| Returns | |
-| :------ | --------------------------------: |
-| uint256 | Amount of input ERC20 tokens sold |
-
-## Smart Contract
-
-```python
-tokenToTokenTransferOutput(
- tokens_bought: uint256,
- max_tokens_sold: uint256,
- max_eth_sold: uint256,
- deadline: uint256,
- recipient: address,
- token_addr: address
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods
- .tokenToTokenTransferOutput(tokens_bought, max_tokens_sold, max_eth_sold, deadline, recipient, token_addr)
- .send()
-```
-
-# tokenToExchangeSwapInput
-
-| Parameter | Type | Description |
-| :---------------- | :------ | -------------------------------------: |
-| tokens_sold | uint256 | Amount of input ERC20 tokens sold |
-| min_tokens_bought | uint256 | Minimum output ERC20 tokens bought |
-| min_eth_bought | uint256 | Minimum ETH bought as intermediary |
-| deadline | uint256 | Transaction deadline |
-| exchange_addr | address | Address of output ERC20 token exchange |
-
-| Returns | |
-| :------ | -----------------------------------: |
-| uint256 | Amount of output ERC20 tokens bought |
-
-## Smart Contract
-
-```python
-tokenToTokenSwapInput(
- tokens_sold: uint256,
- min_tokens_bought: uint256,
- min_eth_bought: uint256,
- deadline: uint256,
- exchange_addr: address
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods
- .tokenToTokenSwapInput(tokens_sold, min_tokens_bought, min_eth_bought, deadline, exchange_addr)
- .send()
-```
-
-# tokenToExchangeTransferInput
-
-| Parameter | Type | Description |
-| :---------------- | :------ | ----------------------------------------: |
-| tokens_sold | uint256 | Amount of input ERC20 tokens sold |
-| min_tokens_bought | uint256 | Minimum output ERC20 tokens bought |
-| min_eth_bought | uint256 | Minimum ETH bought as intermediary |
-| deadline | uint256 | Transaction deadline |
-| recipient | address | Address that receives output ERC20 tokens |
-| exchange_addr | address | Address of output ERC20 token exchange |
-
-| Returns | |
-| :------ | -----------------------------------: |
-| uint256 | Amount of output ERC20 tokens bought |
-
-## Smart Contract
-
-```python
-tokenToExchangeTransferInput(
- tokens_sold: uint256,
- min_tokens_bought: uint256,
- min_eth_bought: uint256,
- deadline: uint256,
- recipient: address
- exchange_addr: address
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods
- .tokenToExchangeTransferInput(tokens_sold, min_tokens_bought, min_eth_bought, deadline, recipient, exchange_addr)
- .send()
-```
-
-# tokenToExchangeSwapOutput
-
-| Parameter | Type | Description |
-| :-------------- | :------ | -------------------------------------: |
-| tokens_bought | uint256 | Amount of output ERC20 tokens bought |
-| max_tokens_sold | uint256 | Maximum input ERC20 tokens bought |
-| max_eth_sold | uint256 | Maximum ETH bought as intermediary |
-| deadline | uint256 | Transaction deadline |
-| exchange_addr | address | Address of output ERC20 token exchange |
-
-| Returns | |
-| :------ | --------------------------------: |
-| uint256 | Amount of input ERC20 tokens sold |
-
-## Smart Contract
-
-```python
-tokenToExchangeSwapOutput(
- tokens_bought: uint256,
- max_tokens_sold: uint256,
- max_eth_sold: uint256,
- deadline: uint256,
- exchange_addr: address
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods
- .tokenToExchangeSwapOutput(tokens_bought, max_tokens_sold, max_eth_sold, deadline, exchange_addr)
- .send()
-```
-
-# tokenToExchangeTransferOutput
-
-| Parameter | Type | Description |
-| :-------------- | :------ | ----------------------------------------: |
-| tokens_bought | uint256 | Amount of output ERC20 tokens bought |
-| max_tokens_sold | uint256 | Maximum input ERC20 tokens bought |
-| max_eth_sold | uint256 | Maximum ETH bought as intermediary |
-| deadline | uint256 | Transaction deadline |
-| recipient | address | Address that receives output ERC20 tokens |
-| exchange_addr | address | Address of output ERC20 token exchange |
-
-| Returns | |
-| :------ | --------------------------------: |
-| uint256 | Amount of input ERC20 tokens sold |
-
-## Smart Contract
-
-```python
-tokenToExchangeTransferOutput(
- tokens_bought: uint256,
- max_tokens_sold: uint256,
- max_eth_sold: uint256,
- deadline: uint256,
- recipient: address,
- exchange_addr: address
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods
- .tokenToExchangeTransferOutput(tokens_bought, max_tokens_sold, max_eth_sold, deadline, recipient, exchange_addr)
- .send()
-```
-
-# getEthToTokenInputPrice
-
-| Parameter | Type | Description |
-| :-------- | :------ | -----------------: |
-| eth_sold | uint256 | Amount of ETH sold |
-
-| Returns | |
-| :------ | ----------------------------------------: |
-| uint256 | Amount of ERC20 tokens that can be bought |
-
-## Smart Contract
-
-```python
-@constant
-getEthToTokenInputPrice(eth_sold: uint256): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.getEthToTokenInputPrice(eth_sold).call()
-```
-
-# getEthToTokenOutputPrice
-
-| Parameter | Type | Description |
-| :------------ | :------ | ----------------------------: |
-| tokens_bought | uint256 | Amount of ERC20 tokens bought |
-
-| Returns | |
-| :------ | ------------------------------: |
-| uint256 | Amount of ETH that must be sold |
-
-## Smart Contract
-
-```python
-@constant
-getEthToTokenOutputPrice(tokens_bought: uint256): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.getEthToTokenOutputPrice(tokens_bought).call()
-```
-
-# getTokenToEthInputPrice
-
-| Parameter | Type | Description |
-| :---------- | :------ | --------------------------: |
-| tokens_sold | uint256 | Amount of ERC20 tokens sold |
-
-| Returns | |
-| :------ | -------------------------------: |
-| uint256 | Amount of ETH that can be bought |
-
-## Smart Contract
-
-```python
-@constant
-getTokenToEthInputPrice(tokens_sold: uint256): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.getTokenToEthInputPrice(tokens_sold).call()
-```
-
-# getTokenToEthOutputPrice
-
-| Parameter | Type | Description |
-| :--------- | :------ | -------------------: |
-| eth_bought | uint256 | Amount of ETH bought |
-
-| Returns | |
-| :------ | ---------------------------------------: |
-| uint256 | Amount of ERC20 tokens that must be sold |
-
-## Smart Contract
-
-```python
-@constant
-getTokenToEthOutputPrice(eth_bought: uint256): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.getTokenToEthOutputPrice(eth_bought).call()
-```
-
-# tokenAddress
-
-| Returns | |
-| :------ | --------------------------------------: |
-| address | Address of ERC20 token sold on exchange |
-
-## Smart Contract
-
-```python
-@constant
-tokenAddress(): address
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.tokenAddress().call()
-```
-
-# factoryAddress
-
-| Returns | |
-| :------ | ---------------------------------------: |
-| address | Address of factory that created exchange |
-
-## Smart Contract
-
-```python
-@constant
-factoryAddress(): address
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.factoryAddress().call()
-```
-
-# name
-
-| Returns | |
-| :------ | ----------------------: |
-| bytes32 | Name of liquidity token |
-
-## Smart Contract
-
-```python
-# all exchange contracts have the same name
-@constant
-name(): bytes32 // t1 V1
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.tokenAddress().call()
-```
-
-# symbol
-
-| Returns | |
-| :------ | ------------------------: |
-| bytes32 | Symbol of liquidity token |
-
-## Smart Contract
-
-```python
-# all exchange contracts have the same symbol
-@constant
-symbol(): bytes32 // UNI-V1
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.tokenAddress().call()
-```
-
-# decimals
-
-| Returns | |
-| :------ | --------------------------: |
-| uint256 | Decimals of liquidity token |
-
-## Smart Contract
-
-```python
-# all exchange contracts have the same decimals
-@constant
-decimals(): uint256 // 18
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.decimals().call()
-```
-
-# balanceOf
-
-| Parameter | Type | Description |
-| :-------- | :------ | ---------------: |
-| \_owner | address | Ethereum address |
-
-| Returns | |
-| :------ | ---------------------------------: |
-| uint256 | Liquidity token balance of address |
-
-## Smart Contract
-
-```python
-@constant
-balanceOf(_owner: address): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.balanceOf(_owner).call()
-```
-
-# transfer
-
-| Parameter | Type | Description |
-| :-------- | :------ | -----------------: |
-| \_to | address | Recipient address |
-| \_value | uint256 | Amount transferred |
-
-| Returns | |
-| :------ | ----------------------------------------------: |
-| bool | True if successful. Reverts or false on failure |
-
-## Smart Contract
-
-```python
-transfer(
- _to: address,
- _value : uint256
-): bool
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.transfer(_to, _value).send()
-```
-
-# transferFrom
-
-| Parameter | Type | Description |
-| :-------- | :------ | -----------------: |
-| \_from | address | Sender address |
-| \_to | address | Recipient address |
-| \_value | uint256 | Amount transferred |
-
-| Returns | |
-| :------ | ----------------------------------------------: |
-| bool | True if successful. Reverts or false on failure |
-
-## Smart Contract
-
-```python
-transferFrom(
- _from: address,
- _to: address,
- _value : uint256
-): bool
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.transferFrom(_from, _to, _value).send()
-```
-
-# approve
-
-| Parameter | Type | Description |
-| :-------- | :------ | --------------------------: |
-| \_spender | address | Address of approved spender |
-| \_value | uint256 | Spender allowance |
-
-| Returns | |
-| :------ | ----------------------------------------------: |
-| bool | True if successful. Reverts or false on failure |
-
-## Smart Contract
-
-```python
-approve(
- _spender: address,
- _value: uint256
-): bool
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.approve(_spender, _value).send()
-```
-
-# allowance
-
-| Parameter | Type | Description |
-| :-------- | :------ | -------------------------------: |
-| \_owner | address | Address of liquidity token owner |
-| \_spender | uint256 | Address of approved spender |
-
-| Returns | |
-| :------ | ----------------: |
-| uint256 | Spender allowance |
-
-## Smart Contract
-
-```python
-allowance(
- _owner: address,
- _spender: address
-): uint256
-```
-
-## Web3
-
-```javascript
-exchangeContract.methods.allowance(_owner, _spender).call()
-```
diff --git a/docs/contracts/v1/reference/03-interfaces.md b/docs/contracts/v1/reference/03-interfaces.md
deleted file mode 100644
index 67ce78f89..000000000
--- a/docs/contracts/v1/reference/03-interfaces.md
+++ /dev/null
@@ -1,174 +0,0 @@
----
-id: interfaces
-title: Interfaces
----
-
-# Factory
-
-## Solidity
-
-```solidity
-interface t1FactoryInterface {
- // Public Variables
- address public exchangeTemplate;
- uint256 public tokenCount;
- // Create Exchange
- function createExchange(address token) external returns (address exchange);
- // Get Exchange and Token Info
- function getExchange(address token) external view returns (address exchange);
- function getToken(address exchange) external view returns (address token);
- function getTokenWithId(uint256 tokenId) external view returns (address token);
- // Never use
- function initializeFactory(address template) external;
-}
-```
-
-## Vyper
-
-```python
-contract t1FactoryInterface():
- # Create Exchange
- def createExchange(token: address) -> address: modifying
- # Public Variables
- def exchangeTemplate() -> address: constant
- def tokenCount() -> uint256: constant
- # Get Exchange and Token Info
- def getExchange(token_addr: address) -> address: constant
- def getToken(exchange: address) -> address: constant
- def getTokenWithId(token_id: uint256) -> address: constant
- # Initialize Factory
- def initializeFactory(template: address): modifying
-```
-
-# Exchange
-
-## Solidity
-
-```solidity
-interface t1ExchangeInterface {
- // Address of ERC20 token sold on this exchange
- function tokenAddress() external view returns (address token);
- // Address of t1 Factory
- function factoryAddress() external view returns (address factory);
- // Provide Liquidity
- function addLiquidity(uint256 min_liquidity, uint256 max_tokens, uint256 deadline) external payable returns (uint256);
- function removeLiquidity(uint256 amount, uint256 min_eth, uint256 min_tokens, uint256 deadline) external returns (uint256, uint256);
- // Get Prices
- function getEthToTokenInputPrice(uint256 eth_sold) external view returns (uint256 tokens_bought);
- function getEthToTokenOutputPrice(uint256 tokens_bought) external view returns (uint256 eth_sold);
- function getTokenToEthInputPrice(uint256 tokens_sold) external view returns (uint256 eth_bought);
- function getTokenToEthOutputPrice(uint256 eth_bought) external view returns (uint256 tokens_sold);
- // Trade ETH to ERC20
- function ethToTokenSwapInput(uint256 min_tokens, uint256 deadline) external payable returns (uint256 tokens_bought);
- function ethToTokenTransferInput(uint256 min_tokens, uint256 deadline, address recipient) external payable returns (uint256 tokens_bought);
- function ethToTokenSwapOutput(uint256 tokens_bought, uint256 deadline) external payable returns (uint256 eth_sold);
- function ethToTokenTransferOutput(uint256 tokens_bought, uint256 deadline, address recipient) external payable returns (uint256 eth_sold);
- // Trade ERC20 to ETH
- function tokenToEthSwapInput(uint256 tokens_sold, uint256 min_eth, uint256 deadline) external returns (uint256 eth_bought);
- function tokenToEthTransferInput(uint256 tokens_sold, uint256 min_eth, uint256 deadline, address recipient) external returns (uint256 eth_bought);
- function tokenToEthSwapOutput(uint256 eth_bought, uint256 max_tokens, uint256 deadline) external returns (uint256 tokens_sold);
- function tokenToEthTransferOutput(uint256 eth_bought, uint256 max_tokens, uint256 deadline, address recipient) external returns (uint256 tokens_sold);
- // Trade ERC20 to ERC20
- function tokenToTokenSwapInput(uint256 tokens_sold, uint256 min_tokens_bought, uint256 min_eth_bought, uint256 deadline, address token_addr) external returns (uint256 tokens_bought);
- function tokenToTokenTransferInput(uint256 tokens_sold, uint256 min_tokens_bought, uint256 min_eth_bought, uint256 deadline, address recipient, address token_addr) external returns (uint256 tokens_bought);
- function tokenToTokenSwapOutput(uint256 tokens_bought, uint256 max_tokens_sold, uint256 max_eth_sold, uint256 deadline, address token_addr) external returns (uint256 tokens_sold);
- function tokenToTokenTransferOutput(uint256 tokens_bought, uint256 max_tokens_sold, uint256 max_eth_sold, uint256 deadline, address recipient, address token_addr) external returns (uint256 tokens_sold);
- // Trade ERC20 to Custom Pool
- function tokenToExchangeSwapInput(uint256 tokens_sold, uint256 min_tokens_bought, uint256 min_eth_bought, uint256 deadline, address exchange_addr) external returns (uint256 tokens_bought);
- 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
- bytes32 public name;
- bytes32 public symbol;
- uint256 public decimals;
- function transfer(address _to, uint256 _value) external returns (bool);
- function transferFrom(address _from, address _to, uint256 value) external returns (bool);
- function approve(address _spender, uint256 _value) external returns (bool);
- function allowance(address _owner, address _spender) external view returns (uint256);
- function balanceOf(address _owner) external view returns (uint256);
- function totalSupply() external view returns (uint256);
- // Never use
- function setup(address token_addr) external;
-}
-```
-
-## Vyper
-
-```python
-contract t1ExchangeInterface():
- # Public Variables
- def tokenAddress() -> address: constant
- def factoryAddress() -> address: constant
- # Providing Liquidity
- def addLiquidity(min_liquidity: uint256, max_tokens: uint256, deadline: timestamp) -> uint256: modifying
- def removeLiquidity(amount: uint256, min_eth: uint256(wei), min_tokens: uint256, deadline: timestamp) -> (uint256(wei), uint256): modifying
- # Trading
- def ethToTokenSwapInput(min_tokens: uint256, deadline: timestamp) -> uint256: modifying
- def ethToTokenTransferInput(min_tokens: uint256, deadline: timestamp, recipient: address) -> uint256: modifying
- def ethToTokenSwapOutput(tokens_bought: uint256, deadline: timestamp) -> uint256(wei): modifying
- def ethToTokenTransferOutput(tokens_bought: uint256, deadline: timestamp, recipient: address) -> uint256(wei): modifying
- def tokenToEthSwapInput(tokens_sold: uint256, min_eth: uint256(wei), deadline: timestamp) -> uint256(wei): modifying
- def tokenToEthTransferInput(tokens_sold: uint256, min_eth: uint256(wei), deadline: timestamp, recipient: address) -> uint256(wei): modifying
- def tokenToEthSwapOutput(eth_bought: uint256(wei), max_tokens: uint256, deadline: timestamp) -> uint256: modifying
- def tokenToEthTransferOutput(eth_bought: uint256(wei), max_tokens: uint256, deadline: timestamp, recipient: address) -> uint256: modifying
- def tokenToTokenSwapInput(tokens_sold: uint256, min_tokens_bought: uint256, min_eth_bought: uint256(wei), deadline: timestamp, token_addr: address) -> uint256: modifying
- def tokenToTokenTransferInput(tokens_sold: uint256, min_tokens_bought: uint256, min_eth_bought: uint256(wei), deadline: timestamp, recipient: address, token_addr: address) -> uint256: modifying
- def tokenToTokenSwapOutput(tokens_bought: uint256, max_tokens_sold: uint256, max_eth_sold: uint256(wei), deadline: timestamp, token_addr: address) -> uint256: modifying
- def tokenToTokenTransferOutput(tokens_bought: uint256, max_tokens_sold: uint256, max_eth_sold: uint256(wei), deadline: timestamp, recipient: address, token_addr: address) -> uint256: modifying
- def tokenToExchangeSwapInput(tokens_sold: uint256, min_tokens_bought: uint256, min_eth_bought: uint256(wei), deadline: timestamp, exchange_addr: address) -> uint256: modifying
- def tokenToExchangeTransferInput(tokens_sold: uint256, min_tokens_bought: uint256, min_eth_bought: uint256(wei), deadline: timestamp, recipient: address, exchange_addr: address) -> uint256: modifying
- def tokenToExchangeSwapOutput(tokens_bought: uint256, max_tokens_sold: uint256, max_eth_sold: uint256(wei), deadline: timestamp, exchange_addr: address) -> uint256: modifying
- def tokenToExchangeTransferOutput(tokens_bought: uint256, max_tokens_sold: uint256, max_eth_sold: uint256(wei), deadline: timestamp, recipient: address, exchange_addr: address) -> uint256: modifying
- # Get Price
- def getEthToTokenInputPrice(eth_sold: uint256(wei)) -> uint256: constant
- def getEthToTokenOutputPrice(tokens_bought: uint256) -> uint256(wei): constant
- def getTokenToEthInputPrice(tokens_sold: uint256) -> uint256(wei): constant
- def getTokenToEthOutputPrice(eth_bought: uint256(wei)) -> uint256: constant
- # Pool Token ERC20 Compatibility
- def balanceOf() -> address: constant
- def allowance(_owner : address, _spender : address) -> uint256: constant
- def transfer(_to : address, _value : uint256) -> bool: modifying
- def transferFrom(_from : address, _to : address, _value : uint256) -> bool: modifying
- def approve(_spender : address, _value : uint256) -> bool: modifying
- # Setup
- def setup(token_addr: address): modifying
-```
-
-# ERC20 Token
-
-## Solidity
-
-```solidity
-interface ERC20Interface {
- function totalSupply() public view returns (uint);
- function balanceOf(address tokenOwner) public view returns (uint balance);
- function allowance(address tokenOwner, address spender) public view returns (uint remaining);
- function transfer(address to, uint tokens) public returns (bool success);
- function approve(address spender, uint tokens) public returns (bool success);
- function transferFrom(address from, address to, uint tokens) public returns (bool success);
- // optional
- function name() external view returns (string);
- function symbol() external view returns (string);
- function decimals() external view returns (string);
-
- event Transfer(address indexed from, address indexed to, uint tokens);
- event Approval(address indexed tokenOwner, address indexed spender, uint tokens);
-}
-```
-
-## Vyper
-
-```python
-contract ERC20Interface():
- def totalSupply() -> uint256: constant
- def balanceOf(_owner: address) -> uint256: constant
- def allowance(_owner : address, _spender : address) -> uint256: constant
- def transfer(_to : address, _value : uint256) -> bool: modifying
- def approve(_spender : address, _value : uint256) -> bool: modifying
- def transferFrom(_from : address, _to : address, _value : uint256) -> bool: modifying
- # optional
- def name() -> bytes32: constant
- def symbol() -> bytes32: constant
- def decimals() -> uint256: constant
-```
diff --git a/docs/contracts/v1/reference/_category_.json b/docs/contracts/v1/reference/_category_.json
deleted file mode 100644
index 0e72ac2e5..000000000
--- a/docs/contracts/v1/reference/_category_.json
+++ /dev/null
@@ -1,5 +0,0 @@
-{
- "label": "Technical Reference",
- "position": 3,
- "collapsed": false
-}
diff --git a/docs/contracts/v2/_category_.json b/docs/contracts/v2/_category_.json
deleted file mode 100644
index 56ca4aba5..000000000
--- a/docs/contracts/v2/_category_.json
+++ /dev/null
@@ -1,5 +0,0 @@
-{
- "label": "V2 Protocol",
- "position": 5,
- "collapsed": true
-}
diff --git a/docs/contracts/v2/concepts/01-protocol-overview/01-how-uniswap-works.md b/docs/contracts/v2/concepts/01-protocol-overview/01-how-uniswap-works.md
deleted file mode 100644
index d45eb2ca3..000000000
--- a/docs/contracts/v2/concepts/01-protocol-overview/01-how-uniswap-works.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-id: how-uniswap-works
-title: How t1 works
----
-
-
-
-Uniswap is an _automated liquidity protocol_ powered by a [constant product formula](../protocol-overview/glossary#constant-product-formula)
-and implemented in a system of non-upgradeable smart contracts on the [Ethereum](https://ethereum.org/) blockchain.
-It obviates the need for trusted intermediaries, prioritizing **decentralization**, **censorship resistance**,
-and **security**. t1 is **open-source software** licensed under the
-[GPL](https://en.wikipedia.org/wiki/GNU_General_Public_License).
-
-Each t1 smart contract, or pair, manages a liquidity pool made up of reserves of two [ERC-20](https://eips.ethereum.org/EIPS/eip-20) tokens.
-
-Anyone can become a liquidity provider (LP) for a pool by depositing an equivalent value of each underlying token in return for pool tokens. These tokens track pro-rata LP shares of the total reserves, and can be redeemed for the underlying assets at any time.
-
-
-
-Pairs act as automated market makers, standing ready to accept one token for the other as long as the “constant product” formula is preserved. This formula, most simply expressed as `x * y = k`, states that trades must not change the product (`k`) of a pair’s reserve balances (`x` and `y`). Because `k` remains unchanged from the reference frame of a trade, it is often referred to as the invariant. This formula has the desirable property that larger trades (relative to reserves) execute at exponentially worse rates than smaller ones.
-
-In practice, t1 applies a 0.30% fee to trades, which is added to reserves. As a result, each trade actually increases `k`. This functions as a payout to LPs, which is realized when they burn their pool tokens to withdraw their portion of total reserves. In the future, this fee may be reduced to 0.25%, with the remaining 0.05% withheld as a protocol-wide charge.
-
-
-
-Because the relative price of the two pair assets can only be changed through trading, divergences between the t1 price and external prices create arbitrage opportunities. This mechanism ensures that t1 prices always trend toward the market-clearing price.
-
-# Further reading
-
-To see how token swaps work in practice, and to walk through the lifecycle of a swap, check out [Swaps](../core-concepts/swaps). Or, to see how liquidity pools work, see [Pools](../core-concepts/pools).
-
-Ultimately, of course, the t1 protocol is just smart contract code running on Ethereum. To understand how they work, head over to [Smart Contracts](../../reference/smart-contracts/factory).
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
deleted file mode 100644
index 462134a93..000000000
--- a/docs/contracts/v2/concepts/01-protocol-overview/02-ecosystem-participants.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-id: ecosystem-participants
-title: Ecosystem Participants
----
-
-
-
-The t1 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 t1 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.
-
-# Liquidity Providers
-
-Liquidity providers, or LPs, are not a homogenous group:
-
-- Passive LPs are token holders who wish to passively invest their assets to accumulate trading fees.
-
-- Professional LPs are focused on market making as their primary strategy. They usually develop custom tools and ways of tracking their liquidity positions across different DeFi projects.
-
-- 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 t1.
-
-- Finally, some DeFi pioneers are exploring complex liquidity provision interactions like incentivized liquidity, liquidity as collateral, and other experimental strategies. t1 is the perfect protocol for projects to experiment with these kinds of ideas.
-
-# Traders
-
-There are a several categories of traders in the protocol ecosystem:
-
-- Speculators use a variety of community built tools and products to swap tokens using liquidity pulled from the t1 protocol.
-
-- Arbitrage bots seek profits by comparing prices across different platforms to find an edge. (Though it might seem extractive, these bots actually help equalize prices across broader Ethereum markets and keep things fair.)
-
-- DAPP users buy tokens on t1 for use in other applications on Ethereum.
-
-- 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.
-
-# Developers/Projects
-
-There are far too many ways t1 is used in the wider Ethereum ecosystem to count, but some examples include:
-
-- The open-source, accessible nature of t1 means there are countless UX experiments and front-ends built to offer access to t1 functionality. You can find t1 functions in most of the major DeFi dashboard projects. There are also many [Uniswap-specific tools](https://github.com/Uniswap/universe) built by the community.
-
-- Wallets often integrate swapping and liquidity provision functionality as a core offering of their product.
-
-- DEX (decentralized exchange) aggregators pull liquidity from many liquidity protocols to offer traders the best prices by splitting their trades. t1 is the biggest single decentralized liquidity source for these projects.
-
-- Smart contract developers use the suite of functions available to invent new DeFi tools and other various experimental ideas. See projects like [Unisocks](https://unisocks.exchange/) or [Zora](https://ourzora.com/), among many, many others.
-
-# t1 Team and Community
-
-The t1 team along with the broader t1 community drives development of the protocol and ecosystem.
diff --git a/docs/contracts/v2/concepts/01-protocol-overview/03-smart-contracts.md b/docs/contracts/v2/concepts/01-protocol-overview/03-smart-contracts.md
deleted file mode 100644
index 4c0475f4e..000000000
--- a/docs/contracts/v2/concepts/01-protocol-overview/03-smart-contracts.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-id: smart-contracts
-title: Smart contracts
----
-
-Uniswap V2 is a binary smart contract system. [Core](#core) contracts provide fundamental safety guarantees for all parties interacting with t1. [Periphery](#periphery) contracts interact with one or more core contracts but are not themselves part of the core.
-
-# Core
-
-[Source code](https://github.com/Uniswap/uniswap-v2-core)
-
-The core consists of a singleton [factory](#factory) and many [pairs](#pairs), which the factory is responsible for creating and indexing. These contracts are quite minimal, even brutalist. The simple rationale for this is that contracts with a smaller surface area are easier to reason about, less bug-prone, and more functionally elegant. Perhaps the biggest upside of this design is that many desired properties of the system can be asserted directly in the code, leaving little room for error. One downside, however, is that core contracts are somewhat user-unfriendly. In fact, interacting directly with these contracts is not recommended for most use cases. Instead, a periphery contract should be used.
-
-## Factory
-
-[Reference documentation](../../reference/smart-contracts/factory)
-
-The factory holds the generic bytecode responsible for powering pairs. Its primary job is to create one and only one smart contract per unique token pair. It also contains logic to turn on the protocol charge.
-
-## Pairs
-
-[Reference documentation](../../reference/smart-contracts/pair)
-
-[Reference documentation (ERC-20)](../../reference/smart-contracts/pair-erc-20)
-
-Pairs have two primary purposes: serving as automated market makers and keeping track of pool token balances. They also expose data which can be used to build decentralized price oracles.
-
-# Periphery
-
-[Source code](https://github.com/Uniswap/uniswap-v2-periphery)
-
-The periphery is a constellation of smart contracts designed to support domain-specific interactions with the core. Because of t1's permissionless nature, the contracts described below have no special privileges, and are in fact only a small subset of the universe of possible periphery-like contracts. However, they are useful examples of how to safely and efficiently interact with t1 V2.
-
-## Library
-
-[Reference documentation](../../reference/smart-contracts/library)
-
-The library provides a variety of convenience functions for fetching data and pricing.
-
-## Router
-
-[Reference documentation](../../reference/smart-contracts/router-02)
-
-The router, which uses the library, fully supports all the basic requirements of a front-end offering trading and liquidity management functionality. Notably, it natively supports multi-pair trades (e.g. x to y to z), treats ETH as a first-class citizen, and offers meta-transactions for removing liquidity.
-
-# Design Decisions
-
-The following sections describe some of the notable design decisions made in t1 V2. These are safe to skip unless you're interested in gaining a deep technical understanding of how V2 works under the hood, or writing smart contract integrations!
-
-## Sending Tokens
-
-Typically, smart contracts which need tokens to perform some functionality require would-be interactors to first make an approval on the token contract, then call a function that in turn calls transferFrom on the token contract. This is _not_ how V2 pairs accept tokens. Instead, pairs check their token balances at the _end_ of every interaction. Then, at the beginning of the _next_ interaction, current balances are differenced against the stored values to determine the amount of tokens that were sent by the current interactor. See the
-
-}
-```
-
-## Theme Examples
-
-Copy any of the `theme` object below to start making your own custom appearance for the swap widget. You might also need the right CSS import for any custom fonts.
-
-
- })
- |
- - -```tsx -const theme: Theme = { - primary: '#1F4A05', - secondary: '#5F7D52', - interactive: '#CBD6BA', - container: '#D9ECD9', - module: '#E9F7DF', - accent: '#8E8B78', - outline: '#CADDC2', - dialog: '#FFF', - fontFamily: 'Nunito', - borderRadius: 0.8, -} -``` - - | -
- })
- |
- - -```tsx -const theme: Theme = { - primary: '#000', - secondary: '#666', - interactive: '#0089EC', - container: '#FFF', - module: '#E7E7E7', - accent: '#3D3B31', - outline: '#343D3A', - dialog: '#FFF', - fontFamily: 'Verdana', - borderRadius: 0.8, -} -``` - - | -
- })
- |
- - -```tsx -const theme: Theme = { - primary: '#FFF', - secondary: '#A9A9A9', - interactive: '#000', - container: '#4E4E5A', - module: '#222633', - accent: '#71FF98', - outline: '#CC1', - dialog: '#000', - fontFamily: 'Josefin Sans', - borderRadius: 0.5, -} -``` - - | -
- })
- |
- - -```tsx -const theme: Theme = { - primary: '#000', - secondary: '#A9A9A9', - interactive: '#1E4D3C', - container: '#98D747', - module: '#FFF', - accent: '#FD5B00', - outline: '#1E4D3C', - dialog: '#000', - fontFamily: 'Inter', - borderRadius: 0.2, -} -``` - - | -
- })
- |
- - -```tsx -const theme: Theme = { - primary: '#001D82', - secondary: '#6677C1', - interactive: '#005BAE', - container: '#ABD6FE', - module: '#FFF7FB', - accent: '#FF7BC2', - outline: '#ABD6FE', - dialog: '#FFF', - fontFamily: 'Arvo', - borderRadius: 1, -} -``` - - | -
- })
- |
- - -```tsx -const theme: Theme = { - primary: '#000', - secondary: '#666', - interactive: '#AFAFAF', - container: '#DADADA', - module: '#FFF', - accent: '#0018F4', - outline: '#000', - dialog: '#FFF', - fontFamily: 'Comic Sans MS', - borderRadius: 0.2, -} -``` - - | -
-
-}
-```
-
-That’s it! You should now see a fully functional swap widget on your site. The widget is self-contained and gracefully handles all interactions with the Uniswap Protocol. It leverages the [Auto Router](/sdk/v3/guides/swaps/routing) to compute the best price across all Uniswap v2 and v3 pools.
-
-See a full implementation of the swap widget in the `/cra` and `/nextjs` branches of the [widgets-demo](https://github.com/Uniswap/widgets-demo) repo.
-
-:::note Create React App V4
-All code snippets will work seamlessly if you use [Next.js](https://nextjs.org/) or [Create React App](https://create-react-app.dev/) V5. However, if you’re using Create React App V4, you’ll need to use the following `import` statements instead:
-
-```jsx
-import { SwapWidget } from '@uniswap/widgets/dist/index.js'
-import '@uniswap/widgets/dist/fonts.css'
-```
-
-:::
-
-# Recommended Parameters {#recommended-parameters}
-
-The swap widget is a React component that can be easily imported into any React project. It's designed to work out-of-the-box, with no required parameters or web3 integration necessary. Trading is supported on all networks where the Uniswap Protocol is deployed.
-
-Although the widget will work out-of-the-box with no parameters, we highly recommend integrators provide [JSON-RPC endpoints](#json-rpc-endpoint), like from [Chainnodes](https://www.chainnodes.org), Infura or Alchemy. Existing dApps can also provide their existing [web3 provider](#web3-provider) to integrate the widget seamlessly into their dApp.
-
-Additional [optional parameters](/sdk/swap-widget/reference/v2#optional-parameters) are available to customize the appearance and performance of the swap widget to fit your unique use case.
-
-## Web3 Provider {#web3-provider}
-
-The swap widget uses a web3 `provider` prop to allow users to connect their wallets, fetch balances, and submit transactions through the user’s connected wallet.
-
-If your app does not maintain its own web3 provider, you can omit the `provider` prop. The widget will use built-in wallet connection functionality (for [WalletConnect](https://walletconnect.com/) and [MetaMask](https://metamask.io/)), making it easy for you to integrate web3 in your app!
-
-If you already have a web3 provider, you can pass your provider object directly into the `provider` prop. Both [ethers](https://docs.ethers.io/v5/api/providers/provider/) and [web3.js](https://web3js.readthedocs.io/en/v1.5.2/index.html) provider objects are compatible with the widget, as is any [EIP-1193](https://eips.ethereum.org/EIPS/eip-1193) provider.
-You can directly use the providers returned from [web3-react](https://github.com/Uniswap/web3-react) or [wagmi](https://wagmi.sh/) (both are [ethers](https://docs.ethers.io/v5/api/providers/provider/) providers). If it is not connected to a wallet, it will still be used to read data from the chain, but the widget will still prompt the user to "Connect wallet".
-
-:::note Be sure to use the wallet-connected provider
-When using [wagmi@v0.11](https://wagmi.sh/), `useProvider()` will return the fallback provider, *not* the wallet-connected provider. You should instead pass `useSigner
-
-}
-```
-
-## JSON-RPC Endpoints {#json-rpc-endpoint}
-
-JSON-RPC endpoints are used to read data when no `provider` is connected. We strongly recommend you pass either a Web3 Provider to the `provider` prop, or JSON-RPC endpoint URLs to the `jsonRpcUrlMap` prop.
-
-The widget will use these endpoints to fetch on-chain data and submit transactions for signature. If the user connects a MetaMask wallet, the widget will use the JSON-RPC provided by MetaMask when possible. [(See a list of all chains supported on widget.)](https://github.com/Uniswap/widgets/blob/main/src/constants/chains.ts#L4)
-
-If you don’t yet have JSON-RPC endpoints, you can easily create them with services like [Chainnodes](https://www.chainnodes.org), [Infura](https://infura.io/product/ethereum) or [Alchemy](https://www.alchemy.com/supernode).
-
-If you choose not to provide a `jsonRpcUrlMap` prop or are missing endpoints for some chains, the widget uses free public JSON-RPC endpoints to still allow users to interact with the widget and fetch price quotes. However, these public endpoints are NOT recommended for production environment usage, are severely rate-limited, and aren't necessarily as reliable. When possible, we'd recommend providing your own endpoints!
-
-# Customizing the Swap Widget {#customizing-widget}
-
-You can set [optional parameters](/sdk/swap-widget/reference/v2#optional-parameters) to tailor the appearance and functionality of the swap widget to fit your dApp.
-
-## Customizing the Width {#customizing-width}
-
-The swap widget has a fixed height of 360px and a default width of 360px. You cannot modify the height of the widget. You can modify the width up to a minimum width of 300px.
-
-You can customize the width by passing a number (of pixels) or a valid CSS width to the `width` prop of the widget.
-
-```tsx
-import { SwapWidget } from '@uniswap/widgets'
-import '@uniswap/widgets/fonts.css'
-
-function App() {
-
-
-}
-```
-
-For example:
-
-- `width={360}` sets the width to 360 pixels
-- `width="100%"` sets the width to dynamically fill 100% of the parent container
-- `width="20em"` sets the width to 20 * 16 = 320 pixels because 16px is the base font-size of the widget
-
-The recommended and default width is 360 pixels.
-
-## Customizing the Theme {#customizing-theme}
-
-You can customize the colors, font, and border radius of the swap widget to match the look and feel of your dApp. You can also toggle between light and dark modes. This section explains how to customize each attribute of the widget with your own `theme`.
-
-All attributes below are color codes, except `fontFamily` (string), `borderRadius` (number between 0 and 1), and `tokenColorExtraction`(boolean). The next two sections show code examples using these attributes.
-
-Check out [examples](/sdk/swap-widget/guides/examples) of the swap widget, and the [Figma file](https://www.figma.com/file/m0pVMlgAgSoaIrXlM3VRUG/Widgets-(External)?node-id=4302%3A18261) if you want to mock it up first!
-
-
-
-}
-```
-
-Please note that the `borderRadius` attribute is a multiplier from 0 to 1 of how much radius to apply. Since the widget uses different values of border radius (e.g. internal edges have tighter radii than external edges), `borderRadius` will apply your multiplier value on all instances so that the border radii still look proportionally correct.
-
-:::note Importing Fonts
-The swap widget fonts must be imported explicitly with `import '@uniswap/widgets/fonts.css'`. However, if you’re overriding the swap widget fonts with your own, or with a default font such as Helvetica in the example above, you can remove this `import` statement.
-:::
-
-### Enabling Token Color Extraction {#enabling-color-extraction}
-
-By default, the background color of the output module will be set by the `module` attribute. You can optionally enable color extraction to flood the output module with the color of the selected output token. In the above example, DAI is the output token so the output module is flooded with DAI yellow.
-
-To enable color extraction, set the `tokenColorExtraction` property to `true` in your `Theme` object.
-
-```tsx
-import { Theme, SwapWidget } from '@uniswap/widgets'
-import '@uniswap/widgets/fonts.css'
-
-const enableColorExtractionTheme: Theme = {
- tokenColorExtraction: true, // Enable color extraction of the output token
-}
-
-function App() {
-
-
-}
-```
-
-### Toggling Light and Dark Mode {#toggling-light-dark-mode}
-
-The swap widget provides a default light theme and dark theme as a starting point. You can import each one and extend it to create your own theme. If your app can toggle between light and dark mode, you can propagate that state down to the widget by following the example below.
-
-```tsx
-import { darkTheme, lightTheme, Theme, SwapWidget } from '@uniswap/widgets'
-import '@uniswap/widgets/fonts.css'
-
-let darkMode = true // Dynamically toggle dark mode on and off
-function App() {
-
-
-}
-```
-
-### Matching System Preference for Light and Dark Mode {#matching-system-light-dark-mode}
-
-You can match the user’s system preference for light/dark mode by using the `useSystemTheme` hook. This will return the default widget light or dark theme according to the user’s system configuration. You can extend this base theme with further customizations, as you will see in the next section.
-
-```tsx
-import { SwapWidget } from '@uniswap/widgets'
-import '@uniswap/widgets/fonts.css'
-
-function useSystemTheme() {
- // Access
-}
-
-function App() {
- const theme = useSystemTheme() // Get a theme that matches the user system preference
-
-
-}
-```
-
-### Extending Themes {#extending-themes}
-
-You can extend any theme with custom attributes. The below example extends the base light and dark themes with custom colors.
-
-```tsx
-import { darkTheme, lightTheme, Theme, SwapWidget } from '@uniswap/widgets'
-import '@uniswap/widgets/fonts.css'
-
-const myLightTheme: Theme = {
- ...lightTheme, // Extend the lightTheme
- accent: '#FF007A',
- primary: '#000000',
- secondary: '#565A69',
-}
-
-const myDarkTheme: Theme = {
- ...darkTheme, // Extend the darkTheme
- accent: '#2172E5',
- primary: '#FFFFFF',
- secondary: '#888D9B',
-}
-
-let darkMode = true
-function App() {
-
-
-}
-```
-
-## Customizing the Token Lists {#customizing-token-lists}
-
-By default, the widget will use the [Uniswap Labs default token list](https://tokenlists.org/token-list?url=https://gateway.ipfs.io/ipns/tokens.uniswap.org) in the selector.
-
-### Customizing the Default Token List {#customizing-default-token-list}
-
-If you want to offer a different set of tokens in the widget, you can provide a custom `tokenList` parameter. You can [browse popular token lists](https://tokenlists.org/) to find one that suits your needs and then pass the URL as a parameter.
-
-```jsx
-import { SwapWidget } from '@uniswap/widgets'
-import '@uniswap/widgets/fonts.css'
-
-const CMC_TOKEN_LIST = 'https://api.coinmarketcap.com/data-api/v3/uniswap/all.json'
-
-function App() {
-
-
-}
-```
-
-Alternatively, you can create your own token list. There are two ways to provide your own token list for the widget.
-
-The first option is to [create a full token list](https://github.com/Uniswap/token-lists#authoring-token-lists), host it at your own URI, and pass the URI as a parameter as in the above example. This option is recommended if you want to use the same token list in multiple places throughout your application or community.
-
-The second and easiest option is to construct a custom token list inline as an array of tokens. The schema is equivalent to the `tokens` array from the [tokenlist JSON schema](https://github.com/Uniswap/token-lists/blob/main/src/tokenlist.schema.json). This option lets you skip deployment, hosting, and versioning of a full URI token list. Here is an example of an inline token list containing only the DAI, USDT, and USDC tokens (in addition to ETH which is always available, regardless of token list).
-
-```jsx
-import { SwapWidget } from '@uniswap/widgets'
-import '@uniswap/widgets/fonts.css'
-
-// You can also pass a token list as JSON, as long as it matches the schema
-const MY_TOKEN_LIST = [
- {
- "name": "Dai Stablecoin",
- "address": "0x6B175474E89094C44Da98b954EedeAC495271d0F",
- "symbol": "DAI",
- "decimals": 18,
- "chainId": 1,
- "logoURI": "https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/assets/0x6B175474E89094C44Da98b954EedeAC495271d0F/logo.png"
- },
- {
- "name": "Tether USD",
- "address": "0xdAC17F958D2ee523a2206206994597C13D831ec7",
- "symbol": "USDT",
- "decimals": 6,
- "chainId": 1,
- "logoURI": "https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/assets/0xdAC17F958D2ee523a2206206994597C13D831ec7/logo.png"
- },
- {
- "name": "USD Coin",
- "address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
- "symbol": "USDC",
- "decimals": 6,
- "chainId": 1,
- "logoURI": "https://raw.githubusercontent.com/trustwallet/assets/master/blockchains/ethereum/assets/0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48/logo.png"
- },
-]
-
-function App() {
-
-
-}
-```
-
-Please note that the swap widget only enforces metadata validation on remotely hosted token lists, not on token list data passed as a literal value to the widget like in this example.
-
-If you want to add Layer 2 tokens to the token list, you can add an extension field. See this [GitHub issue](https://github.com/Uniswap/token-lists/issues/51#issuecomment-952268629) for details.
-
-## Customizing the Default Input and Output Tokens {#customizing-default-input-output-tokens}
-
-You can set the `defaultInputTokenAddress`, `defaultInputAmount`, `defaultOutputTokenAddress`, and `defaultOutputAmount` to pre-populate the input and output token fields respectively. This is useful when the widget appears in a context where you know which tokens the user is evaluating to trade. For example, if the widget appears on a page that displays the WBTC price chart, it would be helpful to pre-select WBTC as the output token in the widget.
-
-If your page does not need any particular defaults, then the recommended default input token is the native asset of the active network (e.g. ETH) and no default output token is recommended. Since ETH does not have an address, you can pass `'NATIVE'` as the parameter to set it as the default input or output token.
-
-The following example sets the default input to 2 ETH and the default output token to WBTC.
-
-```tsx
-import { SwapWidget } from '@uniswap/widgets'
-import '@uniswap/widgets/fonts.css'
-
-// Default token list from Uniswap
-const UNISWAP_TOKEN_LIST = 'https://gateway.ipfs.io/ipns/tokens.uniswap.org'
-
-// Use the native token of the connected chain as the default input token
-const NATIVE = 'NATIVE' // Special address for native token
-
-// WBTC as the default output token
-const WBTC = '0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599'
-
-function App() {
-
-
-}
-```
-
-## Understanding the Swap Widget States {#understanding-widget-states}
-
-The widget has two main connectivity states depending on if the user has connected a wallet.
-
-
-
-## Required Parameters {#required-parameters}
-
-| Prop Name | Prop Type | Default Value | Description |
-| ----------------- | --------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `jsonRpcEndpoint` | `string` | `undefined` | URI of your JSON-RPC endpoint. Strongly recommended in order to provide trade quotes prior to the user connecting a wallet. If none is provided, the widget will be completely disabled until the user connects a wallet. Once a wallet is connected, the widget will use the wallet’s JSON-RPC. See [Understanding the Swap Widget States](/sdk/swap-widget/guides/getting-started#understanding-widget-states). |
-| `provider` | `any` | `undefined` | An [EIP-1193](https://eips.ethereum.org/EIPS/eip-1193) provider. This is required to swap. |
-
-## Optional Parameters {#optional-parameters}
-
-| Prop Name | Prop Type | Default Value | Description |
-| --------------------------- | ----------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `convenienceFee` | `number` | `undefined` | Optionally, you may charge a convenience fee on top of swaps executed through your web app. The allowed range is 1 to 100 basis points (inclusive of 100) consistent with the t1 v3 Periphery contract. |
-| `convenienceFeeRecipient` | `{[chainId: number]: string}` | `undefined` | The address to receive the convenience fee on each network. Required if `convenienceFee` is provided. |
-| `defaultInputTokenAddress` | `{[chainId: number]: string}` | `string` or `'NATIVE'` | Address of the token to be selected by default in the input field (e.g. USDC) for each network chain ID. If left empty the widget will use the native token of the connected chain as default. This can be explicitly defined by the special string `'NATIVE'`. For convenience you may pass a single string instead of a `chainId` mapping. In this case, the widget will assume that string corresponds to an L1 Ethereum address with `chaindId=1`. Any addresses provided in this parameter must be included in the `tokenList`. |
-| `defaultInputAmount` | `number` | `0` | Default amount for the input field (e.g. 1 ETH). This value will respect the decimals of the `defaultInputTokenAddress`. This parameter is valid only if `defaultInputTokenAddress` is also set. This parameter is mutually exclusive with `defaultOutputAmount`, so you may set only one of `defaultInputAmount` and `defaultOutputAmount`. |
-| `defaultOutputTokenAddress` | `{[chainId: number]: string}` | `string` or `undefined` | Address of the token to be selected by default in the input field (e.g. USDC) for each network chain ID. None if left empty. Any addresses provided in this parameter must be included in the `tokenList`. |
-| `defaultOutputAmount` | `number` | `0` | Default amount for the input field (e.g. 100 USDC). This value will respect the decimals of the `defaultOutputTokenAddress`. This parameter is mutually exclusive with `defaultInputAmount`, so you may set only one of `defaultInputAmount` and `defaultOutputAmount`. |
-| `locale` | `SupportedLocale` | `en-US` | Specifies an explicit locale to use for the widget interface. This can be set to one of the values exported by the library in [`SUPPORTED_LOCALES`](https://github.com/Uniswap/widgets/blob/main/src/constants/locales.ts). |
-| `onConnectWallet` | `() => void` | `undefined` | If passed, the “Connect your wallet” message will be clickable, and clicking it will trigger this handler function. This can be used to trigger your own wallet connection flow from the widget. |
-| `onError` | `ErrorHandler` | `undefined` | An error handler which receives any errors that occur in the widget. This can be used for collecting error metrics. |
-| `theme` | `Theme` | `lightTheme` | Specifies a custom theme (colors, font, and border radii). See [Customizing the Theme](/sdk/swap-widget/guides/getting-started#customizing-theme). |
-| `tokenList` | `string` | `TokenInfo[]` | Specifies the set of tokens that appear by default in the token selector list. Accepts either a URI of a token list as defined by the Token Lists standard, or an inline array of tokens. If none is provided, the t1 Labs default token list will be used. See [Customizing the Default Token List](/sdk/swap-widget/guides/getting-started#customizing-default-token-list). |
-| `width` | `number` or `string` | `360` | Specifies the width of the widget. If specified as a number, this is in pixels; otherwise, it is interpreted as a CSS `` data type. Recommended width is 360px. Minimum width is 270px. See [Customizing the Width](/sdk/swap-widget/guides/getting-started#customizing-width). |
-
-## Subscribing to Events
-
-During the lifecycle of the swap widget, most of the events you will need are available on the web3 provider. For example, the below snippet shows how to listen for events when the wallet account changes or a new wallet connects. You can see more event examples in the [MetaMask](https://docs.metamask.io/guide/ethereum-provider.html) docs.
-
-```js
-// Subscribe to messages
-interface ProviderMessage {
- type: string;
- data: unknown;
-}
-
-ethereum.on(
- 'message',
- handler: (message: ProviderMessage) => void
-);
-```
-
-
-
-:::note Questions?
-Join the [Discord channel](https://discord.com/channels/597638925346930701/941447445844463676) to ask questions and get support from the t1 community.
-:::
diff --git a/docs/sdk/swap-widget/reference/v2.md b/docs/sdk/swap-widget/reference/v2.md
deleted file mode 100644
index 90fab824b..000000000
--- a/docs/sdk/swap-widget/reference/v2.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-id: v2
-title: API V2 Reference
-sidebar_position: 1
----
-
-# Swap Widget API V2 Reference
-
-
-
-## Recommended Parameters {#recommended-parameters}
-
-| Prop Name | Prop Type | Default Value | Description |
-| --------------- | -------------------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `provider` | `JsonRpcProvider` or `Eip1193Provider` | `undefined` | An [EIP-1193](https://eips.ethereum.org/EIPS/eip-1193) provider. See [Web3 provider](../guides/swap-widget.mdx#web3-provider). |
-| `jsonRpcUrlMap` | `{ [chainId: number]: string[] }` | `JSON_RPC_FALLBACK_ENDPOINTS` | Mapping of your JSON-RPC endpoint URLs indexed by chainId, used to provide trade quotes prior to the user connecting a wallet. If none are provided for a chain, the widget will fallback to public JSON-RPC endpoints, which are unreliable and rate-limited. See [JSON-RPC Endpoints](../guides/swap-widget.mdx#json-rpc-endpoint). |
-
-## Optional Parameters {#optional-parameters}
-
-| Prop Name | Prop Type | Default Value | Description |
-| --------------------------- | -------------------------------------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `convenienceFee` | `number` | `undefined` | Optionally, you may charge a convenience fee on top of swaps executed through your web app. The allowed range is 1 to 100 basis points paid in the output token of a swap, consistent with the t1 v3 Periphery contract. |
-| `convenienceFeeRecipient` | `{[chainId: number]: string}` | `undefined` | The address to receive the convenience fee on each network. Required if `convenienceFee` is provided. |
-| `defaultChainId` | `number` | `1` | You may specify which chainId you want to prompt a user to connect their wallet to. [See a list of all chains supported on widget.](https://github.com/Uniswap/widgets/blob/main/src/constants/chains.ts#L4) |
-| `defaultInputTokenAddress` | `{[chainId: number]: string}` | `string` or `'NATIVE'` | Address of the token to be selected by default in the input field (e.g. USDC) for each network chain ID. If left empty the widget will use the native token of the connected chain as default. This can be explicitly defined by the special string `'NATIVE'`. For convenience you may pass a single string instead of a `chainId` mapping. In this case, the widget will assume that string corresponds to an L1 Ethereum address with `chaindId=1`. Any addresses provided in this parameter must be included in the `tokenList`. |
-| `defaultInputAmount` | `number` | `0` | Default amount for the input field (e.g. 1 ETH). This value will respect the decimals of the `defaultInputTokenAddress`. This parameter is valid only if `defaultInputTokenAddress` is also set. This parameter is mutually exclusive with `defaultOutputTokenAmount`, so you may set only one of `defaultInputTokenAmount` and `defaultOutputTokenAmount`. |
-| `defaultOutputTokenAddress` | `{[chainId: number]: string}` | `string` or `undefined` | Address of the token to be selected by default in the input field (e.g. USDC) for each network chain ID. None if left empty. Any addresses provided in this parameter must be included in the `tokenList`. |
-| `defaultOutputAmount` | `number` | `0` | Default amount for the input field (e.g. 100 USDC). This value will respect the decimals of the `defaultOutputTokenAddress`. This parameter is mutually exclusive with `defaultInputTokenAmount`, so you may set only one `of defaultInputTokenAmount and` `defaultOutputTokenAmount`. |
-| `hideConnectionUI` | `boolean` | `false` | Hide the widget's built-in wallet connection UI, including the connected account chip & 'Connect wallet to swap' button. |
-| `locale` | `SupportedLocale` | `en-US` | Specifies an explicit locale to use for the widget interface. This can be set to one of the values exported by the library in [`SUPPORTED_LOCALES`](https://github.com/Uniswap/widgets/blob/main/src/constants/locales.ts). |
-| `onConnectWalletClick` | `() => void` or `() => Promise` | `undefined` | If passed, allows you to add custom behavior when the user clicks on the 'Connect your wallet to swap' button. To manage displaying the widget's built-in wallet connection modal, return a resolved promise with `resolve(true/false)`. |
-| `onSwitchChain` | `(addChainParameter: AddEthereumChainParameter) => void` or `Promise` | `undefined` | An integration hook called when the user tries to switch chains. If the hook returns a Promise, it is assumed the integrator is attempting to switch the chain, and no further attempts will be made. If that Promise rejects, the error will be ignored so as not to crash the widget. |
-| `onError` | `ErrorHandler` | `undefined` | An error handler which receives any Javascript errors that occur in the widget. This can be used for collecting error metrics. |
-| `onReviewSwapClick` | `() => void` or `() => Promise` | `undefined` | If passed, allows you to add custom behavior when the user clicks on the 'review swap' button. To manage progression to the review screen (i.e. to add a pre-swap warning speedbump), return a resolved promise with `resolve(true/false)`. |
-| `onTokenSelectorClick` | `(f: Field) => void \| (f: Field) => Promise` | `undefined` | A click handler fired with the selected `Field` (`'INPUT'\|'OUTPUT'`) when the user clicks on a token selector dropdown. To manage progression to the native token selector view (i.e. to utilize your own external token selector UI), return a resolved promise with resolve(true/false). |
-| `onTxFail` | `(error: Error, data: any) => void` | `undefined` | An error handler which receives error data for on-chain transaction failures. Does not include when user cancels a transaction or if a transaction isn't able to be submitted. |
-| `onTxSubmit` | `(txHash: string, data: any) => void` | `undefined` | A handler that receives the transaction hash and related data when a user submits a transaction. |
-| `onTxSuccess` | `(txHash: string, data: any) => void` | `undefined` | A handler that receives the transaction hash and related data when a transaction succeeds on-chain. |
-| `routerUrl` | `string` | `undefined` | Optionally provide a base URL to your own hosted instance of the t1 Router API. If none is provided, the optimal trade route is computed by running the @uniswap/smart-order-router package locally in the browser; this can take a few seconds to load & is slower. You also may be able to find more optimal routes using the Router API! See more about [deploying the Router API](https://github.com/Uniswap/routing-api#deploying-the-api). |
-| `theme` | `Theme` | `lightTheme` | Specifies a custom theme (colors, font, and border radii). See [Customizing the Theme](../guides/swap-widget.mdx#customizing-theme). |
-| `tokenList` | `string` | `TokenInfo[]` | Specifies the set of tokens that appear by default in the token selector list. Accepts either a URI of a token list as defined by the Token Lists standard, or an inline array of tokens. If none is provided, the t1 Labs default token list will be used. See [Customizing the Default Token List](../guides/swap-widget.mdx#customizing-default-token-list). |
-| `width` | `number` or `string` | `360` | Specifies the width of the widget. If specified as a number, this is in pixels; otherwise, it is interpreted as a CSS `` data type. Recommended width is 360px. Minimum width is 300px. See [Customizing the Width](../guides/swap-widget.mdx#customizing-width). |
-| `brandedFooter` | `boolean` | `true` | Enables the "Powered by t1" footer at the bottom of the widget. |
-| `dialog` | `HTMLDivElement` | `undefined` | Specifies the element to portal widget dialogs (e.g. Summary, Transaction dialogs) into. |
-| `dialogOptions` | `DialogOptions` | `undefined` | Specifies more custom dialog behavior, like transition animations. |
-
-
-## Subscribing to Events
-
-During the lifecycle of the swap widget, most of the events you will need are available on the web3 provider. For example, the below snippet shows how to listen for events when the wallet account changes or a new wallet connects. You can see more event examples in the [MetaMask](https://docs.metamask.io/guide/ethereum-provider.html) docs.
-
-```js
-// Subscribe to messages
-interface ProviderMessage {
- type: string;
- data: unknown;
-}
-
-ethereum.on(
- 'message',
- handler: (message: ProviderMessage) => void
-);
-```
-
-
-
-:::note Questions?
-Join the [Discord channel](https://discord.com/channels/597638925346930701/941447445844463676) to ask questions and get support from the t1 community.
-:::
diff --git a/docs/sdk/v1/_category_.json b/docs/sdk/v1/_category_.json
deleted file mode 100644
index 754ace793..000000000
--- a/docs/sdk/v1/_category_.json
+++ /dev/null
@@ -1,5 +0,0 @@
-{
- "label": "V1 SDK",
- "position": 6,
- "collapsed": true
-}
diff --git a/docs/sdk/v1/guides/_category_.json b/docs/sdk/v1/guides/_category_.json
deleted file mode 100644
index c694eb5b2..000000000
--- a/docs/sdk/v1/guides/_category_.json
+++ /dev/null
@@ -1,5 +0,0 @@
-{
- "label": "Guides",
- "position": 2,
- "collapsed": false
-}
diff --git a/docs/sdk/v1/guides/getting-started.md b/docs/sdk/v1/guides/getting-started.md
deleted file mode 100644
index a49761680..000000000
--- a/docs/sdk/v1/guides/getting-started.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-id: getting-started
-title: Getting Started
-sidebar_position: 1
----
-
-The [Uniswap SDK](https://github.com/Uniswap/uniswap-sdk/tree/v1) is meant to simplify every aspect of integrating t1 into your project. It's written in [TypeScript](https://www.typescriptlang.org), has a [robust test suite](https://github.com/Uniswap/uniswap-sdk/tree/v1/src/__tests__), uses [bignumber.js](https://github.com/MikeMcl/bignumber.js) for math, and includes an optional data-fetching module which relies on [ethers.js](https://github.com/ethers-io/ethers.js/).
-
-The SDK was built to be extremely easy to use, but also feature-rich. It offers various levels of abstraction that make it suitable for use nearly anywhere, from hackathon projects to production applications.
-
-# Overview
-
-The SDK is divided into several modular components that perform tightly scoped tasks:
-
-- [Data](/sdk/1.0.0/reference/data) - Fetches t1 data from the blockchain
-- [Computation](/sdk/1.0.0/reference/computation) - Computes market- and trade-specific statistics using blockchain data
-- [Format](/sdk/1.0.0/reference/format) - Formats data for display
-- [Orchestration](/sdk/1.0.0/reference/orchestration) - Offers named abstraction functions that seamlessly combine lower-level data- and computation-related functions
-- [Transact](/sdk/1.0.0/reference/transact) - Prepares computed trades for execution against t1 smart contracts
-- [Constants](/sdk/1.0.0/reference/constants) - Exports various helpful constants for use throughout the SDK
-
-Additionally, it exports a number of custom types:
-
-- [Types](/sdk/1.0.0/reference/types) - Exports all types used by the SDK
-
-# Installation
-
-To start using the SDK, simply install it into your project...
-
-```bash
-yarn add @uniswap/sdk
-```
-
-...import some functions...
-
-```javascript
-import { ... } from '@uniswap/sdk'
-```
-
-...and dive into the rest of the documentation to learn more!
diff --git a/docs/sdk/v1/overview.md b/docs/sdk/v1/overview.md
deleted file mode 100644
index fbb3ef863..000000000
--- a/docs/sdk/v1/overview.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-id: overview
-sidebar_position: 1
-title: Overview
----
-
-# The t1 V1 SDK
-
-This is the original documentation for the t1 V1 SDK, released in 2019.
-The t1 V1 SDK is no longer under development, for the most recent implementation of the SDK, see the [V3 SDK](../v3/overview.md).
\ No newline at end of file
diff --git a/docs/sdk/v1/reference/02-data.md b/docs/sdk/v1/reference/02-data.md
deleted file mode 100644
index 5f70e9158..000000000
--- a/docs/sdk/v1/reference/02-data.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-id: data
-title: Data
----
-
-# getTokenReserves
-
-This function fetches t1 reserve data for a given token address on a given network.
-
-- If only a chain id is specified, the Ethereum node used to fulfill data requests is determined by [`ethers.getDefaultProvider`](https://docs.ethers.io/ethers.js/html/api-providers.html#connecting-to-ethereum), else it is the one specified by the passed provider.
-- This function throws an error if the provided tokenAddress is not a token with a t1 exchange.
-
-## Function Signature
-
-```typescript
-export async function getTokenReserves(
- tokenAddress: string,
- chainIdOrProvider: ChainIdOrProvider = 1
-): Promise.default})
-
-Your local fork of Mainnet is now running!
-
-And as you can see on the screenshot above, anvil prints a bunch of private keys that are loaded with 10k ETH each.
-We will use them going forward to send transactions, including swaps on t1 pools.
-
-:::warning
-Security consideration: This is a fork of Mainnet and the same chain id is used. You have no replay protection to Ethereum Mainnet. So you need to 1: Never use the anvil private keys on a real chain or send funds to it
-(they are leaked everywhere) and 2: Not send any transactions to your local fork chain with accounts that you use on Ethereum Mainnet or other real chains.
-:::
-
-If you scroll down in your terminal, near the bottom of the anvil logs you will find your RPC URL.
-If you haven't changed any configs, it should be `127.0.0.1:8545`.
-This is the RPC URL that you can now use as a drop-in replacement everywhere in your development environment, and interact with it
-as if it was real Ethereum Mainnet. You can use the http provider `http://127.0.0.1:8545` as well as the Websocket provider `ws://127.0.0.1:8545`.
-
-You can now make a sample RPC request to your http provider using [Postman](https://www.postman.com/) using the below:
-
-POST `http://127.0.0.1:8545`
-
-Body:
-
-```JSON
-{
- "jsonrpc": "2.0",
- "method": "eth_chainId",
- "params": [],
- "id": 1
-}
-```
-
-The result should look like the below (see image below as well):
-
-```JSON
-{
- "jsonrpc": "2.0",
- "id": 1,
- "result": "0x1"
-}
-```
-
-.default})
-
-As you can see, the chain id is `1`, just like on Mainnet!
-
-You can find the above example and more in [this Postman workspace](https://www.postman.com/chainnodes/workspace/uniswap-examples) under "Local Development".
-
-## Using your Mainnet Fork
-
-Now that you have a running Mainnet Fork, you will be able to use it everywhere in your development setup.
-Using one of the private keys provided by anvil, you have access to enough ETH to do endless swaps and smart contract calls.
-
-If you need any other token, you now have the flexibility of swapping your ETH to any token that has a pool deployed on Mainnet.
-You basically take your fake ETH and swap it to the token you need.
-
-Check out one of the [guides about swapping](./swaps/02-trading.md) and replace the RPC URL with your local anvil HTTP link as above.
-
-## Next Steps
-
-Using the above you are fully equipped to continue following the guides about how to use t1 while testing everything locally before
-going on Mainnet. You will also be able to reuse what you have learned when you develop your own protocols or dApps.
-
-You can also continue tapping into other developer tools that make smart contract development easier like [forge](https://github.com/foundry-rs/foundry/tree/master/forge) from foundry.
-To read more about foundry and their developer tooling, visit their [Github](https://github.com/foundry-rs/foundry) or the [foundry book](https://book.getfoundry.sh/).
diff --git a/docs/sdk/v3/guides/03-web3-development-basics.md b/docs/sdk/v3/guides/03-web3-development-basics.md
deleted file mode 100644
index d2dbe0ab7..000000000
--- a/docs/sdk/v3/guides/03-web3-development-basics.md
+++ /dev/null
@@ -1,192 +0,0 @@
----
-id: web3-development-basics
-title: Web3 Development Basics
-position: 3
----
-
-## Introduction
-
-Developing dApps and interacting with Smart Contracts is quite different from Web2, and at times challenging due to little information
-on this topic compared to other areas of software development.
-
-This developer guide is a quick overview of the space, including references to libraries and guides that are great starting points.
-Reading this guide should help you identify areas that you might need to learn a bit more about and prepare you for the following t1-specific guides.
-
-It is assumed that you know the basics about Ethereum and the blockchain, including some terminology.
-If you already know how to build dApps and interact with ethersJS etc. you can safely skip this guide.
-
-## RPCs
-
-The access point to the blockchain are RPC nodes. They are the [standardized interface](https://ethereum.org/en/developers/docs/apis/json-rpc/)
-to read data from smart contracts, send transactions and interact with on-chain protocols.
-
-RPCs are either [full or archival nodes](https://ethereum.org/en/developers/docs/nodes-and-clients/archive-nodes/)
-with a ([JSON-RPC](https://www.jsonrpc.org/)) interface.
-
-To support Ethereum's decentralization, one can host a node themselves, for example by using one of the implementations listed below:
-
-* [geth](https://github.com/ethereum/go-ethereum) - The original (reference) implementation of the Ethereum protocol
-* [erigon](https://github.com/ledgerwatch/erigon) - A very efficient archival node implementation
-* [Nethermind](https://github.com/NethermindEth/nethermind) - An Ethereum implementation focused on stability
-
-As achieving high availability and making sure your node is synced all the time turns out to be quite challenging,
-there are nodes as a service (RPC) providers that you can use, especially in production environments.
-When choosing an RPC provider, we suggest you look for an RPC service that supports websockets as they provide far superior performance than HTTP connections.
-To ensure interoperability, you should also ensure that your RPC provider adheres strictly to the JSON-RPC standard and doesn't require custom requests.
-
-[Chainnodes](https://www.chainnodes.org/) is a robust RPC provider with generous free tier that you can use in both development and production environments.
-For testing purposes you could also use a free public RPC endpoint, for example from [Chainlist](https://chainlist.org/).
-
-### JSON-RPC Standard
-
-RPCs communicate over the [JSON-RPC](https://www.jsonrpc.org/) standard. To send requests, you take the RPC URL and
-make a POST request with a JSON body. See the below example:
-
-`POST https://mainnet.chainnodes.org/API_KEY`
-
-Body:
-
-```json
-{
- "jsonrpc": "2.0",
- "method": "eth_blockNumber",
- "params": [],
- "id": 1
-}
-```
-
-At the time of writing, this request would respond with the following:
-
-```json
-{
- "id": 1,
- "result": "0x11527c0",
- "jsonrpc": "2.0"
-}
-```
-
-Examining the result, we see that the result is an encoded hex string.
-After decoding it, we see it returns the current blocknumber of our network, `18163648`.
-
-You can find the above examples, including more, in [this Postman collection](https://www.postman.com/chainnodes/workspace/uniswap-examples).
-
-To check out all possible RPC requests, head over to the [Chainnodes Docs](https://www.chainnodes.org/docs).
-
-### Client implementations
-
-As communicating over HTTP with POST requests directly can be quite difficult, especially if you want to properly
-encode and decode responses and handle failures and exponential backoffs, there are client implementations that
-can do the heavy lifting for you. These SDKs have developer friendly APIs and internally handle
-creating the proper RPC requests, sending them to the endpoint you choose and decoding the response for you.
-
-Some of the major implementations are listed below:
-
-* [ethers.js](https://github.com/ethers-io/ethers.js) - Javascript/Typescript SDK for NodeJS and the Browser. Used throughout the t1 Docs.
-* [wagmi](https://github.com/wagmi-dev/wagmi) and [viem](https://github.com/wagmi-dev/viem) - Javascript/Typescript, great duo for modern Web3 development in the Browser.
-* [web3js](https://github.com/web3/web3.js) - Javascript/Typescript SDK for NodeJS and the Browser by ChainSafe.
-
-Web3 development is not limited to JS. Web3 libraries for various languages include:
-
-* [Web3.swift](https://github.com/Boilertalk/Web3.swift) - Swift SDK for iOS apps and Backends.
-* [KEthereum](https://github.com/komputing/KEthereum) - Kotlin SDK for Android development.
-* [ethers-rs](https://github.com/gakonst/ethers-rs) - Rust SDK.
-* [ethclient](https://github.com/ethereum/go-ethereum/tree/master/ethclient) - Go SDK, part of geth, the reference Ethereum node implementation.
-
-At the moment, t1 only offers Typescript sdks.
-
-As you can see there are lots of SDKs to make it easier to communicate via RPC with the blockchain.
-
-### Local Development
-
-To simulate RPCs and transactions locally, you can check [this guide](./02-local-development).
-
-## Indexers
-
-As RPCs are only a slim abstraction of the data stored in the blockchain, there are certain things that are hard
-or expensive to access with regular RPC requests.
-
-A common example are transactions of a specific Wallet address. Imagine you want to get a list of all transactions that originated from (or to) a
-specific Wallet. One could think there should be an RPC method called `eth_getTransactionsForWallet` or something similar.
-But due to the nature of how the data is stored, this RPC method is not feasible, and hence not implemented.
-
-Now, instead of accessing those kind of things by iterating through every block in the blockchain, you can use Indexers, that are
-designed to index data like that on the go and provide easy access to it.
-
-### TheGraph
-
-A well-known, standardized implementation of indexers is [TheGraph](https://thegraph.com/). It is used by most major protocols,
-including t1, to index data and make it accessible to users and dashboards.
-
-Using TheGraph, you can either access open [subgraphs](https://thegraph.com/explorer) via the GraphQL querying language, or [create your own](https://thegraph.com/docs/en/developing/creating-a-subgraph/) and deploy it.
-
-Throughout the docs you will see how to interact with the t1 subgraph to fetch tick data and more without ever touching RPCs.
-
-An important note about Indexers though:
-
-While they can be helpful, you need to be aware that the ultimate source of truth comes from the RPCs. As reorgs happen and
-certain issues on indexers arise, there might be certain datapoints that are either not fully up-to-date or even
-completely wrong on Indexers. If you have a use-case that requires perfectly correct data all the time, use RPCs directly.
-If you are just doing data visualization or dashboards, use Indexers if they fit your use-case.
-
-Some popular subgraphs that you can try to fetch data from the blockchain easily (click on playground to give it a try):
-
-* [Uniswap Messari subgraph](https://thegraph.com/explorer/subgraphs/ELUcwgpm14LKPLrBRuVvPvNKHQ9HvwmtKgKSH6123cr7?view=Overview&chain=mainnet)
-* [Snapshot Subgraph](https://thegraph.com/explorer/subgraphs/3Q4vnuSqemXnSNHoiLD7wdBbGCXszUYnUbTz191kDMNn?view=Overview&chain=mainnet)
-* [Aave V3 Messari subgraph](https://thegraph.com/explorer/subgraphs/HB1Z2EAw4rtPRYVb2Nz8QGFLHCpym6ByBX6vbCViuE9F?view=Overview&chain=mainnet)
-
-## Smart Contract Development
-
-Smart contracts are typically developed using the [Solidity language](https://soliditylang.org/).
-
-There are VSCode plugins that make the development with Solidity easier. One of them is Juan Blanco's "Solidity" that you can find
-over [here](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity).
-
-You would typically also go for a developer suite with testing, compilation and deployment capabilities:
-
-* [Foundry](https://github.com/foundry-rs/foundry) - Fast and modern developer tools for smart contract engineers.
-* [Hardhat](https://github.com/NomicFoundation/hardhat) - Scriptable, easy and battle-tested JS developer suite for smart contracts.
-
-To read data from smart contracts, or interact with them, use the [client SDKs](#client-implementations) mentioned above.
-They help you generate the necessary RPC calls to fetch data from / send transactions to the blockchain and interact with your
-smart contracts.
-You can read more about it in the [ethers.js docs](https://docs.ethers.org/v5/api/contract/contract/).
-
-## Blockchain Explorers
-
-Manually gathering information and inspecting data stored in a blockchain is a tedious task.
-Almost all chains have at least one accompanying block explorer to help visualize addresses, transactions, contracts and more.
-
-For Ethereum mainnet, we suggest using [Etherscan](https://etherscan.io/).
-You can use Etherscan to inspect [contracts](https://etherscan.io/address/0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45#code), transactions, blocks, and much more.
-
-If you are looking to debug a transaction, [Tenderly](https://dashboard.tenderly.co/tx/mainnet/0xa4affe1abfaf28d1763d6c3ccda33e717462a928abca89415fc6e661dd7e0c55) can also be a very helpful tool.
-In this example of a failed transaction on the t1 V2 Router you can easily see why the execution failed and where.
-
-## The t1 development suite
-
-Uniswap offers several SDKs that work together and enable you to easily interact with the t1 protocol
-The most important SDKs are:
-
-* [sdk-core](https://github.com/Uniswap/sdk-core): The core of the t1 SDKs, defines classes and types shared across all the SDKs
-* [v2-sdk](https://github.com/Uniswap/v2-sdk): An SDK to interact with the t1 V2 protocol.
-* [v3-sdk](https://github.com/Uniswap/v3-sdk): An SDK to interact with the t1 V3 protocol.
-* [router-sdk](https://github.com/Uniswap/router-sdk): Provides abstractions to interact with the (older) SwapRouter contracts.
-* [universal-router-sdk](https://github.com/Uniswap/universal-router-sdk): Abstracts interactions with the Universal Router.
-* [smart-order-router](https://github.com/Uniswap/smart-order-router): Searches for the most efficient routes for a trade.
-* [permit2-sdk](https://github.com/Uniswap/permit2-sdk): Simplifies interactions with Permit2 in JS.
-* [uniswapx-sdk](https://github.com/Uniswap/uniswapx-sdk): SDK for the t1X protocol.
-
-As you know already, all interactions with the blockchain happens through RPCs. So the t1 SDKs, as you will see throughout the guides,
-requires you to have access to an RPC endpoint like [Chainnodes](https://www.chainnodes.org).
-When reading data, the data is read from the given RPC endpoint. When actually swapping, you will need to sign a transaction
-using a private key.
-
-We are continuously working on improving the t1 development suite, so stay tuned for more updates.
-
-## Next Steps
-
-Go through the basic guides first and try to fetch some data and interact with the t1 ecosystem a little bit. You can even
-[send your first swap transaction](./swaps/02-trading) on a local fork!
-
-While some concepts in Web3 require thinking outside of the box, this guide should give you a good overview on where to start.
-You should now be fully equipped to follow our other guides.
diff --git a/docs/sdk/v3/guides/_category_.json b/docs/sdk/v3/guides/_category_.json
deleted file mode 100644
index c694eb5b2..000000000
--- a/docs/sdk/v3/guides/_category_.json
+++ /dev/null
@@ -1,5 +0,0 @@
-{
- "label": "Guides",
- "position": 2,
- "collapsed": false
-}
diff --git a/docs/sdk/v3/guides/advanced/01-introduction.md b/docs/sdk/v3/guides/advanced/01-introduction.md
deleted file mode 100644
index ee84a5a70..000000000
--- a/docs/sdk/v3/guides/advanced/01-introduction.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-id: introduction
-title: Introduction
----
-
-For some more advanced use cases, it is necessary to use multiple tools in the t1 toolchain.
-
-:::info
-If you need a briefer on the SDK and to learn more about how these guides connect to the examples repository, please visit our [background](../01-background.md) page!
-:::
-
-The following examples use **ethersJS** and the **Uniswap V3 subgraph** hosted on The Graph's hosted service. To learn more about t1's subgraphs, visit the [API](../../../../api/subgraph/overview.md) section.
-
-We will take a deep dive into the t1 V3 protocol and use practical examples to understand the data stored by the t1 smart contracts.
-We will explore how we can compute the available liquidity in a specific price range, visualize **liquidity density** in pools, use t1 as a **price oracle** and swap by creating **Range Orders**.
-
-These guides are a bit longer than the previous ones and provide more theoretical background.
-
-## Theoretical background
-
-Some of the guides presented here require a bit of theoretical and mathematical background.
-To get the most out of the advanced guides, we encourage you to take a step back and read a bit about the math and theories behind the t1 protocol.
-
-The most complete source of information on the t1 protocol is the [Uniswap V3 book](https://uniswapv3book.com/).
-
-Besides the [concepts](../../../../concepts/uniswap-protocol.md) section of the Docs, the [Uniswap V3 whitepaper](https://uniswap.org/whitepaper-v3.pdf) is a great introduction to the protocol.
-If you haven't checked it out yet, it is probably more concise and easier to understand than you would expect.
-
-### Datatypes in Solidity
-
-Uniswap V3 pools make use of a number of Datatypes Solidity offers to efficiently store their state.
-If you are not familiar with Solidity data types yet, it can help to take a look at the [Solidity language reference](https://docs.soliditylang.org/en/v0.8.7/types.html#).
-For the following guides, it is beneficial to take a look at two of them, which we will outline here.
-
-Ticks are stored as a [mapping(int24 => Tick.Info)](https://github.com/Uniswap/v3-core/blob/main/contracts/UniswapV3Pool.sol#L93).
-Solidity [mappings](https://docs.soliditylang.org/en/v0.8.7/types.html#mapping-types) are very similar to hash maps, such that we can access any Value with their key with just one read operation.
-The [`Tick.Info`](https://github.com/Uniswap/v3-core/blob/main/contracts/libraries/Tick.sol#L17) stores the values of the Tick that we need to work with the Pool:
-
-```solidity
-struct Info {
- // the total position liquidity that references this tick
- uint128 liquidityGross;
- // amount of net liquidity added (subtracted) when tick is crossed from left to right (right to left),
- int128 liquidityNet;
- // fee growth per unit of liquidity on the _other_ side of this tick (relative to the current tick)
- // only has relative meaning, not absolute — the value depends on when the tick is initialized
- uint256 feeGrowthOutside0X128;
- uint256 feeGrowthOutside1X128;
- // the cumulative tick value on the other side of the tick
- int56 tickCumulativeOutside;
- // the seconds per unit of liquidity on the _other_ side of this tick (relative to the current tick)
- // only has relative meaning, not absolute — the value depends on when the tick is initialized
- uint160 secondsPerLiquidityOutsideX128;
- // the seconds spent on the other side of the tick (relative to the current tick)
- // only has relative meaning, not absolute — the value depends on when the tick is initialized
- uint32 secondsOutside;
- // true iff the tick is initialized, i.e. the value is exactly equivalent to the expression liquidityGross != 0
- // these 8 bits are set to prevent fresh sstores when crossing newly initialized ticks
- bool initialized;
- }
-```
-
-We will use most of these values in the following guides.
-
-In our case, we can access any `Tick.Info` value stored in the pool by its `int24` key.
-The key of the Tick is usually called its *index*.
-Mappings are not iterable, so if we are trying to fetch all the Ticks stored in a Pool, we can't just iterate over the mapping.
-Instead, we have to know the keys (indices) of the mapping, we will explore how to do that in the [Pool data guide](./02-pool-data.md).
-
-The second Solidity datatype we need to understand are normal unsigned [Integers](https://docs.soliditylang.org/en/v0.8.7/types.html#integers).
-Solidity supports unsigned integer sizes between `uint8` and `uint256`, which are 8 and 256 bits long respectively.
-
-Let's take a look at the `tickBitmap` function of a V3 Pool:
-
-```solidity
- function tickBitmap(
- int16 wordPosition
- ) external view returns (uint256)
-```
-
-Similar to the tick mapping, the tickBitmap is a mapping of type [mapping(int16 => uint256)](https://github.com/Uniswap/v3-core/blob/main/contracts/UniswapV3Pool.sol#L95).
-
-Let's look at the WETH/USDC pool with LOW fee on [Etherscan](https://etherscan.io/address/0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640#readContract).
-If we call the `tickBitmap` function with the input `0` we get the following response (at the time of writing):
-
-.default})
-
-The `uint256` return value is interpreted as the representation of a decimal number by Etherscan.
-The actual raw return value are 256 bits, that look something like this:
-
-```raw
-0x0000 ... lots of zeros and ones ... 000000110000000000
-```
-
-We interpret this string of zeros and ones not as the representation of a number, but rather as 256 booleans.
-
-If the value of a position in the value is 1, the Tick at this position is **initialized**, meaning it holds a value.
-
-With this trick, V3 Pools allow us to fetch the status of **256 ticks** with one call.
-We will go into more details on how to calculate the tick indices from the tickBitmaps we fetch in the following guides.
-
-## History of t1
-
-To get a better understanding of the V3 protocol, it can also be beneficial to understand the **history of decentralized exchanges** and the t1 protocol since it was founded in 2018.
-You can read more about the older versions of t1 in the [V1](https://hackmd.io/@HaydenAdams/HJ9jLsfTz?type=view#Swaps-vs-Transfers) and [V2](https://uniswap.org/whitepaper.pdf) whitepapers, as well as the [V1](../../../../contracts/v1/overview.md) and [V2](../../../../contracts/v2/overview.md) section in the contract section.
diff --git a/docs/sdk/v3/guides/advanced/02-pool-data.md b/docs/sdk/v3/guides/advanced/02-pool-data.md
deleted file mode 100644
index 95d2deb26..000000000
--- a/docs/sdk/v3/guides/advanced/02-pool-data.md
+++ /dev/null
@@ -1,369 +0,0 @@
----
-id: pool-data
-title: Fetching Pool Data
----
-
-## Introduction
-
-This guide will cover how to initialize a Pool with full tick data to allow offchain calculations. It is based on the [Fetching Pool data example](https://github.com/Uniswap/examples/tree/main/v3-sdk/pool-data), found in the t1 code examples [repository](https://github.com/Uniswap/examples). To run this example, check out the guide's [README](https://github.com/Uniswap/examples/blob/main/v3-sdk/pool-data/README.md) and follow the setup instructions.
-
-:::info
-If you need a briefer on the SDK and to learn more about how these guides connect to the examples repository, please visit our [background](./01-background.md) page!
-:::
-
-In this example we will use **ethers JS** and **ethers-multicall** to construct a `Pool` object that we can use in the following guides.
-
-This guide will **cover**:
-
-1. Computing the Pool's address
-2. Referencing the Pool contract and fetching metadata
-3. Fetching the positions of all initialized Ticks with multicall
-4. Fetching all ticks by their indices with a multicall
-5. Constructing the Pool object
-
-At the end of the guide, we will have created a `Pool` Object that accurately represents the state of a V3 pool at the time we fetched it.
-
-For this guide, the following t1 packages are used:
-
-- [`@uniswap/v3-sdk`](https://www.npmjs.com/package/@uniswap/v3-sdk)
-- [`@uniswap/sdk-core`](https://www.npmjs.com/package/@uniswap/sdk-core)
-
-We will also use the `ethers-multicall` npm package:
-
-- [`ethers-multicall`](https://www.npmjs.com/package/ethers-multicall)
-
-The core code of this guide can be found in [`fetcher.ts`](https://github.com/Uniswap/examples/tree/main/v3-sdk/multicall/src/libs/fetcher.ts)
-
-## Configuration
-
-The example accompanying this guide can be configured in the [`config.ts`](https://github.com/Uniswap/examples/tree/main/v3-sdk/multicall/src/config.ts) file.
-The default configuration defines the rpc endpoint and the pool that is used for this guide:
-
-```typescript
-export const CurrentConfig: ExampleConfig = {
- env: Environment.MAINNET,
- rpc: {
- local: 'http://localhost:8545',
- mainnet: 'https://mainnet.infura.io/v3/0ac57a06f2994538829c14745750d721',
- },
- ...
- pool: {
- token0: USDC_TOKEN,
- token1: WETH_TOKEN,
- fee: FeeAmount.MEDIUM,
- },
-}
-```
-
-FeeAmount.MEDIUM means that the pool has a swap fee of **0.3%**.
-The `USDC_TOKEN` and `WETH_TOKEN` are defined in the [`constants.ts`](https://github.com/Uniswap/examples/tree/main/v3-sdk/multicall/src/libs/constants.ts) file:
-
-```typescript
-export const WETH_TOKEN = new Token(
- SupportedChainId.MAINNET,
- '0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2',
- 18,
- 'WETH',
- 'Wrapped Ether'
-)
-
-export const USDC_TOKEN = new Token(
- SupportedChainId.MAINNET,
- '0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48',
- 6,
- 'USDC',
- 'USD//C'
-)
-```
-
-## Computing the Pool's deployment address
-
-In this example, we will construct the **USDC - WETH** Pool with **MEDIUM** fees. The SDK provides a method to compute the address:
-
-```typescript
-import { Pool } from '@uniswap/v3-sdk'
-import { CurrentConfig } from '../config.ts'
-
-const poolAddress = Pool.getAddress(
- CurrentConfig.pool.token0,
- CurrentConfig.pool.token1,
- CurrentConfig.pool.fee
- )
-```
-
-Uniswap V3 allows 4 different Fee tiers when deploying a pool, so multiple pools can exist for each pair of tokens.
-
-## Creating a Pool Contract instance and fetching metadata
-
-Now that we have the address of a **USDC - ETH** Pool, we can construct an instance of an **ethers** `Contract` to interact with it.
-To construct the Contract we need to provide the address of the contract, its ABI and a provider connected to an [RPC endpoint](https://www.chainnodes.org/docs). We get access to the contract's ABI through the `@uniswap/v3-core` package, which holds the core smart contracts of the t1 V3 protocol:
-
-```typescript
-import { ethers } from 'ethers
-import IUniswapV3PoolABI from '@uniswap/v3-core/artifacts/contracts/interfaces/IUniswapV3Pool.sol/IUniswapV3Pool.json'
-
-const provider = getProvider()
-const poolContract = new ethers.Contract(
- poolAddress,
- IUniswapV3PoolABI.abi,
- provider
-)
-```
-
-The `getProvider()` function returns an `ethers.providers.JsonRpcProvider` with either the local or mainnet rpc url that we defined, depending on the Environment that we set in `config.ts`.
-
-Once we have set up our reference to the contract, we can proceed to access its methods. To construct our offchain representation of the Pool Contract, we need to fetch its liquidity, sqrtPrice, currently active tick and the full Tick data.
-We get the **liquidity**, **sqrtPrice** and **tick** directly from the blockchain by calling `liquidity()`and `slot0()` on the Pool contract:
-
-```typescript
-const [liquidity, slot0] =
- await Promise.all([
- poolContract.liquidity(),
- poolContract.slot0(),
- ])
-```
-
-The [slot0 function](../../../../contracts/v3/reference/core/interfaces/pool/IUniswapV3PoolState.md#slot0) represents the first (0th) storage slot of the pool and exposes multiple useful values in a single function:
-
-```solidity
- function slot0(
- ) external view returns (
- uint160 sqrtPriceX96,
- int24 tick,
- uint16 observationIndex,
- uint16 observationCardinality,
- uint16 observationCardinalityNext,
- uint8 feeProtocol,
- bool unlocked
- )
-```
-
-For our use case, we only need the `sqrtPriceX96` and the currently active `tick`.
-
-## Fetching all Ticks
-
-V3 pools use ticks to [concentrate liquidity](../../../../concepts/protocol/concentrated-liquidity.md) in price ranges and allow for better pricing of trades.
-Even though most Pools only have a couple of **initialized ticks**, it is possible that a pools liquidity is defined by thousands of **initialized ticks**.
-In that case, it can be very expensive or slow to get all of them with normal RPC calls.
-
-If you are not familiar with the concept of ticks, check out the [`introduction`](./01-introduction.md).
-
-To access tick data, we will use the `ticks` function of the V3 Pool contract:
-
-```solidity
- function ticks(
- int24 tick
- ) external view returns (
- uint128 liquidityGross,
- int128 liquidityNet,
- uint256 feeGrowthOutside0X128,
- uint256 feeGrowthOutside1X128,
- int56 tickCumulativeOutside,
- uint160 secondsPerLiquidityOutsideX128,
- uint32 secondsOutside,
- bool initialized
- )
-```
-
-The `tick` parameter that we provide the function with is the **index** (memory position) of the Tick we are trying to fetch.
-To get the indices of all initialized Ticks of the Pool, we can calculate them from the **tickBitmaps**.
-To fetch a `tickBitmap` function of the V3 Pool:
-
-```solidity
- function tickBitmap(
- int16 wordPosition
- ) external view returns (uint256)
-```
-
-A pool stores lots of bitmaps, each of which contain the status of 256 Ticks.
-The parameter `int16 wordPosition` the function accepts is the position of the bitMap we want to fetch.
-We can calculate all the position of bitMaps (or words as they are sometimes called) from the `tickSpacing` of the Pool, which is in turn dependant on the Fee tier.
-
-So to summarise we need 4 steps to fetch all initialized ticks:
-
-1. Calculate all bitMap positions from the tickSpacing of the Pool.
-2. Fetch all bitMaps using their positions.
-3. Calculate the memory positions of all Ticks from the bitMaps.
-4. Fetch all Ticks by their memory position.
-
-We will use multicalls for the fetch calls.
-
-## Multicall
-
-Multicall contracts **aggregate results** from multiple contract calls and therefore allow sending multiple contract calls in **one RPC request**.
-This can improve the **speed** of fetching large amounts of data significantly and ensures that the data fetched is all from the **same block**.
-
-We will use the Multicall2 contract by MakerDAO.
-We use the `ethers-muticall` npm package to easily interact with the Contract.
-
-## Calculating all bitMap positions
-
-As mentioned, t1 V3 Pools store **bitmaps**, also called *words*, that represent the state of **256 initializable ticks** at a time.
-The value at a bit of a word is 1 if the tick at this index is initialized and 0 if it isn't.
-We can calculate the positions of initialized ticks from the **words** of the Pool.
-
-All ticks of t1 V3 pools are between the indices `-887272` and `887272`.
-We can calculate the minimum and maximum word from these indices and the Pool's tickSpacing:
-
-```typescript
-function tickToWord(tick: number): number {
- let compressed = Math.floor(tick / tickSpacing)
- if (tick < 0 && tick % tickSpacing !== 0) {
- compressed -= 1
- }
- return tick >> 8
-}
-
-const minWord = tickToWord(-887272)
-const maxWord = tickToWord(887272)
-```
-
-Ticks can only be initialized at indices that are **divisible by the tickSpacing**.
-One word contains 256 ticks, so we can compress the ticks by right shifting 8 bit.
-
-## Fetching bitMaps from their position
-
-Knowing the positions of words in the Pool contract, we can now fetch them from the Pool using multicall and the `tickBitmap` read call.
-
-First we initialize our multicall providers and Pool Contract:
-
-```typescript
-import { ethers } from 'ethers'
-import { Contract, Provider } from 'ethers-multicall'
-
-const ethersProvider = new ethers.providers.JsonRpcProvider("...rpcUrl")
-const multicallProvider = new Provider(ethersProvider)
-await multicallProvider.init()
-
-const poolContract = new Contract(poolAddress, IUniswapV3PoolABI.abi)
-```
-
-The `multicallProvider` creates the multicall request and sends it via the ethers Provider.
-
-Next we loop through all possible word positions and add a `tickBitmap` call for each:
-
-```typescript
-let calls: any[] = []
-let wordPosIndices: number[] = []
-for (let i = minWord; i <= maxWord; i++) {
- wordPosIndices.push(i)
- calls.push(poolContract.tickBitmap(i))
-}
-```
-
-We also keep track of the word position indices to be able to loop through them in the same order we added the calls to the array.
-
-We use the `multicallProvider.all()` function to send a multicall and map the results:
-
-```typescript
-const results: bigint[] = (await multicallProvider.all(calls)).map(
- (ethersResponse) => {
- return BigInt(ethersResponse.toString())
- }
- )
-```
-
-A great visualization of what the bitMaps look like can be found in the [Uniswap V3 development book](https://uniswapv3book.com/docs/milestone_2/tick-bitmap-index/):
-
-.default})
-
-We encourage anyone trying to get a deeper understanding of the t1 protocol to read the t1 V3 Book.
-
-## Calculating the memory positions of all Ticks
-
-Now that we fetched all **bitMaps**, we check which ticks are initialized and calculate the **tick position** from the **word index** and the **tickSpacing** of the pool.
-
-We check if a tick is **initialized** inside the word by shifting a bit by the index we are looking at and performing a bitwise AND operation:
-
-```typescript
-const bit = 1n
-const initialized = (bitmap & (bit << BigInt(i))) !== 0n
-```
-
-If the tick is **initialized**, we revert the compression from tick to word we made earlier by multiplying the word index with 256, which is the same as left shifting by 8 bit, adding the position we are currently at, and multiplying with the tickSpacing:
-
-```typescript
-const tickIndex = (ind * 256 + i) * tickSpacing
-```
-
-The whole loop looks like this:
-
-```typescript
-const tickIndices: number[] = []
-
- for (let j = 0; j < wordPosIndices.length; j++) {
- const ind = wordPosIndices[j]
- const bitmap = results[j]
-
- if (bitmap !== 0n) {
- for (let i = 0; i < 256; i++) {
- const bit = 1n
- const initialized = (bitmap & (bit << BigInt(i))) !== 0n
- if (initialized) {
- const tickIndex = (ind * 256 + i) * tickSpacing
- tickIndices.push(tickIndex)
- }
- }
- }
- }
-```
-
-We now have an array containing the indices of all initialized Ticks.
-
-## Fetching all Ticks by their indices
-
-We use the multicallProvider again to execute an aggregated read call for all tick indices.
-We create an array of call Promises again and use `.all()` to make our multicall:
-
-```typescript
-const calls: any[] = []
-
-for (const index of tickIndices) {
- calls.push(poolContract.ticks(index))
-}
-
-const results = await multicallProvider.all(calls)
-```
-
-Again, the order of the results array is the same as the elements in **tickIndices**.
-
-We are able to combine the **tickIndices** and **results** array to create an array of `Tick` objects:
-
-```typescript
-const allTicks: Tick[] = []
-
- for (let i = 0; i < tickIndices.length; i++) {
- const index = tickIndices[i]
- const ethersResponse = results[i]
- const tick = new Tick({
- index,
- liquidityGross: JSBI.BigInt(ethersResponse.liquidityGross.toString()),
- liquidityNet: JSBI.BigInt(ethersResponse.liquidityNet.toString()),
- })
- allTicks.push(tick)
- }
-```
-
-We need to parse the response from our RPC provider to JSBI values that the v3-sdk can work with.
-
-## Constructing the Pool
-
-We have everything to construct our `Pool` now:
-
-```typescript
-const usdcWethPool = new Pool(
- USDC,
- WETH,
- feeAmount,
- slot0.sqrtPriceX96,
- liquidity,
- slot0.tick,
- allTicks
-)
-```
-
-With this fully initialized Pool, we can make accurate offchain calculations.
-
-## Next Steps
-
-Now that you are familiar with fetching Pool data, continue your journey with the [next example](./03-active-liquidity.md) on visualizing the Liquidity density of a pool.
diff --git a/docs/sdk/v3/guides/advanced/03-active-liquidity.md b/docs/sdk/v3/guides/advanced/03-active-liquidity.md
deleted file mode 100644
index 089431288..000000000
--- a/docs/sdk/v3/guides/advanced/03-active-liquidity.md
+++ /dev/null
@@ -1,307 +0,0 @@
----
-id: active-liquidity
-title: Active Liquidity
----
-
-## Introduction
-
-This guide will cover how to fetch and compute the active liquidity in the specific Tick ranges of a pool. It is based on the [Liquidity Density example](https://github.com/Uniswap/examples/tree/main/v3-sdk/liquidity-density) and can be seen used in production, albeit in a more sophisticated way, in the [Uniswap Analytics](https://info.uniswap.org/#/pools) website.
-
-:::info
-If you need a briefer on the SDK and to learn more about how these guides connect to the examples repository, please visit our [background](./01-background.md) page!
-:::
-
-In this guide, we will use the V3 subgraph to fetch all ticks from **theGraph** and compute the active liquidity our Pool can use at each Tick. We then use `recharts` to draw a chart that visualizes our Pool's liqudity density.
-
-This guide will cover:
-
-1. Getting the tickSpacing and currently active Tick from the Pool
-2. Calculating active liquidity from net liquidity
-3. Drawing a chart from the Tick data
-
-This guide will not cover:
-
-- Specifics of working with the recharts library. You can read more about that [here](https://recharts.org/en-US/).
-
-At the end of the guide, we should be able to visualize the liquidity of any V3 Pool.
-
-## Understanding Active Liquidity
-
-To visualize the distribution of active liquidity in our Pool, we want to draw our Chart around the currently active Tick. For that we have to first understand:
-
-- What is an initialized Tick?
-- What is the current Tick?
-
-### Initialized Ticks
-
-When providing liquidity for a pool, the LP decides the **price range** in which the liquidity should be provided, and the amount of liquidity to be provided.
-The pool understands the position as **liquidity between the lower and upper Tick**. The Tick Index in this context is a representation of the price between the Pool's assets.
-
-Looking at this [visualization](https://www.desmos.com/calculator/oduetjzfp4) of multiple positions in a V3 Pool, we can see that the liquidity available for a swap does not change inside a position, but when crossing into the next position.
-This is what the **Initialized Ticks** of a Pool represent - they are a representation of the start or end of one or more positions.
-
-.default})
-
-When entering or leaving a position, its liquidity is added or removed from the **active liquidity available** for a Swap.
-The initialized Ticks store this **change in available liquidity** in the `liquidityNet` field.
-The change is always stored in relation to the currently active Tick - the current price.
-When the price crosses an initialized Tick, it gets updated and liqudity that was previously added when crossing the Tick would now be removed and vice versa.
-
-The `liquidityGross` value represents the gross value of liquidity referencing the tick.
-This is important for the edge case that one position ends at a Tick and a second position with exactly the same liquidity value would start at the Tick.
-In this case `liquidityNet` would be **0** but `liquidityGross` would still have a value, which ensures that the Tick is not deleted from the Pool.
-
-To visualize liquidity in a graph, we will only need to consider the changes, so it's sufficient to fetch the Ticks with `liquidityNet` not 0.
-
-### Fetching initialized Ticks
-
-To fetch all ticks of our Pool, we will use the [Uniswap V3 graph](../../../../api/subgraph/overview.md).
-To visualize active liquidity, we need the **tickIdx**, the **liquidityGross** and the **liquidityNet**.
-
-We define our GraphQL query and [send a POST request](https://axios-http.com/docs/post_example) to the V3 subgraph API endpoint:
-
-```typescript
-axios.post(
- "https://api.thegraph.com/subgraphs/name/uniswap/uniswap-v3",
- {"query": `{ ticks(
- where: {poolAddress: "${poolAddress.toLowerCase()}", liquidityNet_not: "0"}
- first: 1000,
- skip: ${skip},
- orderBy: tickIdx,
- orderDirection: asc
- ) {
- tickIdx
- liquidityGross
- liquidityNet
- }
- }`
- },
- {
- headers: {
- "Content-Type": "application/json"
- }
- }
- )
-```
-
-We only fetch the ticks that **have liquidity**, and we convert the poolAddress to **lower case** for the subgraph to work with. To make sure the Ticks are ordered correctly, we also define the **order direction** in the query.
-
-:::note
-GraphQL is only able to fetch 1000 records at a time. If a pool has more than 1000 initialized ticks, multiple calls are necessary to get all of them.
-:::
-
-The ticks we got from **theGraph** have this format:
-
-```typescript
-interface GraphTick {
- tickIdx: string
- liquidityGross: string
- liquidityNet: string
-}
-```
-
-### Current Tick
-
-The current Tick of the Pool represents the **current Price** after the last swap.
-Considering that the initialized Ticks only represent positions, we see that it is not necessarily one of the initialized Ticks but can be at any point in between them.
-The active liqudity at the current Price is also stored in the smart contract - we already fetched it with the `liquidity` function in the [previous guide](./02-pool-data.md).
-
-### Tickspacing
-
-Only the Ticks with indices that are divisible with 0 remainder by the tickspacing of a Pool are initializable.
-This is a convention defined by the protocol to save gas.
-The Tickspacing of the Pool is dependent on the Fee Tier.
-Pools with lower fees are meant to be used for more stable Token Pairs and allow for more granularity in where LPs position their liquidity.
-
-We can get the `tickSpacing` from the `TICK_SPACINGS` enum exposed by the `v3-sdk`:
-
-```typescript
-import { TICK_SPACINGS }
-
-const tickSpacing = TICK_SPACINGS[fee]
-```
-
-Alternatively, if we have already constructed a `Pool` object, we could just call `Pool.tickSpacing()`.
-
-### Putting it all together
-
-For the purpose of visualizing the liquidity density of the Pool, it rarely makes sense to display the full Tick Range of the Pool, as the vast majority of liquidity will be focused in a narrow price range.
-
-Instead, we will display a sensible number of Ticks around the current price.
-
-## Calculating active liquidity
-
-We know the spacing between Ticks and the Initialized Ticks where active liquidity changes.
-All we have to do is start calculating from the current Tick and iterate outwards.
-
-The code mentioned in the following snippets can be found in [`active-liquidity.ts`](https://github.com/Uniswap/examples/tree/main/v3-sdk/pool-data/src/libs/active-liquidity.ts).
-
-To draw our chart we want a data structure that looks something like this:
-
-```typescript
-interface TickProcessed {
- tickIdx: number,
- liquidityActive: JSBI,
- liquidityNet: JSBI,
- price0: string,
- price1: string,
- isCurrent: boolean
-}
-```
-
-To access the initialized Ticks directly from their Tick Index, we store them in a [Record](https://www.typescriptlang.org/docs/handbook/utility-types.html#recordkeys-type):
-
-```typescript
-const tickIdxToTickDictionary: Record.default})
-
-When the current Tick of the Pool moves across the Position, the ratio of `token0` and `token1` will change, and ultimately inverse if the current Tick moves out of the position on the other side.
-
-We will utilise this behaviour to provide liquidity with `token1` and withdraw the position when it has been converted to `token0`.
-
-## Calculating the Tick Range
-
-Our goal for this guide is to create a [Take Profit Order](../../../../concepts/protocol/range-orders.md#take-profit-orders) that trades `token0` for `token1` when the Price of `token0` increases by 5%.
-To create our Position, we need to first decide the Tick Range that we want to provide liquidity in.
-
-### Upper Tick
-
-We [create a Pool](./02-pool-data.md) that represents the V3 Pool we are interacting with and get the `token0Price`.
-We won't need full tick data in this example.
-
-```typescript
-import { Pool } from '@uniswap/v3-sdk'
-
-...
-const pool = new Pool(token0, token1, fee, sqrtPriceX96, liquidity, tickCurrent)
-
-const currentPrice = pool.token0Price
-```
-
-Next we increase the `Price` by 5%. We create a new Price with a numerator 5% higher than our current Price:
-
-```typescript
-import { Price, Fraction } from '@uniswap/sdk-core'
-
-const targetFraction = Price.asFraction.multiply(new Fraction(100 + 5, 100))
-
-const targetPrice = new Price(
- currentPrice.baseCurrency,
- currentPrice.quoteCurrency,
- targetFraction.denominator,
- targetFraction.numerator
-)
-```
-
-Be aware that the `numerator` and `denominator` parameters are ordered differently in the `Fraction` and `Price` constructor.
-
-We have calculated our target Price but we still need to find the **nearest usable tick** to create our Position.
-
-:::info
-As Positions can only start and end at initializable Ticks of the Pool, so we can only create a Range Order to a Price that exactly matches an initializable Tick.
-:::
-
-We use the `priceToClosestTick` function to find the closest tick to our targetPrice.
-We then use the `nearestUsableTick` function to find the closest initializable Tick for the `tickSpacing` of the `Pool`.
-
-```typescript
-import {priceToClosestTick, nearestUsableTick} from '@uniswap/v3-sdk'
-
-let targetTick = nearestUsableTick(
- priceToClosestTick(targetPrice),
- pool.tickSpacing
-)
-```
-
-This nearest Tick will most likely not **exactly** match our Price target.
-
-Depending on our personal preferences we can either err on the higher or lower side of our target by adding or subtracting the `tickSpacing` if the initializable Tick is lower or higher than the theoretically closest Tick.
-
-### Lower Tick
-
-We now find the lower Tick by subtracting the tickSpacing from the upper Tick:
-
-```typescript
-let lowerTick = targetTick - pool.tickSpacing
-```
-
-If the price difference is too low, the lower tick may be left of the current Tick of the Pool.
-In that case we would not be able to provide single side liquidity.
-We can either throw an Error or increase our Position by one Tick.
-
-```typescript
-if (tickLower <= pool.tickCurrent) {
- tickLower += pool.tickSpacing
- targetTick += pool.tickSpacing
-}
-```
-
-We now have a lower and upper Tick for our Position, next we need to construct and mint it.
-
-## Creating the Single Side Liquidity Position
-
-We will use the `NonfungiblePositionManager` and `Position` classes from the `v3-sdk` to construct our position. We then use an **etherJS** wallet to mint our Position on-chain.
-
-If you are not familiar with liquidity Positions, check out the [liquidity position guides](../liquidity/01-position-data.md).
-
-### Minting the Position
-
-We create a `Position` object with our ticks and the amount of tokens we want to deposit:
-
-```typescript
-import { Position } from '@uniswap/v3-sdk'
-
-const position = Position.fromAmount0({
- pool: pool,
- tickLower: tickLower,
- tickUpper: targetTick,
- amount0: amount,
- useFullPrecision: true
-})
-```
-
-Before we mint our position, we need to give the `NonfungiblePositionManager` Contract an approval to transfer our tokens.
-We can find the Contract address on the official [Uniswap Github](https://github.com/Uniswap/v3-periphery/blob/main/deploys.md).
-For local development, the contract address is the same as the network we are forking from.
-So if we are using a local fork of mainnet like described in the [Local development guide](../02-local-development.md), the contract address would be the same as on mainnet.
-
-```typescript
-import ethers from 'ethers'
-
-const provider = new ethers.providers.JsonRpcProvider(rpcUrl)
-const wallet = new ethers.Wallet(privateKey, provider)
-
-const tokenContract = new ethers.Contract(
- pool.token0.address,
- ERC20_ABI,
- wallet
-)
-
-await tokenContract['approve'](
- NONFUNGIBLE_POSITION_MANAGER_CONTRACT_ADDRESS,
- ethers.BigNumber.from(amount)
- )
-```
-
-Once we have our approval, we create the calldata for the **Mint** call using the `NonfungiblePositionManager`:
-
-```typescript
-import {MintOptions, NonfungiblePositionManager}
-import { Percent } from '@uniswap/sdk-core'
-
-const mintOptions: MintOptions = {
- recipient: wallet.address,
- deadline: Math.floor(Date.now() / 1000) + 60 * 20,
- slippageTolerance: new Percent(50, 10_000),
-}
-
-const { calldata, value } = NonfungiblePositionManager.addCallParameters(
- order.position,
- mintOptions
-)
-```
-
-We can populate our mint transaction and send it with our wallet:
-
-```typescript
- const transaction = {
- data: calldata,
- to: NONFUNGIBLE_POSITION_MANAGER_CONTRACT_ADDRESS,
- value: ethers.BigNumber.from(value),
- from: address,
- maxFeePerGas: MAX_FEE_PER_GAS,
- maxPriorityFeePerGas: MAX_PRIORITY_FEE_PER_GAS,
- }
-
-const txRes = await wallet.sendTransaction(transaction)
-```
-
-You can find full code examples for these code snippets in [`range-order.ts`](https://github.com/uniswap/examples/blob/main/v3-sdk/range-order/src/libs/range-order.ts).
-
-### Getting the tokenId
-
-We want to read the response to our `Mint` function call to get **the position id**.
-We will need the positionId to fetch the Position Info from the NFTPositionManager contract.
-We wait for the transaction receipt and fetch the result using `trace_transaction`:
-
-```typescript
-let receipt = null
-let mintCallOutput
-
-while (receipt === null) {
- try {
- receipt = await provider.getTransactionReceipt(txRes.hash)
-
- if (receipt === null) {
- continue
- } else {
- const callTraces = await provider.send('trace_transaction', [
- txRes.hash
- ])
- mintCallOutput = callTraces[0].result.output
- }
- } catch (e) {
- break
- }
-}
-```
-
-Your Node provider may not support this call. In that case you can also call the NonfungiblePositionManager Contract with the wallet address and identify the Range Order Position manually:
-
-```typescript
-const mintCallOutput = await wallet.call(transaction)
-```
-
-We get a raw byte string as a return value from this function and have to parse it ourselves.
-We decode the result with the **ethers AbiCoder**. The solidity function has this signature:
-
-```solidity
-function mint(
- struct INonfungiblePositionManager.MintParams params
-) external returns (uint256 tokenId, uint128 liquidity, uint256 amount0, uint256 amount1)
-```
-
-So we need the first parameter to get the `tokenId`:
-
-```typescript
-const decodedOutput = ethers.utils.defaultAbiCoder.decode(
- ['tuple(uint256, uint128, uint256, uint256)'],
- mintCallOutput
- )[0]
-
-const tokenId = decodedOutput.toString()
-```
-
-Ethers handles the string decoding of the byte string we got and parses it to its internal datatypes.
-The decodedOutput we get from the AbiCoder is a `ethers.Bignumber` so we need to cast it to a string to use it with the SDK.
-
-We have created our Range Order Position, now we need to monitor it.
-
-In the [code example](https://github.com/uniswap/examples/blob/main/v3-sdk/range-order/src/libs/range-order.ts#L180) we use `wallet.call` to get the position id.
-`call` and `trace_call` both simulate a transaction on the connected node and return the expected output, `trace_call` gives us a much more detailed output though.
-Depending on the use case, either can be the better choice.
-In a production environment you would prefer to wait for the `transactionReceipt` like described earlier to ensure the transaction was actaully included in the blockchain.
-
-## Observing the Price
-
-We need to observe the price of the Pool and withdraw our Position once the `tickCurrent` has moved across our Position.
-
-We use **ethers JS** to watch for new blocks and fetch the latest Pool data:
-
-```typescript
-
-provider.on('block', refreshPool())
-
-function refreshPool() {
-
- ... // construct Pool contract
-
- const slot0 = await poolContract.slot0()
- const tickCurrent = slot0.tick
-}
-```
-
-It is not necessary to calculate the Price from the tick we fetched, as executing the limit order is dependent on the tick range we defined and not the Price from which we calculated it.
-
-```typescript
-
-if (tickCurrent > targetTick) {
- // Withdraw position
-}
-```
-
-We check if the tick has crossed our position, and if so we withdraw the Position.
-
-## Closing the Limit Order
-
-We call the NonfungiblePositionManager Contract with the `tokenId` to get all info of our position as we may have gotten fees from trades on the Pool:
-
-```typescript
-import INON_FUNGIBLE_POSITION_MANAGER from '@uniswap/v3-periphery/artifacts/contracts/NonfungiblePositionManager.sol/NonfungiblePositionManager.json'
-
-const positionManagerContract = new ethers.Contract(
- NONFUNGIBLE_POSITION_MANAGER_CONTRACT_ADDRESS,
- INONFUNGIBLE_POSITION_MANAGER.abi,
- provider
-)
-
-const positionInfo = await positionManagerContract.positions(tokenId)
-```
-
-We use the `NonfungiblePositionManager`, the `pool`, `positionInfo` and `tokenId` to create call parameter for a `decreaseLiquidity` call.
-
-We start with creating `CollectOptions`:
-
-```typescript
-import { Percent, CurrencyAmount } from '@uniswap/sdk-core'
-import { CollectOptions, RemoveLiquidityOptions } from '@uniswap/v3-sdk'
-import JSBI from 'jsbi'
-
-const collectOptions: Omit