- Fillers should start with polling for orders and rate limit at 6 RPS.
+ Fillers should start with polling for orders and rate limit at 4 RPS. The orders endpoint serves cached responses, and requests above 4 RPS return `429`. Each response returns at most the last 50 orders, ordered by most recent.
+
+
+
+
+
+
- `ERC20ETH` is deployed at `0x00000000e20E49e6dCeE6e8283A0C090578F0fb9`. The address is the same across supported chains through deterministic CREATE2 deployment and a mined vanity address.
+ `ERC20ETH` is deployed at `0x00000000e20E49e6dCeE6e8283A0C090578F0fb9`, the same address on the chains that carry it through deterministic CREATE2 deployment and a mined vanity address. It is not deployed on every UniswapX chain, so check the [Deployments](/docs/liquidity/uniswapx/deployments) page or deployments.json for a given chain before relying on it.
References:
@@ -450,7 +502,7 @@ faqs:
- Use the UniswapX filler help form to reach the team without leaving this page.
+ Use the Help Center to reach the team without leaving this page.
diff --git a/content/liquidity/uniswapx/filling/mainnet/become-a-quoter.mdx b/content/liquidity/uniswapx/filling/mainnet/become-a-quoter.mdx
index 3d0a340fa..a6fe9d377 100644
--- a/content/liquidity/uniswapx/filling/mainnet/become-a-quoter.mdx
+++ b/content/liquidity/uniswapx/filling/mainnet/become-a-quoter.mdx
@@ -1,5 +1,4 @@
---
-id: becomequoter
title: Become a Quoter
description: Set up a UniswapX quoter on Ethereum mainnet, meet performance requirements, and move from beta to production.
---
@@ -16,8 +15,14 @@ To participate as a quoter, you must host a service that adheres to the UniswapX
## Performance Expectations
To ensure a smooth experience for swappers and a fair auction process for quoters, participants are held to the following performance standards:
-
-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.
+
+
+Your server must respond to every quote request within 500ms. The budget is the same on every chain.
+
+If you cannot quote, return a `204` with an empty body.
+
+Do not let quote requests time out. Endpoints that time out on a meaningful share of requests may be disabled at Uniswap Labs' discretion until the issue is fixed.
+
## Handling Fades & the Circuit Breaker
@@ -71,7 +76,7 @@ If you can fulfill the quote request, your server should respond with status `20
}
```
-If you do not wish to respond to a quote request, you must return an empty response with status code `204`.
+A `204` with an empty body is the expected signal when you cannot or will not quote.
### 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:
diff --git a/content/liquidity/uniswapx/filling/mainnet/filling-on-mainnet.mdx b/content/liquidity/uniswapx/filling/mainnet/filling-on-mainnet.mdx
index 51195c478..a385568dd 100644
--- a/content/liquidity/uniswapx/filling/mainnet/filling-on-mainnet.mdx
+++ b/content/liquidity/uniswapx/filling/mainnet/filling-on-mainnet.mdx
@@ -1,5 +1,4 @@
---
-id: createfiller
title: Filling on Mainnet
description: Integrate a UniswapX filler on Ethereum mainnet, retrieve open orders, and execute Dutch and limit fills safely.
---
@@ -56,6 +55,8 @@ All signed Dutch Orders created through the Uniswap UI are available via the Uni
GET https://api.uniswap.org/v2/orders?orderStatus=open&chainId=1&limit=1
```
+The endpoint serves cached responses and returns at most the last 50 orders, ordered by most recent. Poll at no more than 4 RPS; requests above that return `429`.
+
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 UniswapX Orders Endpoint as written above, to retrieve open signed orders. This page covers Dutch V2 orders on Mainnet (`chainId=1`). For the DutchV3 chains, see [Filling Dutch V3 Auctions](/docs/liquidity/uniswapx/filling/dutch-v3-chains/filling-on-dutch-v3-chains).
diff --git a/content/liquidity/uniswapx/filling/overview.mdx b/content/liquidity/uniswapx/filling/overview.mdx
index c45922e81..ab760f450 100644
--- a/content/liquidity/uniswapx/filling/overview.mdx
+++ b/content/liquidity/uniswapx/filling/overview.mdx
@@ -1,5 +1,4 @@
---
-id: filleroverview
title: Fillers Overview
description: Learn how UniswapX fillers and quoters compete to settle swaps across chains.
---
@@ -9,11 +8,11 @@ description: Learn how UniswapX fillers and quoters compete to settle swaps acro
| Chain | Auction type | Reactor | Guide |
|---|---|---|---|
| Ethereum | RFQ + Exclusive Dutch Auction | Dutch V2 | [Filling on Mainnet](/docs/liquidity/uniswapx/filling/mainnet/filling-on-mainnet), [Become a Quoter](/docs/liquidity/uniswapx/filling/mainnet/become-a-quoter) |
-| Arbitrum, Avalanche, Base, BNB Smart Chain, Robinhood Chain, Tempo, Unichain | RFQ + Exclusive Dutch Auction (block-based decay) | Dutch V3 | [Filling Dutch V3 Auctions](/docs/liquidity/uniswapx/filling/dutch-v3-chains/filling-on-dutch-v3-chains) |
+| Arbitrum, Arc, Avalanche, Base, BNB Smart Chain, Ink, Monad, Robinhood Chain, Tempo, Unichain | RFQ + Exclusive Dutch Auction (block-based decay) | Dutch V3 | [Filling Dutch V3 Auctions](/docs/liquidity/uniswapx/filling/dutch-v3-chains/filling-on-dutch-v3-chains) |
UniswapX fillers compete to settle swaps through permissionless auctions. Use this section to choose a chain, ingest orders, and fill.
-UniswapX now uses RFQ and the exclusive Dutch auction model on every supported chain. Priority gas auctions are no longer a separate integration path. Fillers previously integrated against a Priority reactor should migrate to DutchV3. See the [changelog entry](/docs/changelog/active-notifications/uniswapx-rfq-auctions-on-base-and-arbitrum) for the Base and Arbitrum transition.
+UniswapX now uses RFQ and the exclusive Dutch auction model on every supported chain. Priority gas auctions are no longer a separate integration path. Fillers previously integrated against a Priority reactor should migrate to DutchV3. See the [changelog entry](/docs/changelog/completed-notifications/uniswapx-rfq-auctions-on-base-and-arbitrum) for the Base and Arbitrum transition.
## Filler Roles
@@ -23,7 +22,7 @@ UniswapX has one permissioned role (quoter) and one permissionless role (filler)
|---|---|---|---|---|
| **Quoter** | Permissioned, vetted by Uniswap Labs | Responds to the off-chain RFQ; if it wins the hard quote, it gets the exclusivity window | Yes: if it wins exclusivity and does not fill, it triggers the circuit breaker | Receives quote requests from the parameterization service |
| **Exclusive filler** | The quoter that won the RFQ | During the exclusivity window (about 24 seconds, or 2 blocks, on mainnet) | Yes | It is the RFQ winner |
-| **Non-exclusive filler** | Permissionless, no vetting | After exclusivity expires in the open Dutch auction, or during exclusivity through a soft-exclusivity override (`exclusivityOverrideBps` greater than zero) | No: it never held exclusivity, so it cannot fade and is not subject to the circuit breaker | Polls the orders API at 6 RPS |
+| **Non-exclusive filler** | Permissionless, no vetting | After exclusivity expires in the open Dutch auction, or during exclusivity through a soft-exclusivity override (`exclusivityOverrideBps` greater than zero) | No: it never held exclusivity, so it cannot fade and is not subject to the circuit breaker | Polls the orders API at 4 RPS |
A non-exclusive filler carries no fade risk and is never subject to the circuit breaker, because it never commits to an exclusivity it could fail to honor.
@@ -46,17 +45,22 @@ Retrieve open orders from the UniswapX Orders Endpoint. The [Swagger documentati
|---|---|---|
| Ethereum | `1` | `Dutch_V2` |
| Arbitrum | `42161` | `Dutch_V3` |
+| Arc | `5042` | `Dutch_V3` |
| Avalanche | `43114` | `Dutch_V3` |
| Base | `8453` | `Dutch_V3` |
| BNB Smart Chain | `56` | `Dutch_V3` |
+| Ink | `57073` | `Dutch_V3` |
+| Monad | `143` | `Dutch_V3` |
| Robinhood Chain | `4663` | `Dutch_V3` |
| Tempo | `4217` | `Dutch_V3` |
| Unichain | `130` | `Dutch_V3` |
```bash
-GET https://api.uniswap.org/v2/orders?orderStatus=open&chainId=1&orderType=Dutch_V2&limit=1000
+GET https://api.uniswap.org/v2/orders?orderStatus=open&chainId=1&orderType=Dutch_V2&limit=50
```
+The endpoint serves cached responses and returns at most the last 50 orders, ordered by most recent. Poll at no more than 4 RPS; requests above that return `429`.
+
## Native ETH Input
UniswapX supports native ETH input from EIP-7702 smart wallets through `ERC20ETH`. Fillers may see orders where `inputTokenAddress` is the `ERC20ETH` deployment address; route those orders as native ETH, not as a pool-backed ERC-20.
@@ -69,5 +73,5 @@ For common RFQ and execution issues, see the [Filler FAQ](/docs/liquidity/uniswa
## Support
-- Submit a ticket via the UniswapX filler help form.
+- Submit a ticket via the Help Center.
- Subscribe to the [Telegram channel](http://t.me/UniswapXdiscussion) for announcements.
diff --git a/content/liquidity/uniswapx/filling/priority-chain/filling-on-op-stack.mdx b/content/liquidity/uniswapx/filling/priority-chain/filling-on-op-stack.mdx
index 74b96ed68..6599514a5 100644
--- a/content/liquidity/uniswapx/filling/priority-chain/filling-on-op-stack.mdx
+++ b/content/liquidity/uniswapx/filling/priority-chain/filling-on-op-stack.mdx
@@ -1,5 +1,4 @@
---
-id: priorityorderreactor
title: Filling Priority Auctions
description: Fill UniswapX Priority orders using priority-fee bidding and reactor execution patterns.
---
diff --git a/content/liquidity/uniswapx/overview.mdx b/content/liquidity/uniswapx/overview.mdx
index f7e6d09c3..cd79475e0 100644
--- a/content/liquidity/uniswapx/overview.mdx
+++ b/content/liquidity/uniswapx/overview.mdx
@@ -1,6 +1,6 @@
---
-id: overview
title: UniswapX Overview
+sidebarTitle: Overview
description: Learn how UniswapX's intent-based infrastructure uses competitive auctions to route swaps across public and private liquidity sources, all gasless with no cost for failed swaps.
---
diff --git a/content/protocols/meta.json b/content/protocols/meta.json
index 3c97600f8..ae10e3fb4 100644
--- a/content/protocols/meta.json
+++ b/content/protocols/meta.json
@@ -5,6 +5,7 @@
"overview",
"[Deployments](/deployments)",
"v4",
+ "uniswap-labs-hooks",
"v3",
"v2",
"smart-wallet",
diff --git a/content/protocols/overview.mdx b/content/protocols/overview.mdx
index 9a978d654..13f3adab7 100644
--- a/content/protocols/overview.mdx
+++ b/content/protocols/overview.mdx
@@ -1,7 +1,30 @@
---
-id: overview
-title: Protocols Overview
+title: Uniswap Protocols Overview
+sidebarTitle: Overview
description: Navigate the Uniswap protocol documentation, from the core AMM versions to supporting infrastructure contracts.
+keywords:
+ - Uniswap protocols
+ - AMM versions
+ - Universal Router
+ - Permit2
+ - The Compact
+ - protocol fees
+faqs:
+ - question: Which Uniswap protocol version should I use for a new integration?
+ answer: |-
+ Uniswap v4 is the current and recommended version for new integrations. It consolidates all pools into a single PoolManager contract, supports hooks that customize pool behavior across the pool lifecycle, and uses flash accounting to defer token transfers until the end of a transaction, which reduces gas for multi-step operations. Use v3 for existing concentrated liquidity integrations and v2 for legacy constant product workflows.
+ - question: What is the difference between the Uniswap AMM and its supporting protocols?
+ answer: |-
+ The AMM contracts are the pool contracts that hold liquidity and execute swaps, versioned as Uniswap v2, v3, and v4. The supporting protocols are infrastructure contracts used across versions: the Universal Router composes swaps across v2, v3, and v4 in a single transaction, Permit2 handles signature-based token transfers and time-bound allowances, Fee Adapter and TokenJar contracts collect protocol fees, The Compact provides ERC-6909 resource locks for cross-chain coordination, and Calibur powers smart wallet delegation through EIP-7702.
+ - question: Which contract should I use to execute Uniswap swaps programmatically?
+ answer: |-
+ The Universal Router is the recommended entry point for executing swaps programmatically. It is an unowned, non-upgradeable contract that composes swaps across Uniswap v2, v3, and v4 in a single transaction using command-based encoding, and it integrates with Permit2 for signature-controlled token approvals.
+ - question: Are the Uniswap protocol contracts audited?
+ answer: |-
+ Yes. The Uniswap v4 core and periphery repositories publish their audit reports, and Uniswap Labs maintains an active bug bounty program on Cantina for eligible vulnerability disclosures.
+ - question: Where do I find Uniswap contract deployment addresses?
+ answer: |-
+ The unified deployments page at developers.uniswap.org/deployments lists Uniswap contract addresses across all protocols and chains. Each protocol section of the docs also has its own deployments page; for example, Uniswap v4 addresses are on the v4 deployments page, and the smart wallet deployments page lists the Calibur address across supported networks.
---
## Protocols
@@ -85,3 +108,68 @@ Uniswap smart wallet features are powered by Calibur, a non-upgradeable contract
Uniswap Labs maintains an active bug bounty program on Cantina for eligible vulnerability disclosures.
[Uniswap Bug Bounty Program](https://cantina.xyz/bounties/f9df94db-c7b1-434b-bb06-d1360abdd1be)
+
+## FAQ
+
+
+ Which Uniswap protocol version should I use for a new integration?
+
+
+
+ Uniswap v4 is the current and recommended version for new integrations. It consolidates all pools into a single `PoolManager` contract, supports [hooks](/docs/protocols/v4/concepts/hooks) that customize pool behavior across the pool lifecycle, and uses [flash accounting](/docs/protocols/v4/concepts/flash-accounting) to defer token transfers until the end of a transaction, which reduces gas for multi-step operations.
+
+ Use [Uniswap v3](/docs/protocols/v3/overview) for existing concentrated liquidity integrations and [Uniswap v2](/docs/protocols/v2/overview) for legacy constant product workflows.
+
+
+
+
+
+
+ What is the difference between the Uniswap AMM and its supporting protocols?
+
+
+
+ The AMM contracts are the pool contracts that hold liquidity and execute swaps, versioned as Uniswap v2, v3, and v4. The supporting protocols are infrastructure contracts used across versions:
+
+ * [Universal Router](/docs/protocols/universal-router/overview): composes swaps across v2, v3, and v4 in a single transaction.
+ * [Permit2](/docs/protocols/permit2/overview): signature-based token transfers and time-bound allowances.
+ * [Protocol Fees](/docs/protocols/protocol-fee/overview): Fee Adapter and TokenJar contracts that collect protocol fees.
+ * [The Compact](/docs/protocols/the-compact/overview): ERC-6909 resource locks for cross-chain coordination.
+ * [Smart wallet (Calibur)](/docs/protocols/smart-wallet/overview): EIP-7702 delegation for smart wallet features.
+
+
+
+
+
+
+ Which contract should I use to execute Uniswap swaps programmatically?
+
+
+
+ The [Universal Router](/docs/protocols/universal-router/overview) is the recommended entry point for executing swaps programmatically. It is an unowned, non-upgradeable contract that composes swaps across Uniswap v2, v3, and v4 in a single transaction using command-based encoding, and it integrates with [Permit2](/docs/protocols/permit2/overview) for signature-controlled token approvals.
+
+
+
+
+
+
+ Are the Uniswap protocol contracts audited?
+
+
+
+ Yes. The Uniswap v4 [core audits](https://github.com/Uniswap/v4-core/tree/main/docs/security/audits) and [periphery audits](https://github.com/Uniswap/v4-periphery/tree/main/audits) are published in their repositories, and Uniswap Labs maintains an active [bug bounty program on Cantina](https://cantina.xyz/bounties/f9df94db-c7b1-434b-bb06-d1360abdd1be) for eligible vulnerability disclosures.
+
+
+
+
+
+
+ Where do I find Uniswap contract deployment addresses?
+
+
+
+ The [unified deployments page](/deployments) lists Uniswap contract addresses across all protocols and chains. Each protocol section of the docs also has its own deployments page; for example, [Uniswap v4 addresses](/docs/protocols/v4/deployments) are on the v4 deployments page, and the [smart wallet deployments page](/docs/protocols/smart-wallet/deployments) lists the Calibur address across supported networks.
+
+
+
+
diff --git a/content/protocols/permit2/concepts/allowance-transfer.mdx b/content/protocols/permit2/concepts/allowance-transfer.mdx
index 1937d018a..0a7faf399 100644
--- a/content/protocols/permit2/concepts/allowance-transfer.mdx
+++ b/content/protocols/permit2/concepts/allowance-transfer.mdx
@@ -1,5 +1,4 @@
---
-id: allowance-transfer
title: Allowance Transfer
description: Understand Uniswap Permit2 allowance-based approvals, permits, and `transferFrom` flows with nonce safety.
---
diff --git a/content/protocols/permit2/overview.mdx b/content/protocols/permit2/overview.mdx
index e9d9da3dd..7074e30a0 100644
--- a/content/protocols/permit2/overview.mdx
+++ b/content/protocols/permit2/overview.mdx
@@ -1,6 +1,30 @@
---
-title: Overview
+title: Permit2 Overview
+sidebarTitle: Overview
description: Learn how Uniswap Permit2 combines signature-based transfers and time-bound allowances for token spending.
+keywords:
+ - permit2
+ - allowance-transfer
+ - signature-transfer
+ - token-approvals
+ - eip-2612
+ - nonces
+faqs:
+ - question: What is the difference between AllowanceTransfer and SignatureTransfer?
+ answer: |-
+ Permit2 exposes two independent modules. AllowanceTransfer stores a standing, time-bound allowance inside the Permit2 contract: you set an amount and an expiration for a spender, and that spender can call transferFrom repeatedly until the allowance is exhausted or expires. This suits recurring flows such as repeated swaps or subscriptions. SignatureTransfer authorizes a single, nonce-scoped transfer through one signature; the permission does not persist after the transaction, so it leaves no standing allowance. Use it when a contract needs tokens infrequently and you want to avoid lingering approvals.
+ - question: Do I still need a per-token approval to use Permit2?
+ answer: |-
+ Yes, but only once per token. Before Permit2 can move a token on a user's behalf, the user makes a one-time standard ERC-20 approval of the Permit2 contract on that token, commonly for the maximum uint256 amount. After that, Permit2 manages granular, per-spender, time-bound permissions through signatures or its own approve function, so integrators no longer trigger a separate onchain approval for every spender.
+ - question: How is Permit2 different from an EIP-2612 permit?
+ answer: |-
+ EIP-2612 adds a permit function to a token itself, so it only works for tokens that implement it. Permit2 is a separate contract that works with any ERC-20, including tokens that will never add EIP-2612 support. After the one-time approval of the Permit2 contract, users get signature-based approvals for every such token, plus batching, expirations, and unordered nonces that a bare EIP-2612 permit does not provide.
+ - question: How do Permit2 nonces and expiration work?
+ answer: |-
+ The two modules use different nonce schemes. AllowanceTransfer packs an incrementing nonce per owner, token, and spender alongside the amount and an expiration timestamp, so two permits with the same nonce do not cancel each other as long as the token or spender differ. SignatureTransfer uses unordered nonces tracked in a bitmap, so signatures can be spent in any order and each nonce is single-use. Both carry a signature deadline, and AllowanceTransfer allowances also carry their own expiration after which the permission is invalid.
+ - question: What is the Permit2 contract address, and has it been audited?
+ answer: |-
+ Permit2 is deployed at the same address on every chain Uniswap supports except zkSync: 0x000000000022D473030F116dDEE9F6B43aC78BA3. On zkSync it is 0x0000000000225e31D15943971F47aD3022F714Fa. The contracts are open source in the Uniswap/permit2 repository, which also publishes the third-party audit reports.
---
[Permit2](https://github.com/Uniswap/permit2) is a unification of 2 contracts, `SignatureTransfer` and `AllowanceTransfer`. The `SignatureTransfer` contract handles all signature-based transfers, meaning that an allowance on the token is bypassed and permissions to the spender only last for the duration of the transaction that the one-time signature is spent. The `AllowanceTransfer` contract handles setting allowances on tokens, giving permissions to spenders on a specified amount for a specified duration of time. Any transfers that then happen through the `AllowanceTransfer` contract will only succeed if the proper permissions have been set.
@@ -22,6 +46,81 @@ To maximize Permit2 utility, users can choose a max approval on the contract whe
totalAmount = type(uint256).max;
```
+## FAQ
+
+
+ What is the difference between AllowanceTransfer and SignatureTransfer?
+
+
+
+ Permit2 exposes two independent modules:
+
+ * **[AllowanceTransfer](/docs/protocols/permit2/concepts/allowance-transfer)** stores a standing, time-bound allowance inside the Permit2 contract. You set an amount and an expiration for a spender, and that spender can call `transferFrom` repeatedly until the allowance is exhausted or expires. This suits recurring flows such as repeated swaps or subscriptions.
+ * **[SignatureTransfer](/docs/protocols/permit2/concepts/signature-transfer)** authorizes a single, nonce-scoped transfer through one signature. The permission does not persist after the transaction, so it leaves no standing allowance. Use it when a contract needs tokens infrequently and you want to avoid lingering approvals.
+
+
+
+
+
+
+ Do I still need a per-token approval to use Permit2?
+
+
+
+ Yes, but only once per token. Before Permit2 can move a token on a user's behalf, the user makes a one-time standard ERC-20 approval of the Permit2 contract on that token, commonly for the maximum `uint256` amount:
+
+ ```solidity
+ USDC.approve(permit2Address, type(uint256).max);
+ ```
+
+ After that, Permit2 manages granular, per-spender, time-bound permissions through signatures or its own `approve` function, so integrators no longer trigger a separate onchain approval for every spender.
+
+
+
+
+
+
+ How is Permit2 different from an EIP-2612 permit?
+
+
+
+ [EIP-2612](https://eips.ethereum.org/EIPS/eip-2612) adds a `permit` function to a token itself, so it only works for tokens that implement it. Permit2 is a separate contract that works with any ERC-20, including tokens that will never add EIP-2612 support. After the one-time approval of the Permit2 contract, users get signature-based approvals for every such token, plus batching, expirations, and unordered nonces that a bare EIP-2612 permit does not provide.
+
+
+
+
+
+
+ How do Permit2 nonces and expiration work?
+
+
+
+ The two modules use different nonce schemes:
+
+ * **AllowanceTransfer** packs an incrementing nonce per owner, token, and spender alongside the amount and an expiration timestamp. Two permits with the same nonce do not cancel each other as long as the token or spender differ.
+ * **SignatureTransfer** uses unordered nonces tracked in a bitmap, so signatures can be spent in any order and each nonce is single-use.
+
+ Both carry a signature deadline, and AllowanceTransfer allowances also carry their own `expiration` after which the permission is invalid.
+
+
+
+
+
+
+ What is the Permit2 contract address, and has it been audited?
+
+
+
+ Permit2 is deployed at the same address on every chain Uniswap supports **except** zkSync: `0x000000000022D473030F116dDEE9F6B43aC78BA3`.
+
+ On zkSync it is `0x0000000000225e31D15943971F47aD3022F714Fa`.
+
+ The contracts are open source in the [Uniswap/permit2](https://github.com/Uniswap/permit2) repository, which also publishes the third-party audit reports.
+
+
+
+
+
## Where to Go Next
- Learn allowance flows in [Allowance Transfer](/docs/protocols/permit2/concepts/allowance-transfer)
diff --git a/content/protocols/protocol-fee/deployments.mdx b/content/protocols/protocol-fee/deployments.mdx
index 288ceb7e5..a25c70791 100644
--- a/content/protocols/protocol-fee/deployments.mdx
+++ b/content/protocols/protocol-fee/deployments.mdx
@@ -1,27 +1,159 @@
---
-title: Deployments
+title: Protocol Fee Deployments
+sidebarTitle: Deployments
description: Find Uniswap Protocol Fee deployment addresses and governance-controlled deployment flow details.
---
-## Ethereum Mainnet
+## Ethereum: 1
| Contract | Address |
|----------|---------|
-| MainnetDeployer | [0xd3Aa12B99892b7D95BBAA27AEf222A8E2a038C0C](https://etherscan.io/address/0xd3Aa12B99892b7D95BBAA27AEf222A8E2a038C0C) |
-| TokenJar (AssetSink) | [0xf38521f130fcCF29dB1961597bc5d2B60F995f85](https://etherscan.io/address/0xf38521f130fcCF29dB1961597bc5d2B60F995f85) |
-| Releaser (Firepit) | [0x0D5Cd355e2aBEB8fb1552F56c965B867346d6721](https://etherscan.io/address/0x0D5Cd355e2aBEB8fb1552F56c965B867346d6721) |
-| V3FeeAdapter | [0x5E74C9f42EEd283bFf3744fBD1889d398d40867d](https://etherscan.io/address/0x5E74C9f42EEd283bFf3744fBD1889d398d40867d) |
-| UNI | [0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984](https://etherscan.io/address/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984) |
+| MainnetDeployer | [`0xd3Aa12B99892b7D95BBAA27AEf222A8E2a038C0C`](https://etherscan.io/address/0xd3Aa12B99892b7D95BBAA27AEf222A8E2a038C0C) |
+| TokenJar | [`0xf38521f130fcCF29dB1961597bc5d2B60F995f85`](https://etherscan.io/address/0xf38521f130fcCF29dB1961597bc5d2B60F995f85) |
+| Releaser (Firepit) | [`0x0D5Cd355e2aBEB8fb1552F56c965B867346d6721`](https://etherscan.io/address/0x0D5Cd355e2aBEB8fb1552F56c965B867346d6721) |
+| V3FeeAdapter | [`0x5E74C9f42EEd283bFf3744fBD1889d398d40867d`](https://etherscan.io/address/0x5E74C9f42EEd283bFf3744fBD1889d398d40867d) |
+| V3OpenFeeAdapter | [`0xf2371551Fe3937Db7c750f4DfABe5c2fFFdcBf5A`](https://etherscan.io/address/0xf2371551Fe3937Db7c750f4DfABe5c2fFFdcBf5A) |
+| UNI Vesting | [`0xCa046A83EDB78F74aE338bb5A291bF6FdAc9e1D2`](https://etherscan.io/address/0xCa046A83EDB78F74aE338bb5A291bF6FdAc9e1D2) |
+| Agreement Anchor 1 | [`0xC707467e7fb43Fe7Cc55264F892Dd2D7f8Fc27C8`](https://etherscan.io/address/0xC707467e7fb43Fe7Cc55264F892Dd2D7f8Fc27C8) |
+| Agreement Anchor 2 | [`0x33A56942Fe57f3697FE0fF52aB16cb0ba9b8eadd`](https://etherscan.io/address/0x33A56942Fe57f3697FE0fF52aB16cb0ba9b8eadd) |
+| Agreement Anchor 3 | [`0xF9F85a17cC6De9150Cd139f64b127976a1dE91D1`](https://etherscan.io/address/0xF9F85a17cC6De9150Cd139f64b127976a1dE91D1) |
+| NttManager | [`0x6569925Aac77D6B8Bb085F31F9828ff80D5a0c44`](https://etherscan.io/address/0x6569925Aac77D6B8Bb085F31F9828ff80D5a0c44) |
+| WormholeTransceiver | [`0x7597C40Fd3df66b750C14ad4D90524e247499011`](https://etherscan.io/address/0x7597C40Fd3df66b750C14ad4D90524e247499011) |
+| V4FeeAdapter | [`0x89A5D5bF00a27D55c02951E49078a5C5771051dB`](https://etherscan.io/address/0x89A5D5bF00a27D55c02951E49078a5C5771051dB) |
+| V4FeePolicy | [`0x1cd822b70a0591420F65E94b9B3A0D0b0fB3a314`](https://etherscan.io/address/0x1cd822b70a0591420F65E94b9B3A0D0b0fB3a314) |
+| UNI | [`0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984`](https://etherscan.io/address/0x1f9840a85d5af5bf1d1762f925bdaddc4201f984) |
-## Unichain
+## Unichain: 130
| Contract | Address |
|----------|---------|
-| UnichainDeployer | [0xD16c47bf3ae22e0B2BAc5925D990b81416f18dea](https://uniscan.xyz/address/0xD16c47bf3ae22e0B2BAc5925D990b81416f18dea) |
-| TokenJar | [0xD576BDF6b560079a4c204f7644e556DbB19140b5](https://uniscan.xyz/address/0xD576BDF6b560079a4c204f7644e556DbB19140b5) |
-| Releaser (OptimismBridgedResourceFirepit) | [0xe0A780E9105aC10Ee304448224Eb4A2b11A77eeB](https://uniscan.xyz/address/0xe0A780E9105aC10Ee304448224Eb4A2b11A77eeB) |
+| UnichainDeployer | [`0xD16c47bf3ae22e0B2BAc5925D990b81416f18dea`](https://uniscan.xyz/address/0xD16c47bf3ae22e0B2BAc5925D990b81416f18dea) |
+| TokenJar | [`0xD576BDF6b560079a4c204f7644e556DbB19140b5`](https://uniscan.xyz/address/0xD576BDF6b560079a4c204f7644e556DbB19140b5) |
+| Releaser (OptimismBridgedResourceFirepit) | [`0xe0A780E9105aC10Ee304448224Eb4A2b11A77eeB`](https://uniscan.xyz/address/0xe0A780E9105aC10Ee304448224Eb4A2b11A77eeB) |
-### Deployment process
+## Optimism: 10
+
+| Contract | Address |
+|----------|---------|
+| Deployer | [`0x3398783D2ffE6F79B56dade84CEAea888C400da4`](https://optimistic.etherscan.io/address/0x3398783D2ffE6F79B56dade84CEAea888C400da4) |
+| TokenJar | [`0xb13285DF724ea75f3f1E9912010B7e491dCd5EE3`](https://optimistic.etherscan.io/address/0xb13285DF724ea75f3f1E9912010B7e491dCd5EE3) |
+| Releaser (OptimismBridgedResourceFirepit) | [`0x94460443Ca27FFC1baeCa61165fde18346C91AbD`](https://optimistic.etherscan.io/address/0x94460443Ca27FFC1baeCa61165fde18346C91AbD) |
+| V3OpenFeeAdapter | [`0xec23Cf5A1db3dcC6595385D28B2a4D9B52503Be4`](https://optimistic.etherscan.io/address/0xec23Cf5A1db3dcC6595385D28B2a4D9B52503Be4) |
+| V4FeeAdapter | [`0xd85393784234fB2ee4f077867A8B78E1aD4cE56B`](https://optimistic.etherscan.io/address/0xd85393784234fB2ee4f077867A8B78E1aD4cE56B) |
+| V4FeePolicy | [`0x13d9D19802660b8167B3c84C1fcDCD0163672eB8`](https://optimistic.etherscan.io/address/0x13d9D19802660b8167B3c84C1fcDCD0163672eB8) |
+
+## BNB Chain: 56
+
+| Contract | Address |
+|----------|---------|
+| SyntheticNttUni | [`0x06e8bdE95BE4ce5cB1134BD47aD18a79fFB35822`](https://bscscan.com/address/0x06e8bdE95BE4ce5cB1134BD47aD18a79fFB35822) |
+| NttManager | [`0x9226AEb835487dD2ed6700A967A8AD25BEE1Dc0E`](https://bscscan.com/address/0x9226AEb835487dD2ed6700A967A8AD25BEE1Dc0E) |
+| WormholeTransceiver | [`0xB89780a55d15CAcA4F5c8828b5B5cf95442C2716`](https://bscscan.com/address/0xB89780a55d15CAcA4F5c8828b5B5cf95442C2716) |
+| TokenJar | [`0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A`](https://bscscan.com/address/0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A) |
+| WormholeReleaser | [`0xa59FfbB55D91Fc32b44A06F0b9cc6036a4afbcE2`](https://bscscan.com/address/0xa59FfbB55D91Fc32b44A06F0b9cc6036a4afbcE2) |
+| V3OpenFeeAdapter | [`0x3F07F08b45912dCd6691C5B9412975D5113B2910`](https://bscscan.com/address/0x3F07F08b45912dCd6691C5B9412975D5113B2910) |
+| V4FeeAdapter | [`0x66276D2e80784180E4B9b859e4327b9C5646B87c`](https://bscscan.com/address/0x66276D2e80784180E4B9b859e4327b9C5646B87c) |
+| V4FeePolicy | [`0x020B1Ad79037f02feC357Ec4601fFbe5f7ED6872`](https://bscscan.com/address/0x020B1Ad79037f02feC357Ec4601fFbe5f7ED6872) |
+
+## Polygon: 137
+
+| Contract | Address |
+|----------|---------|
+| SyntheticNttUni | [`0x06e8bdE95BE4ce5cB1134BD47aD18a79fFB35822`](https://polygonscan.com/address/0x06e8bdE95BE4ce5cB1134BD47aD18a79fFB35822) |
+| NttManager | [`0x9226AEb835487dD2ed6700A967A8AD25BEE1Dc0E`](https://polygonscan.com/address/0x9226AEb835487dD2ed6700A967A8AD25BEE1Dc0E) |
+| WormholeTransceiver | [`0xB89780a55d15CAcA4F5c8828b5B5cf95442C2716`](https://polygonscan.com/address/0xB89780a55d15CAcA4F5c8828b5B5cf95442C2716) |
+| TokenJar | [`0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A`](https://polygonscan.com/address/0xc6Ae6373CEcc9e595A6C8b9fe581925a8c84f70A) |
+| WormholeReleaser | [`0xa59FfbB55D91Fc32b44A06F0b9cc6036a4afbcE2`](https://polygonscan.com/address/0xa59FfbB55D91Fc32b44A06F0b9cc6036a4afbcE2) |
+| V3OpenFeeAdapter | [`0x3F07F08b45912dCd6691C5B9412975D5113B2910`](https://polygonscan.com/address/0x3F07F08b45912dCd6691C5B9412975D5113B2910) |
+| V4FeeAdapter | [`0x59e84309Afa65F084F9c03668583d231afB12cc6`](https://polygonscan.com/address/0x59e84309Afa65F084F9c03668583d231afB12cc6) |
+| V4FeePolicy | [`0x600c29d3Ce95Ce503FAb43753cbcb5Fa87EE6093`](https://polygonscan.com/address/0x600c29d3Ce95Ce503FAb43753cbcb5Fa87EE6093) |
+
+## X Layer: 196
+
+| Contract | Address |
+|----------|---------|
+| CrossChainAccount | [`0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7`](https://www.oklink.com/xlayer/address/0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7) |
+| Deployer | [`0xC943dd90D459dB082D9e9C1baBf89D4Afe79E7E0`](https://www.oklink.com/xlayer/address/0xC943dd90D459dB082D9e9C1baBf89D4Afe79E7E0) |
+| TokenJar | [`0x8Dd8B6D56e4a4A158EDbBfE7f2f703B8FFC1a754`](https://www.oklink.com/xlayer/address/0x8Dd8B6D56e4a4A158EDbBfE7f2f703B8FFC1a754) |
+| Releaser (OptimismBridgedResourceFirepit) | [`0xe122E231cb52aea99690963Fd73E91e33E97468f`](https://www.oklink.com/xlayer/address/0xe122E231cb52aea99690963Fd73E91e33E97468f) |
+| V3OpenFeeAdapter | [`0x6A88EF2e6511CAFfE2D006e260e7A5d1E7D4d7D7`](https://www.oklink.com/xlayer/address/0x6A88EF2e6511CAFfE2D006e260e7A5d1E7D4d7D7) |
+
+## World Chain: 480
+
+| Contract | Address |
+|----------|---------|
+| Deployer | [`0x4E524DAbf30A1D6e87261c804991119181F65bb8`](https://worldscan.org/address/0x4E524DAbf30A1D6e87261c804991119181F65bb8) |
+| TokenJar | [`0xbDb82c2dE7D8748A3e499e771604ef8ef8544918`](https://worldscan.org/address/0xbDb82c2dE7D8748A3e499e771604ef8ef8544918) |
+| Releaser (OptimismBridgedResourceFirepit) | [`0x455e844D286631566cF98D6cb2996149734618C6`](https://worldscan.org/address/0x455e844D286631566cF98D6cb2996149734618C6) |
+| V3OpenFeeAdapter | [`0x1CE9d4DfB474Ef9ea7dc0e804a333202e40d6201`](https://worldscan.org/address/0x1CE9d4DfB474Ef9ea7dc0e804a333202e40d6201) |
+
+## Soneium: 1868
+
+| Contract | Address |
+|----------|---------|
+| CrossChainAccount | [`0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7`](https://soneium.blockscout.com/address/0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7) |
+| Deployer | [`0xD63fFE536bE3f44AE8f33C5f9c81581f9C94d1C8`](https://soneium.blockscout.com/address/0xD63fFE536bE3f44AE8f33C5f9c81581f9C94d1C8) |
+| TokenJar | [`0x85aeb792b94a9d79741002FC871423Ec5dAD29e9`](https://soneium.blockscout.com/address/0x85aeb792b94a9d79741002FC871423Ec5dAD29e9) |
+| Releaser (OptimismBridgedResourceFirepit) | [`0xc9CC50A75cE2a5f88fa77B43e3b050480c731b6e`](https://soneium.blockscout.com/address/0xc9CC50A75cE2a5f88fa77B43e3b050480c731b6e) |
+| V3OpenFeeAdapter | [`0x47Cf920815344Fd684A48BBEFcbfbed9C7AE09CF`](https://soneium.blockscout.com/address/0x47Cf920815344Fd684A48BBEFcbfbed9C7AE09CF) |
+
+## Robinhood Chain: 4663
+
+| Contract | Address |
+|----------|---------|
+| Deployer | [`0x81405C50595f09175d282ccEc657e090EE54AB2E`](https://robinhoodchain.blockscout.com/address/0x81405C50595f09175d282ccEc657e090EE54AB2E) |
+| TokenJar | [`0x2aC03e14Cfe755426DaAEe0a4994184Ce81482F8`](https://robinhoodchain.blockscout.com/address/0x2aC03e14Cfe755426DaAEe0a4994184Ce81482F8) |
+| Releaser | [`0x7a8f74C2585F84c781F951B7f2FF21337D5b630b`](https://robinhoodchain.blockscout.com/address/0x7a8f74C2585F84c781F951B7f2FF21337D5b630b) |
+| V3OpenFeeAdapter | [`0x05C420bC4823e039AA4dA645eDde743486dAAA25`](https://robinhoodchain.blockscout.com/address/0x05C420bC4823e039AA4dA645eDde743486dAAA25) |
+| V4FeeAdapter | [`0x6d0009504D129CF5002Dba61D9Ae8575AA79314c`](https://robinhoodchain.blockscout.com/address/0x6d0009504D129CF5002Dba61D9Ae8575AA79314c) |
+| V4FeePolicy | [`0x6ee984309ba26c224f12Bb85D6F7f3C019483DFc`](https://robinhoodchain.blockscout.com/address/0x6ee984309ba26c224f12Bb85D6F7f3C019483DFc) |
+
+## Base: 8453
+
+| Contract | Address |
+|----------|---------|
+| Deployer | [`0x076f84717f3601B8Cd177bb84b217A2679B38b7d`](https://basescan.org/address/0x076f84717f3601B8Cd177bb84b217A2679B38b7d) |
+| TokenJar | [`0x9bD25e67bF390437C8fAF480AC735a27BcF6168c`](https://basescan.org/address/0x9bD25e67bF390437C8fAF480AC735a27BcF6168c) |
+| Releaser (OptimismBridgedResourceFirepit) | [`0xFf77c0ED0B6b13A20446969107E5867abc46f53a`](https://basescan.org/address/0xFf77c0ED0B6b13A20446969107E5867abc46f53a) |
+| V3OpenFeeAdapter | [`0xaBEA76658b205696d49B5F91b2a03536cB8A3bE1`](https://basescan.org/address/0xaBEA76658b205696d49B5F91b2a03536cB8A3bE1) |
+| V4FeeAdapter | [`0xc53DD825dedBE7814562528A1A30e8e5BCbB4b55`](https://basescan.org/address/0xc53DD825dedBE7814562528A1A30e8e5BCbB4b55) |
+| V4FeePolicy | [`0xf963bdbe8BA2aABBB3190fF2268F3d833393ab71`](https://basescan.org/address/0xf963bdbe8BA2aABBB3190fF2268F3d833393ab71) |
+
+## Arbitrum: 42161
+
+| Contract | Address |
+|----------|---------|
+| Deployer | [`0x3Ac66e1bfC79032C9deFCB23aE4DEe3F8c1630eb`](https://arbiscan.io/address/0x3Ac66e1bfC79032C9deFCB23aE4DEe3F8c1630eb) |
+| TokenJar | [`0x95E337C5B155385945D407f5396387D0c2a3A263`](https://arbiscan.io/address/0x95E337C5B155385945D407f5396387D0c2a3A263) |
+| Releaser | [`0xB8018422bcE25D82E70cB98FdA96a4f502D89427`](https://arbiscan.io/address/0xB8018422bcE25D82E70cB98FdA96a4f502D89427) |
+| V3OpenFeeAdapter | [`0xFF7aD5dA31fECdC678796c88B05926dB896b0699`](https://arbiscan.io/address/0xFF7aD5dA31fECdC678796c88B05926dB896b0699) |
+| V4FeeAdapter | [`0x66276D2e80784180E4B9b859e4327b9C5646B87c`](https://arbiscan.io/address/0x66276D2e80784180E4B9b859e4327b9C5646B87c) |
+| V4FeePolicy | [`0x8F6a5A19Ff1adc6AA9456d6b201fA4FC7589BD0B`](https://arbiscan.io/address/0x8F6a5A19Ff1adc6AA9456d6b201fA4FC7589BD0B) |
+
+## Celo: 42220
+
+| Contract | Address |
+|----------|---------|
+| CrossChainAccount | [`0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7`](https://celoscan.io/address/0x044aAF330d7fD6AE683EEc5c1C1d1fFf5196B6b7) |
+| Deployer | [`0x91Df768dF14E94a3fCa42badBF1907E3a3b0240f`](https://celoscan.io/address/0x91Df768dF14E94a3fCa42badBF1907E3a3b0240f) |
+| TokenJar | [`0x190c22c5085640D1cB60CeC88a4F736Acb59bb6B`](https://celoscan.io/address/0x190c22c5085640D1cB60CeC88a4F736Acb59bb6B) |
+| Releaser (OptimismBridgedResourceFirepit) | [`0x2758FbaA228D7d3c41dD139F47dab1a27bF9bc25`](https://celoscan.io/address/0x2758FbaA228D7d3c41dD139F47dab1a27bF9bc25) |
+| V3OpenFeeAdapter | [`0xB9952C01830306ea2fAAe1505f6539BD260Bfc48`](https://celoscan.io/address/0xB9952C01830306ea2fAAe1505f6539BD260Bfc48) |
+| V4FeeAdapter | [`0xfd39ac616e630e9db03EFB2c9a4Fe63eDB949233`](https://celoscan.io/address/0xfd39ac616e630e9db03EFB2c9a4Fe63eDB949233) |
+| V4FeePolicy | [`0xe1Adf3f130Abf616a7aB04AEeBf8D0470F6B6a16`](https://celoscan.io/address/0xe1Adf3f130Abf616a7aB04AEeBf8D0470F6B6a16) |
+
+## Zora: 7777777
+
+| Contract | Address |
+|----------|---------|
+| Deployer | [`0x71F14F2A8b827cD29453498d5AF24F605caee931`](https://explorer.zora.energy/address/0x71F14F2A8b827cD29453498d5AF24F605caee931) |
+| TokenJar | [`0x4753C137002D802f45302b118E265c41140e73C2`](https://explorer.zora.energy/address/0x4753C137002D802f45302b118E265c41140e73C2) |
+| Releaser (OptimismBridgedResourceFirepit) | [`0x2f98eD4D04e633169FbC941BFCc54E785853b143`](https://explorer.zora.energy/address/0x2f98eD4D04e633169FbC941BFCc54E785853b143) |
+| V3OpenFeeAdapter | [`0xbfc49b47637a4DC9b7B8dE8E71BF41E519103B95`](https://explorer.zora.energy/address/0xbfc49b47637a4DC9b7B8dE8E71BF41E519103B95) |
+
+## Deployment process
+
+The `AssetSink` contract described below is listed as `TokenJar` in the tables above.
To enable fees for v2 and v3 on *mainnet*, the Deployer handles the entire set up in one transaction. Subsequent transactions
will be required to set the initial fee values.
diff --git a/content/protocols/protocol-fee/guides/best-practices.mdx b/content/protocols/protocol-fee/guides/best-practices.mdx
index 1c4759b78..e9e1a8533 100644
--- a/content/protocols/protocol-fee/guides/best-practices.mdx
+++ b/content/protocols/protocol-fee/guides/best-practices.mdx
@@ -1,5 +1,6 @@
---
-title: Best Practices
+title: Protocol Fee Best Practices
+sidebarTitle: Best Practices
description: Apply practical safeguards when integrating with the Uniswap Protocol Fee contracts and release flow.
---
diff --git a/content/protocols/protocol-fee/guides/getting-started.mdx b/content/protocols/protocol-fee/guides/getting-started.mdx
index 51d6162f0..cb2134f42 100644
--- a/content/protocols/protocol-fee/guides/getting-started.mdx
+++ b/content/protocols/protocol-fee/guides/getting-started.mdx
@@ -1,5 +1,6 @@
---
-title: Get Started
+title: Get Started with the Protocol Fee System
+sidebarTitle: Get Started
description: Follow a complete step-by-step flow to call `Firepit.release()` in the Uniswap Protocol Fee system.
---
diff --git a/content/protocols/protocol-fee/overview.mdx b/content/protocols/protocol-fee/overview.mdx
index 85017a4bb..974d1e17b 100644
--- a/content/protocols/protocol-fee/overview.mdx
+++ b/content/protocols/protocol-fee/overview.mdx
@@ -1,5 +1,6 @@
---
title: Uniswap Protocol Fees
+sidebarTitle: Overview
description: Understand how protocol fees flow from Uniswap products into TokenJar and through releaser contracts.
---
@@ -25,20 +26,20 @@ Each protocol component that generates fees (v2, v3, v4, UniswapX, Unichain, and
Immutable contract that receives all tokens from fee sources on a given chain. Only the active Releaser can withdraw from it.
-See the TokenJar contract source for more.
+See the [TokenJar contract source](https://github.com/Uniswap/protocol-fees/blob/main/src/TokenJar.sol) for more.
### Fee adapters
Adapters that connect specific protocol versions or products to the TokenJar. They define how and when fees are collected.
-See the Fee Adapter contract source for more.
+See the [Fee Adapter contract sources](https://github.com/Uniswap/protocol-fees/tree/main/src/feeAdapters) for more.
### Releasers
Contracts that convert collected fees into protocol value according to defined logic.
Examples include the Firepit Releaser, which burns UNI in return for assets.
-See the Releaser contract source for more.
+See the [Releaser contract sources](https://github.com/Uniswap/protocol-fees/tree/main/src/releasers) for more.
## Real-World Example
diff --git a/content/protocols/smart-wallet/concepts/batched-transactions.mdx b/content/protocols/smart-wallet/concepts/batched-transactions.mdx
index 0cc88c89a..ed85775a9 100644
--- a/content/protocols/smart-wallet/concepts/batched-transactions.mdx
+++ b/content/protocols/smart-wallet/concepts/batched-transactions.mdx
@@ -1,5 +1,4 @@
---
-id: batched-transactions
title: Batched Transactions
description: Understand how Uniswap smart wallet supports batched actions and ERC-7821-compatible execution flows.
---
diff --git a/content/protocols/smart-wallet/concepts/delegation.mdx b/content/protocols/smart-wallet/concepts/delegation.mdx
index f86e9e825..a33a27197 100644
--- a/content/protocols/smart-wallet/concepts/delegation.mdx
+++ b/content/protocols/smart-wallet/concepts/delegation.mdx
@@ -1,5 +1,4 @@
---
-id: delegation
title: Delegation
description: Learn how EIP-7702 delegation enables Uniswap smart wallet account behavior while preserving EOA addresses.
---
diff --git a/content/protocols/smart-wallet/concepts/hooks.mdx b/content/protocols/smart-wallet/concepts/hooks.mdx
index 231ec01f0..dc02401dd 100644
--- a/content/protocols/smart-wallet/concepts/hooks.mdx
+++ b/content/protocols/smart-wallet/concepts/hooks.mdx
@@ -1,6 +1,6 @@
---
-id: hooks
-title: Hooks
+title: Smart Wallet Hooks
+sidebarTitle: Hooks
description: Understand validation and execution hooks in Uniswap smart wallet, including call sites and integration cautions.
---
diff --git a/content/protocols/smart-wallet/deployments.mdx b/content/protocols/smart-wallet/deployments.mdx
index 6cd28f881..c1639fac6 100644
--- a/content/protocols/smart-wallet/deployments.mdx
+++ b/content/protocols/smart-wallet/deployments.mdx
@@ -1,10 +1,12 @@
---
-id: deployments
-title: Deployments
+title: Smart Wallet Deployments
+sidebarTitle: Deployments
description: View Uniswap smart wallet Calibur deployment addresses, versions, and repository references.
---
-
+
+ All Smart Wallet deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
## Deployment Addresses
diff --git a/content/protocols/smart-wallet/guides/best-practices.mdx b/content/protocols/smart-wallet/guides/best-practices.mdx
index 0d4599932..e0eff1ba3 100644
--- a/content/protocols/smart-wallet/guides/best-practices.mdx
+++ b/content/protocols/smart-wallet/guides/best-practices.mdx
@@ -1,5 +1,6 @@
---
-title: Best Practices
+title: Smart Wallet Best Practices
+sidebarTitle: Best Practices
description: Apply practical security best practices when integrating Uniswap smart wallet Calibur features into production flows.
---
diff --git a/content/protocols/smart-wallet/overview.mdx b/content/protocols/smart-wallet/overview.mdx
index 18c16ee04..9294bcbff 100644
--- a/content/protocols/smart-wallet/overview.mdx
+++ b/content/protocols/smart-wallet/overview.mdx
@@ -1,7 +1,33 @@
---
-id: overview
title: Smart Wallet Overview
+sidebarTitle: Overview
description: Learn how Uniswap smart wallet uses the Calibur implementation with EIP-7702 delegation across supported networks.
+keywords:
+ - smart wallet
+ - EIP-7702
+ - delegation
+ - gas abstraction
+ - batched transactions
+ - ERC-7739
+faqs:
+ - question: What is EIP-7702 delegation, and does it change my account address?
+ answer: |-
+ No. Your address and onchain history stay the same. Delegation is the EIP-7702 process where an Externally Owned Account (EOA) points to code deployed at a remote smart contract address, called the implementation. After the Pectra fork, an EOA can internalize that code and execute transactions using the implementation logic while keeping its original address and onchain history. Uniswap smart wallet uses the Calibur implementation for this.
+ - question: Can I delegate to more than one implementation at a time?
+ answer: |-
+ No. A user can only be delegated to one contract at a time on a given chain. You can, however, have separate delegations on different chains, since delegation state is tracked per chain. To move to a different implementation on the same chain, you replace the existing delegation rather than adding a second one.
+ - question: What are batched transactions, and when would I use them?
+ answer: |-
+ Batched transactions combine multiple actions in the same execution flow. A common example is approving an ERC-20 token and then swapping that token in a single batched flow, rather than sending two separate transactions. Uniswap smart wallet supports simple batch calls and the ERC-7821 Minimal Batch Executor Interface, which improves interoperability between dapps and contract implementations.
+ - question: How does gas abstraction let someone else pay for gas?
+ answer: |-
+ Gas abstraction allows a user to transact without holding ETH to pay for gas. A third party called a bundler can cover or manage those fees on the user's behalf. Uniswap smart wallet implements ERC-4337, Account Abstraction Using Alt Mempool. By default, EntryPoint v0.8 is enabled on the account; see the gas abstraction concept page for the address. The root signer can disable or change this, but doing so incorrectly can lead to loss of funds.
+ - question: What is ERC-7739, and which signatures does it apply to?
+ answer: |-
+ ERC-7739 defines a defensive rehashing model for external signers on smart contract accounts. In Uniswap smart wallet it is enforced for all alternative keys added to an account, but does not apply to signatures from the root EOA, the account delegated to the implementation. It protects signatures from being replayed across accounts by binding the signed data to the account and chain. The standard is still in draft.
+ - question: What does Calibur add on top of a plain EOA?
+ answer: |-
+ Calibur is the contract implementation that a user delegates to through EIP-7702. Once delegated, the account can batch multiple actions into one flow, use gas abstraction so a third party can pay fees, and apply custom permission controls through alternative signers. Calibur is deployed to the same address across supported networks, is non-upgradeable, and has no owner.
---
Uniswap smart wallet features are powered by [Calibur](/docs/protocols/smart-wallet/deployments), a contract implementation designed for [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702).
@@ -14,6 +40,90 @@ Uniswap smart wallet features are powered by [Calibur](/docs/protocols/smart-wal
Users delegate to the implementation through EIP-7702 and then use smart wallet features while keeping the same EOA address.
+## FAQ
+
+
+ What is EIP-7702 delegation, and does it change my account address?
+
+
+
+ No. Your address and onchain history stay the same. [Delegation](/docs/protocols/smart-wallet/concepts/delegation) is the [EIP-7702](https://eips.ethereum.org/EIPS/eip-7702) process where an Externally Owned Account (EOA) points to code deployed at a remote smart contract address, called the *implementation*. After the Pectra fork, an EOA can internalize that code and execute transactions using the implementation logic while keeping its original address and onchain history.
+
+ Uniswap smart wallet uses the [Calibur](/docs/protocols/smart-wallet/deployments) implementation for this.
+
+
+
+
+
+
+ Can I delegate to more than one implementation at a time?
+
+
+
+ No. A user can only be delegated to one contract at a time on a given chain. You can, however, have separate delegations on different chains, since delegation state is tracked per chain.
+
+ To move to a different implementation on the same chain, you replace the existing delegation rather than adding a second one.
+
+
+
+
+
+
+ What are batched transactions, and when would I use them?
+
+
+
+ [Batched transactions](/docs/protocols/smart-wallet/concepts/batched-transactions) combine multiple actions in the same execution flow. A common example is approving an ERC-20 token and then swapping that token in a single batched flow, rather than sending two separate transactions.
+
+ Uniswap smart wallet supports simple batch calls and [ERC-7821](https://eips.ethereum.org/EIPS/eip-7821), the Minimal Batch Executor Interface, which improves interoperability between dapps and contract implementations.
+
+
+
+
+
+
+ How does gas abstraction let someone else pay for gas?
+
+
+
+ [Gas abstraction](/docs/protocols/smart-wallet/concepts/gas-abstraction) allows a user to transact without holding ETH to pay for gas. A third party called a [bundler](https://www.alchemy.com/overviews/what-is-a-bundler) can cover or manage those fees on the user's behalf. Uniswap smart wallet implements [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337), Account Abstraction Using Alt Mempool.
+
+ By default, EntryPoint v0.8 is enabled on the account; see [Gas Abstraction](/docs/protocols/smart-wallet/concepts/gas-abstraction) for the address. The root signer can disable or change this, but doing so incorrectly can lead to loss of funds.
+
+
+
+
+
+
+ What is ERC-7739, and which signatures does it apply to?
+
+
+
+ [ERC-7739](/docs/protocols/smart-wallet/concepts/erc-7739) defines a defensive rehashing model for external signers on smart contract accounts. In Uniswap smart wallet it is enforced for all alternative keys added to an account, but does not apply to signatures from the root EOA, the account delegated to the implementation.
+
+ It protects signatures from being replayed across accounts by binding the signed data to the account and chain. The [standard](https://eips.ethereum.org/EIPS/eip-7739) is still in draft.
+
+
+
+
+
+
+ What does Calibur add on top of a plain EOA?
+
+
+
+ [Calibur](/docs/protocols/smart-wallet/deployments) is the contract implementation that a user delegates to through EIP-7702. Once delegated, the account can:
+
+ * Batch multiple actions into one flow.
+ * Use gas abstraction so a third party can pay fees.
+ * Apply custom permission controls through alternative signers.
+
+ Calibur is deployed to the same address across supported networks, is non-upgradeable, and has no owner.
+
+
+
+
+
## Where to Go Next
- Explore core smart wallet patterns in [Concepts](/docs/protocols/smart-wallet/concepts/delegation).
diff --git a/content/protocols/the-compact/concepts/arbiters.mdx b/content/protocols/the-compact/concepts/arbiters.mdx
index 14a56a47a..60f33409a 100644
--- a/content/protocols/the-compact/concepts/arbiters.mdx
+++ b/content/protocols/the-compact/concepts/arbiters.mdx
@@ -1,5 +1,4 @@
---
-id: arbiters
title: Arbiters
description: Learn how arbiters verify conditions and submit claims for Uniswap The Compact single-chain and multichain compacts.
---
diff --git a/content/protocols/the-compact/concepts/compacts.mdx b/content/protocols/the-compact/concepts/compacts.mdx
index dd80431b1..2ee4fa36d 100644
--- a/content/protocols/the-compact/concepts/compacts.mdx
+++ b/content/protocols/the-compact/concepts/compacts.mdx
@@ -1,5 +1,4 @@
---
-id: compacts-eip712
title: Compacts & EIP-712
description: Understand Uniswap The Compact agreement formats, witness data, and EIP-712 signing or registration workflows.
---
diff --git a/content/protocols/the-compact/concepts/core-interfaces.mdx b/content/protocols/the-compact/concepts/core-interfaces.mdx
index 86bcc0f31..cbd4075a9 100644
--- a/content/protocols/the-compact/concepts/core-interfaces.mdx
+++ b/content/protocols/the-compact/concepts/core-interfaces.mdx
@@ -1,5 +1,4 @@
---
-id: core-interfaces
title: Core Interfaces
description: Reference key Uniswap The Compact interfaces for deposits, registration, claims, allocator checks, and emissary verification.
---
diff --git a/content/protocols/the-compact/concepts/periphery-contracts.mdx b/content/protocols/the-compact/concepts/periphery-contracts.mdx
index 0e0fd0e0d..8d92037cb 100644
--- a/content/protocols/the-compact/concepts/periphery-contracts.mdx
+++ b/content/protocols/the-compact/concepts/periphery-contracts.mdx
@@ -1,5 +1,4 @@
---
-id: Periphery Contracts
title: Periphery Contracts
description: Understand emissaries and Tribunal as peripheral patterns that integrate with Uniswap The Compact claim verification flows.
---
diff --git a/content/protocols/the-compact/overview.mdx b/content/protocols/the-compact/overview.mdx
index 91cb4951a..b15b27090 100644
--- a/content/protocols/the-compact/overview.mdx
+++ b/content/protocols/the-compact/overview.mdx
@@ -1,6 +1,6 @@
---
-id: overview
title: The Compact Overview
+sidebarTitle: Overview
description: Learn how Uniswap The Compact coordinates resource locks, compacts, and claims across single-chain and multichain flows.
---
diff --git a/content/protocols/uniswap-labs-hooks/index.mdx b/content/protocols/uniswap-labs-hooks/index.mdx
new file mode 100644
index 000000000..d6867ee5a
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/index.mdx
@@ -0,0 +1,15 @@
+---
+title: Overview
+description: This is the technical repository for production-ready v4 hooks designed and maintained by Uniswap Labs. Every hook is open source and ready to be deployed.
+keywords: ["Uniswap Labs Hooks", "v4 hooks", "production-ready hooks"]
+---
+
+| Hook | Core Mechanism | Primary Technology | Get Started |
+| :--- | :--- | :--- | :--- |
+| **LitePSM** | Facilitates gas-efficient USDC <> USDS conversions in a hook. | Peg Stability Module | [Link](https://github.com/Uniswap/v4-hooks-public/blob/main/src/aggregator-hooks/implementations/LitePSM/LitePSMAggregator.sol) |
+| **Permissioned Pools** | Restricts swaps and liquidity provision to allowlisted addresses. | ERC6909 Wrapped Token Proxy | [Link](/docs/protocols/uniswap-labs-hooks/permissioned-pools/overview) |
+| **StablePair Hook** | Concentrates liquidity around a reference price for assets that should trade at a fixed rate. | Custom Pricing Logic | [Link](/docs/protocols/uniswap-labs-hooks/stable-pair/overview) |
+| **WETH <> ETH** | Facilitates WETH <> ETH conversions in a hook. | Wraps core conversion contract | [Link](https://github.com/Uniswap/v4-hooks-public/blob/main/src/WETHHook.sol) |
+| **wstETH <> stETH** | Facilitates wstETH <> stETH conversions in a hook. | Wraps core conversion contract | [Link](https://github.com/Uniswap/v4-hooks-public/blob/main/src/WstETHHook.sol) |
+
+For bespoke infrastructure or custom asset class support, [get in touch](/uniswap-labs-hooks) with our team.
diff --git a/content/protocols/uniswap-labs-hooks/meta.json b/content/protocols/uniswap-labs-hooks/meta.json
new file mode 100644
index 000000000..24c8d591d
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/meta.json
@@ -0,0 +1,4 @@
+{
+ "title": "Uniswap Labs Hooks",
+ "pages": ["index", "permissioned-pools", "stable-pair"]
+}
diff --git a/content/protocols/uniswap-labs-hooks/permissioned-pools/architecture.mdx b/content/protocols/uniswap-labs-hooks/permissioned-pools/architecture.mdx
new file mode 100644
index 000000000..1ecc69b84
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/permissioned-pools/architecture.mdx
@@ -0,0 +1,89 @@
+---
+title: Permissioned Pools Architecture
+sidebarTitle: Architecture
+description: Explore the contracts behind Uniswap v4 permissioned pools, including the Permissions Adapter, hooks, position manager, and routing.
+---
+
+Permissioned pools are built from four contracts that work together to enforce an issuer's allowlist while keeping the permissioned token compatible with the standard `PoolManager`.
+
+## The Permissions Adapter
+
+The Permissions Adapter is the ERC-20 contract at the center of this design. It holds the underlying permissioned token and mints a virtual version of it that the pool trades, so the underlying token never enters the `PoolManager` directly. The adapter and the virtual token are the same contract.
+
+Creating the virtual token and converting it back to the original are handled automatically. Swappers and liquidity providers interact with the token as usual, and the router and position manager perform these conversions behind the scenes, so end users never manage the virtual token themselves. The virtual token is necessary for two reasons:
+
+- **The `PoolManager` allowlist cannot be enforced directly.** The `PoolManager` is a single shared contract, so it cannot be added to every issuer's allowlist. The adapter acts as the approved holder of the underlying token and keeps the raw asset out of the `PoolManager`.
+- **Direct holding would expose the token as a freely tradable claim.** A permissioned token held directly by the `PoolManager` could be minted into an ERC-6909 claim and traded without the allowlist. The adapter prevents this by restricting minting to authorized periphery contracts, such as the position manager, router, and quoters the issuer approves.
+
+See the [`PermissionsAdapter` source](https://github.com/Uniswap/v4-periphery/blob/main/src/hooks/permissionedPools/PermissionsAdapter.sol) in `v4-periphery`.
+
+- **Pool manager exclusivity:** only the `PoolManager` can hold the virtual token. When it is transferred out of the pool, the adapter burns it and releases the underlying token in the same call.
+- **Pluggable allowlist:** the adapter delegates permission checks to an allowlist checker that the issuer implements and deploys.
+
+
+
+The adapter exposes several administrative functions for the permissioned token issuer:
+
+- **`updateAllowListChecker`:** update the pluggable validation contract that decides who is authorized to swap the token or provide liquidity.
+- **`updateAllowedWrapper`:** approve or revoke a contract, such as a router, position manager, or quoter, that can create a virtual version of the token.
+- **`updateSwappingEnabled`:** enable, pause, or resume swapping for the token. Swapping is disabled by default on a new adapter.
+- **`updateAllowedHook`:** allow or revoke a hook for the adapter. Position mints and liquidity increases revert with `InvalidHook` unless the pool's hook is allowed. The position manager and the router both read this from the adapter, so one call covers every periphery contract.
+
+## Permissioned Hooks
+
+The permissioned hook enforces the allowlist on every interaction. Like any v4 hook, it is attached to a pool at initialization through the `PoolKey`. It activates four callbacks:
+
+- `beforeInitialize` queries the `PermissionsAdapterFactory`, requires at least one pool currency to be a factory-verified adapter, and rejects any currency that is an unverified adapter, so a pool cannot be created around an unverified Permissions Adapter.
+- `beforeSwap` checks the `SWAP_ALLOWED` flag for the swapper, and also reverts while the issuer has swapping paused via `updateSwappingEnabled`.
+- `afterSwap` emits a `Swap` event so indexers can track activity on permissioned pools.
+- `beforeAddLiquidity` checks the `LIQUIDITY_ALLOWED` flag before a position is minted.
+
+Permissions are expressed as flags: `SWAP_ALLOWED` (`0x0001`) and `LIQUIDITY_ALLOWED` (`0x0002`). The hook also confirms that the calling router or position manager is approved to create virtual versions of the token (via `updateAllowedWrapper`), which is why the issuer must approve the contracts that can interact with the pool.
+
+## Permissioned Position Manager
+
+The Permissioned Position Manager extends the standard `PositionManager`, adding allowlist enforcement and automatic creation of the virtual token.
+
+- **Non-transferable NFTs:** position transfers revert, which prevents an allowlisted holder from handing a position to a disallowed address.
+- **Position unwinding:** the owner of either Permissions Adapter in the pool can call `unwindPosition` to burn a position NFT, remove its liquidity, and route each asset back to the holder. Any asset the holder can no longer receive falls back to that asset's own issuer (as tokens, or as an ERC-6909 claim if delivery fails), so unwinding never lets one issuer receive the other's asset.
+- **Automatic conversion:** the position manager creates a virtual version of the permissioned token before interacting with the pool and validates the holder against the allowlist on mint and increase.
+
+
+When building a pool key, supply the **adapter address** as the currency, not the underlying permissioned token. The same applies when settling and taking.
+
+
+
+
+
+When a position is unwound, each asset routes to the holder first. An asset the holder can no longer receive falls back to its own issuer, never to the other issuer.
+
+
+## Swap Routing
+
+Swaps go through the [Universal Router](/docs/trading/swapping-api/supported-chains#universal-router-version), which converts permissioned tokens to and from their virtual versions. The router identifies the permissioned token in the swap path, creates a virtual version of it before the pool interaction, executes the swap with the virtual token, and converts back to the original token automatically on exit. The allowlist is enforced twice: by the router when it creates the virtual version of the input token, and by the hook on `beforeSwap`, so the restriction cannot be bypassed.
+
+
+Permissioned swap routing requires [Universal Router](/docs/trading/swapping-api/supported-chains#universal-router-version) 2.2.0 or higher.
+
+
+
+
+## Adapter Verification
+
+A factory deploys and verifies adapters. Verification confirms that an adapter is allowed to hold its underlying token: the issuer seeds the adapter with a minimal balance, as little as 1 wei, which is only possible if the adapter is on the token's allowlist. See [Step 3](/docs/protocols/uniswap-labs-hooks/permissioned-pools/deploy-a-permissioned-pool#step-3-allowlist-and-fund-the-adapter) and [Step 4](/docs/protocols/uniswap-labs-hooks/permissioned-pools/deploy-a-permissioned-pool#step-4-verify-the-adapter) for the mechanics. The factory records a mapping from each adapter to its underlying token, never the reverse.
+
+Factory verification is separate from the ERC-165 check on the allowlist checker. Factory verification proves the adapter holds a real balance of its token, while ERC-165 only confirms that a checker implements `IAllowlistChecker`.
+
+## Security Considerations
+
+- **Issuer recall:** if a holder loses permissions, the Permissions Adapter owner can call `unwindPosition` to remove their liquidity and route the assets back. Assets that cannot be delivered to the holder fall back to the issuer, so an issuer can always reclaim exposure to a permissioned token when required.
+- **Non-custodial design:** user funds can only leave the pool through `PoolManager` settlement flows: swaps, position withdrawals, and claim redemptions. They never leave through the virtual token directly.
+- **Access control:** the Permissions Adapter owner can change the allowlist checker, approve or revoke the contracts that can create virtual tokens, and pause swapping. The owner cannot transfer positions or pull funds directly through the virtual token; unwinding routes assets to the holder first, and the issuer receives an asset only when the holder can no longer hold it. The factory and hook are shared contracts that Uniswap deploys, and they are not issuer-controlled.
+- **Reverse mapping:** the factory maps each adapter to its underlying token, never the reverse, which stops anyone from registering an arbitrary allowlist check against an existing ERC-20.
+- **Unwinding in dual-permissioned pools:** pools with two permissioned tokens from different issuers, for example two tokenized funds in the same sector, are fully supported. Either Permissions Adapter owner can unwind a position, and each asset routes to the holder first. An asset the holder can no longer receive falls back to its own issuer only, so one issuer cannot seize the other's asset.
+
+## Where to Go Next
+
+- Onboard a token in [Deploy a Permissioned Pool](/docs/protocols/uniswap-labs-hooks/permissioned-pools/deploy-a-permissioned-pool).
+- Integrate permissioned tokens in an app with [Swapping through Permissioned Pools](/docs/trading/swapping-api/swapping-permissioned-pools).
+- Review hook fundamentals in [Hooks](/docs/protocols/v4/concepts/hooks).
diff --git a/content/protocols/uniswap-labs-hooks/permissioned-pools/deploy-a-permissioned-pool.mdx b/content/protocols/uniswap-labs-hooks/permissioned-pools/deploy-a-permissioned-pool.mdx
new file mode 100644
index 000000000..c1cd2d0e8
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/permissioned-pools/deploy-a-permissioned-pool.mdx
@@ -0,0 +1,253 @@
+---
+title: Deploy a Permissioned Pool
+description: Deploy a permissioned pool on Uniswap v4 by creating an allowlist checker and a Permissions Adapter.
+---
+
+This guide walks a permissioned asset issuer through onboarding a permissioned token so it can trade in a Uniswap v4 permissioned pool. Rather than building custom infrastructure, you use the shared `PermissionsAdapterFactory` and `PermissionedHooks` that Uniswap deploys and maintains, while keeping direct administrative control over your compliance rules.
+
+
+ You will need contract addresses throughout this guide. They are listed under [Deployment
+ Addresses](#deployment-addresses) below, and on the unified [Deployments](/deployments) page and
+ its [deployments.json](/deployments.json) feed. Permissioned pools use their own Universal Router
+ build, so use the address listed there rather than the standard one.
+
+
+At a high level, onboarding is seven steps:
+
+1. **Implement an allowlist checker.** Define the compliance logic that decides who is authorized to swap or provide liquidity.
+2. **Create the Permissions Adapter.** Use the factory to deploy the contract that issues the virtual version of your token and acts as its pool-facing proxy.
+3. **Allowlist and fund the adapter.** Add the adapter to your token's allowlist and seed it with at least 1 wei so it can be verified.
+4. **Verify the adapter.** Register it with the factory so the protocol recognizes it as a legitimate adapter.
+5. **Approve virtual token contracts.** Authorize the position manager, router, and quoters that are allowed to create the virtual version of your token, and allow the permissioned hook on the adapter.
+6. **Create the pool.** Initialize the pool with the adapter as a currency and the permissioned hook, then enable swapping on the adapter.
+7. **Allowlist your pool for routing.** Register with Uniswap Labs so the pool is eligible for routing in the Uniswap interface and API.
+
+The steps below walk through each in detail.
+
+
+
+
+A permissioned pool does not by itself restrict who can hold the token. The token's allowlist does that, and the pool enforces those rules onchain for swaps and liquidity. Make sure your allowlist reflects any requirements that apply to your asset before deploying.
+
+
+## Prerequisites
+
+- A deployed ERC-20 permissioned token. The virtual token is always named `Uniswap v4 ` with symbol `v4`, read from your token's `name()`, `symbol()`, and `decimals()`. When those are missing, it falls back to `Uniswap v4 Permissioned Token`, `v4PT`, and `18` decimals, so exposing them is recommended.
+- A way to determine which addresses are allowed to swap or provide liquidity.
+- The address of the `PermissionsAdapterFactory` and `PermissionedHooks` for your target network. See [Deployment Addresses](#deployment-addresses).
+
+Developing with Uniswap v4 _requires [foundry](https://book.getfoundry.sh)_. The permissioned pools contracts are not in a published npm release yet — the latest `@uniswap/v4-periphery` on npm predates them — so install them from source with the commit pinned:
+
+```bash
+forge install Uniswap/v4-periphery@3245c3cb99c48fa1dc2459c3b60abc37d4294aba
+forge install OpenZeppelin/openzeppelin-contracts@v5.0.2
+```
+
+In the `remappings.txt`, add the following:
+
+```
+@uniswap/v4-periphery/=lib/v4-periphery/
+@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/
+```
+
+`v4-periphery` has no release tags, so pinning the commit is what keeps the import paths below resolving to the code this guide describes.
+
+## Step 1: Implement an Allowlist Checker
+
+The adapter delegates permission checks to a contract you implement. It must satisfy the [`IAllowlistChecker`](https://github.com/Uniswap/v4-periphery/blob/3245c3cb99c48fa1dc2459c3b60abc37d4294aba/src/hooks/permissionedPools/interfaces/IAllowlistChecker.sol) interface, which is an `IERC165`. The `checkAllowlist` function returns a `PermissionFlag` for a given account and token. A single checker can therefore serve multiple assets.
+
+```solidity
+import {IAllowlistChecker} from "@uniswap/v4-periphery/src/hooks/permissionedPools/interfaces/IAllowlistChecker.sol";
+import {PermissionFlag, PermissionFlags} from "@uniswap/v4-periphery/src/hooks/permissionedPools/libraries/PermissionFlags.sol";
+import {ERC165, IERC165} from "@openzeppelin/contracts/utils/introspection/ERC165.sol";
+
+contract MyAllowlistChecker is IAllowlistChecker, ERC165 {
+ // Map each approved account to its granted permissions.
+ mapping(address account => PermissionFlag) public permissions;
+
+ // Return the permissions granted to `account` for `tokenAddress`.
+ // PermissionFlags.SWAP_ALLOWED and PermissionFlags.LIQUIDITY_ALLOWED can be combined.
+ function checkAllowlist(address account, address tokenAddress)
+ external
+ view
+ returns (PermissionFlag)
+ {
+ return permissions[account];
+ }
+
+ // Owner-controlled setter to manage the allowlist (access control omitted for brevity).
+ function setPermissions(address account, PermissionFlag permission) external {
+ permissions[account] = permission;
+ }
+
+ // ERC-165 lets the adapter confirm this is a valid allowlist checker.
+ // This is separate from factory verification of the adapter itself.
+ function supportsInterface(bytes4 interfaceId)
+ public
+ view
+ override(ERC165, IERC165)
+ returns (bool)
+ {
+ return interfaceId == type(IAllowlistChecker).interfaceId || super.supportsInterface(interfaceId);
+ }
+}
+```
+
+## Step 2: Create a Permissions Adapter
+
+Call `createPermissionsAdapter` on the factory with your permissioned token, the admin address that will own the adapter, and your allowlist checker. The factory deploys an adapter scoped to your token.
+
+```solidity
+address adapter = factory.createPermissionsAdapter(
+ IERC20(permissionedToken),
+ issuerAdmin, // adapter owner: holds admin control over the pool
+ IAllowlistChecker(myChecker)
+);
+```
+
+
+The admin address becomes the adapter owner and holds admin control over the pool. It can change the allowlist checker, approve or revoke the contracts that can create virtual tokens, pause swapping, and unwind positions. This is a high-leverage key, so secure it accordingly, for example with a multisig.
+
+
+## Step 3: Allowlist and Fund the Adapter
+
+The adapter must be able to hold your permissioned token. Add the adapter address to your token's allowlist, then transfer a small balance so the factory can verify it. The amount can be as little as 1 wei.
+
+```solidity
+// 1. On your permissioned token, allow the adapter to hold the token.
+// 2. Seed the adapter so it holds a non-zero balance.
+PermissionsAdapter(adapter).depositForVerification(1);
+```
+
+## Step 4: Verify the Adapter
+
+Verification confirms the adapter is allowed to hold your token. It succeeds only when the adapter holds a non-zero balance of the permissioned token.
+
+```solidity
+factory.verifyPermissionsAdapter(adapter);
+```
+
+## Step 5: Approve Virtual Token Contracts
+
+Approve the contracts that are allowed to create the virtual version of your token and redeem the original: the Permissioned Position Manager, the Universal Router, and both quoters (`V4Quoter` and `MixedRouteQuoterV2`) used for pricing. Onchain, these are called *allowed wrappers*, which is why the function below is named `updateAllowedWrapper`. All four addresses are listed in [Deployment Addresses](#deployment-addresses) below.
+
+```solidity
+PermissionsAdapter(adapter).updateAllowedWrapper(permissionedPositionManager, true);
+PermissionsAdapter(adapter).updateAllowedWrapper(universalRouter, true);
+PermissionsAdapter(adapter).updateAllowedWrapper(v4Quoter, true);
+PermissionsAdapter(adapter).updateAllowedWrapper(mixedRouteQuoterV2, true);
+```
+
+Then, allow `PermissionedHooks` on the adapter itself. Only the adapter owner can call this, and without it every attempt to mint a liquidity position reverts with `InvalidHook`.
+
+```solidity
+PermissionsAdapter(adapter).updateAllowedHook(IHooks(permissionedHooks), true);
+```
+
+## Step 6: Create the Pool
+
+Create the pool with the **adapter address** as the currency and `PermissionedHooks` as the hook. The hook reverts on initialization unless at least one currency is a verified adapter.
+
+```solidity
+PoolKey memory key = PoolKey({
+ currency0: Currency.wrap(adapter), // the adapter, not the underlying token
+ currency1: Currency.wrap(weth),
+ fee: 3000,
+ tickSpacing: 60,
+ hooks: IHooks(permissionedHooks)
+});
+```
+
+Finally, enable swapping on the adapter. Swapping is disabled by default on a new adapter, so swaps revert with `SwappingDisabled` until the owner turns it on.
+
+```solidity
+PermissionsAdapter(adapter).updateSwappingEnabled(true);
+```
+
+## Step 7: Allowlist Your Pool for Routing
+
+To be eligible for routing in the Uniswap interface and API, your permissioned pool must be allowlisted with Uniswap Labs. Once your adapter is verified, [request allowlisting](/permissioned-pools-allowlist) with the details below, and the team follows up to complete onboarding.
+
+Uniswap Labs reviews this request manually. It is not self-serve, and submitting the form does not enable routing by itself.
+
+Allowlisting is required on every network, including mainnet and Sepolia. One request can cover several networks, so list them all in the Chain(s) field.
+
+
+This form is for issuers with a deployed, verified permissioned token. If you are still exploring and want the team to reach out, use the [Uniswap Labs Hooks interest form](/uniswap-labs-hooks) instead.
+
+
+
+
+Requests are reviewed as they are received, but they may take varying time to consider. Submit your request as soon as your adapter is verified onchain, to give the request the most time possible before your intended launch date. Uniswap cannot guarantee that a review or an allowlisting takes place before any given launch date, but we get back to you as quickly as we can.
+
+
+
+### What the form asks for
+
+Have these ready before you open the form. Every field is required except last name and notes. You also must accept the terms and privacy notice.
+
+- First name and last name.
+- Email and Telegram handle.
+- Company and company location.
+- Token issuer.
+- The chain or chains you want routing on.
+- A CoinGecko API link for your token logo.
+- Permissioned token address, verified adapter address, and KYC URL.
+- Notes.
+
+A monitored Telegram handle matters, because the team uses it to reach you with any questions about your submission. Uniswap does not work with CoinGecko to make sure logos are available and accurate, so contact CoinGecko and get your logo set before you submit this form.
+
+During onboarding, the following values are added to the backend configuration:
+
+- **Permissioned token address** (the token wallets hold).
+- **Verified adapter address** (the Permissions Adapter created in Step 2 and verified in Step 4).
+- **KYC URL** (where unapproved users complete verification).
+
+The configuration entry looks like this:
+
+```typescript
+// Keyed by the permissioned token address, lowercased.
+'0x...permissionedtokenaddress': {
+ adapterTokenAddress: '0x...verifiedadapteraddress',
+ kycUrl: 'https://your-kyc-provider.example/verify',
+ issuer: 'Your Issuer Name',
+},
+```
+
+
+Addresses must be lowercase. When the adapter and the permissioned token share an address, the token already behaves as its own adapter.
+
+
+## Deployment Addresses
+
+The Permissions Adapter Factory, the Permissioned Position Manager, the hook, and the Universal Router are builds specific to permissioned pools, so use these addresses rather than the standard v4 equivalents. The two quoters are the standard Uniswap deployments, unchanged for permissioned pools.
+
+### Ethereum mainnet
+
+| Contract | Address |
+| --- | --- |
+| `PermissionsAdapterFactory` | 0x7DA911490Ca4663E572eA9C8154f3CdEbCE16452 |
+| `PermissionedPositionManager` | 0x63Bd7e5D4EcfAA74d82AE1dE98F476C935a81973 |
+| `PermissionedHooks` | 0x499a724Ab630549f14C995EC41a8E04fA3fd28c0 |
+| Universal Router | 0xab863E752Bf67D8DCDD929EaAe9Be9dc83Fb3BbB |
+| `V4Quoter` | 0x52F0E24D1c21C8A0cB1e5a5dD6198556BD9E1203 |
+| `MixedRouteQuoterV2` | 0xE63C5F5005909E96b5aA9CE10744CCE70eC16CC3 |
+
+### Sepolia testnet
+
+| Contract | Address |
+| --- | --- |
+| `PermissionsAdapterFactory` | 0xE6B0d96919334C33d06266d1420F97f6f434fA2B |
+| `PermissionedPositionManager` | 0xf99D553912084c99F6299291b75Fe9B7119Aa1A7 |
+| `PermissionedHooks` | 0x51247E2291d290d17C08813A175AC86465EdE8c0 |
+| Universal Router | 0x5093f1CDED83d99FfEd6602dA6260672ae16787c |
+| `V4Quoter` | 0x61B3f2011A92d183C7dbaDBdA940a7555Ccf9227 |
+| `MixedRouteQuoterV2` | 0x4745F77b56a0E2294426E3936dc4Fab68d9543Cd |
+
+Swaps involving a permissioned token route through the Universal Router rather than a standalone router.
+
+## Where to Go Next
+
+- Understand the contracts in [Architecture](/docs/protocols/uniswap-labs-hooks/permissioned-pools/architecture).
+- Add liquidity as an allowlisted LP in [Provide Liquidity](/docs/protocols/uniswap-labs-hooks/permissioned-pools/provide-liquidity).
+- Integrate the token in an app with [Swapping through Permissioned Pools](/docs/trading/swapping-api/swapping-permissioned-pools).
diff --git a/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-architecture.png b/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-architecture.png
new file mode 100644
index 000000000..f2dca2525
Binary files /dev/null and b/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-architecture.png differ
diff --git a/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-liquidity.png b/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-liquidity.png
new file mode 100644
index 000000000..f2f3f179a
Binary files /dev/null and b/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-liquidity.png differ
diff --git a/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-onboarding.png b/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-onboarding.png
new file mode 100644
index 000000000..7a6a1e688
Binary files /dev/null and b/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-onboarding.png differ
diff --git a/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-swap-flow.png b/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-swap-flow.png
new file mode 100644
index 000000000..387104ac9
Binary files /dev/null and b/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-swap-flow.png differ
diff --git a/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-virtual-token.png b/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-virtual-token.png
new file mode 100644
index 000000000..4a03a38d8
Binary files /dev/null and b/content/protocols/uniswap-labs-hooks/permissioned-pools/images/permissioned-pools-virtual-token.png differ
diff --git a/content/protocols/uniswap-labs-hooks/permissioned-pools/meta.json b/content/protocols/uniswap-labs-hooks/permissioned-pools/meta.json
new file mode 100644
index 000000000..5c38c30af
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/permissioned-pools/meta.json
@@ -0,0 +1,4 @@
+{
+ "title": "Permissioned Pools Hook",
+ "pages": ["overview", "architecture", "deploy-a-permissioned-pool", "provide-liquidity"]
+}
diff --git a/content/protocols/uniswap-labs-hooks/permissioned-pools/overview.mdx b/content/protocols/uniswap-labs-hooks/permissioned-pools/overview.mdx
new file mode 100644
index 000000000..7e1d882b8
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/permissioned-pools/overview.mdx
@@ -0,0 +1,42 @@
+---
+title: Permissioned Pools Overview
+sidebarTitle: Overview
+description: Understand Uniswap v4 permissioned pools, which restrict swaps and liquidity to allowlisted holders of a permissioned asset.
+---
+
+The Permissioned Pools hook lets a Uniswap v4 pool support tokens that can only be held or traded by approved addresses, such as tokenized or crypto-native assets that must restrict who can hold them. It combines an onchain allowlist with a virtual version of the token that keeps the permissioned token compatible with the standard `PoolManager`. The protocol stays permissionless: anyone can create a pool, but only allowlisted holders can swap or provide liquidity.
+
+## Use Cases
+
+Potential use cases for the Permissioned Pools hook include:
+
+- **Tokenized assets** that require holders to pass identity verification before trading.
+- **Regulated assets** where an issuer must be able to restrict who gains exposure.
+- **Compliance-gated liquidity** where both swappers and liquidity providers must be on an allowlist.
+
+## How It Works
+
+With permissioned pools, a verified contract, the **Permissions Adapter**, holds the underlying permissioned token and issues a virtual version of it, and the pool trades that virtual token. When assets enter the pool, a virtual version of the token is created; when they leave, the virtual token is converted back to the original, so the holder always ends up with the underlying permissioned token. A **permissioned hook** checks the issuer's allowlist on every swap and liquidity addition, and the Permissioned Position Manager and the Universal Router handle these conversions automatically so integrations need minimal changes.
+
+The Permissions Adapter is verified through a factory: before a pool can use it, the issuer proves the adapter is authorized to hold the underlying token by seeding it with a minimal balance, which is only possible if the adapter is on the token's allowlist. See [Architecture](/docs/protocols/uniswap-labs-hooks/permissioned-pools/architecture) for the details.
+
+
+
+## Core Invariants
+
+- Only allowlisted addresses can swap or provide liquidity.
+- Disallowed addresses cannot gain exposure to the permissioned token, including through multi-hop routes.
+- The issuer can halt swapping and can unwind liquidity positions.
+- Liquidity position NFTs are non-transferable, so allowlist checks cannot be bypassed.
+- The system is non-custodial: funds leave the pool only through swaps, position withdrawals, and claim redemptions, never through the virtual token directly.
+
+
+If you are considering bringing an asset onchain and want the team to follow up, [register your interest](/uniswap-labs-hooks).
+If you already have a permissioned token deployed, [request allowlisting for routing](/permissioned-pools-allowlist) instead.
+
+
+## Where to Go Next
+
+- Learn how the contracts fit together in [Architecture](/docs/protocols/uniswap-labs-hooks/permissioned-pools/architecture).
+- Onboard a token in [Deploy a Permissioned Pool](/docs/protocols/uniswap-labs-hooks/permissioned-pools/deploy-a-permissioned-pool).
+- Integrate permissioned tokens in an app with [Swapping through Permissioned Pools](/docs/trading/swapping-api/swapping-permissioned-pools).
diff --git a/content/protocols/uniswap-labs-hooks/permissioned-pools/provide-liquidity.mdx b/content/protocols/uniswap-labs-hooks/permissioned-pools/provide-liquidity.mdx
new file mode 100644
index 000000000..6ae019266
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/permissioned-pools/provide-liquidity.mdx
@@ -0,0 +1,108 @@
+---
+title: Provide Liquidity in Permissioned Pools
+sidebarTitle: Provide Liquidity
+description: Add liquidity to a Uniswap v4 permissioned pool with the Permissioned Position Manager, including minting a position, viewing it, and how issuer recall works.
+---
+
+This guide walks allowlisted liquidity providers through the process of adding liquidity to a Uniswap v4 permissioned pool. It assumes familiarity with the standard Uniswap v4 liquidity provisioning flow and focuses specifically on the technical and operational differences introduced by the permissioned hook. For the deep dive into the contract details, please refer to [Architecture](/docs/protocols/uniswap-labs-hooks/permissioned-pools/architecture) first.
+
+
+You must hold the `LIQUIDITY_ALLOWED` permission for the token. This is separate from `SWAP_ALLOWED`: a wallet allowed to swap is not automatically allowed to provide liquidity.
+
+
+## Prerequisites
+
+- The connected wallet is allowlisted with `LIQUIDITY_ALLOWED` for the permissioned token.
+- You use the `PermissionedPositionManager`, not the standard `PositionManager`. See [Deployment Addresses](/docs/protocols/uniswap-labs-hooks/permissioned-pools/deploy-a-permissioned-pool#deployment-addresses).
+- You know the token's verified **Permissions Adapter** address. The pool uses the adapter as its currency, not the underlying token.
+- The `PermissionedHooks` contract is allowed on the adapter by the adapter admin through `updateAllowedHook`, part of [Step 5 of onboarding](/docs/protocols/uniswap-labs-hooks/permissioned-pools/deploy-a-permissioned-pool#step-5-approve-virtual-token-contracts). Mints and increases revert with `InvalidHook` otherwise.
+
+## How Liquidity Differs From Standard v4
+
+- You interact with the `PermissionedPositionManager`, which converts the token into its virtual version through the Permissions Adapter before touching the pool.
+- The pool currency is the adapter address, not the underlying token.
+- Minting and increasing check `LIQUIDITY_ALLOWED` twice: the position manager checks the recipient, and the hook's `beforeAddLiquidity` checks the caller.
+- Position NFTs are non-transferable. `transferFrom` and `safeTransferFrom` revert with `TransferDisabled`.
+- Decreasing and burning are never gated, so you can always exit, even after losing permission.
+- The adapter admin can force-close your position with `unwindPosition`.
+
+## Step 1: Approve the Position Manager
+
+The position manager pulls the underlying token through Permit2, so approvals are on the **underlying permissioned token**, not the adapter. Approve Permit2 on the token, then approve the position manager as a Permit2 spender.
+
+```solidity
+// 1. Approve Permit2 to move the underlying permissioned token.
+IERC20(permissionedToken).approve(address(permit2), type(uint256).max);
+
+// 2. Approve the Permissioned Position Manager as a Permit2 spender.
+permit2.approve(permissionedToken, address(permissionedPositionManager), type(uint160).max, type(uint48).max);
+```
+
+When the position manager settles, it pulls the underlying token into the Permissions Adapter, which creates the virtual version for the pool, so you never handle the virtual token yourself.
+
+## Step 2: Build the Pool Key
+
+Use the **adapter address** as the currency and `PermissionedHooks` as the hook, the same key the pool was created with.
+
+```solidity
+PoolKey memory key = PoolKey({
+ currency0: Currency.wrap(adapter), // the Permissions Adapter, not the underlying token
+ currency1: Currency.wrap(weth),
+ fee: 3000,
+ tickSpacing: 60,
+ hooks: IHooks(permissionedHooks)
+});
+```
+
+## Step 3: Mint a Position
+
+Minting uses the standard `modifyLiquidities` batch flow. Encode a `MINT_POSITION` action followed by `SETTLE_PAIR` to pay what the mint owes. The recipient must hold `LIQUIDITY_ALLOWED`, or the call reverts.
+
+```solidity
+bytes memory actions = abi.encodePacked(uint8(Actions.MINT_POSITION), uint8(Actions.SETTLE_PAIR));
+
+bytes[] memory params = new bytes[](2);
+params[0] = abi.encode(key, tickLower, tickUpper, liquidity, amount0Max, amount1Max, recipient, hookData);
+params[1] = abi.encode(key.currency0, key.currency1);
+
+PermissionedPositionManager(permissionedPositionManager).modifyLiquidities(
+ abi.encode(actions, params),
+ block.timestamp + 60
+);
+```
+
+On settlement, the position manager pulls the underlying token from your wallet through Permit2, deposits it into the Permissions Adapter, and the adapter mints the virtual token to the `PoolManager`. The position NFT is minted to `recipient`.
+
+## Step 4: Increase or Decrease Liquidity
+
+Use `INCREASE_LIQUIDITY` and `DECREASE_LIQUIDITY` on the same position, exactly as on standard v4. Increases check `LIQUIDITY_ALLOWED` for the position owner. Decreases and burns are never gated, so you can always withdraw, even if the wallet later loses permission or the hook is revoked.
+
+## Step 5: View a Position
+
+Positions are read through the inherited `PositionManager` accessors.
+
+```solidity
+(PoolKey memory poolKey, PositionInfo info) =
+ PermissionedPositionManager(permissionedPositionManager).getPoolAndPositionInfo(tokenId);
+
+uint128 liquidity = PermissionedPositionManager(permissionedPositionManager).getPositionLiquidity(tokenId);
+address owner = PermissionedPositionManager(permissionedPositionManager).ownerOf(tokenId);
+```
+
+Read raw pool state with `StateView`, the same as any v4 pool.
+
+## Non-Transferable Positions
+
+Position NFTs cannot be moved. `transferFrom` and both `safeTransferFrom` overloads revert with `TransferDisabled`. This prevents an allowlisted holder from handing a position to a disallowed address, which would bypass the allowlist.
+
+## Issuer Recall
+
+The owner of either Permissions Adapter in the pool can call `unwindPosition(tokenId)` to force-close a position. It burns the NFT, removes the liquidity, and routes each asset back to the holder. Any asset the holder can no longer receive falls back to that asset's own adapter owner (as tokens, or as an ERC-6909 claim if delivery fails), regardless of which issuer called. You can always exit a position yourself through a decrease or burn, so recall does not trap your funds.
+
+
+
+## Where to Go Next
+
+- Understand the contracts in [Architecture](/docs/protocols/uniswap-labs-hooks/permissioned-pools/architecture).
+- Onboard a token in [Deploy a Permissioned Pool](/docs/protocols/uniswap-labs-hooks/permissioned-pools/deploy-a-permissioned-pool).
+- Integrate swaps in an app with [Swapping through Permissioned Pools](/docs/trading/swapping-api/swapping-permissioned-pools).
diff --git a/content/protocols/uniswap-labs-hooks/stable-pair/concepts/block-price-caching.mdx b/content/protocols/uniswap-labs-hooks/stable-pair/concepts/block-price-caching.mdx
new file mode 100644
index 000000000..d7597e614
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/stable-pair/concepts/block-price-caching.mdx
@@ -0,0 +1,27 @@
+---
+title: Block Price Caching
+description: Learn why StablePair prices every swap in a block from the same cached pool price, and what that means for integrators.
+---
+
+On the first swap of each block, the hook reads the pool price and stores it. Every other swap in that block is priced from that same stored value, not from the live price.
+
+## Why
+
+Without the cache, a corrective swap could be split into legs, each leg facing a price slightly closer to the reference rate and paying a slightly smaller fee than the last. The split trade would pay less in total than the single trade. Caching the price at the start of the block removes the advantage: every leg sees the same inputs and pays the same rate.
+
+This behavior was introduced in response to a finding in the OpenZeppelin review of the fee mechanism. See [StablePair Security](/docs/protocols/uniswap-labs-hooks/stable-pair/security).
+
+## What it means for integrators
+
+- **Splitting a swap gains nothing.** Same-direction corrective swaps within a block all pay the same rate.
+- **The fee does not move within a block.** A quote taken at the top of a block holds for the rest of it, even as other swaps move the actual pool price. The next block reads a fresh price and reprices.
+- **The cached price can go stale inside a block.** Later swaps in a heavily traded block may see a fee derived from a price the pool has already moved away from. For pairs trading near parity the gap is small, and it is bounded to a single block.
+
+
+While a pool is outside its band, the cached price also decides which direction counts as corrective. If a swap pushes the price across the reference rate mid-block, the fee directions invert for the remainder of that block: the newly corrective direction is charged zero and the newly adverse direction pays the decaying fee. The next block restores the correct assignment.
+
+
+## Where to Go Next
+
+- [Dynamic Fees](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/dynamic-fees)
+- [Swap Against a StablePair Pool](/docs/protocols/uniswap-labs-hooks/stable-pair/guides/swap)
diff --git a/content/protocols/uniswap-labs-hooks/stable-pair/concepts/dynamic-fees.mdx b/content/protocols/uniswap-labs-hooks/stable-pair/concepts/dynamic-fees.mdx
new file mode 100644
index 000000000..189f83d86
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/stable-pair/concepts/dynamic-fees.mdx
@@ -0,0 +1,38 @@
+---
+title: Dynamic Fees
+description: Learn how StablePair sets the LP fee from the pool's distance from its reference rate and the direction of the swap.
+---
+
+StablePair sets the LP fee dynamically instead of charging one fixed number. Each pool is configured with a reference rate (the price the pair is expected to hold) and a narrow band around it. The hook derives the fee from that reference rate and the pool's price at the start of the block.
+
+## Inside the band
+
+Within the band, the hook sets the fee so that every buy clears at one price and every sell at another, regardless of where the spot price sits inside the band. Two swappers arriving at different moments in the band see the same quote.
+
+
+These are pre-impact prices. The hook derives the fee from the pool price as it stands before the swap executes, so a quoted rate never includes the price impact of the swap itself. A large swap still walks the curve and realizes a worse average price than a small one. The consistency guarantee is about the fee, not the execution.
+
+
+At exactly the reference rate, both directions are charged the configured band width. As the price drifts toward one edge, the fee for swaps pushing toward that edge falls toward zero, while the fee in the opposite direction rises toward roughly twice the band width.
+
+The band is defined symmetrically in price terms, so a buy-then-sell roundtrip at the two edges costs the same percentage in either direction.
+
+## Outside the band
+
+Once the price leaves the band, the hook switches regime and the fee depends on the direction of the swap.
+
+| Swap direction | Fee |
+| :--- | :--- |
+| Toward the reference rate (corrective) | A decaying fee. It starts at the far edge of the band and falls each block toward a target. See [Fee Decay](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/fee-decay). |
+| Away from the reference rate (adverse) | Zero. |
+
+Adverse swaps pay nothing because they bring volume without extracting from the mispricing. Charging them would cost the pool activity and gain liquidity providers nothing.
+
+
+The fee never depends on swap size. StablePair reads the pool price and the swap direction, never the amount, so a quote holds for any size.
+
+
+## Where to Go Next
+
+- [Fee Decay](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/fee-decay)
+- [Swap Against a StablePair Pool](/docs/protocols/uniswap-labs-hooks/stable-pair/guides/swap)
diff --git a/content/protocols/uniswap-labs-hooks/stable-pair/concepts/fee-decay.mdx b/content/protocols/uniswap-labs-hooks/stable-pair/concepts/fee-decay.mdx
new file mode 100644
index 000000000..14f454798
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/stable-pair/concepts/fee-decay.mdx
@@ -0,0 +1,31 @@
+---
+title: Fee Decay
+description: Understand how StablePair lowers the fee on corrective swaps over time to create a progressively stronger arbitrage incentive.
+---
+
+When the pool price sits outside its band, the pool is mispriced against the wider market and there is an arbitrage opportunity. StablePair auctions that opportunity off rather than fixing a price for it.
+
+## The auction
+
+When the hook reads a price outside the band, the fee on corrective swaps resets to the far edge of the band (the same price an ordinary in-band swap would get) and decays from there, one step per block. As blocks pass and nobody takes it, the fee falls until someone does, and the pool collects whatever the fee is at that moment.
+
+Two configured parameters shape how much that turns out to be: a per-block decay factor, controlling how quickly the fee falls, and a target multiplier, controlling how low it can go.
+
+## The target and the incentive
+
+The target the fee decays toward is set by the target multiplier, applied to the pool's distance outside the band. At the maximum multiplier the target settles near twice the band width and stays roughly there however far the price has drifted. At lower multipliers the target scales up with the mispricing, so the fee is not permitted to fall as far.
+
+At the maximum setting this makes larger mispricings clear sooner: the floor stays put while the arbitrage on offer grows, so the fee becomes worth taking in fewer blocks.
+
+## Adjustment before decay
+
+Between blocks, the price itself moves, and the fee is adjusted before decay is applied:
+
+- **The price moved further out.** The fee is raised to preserve the same quoted price it would have produced at the previous, better pool price. A worsening pool price never lowers the fee.
+- **The price moved back toward the reference.** The fee is capped so it can never exceed what the far edge of the band would produce at the new price, then decays from there.
+- **The price crossed the reference rate, or re-entered the band and left again.** The fee resets to the far edge of the band. There is no meaningful prior fee to carry forward.
+
+## Where to Go Next
+
+- [Block Price Caching](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/block-price-caching)
+- [StablePair Security](/docs/protocols/uniswap-labs-hooks/stable-pair/security)
diff --git a/content/protocols/uniswap-labs-hooks/stable-pair/concepts/meta.json b/content/protocols/uniswap-labs-hooks/stable-pair/concepts/meta.json
new file mode 100644
index 000000000..c78755f67
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/stable-pair/concepts/meta.json
@@ -0,0 +1,4 @@
+{
+ "title": "Concepts",
+ "pages": ["dynamic-fees", "fee-decay", "block-price-caching", "pool-creation"]
+}
diff --git a/content/protocols/uniswap-labs-hooks/stable-pair/concepts/pool-creation.mdx b/content/protocols/uniswap-labs-hooks/stable-pair/concepts/pool-creation.mdx
new file mode 100644
index 000000000..64b41e013
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/stable-pair/concepts/pool-creation.mdx
@@ -0,0 +1,59 @@
+---
+title: Pool Creation and Configuration
+description: Understand why StablePair pools are created only by Uniswap Labs, and where each pool's fee parameters live.
+---
+
+## What identifies a pool
+
+Every Uniswap v4 pool is identified by five values, which together form its pool key: the two currencies, a fee field, a tick spacing, and the hook. Change any one of them and it is a different pool.
+
+For a dynamic fee hook the fee field does not hold a rate. It holds a flag meaning that the fee is set by the hook at swap time.
+
+## Fee parameters are not part of pool identity
+
+The parameters StablePair uses to compute a fee live in the hook's own storage, keyed by pool ID, not in the pool key:
+
+| Parameter | What it controls |
+| :--- | :--- |
+| Reference rate | The price the pair is expected to hold. The fee is derived from how far the pool sits from it. |
+| Optimal fee | How wide the band around the reference rate is. |
+| Decay factor | How quickly the corrective fee falls each block once the price is outside the band. |
+| Target multiplier | How far the corrective fee is allowed to fall. |
+
+Because configuration sits outside the pool key, two pools on the same pair, tick spacing, and hook cannot differ by configuration. They would be the same pool.
+
+## Why creation is permissioned
+
+That has a direct consequence: whoever creates the pool for a given pair first occupies the identity permanently, and v4 rejects creating a pool that already exists. Under open creation, anyone could create the pool for a pair ahead of its launch and fix its parameters, with a governance vote as the only remedy.
+
+So creation is restricted structurally. The hook's `beforeInitialize` callback reverts unconditionally, which makes `PoolManager.initialize` unusable against it. Pools are created only through the hook's own `initializePool`, restricted to a role held by a Uniswap Labs Safe, which validates and stores the fee configuration atomically with creation.
+
+Two guarantees follow:
+
+- No pool on this hook can exist without a valid fee configuration.
+- No fee configuration can exist without a live pool.
+
+Support for a new pair is therefore a request rather than a transaction.
+
+## Who controls what
+
+| Action | Who |
+| :--- | :--- |
+| Create a pool and set its opening parameters | Uniswap Labs Safe |
+| Change a live pool's parameters | Uniswap governance |
+| Upgrade the hook | Uniswap governance |
+
+See [StablePair Security](/docs/protocols/uniswap-labs-hooks/stable-pair/security) for the full trust model.
+
+## One hook serves every pool
+
+Every hook entry point takes a pool key, so a single deployment handles every pair. There is one canonical StablePair hook address per chain to integrate against, listed in [Deployments](/docs/protocols/uniswap-labs-hooks/stable-pair/deployments).
+
+
+Permissioned creation is a property of this deployment rather than of the fee mechanism. Governance is the role admin and can change who may create pools.
+
+
+## Where to Go Next
+
+- [Dynamic Fees](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/dynamic-fees)
+- [StablePair Deployments](/docs/protocols/uniswap-labs-hooks/stable-pair/deployments)
diff --git a/content/protocols/uniswap-labs-hooks/stable-pair/deployments.mdx b/content/protocols/uniswap-labs-hooks/stable-pair/deployments.mdx
new file mode 100644
index 000000000..f77a5d4b6
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/stable-pair/deployments.mdx
@@ -0,0 +1,55 @@
+---
+title: StablePair Deployments
+sidebarTitle: Deployments
+description: Find StablePair hook addresses and live pool parameters on Ethereum and Sepolia.
+---
+
+The registered v4 hook is an ERC1967 proxy. Its address is permanent and encodes the hook permission flags; the implementation behind it changes on a governance upgrade. Always integrate against the hook address.
+
+## Mainnet Deployments
+
+### Ethereum: 1
+
+| Contract | Address |
+| :--- | :--- |
+| StablePairHook (hook) | [`0x0000113dCf4ADd69999Fad8F20F2b63F979bfcC0`](https://etherscan.io/address/0x0000113dCf4ADd69999Fad8F20F2b63F979bfcC0) |
+| StablePairHook (implementation) | [`0x5f216d21b1C81346938EDDc1Df7e0111A0F64000`](https://etherscan.io/address/0x5f216d21b1C81346938EDDc1Df7e0111A0F64000) |
+
+## Testnet Deployments
+
+### Sepolia: 11155111
+
+| Contract | Address |
+| :--- | :--- |
+| StablePairHook (hook) | [`0x2F45A94782d3e187BaB5F72448bb85d6d1d67CC0`](https://sepolia.etherscan.io/address/0x2F45A94782d3e187BaB5F72448bb85d6d1d67CC0) |
+| StablePairHook (implementation) | [`0xDBc81fFadaB5ee9c9fB1c2D43Bef547EB9c64000`](https://sepolia.etherscan.io/address/0xDBc81fFadaB5ee9c9fB1c2D43Bef547EB9c64000) |
+
+## Pool Parameters
+
+Two pools are live on Ethereum.
+
+### USDC / USDT
+
+| Parameter | Value |
+| :--- | :--- |
+| Pool ID | `0x2b21c65d9a7dc6926ee330a1c6e5a8037fd81774f3dc066536f800128e39f634` |
+| currency0 | USDC [`0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48`](https://etherscan.io/address/0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48) |
+| currency1 | USDT [`0xdAC17F958D2ee523a2206206994597C13D831ec7`](https://etherscan.io/address/0xdAC17F958D2ee523a2206206994597C13D831ec7) |
+| Fee | Dynamic (`0x800000`) |
+| Tick spacing | 1 |
+| Reference rate | 1 USDC = 1 USDT |
+
+### USDC / USDG
+
+| Parameter | Value |
+| :--- | :--- |
+| Pool ID | `0xeda62d2906d0edf26d40c793d581609552a44a87f618a98ff76ebe8dde4b7edb` |
+| currency0 | USDC [`0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48`](https://etherscan.io/address/0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48) |
+| currency1 | USDG [`0xe343167631d89B6Ffc58B88d6b7fB0228795491D`](https://etherscan.io/address/0xe343167631d89B6Ffc58B88d6b7fB0228795491D) |
+| Fee | Dynamic (`0x800000`) |
+| Tick spacing | 1 |
+| Reference rate | 1 USDC = 1 USDG |
+
+
+Do not hardcode pool IDs. Derive them from the pool key, and read each pool's live fee configuration from the hook rather than from this page. Parameters can be changed by governance.
+
diff --git a/content/protocols/uniswap-labs-hooks/stable-pair/guides/meta.json b/content/protocols/uniswap-labs-hooks/stable-pair/guides/meta.json
new file mode 100644
index 000000000..a1100826b
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/stable-pair/guides/meta.json
@@ -0,0 +1,4 @@
+{
+ "title": "Guides",
+ "pages": ["swap", "provide-liquidity"]
+}
diff --git a/content/protocols/uniswap-labs-hooks/stable-pair/guides/provide-liquidity.mdx b/content/protocols/uniswap-labs-hooks/stable-pair/guides/provide-liquidity.mdx
new file mode 100644
index 000000000..ea741b07a
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/stable-pair/guides/provide-liquidity.mdx
@@ -0,0 +1,25 @@
+---
+title: Provide Liquidity on StablePair
+description: Add and remove liquidity in StablePair pools using the standard Uniswap v4 position flow.
+---
+
+Liquidity in a StablePair pool works exactly as it does in any Uniswap v4 pool. Use `PositionManager` as normal. There is no hook-specific calldata, no allowlist, and no deposit wrapper.
+
+## What the hook can and cannot do
+
+StablePair deliberately claims almost no power over liquidity:
+
+- Its remove-liquidity callbacks are switched off entirely, so it cannot block or interfere with an exit.
+- It holds none of v4's return-delta permissions, so it cannot alter the amounts on a mint or a burn.
+- Its add-liquidity callbacks are enabled but inert.
+
+The hook's only active role in a live pool is overriding the LP fee on swaps.
+
+## Creating pools is permissioned
+
+Liquidity is open to anyone, but pool creation is not. Calling `PoolManager.initialize` against this hook reverts; pools are created only by Uniswap Labs, which sets each pool's fee parameters atomically with creation. See [Pool Creation and Configuration](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/pool-creation) for why.
+
+## Where to Go Next
+
+- [StablePair Deployments](/docs/protocols/uniswap-labs-hooks/stable-pair/deployments)
+- [StablePair Security](/docs/protocols/uniswap-labs-hooks/stable-pair/security)
diff --git a/content/protocols/uniswap-labs-hooks/stable-pair/guides/swap.mdx b/content/protocols/uniswap-labs-hooks/stable-pair/guides/swap.mdx
new file mode 100644
index 000000000..ccdaaffaa
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/stable-pair/guides/swap.mdx
@@ -0,0 +1,52 @@
+---
+title: Swap Against a StablePair Pool
+description: Quote and execute swaps against StablePair pools, including how to read the current dynamic fee.
+---
+
+Swapping against a StablePair pool uses the standard v4 swap path. The only difference is the fee: it is set by the hook at swap time, so it cannot be read from the pool key.
+
+## Build the pool key
+
+The pool uses v4's dynamic fee flag rather than a fixed fee tier. Code that assumes a static tier will not find the pool.
+
+```solidity
+PoolKey memory key = PoolKey({
+ currency0: Currency.wrap(USDC),
+ currency1: Currency.wrap(USDT),
+ fee: LPFeeLibrary.DYNAMIC_FEE_FLAG, // 0x800000, not a fee tier
+ tickSpacing: 1,
+ hooks: IHooks(0x0000113dCf4ADd69999Fad8F20F2b63F979bfcC0)
+});
+```
+
+## Read the current fee
+
+`PoolKey.fee` holds the dynamic flag, not a rate. Instead, the hook exposes a view function returning the exact LP fee a swap will be charged in the current block, per direction:
+
+```solidity
+function getFee(PoolKey calldata key) external view returns (uint24 feeE6ZeroForOne, uint24 feeE6OneForZero);
+```
+
+Both values are returned in 1e6 precision, matching v4's own fee units.
+
+For routers and aggregators this makes quoting substantially cheaper: the fee can be computed locally rather than simulated per size. Two properties are why.
+
+- **Size-independent.** The fee never depends on the swap amount, so the same value applies to every size. `getFee` never reads a swap amount, and so never reverts on the basis of one.
+- **Fixed for the block.** Both values are computed from the start-of-block price the next swap will see, so one read per pool per block covers every quote in that block. See [Block Price Caching](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/block-price-caching).
+
+The two directions differ, often substantially (outside the band one of them is zero), so quote the direction being swapped.
+
+`getFee` reverts with `PoolNotInitialized` if the pool was not initialized through the hook.
+
+
+Two things the returned value is not. It is the LP fee only: if the pool has a protocol fee enabled, v4 compounds the two, taking the protocol fee from the input first and the LP fee from the remainder, and rounds the combined rate up to a whole pip. And it is pre price impact: the fee is exact, but the execution price still depends on the liquidity the swap traverses.
+
+
+## Execute the swap
+
+Swap through the standard v4 router or `PoolManager` unlock flow. StablePair holds no return-delta permissions, so it never alters swap amounts. It only overrides the fee.
+
+## Where to Go Next
+
+- [Dynamic Fees](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/dynamic-fees)
+- [Provide Liquidity on StablePair](/docs/protocols/uniswap-labs-hooks/stable-pair/guides/provide-liquidity)
diff --git a/content/protocols/uniswap-labs-hooks/stable-pair/meta.json b/content/protocols/uniswap-labs-hooks/stable-pair/meta.json
new file mode 100644
index 000000000..f3b8aca9b
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/stable-pair/meta.json
@@ -0,0 +1,4 @@
+{
+ "title": "StablePair Hook",
+ "pages": ["overview", "concepts", "guides", "deployments", "security"]
+}
diff --git a/content/protocols/uniswap-labs-hooks/stable-pair/overview.mdx b/content/protocols/uniswap-labs-hooks/stable-pair/overview.mdx
new file mode 100644
index 000000000..94033ef53
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/stable-pair/overview.mdx
@@ -0,0 +1,37 @@
+---
+title: StablePair Overview
+sidebarTitle: Overview
+description: Understand StablePair, a Uniswap v4 hook that computes LP fees dynamically for pairs expected to trade at the same price.
+---
+
+StablePair is a dynamic fee hook built on Uniswap v4, for pools whose two assets are expected to trade at the same price: USDC/USDT, or WBTC/cbBTC. Rather than charging one static fee, the hook sets the LP fee on every swap from how far the pool price has drifted from a configured reference rate and which direction the swap pushes it.
+
+Inside a narrow band around that reference rate, where the pool sits under normal conditions, both directions pay a small fee, set so that every buy is quoted at one price and every sell at another, before the price impact of the swap itself. Once the price leaves the band the regime changes: swaps pushing it back toward the reference are charged a fee that starts high and decays each block until an arbitrageur takes it, and swaps pushing it further away pay nothing.
+
+
+StablePair pools cannot be created permissionlessly. Calling `PoolManager.initialize` against this hook reverts; pools are created only by Uniswap Labs, which sets each pool's fee parameters atomically with creation. See [Pool Creation and Configuration](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/pool-creation).
+
+
+## Concepts
+
+- [Dynamic Fees](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/dynamic-fees): how the fee is chosen for any given swap
+- [Fee Decay](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/fee-decay): how corrective swaps get cheaper over time
+- [Block Price Caching](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/block-price-caching): why the fee is fixed for a whole block
+- [Pool Creation and Configuration](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/pool-creation): who can create pools, and where fee parameters live
+
+## Guides
+
+- [Swap Against a StablePair Pool](/docs/protocols/uniswap-labs-hooks/stable-pair/guides/swap): quote and execute swaps
+- [Provide Liquidity on StablePair](/docs/protocols/uniswap-labs-hooks/stable-pair/guides/provide-liquidity): deposit and withdraw
+
+## Repositories
+
+- [Uniswap/v4-hooks-public](https://github.com/Uniswap/v4-hooks-public): hook source and tests
+
+## Deployments
+
+See [StablePair Deployments](/docs/protocols/uniswap-labs-hooks/stable-pair/deployments) for hook addresses and live pool parameters.
+
+## Security
+
+See [StablePair Security](/docs/protocols/uniswap-labs-hooks/stable-pair/security) for the trust model, protocol invariants, and audit history.
diff --git a/content/protocols/uniswap-labs-hooks/stable-pair/security.mdx b/content/protocols/uniswap-labs-hooks/stable-pair/security.mdx
new file mode 100644
index 000000000..45082c6d7
--- /dev/null
+++ b/content/protocols/uniswap-labs-hooks/stable-pair/security.mdx
@@ -0,0 +1,58 @@
+---
+title: StablePair Security
+sidebarTitle: Security
+description: Review StablePair's trust model, protocol invariants, and audit history.
+---
+
+## Audit
+
+OpenZeppelin reviewed the StablePair fee mechanism from February 9 to February 13, 2026. One high-severity finding, that splitting a corrective swap into legs produced a cheaper aggregate price, was resolved by caching the pool price once per block, the behavior described in [Block Price Caching](/docs/protocols/uniswap-labs-hooks/stable-pair/concepts/block-price-caching).
+
+The review covered the fee mechanism as implemented in the hook's non-upgradeable predecessor, which shares StablePair's core fee math. The upgradeability and role model described below postdate that review.
+
+## Trust Model
+
+### Governance
+
+The hook sits behind an upgradeable proxy controlled by Uniswap Governance, so the implementation can change over time as new research identifies opportunities to increase LP value capture. Even so, governance can never change the permissions that protect LP funds.
+
+In Uniswap v4, a hook's permissions are encoded in its address, and that address is permanent. A hook's permissions are strictly scoped, so upgrades cannot expand them. Because the flags for the remove-liquidity callbacks and for returning custom accounting deltas are switched off, no upgrade can let the hook block LP withdrawals or alter swap amounts to skim additional fees.
+
+A fee configuration change also resets the pool's decay state, so the next swap starts from a fresh price reading.
+
+### Pool creation
+
+A Uniswap Labs Safe holds the role that can create pools. It cannot change fee configurations, upgrade the implementation, or grant roles.
+
+### Roles
+
+| Capability | Holder |
+| :--- | :--- |
+| Upgrade the implementation; grant and revoke all roles | [Uniswap Governance Timelock](https://etherscan.io/address/0x1a9C8182C09F50C8318d769245beA52c32BE35BC) |
+| Change a pool's fee configuration | [Uniswap Governance Timelock](https://etherscan.io/address/0x1a9C8182C09F50C8318d769245beA52c32BE35BC) |
+| Create pools and set initial pool fee configuration | [Uniswap Labs Safe](https://etherscan.io/address/0xFc43582532E90Fa8726FE9cdb5FAd48f4e487d27) |
+
+Neither operational role can grant or revoke roles. Because the hook sits behind a proxy, the pool address survives upgrades: no liquidity migration and no re-integration when the implementation changes.
+
+## Core Invariants
+
+- The decaying fee always sits between its target and its starting value.
+- Inside the band, every buy is quoted at one price and every sell at another, before price impact, for every pool price in the band.
+- The swap callback never reverts.
+- While a pool is outside its band, a worsening price can only raise the corrective fee, never lower it.
+- Splitting a corrective swap within a block yields no fee advantage.
+- No pool can exist without a valid fee configuration, and no fee configuration can exist without a live pool.
+- The hook cannot block or alter a liquidity withdrawal.
+
+## Known Limitations
+
+The cached start-of-block price is intentionally stale within a block. Two consequences are accepted rather than fixed, because resolving either would restore the swap-splitting advantage the cache exists to remove:
+
+- Later swaps in a heavily traded block may be priced from a pool price that has already moved.
+- A swap that pushes the price across the reference rate mid-block inverts the fee directions for the remainder of that block.
+
+Both are bounded to a single block and self-correct on the next one.
+
+## Quote Semantics
+
+`getFee` returns the LP fee a swap would pay right now, in both directions, computed from the same start-of-block price the next swap will see. It is size-independent, excludes any protocol fee, and does not account for price impact: the realized execution price of a large swap will differ from the quoted rate according to the depth of the liquidity it traverses.
diff --git a/content/protocols/universal-router/concepts/commands.mdx b/content/protocols/universal-router/concepts/commands.mdx
index c8f391683..0bdb3ca65 100644
--- a/content/protocols/universal-router/concepts/commands.mdx
+++ b/content/protocols/universal-router/concepts/commands.mdx
@@ -1,5 +1,4 @@
---
-id: technical-reference
title: Universal Router Commands
description: Reference Uniswap Universal Router command encoding, supported v2 commands, and composition patterns for execute flows.
---
diff --git a/content/protocols/universal-router/overview.mdx b/content/protocols/universal-router/overview.mdx
index 5be2d4d93..eeda6ff9f 100644
--- a/content/protocols/universal-router/overview.mdx
+++ b/content/protocols/universal-router/overview.mdx
@@ -1,6 +1,29 @@
---
-title: Overview
+title: Universal Router Overview
+sidebarTitle: Overview
description: Learn how Uniswap Universal Router composes v2, v3, and v4 swaps with Permit2-based approvals in one transaction.
+keywords:
+ - universal-router
+ - swaprouter
+ - command-encoding
+ - permit2
+ - router-address
+faqs:
+ - question: How does Universal Router command encoding work?
+ answer: |-
+ You call execute(commands, inputs), optionally with a deadline. The commands argument is a byte string where each byte is one operation, and inputs is a parallel array holding the ABI-encoded parameters for each command. The router walks the command stream in order and dispatches each byte to its module, so a single transaction can chain swaps across v2, v3, and v4, Permit2 permits, ETH wrapping, payments, and position-manager calls. The low 7 bits of each byte select the command, and the high bit is an allow-revert flag.
+ - question: How is Universal Router different from SwapRouter?
+ answer: |-
+ SwapRouter (SwapRouter02) exposed fixed functions tightly coupled to v2 and v3, so each call ran a scripted sequence. Universal Router is command-based: the caller composes an arbitrary ordered list of operations, so it aggregates v2, v3, and v4 swaps, Permit2 approvals, ETH wrapping, and position-manager actions in one transaction, and it supports splitting, interleaving, and partial fills. It is unowned and non-upgradeable. New integrations should target Universal Router rather than the legacy SwapRouter.
+ - question: Which Universal Router address should I use for each chain?
+ answer: |-
+ Universal Router is deployed at a different address on each chain and per router version, so do not hardcode a single address. The current per-chain addresses are published in Supported Chains and Tokens, and the canonical source of truth is maintained in the universal-router-sdk constants on GitHub. Whitelist the address for the specific chain and version you integrate.
+ - question: How do I enable partial fills with Universal Router?
+ answer: |-
+ Set the high bit (0x80) on a command byte to mark it allow-revert. If that command fails, the rest of the transaction still executes, which is how partial fills work. For example, 0x80 combined with 0x00 is a V3_SWAP_EXACT_IN that is allowed to revert. When you use allow-revert, include a cleanup command such as SWEEP so no funds are stranded in the router.
+ - question: Do I need Permit2 to use Universal Router?
+ answer: |-
+ Universal Router pulls a user's ERC-20 tokens through Permit2, so the user first approves the Permit2 contract once per token and then authorizes the router by signature. Native ETH does not require Permit2. See the Permit2 documentation for allowance and signature-transfer patterns.
---
The `UniversalRouter` is an ETH and ERC20 swap router that aggregates trades across Uniswap v2, v3, and v4. It is unowned and non-upgradeable.
@@ -26,6 +49,71 @@ You call `execute(...)` with a `commands` byte string and a parallel `inputs` ar
See [Permit2 documentation](/docs/protocols/permit2/overview) for allowance and signature-transfer patterns.
+## FAQ
+
+
+ How does Universal Router command encoding work?
+
+
+
+ You call `execute(commands, inputs)`, optionally with a `deadline`. The `commands` argument is a byte string where each byte is one operation, and `inputs` is a parallel array holding the ABI-encoded parameters for each command. The router walks the command stream in order and dispatches each byte to its module, so a single transaction can chain swaps across v2, v3, and v4, Permit2 permits, ETH wrapping, payments, and position-manager calls. The low 7 bits of each byte select the command, and the high bit is an allow-revert flag.
+
+ See [Universal Router Commands](/docs/protocols/universal-router/concepts/commands) for the full command table.
+
+
+
+
+
+
+ How is Universal Router different from SwapRouter?
+
+
+
+ `SwapRouter` (SwapRouter02) exposed fixed functions tightly coupled to v2 and v3, so each call ran a scripted sequence. Universal Router is command-based: the caller composes an arbitrary ordered list of operations, so it aggregates v2, v3, and v4 swaps, Permit2 approvals, ETH wrapping, and position-manager actions in one transaction, and it supports splitting, interleaving, and partial fills. It is unowned and non-upgradeable. New integrations should target Universal Router rather than the legacy `SwapRouter`.
+
+
+
+
+
+
+ Which Universal Router address should I use for each chain?
+
+
+
+ Universal Router is deployed at a different address on each chain and per router version, so do not hardcode a single address. The current per-chain addresses are published in [Supported Chains & Tokens](/docs/trading/swapping-api/supported-chains#supported-chains-for-swapping), and the canonical source of truth is maintained in the [universal-router-sdk constants](https://github.com/Uniswap/sdks/blob/main/sdks/universal-router-sdk/src/utils/constants.ts) on GitHub. Whitelist the address for the specific chain and version you integrate.
+
+
+
+
+
+
+ How do I enable partial fills with Universal Router?
+
+
+
+ Set the high bit (`0x80`) on a command byte to mark it allow-revert. If that command fails, the rest of the transaction still executes, which is how partial fills work:
+
+ ```solidity
+ command = 0x80 | 0x00; // V3_SWAP_EXACT_IN with allow-revert
+ ```
+
+ When you use allow-revert, include a cleanup command such as `SWEEP` so no funds are stranded in the router.
+
+
+
+
+
+
+ Do I need Permit2 to use Universal Router?
+
+
+
+ Universal Router pulls a user's ERC-20 tokens through Permit2, so the user first approves the Permit2 contract once per token and then authorizes the router by signature. Native ETH does not require Permit2. See the [Permit2 documentation](/docs/protocols/permit2/overview) for allowance and signature-transfer patterns.
+
+
+
+
+
## Where to Go Next
- Review command encoding in [Universal Router Commands](/docs/protocols/universal-router/concepts/commands)
diff --git a/content/protocols/v2/audits.mdx b/content/protocols/v2/audits.mdx
index d24aaa7e8..86cf16b0b 100644
--- a/content/protocols/v2/audits.mdx
+++ b/content/protocols/v2/audits.mdx
@@ -1,5 +1,6 @@
---
-title: Audits
+title: Uniswap v2 Audits
+sidebarTitle: Audits
description: Learn about the audits for Uniswap v2
---
diff --git a/content/protocols/v2/concepts/architecture.mdx b/content/protocols/v2/concepts/architecture.mdx
index 6d7700012..204b20194 100644
--- a/content/protocols/v2/concepts/architecture.mdx
+++ b/content/protocols/v2/concepts/architecture.mdx
@@ -1,5 +1,6 @@
---
-title: Architecture
+title: Uniswap v2 Architecture
+sidebarTitle: Architecture
description: Understand Uniswap v2 core and periphery contracts and the design decisions behind pair behavior and routing.
---
diff --git a/content/protocols/v2/concepts/flash-swap.mdx b/content/protocols/v2/concepts/flash-swap.mdx
index 26a510994..80ed72dc8 100644
--- a/content/protocols/v2/concepts/flash-swap.mdx
+++ b/content/protocols/v2/concepts/flash-swap.mdx
@@ -1,5 +1,6 @@
---
-title: Flash Swaps
+title: Uniswap v2 Flash Swaps
+sidebarTitle: Flash Swaps
description: Withdraw up to the full reserves of any ERC20 token on Uniswap v2 and execute arbitrary logic at no upfront cost.
---
diff --git a/content/protocols/v2/concepts/meta-transactions.mdx b/content/protocols/v2/concepts/meta-transactions.mdx
index 77c110f8a..f6fc92126 100644
--- a/content/protocols/v2/concepts/meta-transactions.mdx
+++ b/content/protocols/v2/concepts/meta-transactions.mdx
@@ -1,5 +1,4 @@
---
-id: supporting-meta-transactions
title: Supporting meta transactions
description: Understand meta-transaction approvals in Uniswap v2 with permit, domain separators, and EIP-712 signatures.
---
diff --git a/content/protocols/v2/concepts/oracles.mdx b/content/protocols/v2/concepts/oracles.mdx
index aef49c78d..e3bd0a70b 100644
--- a/content/protocols/v2/concepts/oracles.mdx
+++ b/content/protocols/v2/concepts/oracles.mdx
@@ -1,5 +1,6 @@
---
-title: Oracles
+title: Uniswap v2 Oracles
+sidebarTitle: Oracles
description: Understand Uniswap v2 oracle design and use cumulative prices to build manipulation-resistant TWAP feeds.
---
diff --git a/content/protocols/v2/concepts/pools.mdx b/content/protocols/v2/concepts/pools.mdx
index 6775c940a..13162c0ea 100644
--- a/content/protocols/v2/concepts/pools.mdx
+++ b/content/protocols/v2/concepts/pools.mdx
@@ -1,5 +1,4 @@
---
-id: pools
title: Pools
description: Understand Uniswap v2 pools, LP shares, and how reserve balances and fees affect liquidity outcomes.
---
diff --git a/content/protocols/v2/concepts/pricing.mdx b/content/protocols/v2/concepts/pricing.mdx
index 38e16a619..cbb8b2ab9 100644
--- a/content/protocols/v2/concepts/pricing.mdx
+++ b/content/protocols/v2/concepts/pricing.mdx
@@ -1,6 +1,6 @@
---
-id: pricing
-title: Pricing
+title: Uniswap v2 Pricing
+sidebarTitle: Pricing
description: Understand Uniswap v2 pricing mechanics, oracle-safe quoting, and exact input and output trade calculations.
---
diff --git a/content/protocols/v2/concepts/swapping.mdx b/content/protocols/v2/concepts/swapping.mdx
index 7767aaeda..b7a803617 100644
--- a/content/protocols/v2/concepts/swapping.mdx
+++ b/content/protocols/v2/concepts/swapping.mdx
@@ -1,5 +1,6 @@
---
-title: Swaps
+title: Uniswap v2 Swaps
+sidebarTitle: Swaps
description: Understand how Uniswap v2 swaps move reserves and how token transfers are validated during execution.
---
diff --git a/content/protocols/v2/concepts/understanding-returns.mdx b/content/protocols/v2/concepts/understanding-returns.mdx
index 6beed2273..773dc3155 100644
--- a/content/protocols/v2/concepts/understanding-returns.mdx
+++ b/content/protocols/v2/concepts/understanding-returns.mdx
@@ -1,5 +1,4 @@
---
-id: understanding-returns
title: Understanding Returns
description: Understand Uniswap v2 LP return drivers, including fee income, divergence loss, and market volatility effects.
---
@@ -46,7 +45,7 @@ So let’s look at the impact of a price change on a liquidity provider. To keep
"Of course, if the price were to return to the same value as when the liquidity provider added their liquidity, this loss would disappear. **For this reason, we can call it an **impermanent loss**.** Using the equations above, we can derive a formula for the size of the impermanent loss in terms of the price ratio between when liquidity was supplied and now. We get the following:"
-- "`impermanent_loss = 2 * sqrt(price_ratio) / (1+price_ratio) — 1`"
+- "`impermanent_loss = 2 * sqrt(price_ratio) / (1+price_ratio) - 1`"
- "Which we can plot out to get a general sense of the scale of the impermanent loss at different price ratios:"
diff --git a/content/protocols/v2/deployments.mdx b/content/protocols/v2/deployments.mdx
index 1ec5aea21..4d7d78465 100644
--- a/content/protocols/v2/deployments.mdx
+++ b/content/protocols/v2/deployments.mdx
@@ -1,8 +1,13 @@
---
-title: Deployments
+title: Uniswap v2 Deployments
+sidebarTitle: Deployments
description: Find Uniswap v2 factory and router deployment addresses across supported networks.
---
+
+ All Uniswap v2 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
Contract addresses for the [`Uniswap v2 Factory`](https://github.com/Uniswap/v2-core/blob/master/contracts/UniswapV2Factory.sol) and the [`Uniswap v2 Router02`](https://github.com/Uniswap/v2-periphery/blob/master/contracts/UniswapV2Router02.sol).
| Network | Factory Contract Address | V2Router02 Contract Address |
@@ -23,3 +28,4 @@ Contract addresses for the [`Uniswap v2 Factory`](https://github.com/Uniswap/v2-
| MegaETH | `0xbf56488c857a881ae7e3bed27cf99c10a7ab7e50` | `0xb73055db2b3a3eae87a331dd88e4a80b43602690` |
| Tempo | `0xf9ec577a4e45b5278bb7cf60fcbc20c3acaef68f` | `0x0fbac3c46f6f83b44c7fb4ea986d7309c701d73e` |
| Robinhood Chain | `0x8bceaa40b9acdfaedf85adf4ff01f5ad6517937f` | `0x89e5db8b5aa49aa85ac63f691524311aeb649eba` |
+| HyperEVM | `0x89e5DB8B5aA49aA85AC63f691524311AEB649eba` | `0x1f7d7550B1b028f7571E69A784071F0205FD2EfA` |
diff --git a/content/protocols/v2/guides/building-an-oracle.mdx b/content/protocols/v2/guides/building-an-oracle.mdx
index bd91e627d..e7a688553 100644
--- a/content/protocols/v2/guides/building-an-oracle.mdx
+++ b/content/protocols/v2/guides/building-an-oracle.mdx
@@ -1,5 +1,4 @@
---
-id: building-an-oracle
title: Building an Oracle
description: Build a Uniswap v2 TWAP oracle using cumulative prices, observation windows, and resilient maintenance patterns.
---
diff --git a/content/protocols/v2/guides/flash-swaps.mdx b/content/protocols/v2/guides/flash-swaps.mdx
index 3441e1320..ccd35ace8 100644
--- a/content/protocols/v2/guides/flash-swaps.mdx
+++ b/content/protocols/v2/guides/flash-swaps.mdx
@@ -1,6 +1,6 @@
---
-id: using-flash-swaps
-title: Flash Swaps
+title: Implementing Flash Swaps on Uniswap v2
+sidebarTitle: Flash Swaps
description: Implement Uniswap v2 flash swaps by handling callbacks, validating pair context, and repaying with required fees.
---
diff --git a/content/protocols/v2/guides/getting-pair-addresses.mdx b/content/protocols/v2/guides/getting-pair-addresses.mdx
index 6a93911a3..c86253220 100644
--- a/content/protocols/v2/guides/getting-pair-addresses.mdx
+++ b/content/protocols/v2/guides/getting-pair-addresses.mdx
@@ -1,6 +1,6 @@
---
-id: getting-pair-addresses
-title: Pair Addresses
+title: Uniswap v2 Pair Addresses
+sidebarTitle: Pair Addresses
description: Compute deterministic Uniswap v2 pair addresses with CREATE2 and verify pair ordering and factory inputs.
---
diff --git a/content/protocols/v2/guides/providing-liquidity.mdx b/content/protocols/v2/guides/providing-liquidity.mdx
index fb3615a25..de1c2c76e 100644
--- a/content/protocols/v2/guides/providing-liquidity.mdx
+++ b/content/protocols/v2/guides/providing-liquidity.mdx
@@ -1,5 +1,4 @@
---
-id: providing-liquidity
title: Providing Liquidity
description: Provide Uniswap v2 liquidity safely by matching reserve ratios and applying slippage-aware minting logic.
---
diff --git a/content/protocols/v2/guides/swapping.mdx b/content/protocols/v2/guides/swapping.mdx
index 796f6b68e..bf4e064cf 100644
--- a/content/protocols/v2/guides/swapping.mdx
+++ b/content/protocols/v2/guides/swapping.mdx
@@ -1,5 +1,4 @@
---
-id: trading-from-a-smart-contract
title: Implement a Swap
description: Implement Uniswap v2 swaps from smart contracts using router functions and external price safety checks.
---
diff --git a/content/protocols/v2/guides/troubleshooting.mdx b/content/protocols/v2/guides/troubleshooting.mdx
index e7334bb14..ef8a3204d 100644
--- a/content/protocols/v2/guides/troubleshooting.mdx
+++ b/content/protocols/v2/guides/troubleshooting.mdx
@@ -64,3 +64,5 @@ The transaction deadline elapsed before inclusion onchain.
### Unable To Approve Transaction On The Front End
Some tokens block direct allowance increases. Setting allowance to zero first, then setting the target amount, usually resolves this.
+
+For developer support, reach out to our team through the Help Center.
diff --git a/content/protocols/v2/overview.mdx b/content/protocols/v2/overview.mdx
index 4671ddcfe..53d61e347 100644
--- a/content/protocols/v2/overview.mdx
+++ b/content/protocols/v2/overview.mdx
@@ -1,5 +1,6 @@
---
-title: Overview
+title: Uniswap v2 Protocol Overview
+sidebarTitle: Overview
description: Get started with Uniswap v2 concepts, guides, deployments, and security references for protocol integrations.
---
diff --git a/content/protocols/v3/audits.mdx b/content/protocols/v3/audits.mdx
index 57e9a9e7a..7479a699e 100644
--- a/content/protocols/v3/audits.mdx
+++ b/content/protocols/v3/audits.mdx
@@ -1,5 +1,6 @@
---
-title: Audits
+title: Uniswap v3 Audits
+sidebarTitle: Audits
description: Learn about the audits for Uniswap v3
---
diff --git a/content/protocols/v3/concepts/architecture.mdx b/content/protocols/v3/concepts/architecture.mdx
index d4e94922f..01076817c 100644
--- a/content/protocols/v3/concepts/architecture.mdx
+++ b/content/protocols/v3/concepts/architecture.mdx
@@ -1,6 +1,6 @@
---
-id: overview
-title: Architecture
+title: Uniswap v3 Architecture
+sidebarTitle: Architecture
description: Understand Uniswap v3 architecture, including core contracts, factory design, and pool interaction patterns.
---
@@ -38,6 +38,29 @@ Pools primarily serve as automated market makers for the paired assets. Addition
Source code: [UniswapV3Pool.sol](https://github.com/Uniswap/uniswap-v3-core/blob/main/contracts/UniswapV3Pool.sol)
+### Core libraries
+
+The pool contract delegates most of its arithmetic to a set of libraries. They are the contracts a v3 integration reads most often when reasoning about ticks, prices and liquidity, and each one is small enough to read end to end.
+
+| Library | What it does |
+| --- | --- |
+| [TickMath](https://github.com/Uniswap/uniswap-v3-core/blob/main/contracts/libraries/TickMath.sol) | Computes sqrt prices from ticks and vice versa, for ticks of size 1.0001 |
+| [SqrtPriceMath](https://github.com/Uniswap/uniswap-v3-core/blob/main/contracts/libraries/SqrtPriceMath.sol) | Price and amount functions based on Q64.96 sqrt price and liquidity |
+| [SwapMath](https://github.com/Uniswap/uniswap-v3-core/blob/main/contracts/libraries/SwapMath.sol) | Computes the result of a swap within a single tick |
+| [FullMath](https://github.com/Uniswap/uniswap-v3-core/blob/main/contracts/libraries/FullMath.sol) | 512-bit multiply and divide without loss of precision |
+| [LiquidityMath](https://github.com/Uniswap/uniswap-v3-core/blob/main/contracts/libraries/LiquidityMath.sol) | Adds a signed liquidity delta to liquidity |
+| [TickBitmap](https://github.com/Uniswap/uniswap-v3-core/blob/main/contracts/libraries/TickBitmap.sol) | Packed record of which ticks are initialized |
+| [Tick](https://github.com/Uniswap/uniswap-v3-core/blob/main/contracts/libraries/Tick.sol) | Per-tick state, including liquidity and fee growth |
+| [Position](https://github.com/Uniswap/uniswap-v3-core/blob/main/contracts/libraries/Position.sol) | Per-position state, keyed by owner and tick range |
+
+Alongside these sit the numeric helpers the pool uses internally: `BitMath`, `FixedPoint96`, `FixedPoint128`, `LowGasSafeMath`, `SafeCast`, `UnsafeMath` and `TransferHelper`.
+
+Every library carries natspec on each function, so the source is the reference.
+
+
+Source code: [libraries/](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts/libraries)
+
+
## Periphery
The periphery is a constellation of smart contracts designed to support domain-specific interactions with the core. As the Uniswap protocol is a permissionless system, the contracts described below have no special privileges and are only a small subset of possible periphery-like contracts.
diff --git a/content/protocols/v3/concepts/unsupported-tokens.mdx b/content/protocols/v3/concepts/unsupported-tokens.mdx
index 2a736e6f4..7e416fcba 100644
--- a/content/protocols/v3/concepts/unsupported-tokens.mdx
+++ b/content/protocols/v3/concepts/unsupported-tokens.mdx
@@ -1,5 +1,4 @@
---
-id: integration-issues
title: Token Integration Issues
description: Understand Uniswap v3 token integration issues and how non-standard token behavior affects pool interactions.
---
diff --git a/content/protocols/v3/deployments/index.mdx b/content/protocols/v3/deployments/index.mdx
index 9ade174b5..20ef2c843 100644
--- a/content/protocols/v3/deployments/index.mdx
+++ b/content/protocols/v3/deployments/index.mdx
@@ -1,9 +1,13 @@
---
-id: deployments
-title: Deployments
+title: Uniswap v3 Deployments
+sidebarTitle: Deployments
description: Find official Uniswap v3 deployment addresses across supported networks and chain-specific references.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
## Uniswap v3 Contract Deployments
The Uniswap Protocol is made up of multiple contracts on many networks.
@@ -27,6 +31,7 @@ Please do not assume contracts are deployed to the same addresses across chains,
- [`MegaETH`](./v3-megaeth-deployments)
- [`Tempo`](./v3-tempo-deployments)
- [`Robinhood Chain`](./v3-robinhood-chain-deployments)
+- [`HyperEVM`](./v3-hyperevm-deployments)
These addresses are final and were deployed from these npm package versions:
diff --git a/content/protocols/v3/deployments/meta.json b/content/protocols/v3/deployments/meta.json
index ebe8f8dd9..bc18ab647 100644
--- a/content/protocols/v3/deployments/meta.json
+++ b/content/protocols/v3/deployments/meta.json
@@ -8,6 +8,7 @@
"v3-bnb-deployments",
"v3-celo-deployments",
"v3-ethereum-deployments",
+ "v3-hyperevm-deployments",
"v3-megaeth-deployments",
"v3-monad-deployments",
"v3-tempo-deployments",
diff --git a/content/protocols/v3/deployments/v3-arbitrum-deployments.mdx b/content/protocols/v3/deployments/v3-arbitrum-deployments.mdx
index 78046d505..72c458428 100644
--- a/content/protocols/v3/deployments/v3-arbitrum-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-arbitrum-deployments.mdx
@@ -1,9 +1,12 @@
---
-id: arbitrum-deployments
title: Arbitrum Deployments
description: Review Uniswap v3 deployment addresses and contract references for Arbitrum integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | Arbitrum Addresses | Arbitrum Sepolia Addresses |
diff --git a/content/protocols/v3/deployments/v3-avalanche-deployments.mdx b/content/protocols/v3/deployments/v3-avalanche-deployments.mdx
index 5a3d5d601..14daeb978 100644
--- a/content/protocols/v3/deployments/v3-avalanche-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-avalanche-deployments.mdx
@@ -1,9 +1,12 @@
---
-id: avalanche-deployments
title: Avalanche Deployments
description: Review Uniswap v3 deployment addresses and contract references for Avalanche integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | AVAX Avalanche C-Chain Addresses |
diff --git a/content/protocols/v3/deployments/v3-base-deployments.mdx b/content/protocols/v3/deployments/v3-base-deployments.mdx
index ca9a638b1..f241de092 100644
--- a/content/protocols/v3/deployments/v3-base-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-base-deployments.mdx
@@ -1,9 +1,12 @@
---
-id: base-deployments
title: Base Deployments
description: Review Uniswap v3 deployment addresses and contract references for Base integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | Base Address | Base Sepolia Address |
diff --git a/content/protocols/v3/deployments/v3-bnb-deployments.mdx b/content/protocols/v3/deployments/v3-bnb-deployments.mdx
index 595a6ab7b..069b7375d 100644
--- a/content/protocols/v3/deployments/v3-bnb-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-bnb-deployments.mdx
@@ -3,6 +3,10 @@ title: BNB Deployments
description: Uniswap v3 contract deployment addresses on BNB Smart Chain.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | BNB Address |
diff --git a/content/protocols/v3/deployments/v3-celo-deployments.mdx b/content/protocols/v3/deployments/v3-celo-deployments.mdx
index 9fe6ad52b..a3a970239 100644
--- a/content/protocols/v3/deployments/v3-celo-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-celo-deployments.mdx
@@ -1,9 +1,12 @@
---
-id: celo-deployments
title: CELO Deployments
description: Review Uniswap v3 deployment addresses and contract references for Celo integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | CELO Address | Alfajores Address |
diff --git a/content/protocols/v3/deployments/v3-ethereum-deployments.mdx b/content/protocols/v3/deployments/v3-ethereum-deployments.mdx
index 8b2e67aae..c28bf9432 100644
--- a/content/protocols/v3/deployments/v3-ethereum-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-ethereum-deployments.mdx
@@ -1,9 +1,12 @@
---
-id: ethereum-deployments
title: Ethereum Deployments
description: Review Uniswap v3 deployment addresses and contract references for Ethereum mainnet integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | Mainnet | Ethereum Sepolia Addresses |
@@ -11,8 +14,8 @@ The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap
| [UniswapV3Factory](https://github.com/Uniswap/uniswap-v3-core/blob/v1.0.0/contracts/UniswapV3Factory.sol) | `0x1F98431c8aD98523631AE4a59f267346ea31F984` | `0x0227628f3F023bb0B980b67D528571c95c6DaC1c` |
| [Multicall](https://etherscan.io/address/0x1F98415757620B543A52E61c46B32eB19261F984#code) | `0x1F98415757620B543A52E61c46B32eB19261F984` | `` |
| [Multicall2](https://etherscan.io/address/0x5BA1e12693Dc8F9c48aAD8770482f4739bEeD696#code) | `0x5BA1e12693Dc8F9c48aAD8770482f4739bEeD696` | `0xD7F33bCdb21b359c8ee6F0251d30E94832baAd07` |
-| [ProxyAdmin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.4.1-solc-0.7-2/contracts/proxy/ProxyAdmin.sol) | `0xB753548F6E010e7e680BA186F9Ca1BdAB2E90cf2` | `0x0b343475d44EC2b4b8243EBF81dc888BF0A14b36` |
-| [TickLens](https://github.com/Uniswap/uniswap-v3-periphery/blob/v1.0.0/contracts/lens/TickLens.sol) | `0xbfd8137f7d1516D3ea5cA83523914859ec47F573` | `` |
+| [ProxyAdmin](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.4.1-solc-0.7-2/contracts/proxy/ProxyAdmin.sol) | `0xB753548F6E010e7e680BA186F9Ca1BdAB2E90cf2` | `0x5d3ceBAb8fbA22B48d725a40452e874F24E537f4` |
+| [TickLens](https://github.com/Uniswap/uniswap-v3-periphery/blob/v1.0.0/contracts/lens/TickLens.sol) | `0xbfd8137f7d1516D3ea5cA83523914859ec47F573` | `0x0b343475d44EC2b4b8243EBF81dc888BF0A14b36` |
| [Quoter](https://github.com/Uniswap/uniswap-v3-periphery/blob/v1.0.0/contracts/lens/Quoter.sol) | `0xb27308f9F90D607463bb33eA1BeBb41C27CE5AB6` | `` |
| [SwapRouter](https://github.com/Uniswap/uniswap-v3-periphery/blob/v1.0.0/contracts/SwapRouter.sol) | `0xE592427A0AEce92De3Edee1F18E0157C05861564` | `` |
| [NFTDescriptor](https://github.com/Uniswap/uniswap-v3-periphery/blob/v1.0.0/contracts/libraries/NFTDescriptor.sol) | `0x42B24A95702b9986e82d421cC3568932790A48Ec` | `0x3B5E3c5E595D85fbFBC2a42ECC091e183E76697C` |
diff --git a/content/protocols/v3/deployments/v3-hyperevm-deployments.mdx b/content/protocols/v3/deployments/v3-hyperevm-deployments.mdx
new file mode 100644
index 000000000..200d5f45c
--- /dev/null
+++ b/content/protocols/v3/deployments/v3-hyperevm-deployments.mdx
@@ -0,0 +1,54 @@
+---
+title: HyperEVM Deployments
+description: Review Uniswap v3 deployment addresses and contract references for HyperEVM integrations.
+---
+
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
+The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
+
+HyperEVM is chainId `999` with HYPE as the gas token. Confirm any deployment on the [HyperEVM explorer](https://hyperevmscan.io).
+
+| Contract | HyperEVM Addresses |
+| ---------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- |
+| [UniswapV3Factory](https://github.com/Uniswap/uniswap-v3-core/blob/v1.0.0/contracts/UniswapV3Factory.sol) | [`0xf0db7b58379503491d857dB50AC9ece64c653918`](https://hyperevmscan.io/address/0xf0db7b58379503491d857dB50AC9ece64c653918) |
+| [UniswapInterfaceMulticall](https://github.com/Uniswap/v3-periphery/blob/main/contracts/lens/UniswapInterfaceMulticall.sol) | [`0x33e885eD0Ec9bF04EcfB19341582aADCb4c8A9E7`](https://hyperevmscan.io/address/0x33e885eD0Ec9bF04EcfB19341582aADCb4c8A9E7) |
+| [TickLens](https://github.com/Uniswap/uniswap-v3-periphery/blob/v1.0.0/contracts/lens/TickLens.sol) | [`0x9EB8600665b55d10C1eB2316Ca5127A9cA6E2E76`](https://hyperevmscan.io/address/0x9EB8600665b55d10C1eB2316Ca5127A9cA6E2E76) |
+| [Quoter](https://github.com/Uniswap/uniswap-v3-periphery/blob/v1.0.0/contracts/lens/Quoter.sol) | [`0xe29df26bce7F7e691F37f2313eA6726fc2b481B3`](https://hyperevmscan.io/address/0xe29df26bce7F7e691F37f2313eA6726fc2b481B3) |
+| [QuoterV2](https://github.com/Uniswap/v3-periphery/blob/main/contracts/lens/QuoterV2.sol) | [`0x7DfD4F31be6814D2906BDE155c3e1B146EAc1468`](https://hyperevmscan.io/address/0x7DfD4F31be6814D2906BDE155c3e1B146EAc1468) |
+| [MixedRouteQuoterV2](https://github.com/Uniswap/swap-router-contracts/blob/main/contracts/lens/MixedRouteQuoterV2.sol) | [`0xD6A1239f7d0A47420349a80a4406EAa7a1283576`](https://hyperevmscan.io/address/0xD6A1239f7d0A47420349a80a4406EAa7a1283576) |
+| [NFTDescriptor](https://github.com/Uniswap/uniswap-v3-periphery/blob/v1.0.0/contracts/libraries/NFTDescriptor.sol) | [`0x2E9D45Bb7b30549F5216813aDA9a6b7982C5B3ED`](https://hyperevmscan.io/address/0x2E9D45Bb7b30549F5216813aDA9a6b7982C5B3ED) |
+| [NonfungibleTokenPositionDescriptor](https://github.com/Uniswap/uniswap-v3-periphery/blob/v1.0.0/contracts/NonfungibleTokenPositionDescriptor.sol) | [`0x73991a25C818Bf1f1128dEAaB1492D45638DE0D3`](https://hyperevmscan.io/address/0x73991a25C818Bf1f1128dEAaB1492D45638DE0D3) |
+| [NonfungiblePositionManager](https://github.com/Uniswap/uniswap-v3-periphery/blob/v1.0.0/contracts/NonfungiblePositionManager.sol) | [`0x39654A85A4C05127f5Fd6ED22CAeC077A0fB1377`](https://hyperevmscan.io/address/0x39654A85A4C05127f5Fd6ED22CAeC077A0fB1377) |
+| [V3Migrator](https://github.com/Uniswap/uniswap-v3-periphery/blob/v1.0.0/contracts/V3Migrator.sol) | [`0x384461c47446324EC0D861aD902fc3935c969B5c`](https://hyperevmscan.io/address/0x384461c47446324EC0D861aD902fc3935c969B5c) |
+| [SwapRouter](https://github.com/Uniswap/uniswap-v3-periphery/blob/v1.0.0/contracts/SwapRouter.sol) | [`0xfF8137B0E0B9EF7021850B5124987C51E5424A9E`](https://hyperevmscan.io/address/0xfF8137B0E0B9EF7021850B5124987C51E5424A9E) |
+| [SwapRouter02](https://github.com/Uniswap/swap-router-contracts/blob/main/contracts/SwapRouter02.sol) | [`0x7AdF4701AbCDBc5Dcf5Cb58B526f897e048F0D11`](https://hyperevmscan.io/address/0x7AdF4701AbCDBc5Dcf5Cb58B526f897e048F0D11) |
+| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://hyperevmscan.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
+| [UniversalRouter](https://github.com/Uniswap/universal-router) | [`0x9aFe3C497e19501DB228F28CdBdD29bC98F65DBa`](https://hyperevmscan.io/address/0x9aFe3C497e19501DB228F28CdBdD29bC98F65DBa) |
+| [UniversalRouter 2.1.2](https://github.com/Uniswap/universal-router) | [`0xeD270A1Bcdc63cf1356D695e7f40961d4819d6bF`](https://hyperevmscan.io/address/0xeD270A1Bcdc63cf1356D695e7f40961d4819d6bF) |
+
+These addresses are final and were deployed from these npm package versions:
+
+- [`@uniswap/v3-core@1.0.0`](https://github.com/Uniswap/uniswap-v3-core/tree/v1.0.0)
+- [`@uniswap/v3-periphery@1.0.0`](https://github.com/Uniswap/uniswap-v3-periphery/tree/v1.0.0)
+- [`@uniswap/swap-router-contracts@1.1.0`](https://github.com/Uniswap/swap-router-contracts/tree/v1.1.0)
+
+## Uniswap v3 Staker
+
+An up-to-date list of [deploy addresses by chain is hosted on GitHub](https://github.com/Uniswap/v3-staker/releases/tag/v1.0.2) for the `UniswapV3Staker` contract.
+
+## Universal Router
+
+The `UniversalRouter` contract is the current preferred entrypoint for ERC20 and NFT swaps, replacing, among other contracts, `SwapRouter02`. An up-to-date list of [deploy addresses by chain is hosted on GitHub](https://github.com/Uniswap/universal-router/tree/main/deploy-addresses).
+
+## Uniswap Pool Deployments
+
+Every Uniswap pool is a unique instance of the `UniswapV3Pool` contract and is deployed at its own unique address. The contract source code of the pool will be auto-verified on the explorer. You can browse [HyperEVM contracts on the explorer](https://hyperevmscan.io) to confirm any deployment.
+
+You can look up the address of an existing pool on [Uniswap Info](https://info.uniswap.org/#/) or by calling the `getPool` function on the `UniswapV3Factory` contract.
+
+```solidity
+getPool("0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2", 3000)
+```
diff --git a/content/protocols/v3/deployments/v3-megaeth-deployments.mdx b/content/protocols/v3/deployments/v3-megaeth-deployments.mdx
index f305a0417..006744475 100644
--- a/content/protocols/v3/deployments/v3-megaeth-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-megaeth-deployments.mdx
@@ -1,9 +1,12 @@
---
-id: megaeth-deployments
title: MegaETH Deployments
description: Review Uniswap v3 deployment addresses and contract references for MegaETH integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | MegaETH Addresses |
diff --git a/content/protocols/v3/deployments/v3-monad-deployments.mdx b/content/protocols/v3/deployments/v3-monad-deployments.mdx
index ff814f1b6..4346bfb30 100644
--- a/content/protocols/v3/deployments/v3-monad-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-monad-deployments.mdx
@@ -1,9 +1,12 @@
---
-id: monad-deployments
title: Monad Deployments
description: Review Uniswap v3 deployment addresses and contract references for Monad integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | Monad Addresses |
diff --git a/content/protocols/v3/deployments/v3-optimism-deployments.mdx b/content/protocols/v3/deployments/v3-optimism-deployments.mdx
index 50afc8c7a..9e8856b3d 100644
--- a/content/protocols/v3/deployments/v3-optimism-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-optimism-deployments.mdx
@@ -1,9 +1,12 @@
---
-id: optimism-deployments
title: Optimism Deployments
description: Review Uniswap v3 deployment addresses and contract references for Optimism integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | Optimism Addresses | OP Sepolia Addresses SDK-Core | OP Sepolia Addresses |
diff --git a/content/protocols/v3/deployments/v3-polygon-deployments.mdx b/content/protocols/v3/deployments/v3-polygon-deployments.mdx
index a0c0812b0..bdea29743 100644
--- a/content/protocols/v3/deployments/v3-polygon-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-polygon-deployments.mdx
@@ -3,6 +3,10 @@ title: Polygon Deployments
description: Uniswap v3 contract deployment addresses on Polygon.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | Polygon Address |
diff --git a/content/protocols/v3/deployments/v3-robinhood-chain-deployments.mdx b/content/protocols/v3/deployments/v3-robinhood-chain-deployments.mdx
index 0aa52b663..0c636d7cc 100644
--- a/content/protocols/v3/deployments/v3-robinhood-chain-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-robinhood-chain-deployments.mdx
@@ -1,9 +1,12 @@
---
-id: robinhood-chain-deployments
title: Robinhood Chain Deployments
description: Review Uniswap v3 deployment addresses and contract references for Robinhood Chain integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
Robinhood Chain is an Arbitrum Orbit L2 (chainId `4663`) with ETH as the gas token. Confirm any deployment on the [Robinhood Chain explorer](https://robinhoodchain.blockscout.com/).
diff --git a/content/protocols/v3/deployments/v3-tempo-deployments.mdx b/content/protocols/v3/deployments/v3-tempo-deployments.mdx
index c6c9b1d1f..296e3fcbe 100644
--- a/content/protocols/v3/deployments/v3-tempo-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-tempo-deployments.mdx
@@ -1,9 +1,12 @@
---
-id: tempo-deployments
title: Tempo Deployments
description: Review Uniswap v3 deployment addresses and contract references for Tempo integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | Tempo Addresses |
diff --git a/content/protocols/v3/deployments/v3-unichain-deployments.mdx b/content/protocols/v3/deployments/v3-unichain-deployments.mdx
index 00a91fedf..c80c5f290 100644
--- a/content/protocols/v3/deployments/v3-unichain-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-unichain-deployments.mdx
@@ -1,9 +1,12 @@
---
-id: unichain-deployments
title: Unichain Deployments
description: Review Uniswap v3 deployment addresses and contract references for Unichain integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | Unichain Addresses | Unichain Sepolia Addresses |
diff --git a/content/protocols/v3/deployments/v3-world-chain-deployments.mdx b/content/protocols/v3/deployments/v3-world-chain-deployments.mdx
index 04457c9e5..3d2f76967 100644
--- a/content/protocols/v3/deployments/v3-world-chain-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-world-chain-deployments.mdx
@@ -3,6 +3,10 @@ title: World Chain Deployments
description: Review Uniswap v3 deployment addresses and contract references for World Chain integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | WorldChain |
diff --git a/content/protocols/v3/deployments/v3-xlayer-deployments.mdx b/content/protocols/v3/deployments/v3-xlayer-deployments.mdx
index 7450bcaca..3511a2381 100644
--- a/content/protocols/v3/deployments/v3-xlayer-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-xlayer-deployments.mdx
@@ -1,9 +1,12 @@
---
-id: xlayer-deployments
title: X Layer Deployments
description: Review Uniswap v3 deployment addresses and contract references for X Layer integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | Address |
| --- | --- |
diff --git a/content/protocols/v3/deployments/v3-zksync-deployments.mdx b/content/protocols/v3/deployments/v3-zksync-deployments.mdx
index 7984b3abf..ec1a922ca 100644
--- a/content/protocols/v3/deployments/v3-zksync-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-zksync-deployments.mdx
@@ -1,9 +1,12 @@
---
-id: ZKsync-deployments
title: ZKsync Deployments
description: Review Uniswap v3 deployment addresses and contract references for ZKsync integrations.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | ZKsync Mainnet |
diff --git a/content/protocols/v3/deployments/v3-zora-deployments.mdx b/content/protocols/v3/deployments/v3-zora-deployments.mdx
index e5da9f335..bc32ec834 100644
--- a/content/protocols/v3/deployments/v3-zora-deployments.mdx
+++ b/content/protocols/v3/deployments/v3-zora-deployments.mdx
@@ -3,6 +3,10 @@ title: Zora Deployments
description: Uniswap v3 contract deployment addresses on Zora and Zora Sepolia.
---
+
+ All Uniswap v3 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The latest version of `@uniswap/v3-core`, `@uniswap/v3-periphery`, and `@uniswap/swap-router-contracts` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
| Contract | Zora | Zora Sepolia |
diff --git a/content/protocols/v3/guides/flash-swaps/calling-flash.mdx b/content/protocols/v3/guides/flash-swaps/calling-flash.mdx
index f2b3442d3..e6f97afbd 100644
--- a/content/protocols/v3/guides/flash-swaps/calling-flash.mdx
+++ b/content/protocols/v3/guides/flash-swaps/calling-flash.mdx
@@ -1,5 +1,4 @@
---
-id: calling-flash
title: Calling Flash
description: Call flash swap functions on Uniswap v3 and encode parameters for callback-driven execution.
---
diff --git a/content/protocols/v3/guides/flash-swaps/final-contract.mdx b/content/protocols/v3/guides/flash-swaps/final-contract.mdx
index eb6bdee36..5d5e4fd6d 100644
--- a/content/protocols/v3/guides/flash-swaps/final-contract.mdx
+++ b/content/protocols/v3/guides/flash-swaps/final-contract.mdx
@@ -1,5 +1,4 @@
---
-id: final-contract
title: The Final Contract
description: Review a complete Uniswap v3 flash swap contract with callback handling and settlement logic.
---
diff --git a/content/protocols/v3/guides/flash-swaps/flash-callback.mdx b/content/protocols/v3/guides/flash-swaps/flash-callback.mdx
index a0c5f4a96..dd247f7c0 100644
--- a/content/protocols/v3/guides/flash-swaps/flash-callback.mdx
+++ b/content/protocols/v3/guides/flash-swaps/flash-callback.mdx
@@ -1,5 +1,4 @@
---
-id: flash-callback
title: The Flash Callback
description: Implement the Uniswap v3 flash callback to settle borrowed amounts and fees correctly.
---
diff --git a/content/protocols/v3/guides/flash-swaps/getting-started.mdx b/content/protocols/v3/guides/flash-swaps/getting-started.mdx
index d9e296b35..7e78a5dbc 100644
--- a/content/protocols/v3/guides/flash-swaps/getting-started.mdx
+++ b/content/protocols/v3/guides/flash-swaps/getting-started.mdx
@@ -1,6 +1,6 @@
---
-id: inheritance-constructors
-title: Get Started
+title: Get Started with Uniswap v3 Flash Swaps
+sidebarTitle: Get Started
description: Set up a Uniswap v3 flash swap environment and prepare the contract workflow end to end.
---
diff --git a/content/protocols/v3/guides/getting-started.mdx b/content/protocols/v3/guides/getting-started.mdx
index 402efffd9..2cb4d2167 100644
--- a/content/protocols/v3/guides/getting-started.mdx
+++ b/content/protocols/v3/guides/getting-started.mdx
@@ -143,3 +143,5 @@ $ npx hardhat test --network localhost
- [Managing Liquidity Getting Started](/docs/protocols/v3/guides/managing-liquidity/getting-started)
- [Flash Swaps Getting Started](/docs/protocols/v3/guides/flash-swaps/getting-started)
- [Troubleshooting](/docs/protocols/v3/guides/troubleshooting)
+
+For developer support, reach out to our team through the
Help Center.
diff --git a/content/protocols/v3/guides/managing-liquidity/collect-fees.mdx b/content/protocols/v3/guides/managing-liquidity/collect-fees.mdx
index 547056790..299d6f000 100644
--- a/content/protocols/v3/guides/managing-liquidity/collect-fees.mdx
+++ b/content/protocols/v3/guides/managing-liquidity/collect-fees.mdx
@@ -1,6 +1,6 @@
---
-id: collect-fees
-title: Collecting Fees
+title: Collecting Fees on Uniswap v3
+sidebarTitle: Collecting Fees
description: Collect accrued fees from Uniswap v3 positions using NonfungiblePositionManager flows.
---
diff --git a/content/protocols/v3/guides/managing-liquidity/decrease-liquidity.mdx b/content/protocols/v3/guides/managing-liquidity/decrease-liquidity.mdx
index 1559a6485..dc47a6bf9 100644
--- a/content/protocols/v3/guides/managing-liquidity/decrease-liquidity.mdx
+++ b/content/protocols/v3/guides/managing-liquidity/decrease-liquidity.mdx
@@ -1,5 +1,4 @@
---
-id: decrease-liquidity
title: Decrease Liquidity (v3)
description: Decrease an existing Uniswap v3 position and collect the returned token amounts with PositionManager.
---
diff --git a/content/protocols/v3/guides/managing-liquidity/getting-started.mdx b/content/protocols/v3/guides/managing-liquidity/getting-started.mdx
index b803e03e5..b46bb45a2 100644
--- a/content/protocols/v3/guides/managing-liquidity/getting-started.mdx
+++ b/content/protocols/v3/guides/managing-liquidity/getting-started.mdx
@@ -1,5 +1,4 @@
---
-id: setting-up
title: Set Up Your Contract
description: Set up a Uniswap v3 liquidity management contract workflow with position lifecycle prerequisites.
---
diff --git a/content/protocols/v3/guides/managing-liquidity/increase-liquidity.mdx b/content/protocols/v3/guides/managing-liquidity/increase-liquidity.mdx
index bbb9e0137..9dfd25070 100644
--- a/content/protocols/v3/guides/managing-liquidity/increase-liquidity.mdx
+++ b/content/protocols/v3/guides/managing-liquidity/increase-liquidity.mdx
@@ -1,5 +1,4 @@
---
-id: increase-liquidity
title: Increase Liquidity (v3)
description: Increase an existing Uniswap v3 position using PositionManager while preserving the position range.
---
diff --git a/content/protocols/v3/guides/managing-liquidity/mint-a-position.mdx b/content/protocols/v3/guides/managing-liquidity/mint-a-position.mdx
index 121553ba7..738799b72 100644
--- a/content/protocols/v3/guides/managing-liquidity/mint-a-position.mdx
+++ b/content/protocols/v3/guides/managing-liquidity/mint-a-position.mdx
@@ -1,5 +1,4 @@
---
-id: mint-a-position
title: Mint a New Position
description: Mint a new Uniswap v3 liquidity position with token approvals, ranges, and position parameters.
---
diff --git a/content/protocols/v3/guides/managing-liquidity/the-full-contract.mdx b/content/protocols/v3/guides/managing-liquidity/the-full-contract.mdx
index 004129b2e..48c9fb0b1 100644
--- a/content/protocols/v3/guides/managing-liquidity/the-full-contract.mdx
+++ b/content/protocols/v3/guides/managing-liquidity/the-full-contract.mdx
@@ -1,5 +1,4 @@
---
-id: the-full-contract
title: The Full Contract
description: Review a complete Uniswap v3 liquidity management contract covering mint, adjust, and collect flows.
---
diff --git a/content/protocols/v3/guides/swapping/getting-started.mdx b/content/protocols/v3/guides/swapping/getting-started.mdx
index 68a559ca5..ac40dc146 100644
--- a/content/protocols/v3/guides/swapping/getting-started.mdx
+++ b/content/protocols/v3/guides/swapping/getting-started.mdx
@@ -1,5 +1,6 @@
---
-title: Get Started
+title: Get Started with Uniswap v3 Swapping
+sidebarTitle: Get Started
description: Start Uniswap v3 swap integrations with single-hop and multi-hop guide paths and implementation references.
---
diff --git a/content/protocols/v3/guides/troubleshooting.mdx b/content/protocols/v3/guides/troubleshooting.mdx
index 3039e5e80..ef74fffe7 100644
--- a/content/protocols/v3/guides/troubleshooting.mdx
+++ b/content/protocols/v3/guides/troubleshooting.mdx
@@ -55,3 +55,5 @@ Use this reference to map common Uniswap v3 error codes to likely failure causes
- `L`: Liquidity in the pool must be greater than zero for a flash to execute
- `F0`: Token0 balance before flash must be less than, or equal to, token0 balance after flash plus fee
- `F1`: Token1 balance before flash must be less than, or equal to, token1 balance after flash plus fee
+
+For developer support, reach out to our team through the
Help Center.
diff --git a/content/protocols/v3/overview.mdx b/content/protocols/v3/overview.mdx
index a9f752c5e..1c70b7d01 100644
--- a/content/protocols/v3/overview.mdx
+++ b/content/protocols/v3/overview.mdx
@@ -1,5 +1,6 @@
---
-title: Overview
+title: Uniswap v3 Protocol Overview
+sidebarTitle: Overview
description: Get started with Uniswap v3 concepts, guides, and security references for protocol integrations.
---
diff --git a/content/protocols/v4/concepts/architecture.mdx b/content/protocols/v4/concepts/architecture.mdx
index e30ab0266..3d48e6f2f 100644
--- a/content/protocols/v4/concepts/architecture.mdx
+++ b/content/protocols/v4/concepts/architecture.mdx
@@ -1,5 +1,6 @@
---
-title: Architecture
+title: Uniswap v4 Architecture
+sidebarTitle: Architecture
description: Understand the core design pillars of Uniswap v4, including hooks, singleton architecture, and flash accounting.
---
@@ -43,3 +44,31 @@ Example use cases:
- Custom curves, opting out of the concentrated liquidity curve in favor of an independent pricing mechanism
- Hook swap fees, charging and collecting fees on swaps
- Liquidity withdrawal fees, penalizing and/or redistributing fee revenue
+
+## Core libraries
+
+The `PoolManager` delegates most of its arithmetic and state handling to a set of libraries in `v4-core`. These are the contracts a v4 integration reads when reasoning about ticks, prices, deltas and hook permissions.
+
+| Library | What it does |
+| --- | --- |
+| [TickMath](https://github.com/Uniswap/v4-core/blob/main/src/libraries/TickMath.sol) | Computes sqrt prices from ticks and vice versa |
+| [SqrtPriceMath](https://github.com/Uniswap/v4-core/blob/main/src/libraries/SqrtPriceMath.sol) | Price and amount functions based on Q64.96 sqrt price and liquidity |
+| [SwapMath](https://github.com/Uniswap/v4-core/blob/main/src/libraries/SwapMath.sol) | Computes the result of a swap within a single tick |
+| [Pool](https://github.com/Uniswap/v4-core/blob/main/src/libraries/Pool.sol) | Every action that can be performed on a pool |
+| [Position](https://github.com/Uniswap/v4-core/blob/main/src/libraries/Position.sol) | Per-position state, keyed by owner and tick range |
+| [CurrencyDelta](https://github.com/Uniswap/v4-core/blob/main/src/libraries/CurrencyDelta.sol) | Stores callers' currency deltas in transient storage, the basis of flash accounting |
+| [TransientStateLibrary](https://github.com/Uniswap/v4-core/blob/main/src/libraries/TransientStateLibrary.sol) | Reads the transient state the manager keeps during a lock |
+| [ProtocolFeeLibrary](https://github.com/Uniswap/v4-core/blob/main/src/libraries/ProtocolFeeLibrary.sol) | Packs and reads the protocol fee for each swap direction |
+| [FullMath](https://github.com/Uniswap/v4-core/blob/main/src/libraries/FullMath.sol) | 512-bit multiply and divide without loss of precision |
+| [LiquidityMath](https://github.com/Uniswap/v4-core/blob/main/src/libraries/LiquidityMath.sol) | Adds a signed liquidity delta to liquidity |
+| [TickBitmap](https://github.com/Uniswap/v4-core/blob/main/src/libraries/TickBitmap.sol) | Packed record of which ticks are initialized |
+
+Three libraries have their own pages rather than a row here, because they carry concepts rather than arithmetic: [Hooks](/docs/protocols/v4/concepts/hooks), [LPFeeLibrary](/docs/protocols/v4/concepts/dynamic-fees) and [StateLibrary](/docs/protocols/v4/guides/state-view).
+
+Alongside these sit the numeric and encoding helpers: `BitMath`, `FixedPoint96`, `FixedPoint128`, `SafeCast`, `UnsafeMath`, `CustomRevert`, `ParseBytes`, `Lock`, `NonzeroDeltaCount` and `CurrencyReserves`.
+
+Every library carries natspec on each function, so the source is the reference.
+
+
+Source code: [src/libraries/](https://github.com/Uniswap/v4-core/tree/main/src/libraries)
+
diff --git a/content/protocols/v4/concepts/erc-6909.mdx b/content/protocols/v4/concepts/erc-6909.mdx
index 0fbe23014..7f97601d9 100644
--- a/content/protocols/v4/concepts/erc-6909.mdx
+++ b/content/protocols/v4/concepts/erc-6909.mdx
@@ -1,5 +1,6 @@
---
-title: ERC-6909
+title: ERC-6909 in Uniswap v4
+sidebarTitle: ERC-6909
description: Learn how ERC-6909 supports efficient token accounting flows in Uniswap v4.
---
diff --git a/content/protocols/v4/concepts/flash-accounting.mdx b/content/protocols/v4/concepts/flash-accounting.mdx
index 73b8d8e32..892cdd48d 100644
--- a/content/protocols/v4/concepts/flash-accounting.mdx
+++ b/content/protocols/v4/concepts/flash-accounting.mdx
@@ -1,5 +1,6 @@
---
-title: Flash Accounting
+title: Uniswap v4 Flash Accounting
+sidebarTitle: Flash Accounting
description: Understand flash accounting in Uniswap v4 and how deltas reduce transfer overhead.
---
diff --git a/content/protocols/v4/concepts/hook-routing.mdx b/content/protocols/v4/concepts/hook-routing.mdx
index 4aa8e9cef..86099c4c4 100644
--- a/content/protocols/v4/concepts/hook-routing.mdx
+++ b/content/protocols/v4/concepts/hook-routing.mdx
@@ -17,7 +17,9 @@ For implementation details, check [UniswapX Documentation](/docs/liquidity/unisw
## Hook Allowlisting
-If you have built a hook that you would like to have allowlisted, fill out the [hook allowlisting form](https://www.notion.so/uniswaplabs/1aec52b2548b80f78dbef8d2f0d7183e).
+If you have built a hook that you would like to have allowlisted, fill out the [hook allowlisting form](/hook-allowlist).
-You can review current allowlisted hooks in [Allowlisted Hooks](https://support.uniswap.org/hc/en-us/articles/41305283155597-Allowlisted-Hooks).
+You can look up the current allowlisting criteria in [Routing for hooked pools](https://support.uniswap.org/hc/en-us/articles/48291859140621-Routing-for-hooked-pools).
+
+You can review current allowlisted hooks in [Allowlisted Hooks](https://github.com/Uniswap/uniroute-public/blob/main/src/lib/poolCaching/util/hooksAddressesAllowlist.ts).
diff --git a/content/protocols/v4/concepts/hooks.mdx b/content/protocols/v4/concepts/hooks.mdx
index cdeedd5a2..9137a03d7 100644
--- a/content/protocols/v4/concepts/hooks.mdx
+++ b/content/protocols/v4/concepts/hooks.mdx
@@ -1,6 +1,33 @@
---
-title: Hooks
+title: Uniswap v4 Hooks
+sidebarTitle: Hooks
description: Learn how Uniswap v4 hooks extend pool behavior at key lifecycle execution points.
+keywords:
+ - Uniswap v4 hooks
+ - hook permissions
+ - hook address flags
+ - HookMiner
+ - CREATE2 salt mining
+ - pool initialization
+faqs:
+ - question: When do I need a hook in Uniswap v4?
+ answer: |-
+ Hooks are optional. A v4 pool works without one, using the same concentrated liquidity behavior as Uniswap v3. You need a hook only when you want to customize pool behavior at specific lifecycle points, such as running logic before or after a swap, gating who can add liquidity, applying dynamic fees, or building custom accounting. If your use case is a standard pool, you do not need to write or attach a hook.
+ - question: How do I deploy a hook to a valid hook address?
+ answer: |-
+ A hook contract must be deployed to an address whose low bits encode exactly the permissions it implements. Each hook function maps to a flag stored in a specific bit of the 20-byte address, so you cannot deploy a hook to an arbitrary address. To get a valid address you mine a CREATE2 salt that produces an address with the correct flag bits set, then deploy with that salt. The HookMiner helper library finds the salt, and the deployment script asserts that the deployed address matches the mined address. For local testing, Foundry's deployCodeTo cheatcode can place a hook at any address without mining.
+ - question: What hook permissions are available in Uniswap v4?
+ answer: |-
+ A hook declares its permissions through getHookPermissions, which returns a struct of boolean flags. The call permissions are beforeInitialize, afterInitialize, beforeAddLiquidity, afterAddLiquidity, beforeRemoveLiquidity, afterRemoveLiquidity, beforeSwap, afterSwap, beforeDonate, and afterDonate. There are also four return-delta permissions that let a hook adjust balances: beforeSwapReturnDelta, afterSwapReturnDelta, afterAddLiquidityReturnDelta, and afterRemoveLiquidityReturnDelta. A hook implements only the functions it needs, and those choices must match the flags encoded in its address.
+ - question: Can I add a hook to an existing pool?
+ answer: |-
+ No. The hook is part of the PoolKey and is set once when the pool is created through PoolManager.initialize. It cannot be added, removed, or swapped afterward. To use a different hook, or to add one to a pool that has none, you create a new pool with the desired hook in its key. A single hook contract can serve many pools, so you do not need to redeploy the hook itself.
+ - question: How do I test a Uniswap v4 hook?
+ answer: |-
+ Most hook development uses Foundry. The v4-template repository ships a preconfigured Foundry project with v4-core and v4-periphery already imported, so you can clone it, run forge test, and start from working examples. For unit tests you can deploy the hook to a valid address using the deployCodeTo cheatcode, which avoids mining during tests. You can also run a local Anvil node, deploy v4 and your hook with a Foundry script, and point the test suite at it with the rpc-url flag.
+ - question: What happens if the address flags do not match the implemented functions?
+ answer: |-
+ The address flags and the implemented functions must agree. If the address lacks a flag, the PoolManager never calls that hook function, so the logic silently does nothing. Permissions are also validated against the address at deployment, so declaring permissions that do not match the mined address makes the deployment fail. Mining the correct address and declaring matching permissions through getHookPermissions keeps the two in sync.
---
Uniswap v4 introduces Hooks, a system that allows developers to customize and extend the behavior of liquidity pools.
@@ -58,3 +85,119 @@ The introduction of hooks in Uniswap v4 opens up a world of possibilities for de
- Lending hooks integrated with Uniswap v4 pools.
As a hook developer you can easily bootstrap the codebase of an entirely new DeFi protocol through hook designs, which subsequently drives down your audit costs and allows you to develop faster. However, it's important to note that just because you made a hook, that does not mean you will get liquidity routed to your hook from the Uniswap frontend.
+
+## FAQ
+
+
+ When do I need a hook in Uniswap v4?
+
+
+
+ Hooks are optional. A v4 pool works without one, using the same concentrated liquidity behavior as Uniswap v3. You need a hook only when you want to customize pool behavior at specific lifecycle points, such as:
+
+ * Running logic before or after a swap
+ * Gating who can add or remove liquidity
+ * Applying dynamic fees
+ * Building custom accounting or a custom curve
+
+ If your use case is a standard pool, you do not need to write or attach a hook.
+
+
+
+
+
+
+ How do I deploy a hook to a valid hook address?
+
+
+
+ A hook contract must be deployed to an address whose low bits encode exactly the permissions it implements. Each hook function maps to a flag stored in a specific bit of the 20-byte address, so you cannot deploy a hook to an arbitrary address.
+
+ To get a valid address you mine a `CREATE2` salt that produces an address with the correct flag bits set, then deploy with that salt. The [`HookMiner`](https://github.com/Uniswap/v4-periphery/blob/main/src/utils/HookMiner.sol) helper library finds the salt:
+
+ ```solidity
+ uint160 flags = uint160(Hooks.AFTER_ADD_LIQUIDITY_FLAG | Hooks.AFTER_SWAP_FLAG);
+ bytes memory constructorArgs = abi.encode(POOLMANAGER);
+ (address hookAddress, bytes32 salt) =
+ HookMiner.find(CREATE2_DEPLOYER, flags, type(PointsHook).creationCode, constructorArgs);
+ ```
+
+ The deployment script then asserts that the deployed address matches the mined address. For local testing, Foundry's `deployCodeTo` cheatcode can place a hook at any address without mining. See [Hook Deployment](/docs/protocols/v4/guides/hooks/hook-deployment) for the full walkthrough.
+
+
+
+
+
+
+ What hook permissions are available in Uniswap v4?
+
+
+
+ A hook declares its permissions through `getHookPermissions`, which returns a struct of boolean flags. The call permissions are:
+
+ * `beforeInitialize` / `afterInitialize`
+ * `beforeAddLiquidity` / `afterAddLiquidity`
+ * `beforeRemoveLiquidity` / `afterRemoveLiquidity`
+ * `beforeSwap` / `afterSwap`
+ * `beforeDonate` / `afterDonate`
+
+ There are also four return-delta permissions that let a hook adjust balances: `beforeSwapReturnDelta`, `afterSwapReturnDelta`, `afterAddLiquidityReturnDelta`, and `afterRemoveLiquidityReturnDelta`. A hook implements only the functions it needs, and those choices must match the flags encoded in its address. See the full flag list in [`Hooks.sol`](https://github.com/Uniswap/v4-core/blob/main/src/libraries/Hooks.sol).
+
+
+
+
+
+
+ Can I add a hook to an existing pool?
+
+
+
+ No. The hook is part of the `PoolKey` and is set once when the pool is created through `PoolManager.initialize`. It cannot be added, removed, or swapped afterward.
+
+ To use a different hook, or to add one to a pool that has none, you create a new pool with the desired hook in its key. A single hook contract can serve many pools, so you do not need to redeploy the hook itself.
+
+
+
+
+
+
+ How do I test a Uniswap v4 hook?
+
+
+
+ Most hook development uses [Foundry](https://book.getfoundry.sh/). The [v4-template](https://github.com/uniswapfoundation/v4-template) repository ships a preconfigured project with `v4-core` and `v4-periphery` already imported:
+
+ ```bash
+ git clone https://github.com/uniswapfoundation/v4-template.git
+ cd v4-template
+ forge install
+ forge test
+ ```
+
+ For unit tests you can deploy the hook to a valid address using the `deployCodeTo` cheatcode, which avoids mining during tests. You can also run a local [Anvil](https://book.getfoundry.sh/anvil/) node, deploy v4 and your hook with a Foundry script, and point the test suite at it:
+
+ ```bash
+ forge test --rpc-url 127.0.0.1:8545
+ ```
+
+ See [Hooks Overview](/docs/protocols/v4/guides/hooks/getting-started) for the full local setup.
+
+
+
+
+
+
+ What happens if the address flags do not match the implemented functions?
+
+
+
+ The address flags and the implemented functions must agree:
+
+ * If the address lacks a flag, the `PoolManager` never calls that hook function, so the logic silently does nothing.
+ * Permissions are validated against the address at deployment, so declaring permissions that do not match the mined address makes the deployment fail.
+
+ Mining the correct address and declaring matching permissions through `getHookPermissions` keeps the two in sync.
+
+
+
+
diff --git a/content/protocols/v4/deployments.mdx b/content/protocols/v4/deployments.mdx
index f582c3b29..c6add9ffb 100644
--- a/content/protocols/v4/deployments.mdx
+++ b/content/protocols/v4/deployments.mdx
@@ -1,9 +1,13 @@
---
-id: deployments
-title: Deployments
+title: Uniswap v4 Deployments
+sidebarTitle: Deployments
description: Find current Uniswap v4 core, periphery, and Universal Router deployment addresses by network.
---
+
+ All Uniswap v4 deployment addresses are also available on the unified [Deployments](/deployments) page and its [deployments.json](/deployments.json) feed.
+
+
The Uniswap Protocol is made up of multiple contracts on many networks.
The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap/universal-router` are deployed at the addresses listed below. Integrators should **no longer assume that they are deployed to the same addresses across chains** and be extremely careful to confirm mappings below.
@@ -21,6 +25,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://etherscan.io/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x66a9893cc07d91d95644aedd05d03f95e1dba8af`](https://etherscan.io/address/0x66a9893cc07d91d95644aedd05d03f95e1dba8af) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x4c82d1fbfe28c977cbb58d8c7ff8fcf9f70a2cca`](https://etherscan.io/address/0x4c82d1fbfe28c977cbb58d8c7ff8fcf9f70a2cca) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x23617e59A5925b2A4Bf75d73ff6711cD0b29De85`](https://etherscan.io/address/0x23617e59A5925b2A4Bf75d73ff6711cD0b29De85) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://etherscan.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### Unichain: 130
@@ -34,6 +39,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://uniscan.xyz/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xef740bf23acae26f6492b10de645d6b98dc8eaf3`](https://uniscan.xyz/address/0xef740bf23acae26f6492b10de645d6b98dc8eaf3) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xfdf682f51fe81aa4898f0ae2163d8a55c127fbc7`](https://uniscan.xyz/address/0xfdf682f51fe81aa4898f0ae2163d8a55c127fbc7) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xD1b797D92d87B688193A2B976eFc8D577D204343`](https://uniscan.xyz/address/0xD1b797D92d87B688193A2B976eFc8D577D204343) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://uniscan.xyz/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### Optimism: 10
@@ -47,6 +53,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://optimistic.etherscan.io/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x851116d9223fabed8e56c0e6b8ad0c31d98b3507`](https://optimistic.etherscan.io/address/0x851116d9223fabed8e56c0e6b8ad0c31d98b3507) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x8b844f885672f333bc0042cb669255f93a4c1e6b`](https://optimistic.etherscan.io/address/0x8b844f885672f333bc0042cb669255f93a4c1e6b) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xC09255D86DB563cBc11C2fCf4a0C512e160111B4`](https://optimistic.etherscan.io/address/0xC09255D86DB563cBc11C2fCf4a0C512e160111B4) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://optimistic.etherscan.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### Base: 8453
@@ -60,6 +67,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://basescan.org/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x6ff5693b99212da76ad316178a184ab56d299b43`](https://basescan.org/address/0x6ff5693b99212da76ad316178a184ab56d299b43) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xfdf682f51fe81aa4898f0ae2163d8a55c127fbc7`](https://basescan.org/address/0xfdf682f51fe81aa4898f0ae2163d8a55c127fbc7) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xd6145b2D3F379919E8CdEda7B97e37c4b2Ca9c40`](https://basescan.org/address/0xd6145b2D3F379919E8CdEda7B97e37c4b2Ca9c40) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://basescan.org/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### Arbitrum One: 42161
@@ -73,6 +81,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://arbiscan.io/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xa51afafe0263b40edaef0df8781ea9aa03e381a3`](https://arbiscan.io/address/0xa51afafe0263b40edaef0df8781ea9aa03e381a3) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x8b844f885672f333bc0042cb669255f93a4c1e6b`](https://arbiscan.io/address/0x8b844f885672f333bc0042cb669255f93a4c1e6b) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x2d01411773c8C24805306E89A41F7855C3c4Fe65`](https://arbiscan.io/address/0x2d01411773c8C24805306E89A41F7855C3c4Fe65) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://arbiscan.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### Polygon: 137
@@ -86,6 +95,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://polygonscan.com/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x1095692a6237d83c6a72f3f5efedb9a670c49223`](https://polygonscan.com/address/0x1095692a6237d83c6a72f3f5efedb9a670c49223) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x8b844f885672f333bc0042cb669255f93a4c1e6b`](https://polygonscan.com/address/0x8b844f885672f333bc0042cb669255f93a4c1e6b) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xDc264714F68d84CF29BC605589405E78bDBE7C9f`](https://polygonscan.com/address/0xDc264714F68d84CF29BC605589405E78bDBE7C9f) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://polygonscan.com/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### Zora: 7777777
@@ -99,6 +109,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://explorer.zora.energy/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x3315ef7ca28db74abadc6c44570efdf06b04b020`](https://explorer.zora.energy/address/0x3315ef7ca28db74abadc6c44570efdf06b04b020) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xfdf682f51fe81aa4898f0ae2163d8a55c127fbc7`](https://explorer.zora.energy/address/0xfdf682f51fe81aa4898f0ae2163d8a55c127fbc7) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xF025e0Fe9E331A0eF05c2ad3C4E9C64b625cda6f`](https://explorer.zora.energy/address/0xF025e0Fe9E331A0eF05c2ad3C4E9C64b625cda6f) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://explorer.zora.energy/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### Worldchain: 480
@@ -112,6 +123,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://worldscan.org/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x8ac7bee993bb44dab564ea4bc9ea67bf9eb5e743`](https://worldscan.org/address/0x8ac7bee993bb44dab564ea4bc9ea67bf9eb5e743) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x8b844f885672f333bc0042cb669255f93a4c1e6b`](https://worldscan.org/address/0x8b844f885672f333bc0042cb669255f93a4c1e6b) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xF025e0Fe9E331A0eF05c2ad3C4E9C64b625cda6f`](https://worldscan.org/address/0xF025e0Fe9E331A0eF05c2ad3C4E9C64b625cda6f) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://worldscan.org/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### X Layer: 196
@@ -125,6 +137,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://www.oklink.com/x-layer/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xda00ae15d3a71466517129255255db7c0c0956d3`](https://www.oklink.com/x-layer/address/0xda00ae15d3a71466517129255255db7c0c0956d3) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x8b844f885672f333bc0042cb669255f93a4c1e6b`](https://www.oklink.com/x-layer/address/0x8b844f885672f333bc0042cb669255f93a4c1e6b) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x1cd182C94fcF42277B80DBB9060F88024809E61E`](https://www.oklink.com/x-layer/address/0x1cd182C94fcF42277B80DBB9060F88024809E61E) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://www.oklink.com/x-layer/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### Ink: 57073
@@ -137,6 +150,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [StateView](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/StateView.sol) | [`0x76fd297e2d437cd7f76d50f01afe6160f86e9990`](https://explorer.inkonchain.com/address/0x76fd297e2d437cd7f76d50f01afe6160f86e9990) |
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://explorer.inkonchain.com/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x112908dac86e20e7241b0927479ea3bf935d1fa0`](https://explorer.inkonchain.com/address/0x112908dac86e20e7241b0927479ea3bf935d1fa0) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x661E93cca42AfacB172121EF892830cA3b70F08d`](https://explorer.inkonchain.com/address/0x661E93cca42AfacB172121EF892830cA3b70F08d) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://explorer.inkonchain.com/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### Soneium: 1868
@@ -150,6 +164,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://soneium.blockscout.com/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x4cded7edf52c8aa5259a54ec6a3ce7c6d2a455df`](https://soneium.blockscout.com/address/0x4cded7edf52c8aa5259a54ec6a3ce7c6d2a455df) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x8b844f885672f333bc0042cb669255f93a4c1e6b`](https://soneium.blockscout.com/address/0x8b844f885672f333bc0042cb669255f93a4c1e6b) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x661E93cca42AfacB172121EF892830cA3b70F08d`](https://soneium.blockscout.com/address/0x661E93cca42AfacB172121EF892830cA3b70F08d) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://soneium.blockscout.com/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### Avalanche: 43114
@@ -163,6 +178,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://snowscan.xyz/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x94b75331ae8d42c1b61065089b7d48fe14aa73b7`](https://snowscan.xyz/address/0x94b75331ae8d42c1b61065089b7d48fe14aa73b7) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x8b844f885672f333bc0042cb669255f93a4c1e6b`](https://snowscan.xyz/address/0x8b844f885672f333bc0042cb669255f93a4c1e6b) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x661E93cca42AfacB172121EF892830cA3b70F08d`](https://snowscan.xyz/address/0x661E93cca42AfacB172121EF892830cA3b70F08d) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://snowscan.xyz/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### BNB Smart Chain: 56
@@ -176,6 +192,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://bscscan.com/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x1906c1d672b88cd1b9ac7593301ca990f94eae07`](https://bscscan.com/address/0x1906c1d672b88cd1b9ac7593301ca990f94eae07) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x8b844f885672f333bc0042cb669255f93a4c1e6b`](https://bscscan.com/address/0x8b844f885672f333bc0042cb669255f93a4c1e6b) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xDc264714F68d84CF29BC605589405E78bDBE7C9f`](https://bscscan.com/address/0xDc264714F68d84CF29BC605589405E78bDBE7C9f) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://bscscan.com/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### Celo: 42220
@@ -189,6 +206,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://celoscan.io/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xcb695bc5d3aa22cad1e6df07801b061a05a0233a`](https://celoscan.io/address/0xcb695bc5d3aa22cad1e6df07801b061a05a0233a) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x8b844f885672f333bc0042cb669255f93a4c1e6b`](https://celoscan.io/address/0x8b844f885672f333bc0042cb669255f93a4c1e6b) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xe2023F3FA515cF070e07fD9d51c1d236e07843f4`](https://celoscan.io/address/0xe2023F3FA515cF070e07fD9d51c1d236e07843f4) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://celoscan.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### Monad: 143
@@ -202,6 +220,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://monadvision.com/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x0d97dc33264bfc1c226207428a79b26757fb9dc3`](https://monadvision.com/address/0x0d97dc33264bfc1c226207428a79b26757fb9dc3) |
| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xfdf682f51fe81aa4898f0ae2163d8a55c127fbc7`](https://monadvision.com/address/0xfdf682f51fe81aa4898f0ae2163d8a55c127fbc7) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xa6CE4F10d83dBdDAc17E68e1837ca9cE6a1b596e`](https://monadvision.com/address/0xa6CE4F10d83dBdDAc17E68e1837ca9cE6a1b596e) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://monadvision.com/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### MegaETH: 4326
@@ -214,6 +233,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [StateView](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/StateView.sol) | [`0x726f84e1dfb8d375a365e0808282f40d52d3e4e8`](https://megaeth.blockscout.com/address/0x726f84e1dfb8d375a365e0808282f40d52d3e4e8) |
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://megaeth.blockscout.com/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x47837eb80db5908eabba9105626d9b348bea7b02`](https://megaeth.blockscout.com/address/0x47837eb80db5908eabba9105626d9b348bea7b02) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xAedd1CF4C14e833140A61E9C0d2b73a64795c823`](https://megaeth.blockscout.com/address/0xAedd1CF4C14e833140A61E9C0d2b73a64795c823) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://megaeth.blockscout.com/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
### Tempo: 4217
@@ -226,6 +246,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [StateView](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/StateView.sol) | [`0x21b954fba3f5ddebe77ef2d47a3100c066908b2a`](https://explore.tempo.xyz/address/0x21b954fba3f5ddebe77ef2d47a3100c066908b2a?tab=contract) |
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://explore.tempo.xyz/address/0x0000001b173C3bbF3984D417d8614E3eed34865B?tab=contract) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xa2dc7d0266f0cc50b3eeaf36c9bfcecff1beea91`](https://explore.tempo.xyz/address/0xa2dc7d0266f0cc50b3eeaf36c9bfcecff1beea91?tab=contract) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x182a927119D56008d921126764bF884221b10f59`](https://explore.tempo.xyz/address/0x182a927119D56008d921126764bF884221b10f59) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://explore.tempo.xyz/address/0x000000000022D473030F116dDEE9F6B43aC78BA3?tab=contract) |
### Robinhood Chain: 4663
@@ -238,8 +259,35 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
| [StateView](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/StateView.sol) | [`0xf3334192d15450cdd385c8b70e03f9a6bd9e673b`](https://robinhoodchain.blockscout.com/address/0xf3334192d15450cdd385c8b70e03f9a6bd9e673b?tab=contract) |
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://robinhoodchain.blockscout.com/address/0x0000001b173C3bbF3984D417d8614E3eed34865B?tab=contract) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x8876789976decbfcbbbe364623c63652db8c0904`](https://robinhoodchain.blockscout.com/address/0x8876789976decbfcbbbe364623c63652db8c0904?tab=contract) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x204FAca1764B154221e35c0d20aBb3c525710498`](https://robinhoodchain.blockscout.com/address/0x204FAca1764B154221e35c0d20aBb3c525710498) |
| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://robinhoodchain.blockscout.com/address/0x000000000022d473030f116ddee9f6b43ac78ba3?tab=contract) |
+### Arc: 5042
+| Contract | Address |
+|----------|---------|
+| [PoolManager](https://github.com/Uniswap/v4-core/blob/main/src/PoolManager.sol) | [`0x8366a39CC670B4001A1121B8F6A443A643e40951`](https://explorer.arc.io/address/0x8366a39CC670B4001A1121B8F6A443A643e40951) |
+| [PositionDescriptor](https://github.com/Uniswap/v4-periphery/blob/main/src/PositionDescriptor.sol) | [`0x516b8a945700D6bBfDeDaa6dcFc4586bA60B8707`](https://explorer.arc.io/address/0x516b8a945700D6bBfDeDaa6dcFc4586bA60B8707) |
+| [PositionManager](https://github.com/Uniswap/v4-periphery/blob/main/src/PositionManager.sol) | [`0x6049c9a0e26405C0985f9E3685C87d0aE917f82B`](https://explorer.arc.io/address/0x6049c9a0e26405C0985f9E3685C87d0aE917f82B) |
+| [Quoter](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/V4Quoter.sol) | [`0x8Dc178eFB8111BB0973Dd9d722ebeFF267c98F94`](https://explorer.arc.io/address/0x8Dc178eFB8111BB0973Dd9d722ebeFF267c98F94) |
+| [StateView](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/StateView.sol) | [`0xF3334192D15450CdD385c8B70e03f9A6bD9E673b`](https://explorer.arc.io/address/0xF3334192D15450CdD385c8B70e03f9A6bD9E673b) |
+| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://explorer.arc.io/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
+| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x4fcA4a51Ab4F23A7447b3284fBd7D73289A89Fb1`](https://explorer.arc.io/address/0x4fcA4a51Ab4F23A7447b3284fBd7D73289A89Fb1) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x8702463e73f74d0b6765aBceb314Ef07aCb92650`](https://explorer.arc.io/address/0x8702463e73f74d0b6765aBceb314Ef07aCb92650) |
+| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://explorer.arc.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
+
+### HyperEVM: 999
+| Contract | Address |
+|----------|---------|
+| [PoolManager](https://github.com/Uniswap/v4-core/blob/main/src/PoolManager.sol) | [`0x12D4Fd9C5DeDd00ab8a0bCe2CF0167bbf94b6B1F`](https://hyperevmscan.io/address/0x12D4Fd9C5DeDd00ab8a0bCe2CF0167bbf94b6B1F) |
+| [PositionDescriptor](https://github.com/Uniswap/v4-periphery/blob/main/src/PositionDescriptor.sol) | [`0xfF0b85caDaC458D5aAcc22755e5107bfE31ED402`](https://hyperevmscan.io/address/0xfF0b85caDaC458D5aAcc22755e5107bfE31ED402) |
+| [PositionManager](https://github.com/Uniswap/v4-periphery/blob/main/src/PositionManager.sol) | [`0x0d7Ab5B3db668128Aff6F70C4eBC71D7d4DA9bf9`](https://hyperevmscan.io/address/0x0d7Ab5B3db668128Aff6F70C4eBC71D7d4DA9bf9) |
+| [Quoter](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/V4Quoter.sol) | [`0x108Bfe38532C98f8Cd8D7Ab49c9dDAa3675a1c5e`](https://hyperevmscan.io/address/0x108Bfe38532C98f8Cd8D7Ab49c9dDAa3675a1c5e) |
+| [StateView](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/StateView.sol) | [`0x1656326235cb9E34Cb58CaDe53AE30789AB32A1A`](https://hyperevmscan.io/address/0x1656326235cb9E34Cb58CaDe53AE30789AB32A1A) |
+| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://hyperevmscan.io/address/0x0000001b173C3bbF3984D417d8614E3eed34865B) |
+| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x9aFe3C497e19501DB228F28CdBdD29bC98F65DBa`](https://hyperevmscan.io/address/0x9aFe3C497e19501DB228F28CdBdD29bC98F65DBa) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xeD270A1Bcdc63cf1356D695e7f40961d4819d6bF`](https://hyperevmscan.io/address/0xeD270A1Bcdc63cf1356D695e7f40961d4819d6bF) |
+| [Permit2](https://github.com/Uniswap/permit2) | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://hyperevmscan.io/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) |
+
## Testnet Deployments
### Unichain Sepolia: 1301
@@ -248,6 +296,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
|--------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|
| [PoolManager](https://github.com/Uniswap/v4-core/blob/main/src/PoolManager.sol) | [`0x00b036b58a818b1bc34d502d3fe730db729e62ac`](https://sepolia.uniscan.xyz/address/0x00b036b58a818b1bc34d502d3fe730db729e62ac#code) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xf70536b3bcc1bd1a972dc186a2cf84cc6da6be5d`](https://sepolia.uniscan.xyz/address/0xf70536b3bcc1bd1a972dc186a2cf84cc6da6be5d#code) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0xDf38F24fE153761634Be942F9d859f3DBA857E95`](https://sepolia.uniscan.xyz/address/0xDf38F24fE153761634Be942F9d859f3DBA857E95) |
| [PositionManager](https://github.com/Uniswap/v4-periphery/blob/main/src/PositionManager.sol) | [`0xf969aee60879c54baaed9f3ed26147db216fd664`](https://sepolia.uniscan.xyz/address/0xf969aee60879c54baaed9f3ed26147db216fd664#code) |
| [StateView](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/StateView.sol) | [`0xc199f1072a74d4e905aba1a84d9a45e2546b6222`](https://sepolia.uniscan.xyz/address/0xc199f1072a74d4e905aba1a84d9a45e2546b6222#code) |
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://sepolia.uniscan.xyz/address/0x0000001b173C3bbF3984D417d8614E3eed34865B#code) |
@@ -262,6 +311,8 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
|--------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|
| [PoolManager](https://github.com/Uniswap/v4-core/blob/main/src/PoolManager.sol) | [`0xE03A1074c86CFeDd5C142C4F04F1a1536e203543`](https://sepolia.etherscan.io/address/0xE03A1074c86CFeDd5C142C4F04F1a1536e203543#code) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x3A9D48AB9751398BbFa63ad67599Bb04e4BdF98b`](https://sepolia.etherscan.io/address/0x3A9D48AB9751398BbFa63ad67599Bb04e4BdF98b#code) |
+| [Universal Router 2.1.1](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x7dfd4f31be6814d2906bde155c3e1b146eac1468`](https://sepolia.etherscan.io/address/0x7dfd4f31be6814d2906bde155c3e1b146eac1468#code) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x7E4f6c5e954Da5c61B3423D81E2277431Ac043f3`](https://sepolia.etherscan.io/address/0x7E4f6c5e954Da5c61B3423D81E2277431Ac043f3) |
| [PositionManager](https://github.com/Uniswap/v4-periphery/blob/main/src/PositionManager.sol) | [`0x429ba70129df741B2Ca2a85BC3A2a3328e5c09b4`](https://sepolia.etherscan.io/address/0x429ba70129df741B2Ca2a85BC3A2a3328e5c09b4#code) |
| [StateView](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/StateView.sol) | [`0xe1dd9c3fa50edb962e442f60dfbc432e24537e4c`](https://sepolia.etherscan.io/address/0xe1dd9c3fa50edb962e442f60dfbc432e24537e4c#code) |
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://sepolia.etherscan.io/address/0x0000001b173C3bbF3984D417d8614E3eed34865B#code) |
@@ -276,6 +327,7 @@ The latest version of `@uniswap/v4-core`, `@uniswap/v4-periphery`, and `@uniswap
|--------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|
| [PoolManager](https://github.com/Uniswap/v4-core/blob/main/src/PoolManager.sol) | [`0x05E73354cFDd6745C338b50BcFDfA3Aa6fA03408`](https://sepolia.basescan.org/address/0x05E73354cFDd6745C338b50BcFDfA3Aa6fA03408#code) |
| [Universal Router](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x492e6456d9528771018deb9e87ef7750ef184104`](https://sepolia.basescan.org/address/0x492e6456d9528771018deb9e87ef7750ef184104#code) |
+| [Universal Router 2.1.2](https://github.com/Uniswap/universal-router/blob/dev/contracts/UniversalRouter.sol) | [`0x8702463e73f74d0b6765aBceb314Ef07aCb92650`](https://sepolia.basescan.org/address/0x8702463e73f74d0b6765aBceb314Ef07aCb92650) |
| [PositionManager](https://github.com/Uniswap/v4-periphery/blob/main/src/PositionManager.sol) | [`0x4b2c77d209d3405f41a037ec6c77f7f5b8e2ca80`](https://sepolia.basescan.org/address/0x4b2c77d209d3405f41a037ec6c77f7f5b8e2ca80#code) |
| [StateView](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/StateView.sol) | [`0x571291b572ed32ce6751a2cb2486ebee8defb9b4`](https://sepolia.basescan.org/address/0x571291b572ed32ce6751a2cb2486ebee8defb9b4#code) |
| [ReservesLens](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/ReservesLens.sol) | [`0x0000001b173C3bbF3984D417d8614E3eed34865B`](https://sepolia.basescan.org/address/0x0000001b173C3bbF3984D417d8614E3eed34865B#code) |
diff --git a/content/protocols/v4/guides/create-pool.mdx b/content/protocols/v4/guides/create-pool.mdx
index 8efc090d4..e37546106 100644
--- a/content/protocols/v4/guides/create-pool.mdx
+++ b/content/protocols/v4/guides/create-pool.mdx
@@ -1,5 +1,6 @@
---
-title: Create Pool
+title: Create a Pool on Uniswap v4
+sidebarTitle: Create Pool
description: Create a Uniswap v4 pool and optionally initialize it with liquidity in one flow.
---
@@ -183,3 +184,5 @@ PositionManager(posm).multicall{value: ethToSend}(params);
> Excess Ether is **NOT** refunded unless developers encoded `SWEEP` in the `actions` parameter
For a full end-to-end script, developers should see [v4-template's scripts](https://github.com/uniswapfoundation/v4-template/tree/main/script)
+
+For developer support, reach out to our team through the
Help Center.
diff --git a/content/protocols/v4/guides/erc-6909.mdx b/content/protocols/v4/guides/erc-6909.mdx
index 92ac9d9bb..c0b3e84ca 100644
--- a/content/protocols/v4/guides/erc-6909.mdx
+++ b/content/protocols/v4/guides/erc-6909.mdx
@@ -1,5 +1,6 @@
---
-title: ERC-6909
+title: Using ERC-6909 in Uniswap v4
+sidebarTitle: ERC-6909
description: Use ERC-6909 primitives in Uniswap v4 to resolve deltas and manage balances efficiently.
---
diff --git a/content/protocols/v4/guides/flash-accounting.mdx b/content/protocols/v4/guides/flash-accounting.mdx
index 1352a808e..c6dcae372 100644
--- a/content/protocols/v4/guides/flash-accounting.mdx
+++ b/content/protocols/v4/guides/flash-accounting.mdx
@@ -1,5 +1,6 @@
---
-title: Flash Accounting
+title: Building with Uniswap v4 Flash Accounting
+sidebarTitle: Flash Accounting
description: Build with Uniswap v4 flash accounting by understanding deltas, settlement, and PoolManager flows.
---
diff --git a/content/protocols/v4/guides/getting-started.mdx b/content/protocols/v4/guides/getting-started.mdx
index 56b9b4ad4..859f6182a 100644
--- a/content/protocols/v4/guides/getting-started.mdx
+++ b/content/protocols/v4/guides/getting-started.mdx
@@ -1,5 +1,6 @@
---
-title: Get Started
+title: Get Started with Uniswap v4
+sidebarTitle: Get Started
description: Choose your first Uniswap v4 integration path across pool creation, swapping, liquidity, and hooks.
---
@@ -23,3 +24,5 @@ Use this page to choose a practical starting point in Uniswap v4 guides.
- [ERC-6909](/docs/protocols/v4/guides/erc-6909)
- [Subscriber](/docs/protocols/v4/guides/subscriber)
- [Troubleshooting](/docs/protocols/v4/guides/troubleshooting)
+
+For developer support, reach out to our team through the
Help Center.
diff --git a/content/protocols/v4/guides/state-view.mdx b/content/protocols/v4/guides/state-view.mdx
index 255284422..8ee9d083e 100644
--- a/content/protocols/v4/guides/state-view.mdx
+++ b/content/protocols/v4/guides/state-view.mdx
@@ -5,7 +5,7 @@ description: Read Uniswap v4 pool state offchain using StateView and compare wit
## StateView Overview
-When building on **Uniswap v4**, you will often need to read pool state for both onchain and offchain use cases. Onchain contracts can directly invoke the [**StateLibrary**](https://github.com/Uniswap/v4-core/blob/main/src/libraries/StateLibrary.sol) to execute these reads during transactions, but offchain systems—such as frontends or analytics services—require a deployed contract with view functions. This is where [**StateView**](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/StateView.sol) comes in.
+When building on **Uniswap v4**, you will often need to read pool state for both onchain and offchain use cases. Onchain contracts can directly invoke the [**StateLibrary**](https://github.com/Uniswap/v4-core/blob/main/src/libraries/StateLibrary.sol) to execute these reads during transactions, but offchain systems such as frontends or analytics services require a deployed contract with view functions. This is where [**StateView**](https://github.com/Uniswap/v4-periphery/blob/main/src/lens/StateView.sol) comes in.
> *In short: Use StateLibrary within onchain contracts and use StateView with an RPC for frontends and analytics.*
>
@@ -57,7 +57,7 @@ This separation ensures that each context (onchain vs. offchain) uses the most e
## Usage With Frontend Clients
-Frontend applications frequently display real-time information about pools, positions, and other market data—without incurring transaction costs. **StateView** addresses these requirements by exposing read-only functions tailored for offchain integrations.
+Frontend applications frequently display real-time information about pools, positions, and other market data, without incurring transaction costs. **StateView** addresses these requirements by exposing read-only functions tailored for offchain integrations.
### Setting up with Viem
diff --git a/content/protocols/v4/guides/swapping/getting-started.mdx b/content/protocols/v4/guides/swapping/getting-started.mdx
index d3d640a5e..6a216b43c 100644
--- a/content/protocols/v4/guides/swapping/getting-started.mdx
+++ b/content/protocols/v4/guides/swapping/getting-started.mdx
@@ -1,5 +1,6 @@
---
-title: Get Started
+title: Get Started with Uniswap v4 Swapping
+sidebarTitle: Get Started
description: Start swapping on Uniswap v4 using Universal Router setup, command routing, and verification steps.
---
diff --git a/content/protocols/v4/guides/swapping/routing.mdx b/content/protocols/v4/guides/swapping/routing.mdx
index eff4b5cc3..9f9676501 100644
--- a/content/protocols/v4/guides/swapping/routing.mdx
+++ b/content/protocols/v4/guides/swapping/routing.mdx
@@ -1,5 +1,6 @@
---
-title: Swap Routing
+title: Swap Routing on Uniswap v4
+sidebarTitle: Swap Routing
description: Configure Universal Router command encoding for Uniswap v4 swap routing flows.
---
diff --git a/content/protocols/v4/guides/troubleshooting.mdx b/content/protocols/v4/guides/troubleshooting.mdx
index 7233318c4..10ef93476 100644
--- a/content/protocols/v4/guides/troubleshooting.mdx
+++ b/content/protocols/v4/guides/troubleshooting.mdx
@@ -1,5 +1,4 @@
---
-id: troubleshooting
title: Troubleshooting (v4)
description: Review common Uniswap v4 custom error selectors to debug integration and runtime failures.
---
@@ -99,3 +98,5 @@ These are custom error selectors for Uniswap v4 contracts.
|-----------------------------------------------------|--------------|
| `TickMath.InvalidTick.selector` | `0xce8ef7fc` |
| `TickMath.InvalidSqrtPrice.selector` | `0x31efafe8` |
+
+For developer support, reach out to our team through the
Help Center.
diff --git a/content/protocols/v4/overview.mdx b/content/protocols/v4/overview.mdx
index ae170456e..f18fd13ef 100644
--- a/content/protocols/v4/overview.mdx
+++ b/content/protocols/v4/overview.mdx
@@ -1,6 +1,6 @@
---
-id: overview
-title: Overview
+title: Uniswap v4 Protocol Overview
+sidebarTitle: Overview
description: Navigate Uniswap v4 concepts, framework guidance, and references for protocol integrations.
---
diff --git a/content/protocols/v4/security.mdx b/content/protocols/v4/security.mdx
index 55ac2674f..c329a16d4 100644
--- a/content/protocols/v4/security.mdx
+++ b/content/protocols/v4/security.mdx
@@ -1,5 +1,4 @@
---
-id: security-framework
title: Security Framework
description: Evaluate Uniswap v4 hook security risks with a structured framework, scoring model, and operational guidance.
---
@@ -130,7 +129,7 @@ Even in these cases, strict controls are necessary.
When safety is higher priority than convenience:
-- Deploy new hook contracts (v1 —> v2) rather than upgrading old ones.
+- Deploy new hook contracts (v1 -> v2) rather than upgrading old ones.
- Allow pools to migrate voluntarily rather than forcing an upgrade path.
### Autonomous behavior or parameter updates
diff --git a/content/sdks/overview.mdx b/content/sdks/overview.mdx
index f4fd3ec34..d05c07de0 100644
--- a/content/sdks/overview.mdx
+++ b/content/sdks/overview.mdx
@@ -1,6 +1,33 @@
---
description: Explore Uniswap SDK families and choose the right version for your integration workflow.
-title: SDKs Overview
+title: Uniswap SDKs Overview
+sidebarTitle: Overview
+keywords:
+ - Uniswap SDK
+ - SDK versioning
+ - Trading API
+ - Quoter callStatic
+ - CurrencyAmount
+ - BigInt precision
+faqs:
+ - question: Which Uniswap SDK version should I use, v2, v3, or v4?
+ answer: |-
+ Match the SDK to the protocol version of the pools you integrate with. Use the v4 SDK for new integrations that rely on hooks, flash accounting, and singleton pools. Use the v3 SDK for concentrated liquidity workflows on v3 pools. Use the v2 SDK for legacy constant product pools and older routing flows. The versions are not interchangeable because each targets a different set of onchain contracts. All three build on the Core SDK for shared token, amount, and price primitives.
+ - question: When should I use a Uniswap SDK versus the Trading API?
+ answer: |-
+ Use an SDK when you want client-side computation and want to construct calldata yourself. The SDK gives you utility classes to build pool keys, compute quotes, and encode swap parameters, but it does not execute trades or send transactions. You manage RPC connections, token definitions, and pool configuration. Use the Trading API when you prefer a hosted service that handles routing, quoting, and transaction building for you. The API returns encoded transaction data that your application signs and submits, so you do not manage pool state or routing logic yourself.
+ - question: Why does my Quoter call fail when I call it like a normal read function?
+ answer: |-
+ The Uniswap Quoter functions are not view functions. They rely on state-changing calls that are designed to revert in order to return the quote data, so executed as a transaction they cost gas. To read a quote, simulate the call instead with callStatic in ethers v5 or staticCall in ethers v6, which asks the node to simulate the state change and return the result rather than execute it. This applies to both the v3 and v4 Quoter contracts.
+ - question: How do I handle token amounts without losing precision?
+ answer: |-
+ Represent amounts in their smallest onchain unit, not as JavaScript floating point numbers, which lose precision on large integers. The Core SDK provides CurrencyAmount, which you create with CurrencyAmount.fromRawAmount using a Token and a raw integer amount. Convert a human readable amount into raw units by scaling by ten to the power of the token decimals. The SDKs represent these integers with JSBI, so convert strings or native BigInt values into JSBI before passing them to SDK constructors. The key rule is to keep amounts as integers in the token's base units through every calculation.
+ - question: What is the Core SDK and do I need it?
+ answer: |-
+ The Core SDK, published as @uniswap/sdk-core, provides the shared token, amount, and price primitives used across the v2, v3, and v4 SDKs. Types such as Token, CurrencyAmount, and Price live there. You almost always install it alongside a version SDK because the version SDKs expect these primitives as inputs and return them as outputs.
+ - question: Can the SDK execute swaps or send transactions for me?
+ answer: |-
+ No. The SDK computes and encodes the data required to interact with Uniswap safely, but it does not sign or broadcast transactions. Your application is responsible for connecting a signer, submitting the transaction through your RPC provider, and handling approvals. If you want a service that returns ready to sign transaction data instead, use the Trading API.
---
Use this page to choose the right Uniswap SDK version for your integration and then jump into implementation guides.
@@ -19,3 +46,106 @@ The Core SDK `@uniswap/sdk-core` provides shared token, amount, and price primit
- [SDK Core GitHub Repo](https://github.com/Uniswap/sdk-core)
- [Core SDK NPM Package](https://www.npmjs.com/package/@uniswap/sdk-core)
+
+## FAQ
+
+
+ Which Uniswap SDK version should I use, v2, v3, or v4?
+
+
+
+ Match the SDK to the protocol version of the pools you integrate with:
+
+ * [Uniswap v4 SDK](/docs/sdks/v4/overview) for new integrations that rely on hooks, flash accounting, and singleton pools.
+ * [Uniswap v3 SDK](/docs/sdks/v3/overview) for concentrated liquidity workflows on v3 pools.
+ * [Uniswap v2 SDK](/docs/sdks/v2/overview) for legacy constant product pools and older routing flows.
+
+ The versions are not interchangeable because each targets a different set of onchain contracts. All three build on the Core SDK for shared token, amount, and price primitives.
+
+
+
+
+
+
+ When should I use a Uniswap SDK versus the Trading API?
+
+
+
+ Use an SDK when you want client-side computation and want to construct calldata yourself. The SDK gives you utility classes to build pool keys, compute quotes, and encode swap parameters, but it does not execute trades or send transactions. You manage RPC connections, token definitions, and pool configuration.
+
+ Use the [Trading API](/docs/trading/overview) when you prefer a hosted service that handles routing, quoting, and transaction building for you. The API returns encoded transaction data that your application signs and submits, so you do not manage pool state or routing logic yourself.
+
+
+
+
+
+
+ Why does my Quoter call fail when I call it like a normal read function?
+
+
+
+ The Uniswap Quoter functions are not `view` functions. They rely on state-changing calls that are designed to revert in order to return the quote data, so executed as a transaction they cost gas.
+
+ To read a quote, simulate the call instead with `callStatic` (ethers v5) or `staticCall` (ethers v6). This asks the node to simulate the state change and return the result rather than execute it:
+
+ ```typescript
+ const quotedAmountOut = await quoterContract.callStatic.quoteExactInputSingle(
+ tokenIn,
+ tokenOut,
+ fee,
+ amountIn,
+ 0
+ )
+ ```
+
+ The snippet shows the v3 Quoter; the v4 Quoter takes a single struct parameter instead of positional arguments. The simulation requirement applies to both the [v3 Quoter](/docs/sdks/v3/guides/swapping/quoting) and the [v4 Quoter](/docs/sdks/v4/guides/swapping/quoting).
+
+
+
+
+
+
+ How do I handle token amounts without losing precision?
+
+
+
+ Represent amounts in their smallest onchain unit, not as JavaScript floating point numbers, which lose precision on large integers. The Core SDK provides `CurrencyAmount`, which you create with `CurrencyAmount.fromRawAmount` from a `Token` and a raw integer amount:
+
+ ```typescript
+ import { CurrencyAmount } from '@uniswap/sdk-core'
+
+ // amountIn is already scaled to the token's base units (e.g. 1000 * 10 ** decimals)
+ const inputAmount = CurrencyAmount.fromRawAmount(USDC_TOKEN, amountIn)
+ ```
+
+ The SDKs represent these integers with `JSBI`, so convert strings or native `BigInt` values into `JSBI` before passing them to SDK constructors. The key rule is to keep amounts as integers in the token's base units through every calculation.
+
+
+
+
+
+
+ What is the Core SDK and do I need it?
+
+
+
+ The Core SDK, published as [`@uniswap/sdk-core`](https://www.npmjs.com/package/@uniswap/sdk-core), provides the shared token, amount, and price primitives used across the v2, v3, and v4 SDKs. Types such as `Token`, `CurrencyAmount`, and `Price` live there.
+
+ You almost always install it alongside a version SDK because the version SDKs expect these primitives as inputs and return them as outputs.
+
+
+
+
+
+
+ Can the SDK execute swaps or send transactions for me?
+
+
+
+ No. The SDK computes and encodes the data required to interact with Uniswap safely, but it does not sign or broadcast transactions. Your application is responsible for connecting a signer, submitting the transaction through your RPC provider, and handling approvals.
+
+ If you want a service that returns ready to sign transaction data instead, use the [Trading API](/docs/trading/overview).
+
+
+
+
diff --git a/content/sdks/v2/guides/getting-pair-address.mdx b/content/sdks/v2/guides/getting-pair-address.mdx
index 092b2596e..5c46d76a1 100644
--- a/content/sdks/v2/guides/getting-pair-address.mdx
+++ b/content/sdks/v2/guides/getting-pair-address.mdx
@@ -1,6 +1,7 @@
---
description: Compute Uniswap v2 pair addresses with factory lookups or CREATE2 address derivation.
-title: Pair Addresses
+title: Getting Pair Addresses with the v2 SDK
+sidebarTitle: Pair Addresses
---
## getPair
diff --git a/content/sdks/v2/guides/pricing.mdx b/content/sdks/v2/guides/pricing.mdx
index 43074e929..b688c6950 100644
--- a/content/sdks/v2/guides/pricing.mdx
+++ b/content/sdks/v2/guides/pricing.mdx
@@ -1,6 +1,7 @@
---
description: Calculate mid price and execution price with the Uniswap v2 SDK for swap integrations.
-title: Pricing
+title: Pricing with the v2 SDK
+sidebarTitle: Pricing
---
Let's talk pricing. This guide will focus on the two most important Uniswap prices: the **mid price** and the **execution price**.
diff --git a/content/sdks/v2/overview.mdx b/content/sdks/v2/overview.mdx
index 12c0407cd..5ceb306ee 100644
--- a/content/sdks/v2/overview.mdx
+++ b/content/sdks/v2/overview.mdx
@@ -1,6 +1,7 @@
---
description: Get started with Uniswap v2 SDK concepts, guides, and integration resources.
-title: Overview
+title: Uniswap v2 SDK Overview
+sidebarTitle: Overview
---
The Uniswap v2 SDK provides abstractions to assist you with interacting with the Uniswap v2 smart contracts in a TypeScript/JavaScript environment (for example websites and node scripts).
diff --git a/content/sdks/v3/guides/getting-started.mdx b/content/sdks/v3/guides/getting-started.mdx
index 4790b9da4..fa5a50aab 100644
--- a/content/sdks/v3/guides/getting-started.mdx
+++ b/content/sdks/v3/guides/getting-started.mdx
@@ -1,6 +1,7 @@
---
description: Set up a local mainnet-fork workflow for the Uniswap v3 SDK using Foundry and Anvil.
-title: Get Started
+title: Get Started with the Uniswap v3 SDK
+sidebarTitle: Get Started
---
Developing your dApps or smart contracts requires some tinkering to get a proper setup that is both a good simulation of how Mainnet will behave,
diff --git a/content/sdks/v3/guides/managing-liquidity/collect-fees.mdx b/content/sdks/v3/guides/managing-liquidity/collect-fees.mdx
index 07b9e6fab..d3d40d572 100644
--- a/content/sdks/v3/guides/managing-liquidity/collect-fees.mdx
+++ b/content/sdks/v3/guides/managing-liquidity/collect-fees.mdx
@@ -1,6 +1,7 @@
---
description: Collect accrued fees from Uniswap v3 positions using SDK-generated calldata and options.
-title: Collecting Fees
+title: Collecting Fees with the v3 SDK
+sidebarTitle: Collecting Fees
---
This guide will cover how to collect fees from a liquidity position on the Uniswap v3 protocol. It is based on the [collecting fees code example](https://github.com/Uniswap/examples/tree/main/v3-sdk/collecting-fees), found in the Uniswap code examples [repository](https://github.com/Uniswap/examples). To run this example, check out the examples's [README](https://github.com/Uniswap/examples/blob/main/v3-sdk/collecting-fees/README.md) and follow the setup instructions.
diff --git a/content/sdks/v3/guides/managing-liquidity/position-fetching.mdx b/content/sdks/v3/guides/managing-liquidity/position-fetching.mdx
index 46ae4b614..819c1f966 100644
--- a/content/sdks/v3/guides/managing-liquidity/position-fetching.mdx
+++ b/content/sdks/v3/guides/managing-liquidity/position-fetching.mdx
@@ -1,6 +1,7 @@
---
description: Fetch Uniswap v3 position data and decode position state with the SDK and periphery contracts.
-title: Fetching Positions
+title: Fetching Positions with the v3 SDK
+sidebarTitle: Fetching Positions
---
This guide will cover how to create (or mint) a liquidity position on the Uniswap v3 protocol.
diff --git a/content/sdks/v3/guides/managing-liquidity/position-minting.mdx b/content/sdks/v3/guides/managing-liquidity/position-minting.mdx
index 2255ea313..090a637d2 100644
--- a/content/sdks/v3/guides/managing-liquidity/position-minting.mdx
+++ b/content/sdks/v3/guides/managing-liquidity/position-minting.mdx
@@ -1,6 +1,7 @@
---
description: Mint a concentrated liquidity position with the Uniswap v3 SDK and position manager calldata.
-title: Minting a Position
+title: Minting a Position with the v3 SDK
+sidebarTitle: Minting a Position
---
This guide will cover how to create (or mint) a liquidity position on the Uniswap v3 protocol.
diff --git a/content/sdks/v3/guides/managing-liquidity/range-orders.mdx b/content/sdks/v3/guides/managing-liquidity/range-orders.mdx
index f2da9e878..157acd34a 100644
--- a/content/sdks/v3/guides/managing-liquidity/range-orders.mdx
+++ b/content/sdks/v3/guides/managing-liquidity/range-orders.mdx
@@ -1,6 +1,7 @@
---
description: Create range-order style strategies with Uniswap v3 positions and SDK position math.
-title: Range Orders
+title: Range Orders with the v3 SDK
+sidebarTitle: Range Orders
---
This guide will cover how single-side liquidity provisioning can be used to execute **Limit Orders** on Uniswap v3 Pools.
diff --git a/content/sdks/v3/guides/pool-data.mdx b/content/sdks/v3/guides/pool-data.mdx
index 5a7adc612..d69f5b549 100644
--- a/content/sdks/v3/guides/pool-data.mdx
+++ b/content/sdks/v3/guides/pool-data.mdx
@@ -1,6 +1,7 @@
---
description: Fetch and model Uniswap v3 pool state with the SDK for pricing and liquidity workflows.
-title: Fetching Pool Data
+title: Fetching Pool Data with the v3 SDK
+sidebarTitle: Fetching Pool Data
---
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 Uniswap 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.
diff --git a/content/sdks/v3/guides/swapping/quoting.mdx b/content/sdks/v3/guides/swapping/quoting.mdx
index d09a6aa3d..ec0553c3f 100644
--- a/content/sdks/v3/guides/swapping/quoting.mdx
+++ b/content/sdks/v3/guides/swapping/quoting.mdx
@@ -1,6 +1,7 @@
---
description: Get swap quotes with the Uniswap v3 SDK before you build and submit transactions.
-title: Getting a Quote
+title: Getting a Quote with the v3 SDK
+sidebarTitle: Getting a Quote
---
This guide will cover how to get the current quotes for any token pair on the Uniswap protocol. It is based on the [Quoting code example](https://github.com/Uniswap/examples/tree/main/v3-sdk/quoting), found in the Uniswap code examples [repository](https://github.com/Uniswap/examples). To run this example, check out the examples's [README](https://github.com/Uniswap/examples/blob/main/v3-sdk/quoting/README.md) and follow the setup instructions.
diff --git a/content/sdks/v3/overview.mdx b/content/sdks/v3/overview.mdx
index ad0c2e2cf..5b7f9397f 100644
--- a/content/sdks/v3/overview.mdx
+++ b/content/sdks/v3/overview.mdx
@@ -1,6 +1,7 @@
---
description: Get started with Uniswap v3 SDK concepts, guides, and integration resources.
-title: Overview
+title: Uniswap v3 SDK Overview
+sidebarTitle: Overview
---
The Uniswap v3 SDK provides abstractions to assist you with interacting with the Uniswap v3 smart contracts in a TypeScript/JavaScript environment (for example websites and node scripts).
diff --git a/content/sdks/v4/guides/create-pool.mdx b/content/sdks/v4/guides/create-pool.mdx
index 39ffd14db..1e6a1a3ff 100644
--- a/content/sdks/v4/guides/create-pool.mdx
+++ b/content/sdks/v4/guides/create-pool.mdx
@@ -1,6 +1,7 @@
---
description: Create and initialize a Uniswap v4 pool using SDK utilities and pool key configuration.
-title: Create Pool
+title: Create a Pool with the v4 SDK
+sidebarTitle: Create Pool
---
In this example we will use **ethers.js** and the **Uniswap v4 SDK** to create pools on Uniswap v4. Uniswap v4 is a popular destination for creating markets due to its:
diff --git a/content/sdks/v4/guides/managing-liquidity/position-fetching.mdx b/content/sdks/v4/guides/managing-liquidity/position-fetching.mdx
index 9821ad31a..b23394e9d 100644
--- a/content/sdks/v4/guides/managing-liquidity/position-fetching.mdx
+++ b/content/sdks/v4/guides/managing-liquidity/position-fetching.mdx
@@ -1,6 +1,7 @@
---
description: Fetch Uniswap v4 position details and map position metadata for SDK-driven workflows.
-title: Fetching Positions
+title: Fetching Positions with the v4 SDK
+sidebarTitle: Fetching Positions
---
This guide covers how to fetch and analyze liquidity positions in Uniswap v4 using the v4-sdk.
diff --git a/content/sdks/v4/guides/managing-liquidity/position-minting.mdx b/content/sdks/v4/guides/managing-liquidity/position-minting.mdx
index 03d5ce70a..18e53cb26 100644
--- a/content/sdks/v4/guides/managing-liquidity/position-minting.mdx
+++ b/content/sdks/v4/guides/managing-liquidity/position-minting.mdx
@@ -1,6 +1,7 @@
---
description: Mint a Uniswap v4 liquidity position using SDK position objects and mint call parameters.
-title: Minting a Position
+title: Minting a Position with the v4 SDK
+sidebarTitle: Minting a Position
---
This guide will introduce us to liquidity positions in Uniswap v4 and present the v4-sdk classes and contracts used to interact with the protocol.
@@ -136,6 +137,7 @@ let tickUpper: number
if (fullRange) {
// For full-range positions, use Uniswap's minimum and maximum allowed ticks
+ // See the note below before hardcoding these bounds in a contract
const MIN_TICK = -887272
const MAX_TICK = 887272
@@ -163,6 +165,12 @@ const amount0Desired = token0IsA ? amountADesired.toString() : amountBDesired.to
const amount1Desired = token0IsA ? amountBDesired.toString() : amountADesired.toString()
```
+> Each tick has a `liquidityGross` counter capped at `maxLiquidityPerTick`. The cap bounds per-tick liquidity so that a pool's active liquidity cannot overflow when a tick is crossed. It is shared by every position that uses the tick as a bound, first come first served.
+>
+> At the minimum and maximum usable ticks the price range spanned by one tick spacing is very small, so filling the cap there costs very little. Anyone can do it. Once a tick is at its cap, any mint or increase using that exact tick reverts with `TickLiquidityOverflow`. If you hit this, move the affected bound in by one or two tick spacings. On a pool with tick spacing 10 the extreme bounds sit at prices around 1e38 and 1e-39, so shifting in by a spacing or two leaves the position covering the same trading range in practice and requires the same capital.
+>
+> Contracts that add liquidity at hardcoded extreme tick bounds can be griefed if the pool is not created atomically with the liquidity add. They therefore should not use the extreme ticks, and instead should choose ticks where filling `maxLiquidityPerTick` would be prohibitively expensive. Uniswap's [`InstantLaunchStrategy`](https://github.com/Uniswap/liquidity-launcher/blob/main/src/strategies/InstantLaunchStrategy.sol) does this with its `MIN_LAUNCH_TICK` and `MAX_INITIAL_TICK` values.
+
### Step 5: Create a position
Use the SDK to create a Position object that represents your liquidity position:
diff --git a/content/sdks/v4/guides/pool-data.mdx b/content/sdks/v4/guides/pool-data.mdx
index d2a633585..1ecacf6f8 100644
--- a/content/sdks/v4/guides/pool-data.mdx
+++ b/content/sdks/v4/guides/pool-data.mdx
@@ -1,6 +1,7 @@
---
description: Fetch and assemble Uniswap v4 pool state with StateView and SDK pool abstractions.
-title: Fetching Pool Data
+title: Fetching Pool Data with the v4 SDK
+sidebarTitle: Fetching Pool Data
---
In this example we will use **ethers JS** and **ethers-multicall** to construct a `Pool` object that we can use in the following guides.
diff --git a/content/sdks/v4/guides/swapping/multi-hop-swapping.mdx b/content/sdks/v4/guides/swapping/multi-hop-swapping.mdx
index 26385efaf..58b3b3a9a 100644
--- a/content/sdks/v4/guides/swapping/multi-hop-swapping.mdx
+++ b/content/sdks/v4/guides/swapping/multi-hop-swapping.mdx
@@ -52,6 +52,7 @@ export const CurrentConfig: SwapExactIn = {
),
amountIn: ethers.utils.parseUnits('1', ETH_TOKEN.decimals).toString(),
amountOutMinimum: "minAmountOut", // Change according to the slippage desired
+ minHopPriceX36: [], // Per-hop price floors added in Universal Router 2.1.1. An empty array disables them, so amountOutMinimum alone enforces slippage
}
```
@@ -105,7 +106,7 @@ export function encodeMultihopExactInPath(
We'll use the same contract addresses and ABIs from the single-hop guide and construct the **ethers** `Contract` for them:
```typescript
-const UNIVERSAL_ROUTER_ADDRESS = "0x66a9893cC07D91D95644AEDD05D03f95e1dBA8Af"
+const UNIVERSAL_ROUTER_ADDRESS = "0x23617e59A5925b2A4Bf75d73ff6711cD0b29De85" // Universal Router 2.1.2 on Ethereum mainnet
const PERMIT2_ADDRESS = "0x000000000022D473030F116dDEE9F6B43aC78BA3"
// ABIs remain the same as in single-hop guide
@@ -114,10 +115,10 @@ const ERC20_ABI = [/* ... */]
const PERMIT2_ABI = [/* ... */]
```
-The main function for executing multi-hop swaps is very similar to the single-hop guide as well. The only difference is that the first action to the Universal Router is `SWAP_EXACT_IN` instead of `SWAP_EXACT_IN_SINGLE`.
+The main function for executing multi-hop swaps is very similar to the single-hop guide as well. The only difference is that the first action to the Universal Router is `SWAP_EXACT_IN` instead of `SWAP_EXACT_IN_SINGLE`. As in the single-hop guide, the actions are encoded for `URVersion.V2_1_1`, the calldata format Universal Router 2.1.2 uses, and `minHopPriceX36` is left empty to disable per-hop price floors.
```typescript
-import { Actions, V4Planner } from '@uniswap/v4-sdk'
+import { Actions, URVersion, V4Planner } from '@uniswap/v4-sdk'
import { CommandType, RoutePlanner } from '@uniswap/universal-router-sdk'
const v4Planner = new V4Planner()
@@ -125,9 +126,10 @@ const routePlanner = new RoutePlanner()
const deadline = Math.floor(Date.now() / 1000) + 3600
-v4Planner.addAction(Actions.SWAP_EXACT_IN, [CurrentConfig]);
-v4Planner.addAction(Actions.SETTLE_ALL, [ETH_USDC_POOL_KEY.currency0, CurrentConfig.amountIn]);
-v4Planner.addAction(Actions.TAKE_ALL, [USDC_USDT_POOL_KEY.currency1, CurrentConfig.amountOutMinimum]);
+// Universal Router 2.1.2 shares its calldata with 2.1.1, so encode the actions for URVersion.V2_1_1
+v4Planner.addAction(Actions.SWAP_EXACT_IN, [CurrentConfig], URVersion.V2_1_1);
+v4Planner.addAction(Actions.SETTLE_ALL, [ETH_USDC_POOL_KEY.currency0, CurrentConfig.amountIn], URVersion.V2_1_1);
+v4Planner.addAction(Actions.TAKE_ALL, [USDC_USDT_POOL_KEY.currency1, CurrentConfig.amountOutMinimum], URVersion.V2_1_1);
const encodedActions = v4Planner.finalize()
diff --git a/content/sdks/v4/guides/swapping/quoting.mdx b/content/sdks/v4/guides/swapping/quoting.mdx
index e04162bbc..a6a27f870 100644
--- a/content/sdks/v4/guides/swapping/quoting.mdx
+++ b/content/sdks/v4/guides/swapping/quoting.mdx
@@ -1,6 +1,7 @@
---
description: Get Uniswap v4 swap quotes with Quoter simulations before submitting swap transactions.
-title: Getting a Quote
+title: Getting a Quote with the v4 SDK
+sidebarTitle: Getting a Quote
---
This guide will cover how to get the current quotes for any token pair on the Uniswap protocol.
diff --git a/content/sdks/v4/guides/swapping/single-hop-swapping.mdx b/content/sdks/v4/guides/swapping/single-hop-swapping.mdx
index ed00aa50c..f2fe96580 100644
--- a/content/sdks/v4/guides/swapping/single-hop-swapping.mdx
+++ b/content/sdks/v4/guides/swapping/single-hop-swapping.mdx
@@ -37,6 +37,7 @@ export const CurrentConfig: SwapExactInSingle = {
zeroForOne: true, // The direction of swap is ETH to USDC. Change it to 'false' for the reverse direction
amountIn: ethers.utils.parseUnits('1', ETH_TOKEN.decimals).toString(),
amountOutMinimum: "minAmountOut", // Change according to the slippage desired
+ minHopPriceX36: "0", // Per-hop price floor added in Universal Router 2.1.1. "0" disables it, so amountOutMinimum alone enforces slippage
hookData: '0x00'
}
```
@@ -50,7 +51,7 @@ The Universal Router is a flexible, gas-efficient contract designed to execute c
So, we construct an instance of an **ethers** `Contract` for the Universal Router contract in order to interact with it:
```typescript
-const UNIVERSAL_ROUTER_ADDRESS = "0x66a9893cc07d91d95644aedd05d03f95e1dba8af" // Change the Universal Router address as per the chain
+const UNIVERSAL_ROUTER_ADDRESS = "0x23617e59A5925b2A4Bf75d73ff6711cD0b29De85" // Universal Router 2.1.2 on Ethereum mainnet. Change the address as per the chain
const UNIVERSAL_ROUTER_ABI = [
{
@@ -73,7 +74,7 @@ const universalRouter = new ethers.Contract(
)
```
-We can get the `UNIVERSAL_ROUTER_ADDRESS` for our chain from [Uniswap Deployments](/docs/protocols/v4/deployments).
+We can get the `UNIVERSAL_ROUTER_ADDRESS` for our chain from the Universal Router 2.1.2 row in [Uniswap Deployments](/docs/protocols/v4/deployments). Universal Router 2.1.2 uses the same calldata as 2.1.1, so the v4 SDK encodes for it with `URVersion.V2_1_1`.
A signer object can be created like this:
@@ -93,7 +94,7 @@ Now, let's implement the main function that handles the swap. When encoding a sw
We will be doing an Exact Input swap in this example.
```typescript
-import { Actions, V4Planner } from '@uniswap/v4-sdk'
+import { Actions, URVersion, V4Planner } from '@uniswap/v4-sdk'
import { CommandType, RoutePlanner } from '@uniswap/universal-router-sdk'
const v4Planner = new V4Planner()
@@ -102,9 +103,10 @@ const routePlanner = new RoutePlanner()
// Set deadline (1 hour from now)
const deadline = Math.floor(Date.now() / 1000) + 3600
-v4Planner.addAction(Actions.SWAP_EXACT_IN_SINGLE, [CurrentConfig]);
-v4Planner.addAction(Actions.SETTLE_ALL, [CurrentConfig.poolKey.currency0, CurrentConfig.amountIn]);
-v4Planner.addAction(Actions.TAKE_ALL, [CurrentConfig.poolKey.currency1, CurrentConfig.amountOutMinimum]);
+// Universal Router 2.1.2 shares its calldata with 2.1.1, so encode the actions for URVersion.V2_1_1
+v4Planner.addAction(Actions.SWAP_EXACT_IN_SINGLE, [CurrentConfig], URVersion.V2_1_1);
+v4Planner.addAction(Actions.SETTLE_ALL, [CurrentConfig.poolKey.currency0, CurrentConfig.amountIn], URVersion.V2_1_1);
+v4Planner.addAction(Actions.TAKE_ALL, [CurrentConfig.poolKey.currency1, CurrentConfig.amountOutMinimum], URVersion.V2_1_1);
const encodedActions = v4Planner.finalize()
@@ -128,7 +130,7 @@ console.log('Swap completed! Transaction hash:', receipt.transactionHash)
The actions in the planner define the sequence of operations that will be performed in our v4 swap:
-- `SWAP_EXACT_IN_SINGLE`: This action specifies that we want to perform an exact input swap using a single pool.
+- `SWAP_EXACT_IN_SINGLE`: This action specifies that we want to perform an exact input swap using a single pool. Its `minHopPriceX36` field is the per-hop price floor added in Universal Router 2.1.1. Setting it to `"0"` disables the per-hop check, so `amountOutMinimum` alone enforces slippage.
- `SETTLE_ALL`: This action ensures all input tokens involved in the swap are properly paid. This is part of v4's settlement pattern for handling token transfers.
- `TAKE_ALL`: This final action collects all output tokens after the swap is complete.
diff --git a/content/sdks/v4/overview.mdx b/content/sdks/v4/overview.mdx
index 0862df4f8..6b0b30bd4 100644
--- a/content/sdks/v4/overview.mdx
+++ b/content/sdks/v4/overview.mdx
@@ -1,7 +1,7 @@
---
description: Get started with Uniswap v4 SDK concepts, guides, and integration resources.
-id: overview
-title: Overview
+title: Uniswap v4 SDK Overview
+sidebarTitle: Overview
---
The Uniswap v4 SDK provides abstractions to assist you with interacting with the Uniswap v4 smart contracts in a TypeScript/JavaScript environment (for example websites and node scripts).
diff --git a/content/trading/custom-interface-links.mdx b/content/trading/custom-interface-links.mdx
index 81e11e0fc..9786193b3 100644
--- a/content/trading/custom-interface-links.mdx
+++ b/content/trading/custom-interface-links.mdx
@@ -1,5 +1,4 @@
---
-id: custom-interface-linking
title: Custom Linking
description: Configure Uniswap interface URL parameters for prefilled swap and pool flows in v2 integration experiences.
---
diff --git a/content/trading/embed-app.mdx b/content/trading/embed-app.mdx
new file mode 100644
index 000000000..46e1b0d92
--- /dev/null
+++ b/content/trading/embed-app.mdx
@@ -0,0 +1,98 @@
+---
+title: "Embed the Uniswap App"
+description: "Embed the Uniswap app in an iframe with full-app or swap-only layouts, swap prefill parameters, and origin allowlisting."
+---
+
+Embed the Uniswap app on your own site with an `
+```
+
+Framing is gated by an origin allowlist. Your site cannot load the embed until your origin is added. See [Allowlist Your Origin](#allowlist-your-origin).
+
+## Layout Modes
+
+The `view` query parameter selects which surface renders. It is read once when the frame mounts and stays fixed for the session, so in-frame navigation cannot switch surfaces.
+
+| URL | Surface |
+|---|---|
+| `https://app.uniswap.org/embed` | Full app (default) |
+| `https://app.uniswap.org/embed?view=swap` | Swap-only |
+
+### Full app
+
+The default surface renders the complete app, including the header, connection flows, balances, and pending transactions. Use it for larger embeds where users benefit from the full experience.
+
+### Swap only
+
+`?view=swap` drops the surrounding app interface (header, navigation, and menus) and mounts the swap form on its own: no chart, no tab switching, and no in-frame route changes. Use it for tight embeds where that surrounding interface, such as the hamburger menu, looks out of place.
+
+## Swap Configuration Parameters
+
+The swap form reads the same query parameters as [Custom Linking](/docs/trading/custom-interface-links). Append them to the embed URL to prefill the form.
+
+| Parameter | Type | Description |
+|---|---|---|
+| `chain` | `string` | Interface chain name, for example `ethereum`, `base`, `arbitrum`, or `unichain`. |
+| `inputCurrency` | `address` or `ETH` | The currency to swap from. |
+| `outputCurrency` | `address` or `ETH` | The currency to swap to. |
+| `value` | `number` | The token amount. Only applied when a currency parameter is also set. |
+| `field` | `string` | Which side `value` applies to. Must be `input` or `output`, and only applied when `value` is set. |
+
+### Example
+
+```html
+
+```
+
+## Allowlist Your Origin
+
+
+
+The embed surface is served with a `frame-ancestors` Content Security Policy that blocks framing by default. Until your origin is on the embed allowlist, the browser refuses to load the iframe and logs a `frame-ancestors` CSP violation in the console. This is a deliberate onboarding step, not a setting you can configure yourself.
+
+
+
+Each allowlisted origin relaxes clickjacking protection for that origin, so additions are manually reviewed and applied by the Uniswap team. This is the same review that all approved embedders go through.
+
+### What to provide
+
+Send the exact production origin(s) you will frame from, each as a full scheme and host with no path or trailing slash, for example `https://app.example.com`.
+
+- Origins are matched exactly. `https://example.com` does not cover `https://app.example.com`, and `http://` does not cover `https://`.
+- Subdomain wildcards are supported (`https://*.example.com`), but a wildcard does not match the apex domain. To cover both, list them separately: `https://example.com` and `https://*.example.com`.
+- You can allowlist more than one origin. Include every origin you plan to embed from, such as separate staging or preview hosts.
+
+### How to request it
+
+Open a request through the
Help Center with the origins above and a short description of where the embed will appear. The Uniswap team reviews each request and adds approved origins to the allowlist.
+
+Approved origins take effect with the next web release, so allow time for a deploy after your request is confirmed. Once live, your iframe loads without the CSP block.
+
+## Behavior Inside a Frame
+
+Two actions cannot complete inside a frame and instead **frame-bust**: the top-level window navigates to the full Uniswap app to finish the action outside the frame, preserving the current query string and hash.
+
+| Action | Top-level destination |
+|---|---|
+| Send | `/send` |
+| Embedded wallet sign-in or sign-up (passkey) | `/swap` |
+
+Money-moving actions and in-DOM signing must happen on the top-level `app.uniswap.org` origin, never inside a third-party frame. Breaking out is a clickjacking protection: it guarantees the user sees the real Uniswap origin in the address bar before authorizing anything. Expect the parent page to navigate away when a user triggers one of these flows.
diff --git a/content/trading/meta.json b/content/trading/meta.json
index a5b1a0586..7f145c216 100644
--- a/content/trading/meta.json
+++ b/content/trading/meta.json
@@ -1,5 +1,5 @@
{
- "title": "Trade",
+ "title": "Swapping",
"root": true,
- "pages": [ "overview", "swapping-api", "custom-interface-links"]
+ "pages": ["overview", "swapping-api", "custom-interface-links", "embed-app"]
}
diff --git a/content/trading/overview.mdx b/content/trading/overview.mdx
index 568e27e25..e90a1777a 100644
--- a/content/trading/overview.mdx
+++ b/content/trading/overview.mdx
@@ -1,7 +1,30 @@
---
-id: Overview
title: Trading Overview
+sidebarTitle: Overview
description: Understand swap integration paths on Uniswap v4 using Custom Linking, the Uniswap API, SDK, and smart contracts.
+keywords:
+ - swap integration
+ - Trading API
+ - custom linking
+ - Universal Router
+ - swap hooks
+ - slippage
+faqs:
+ - question: What are the ways to integrate Uniswap swaps into my app?
+ answer: |-
+ There are four integration paths, in rising order of complexity. Custom Linking directs users to the Uniswap web app with pre-filled swap parameters through URL query strings. The Uniswap Trading API is a hosted service that handles routing, quoting, and transaction construction. The Uniswap SDK computes routes and quotes locally on the client side. Direct smart contract integration against the Universal Router or PoolManager gives onchain contracts direct control and composability.
+ - question: Does the Uniswap Trading API execute swaps for me?
+ answer: |-
+ No. The Uniswap Trading API handles routing, quoting, and transaction construction, and returns encoded transaction data. Your application handles wallet signing and onchain submission through your own signer or RPC provider. The flow is check_approval to verify Permit2 or router authorization, quote to get routing and quote data, then swap to get the encoded transaction.
+ - question: How do I add Uniswap swaps to my site without building a swap UI?
+ answer: |-
+ Use Custom Linking. Append URL query parameters to the Uniswap web app swap URL to pre-fill the input and output tokens, the amount, and the UI theme. The Uniswap interface configures the swap automatically for the user, so you do not manage transactions, quoting, or a custom UI.
+ - question: How do I execute a Uniswap swap from a smart contract?
+ answer: |-
+ Interact with the Universal Router, the recommended entry point, or with the PoolManager directly. The Universal Router uses a command-encoding pattern where you pack a sequence of actions, such as swap, settle input tokens, and take output tokens, into byte arrays and execute them in a single transaction. Always enforce slippage limits through amountOutMinimum or an onchain price oracle; setting it to zero leaves your contract vulnerable to sandwich attacks and price manipulation.
+ - question: Can I customize how swaps execute on Uniswap v4?
+ answer: |-
+ Yes, by writing a hook contract. Hooks are external contracts that a Uniswap v4 pool calls at specific lifecycle points. For swaps, beforeSwap runs before the swap executes and can modify fees, enforce conditions, or reject the swap, while afterSwap runs after execution and receives the resulting balance delta. A hook declares which lifecycle points it implements through getHookPermissions.
---
Uniswap offers distinct methods for integrating swapping functionality into your application. Choosing the right approach depends on your specific needs regarding customization, control, and development resources.
@@ -155,3 +178,69 @@ Hooks are external contracts that a Uniswap v4 pool calls at specific points dur
- **`afterSwap`**: called after the swap executes. Receives the resulting `BalanceDelta` and can perform follow-up logic.
A hook contract declares which lifecycle points it implements via `getHookPermissions()`, and is associated with a pool during deployment.
+
+## FAQ
+
+
+ What are the ways to integrate Uniswap swaps into my app?
+
+
+
+ There are four integration paths, in rising order of complexity:
+
+ * **[Custom Linking](/docs/trading/custom-interface-links)**: directs users to the Uniswap web app with pre-filled swap parameters through URL query strings.
+ * **[Uniswap Trading API](/docs/trading/swapping-api/getting-started)**: a hosted service that handles routing, quoting, and transaction construction.
+ * **[Uniswap SDK](/docs/sdks/v4/guides/swapping/quoting)**: computes routes and quotes locally on the client side.
+ * **[Smart contracts](/docs/protocols/v4/guides/swapping/swapping)**: direct integration against the Universal Router or `PoolManager` for onchain control and composability.
+
+
+
+
+
+
+ Does the Uniswap Trading API execute swaps for me?
+
+
+
+ No. The [Trading API](/docs/trading/swapping-api/getting-started) handles routing, quoting, and transaction construction, and returns encoded transaction data. Your application handles wallet signing and onchain submission through your own signer or RPC provider.
+
+ The flow is `/check_approval` to verify Permit2 or router authorization, `/quote` to get routing and quote data, then `/swap` to get the encoded transaction.
+
+
+
+
+
+
+ How do I add Uniswap swaps to my site without building a swap UI?
+
+
+
+ Use [Custom Linking](/docs/trading/custom-interface-links). Append URL query parameters to `https://app.uniswap.org/#/swap` to pre-fill the input and output tokens, the amount, and the UI theme. The Uniswap interface configures the swap automatically for the user, so you do not manage transactions, quoting, or a custom UI.
+
+
+
+
+
+
+ How do I execute a Uniswap swap from a smart contract?
+
+
+
+ Interact with the [Universal Router](/docs/protocols/universal-router/overview), the recommended entry point, or with the `PoolManager` directly. The Universal Router uses a command-encoding pattern where you pack a sequence of actions, such as swap, settle input tokens, and take output tokens, into byte arrays and execute them in a single transaction. See [swapping with smart contracts](/docs/protocols/v4/guides/swapping/swapping).
+
+ Always enforce slippage limits through `amountOutMinimum` or an onchain price oracle; setting it to zero leaves your contract vulnerable to sandwich attacks and price manipulation.
+
+
+
+
+
+
+ Can I customize how swaps execute on Uniswap v4?
+
+
+
+ Yes, by writing a [hook](/docs/protocols/v4/guides/hooks/swap-hooks) contract. Hooks are external contracts that a Uniswap v4 pool calls at specific lifecycle points. For swaps, `beforeSwap` runs before the swap executes and can modify fees, enforce conditions, or reject the swap, while `afterSwap` runs after execution and receives the resulting `BalanceDelta`. A hook declares which lifecycle points it implements through `getHookPermissions`.
+
+
+
+
diff --git a/content/trading/swapping-api/amm-vs-uniswapx-routing.mdx b/content/trading/swapping-api/amm-vs-uniswapx-routing.mdx
index 60a3250a5..337da6c71 100644
--- a/content/trading/swapping-api/amm-vs-uniswapx-routing.mdx
+++ b/content/trading/swapping-api/amm-vs-uniswapx-routing.mdx
@@ -1,5 +1,6 @@
---
title: "AMM vs UniswapX Routing"
+sidebarTitle: "Routing"
description: "Understand how the Uniswap API evaluates Uniswap AMM and UniswapX routes when returning swap quotes."
---
@@ -89,3 +90,5 @@ The web app typically considers all available protocols unless the user changes
This is expected in some cases. On some chains, UniswapX quotes are subject to minimum notional thresholds, and solver participation may vary by trade size and market conditions.
For route behavior and configuration details, see [Swap Routing](/docs/trading/swapping-api/concepts/swap-routing) and the [POST `/quote` API reference](/docs/api-reference/aggregator_quote).
+
+For developer support, reach out to our team through the
Help Center.
diff --git a/content/trading/swapping-api/building-prerequisites.mdx b/content/trading/swapping-api/building-prerequisites.mdx
deleted file mode 100644
index f8e3df7e4..000000000
--- a/content/trading/swapping-api/building-prerequisites.mdx
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: 'Building Prerequisites'
-description: 'Prepare your Uniswap API integration with signer, RPC, JSON request, and API key management prerequisites.'
----
-
-To build with the Uniswap API, you will need the following technical capabilities and environment parameters.
-
-**1. Ability to Sign and Send EVM Transactions and Messages**
-
-You must have the technical capability to:
-
-- Sign transactions using an EVM-compatible wallet, key management system, or backend signer
-- Broadcast transactions to your preferred RPC provider
-- Manage gas, nonces, and transaction lifecycle
-- Present EIP-712 Permit2 messages to the user for signing
-
-**2. Familiarity with JSON-Based API Integration**
-
-You need to be able to:
-
-- Construct and parse JSON requests/responses
-- Handle standard HTTP status codes
-- Implement retries or timeouts where required
-
-**3. Access to Reliable RPC Infrastructure**
-
-You must operate or use a provider that supports:
-
-- The chains you wish to trade on (e.g., Ethereum, Unichain, other L2s)
-- Knowledge of how to troubleshoot RPC submission failures
-
-**4. Secure API Key Management**
-
-Your system must be able to:
-
-- Store and protect your Uniswap API key
-- Attach it to all requests via HTTPS
-- Protect it from exposure in front-end code (ex. using a proxy)
\ No newline at end of file
diff --git a/content/trading/swapping-api/common-errors.mdx b/content/trading/swapping-api/common-errors.mdx
index 5eea937cd..e4b2cb441 100644
--- a/content/trading/swapping-api/common-errors.mdx
+++ b/content/trading/swapping-api/common-errors.mdx
@@ -9,21 +9,39 @@ description: Troubleshoot common Uniswap API request, quoting, authentication, a
The API is specific about request header validation. In particular, ensure that your `accept` and `content-type` headers only include the value `application/json`. For a complete example of properly formatted request headers, see the authentication section of the [Developer Dashboard](https://developers.uniswap.org/dashboard).
-If you're sending the optional `X-Agent-Info` attribution header and it isn't being picked up, check the response for an `x-agent-info-status: malformed` header — see [Agent Attribution](/docs/trading/swapping-api/agent-attribution#confirming-it-was-received) for the full set of rules that make the header malformed. A malformed `X-Agent-Info` never causes an error response; the request proceeds without attribution.
+If you're sending the optional `X-Agent-Info` attribution header and it isn't being picked up, check the response for an `x-agent-info-status: malformed` header. See [Agent Attribution](/docs/trading/swapping-api/start-building/agent-attribution#what-makes-a-header-malformed) for the full set of rules that make the header malformed. A malformed `X-Agent-Info` never causes an error response; the request proceeds without attribution.
### Rate limits
-Most API keys have a default rate limit of 6 requests per second (RPS). If you exceed the rate limit supported by an API key you can expect to receive an HTTP 429 error. If you receive a 429 error, we recommend pausing all requests from your API key and then retrying your requests. If you require a higher rate limit than what your API key is currently provisioned for, please reach out to [Uniswap Developer Support](https://support.uniswap.org/hc/en-us/requests/new). For more information on rate limits, see the [Developer Dashboard](https://developers.uniswap.org/dashboard).
+Most API keys have a default rate limit of 6 requests per second (RPS). If you exceed the rate limit supported by an API key you can expect to receive an HTTP 429 error. If you receive a 429 error, we recommend pausing all requests from your API key and then retrying your requests. If you require a higher rate limit than what your API key is currently provisioned for, please reach out to our team through the
Help Center. For more information on rate limits, see the [Developer Dashboard](https://developers.uniswap.org/dashboard).
## Error Code Troubleshooting
### 404 No quotes available
-The most commonly encountered HTTP error is an HTTP 404 with a message "No quotes available" from the [`/quote`](/docs/trading/swapping-api/getting-started) endpoint. This error can happen for a variety of reasons related to request syntax, rather than there being no actual route between the specified tokens. In order of most common to less common reasons for receiving this error:
-* The `amount` is too low to be quoted by UniswapX. UniswapX requires a minimum of **300 USDC equivalent on all supported chains**. Requests below this threshold will fail. See [UniswapX Chain Support](/docs/trading/swapping-api/supported-chains#uniswapx-chain-support) for details.
-* The specified chain is not supported by UniswapX. UniswapX has limited chain support.
-* The specified token(s) do not match the specified chain. The token addresses specified must be those belonging to the token on the given chain (ex. the USDC address on Mainnet is different than that on Base).
-* A combined bridge and swap quote is requested. The API can provide a quote for either a bridge (different input/output chains, same token) or a swap (same chain, different input/output tokens), but not both simultaneously. For a list of bridgeable tokens, see [Supported Chains](/docs/trading/swapping-api/supported-chains).
+The most commonly encountered HTTP error is an HTTP 404 from the [`/quote`](/docs/trading/swapping-api/getting-started) endpoint. The `errorCode` field identifies the cause, and `detail` carries a human-readable explanation:
+
+```json
+{
+ "errorCode": "QuoteAmountTooLowError",
+ "detail": "Order size is below the minimum quotable size for the requested protocols on this chain.",
+ "requestId": "..."
+}
+```
+
+`errorCode` is a stable enum. `detail` is free text and may be reworded without notice. New `errorCode` values may be added over time, so treat unrecognized values the same as you do `ResourceNotFound`.
+
+| `errorCode` | What it means | What to do |
+|---|---|---|
+| `QuoteAmountTooLowError` | The `amount` is below the minimum quotable size for the requested protocols — most commonly UniswapX minimums on L2s (see [UniswapX Chain Support](/docs/trading/swapping-api/supported-chains#uniswapx-chain-support)) | Increase the amount, or widen `protocols` |
+| `NoRouteFoundError` | Routing completed and found no viable route for this pair | Verify token addresses match the specified chain; do not retry unchanged |
+| `UnsupportedTokenError` | A requested token is not routable (unknown or not on this chain) | Verify the token address belongs to the given chain (ex. USDC on Mainnet differs from Base) |
+| `UnsupportedChainError` | The chain is not supported for this operation | See [Supported Chains](/docs/trading/swapping-api/supported-chains) |
+| `UniswapXNotSupportedOnChainError` | A UniswapX protocol was requested on a chain it does not serve | Remove the UniswapX protocol pin, or change chain |
+| `UpstreamTimeoutError` | A routing dependency timed out or failed | **Retry with exponential backoff** — this is the only cause where an unchanged retry can succeed |
+| `ResourceNotFound` | The failure could not be classified (`detail` is "No quotes available") | Retry cautiously; contact support with the `requestId` if persistent |
+
+A request that combines a bridge and a swap (different chains *and* different tokens) is not supported as a single quote and currently surfaces as `ResourceNotFound`. Request a bridge or a swap, not both — for bridgeable pairs see [Supported Chains](/docs/trading/swapping-api/supported-chains).
### 400 Request validation error
@@ -31,4 +49,6 @@ Request validation errors are returned when a request does not contain the minim
### 401 Unauthorized error
-All API requests must be authenticated through the inclusion of a valid API key in the header of the request. If you do not have an API key, you may create one through the [Uniswap Developer Platform](https://developers.uniswap.org/dashboard/welcome?utm_medium=eco&utm_source=platform&utm_campaign=20260428-swapping-api-errors&utm_content=auth-section&utm_term=self-serve). 401 errors may also be returned if the request has malformed or missing required headers, or if headers contain unsupported values (see above). For more details on authentication requirements, see the [Developer Dashboard](https://developers.uniswap.org/dashboard).
\ No newline at end of file
+All API requests must be authenticated through the inclusion of a valid API key in the header of the request. If you do not have an API key, you may create one through the [Uniswap Developer Platform](https://developers.uniswap.org/dashboard/welcome?utm_medium=eco&utm_source=platform&utm_campaign=20260428-swapping-api-errors&utm_content=auth-section&utm_term=self-serve). 401 errors may also be returned if the request has malformed or missing required headers, or if headers contain unsupported values (see above). For more details on authentication requirements, see the [Developer Dashboard](https://developers.uniswap.org/dashboard).
+
+For developer support, reach out to our team through the
Help Center.
\ No newline at end of file
diff --git a/content/trading/swapping-api/chained-actions.mdx b/content/trading/swapping-api/concepts/chained-actions.mdx
similarity index 89%
rename from content/trading/swapping-api/chained-actions.mdx
rename to content/trading/swapping-api/concepts/chained-actions.mdx
index 9d96e2f80..dbe50bf65 100644
--- a/content/trading/swapping-api/chained-actions.mdx
+++ b/content/trading/swapping-api/concepts/chained-actions.mdx
@@ -1,5 +1,6 @@
---
title: Swapping with Chained Actions
+sidebarTitle: Chained Actions
description: Cross-chain and multi-step swaps execute as an ordered plan of steps through the Uniswap Trading API.
---
@@ -13,13 +14,13 @@ A few common shapes:
Without a coordinating API, an integrator would orchestrate each leg by hand: quote a swap, submit it, wait for confirmation, quote a bridge, submit it, wait again, and handle a failure at any stage. Chained Actions package that sequence into a state-tracked plan. The API handles routing and quoting. Your application handles execution and user confirmation.
-To build against the plan endpoints, see the [Chained Actions Integration Guide](/docs/trading/swapping-api/chained-actions-integration).
+To build against the plan endpoints, see the [Chained Actions Integration Guide](/docs/trading/swapping-api/start-building/chained-actions-integration).
## Execution flow
A trade becomes a Chained Action when `/quote` returns `"routing": "CHAINED"`. From there, three `/plan` endpoints drive execution: `POST /plan` creates the plan, `PATCH /plan` advances it as each step completes, and `GET /plan` reports the current state.
-
+
At a high level:
@@ -31,7 +32,7 @@ At a high level:
## Plans and steps
-A plan is an ordered array of steps identified by a unique `planId`. Each step is one wallet action: an approval, a swap, a bridge, or a UniswapX order. To execute a step, you branch on its `method` and `payloadType`, covered in the [integration guide](/docs/trading/swapping-api/chained-actions-integration).
+A plan is an ordered array of steps identified by a unique `planId`. Each step is one wallet action: an approval, a swap, a bridge, or a UniswapX order. To execute a step, you branch on its `method` and `payloadType`, covered in the [integration guide](/docs/trading/swapping-api/start-building/chained-actions-integration).
Only one step is active at any moment. The rest stay blocked until the preceding step completes. Each future step's amounts derive from the confirmed output of the step before it, so only the active step and any completed steps carry a populated payload.
@@ -57,7 +58,7 @@ The router automatically selects one of three patterns, based on the tokens and
| **Bridge to Swap (B→S)** | Source token is native ETH, and the destination token is not directly bridgeable from it | ETH (Mainnet) to USDC (Base) | Bridge → Swap |
| **Swap to Bridge to Swap (S→B→S)** | Default fallback, using ETH as the bridge medium | USDC (Mainnet) to PEPE (Base) | `[Approval]` → Swap → Bridge → Swap |
-AMM swap steps can route through Uniswap v2, v3, or v4. The longest plan has three quote-generating steps, plus any approval steps on top. A plan can also end in error: see [error handling and recovery](/docs/trading/swapping-api/chained-actions-integration#error-handling-and-recovery) in the integration guide.
+AMM swap steps can route through Uniswap v2, v3, or v4. The longest plan has three quote-generating steps, plus any approval steps on top. A plan can also end in error: see [error handling and recovery](/docs/trading/swapping-api/start-building/chained-actions-integration#error-handling-and-recovery) in the integration guide.
## Constraints
@@ -67,5 +68,5 @@ AMM swap steps can route through Uniswap v2, v3, or v4. The longest plan has thr
## Next steps
-- [Chained Actions Integration Guide](/docs/trading/swapping-api/chained-actions-integration): the full execution loop, with `cURL` examples for each step, proof submission, polling, and error recovery.
+- [Chained Actions Integration Guide](/docs/trading/swapping-api/start-building/chained-actions-integration): the full execution loop, with `cURL` examples for each step, proof submission, polling, and error recovery.
- [Swap Routing](/docs/trading/swapping-api/concepts/swap-routing): how to choose protocols and routing preferences on the underlying swaps.
diff --git a/content/trading/swapping-api/concepts/meta.json b/content/trading/swapping-api/concepts/meta.json
index 57d54a95c..811ce1cc7 100644
--- a/content/trading/swapping-api/concepts/meta.json
+++ b/content/trading/swapping-api/concepts/meta.json
@@ -3,6 +3,7 @@
"pages": [
"permit2",
"no-permit2-workflow",
- "swap-routing"
+ "swap-routing",
+ "chained-actions"
]
}
diff --git a/content/trading/swapping-api/concepts/no-permit2-workflow.mdx b/content/trading/swapping-api/concepts/no-permit2-workflow.mdx
index 907bc4ab5..54bc04d8a 100644
--- a/content/trading/swapping-api/concepts/no-permit2-workflow.mdx
+++ b/content/trading/swapping-api/concepts/no-permit2-workflow.mdx
@@ -18,7 +18,7 @@ The proxy approval flow cannot execute UniswapX orders. UniswapX requires Permit
## When to Use Proxy Approval
The no-Permit2 flow may be appropriate if:
-- Your infrastructure requires a strict approve —> swap transaction sequence
+- Your infrastructure requires a strict approve -> swap transaction sequence
- Your system cannot generate Permit2 signatures
- Your wallet or signing system does not support EIP-712 signing
diff --git a/content/trading/swapping-api/concepts/permit2.mdx b/content/trading/swapping-api/concepts/permit2.mdx
index 04dc17e88..cda3f493e 100644
--- a/content/trading/swapping-api/concepts/permit2.mdx
+++ b/content/trading/swapping-api/concepts/permit2.mdx
@@ -6,7 +6,7 @@ description: Learn how to use Permit2 approvals and troubleshoot common signing
## Swapping with Permit2
The Uniswap API supports a swap flow that uses Permit2 signatures. This option is the default and it provides security to swapper wallets which direct router approval workflows cannot.
-In this flow, the swapping wallet grants ERC-20 approval to the Permit2 contract and then subsequently signs messages which authorize Permit2 to spend tokens from the swapping wallet with the Universal Router. This flow requires that integrators provide up to a three-step swap process: approve —> sign permit —> swap.
+In this flow, the swapping wallet grants ERC-20 approval to the Permit2 contract and then subsequently signs messages which authorize Permit2 to spend tokens from the swapping wallet with the Universal Router. This flow requires that integrators provide up to a three-step swap process: approve -> sign permit -> swap.
## What Is a Permit2 Message and How Is It Used?
diff --git a/content/trading/swapping-api/concepts/swap-routing.mdx b/content/trading/swapping-api/concepts/swap-routing.mdx
index 386e3672f..3e9dfcf6d 100644
--- a/content/trading/swapping-api/concepts/swap-routing.mdx
+++ b/content/trading/swapping-api/concepts/swap-routing.mdx
@@ -1,5 +1,6 @@
---
-title: 'Swap Routing'
+title: Swap Routing in the Uniswap API
+sidebarTitle: Swap Routing
description: 'Use Uniswap API routing fields to choose protocol paths and return the most efficient quote flow for your integration.'
icon: 'route'
---
@@ -9,7 +10,7 @@ In order to get the appropriate swap routing, it is important to closely conside
- The `protocols` field is used to specify the protocols from which pricing will be considered and through which your swap may eventually be executed. The possible values for the field are `V2`, `V3`, `V4`, `UNISWAPX_V2`, and `UNISWAPX_V3`
- The `routingPreference` field is used to specify the preferred matching strategy. The possible values for the field are `BEST_PRICE` and `FASTEST`
-For complete information on the available values and combinations for the `protocols` and `routingPreference` fields, see [Swapping Architecture Overview](/docs/trading/swapping-api/getting-started). A summary is provided below:
+For complete information on the available values and combinations for the `protocols` and `routingPreference` fields, see [Swapping via the Uniswap API](/docs/trading/swapping-api/getting-started). A summary is provided below:
## Routing Outcomes
@@ -21,4 +22,4 @@ For complete information on the available values and combinations for the `proto
## Cross-chain and multi-step routing
-Some trades cannot settle in a single transaction, either because they cross chains or because they need more than one step on the same chain. For these, `/quote` returns `"routing": "CHAINED"` and the API drives execution as an ordered plan of steps. See [Swapping with Chained Actions](/docs/trading/swapping-api/chained-actions).
\ No newline at end of file
+Some trades cannot settle in a single transaction, either because they cross chains or because they need more than one step on the same chain. For these, `/quote` returns `"routing": "CHAINED"` and the API drives execution as an ordered plan of steps. See [Swapping with Chained Actions](/docs/trading/swapping-api/concepts/chained-actions).
\ No newline at end of file
diff --git a/content/trading/swapping-api/faqs.mdx b/content/trading/swapping-api/faqs.mdx
index fec878d93..415816d68 100644
--- a/content/trading/swapping-api/faqs.mdx
+++ b/content/trading/swapping-api/faqs.mdx
@@ -1,5 +1,5 @@
---
-title: Swapping FAQ
+title: Uniswap API FAQs
description: Find answers to common Uniswap API integration questions about authentication, quotes, routing, rate limits, Permit2 approvals, UniswapX, error handling, fees, and support.
keywords:
- uniswap-api
@@ -21,7 +21,7 @@ faqs:
- question: Is there an OpenAPI / OAS specification I can use to build a client?
answer: "Yes. AI builders can consume the full Open API Specification (OAS) at https://trade-api.gateway.uniswap.org/v1/api.json."
- question: What Permit2 address do I need to whitelist for approvals?
- answer: "The Permit2 address for all chains we support EXCEPT zkSync is: 0x000000000022D473030F116dDEE9F6B43aC78BA3. The Permit2 address for zkSync is: 0x0000000000225e31D15943971F47aD3022F714Fa."
+ answer: Approving the Permit2 contract uses the same contract address across supported chains, with a separate address on zkSync. See the Permit2 FAQ for the canonical contract address and audit details.
- question: What parameter determines if I receive a gasless quote?
answer: |-
When the /quote endpoint's routingPreference is set to BEST_PRICE, the endpoint will attempt to find a quote that nets users the best execution price for a trade. Assuming the protocols are not limited, the endpoint will attempt to get a gasless order and a Uniswap Protocol swap quote, calculate which is currently providing the best price to the user including transaction costs, and return that quote. Integrators of the API who only want gasless quotes may limit the protocols considered to just gasless options (for example UniswapX). There are some scenarios where the API will not be able to get a gasless quote, even if the integrator attempts to force it. The most common reason for this (on chains where UniswapX is supported) is that the gas price of the swap is too high relative to the value of the trade. In cases where the gas cost is 20% or more of the total trade value, the API will always return Uniswap Protocol swap quotes (if permitted by protocols) or fail.
@@ -33,9 +33,9 @@ faqs:
answer: If a quote fails, the response includes helpful information to understand the problem with the request. The most common quote failure reason is that no route can be found for the quoted pair. This can occur for various reasons, including all available routes would exceed the slippage tolerance, insufficient liquidity for the requested quote size, or no available route through the specified protocols. We recommend retrying the quote but modifying one or more parameters of the requested quote (protocols used, slippage allowed, or the size of the swap).
- question: How do I quote the native token?
answer: See the Supported Chains guide for native-token swap details. To quote the native token via UniswapX you must set the x-erc20eth-enabled header in your quote request to true.
- - question: Why am I getting "No Quotes Available" as a response?
+ - question: Why am I getting 404 errors from /quote?
answer: |-
- A quote response with "No Quotes Available" means that the Uniswap router was unable to find a route for the proposed swap. This can happen for a number of reasons, many of which can be easily avoided by understanding the API constraints. While not exhaustive, some of the most common issues are: there is insufficient liquidity to fill the swap; if making a bridge request, the selected token cannot be bridged between the two selected networks; if making a UniswapX-only request, the amount is below 300 USDC equivalent and the UniswapX quote does not improve on the AMM route by at least 0.2%; the request is requesting a bridge and swap (currently not supported).
+ A 404 from /quote means the request passed schema validation, but the router could not return a quote for it. The errorCode field identifies the cause; the full reference, with what to do for each value, is in the Troubleshooting guide. Common causes: insufficient liquidity for the pair (NoRouteFoundError); a UniswapX-only request below the chain's minimum quotable size (QuoteAmountTooLowError); a token that is not routable (UnsupportedTokenError); or a chain not supported for the operation (UnsupportedChainError). Only UpstreamTimeoutError is safe to retry unchanged.
- question: What are the valid values for the protocols field?
answer: "The possible values are V2, V3, V4, UNISWAPX_V2, and UNISWAPX_V3. To perform a swap using only UniswapX protocol liquidity, specify protocols as UNISWAPX_V2 or UNISWAPX_V3. Multiple UniswapX protocols may not be specified in the same request. For more information, please visit Swap Routing."
- question: Can I do a wrap/unwrap through UniswapX?
@@ -83,7 +83,7 @@ faqs:
answer: |-
A Priority quote comes from the PriorityOrderReactor, an older UniswapX auction type that is not currently returned by the API. Today the API returns DutchV2 on Mainnet and DutchV3 on the other supported chains, and it notifies you of the auction type in the quote response. For more information on different auction types, see the auction-types docs.
- question: Which chains and protocol versions does UniswapX support?
- answer: "UniswapX v2 is supported on Mainnet (chain ID 1), Arbitrum (42161), and Base (8453). UniswapX v3 is supported on Arbitrum (42161), Avalanche (43114), Base (8453), BNB Smart Chain (56), Robinhood Chain (4663), Tempo (4217), and Unichain (130). If you submit a quote request with protocols set to UNISWAPX_V2 or UNISWAPX_V3 on a chain not listed above, the request will fail. Most integrators do not need to set protocols and can let the API select the best route."
+ answer: "UniswapX v2 is supported on Mainnet (chain ID 1), Arbitrum (42161), and Base (8453). UniswapX v3 is supported on Arbitrum (42161), Arc (5042), Avalanche (43114), Base (8453), BNB Smart Chain (56), Ink (57073), Monad (143), Robinhood Chain (4663), Tempo (4217), and Unichain (130). If you submit a quote request with protocols set to UNISWAPX_V2 or UNISWAPX_V3 on a chain not listed above, the request will fail. Most integrators do not need to set protocols and can let the API select the best route."
- question: Are there restrictions on how I can integrate the API?
answer: The API is free to integrate into any application including whitelabeled swap experiences, wallets, mobile apps, and more. You are responsible for ensuring that your integration complies with the API Terms of Use. We are flexible regarding how you decide to offer the API through your application. Developers may create a whitelabel swap experience, add swapping to a custodial wallet, integrate the APIs into a mobile application, and more.
- question: Can I restrict token pairs available to my users?
@@ -97,7 +97,7 @@ faqs:
- question: Does Uniswap take positive slippage as fees?
answer: No. Uniswap Labs never takes positive slippage. All price improvement achieved at execution is for the benefit of the end swapper.
- question: How do I submit a ticket?
- answer: Use the Uniswap API help form to reach the team without leaving this page. Note that we are unable to provide technical assistance with troubleshooting your code, deployment, or workflow.
+ answer: Use the Help Center to reach the team without leaving this page. Note that we are unable to provide technical assistance with troubleshooting your code, deployment, or workflow.
- question: What information should I include when reporting an API issue to support?
answer: "When reporting issues, include: Request ID from API response, Full request/response payloads (sanitize sensitive data), Chain ID and transaction hash (if applicable), Timestamp of the request."
- question: Is there a sandbox environment?
@@ -115,7 +115,7 @@ Use this page to find answers to the questions Uniswap API integrators ask most
- Integration of the API can be done in less than two weeks. We provide [sample code](/docs/trading/swapping-api/swapping-code-examples) to help get you off the ground quickly. To get started, reach out to request an API key. If you are not yet in touch with Uniswap Labs, register your interest in integrating the API through the [Uniswap Developer Platform](https://developers.uniswap.org/dashboard/welcome).
+ Integration of the API can be done in less than two weeks. We provide [sample code](/docs/trading/swapping-api/start-building/swapping-code-examples) to help get you off the ground quickly. To get started, reach out to request an API key. If you are not yet in touch with Uniswap Labs, register your interest in integrating the API through the [Uniswap Developer Platform](https://developers.uniswap.org/dashboard/welcome).
@@ -167,9 +167,7 @@ Use this page to find answers to the questions Uniswap API integrators ask most
- The Permit2 address for all chains we support **EXCEPT** zkSync is: `0x000000000022D473030F116dDEE9F6B43aC78BA3`.
-
- The Permit2 address for zkSync is: `0x0000000000225e31D15943971F47aD3022F714Fa`.
+ Approving the Permit2 contract uses the same contract address across supported chains, with a separate address on zkSync. See the [Permit2 FAQ](/docs/protocols/permit2/overview#faq) for the canonical contract address and audit details.
@@ -237,15 +235,14 @@ Use this page to find answers to the questions Uniswap API integrators ask most
- Why am I getting "No Quotes Available" as a response?
+ Why am I getting 404 errors from `/quote`?
- A quote response with "No Quotes Available" means that the Uniswap router was unable to find a route for the proposed swap. This can happen for a number of reasons, many of which can be easily avoided by understanding the API constraints. While not exhaustive, some of the most common issues are:
- * There is insufficient liquidity to fill the swap
+ A 404 from `/quote` means the request passed schema validation, but the router could not return a quote for it. The `errorCode` field identifies the cause; the full reference, with what to do for each value, is in [Troubleshooting Common Errors](/docs/trading/swapping-api/common-errors#404-no-quotes-available). Common causes include:
+ * There is insufficient liquidity to fill the swap (`errorCode: NoRouteFoundError`)
* If making a bridge request, the selected token cannot be bridged between the two selected networks (check [Supported Bridges](/docs/api-reference/get_swappable_tokens))
- * If making a UniswapX-only request, the amount is below 300 USDC equivalent and the UniswapX quote does not improve on the AMM route by at least 0.2% (see [Supported Chains](/docs/trading/swapping-api/supported-chains#uniswapx-chain-support))
- * The request is requesting a bridge and swap (currently not supported)
+ * If making a UniswapX-only request, the amount is below the chain's minimum quotable size (`errorCode: QuoteAmountTooLowError`; see [Supported Chains](/docs/trading/swapping-api/supported-chains#uniswapx-chain-support))
@@ -529,7 +526,7 @@ Use this page to find answers to the questions Uniswap API integrators ask most
- UniswapX v2 is supported on Mainnet (chain ID 1), Arbitrum (42161), and Base (8453). UniswapX v3 is supported on Arbitrum (42161), Avalanche (43114), Base (8453), BNB Smart Chain (56), Robinhood Chain (4663), Tempo (4217), and Unichain (130).
+ UniswapX v2 is supported on Mainnet (chain ID 1), Arbitrum (42161), and Base (8453). UniswapX v3 is supported on Arbitrum (42161), Arc (5042), Avalanche (43114), Base (8453), BNB Smart Chain (56), Ink (57073), Monad (143), Robinhood Chain (4663), Tempo (4217), and Unichain (130).
If you submit a quote request with `protocols` set to `UNISWAPX_V2` or `UNISWAPX_V3` on a chain not listed above, the request will fail. Most integrators do not need to set `protocols` and can let the API select the best route.
@@ -616,7 +613,7 @@ Use this page to find answers to the questions Uniswap API integrators ask most
- Use the Uniswap API help form to reach the team without leaving this page. Note that we are unable to provide technical assistance with troubleshooting your code, deployment, or workflow.
+ Use the Help Center to reach the team without leaving this page. Note that we are unable to provide technical assistance with troubleshooting your code, deployment, or workflow.
diff --git a/content/trading/swapping-api/getting-started.mdx b/content/trading/swapping-api/getting-started.mdx
index 14773ea99..6854c282f 100644
--- a/content/trading/swapping-api/getting-started.mdx
+++ b/content/trading/swapping-api/getting-started.mdx
@@ -1,5 +1,6 @@
---
title: Swapping via the Uniswap API
+sidebarTitle: Overview
description: High-level overview of swapping through the Uniswap API
---
@@ -21,10 +22,12 @@ The diagram below is an illustration of the token swap flow where steps in gray
-If using UniswapX protocols, quote requests require a minimum of 300 USDC equivalent on all supported chains. Below that, UniswapX is included only when its quote improves on the AMM route by at least 0.2%.
+If using UniswapX protocols, quote requests must meet a per-chain minimum quotable size. Below that, UniswapX is included only when its quote improves on the AMM route by at least 0.2%.
-Requests that meet neither condition will return "No quotes available." See [Supported Chains](/docs/trading/swapping-api/supported-chains#uniswapx-chain-support) for details.
+Requests that meet neither condition return a 404 with `errorCode: QuoteAmountTooLowError`. See [Supported Chains](/docs/trading/swapping-api/supported-chains#uniswapx-chain-support) for details.
For full request and response schemas for each endpoint, see the [API Reference](/docs/api-reference).
+
+For developer support, reach out to our team through the
Help Center.
diff --git a/content/trading/swapping-api/images/permissioned-token-gating.png b/content/trading/swapping-api/images/permissioned-token-gating.png
new file mode 100644
index 000000000..3f8a67ac8
Binary files /dev/null and b/content/trading/swapping-api/images/permissioned-token-gating.png differ
diff --git a/content/trading/swapping-api/meta.json b/content/trading/swapping-api/meta.json
index 1ef124c66..b5990fa51 100644
--- a/content/trading/swapping-api/meta.json
+++ b/content/trading/swapping-api/meta.json
@@ -1,18 +1,13 @@
{
- "title": "Swapping",
- "pages": [
- "getting-started",
- "concepts",
- "supported-chains",
- "integration-guide",
- "agent-attribution",
- "chained-actions",
- "chained-actions-integration",
- "amm-vs-uniswapx-routing",
- "swapping-code-examples",
- "building-prerequisites",
- "common-errors",
- "faqs"
- ]
+ "title": "Uniswap API",
+ "pages": [
+ "getting-started",
+ "supported-chains",
+ "concepts",
+ "start-building",
+ "amm-vs-uniswapx-routing",
+ "swapping-permissioned-pools",
+ "common-errors",
+ "faqs"
+ ]
}
-
\ No newline at end of file
diff --git a/content/trading/swapping-api/agent-attribution.mdx b/content/trading/swapping-api/start-building/agent-attribution.mdx
similarity index 78%
rename from content/trading/swapping-api/agent-attribution.mdx
rename to content/trading/swapping-api/start-building/agent-attribution.mdx
index 168ad2f67..c0782c07f 100644
--- a/content/trading/swapping-api/agent-attribution.mdx
+++ b/content/trading/swapping-api/start-building/agent-attribution.mdx
@@ -1,5 +1,6 @@
---
title: Agent Attribution (X-Agent-Info)
+sidebarTitle: Agent Attribution
description: Send the optional X-Agent-Info header to attribute agent-driven Trading API traffic, and check x-agent-info-status to confirm it was recognized.
---
@@ -13,12 +14,12 @@ The Uniswap API accepts an optional `X-Agent-Info` request header. Send it if an
## Sending the header
-Send `X-Agent-Info` alongside your usual [authentication](/docs/trading/swapping-api/integration-guide#authentication) headers, with a JSON object value containing up to three fields:
+Send `X-Agent-Info` alongside your usual [authentication](/docs/trading/swapping-api/start-building/integration-guide#authentication) headers, with a JSON object value containing up to three fields:
| Field | Type | Required | Notes |
| --- | --- | --- | --- |
| `decision_origin` | string | Yes | Must be exactly `autonomous` or `human_mediated` (case-sensitive). Any other value marks the header malformed. |
-| `integration_name` | string | No | Name of your integration or agent, e.g. `my-trading-bot`. Up to 256 UTF-16 code units — JavaScript's `String#length`. |
+| `integration_name` | string | No | Name of your integration or agent, e.g. `my-trading-bot`. Up to 256 UTF-16 code units, which is JavaScript's `String#length`. |
| `version` | string | No | Version identifier for your integration. Up to 256 UTF-16 code units. |
Send only these three fields. Any other key is dropped rather than rejected, so an extra key never makes the header malformed.
@@ -30,32 +31,33 @@ Send only these three fields. Any other key is dropped rather than rejected, so
curl -X POST https://trade-api.gateway.uniswap.org/v1/quote \
-H "x-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
+ -H "Accept: application/json" \
-H 'X-Agent-Info: {"decision_origin":"autonomous","integration_name":"my-trading-bot","version":"1.4.0"}' \
-d '{"tokenIn":"0x...","tokenOut":"0x...","tokenInChainId":1,"tokenOutChainId":1,"type":"EXACT_INPUT","amount":"1000000","swapper":"0x...","slippageTolerance":0.5}'
```
## What makes a header malformed
-A header is dropped (marked malformed) rather than rejected outright if any of the following hold. The request is handled exactly as if the header were absent — see [Confirming it was received](#confirming-it-was-received) below for how to tell the difference.
+A header is dropped (marked malformed) rather than rejected outright if any of the following hold. The request is handled exactly as if the header were absent. See [Confirming it was received](#confirming-it-was-received) below for how to tell the difference.
- The raw header value is larger than **1024 bytes**, measured on the raw value before parsing. JSON whitespace and `\u` escapes count toward the cap.
- The raw header value contains any byte outside printable US-ASCII (`0x20`–`0x7E`). This is checked first, before the JSON is parsed, because bytes above `0x7E` decode differently in different HTTP stacks. So a literal `é`, an emoji, or a curly quote in the header marks it malformed no matter how short the value is. Send non-ASCII as a JSON `\u` escape instead.
- The value isn't valid JSON, or is valid JSON that isn't a plain object (an array, string, number, boolean, or `null`).
-- The request carried two or more `X-Agent-Info` header lines. They are joined with `", "`, which is almost never valid JSON. Set the header once rather than appending to it — some HTTP clients append by default.
+- The request carried two or more `X-Agent-Info` header lines. They are joined with `", "`, which is almost never valid JSON. Set the header once rather than appending to it, since some HTTP clients append by default.
- `decision_origin` is missing, or is anything other than exactly `autonomous` or `human_mediated`.
- `integration_name` or `version` is present but isn't a string, or is longer than 256 UTF-16 code units. That count is JavaScript's `String#length`, so an emoji or other astral character costs two units, not one.
- `integration_name` or `version` contains a disallowed character. Those are control characters (C0 `0x00`–`0x1F`, DEL `0x7F`, C1 `0x80`–`0x9F`), the Unicode line separators U+2028 and U+2029, and the replacement character U+FFFD. An escaped unpaired surrogate decodes to U+FFFD, so it is rejected too. Text pasted from a PDF, or left behind by a lossy re-encode, often carries one of these invisibly.
-Not sending the header at all, or sending it with an empty value, isn't an error condition — both are simply "no attribution," the same outcome as a header that's out of scope for your client.
+Not sending the header at all isn't an error condition. It's simply "no attribution," the same outcome as a header that's out of scope for your client.
## Confirming it was received
Because the request succeeds regardless of whether `X-Agent-Info` parsed, check the `x-agent-info-status` response header to confirm your header was actually recognized:
-- **`x-agent-info-status: malformed`** — the header was received but failed one of the checks above and was dropped. The value is always the fixed string `malformed`; it never echoes anything from your request.
-- **No `x-agent-info-status` header at all** — your `X-Agent-Info` header parsed, or you didn't send one.
+- **`x-agent-info-status: malformed`**: the header was received but failed one of the checks above and was dropped. The value is always the fixed string `malformed`; it never echoes anything from your request.
+- **No `x-agent-info-status` header at all**: your `X-Agent-Info` header parsed, or you didn't send one.
-The gateway sets this header after it routes your request, and before it writes its own response. Error responses carry it too — a 400, a 401, a 403, a 429, and a 404 for a path that does not exist. So you can debug the header without first getting a working quote. A CORS preflight carries no status header, because the gateway answers it before it looks at `X-Agent-Info`.
+The gateway sets this header after it routes your request, and before it writes its own response. Error responses carry it too: a 400, a 401, a 403, a 429, and a 404 for a path that does not exist. So you can debug the header without first getting a working quote. A CORS preflight carries no status header, because the gateway answers it before it looks at `X-Agent-Info`.
Call the Trading API server-to-server. The gateway sends CORS headers only to a small allow-list of origins, so a browser page on your own domain cannot read this header. Check it from a server or with curl.
@@ -65,6 +67,7 @@ const response = await fetch('https://trade-api.gateway.uniswap.org/v1/quote', {
headers: {
'x-api-key': 'YOUR_API_KEY',
'Content-Type': 'application/json',
+ Accept: 'application/json',
'X-Agent-Info': JSON.stringify({
decision_origin: 'autonomous',
integration_name: 'my-trading-bot',
@@ -84,7 +87,7 @@ const response = await fetch('https://trade-api.gateway.uniswap.org/v1/quote', {
});
if (response.headers.get('x-agent-info-status') === 'malformed') {
- // Received but dropped — check field names, decision_origin value, and length limits above.
+ // Received but dropped. Check field names, decision_origin value, and length limits above.
console.warn('X-Agent-Info was sent but not recognized.');
}
diff --git a/content/trading/swapping-api/chained-actions-integration.mdx b/content/trading/swapping-api/start-building/chained-actions-integration.mdx
similarity index 93%
rename from content/trading/swapping-api/chained-actions-integration.mdx
rename to content/trading/swapping-api/start-building/chained-actions-integration.mdx
index 693d496a2..25e24bc69 100644
--- a/content/trading/swapping-api/chained-actions-integration.mdx
+++ b/content/trading/swapping-api/start-building/chained-actions-integration.mdx
@@ -1,11 +1,12 @@
---
title: Chained Actions Integration Guide
+sidebarTitle: Chained Actions Swap Guide
description: Build cross-chain and multi-step swaps with the Uniswap Trading API plan endpoints, with cURL examples and the full execution loop.
---
-This guide is the operational counterpart to [Swapping with Chained Actions](/docs/trading/swapping-api/chained-actions). When `/quote` returns `"routing": "CHAINED"`, you drive the trade through the `/plan` endpoints as an ordered sequence of steps under one `planId`.
+This guide is the operational counterpart to [Swapping with Chained Actions](/docs/trading/swapping-api/concepts/chained-actions). When `/quote` returns `"routing": "CHAINED"`, you drive the trade through the `/plan` endpoints as an ordered sequence of steps under one `planId`.
-For conceptual background (plans, steps, the state machine, and routing patterns), read the [concepts page](/docs/trading/swapping-api/chained-actions). For full request and response schemas, see the [API Reference](/docs/api-reference). AI builders can consume the full OpenAPI Specification at [https://trade-api.gateway.uniswap.org/v1/api.json](https://trade-api.gateway.uniswap.org/v1/api.json).
+For conceptual background (plans, steps, the state machine, and routing patterns), read the [concepts page](/docs/trading/swapping-api/concepts/chained-actions). For full request and response schemas, see the [API Reference](/docs/api-reference). AI builders can consume the full OpenAPI Specification at [https://trade-api.gateway.uniswap.org/v1/api.json](https://trade-api.gateway.uniswap.org/v1/api.json).
## Endpoints
@@ -195,7 +196,7 @@ Scan the steps array for `STEP_ERROR` rather than assuming which index failed. T
`slippageTolerance` is the value set on the `/quote` request, or the API default if you omit it. It governs the AMM swap steps in a plan. It is fixed at quote time and applied to each swap step independently, not as a single end-to-end guarantee. For an S→B→S plan at 0.5%, each swap applies 0.5% on its own, so the combined deviation across both swaps can exceed 0.5%. Slippage cannot be changed after a plan is created. If no valid swap route exists within tolerance, the step fails with no automatic recovery.
-The bridge step is not an AMM swap. It is quoted through the bridge provider (Across Protocol) when the plan is built, so `slippageTolerance` does not apply to it. The bridge runs as a `SEND_TX` step alongside approvals and swaps (see the [execution flow](/docs/trading/swapping-api/chained-actions#execution-flow)), but only the swap steps have a slippage tolerance band.
+The bridge step is not an AMM swap. It is quoted through the bridge provider (Across Protocol) when the plan is built, so `slippageTolerance` does not apply to it. The bridge runs as a `SEND_TX` step alongside approvals and swaps (see the [execution flow](/docs/trading/swapping-api/concepts/chained-actions#execution-flow)), but only the swap steps have a slippage tolerance band.
## Gas
@@ -210,7 +211,7 @@ Gas applies only to `SEND_TX` steps (approvals, swaps, and bridges). `SIGN_MSG`
## API Reference
-For full request and response schemas, see the [API Reference](/docs/api-reference). For conceptual background, see [Swapping with Chained Actions](/docs/trading/swapping-api/chained-actions).
+For full request and response schemas, see the [API Reference](/docs/api-reference). For conceptual background, see [Swapping with Chained Actions](/docs/trading/swapping-api/concepts/chained-actions).
## Support
diff --git a/content/trading/swapping-api/integration-guide.mdx b/content/trading/swapping-api/start-building/integration-guide.mdx
similarity index 90%
rename from content/trading/swapping-api/integration-guide.mdx
rename to content/trading/swapping-api/start-building/integration-guide.mdx
index 3c4ff7673..c8094fa76 100644
--- a/content/trading/swapping-api/integration-guide.mdx
+++ b/content/trading/swapping-api/start-building/integration-guide.mdx
@@ -1,11 +1,12 @@
---
title: Swapping API Integration Guide
+sidebarTitle: Standard Swap Guide
description: Build swapping integrations with the Uniswap API using this practical step-by-step guide.
---
-This guide covers single-transaction swaps. When `/quote` returns `"routing": "CHAINED"` (a trade that crosses chains or needs more than one step), drive execution through the `/plan` endpoints instead. See the [Chained Actions Integration Guide](/docs/trading/swapping-api/chained-actions-integration).
+This guide covers single-transaction swaps. When `/quote` returns `"routing": "CHAINED"` (a trade that crosses chains or needs more than one step), drive execution through the `/plan` endpoints instead. See the [Chained Actions Integration Guide](/docs/trading/swapping-api/start-building/chained-actions-integration).
@@ -48,9 +49,9 @@ const quote = await response.json();
AI builders can consume the full Open API Specification (OAS) at [https://trade-api.gateway.uniswap.org/v1/api.json](https://trade-api.gateway.uniswap.org/v1/api.json).
-If your integration is built or operated by an AI agent, also consider sending the optional [`X-Agent-Info` attribution header](/docs/trading/swapping-api/agent-attribution) alongside your request.
+If your integration is built or operated by an AI agent, also consider sending the optional [`X-Agent-Info` attribution header](/docs/trading/swapping-api/start-building/agent-attribution) alongside your request.
-Full code examples for completing a basic swap workflow are available in [Swapping Code Examples](/docs/trading/swapping-api/swapping-code-examples).
+Full code examples for completing a basic swap workflow are available in [API Swapping Code Examples](/docs/trading/swapping-api/start-building/swapping-code-examples).
## Architecture
@@ -79,8 +80,7 @@ Your integration must include:
- **RPC Provider**: Connection to blockchain nodes (ex. Infura, Alchemy, or self-hosted)
- **Web3 Library**: ethers.js, viem, or web3.js for transaction signing
- **Wallet Integration**: Uniswap Wallet, MetaMask, or similar for user signing
-
-See the [Build Prerequisites](/docs/trading/swapping-api/building-prerequisites) for more details.
+- **API Key Handling**: Store your Uniswap API key server-side and attach it to requests over HTTPS. Do not ship it in front-end code; proxy calls through your own backend so the key is never exposed to users.
### Data flow
@@ -333,13 +333,13 @@ interface ErrorResponse {
#### No quotes available
-**Cause**: No route found for the requested swap
+**Cause**: identified by the `errorCode` field on the 404 body (see the [full reference](/docs/trading/swapping-api/common-errors#404-no-quotes-available))
**Solutions**:
-- Verify token addresses are correct and on the specified chain
-- Check chains are available for selected protocol (note [limited chain support for UniswapX](/docs/trading/swapping-api/supported-chains))
-- Try different protocols or routing preferences
-- Reduce trade size
+- Handle the 404 by `errorCode`: only `UpstreamTimeoutError` can succeed on an unchanged retry; all other values indicate the request must be modified
+- Verify token addresses are correct and on the specified chain (`UnsupportedTokenError`, `NoRouteFoundError`)
+- Check chains are available for the selected protocol (`UniswapXNotSupportedOnChainError`; note [limited chain support for UniswapX](/docs/trading/swapping-api/supported-chains))
+- Increase trade size for UniswapX minimums (`QuoteAmountTooLowError`)
#### Validation error
@@ -476,7 +476,7 @@ Balance protection vs execution success:
### Error recovery
-If a quote fails, read the error message to address the specific error cause. If the quote fails due to no quotes available, implement retry logic with exponential backoff:
+If a quote fails with a 404, use the `errorCode` field to address the specific cause (see the [errorCode reference](/docs/trading/swapping-api/common-errors#404-no-quotes-available)). Only retry when `errorCode` is `UpstreamTimeoutError` (or, cautiously, `ResourceNotFound`) — every other cause is deterministic and will fail again unchanged. Retry with exponential backoff:
```typescript
async function fetchQuoteWithRetry(
@@ -642,11 +642,11 @@ The API does not return every field that some libraries expect to generate an EI
- **`UNISWAPX_V2`**: Mainnet, Arbitrum, Base only
-- **`UNISWAPX_V3`**: Arbitrum, Avalanche, Base, BNB Smart Chain, Robinhood Chain, Tempo, Unichain
-- **UniswapX minimum**: 300 USDC equivalent on all supported chains
+- **`UNISWAPX_V3`**: Arbitrum, Arc, Avalanche, Base, BNB Smart Chain, Ink, Monad, Robinhood Chain, Tempo, Unichain
+- **UniswapX minimum**: a per-chain minimum quotable size (see [Supported Chains](/docs/trading/swapping-api/supported-chains#uniswapx-chain-support))
- **Native token swaps**: UniswapX for native token input only when the `x-erc20eth-enabled` header is set to `true` on `/quote` and `/order`
-Requests below the minimum threshold will return "No quotes available." See [Supported Chains](/docs/trading/swapping-api/supported-chains#uniswapx-chain-support) for details.
+Requests below the minimum threshold return a 404 with `errorCode: QuoteAmountTooLowError`. See [Supported Chains](/docs/trading/swapping-api/supported-chains#uniswapx-chain-support) for details.
diff --git a/content/trading/swapping-api/start-building/meta.json b/content/trading/swapping-api/start-building/meta.json
new file mode 100644
index 000000000..2ee5ab081
--- /dev/null
+++ b/content/trading/swapping-api/start-building/meta.json
@@ -0,0 +1,4 @@
+{
+ "title": "Start building",
+ "pages": ["integration-guide", "agent-attribution", "chained-actions-integration", "swapping-code-examples"]
+}
diff --git a/content/trading/swapping-api/swapping-code-examples.mdx b/content/trading/swapping-api/start-building/swapping-code-examples.mdx
similarity index 100%
rename from content/trading/swapping-api/swapping-code-examples.mdx
rename to content/trading/swapping-api/start-building/swapping-code-examples.mdx
diff --git a/content/trading/swapping-api/supported-chains.mdx b/content/trading/swapping-api/supported-chains.mdx
index 506664290..a65e601c3 100644
--- a/content/trading/swapping-api/supported-chains.mdx
+++ b/content/trading/swapping-api/supported-chains.mdx
@@ -9,37 +9,40 @@ The following chains are supported for swapping. **Note the router address, whic
For the avoidance of any doubt, the most up to date list of routers is available in GitHub [here](https://github.com/Uniswap/sdks/blob/main/sdks/universal-router-sdk/src/utils/constants.ts).
-
-| Chain ID | Chain Name | Universal Router 2.0 Address | Universal Router 2.1.1 Address | UniswapX Support |
-| :------------------- | :------------------------- | :----------------------------------------- | :----------------------------------------- | :------- |
-| 1 | Mainnet (Ethereum) | 0x66a9893cc07d91d95644aedd05d03f95e1dba8af | 0x4c82d1fbfe28c977cbb58d8c7ff8fcf9f70a2cca | Yes |
-| 10 | OP Mainnet | 0x851116d9223fabed8e56c0e6b8ad0c31d98b3507 | 0x8b844f885672f333bc0042cb669255f93a4c1e6b | |
-| 56 | BNB Smart Chain | 0x1906c1d672b88cd1b9ac7593301ca990f94eae07 | 0x8b844f885672f333bc0042cb669255f93a4c1e6b | Yes |
-| 130 | Unichain | 0xef740bf23acae26f6492b10de645d6b98dc8eaf3 | 0xfdf682f51fe81aa4898f0ae2163d8a55c127fbc7 | |
-| 137 | Polygon | 0x1095692a6237d83c6a72f3f5efedb9a670c49223 | 0x8b844f885672f333bc0042cb669255f93a4c1e6b | |
-| 143 | Monad | 0x0d97dc33264bfc1c226207428a79b26757fb9dc3 | 0xfdf682f51fe81aa4898f0ae2163d8a55c127fbc7 | |
-| 196 | X Layer | 0x5507749f2c558bb3e162c6e90c314c092e7372ff | 0x8b844f885672f333bc0042cb669255f93a4c1e6b | |
-| 324 | zkSync | 0x28731BCC616B5f51dD52CF2e4dF0E78dD1136C06 | | |
-| 480 | World Chain | 0x8ac7bee993bb44dab564ea4bc9ea67bf9eb5e743 | 0x8b844f885672f333bc0042cb669255f93a4c1e6b | |
-| 1868 | Soneium | 0x0e2850543f69f678257266e0907ff9a58b3f13de | 0x8b844f885672f333bc0042cb669255f93a4c1e6b | |
-| 4217 | Tempo | 0x1febb76be10aaf3a1402f04e8e835f2c382f7914 | 0xfdf682f51fe81aa4898f0ae2163d8a55c127fbc7 | Yes |
-| 4326 | MegaETH | 0x48fd03529d2a91be835f07f6b72f53b4aad6093d | 0x47837eb80db5908eabba9105626d9b348bea7b02 | |
-| 4663 | Robinhood Chain | | 0x8876789976decbfcbbbe364623c63652db8c0904 | Yes |
-| 8453 | Base | 0x6ff5693b99212da76ad316178a184ab56d299b43 | 0xfdf682f51fe81aa4898f0ae2163d8a55c127fbc7 | Yes |
-| 42161 | Arbitrum | 0xa51afafe0263b40edaef0df8781ea9aa03e381a3 | 0x8b844f885672f333bc0042cb669255f93a4c1e6b | Yes |
-| 42220 | Celo | 0xcb695bc5D3Aa22cAD1E6DF07801b061a05A0233A | 0x8b844f885672f333bc0042cb669255f93a4c1e6b | |
-| 43114 | Avalanche | 0x94b75331ae8d42c1b61065089b7d48fe14aa73b7 | 0x8b844f885672f333bc0042cb669255f93a4c1e6b | Yes |
-| 57073 | Ink | 0x112908dac86e20e7241b0927479ea3bf935d1fa0 | 0x28bd21bb4ea4fda370d8d7544992038375d8d456 | |
-| 59144 | Linea | 0x661e93cca42afacb172121ef892830ca3b70f08d | 0x8b844f885672f333bc0042cb669255f93a4c1e6b | |
-| 7777777 | Zora | 0x3315ef7ca28db74abadc6c44570efdf06b04b020 | 0xfdf682f51fe81aa4898f0ae2163d8a55c127fbc7 | |
-| **Testnets** | | | | |
-| 1301 | Unichain Sepolia (Testnet) | 0xf70536b3bcc1bd1a972dc186a2cf84cc6da6be5d | 0x8b844f885672f333bc0042cb669255f93a4c1e6b | |
-| 84532 | Base Sepolia (Testnet) | 0x492e6456d9528771018deb9e87ef7750ef184104 | 0x8b844f885672f333bc0042cb669255f93a4c1e6b | |
-| 11155111 | Ethereum Sepolia (Testnet) | 0x3a9d48ab9751398bbfa63ad67599bb04e4bdf98b | 0xed4885c9a52c23312facbf9d5aff409779e1babc | |
+Support for Universal Router 2.0 and 2.1.1 ends on October 21, 2026. See [Sunset of Universal Router 2.0 and 2.1.1](/docs/changelog/active-notifications/sunset-of-universal-router-2-0-and-2-1-1).
+
+
+| Chain ID | Chain Name | Universal Router 2.1.2 Address | UniswapX Support |
+| :------------------- | :------------------------- | :----------------------------------------- | :--------------- |
+| 1 | Mainnet (Ethereum) | 0x23617e59A5925b2A4Bf75d73ff6711cD0b29De85 | Yes |
+| 10 | OP Mainnet | 0xC09255D86DB563cBc11C2fCf4a0C512e160111B4 | |
+| 56 | BNB Smart Chain | 0xDc264714F68d84CF29BC605589405E78bDBE7C9f | Yes |
+| 130 | Unichain | 0xD1b797D92d87B688193A2B976eFc8D577D204343 | Yes |
+| 137 | Polygon | 0xDc264714F68d84CF29BC605589405E78bDBE7C9f | |
+| 143 | Monad | 0xa6CE4F10d83dBdDAc17E68e1837ca9cE6a1b596e | Yes |
+| 196 | X Layer | 0x1cd182C94fcF42277B80DBB9060F88024809E61E | |
+| 324 | zkSync | (See note below) | |
+| 480 | World Chain | 0xF025e0Fe9E331A0eF05c2ad3C4E9C64b625cda6f | |
+| 1868 | Soneium | 0x661E93cca42AfacB172121EF892830cA3b70F08d | |
+| 4217 | Tempo | 0x182a927119D56008d921126764bF884221b10f59 | Yes |
+| 4326 | MegaETH | 0xAedd1CF4C14e833140A61E9C0d2b73a64795c823 | |
+| 4663 | Robinhood Chain | 0x204FAca1764B154221e35c0d20aBb3c525710498 | Yes |
+| 5042 | Arc | 0x8702463e73f74d0b6765aBceb314Ef07aCb92650 | Yes |
+| 8453 | Base | 0xd6145b2D3F379919E8CdEda7B97e37c4b2Ca9c40 | Yes |
+| 42161 | Arbitrum | 0x2d01411773c8C24805306E89A41F7855C3c4Fe65 | Yes |
+| 42220 | Celo | 0xe2023F3FA515cF070e07fD9d51c1d236e07843f4 | |
+| 43114 | Avalanche | 0x661E93cca42AfacB172121EF892830cA3b70F08d | Yes |
+| 57073 | Ink | 0x661E93cca42AfacB172121EF892830cA3b70F08d | Yes |
+| 59144 | Linea | 0xDc264714F68d84CF29BC605589405E78bDBE7C9f | |
+| 7777777 | Zora | 0xF025e0Fe9E331A0eF05c2ad3C4E9C64b625cda6f | |
+| **Testnets** | | | |
+| 1301 | Unichain Sepolia (Testnet) | 0xDf38F24fE153761634Be942F9d859f3DBA857E95 | |
+| 84532 | Base Sepolia (Testnet) | 0x8702463e73f74d0b6765aBceb314Ef07aCb92650 | |
+| 11155111 | Ethereum Sepolia (Testnet) | 0x7E4f6c5e954Da5c61B3423D81E2277431Ac043f3 | |
-Only Ethereum Sepolia and Unichain Sepolia are available as testnets on the [Uniswap web interface](https://app.uniswap.org). All listed testnets are accessible via the API.
+Only Ethereum Sepolia and Unichain Sepolia are available as testnets on the [Uniswap web interface](https://app.uniswap.org). All listed testnets above are accessible via the API.
@@ -49,27 +52,46 @@ The Trading API builds swap calldata for a specific Universal Router version. Se
### Default version
-When you do not send the `x-universal-router-version` header, the API defaults to Universal Router `2.0` on most chains. Some chains default to `2.1.1`, such as Robinhood Chain and Ink, so you do not need to set the header there to get `2.1.1`.
+When you do not send the `x-universal-router-version` header, the API defaults to Universal Router `2.1.2` on every chain that has a 2.1.2 deployment. zkSync has no 2.1.2 and runs `2.0` only. zkSync's 2.0 Universal Router address is `0x28731BCC616B5f51dD52CF2e4dF0E78dD1136C06`.
-You can always set the header explicitly. Requesting a version a chain does not support returns an error, for example `2.0` on Robinhood Chain, which has no `2.0` deployment.
+You can always set the header explicitly. Requesting a version a chain does not support returns an error, for example `2.0` on Robinhood Chain and Arc, neither of which has a `2.0` deployment.
-The supported chains table above shows which versions each chain runs. zkSync supports `2.0` only. **The default can change over time, so set the header explicitly when you need a stable target.**
+The table above lists the 2.1.2 address for each chain. **The default can change over time, so set the header explicitly when you need a stable target.**
### SDK compatibility for decoding calldata
-If you decode the calldata the API returns with the [Universal Router SDK](https://github.com/Uniswap/sdks/tree/main/sdks/universal-router-sdk), your `@uniswap/universal-router-sdk` version must support the Universal Router version used for the request. Decoding with an older version can fail or produce incorrect results.
+If you decode the calldata the API returns with the [Universal Router SDK](https://github.com/Uniswap/sdks/tree/main/sdks/universal-router-sdk), your `@uniswap/universal-router-sdk` version must support the Universal Router version used for the request, and you must pass the matching `UniversalRouterVersion` to `CommandParser.parseCalldata`. Decoding with an older version, or without the version argument, can fail or produce incomplete results. If you submit the returned calldata onchain and never decode it yourself, only the header matters.
-Use at least the SDK version that introduced support for the router version you decode:
+Use at least the SDK version that introduced support for the router version you decode, and pass its `UniversalRouterVersion` member to the parser:
-| Universal Router version | Minimum `@uniswap/universal-router-sdk` |
-| :--- | :--- |
-| 2.0 | 3.1.0 |
-| 2.1.1 | 5.9.0 |
-| 2.2.0 | 5.9.0 |
+| Universal Router version | `UniversalRouterVersion` | Minimum `@uniswap/universal-router-sdk` |
+| :--- | :--- | :--- |
+| 2.0 | `V2_0` | 3.1.0 |
+| 2.1.1 | `V2_1_1` | 5.9.0 |
+| 2.1.2 | `V2_1_2` | 5.12.0 |
+| 2.2.0 | `V2_2_0` | 5.12.0 |
+
+Versions 5.12.0 and later are the first to resolve 2.1.2, and the first to carry the current 2.2.0 addresses. Earlier releases resolve 2.2.0 to a deployment that was replaced, so do not use them for that version.
+
+From 2.1.1 onward, the V2 and V3 swap commands carry an extra `minHopPriceX36` per-hop slippage array, and the v4 swap actions have the same field. SDK 5.9.0 is the first release whose parser decodes that array and the first whose `parseCalldata` accepts a `UniversalRouterVersion` argument, which defaults to `V2_0`. Older SDKs may parse newer calldata without an error but drop `minHopPriceX36`, so your validation can be incomplete even when it appears to succeed.
+
+```typescript
+import { CommandParser, UniversalRouterVersion } from '@uniswap/universal-router-sdk'
+
+// `calldata` is the value returned by the /swap response.
+// The version you pass must match the x-universal-router-version header you sent.
+
+// Defaults to V2_0. On 2.1.1 and later calldata the per-hop slippage array is
+// silently dropped, and on SDK < 5.9.0 there is no version argument to fix it.
+const parsedWrong = CommandParser.parseCalldata(calldata)
+
+// SDK >= 5.12.0: pass the matching version so 2.1.2 calldata decodes fully.
+const parsed = CommandParser.parseCalldata(calldata, UniversalRouterVersion.V2_1_2)
+```
Track the [SDK releases](https://github.com/Uniswap/sdks/releases) so your decoder stays compatible when the router version changes. The current mapping lives in the SDK [constants file](https://github.com/Uniswap/sdks/blob/main/sdks/universal-router-sdk/src/utils/constants.ts).
@@ -80,7 +102,7 @@ UniswapX is available on the following chains:
| Protocol | Supported Chains |
| :--- | :--- |
| UniswapX V2 | Mainnet (1), Arbitrum (42161), Base (8453) |
-| UniswapX V3 | Arbitrum (42161), Avalanche (43114), Base (8453), BNB Smart Chain (56), Robinhood Chain (4663), Tempo (4217), Unichain (130) |
+| UniswapX V3 | Arbitrum (42161), Arc (5042), Avalanche (43114), Base (8453), BNB Smart Chain (56), Ink (57073), Monad (143), Robinhood Chain (4663), Tempo (4217), Unichain (130) |
If you submit a quote request with `protocols` set to `UNISWAPX_V2` or `UNISWAPX_V3` on a chain not listed above, the request will fail.
@@ -88,9 +110,9 @@ Most integrators do not need to set `protocols`. With the default `BEST_PRICE` r
-All UniswapX quote requests require a minimum swap value of 300 USDC equivalent across all supported chains. Below that, UniswapX is included only when its quote improves on the AMM route by at least 0.2%.
+All UniswapX quote requests must meet a per-chain minimum swap value. Below that, UniswapX is included only when its quote improves on the AMM route by at least 0.2%.
-Requests that meet neither condition will return **"No quotes available"**. This is the most common cause of failed UniswapX quote requests.
+Requests that meet neither condition return a 404 with `errorCode: QuoteAmountTooLowError` (see [Troubleshooting](/docs/trading/swapping-api/common-errors#404-no-quotes-available)). This is the most common cause of failed UniswapX quote requests.
diff --git a/content/trading/swapping-api/swapping-permissioned-pools.mdx b/content/trading/swapping-api/swapping-permissioned-pools.mdx
new file mode 100644
index 000000000..63f2c940e
--- /dev/null
+++ b/content/trading/swapping-api/swapping-permissioned-pools.mdx
@@ -0,0 +1,86 @@
+---
+title: Swapping through Permissioned Pools
+sidebarTitle: Permissioned Pools
+description: Swap tokens that trade through permissioned pools on Uniswap v4 and gate them in your app using the Uniswap API check permissions endpoint.
+keywords:
+ - permissioned-pools
+ - tokenized-pools
+ - allowlist
+ - check-permissions
+ - uniswap-api
+---
+
+Some tokens on Uniswap v4 trade through [permissioned pools](/docs/protocols/uniswap-labs-hooks/permissioned-pools/overview), which restrict swaps and liquidity provisioning to allowlisted addresses. Before a wallet can swap one of these tokens, your app must confirm the wallet is allowlisted. The Uniswap API exposes a check permissions endpoint for this purpose. This check is a client-side safeguard for user experience: the swap endpoints reject transactions from wallets that are not allowlisted regardless, so a token never becomes tradable just because an app skips the check.
+
+## Check Permissions Before Swapping
+
+Send the connected wallet and the tokens it wants to trade to the check permissions endpoint. The request accepts up to two tokens.
+
+Like every Uniswap API endpoint, `/v1/permissions` requires an API key in the `x-api-key` header. Without one it returns `401`. Create a key in the [Uniswap Developer Platform](https://developers.uniswap.org/dashboard/welcome).
+
+```bash
+curl -X POST https://trade-api.gateway.uniswap.org/v1/permissions \
+ -H "x-api-key: YOUR_API_KEY" \
+ -H "Content-Type: application/json" \
+ -H "Accept: application/json" \
+ -d '{
+ "walletAddress": "0xC9bebBA9f481b12cE6f3EA54c4B182c9636ec421",
+ "tokens": ["0x1111111111111111111111111111111111111111"],
+ "chainId": 1
+ }'
+```
+
+
+
+## Handle the Response
+
+`isPermissioned` describes the token, meaning whether it trades through a permissioned pool. `isAllowlisted` describes the connected wallet, meaning whether that wallet may trade the token. Each token returns a result with one of three shapes:
+
+```json
+{
+ "requestId": "e63f1e1e-b9e9-411a-bcc8-ff18ce4e77cf",
+ "results": [
+ {
+ "token": "0x1111111111111111111111111111111111111111",
+ "isPermissioned": true,
+ "isAllowlisted": false,
+ "adapterTokenAddress": "0x2222222222222222222222222222222222222222",
+ "kycUrl": "https://your-kyc-provider.example/verify",
+ "issuer": "Your Issuer Name"
+ }
+ ]
+}
+```
+
+- **Not permissioned:** `isPermissioned` is `false`. No token in the request requires permission to trade, so proceed to quoting and swapping normally.
+- **Permissioned and allowlisted:** `isPermissioned` and `isAllowlisted` are both `true`. Trade normally.
+- **Permissioned and not allowlisted:** `isAllowlisted` is `false` and the result includes a `kycUrl`. Direct the user to complete verification. The result also includes `issuer`, the KYC provider display name, so you can tell the user who runs the verification.
+
+## Gate Your Interface
+
+For a wallet that is not allowlisted, let the user quote the token so they can see prices, but block transaction submission to avoid reverts and a confusing experience. Link the user to the `kycUrl` so they can complete verification.
+
+
+Check permissions before submitting. The swap endpoints reject transactions from wallets that are not allowlisted, so a pre-check avoids failed requests and wasted gas.
+
+
+## Set the Universal Router Version
+
+Quotes and swaps that involve a permissioned token must use [Universal Router](/docs/trading/swapping-api/supported-chains#universal-router-version) 2.2.0 or higher. Send the version header when any token in the request is permissioned.
+
+```bash
+x-universal-router-version: 2.2.0
+```
+
+## Routing Behavior
+
+Routing will not send a user through a permissioned pool they are not allowed to trade in. Permissioned tokens are matched only as the input or output of a trade, never as an intermediate hop, so a disallowed user is never routed through a restricted token. For example, a permissioned token to USDC to ETH route is supported for an allowlisted user, while an unrelated trade routed through a permissioned token is not.
+
+## Providing Liquidity
+
+This page covers the swap path through the API. Liquidity provision is gated by the same allowlist: the permissioned hook checks `LIQUIDITY_ALLOWED` on `beforeAddLiquidity`, and positions are minted through the Permissioned Position Manager, which enforces the allowlist and issues non-transferable position NFTs. For the contract details, see [Permissioned Pools Architecture](/docs/protocols/uniswap-labs-hooks/permissioned-pools/architecture) and [Deploy a Permissioned Pool](/docs/protocols/uniswap-labs-hooks/permissioned-pools/deploy-a-permissioned-pool).
+
+## Where to Go Next
+
+- Learn how the pools work in [Permissioned Pools Architecture](/docs/protocols/uniswap-labs-hooks/permissioned-pools/architecture).
+- Onboard a token in [Deploy a Permissioned Pool](/docs/protocols/uniswap-labs-hooks/permissioned-pools/deploy-a-permissioned-pool).
diff --git a/content/unichain/index.mdx b/content/unichain/index.mdx
index f579cbb3c..69aad6d97 100644
--- a/content/unichain/index.mdx
+++ b/content/unichain/index.mdx
@@ -1,6 +1,33 @@
---
title: Unichain Overview
+sidebarTitle: Overview
description: Learn what Unichain is and how it supports faster, lower-cost onchain liquidity and cross-chain interoperability.
+keywords:
+ - Unichain
+ - layer 2
+ - Superchain
+ - Flashblocks
+ - chain ID
+ - bridging
+faqs:
+ - question: How is Unichain different from other Ethereum L2s?
+ answer: |-
+ Unichain is a DeFi-focused Ethereum L2 built on the OP Stack and part of the Superchain, so it shares standards, tooling, and native interoperability with other OP Stack chains. It is a Stage 1 rollup with a permissionless fault-proof system for trust-minimized security. Compared with a general-purpose L2, Unichain targets fast, low-cost onchain liquidity: it runs 1-second block times with 200 ms preconfirmations through Flashblocks, and is designed to reduce value lost to MEV by increasing arbitrage frequency.
+ - question: What are Flashblocks and how do I use them?
+ answer: |-
+ Flashblocks provide transaction preconfirmations on Unichain in about 200 milliseconds, so apps can show faster feedback than the 1-second block time. They are an out-of-protocol extension that streams partial block updates and does not change Unichain's core consensus. Most apps can benefit with minimal changes: use the pending block tag with standard Ethereum JSON-RPC methods such as eth_getBlockByNumber, eth_call, eth_getBalance, and eth_getTransactionCount. The public RPC endpoints are Flashblocks-aware but rate limited, so use a node provider that supports Flashblocks for production.
+ - question: What are the chain ID and RPC URL for Unichain?
+ answer: |-
+ Unichain Mainnet uses chain ID 130 with the public RPC URL https://mainnet.unichain.org, ETH as the currency symbol, and the Uniscan block explorer at https://uniscan.xyz. Unichain Sepolia Testnet uses chain ID 1301 with the public RPC URL https://sepolia.unichain.org. Both public RPC URLs are rate limited and not intended for production, so use a node provider for production workloads.
+ - question: How do I bridge assets to Unichain?
+ answer: |-
+ You can bridge ETH and other supported assets from Ethereum L1 to Unichain through Superbridge, which supports both Unichain Mainnet and Unichain Sepolia. Several third-party bridges also support Unichain, including Across, Brid.gg, Allbridge, Synapse, thirdweb, Relay, and Orbiter Finance. See the Bridges reference for the full list and supported networks.
+ - question: Can I use my existing Ethereum tooling on Unichain?
+ answer: |-
+ Yes. As an OP Stack chain, Unichain is EVM-equivalent with minimal changes to standard Ethereum behavior, so existing Ethereum tooling such as Hardhat and Foundry works after you point it at a Unichain RPC URL. The main differences are network parameters: Unichain uses a 1-second block time and OP Stack EIP-1559 settings rather than Ethereum mainnet values. See the EVM Equivalence and Network Information references for details.
+ - question: What is the difference between Unichain Mainnet and Unichain Sepolia?
+ answer: |-
+ Unichain Mainnet is the production network where real value is at stake. Unichain Sepolia is the public testnet, used to test contracts and integrations with test funds before deploying to mainnet. Both share the same OP Stack architecture and Flashblocks support, so behavior on Sepolia closely matches mainnet. See the Network Information reference on the Unichain docs for chain IDs, RPC URLs, and explorers.
---
## What is Unichain?
Unichain is a DeFi-focused Ethereum L2 designed for fast blocks, lower costs, and efficient onchain liquidity across chains.
@@ -17,6 +44,90 @@ Unichain is designed to align with Ethereum's scaling roadmap by moving executio
### Cross-chain liquidity
Unichain supports interoperability across multiple chains. As part of the Superchain, Unichain supports native [interoperability](https://docs.optimism.io/get-started/interop) and cross-chain liquidity access.
+## FAQ
+
+
+ How is Unichain different from other Ethereum L2s?
+
+
+
+ Unichain is a DeFi-focused Ethereum L2 built on the OP Stack and part of the [Superchain](https://docs.optimism.io/superchain/superchain-explainer), so it shares standards, tooling, and native [interoperability](https://docs.optimism.io/get-started/interop) with other OP Stack chains. It is a Stage 1 rollup with a permissionless fault-proof system for trust-minimized security.
+
+ Compared with a general-purpose L2, Unichain targets fast, low-cost onchain liquidity:
+
+ * 1-second block times, with 200 ms preconfirmations through [Flashblocks](/docs/unichain/technical-information/flashblocks)
+ * Lower latency designed to increase arbitrage frequency and reduce value lost to MEV
+
+
+
+
+
+
+ What are Flashblocks and how do I use them?
+
+
+
+ [Flashblocks](/docs/unichain/technical-information/flashblocks) provide transaction preconfirmations in about 200 milliseconds, so apps can show faster feedback than the 1-second block time. They are an out-of-protocol extension that streams partial block updates and does not change Unichain's core consensus.
+
+ Most apps can benefit with minimal changes. Use the `pending` block tag with standard Ethereum JSON-RPC methods such as `eth_getBlockByNumber`, `eth_call`, `eth_getBalance`, and `eth_getTransactionCount`. The public RPC endpoints are Flashblocks-aware but rate limited, so use a [node provider](/docs/unichain/tools/node-providers) that supports Flashblocks for production.
+
+
+
+
+
+
+ What are the chain ID and RPC URL for Unichain?
+
+
+
+ | Network | Chain ID | Public RPC URL | Block Explorer |
+ | :-- | :-- | :-- | :-- |
+ | Unichain Mainnet | `130` | `https://mainnet.unichain.org` | [uniscan.xyz](https://uniscan.xyz) |
+ | Unichain Sepolia | `1301` | `https://sepolia.unichain.org` | [sepolia.uniscan.xyz](https://sepolia.uniscan.xyz) |
+
+ Both public RPC URLs are rate limited and not intended for production. Use a [node provider](/docs/unichain/tools/node-providers) for production workloads. See [Network Information](/docs/unichain/technical-information/network-information) for full parameters.
+
+
+
+
+
+
+ How do I bridge assets to Unichain?
+
+
+
+ You can bridge ETH and other supported assets from Ethereum L1 to Unichain through [Superbridge](https://superbridge.app), which supports both [Unichain Mainnet](https://superbridge.app/unichain) and [Unichain Sepolia](https://superbridge.app/unichain-sepolia).
+
+ Several third-party bridges also support Unichain, including Across, Brid.gg, Allbridge, Synapse, thirdweb, Relay, and Orbiter Finance. See the [Bridges](/docs/unichain/tools/bridges) reference for the full list and supported networks.
+
+
+
+
+
+
+ Can I use my existing Ethereum tooling on Unichain?
+
+
+
+ Yes. As an OP Stack chain, Unichain is [EVM-equivalent](/docs/unichain/technical-information/evm-equivalence) with minimal changes to standard Ethereum behavior, so existing tooling such as Hardhat and Foundry works after you point it at a Unichain RPC URL.
+
+ The main differences are network parameters: Unichain uses a 1-second block time and OP Stack EIP-1559 settings rather than Ethereum mainnet values. See [EVM Equivalence](/docs/unichain/technical-information/evm-equivalence) and [Network Information](/docs/unichain/technical-information/network-information) for details.
+
+
+
+
+
+
+ What is the difference between Unichain Mainnet and Unichain Sepolia?
+
+
+
+ Unichain Mainnet is the production network where real value is at stake. Unichain Sepolia is the public testnet, used to test contracts and integrations with test funds before deploying to mainnet. Both share the same OP Stack architecture and Flashblocks support, so behavior on Sepolia closely matches mainnet. See [Network Information](/docs/unichain/technical-information/network-information) for chain IDs, RPC URLs, and explorers.
+
+
+
+
+
## Where to Go Next
- [Read the Unichain Whitepaper](/whitepaper_unichain.pdf)
diff --git a/content/unichain/tools/oracles.mdx b/content/unichain/tools/oracles.mdx
index 682cbe386..79c0e69c5 100644
--- a/content/unichain/tools/oracles.mdx
+++ b/content/unichain/tools/oracles.mdx
@@ -1,5 +1,6 @@
---
-title: Oracles
+title: Oracles on Unichain
+sidebarTitle: Oracles
description: Connect oracle services to fetch real-time data feeds for applications built on Unichain.
---
diff --git a/content/uniswap-ai/overview.mdx b/content/uniswap-ai/overview.mdx
index 1bb646c00..1c2a29dd4 100644
--- a/content/uniswap-ai/overview.mdx
+++ b/content/uniswap-ai/overview.mdx
@@ -1,11 +1,35 @@
---
title: Uniswap AI Overview
+sidebarTitle: Overview
description: Get started with Uniswap AI plugins, skills, and LLM context.
+keywords:
+ - Uniswap AI
+ - AI plugins
+ - coding agents
+ - llms.txt
+ - Claude Code marketplace
+ - open source
+faqs:
+ - question: Is Uniswap AI free and open source?
+ answer: |-
+ Yes. Uniswap AI is an open-source collection of plugins and skills published under the MIT license in the Uniswap/uniswap-ai repository on GitHub. There is no cost to install or use the skills, and you can read, fork, and contribute to the source.
+ - question: Do I need Claude Code to use Uniswap AI skills?
+ answer: |-
+ No. The skills are designed for any coding agent and install with the Skills CLI. Claude Code is one supported option: it adds a plugin marketplace that bundles the skills with expert agents and protocol-specific tools, but it is not required.
+ - question: Do Uniswap AI skills run in production?
+ answer: |-
+ No. Skills are build-time workflows that guide your coding agent while you write integration code. They are instructions and references loaded into the agent, not a runtime service that ships inside your deployed application. The code your agent produces with a skill is what runs in production.
+ - question: How are skills different from the llms.txt context files?
+ answer: |-
+ Both give an AI model Uniswap knowledge, but at different levels of structure. The llms.txt and llms-full.txt files are raw documentation context you add to a model's context window. Skills are structured, task-scoped workflows with step-by-step instructions and references that a coding agent activates directly or by matching your prompt. Use the context files when you want plain documentation grounding, and use skills when you want guided, protocol-specific workflows.
+ - question: Which skills are available and how do I install them?
+ answer: |-
+ Uniswap AI publishes skills such as swap-integration, v4-security-foundations, and liquidity-planner; see the Uniswap/uniswap-ai repository on GitHub for the full, current list. Install them with the Skills CLI, or add the Claude Code marketplace to install plugins individually.
---
Use Uniswap AI to speed up swap integration, hook development, and EVM workflows with tools designed for builders on Uniswap.
-If your agent talks to the Trading API directly, send the optional [`X-Agent-Info` attribution header](/docs/trading/swapping-api/agent-attribution) so agent-driven traffic is measured separately from human-driven traffic.
+If your agent talks to the Trading API directly, send the optional [`X-Agent-Info` attribution header](/docs/trading/swapping-api/start-building/agent-attribution) so agent-driven traffic is measured separately from human-driven traffic.
## Uniswap AI
@@ -99,6 +123,80 @@ https://developers.uniswap.org/llms-full.txt
Install the Uniswap AI plugins (see [above](#claude-code-marketplace)) for the richest integration. The plugins provide structured skills, expert agents, and protocol-specific tools that go beyond static documentation context.
+## FAQ
+
+
+ Is Uniswap AI free and open source?
+
+
+
+ Yes. Uniswap AI is an open-source collection of plugins and skills published under the MIT license in the [Uniswap/uniswap-ai](https://github.com/Uniswap/uniswap-ai) repository on GitHub. There is no cost to install or use the skills, and you can read, fork, and contribute to the source.
+
+
+
+
+
+
+ Do I need Claude Code to use Uniswap AI skills?
+
+
+
+ No. The skills are designed for any coding agent and install with the Skills CLI:
+
+ ```bash
+ npx skills add Uniswap/uniswap-ai
+ ```
+
+ [Claude Code](https://claude.ai/code) is one supported option: it adds a [plugin marketplace](#claude-code-marketplace) that bundles the skills with expert agents and protocol-specific tools, but it is not required.
+
+
+
+
+
+
+ Do Uniswap AI skills run in production?
+
+
+
+ No. Skills are build-time workflows that guide your coding agent while you write integration code. They are instructions and references loaded into the agent, not a runtime service that ships inside your deployed application. The code your agent produces with a skill is what runs in production. See [Uniswap Skills](/docs/uniswap-ai/skills) for how skills activate.
+
+
+
+
+
+
+ How are skills different from the llms.txt context files?
+
+
+
+ Both give an AI model Uniswap knowledge, but at different levels of structure:
+
+ * `llms.txt` and `llms-full.txt` are raw documentation context you add to a model's context window. See [LLM Context Files](#llm-context-files).
+ * Skills are structured, task-scoped workflows with step-by-step instructions and references that a coding agent activates directly or by matching your prompt.
+
+ Use the context files when you want plain documentation grounding, and use skills when you want guided, protocol-specific workflows.
+
+
+
+
+
+
+ Which skills are available and how do I install them?
+
+
+
+ Uniswap AI publishes skills such as `swap-integration`, `v4-security-foundations`, and `liquidity-planner`. See the [Uniswap/uniswap-ai](https://github.com/Uniswap/uniswap-ai) repository for the full, current list. Install them with the Skills CLI:
+
+ ```bash
+ npx skills add Uniswap/uniswap-ai
+ ```
+
+ Alternatively, add the [Claude Code marketplace](#claude-code-marketplace) to install plugins individually.
+
+
+
+
+
## Where to Go Next
- [Browse official skills](/docs/uniswap-ai/skills)
diff --git a/content/uniswap-ai/skills.mdx b/content/uniswap-ai/skills.mdx
index 12e8f4ece..e407dfc4e 100644
--- a/content/uniswap-ai/skills.mdx
+++ b/content/uniswap-ai/skills.mdx
@@ -1,6 +1,14 @@
---
title: Uniswap Skills
description: Browse available Uniswap AI skills for swap integration, hook development, liquidity management, and more.
+keywords:
+ - Uniswap AI
+ - skills
+ - plugins
+ - coding agents
+ - llms.txt
+ - open source
+
---
Use Uniswap AI skills to run specialized workflows for swap integration, hook development, EVM interactions, and liquidity planning.
@@ -81,3 +89,4 @@ Each skill is defined in a `SKILL.md` file and typically includes:
2. Add a `SKILL.md` file with frontmatter and clear instructions
3. Register the skill in the plugin manifest (`plugin.json`)
4. Validate the skill with lint and test checks before opening a PR
+