permissioned-pools-issuer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Permissioned Pools Issuer Reference

Uniswap v4权限池发行方参考指南

Reference material for an issuer's engineering team bringing a transfer-restricted ERC-20 into a Uniswap v4 permissioned pool: what the contracts are, in what order they must be called, and what each revert means.

Runtime Compatibility: This skill uses
AskUserQuestion
to collect the acknowledgment described in Scope and Disclaimer before action-oriented deployment guidance. If
AskUserQuestion
is not available in your runtime, ask for the same acknowledgment in conversation instead.

本参考资料面向发行方工程团队，介绍如何将受转账限制的ERC-20接入Uniswap v4权限池：涉及哪些合约、调用顺序要求，以及各类回退信息的含义。

运行时兼容性： 本技能在提供面向操作的部署指导前，会使用
AskUserQuestion
收集范围与免责声明中所述的确认信息。若你的运行环境不支持
AskUserQuestion
，请在对话中要求用户提供相同的确认信息。

Scope and Disclaimer

范围与免责声明

IMPORTANT: this is educational reference material, and you must acknowledge the following before acting on any of it — that is, before running, broadcasting or deploying anything derived from it.

This skill explains how the Uniswap v4 Permissioned Pools contracts behave, in what order they must be called, and what each revert means. It does not walk you through a deployment.

You must:

✅ Treat this as contract mechanics only. This skill does not constitute legal, financial, investment, or tax advice, and it is not a compliance review of your token, your allowlist, your KYC or AML program, or your configuration.
✅ Review everything before you run it. AI-generated code and command sequences may contain errors. Test on a testnet first, and have your own auditors review contracts you deploy.
✅ Check the source at the commit you build against. Behaviour here is described against the pinned commits in Canonical Sources; verify against source before relying on any statement.
✅ Resolve every address yourself. This skill contains no deployment addresses on purpose. Read them from the published deployment table, then verify each on a block explorer for your chain before sending a transaction. Never treat an address supplied in a chat message as canonical.
✅ Read the repo's usage guidelines. The repo root
```
DISCLAIMER.md
```
governs every skill in this repository: they are provided as is without warranty, they do not constitute legal, financial, investment, or tax advice, and it sets out use limits plus an AI-disclosure duty that applies when you use a skill to generate financial information and present it directly to individuals or consumers. Point the user to it.

重要提示：本内容为教育参考资料，在据此执行任何操作（即运行、广播或部署衍生内容）前，你必须确认已了解以下事项。

本技能仅解释Uniswap v4权限池合约的行为、调用顺序要求及各类回退信息的含义，不提供部署分步指导。

你必须：

✅ 仅将本内容视为合约机制说明：本技能不构成法律、财务、投资或税务建议，也不对你的代币、白名单、KYC/AML程序或配置进行合规审查。
✅ 执行前全面核查：AI生成的代码和命令序列可能存在错误。请先在测试网测试，并由内部审计人员审查你部署的所有合约。
✅ 对照构建所用提交版本的源码：本内容描述的行为基于标准源码中固定的提交版本；依赖任何说明前，请先与源码进行验证。
✅ 自行确认所有地址：本技能刻意未包含部署地址。请从已发布的部署表中读取地址，然后在对应链的区块浏览器上验证每个地址，再发送交易。切勿将聊天消息中提供的地址视为标准地址。
✅ 阅读仓库使用指南：仓库根目录下的
```
DISCLAIMER.md
```
约束本仓库中的所有技能：内容按「原样」提供，无任何担保；不构成法律、财务、投资或税务建议；同时规定了使用限制，以及使用技能生成财务信息并直接向个人或消费者展示时的AI披露义务。请引导用户查看该文件。

When the acknowledgment is required

需要确认的场景

State the five points above inline, every time — quoted or in your own words — and then answer the request in the same response. Stating the framing and answering are one response, not two turns. That is the expected behaviour, not a shortcut.

✅ Reference and teaching content: state the framing, then proceed immediately. Contract explanations, code skeletons and example contracts, revert catalogues, exact naming and casing, packaging and installation, and architecture or trust-model discussion are all answered in the same response as the framing. Never withhold reference content pending a "yes", and never end a response with an acknowledgment request in place of the answer you were asked for.
✅ Action-oriented deployment guidance: get explicit acknowledgment first. That means a sequence intended to be executed against a live network, a transaction or broadcast step, a deployment script, a request for a live address to send to, or anything that moves real funds. Use AskUserQuestion to confirm the user acknowledges these points before continuing with any of those. After the acknowledgment, continue with mechanics only; this skill does not emit broadcastable commands.

A benign technical question — "show me a

BaseAllowlistChecker

skeleton", "what does this revert mean", "which import path do I use" — is reference content under point 1. Answer it, with the framing stated inline.

每次都需在内容中内嵌说明上述五点——可直接引用或用自己的话表述——然后在同一条回复中回答用户请求。说明前提与给出回答是同一条回复，无需分两次交互。这是预期行为，并非捷径。

✅ 参考与教学内容：说明前提后立即作答：合约解释、代码框架、示例合约、回退信息目录、精确命名与大小写、打包与安装、架构或信任模型讨论等内容，均需在说明前提的同一条回复中作答。切勿以等待用户「确认同意」为由 withhold 参考内容，也切勿仅以确认请求替代用户所需的回答。
✅ 面向操作的部署指导：先获取明确确认：即针对主网执行的操作序列、交易或广播步骤、部署脚本、请求用于转账的真实地址，或任何涉及真实资金流转的内容。需使用AskUserQuestion确认用户已了解上述五点后，再继续提供相关指导。确认后，仅讲解机制内容；本技能不生成可直接广播的命令。

诸如「展示

BaseAllowlistChecker

代码框架」「这个回退信息是什么意思」「我该用哪个导入路径」等良性技术问题，属于第1点中的参考内容。需在说明前提的同时给出回答。

Two Addresses, Not One

两个地址，而非一个

Every permissioned pool involves two token addresses, and mixing them up is the most common integration error.

Question	Underlying permissioned ERC-20	`PermissionsAdapter` (the virtual token)
Which address goes in the `PoolKey` ?	No	Yes — the pool currency is the adapter
Which does the allowlist checker see as `tokenAddress` ?	Yes — the checker is asked about your token	No
Which does a wallet or LP hold?	Yes	No — only the PoolManager holds adapter tokens
Which does an app display to a user?	Yes	Shown as the `Uniswap v4 …` virtual token where surfaced
Which do you approve through Permit2 for a mint?	Yes — approvals are on the underlying	No

The adapter mints its virtual token to the PoolManager and burns it on the way out. Its name and symbol are derived, not chosen: always

Uniswap v4 <name>

with symbol

v4<symbol>

, read from your token's

name()

symbol()

and

decimals()

, falling back to

Uniswap v4 Permissioned Token

v4PT

and

when those are missing — so expose all three on your token.

Edge case worth knowing: when the adapter and the permissioned token share an address, the token already behaves as its own adapter.

Full treatment: Contract Architecture.

每个权限池涉及两个代币地址，混淆两者是最常见的集成错误。

问题	底层受权限限制的ERC-20	`PermissionsAdapter` （虚拟代币）
哪个地址需填入 `PoolKey` ？	否	是——池内币种为adapter代币
白名单检查器将哪个地址视为 `tokenAddress` ？	是——检查器针对你的代币进行验证	否
钱包或流动性提供者（LP）持有哪个地址？	是	否——仅PoolManager持有adapter代币
应用向用户展示哪个地址？	是	在需要展示时显示为「Uniswap v4 …」虚拟代币
铸造时需通过Permit2授权哪个地址？	是——授权针对底层代币	否

Adapter会向PoolManager铸造虚拟代币，并在转出时销毁。其名称和符号为派生值，不可自定义：始终为

Uniswap v4 <name>

，符号为

v4<symbol>

，读取自你的代币的

name()

、

symbol()

和

decimals()

方法；若这些方法缺失，则默认使用

Uniswap v4 Permissioned Token

、

v4PT

和

——因此请确保你的代币暴露这三个方法。

需要注意的边缘情况：当adapter与受权限限制的代币地址相同时，该代币已具备自身adapter的功能。

详细说明：合约架构。

Journey at a Glance

流程概览

Two separate things are often conflated. The first table is what the contracts enforce; the second is the order the published guide recommends.

人们常混淆两个不同的概念。第一个表格是合约强制要求的顺序，第二个是官方指南推荐的顺序。

Enforced by code

代码强制的顺序

Exactly five ordering edges are enforced. Each one has a revert you will hit if you are early.

Enforced edge	Revert if you are early
Adapter allowlisted on your token and holding a non-zero balance → `verifyPermissionsAdapter`	`PermissionsAdapterNotVerified`
`verifyPermissionsAdapter` → `setAllowedHook`	`NotPermissionsAdapterAdmin`
Adapter registered and verified → pool `initialize`	`NoVerifiedAdapter` (hook) or `UnverifiedAdapter`
Verified adapter + approved hook + `LIQUIDITY_ALLOWED` on caller and recipient → first mint	`NoVerifiedAdapter` (position manager), `InvalidHook` , or bare `Unauthorized`
Position manager, router or quoter registered with `updateAllowedWrapper` → any mint, swap or quote routed through it	bare `Unauthorized` (hook), then `UnauthorizedWrapper` on settlement

代码严格强制执行以下五条顺序规则。若提前调用，会触发对应的回退信息。

强制顺序规则	提前调用时触发的回退信息
Adapter已在你的代币白名单中且持有非零余额 → `verifyPermissionsAdapter`	`PermissionsAdapterNotVerified`
`verifyPermissionsAdapter` → `setAllowedHook`	`NotPermissionsAdapterAdmin`
Adapter已注册并验证 → 调用pool的 `initialize`	`NoVerifiedAdapter` （hook）或 `UnverifiedAdapter`
已验证的adapter + 已授权的hook + 调用方和接收方具备 `LIQUIDITY_ALLOWED` 权限 → 首次铸造	`NoVerifiedAdapter` （position manager）、 `InvalidHook` 或直接 `Unauthorized`
Position manager、router或quoter已通过 `updateAllowedWrapper` 注册 → 通过其进行的任何铸造、兑换或报价操作	直接 `Unauthorized` （hook），结算时触发 `UnauthorizedWrapper`

Recommended order (convention, not enforced)

Step	Action
1	Implement an allowlist checker
2	Create the Permissions Adapter via the factory
3	Allowlist the adapter on your token and fund it (1 wei is enough)
4	Verify the adapter with the factory
5	Approve the virtual-token contracts (allowed wrappers), then allow the hook on the position manager
6	Create the pool, then enable swapping on the adapter
7	Request routing allowlisting with Uniswap Labs

步骤	操作
1	实现白名单检查器
2	通过工厂创建Permissions Adapter
3	将adapter加入你的代币白名单，并为其充值（1 wei即可）
4	通过工厂验证adapter
5	授权虚拟代币合约（允许的wrapper），然后在position manager上授权hook
6	创建池，然后在adapter上启用兑换功能
7	向Uniswap Labs申请路由白名单

Compile-Critical Naming and Signatures

编译关键的命名与签名

Casing here is inconsistent in the source and is load-bearing. Use exactly these spellings.

Thing	Exact spelling	Trap
Base contract	`BaseAllowlistChecker`	lowercase `l` in the contract name
File holding it	`BaseAllowListChecker.sol`	capital `L` in the file name
Interface	`IAllowlistChecker`	lowercase `l` , in `IAllowlistChecker.sol`
Adapter admin call	`updateAllowListChecker`	capital `L` ; there is no lowercase variant
Adapter getter	`allowListChecker()`	capital `L` , unlike the interface
Hook approval call	`setAllowedHook`	singular, on the position manager
Its storage mapping	`isAllowedHooks`	plural
Its event	`AllowedHooksUpdated`	plural
Flags library	`PermissionFlags`	plural
Flag type	`PermissionFlag`	singular

Import and Forge lookup forms:

solidity

import {BaseAllowlistChecker} from "@uniswap/v4-periphery/src/hooks/permissionedPools/BaseAllowListChecker.sol";

text

BaseAllowListChecker.sol:BaseAllowlistChecker

That

path:Contract

pair — capital-L file, lowercase-l contract — is what

forge inspect

and

forge verify-contract

need.

源码中的大小写不一致，且对编译至关重要。请严格使用以下拼写。

名称	精确拼写	注意事项
基础合约	`BaseAllowlistChecker`	合约名称中的 `l` 为小写
所在文件	`BaseAllowListChecker.sol`	文件名中的 `L` 为大写
接口	`IAllowlistChecker`	`IAllowlistChecker.sol` 中的 `l` 为小写
Adapter管理员调用	`updateAllowListChecker`	`L` 为大写；无小写变体
Adapter获取方法	`allowListChecker()`	`L` 为大写，与接口不同
Hook授权调用	`setAllowedHook`	单数形式，调用对象为position manager
存储映射	`isAllowedHooks`	复数形式
事件	`AllowedHooksUpdated`	复数形式
标志库	`PermissionFlags`	复数形式
标志类型	`PermissionFlag`	单数形式

导入与Forge查找格式：

solidity

import {BaseAllowlistChecker} from "@uniswap/v4-periphery/src/hooks/permissionedPools/BaseAllowListChecker.sol";

text

BaseAllowListChecker.sol:BaseAllowlistChecker

该

路径:合约

组合——文件名

大写，合约名

小写——是

forge inspect

和

forge verify-contract

所需的格式。

checkAllowlist

has two legitimate shapes

checkAllowlist

有两种合法实现形式

Both compile. Pick one and stay in it.

Extend the base contract. Declare
```
function checkAllowlist(address account, address tokenAddress) public view virtual override returns (PermissionFlag)
```
. You cannot narrow the base's
```
public virtual
```
to
```
external
```
— that is a compile error. ERC-165 support comes for free from the base contract.
Implement the interface directly. Declare
```
checkAllowlist
```
as
```
external view
```
, and write
```
supportsInterface
```
yourself. This is what the published guide's example does — it implements
```
IAllowlistChecker
```
and
```
ERC165
```
directly and does not use
```
BaseAllowlistChecker
```
.

两种形式均可编译。请选择其一并保持一致。

继承基础合约：声明
```
function checkAllowlist(address account, address tokenAddress) public view virtual override returns (PermissionFlag)
```
。不能将基础合约的
```
public virtual
```
改为
```
external
```
——这会导致编译错误。继承基础合约可自动获得ERC-165支持。
直接实现接口：将
```
checkAllowlist
```
声明为
```
external view
```
，并自行编写
```
supportsInterface
```
方法。官方指南的示例采用此方式——直接实现
```
IAllowlistChecker
```
和
```
ERC165
```
，不使用
```
BaseAllowlistChecker
```
。

The adapter checks your checker with ERC-165

Adapter通过ERC-165检查你的检查器

createPermissionsAdapter

reverts

InvalidAllowListChecker

unless the checker advertises

IAllowlistChecker

through an ERC-165

supportsInterface

call. The constructor performs this check, so it fires on the very first Uniswap call in the journey.

updateAllowListChecker

performs the same check later. Extending

BaseAllowlistChecker

satisfies it. A from-scratch implementation must supply

supportsInterface

itself, and it has to answer the full ERC-165 probe, not just its own id: OpenZeppelin's

ERC165Checker.supportsInterface

first requires

supportsInterface(0x01ffc9a7)

to return

true

and

supportsInterface(0xffffffff)

to return

false

. Inheriting OpenZeppelin

ERC165

and delegating to

super.supportsInterface

covers both; a hand-written function that returns

true

only for

type(IAllowlistChecker).interfaceId

fails adapter creation.

除非检查器通过ERC-165的

supportsInterface

调用声明支持

IAllowlistChecker

，否则

createPermissionsAdapter

会触发

InvalidAllowListChecker

回退。该检查在构造函数中执行，因此会在流程中的第一个Uniswap调用时触发。

updateAllowListChecker

后续也会执行相同检查。继承

BaseAllowlistChecker

可满足该要求。从零实现的检查器必须自行提供

supportsInterface

方法，且需完整响应ERC-165探测，而非仅返回自身ID：OpenZeppelin的

ERC165Checker.supportsInterface

首先要求

supportsInterface(0x01ffc9a7)

true

且

supportsInterface(0xffffffff)

false

。继承OpenZeppelin的

ERC165

并委托给

super.supportsInterface

可覆盖这两个要求；若手写函数仅对

type(IAllowlistChecker).interfaceId

true

，则会导致adapter创建失败。

Permission Flags

权限标志

PermissionFlags

(the library) exposes four values of the

PermissionFlag

type:

Name	Value	Gates
`NONE`	`0x0000`	nothing
`SWAP_ALLOWED`	`0x0001`	`beforeSwap` on the hook, and the router's settlement check
`LIQUIDITY_ALLOWED`	`0x0002`	`beforeAddLiquidity` on the hook, and the recipient check on mints and increases
`ALL_ALLOWED`	`0xFFFF`	both

SWAP_ALLOWED

does not imply

LIQUIDITY_ALLOWED

. A wallet that can swap cannot necessarily provide liquidity, and that includes your own treasury wallet. Your checker returns a

PermissionFlag

combining whichever apply.

PermissionFlags

（库）暴露

PermissionFlag

类型的四个值：

名称	值	控制范围
`NONE`	`0x0000`	无任何权限
`SWAP_ALLOWED`	`0x0001`	hook的 `beforeSwap` 方法，以及router的结算检查
`LIQUIDITY_ALLOWED`	`0x0002`	hook的 `beforeAddLiquidity` 方法，以及铸造和增加流动性时的接收方检查
`ALL_ALLOWED`	`0xFFFF`	同时拥有上述两种权限

SWAP_ALLOWED

不隐含

LIQUIDITY_ALLOWED

权限。可进行兑换的钱包不一定能提供流动性，这包括你自己的国库钱包。你的检查器需返回组合了适用权限的

PermissionFlag

值。

The Wrapper Registration Set

Wrapper注册集合

updateAllowedWrapper(address wrapper, bool allowed)

on the adapter is

onlyOwner

. The published guide names four contracts to register:

```
PermissionedPositionManager
```
The Universal Router — 2.2.0 or higher, whose canonical deployments key is
```
UniversalRouter#v2.2
```
```
V4Quoter
```
```
MixedRouteQuoterV2
```

The rule behind the four: register every contract that will call the PoolManager on this pool. The hook checks

allowedWrappers(router)

, where

router

is the calling router or position manager, and

wrapToPoolManager

separately checks

allowedWrappers[msg.sender]

. So a custom router of your own must be registered too, and the four are the production callers rather than a closed set. Registration is enforced against use: the position manager must be registered before your first mint, and each router and quoter before the first swap or quote through it.

Two traps. The guide's Step 5 says "all four addresses" and links a table with six rows:

PermissionsAdapterFactory

and

PermissionedHooks

are in that table and are not wrappers — never register the factory or the hook. And the plain

UniversalRouter

deployments key is a different, non-permissioned router; only the

#v2.2

deployment takes the permissions-adapter factory in its constructor.

Adapter上的

updateAllowedWrapper(address wrapper, bool allowed)

方法仅允许管理员调用。官方指南列出了四个需注册的合约：

```
PermissionedPositionManager
```
Universal Router — 版本2.2.0或更高，其标准部署标识为
```
UniversalRouter#v2.2
```
```
V4Quoter
```
```
MixedRouteQuoterV2
```

四个合约背后的规则： 注册所有将针对该池调用PoolManager的合约。Hook会检查

allowedWrappers(router)

（其中

router

为调用的router或position manager），

wrapToPoolManager

会单独检查

allowedWrappers[msg.sender]

。因此你自己的自定义router也必须注册，上述四个是生产环境中的常用调用方，而非封闭集合。注册是使用前的强制要求：position manager必须在首次铸造前注册，每个router和quoter必须在首次通过其进行兑换或报价前注册。

两个陷阱： 指南的步骤5提到「所有四个地址」，并链接了一个包含六行的表格：

PermissionsAdapterFactory

和

PermissionedHooks

在该表格中，但不属于wrapper——切勿注册工厂或hook。另外，普通

UniversalRouter

的部署标识对应不同的非权限化router；只有

#v2.2

版本的部署在构造函数中包含权限池adapter工厂。

Installing the Contracts

合约安装

The latest published

@uniswap/v4-periphery

on npm is 1.0.3 (2025-07-29), and its tarball does not contain

src/hooks/permissionedPools/

at all.

v4-periphery

also has zero git tags, so there is no tag to pin either. A raw commit SHA is the only option.

bash

undefined

npm上最新发布的

@uniswap/v4-periphery

版本为1.0.3（2025-07-29），其压缩包完全不包含

src/hooks/permissionedPools/

目录。

v4-periphery

也无任何git标签，因此无法通过标签固定版本。唯一的选择是使用原始提交SHA。

bash

undefined

Foundry — pin the exact commit

Foundry — 固定精确提交版本

forge install Uniswap/v4-periphery@3245c3cb99c48fa1dc2459c3b60abc37d4294aba


```text

forge install Uniswap/v4-periphery@3245c3cb99c48fa1dc2459c3b60abc37d4294aba


```text

remappings.txt — matches what v4-hooks-public itself uses

remappings.txt — 与v4-hooks-public自身使用的映射一致

@uniswap/v4-periphery/=lib/v4-periphery/


The published guide's import paths are npm-scoped and correct once remapped this way. The guide gives the import lines; the install step and remapping above are what they require.

Details, including the hook-source pin and how to resolve addresses: [Packaging and Sources](./references/packaging-and-sources.md).

---

@uniswap/v4-periphery/=lib/v4-periphery/


官方指南的导入路径为npm作用域格式，按上述方式配置映射后即可正确使用。指南提供了导入代码行；上述安装步骤和映射是其必要前提。

详细说明，包括hook源码固定版本和地址解析方法：[打包与源码](./references/packaging-and-sources.md)。

---

Ordering Is Enforced in Code

代码强制的顺序规则

These calls revert with the selector shown if you make them early. They are behaviours to expect, not open questions.

Call	Revert	Condition
`createPermissionsAdapter`	`InvalidAllowListChecker`	the checker fails the ERC-165 interface check
`verifyPermissionsAdapter`	`PermissionsAdapterNotVerified`	the adapter's permissioned-token balance is zero
`setAllowedHook`	`NotPermissionsAdapterAdmin`	the currency's adapter is not verified yet, so its owner reads as `address(0)`
pool `initialize`	`NoVerifiedAdapter` / `UnverifiedAdapter`	neither currency was created by the factory / a factory-created currency is not verified
`_mint` on the position manager	`NoVerifiedAdapter` / `InvalidHook` / `Unauthorized`	no verified side / hook not allowed / caller or recipient lacks `LIQUIDITY_ALLOWED` , or the position manager is not a registered allowed wrapper

NoVerifiedAdapter

Unauthorized

and

SwappingDisabled

are each declared more than once with the same selector —

NoVerifiedAdapter

and

Unauthorized

with genuinely different meanings,

SwappingDisabled

with the same meaning from two different points in a swap. Always decode by call site, never by name.

Full catalogue and worked out-of-order scenarios: Enforced Ordering and Reverts.

若提前调用以下方法，会触发所示的选择器回退。这些是预期行为，而非未明确的问题。

调用方法	回退信息	触发条件
`createPermissionsAdapter`	`InvalidAllowListChecker`	检查器未通过ERC-165接口验证
`verifyPermissionsAdapter`	`PermissionsAdapterNotVerified`	Adapter的受权限限制代币余额为零
`setAllowedHook`	`NotPermissionsAdapterAdmin`	币种对应的adapter尚未验证，因此其所有者地址为 `address(0)`
pool的 `initialize`	`NoVerifiedAdapter` / `UnverifiedAdapter`	任一币种非工厂创建 / 工厂创建的币种未验证
position manager的 `_mint`	`NoVerifiedAdapter` / `InvalidHook` / `Unauthorized`	无已验证的币种 / hook未授权 / 调用方或接收方无 `LIQUIDITY_ALLOWED` 权限，或position manager未注册为允许的wrapper

NoVerifiedAdapter

、

Unauthorized

和

SwappingDisabled

均被多次声明，且选择器相同——

NoVerifiedAdapter

和

Unauthorized

具有完全不同的含义，

SwappingDisabled

在兑换流程的两个不同点触发时含义相同。请始终根据调用位置解码，而非仅根据名称。

完整目录及无序调用场景示例：强制顺序与回退信息。

Trust Model Summary

信任模型概述

LP positions are permanently non-transferable. All three ERC-721 transfer entry points revert
```
TransferDisabled
```
. It is not a configuration flag. Decrease and burn are never gated by the allowlist checker, so the pool never blocks an exit — though delivery of the permissioned side unwraps to the underlying token, so the recipient still has to clear your token's own transfer restriction.
Either adapter admin can force-exit any LP with
```
unwindPosition
```
, and proceeds cascade to the LP first, then to an admin, then as an ERC-6909 claim whose recipient depends on the currency.
The real enforcement boundary is the adapter's
allowedWrappers
list. Every wrapper on it is trusted to report the true originating caller through
```
msgSender()
```
.
```
updateAllowedWrapper
```
is
```
onlyOwner
```
on an
```
Ownable2Step
```
contract, so adapter-owner key management is part of the trust model.

Full treatment: Trust Model.

LP头寸永久不可转让：三个ERC-721转让入口均会触发
```
TransferDisabled
```
回退。这并非配置项。减少流动性和销毁操作不受白名单检查器限制，因此池永远不会阻止退出——但受权限限制的币种会解包为底层代币，因此接收方仍需通过你的代币自身的转账限制验证。
任一adapter管理员可强制退出任意LP：调用
```
unwindPosition
```
会优先将资金返还给LP，然后是管理员，最后作为ERC-6909索赔，接收方取决于币种类型。
实际执行边界是adapter的
allowedWrappers
列表：列表中的每个wrapper都被信任可通过
```
msgSender()
```
报告真实的发起调用方。
```
updateAllowedWrapper
```
是
```
Ownable2Step
```
合约的
```
onlyOwner
```
方法，因此adapter所有者的密钥管理是信任模型的一部分。

详细说明：信任模型。

What Is Permissionless and What Is Not

无需许可与需要协调的内容

Permissionless / issuer-controlled	Coordinated with Uniswap Labs
Deploying your allowlist checker	Routing eligibility in the Uniswap interface and API
`createPermissionsAdapter` (anyone may call)	Token-list inclusion
Allowlisting the adapter on your token	Token-detail metadata
`depositForVerification` (anyone may call)	Issuer metadata and KYC URL in the backend configuration
`verifyPermissionsAdapter` (anyone may call, one-shot)
Every adapter admin operation
`setAllowedHook` , pool initialization, seeding liquidity

The on-chain path has no Uniswap approval gate. Nothing in the left column waits on anybody.

Boundary detail, including the routing request: Coordination Boundary.

无需许可/发行方可控	需与Uniswap Labs协调
部署你的白名单检查器	Uniswap界面与API中的路由资格
`createPermissionsAdapter` （任何人可调用）	代币列表收录
将adapter加入你的代币白名单	代币详情元数据
`depositForVerification` （任何人可调用）	后端配置中的发行方元数据与KYC URL
`verifyPermissionsAdapter` （任何人可调用，仅一次）
所有adapter管理员操作
`setAllowedHook` 、池初始化、注入流动性

链上流程无Uniswap审批环节：左列中的所有操作无需等待任何第三方许可。

边界详细说明，包括路由申请：协调边界。

Reference Topics

参考主题

Topic	Reference File
Contract-by-contract stack, exact-casing inventory, flags, events	Contract Architecture
The seven steps in detail, with calls, callers and checks	Issuer Journey
The five enforced edges, the revert catalogue, worked scenarios	Enforced Ordering and Reverts
Non-transferability, admin force-exit, vetting a candidate wrapper	Trust Model
Pinning, remapping, import paths, resolving addresses	Packaging and Sources
What is permissionless versus coordinated, the routing request	Coordination Boundary

主题	参考文件
逐合约栈、精确大小写清单、标志、事件	合约架构
七个步骤的详细说明，含调用方法、调用方与检查项	发行方流程
五条强制顺序规则、回退信息目录、场景示例	强制顺序与回退信息
不可转让性、管理员强制退出、候选wrapper审核	信任模型
版本固定、映射配置、导入路径、地址解析	打包与源码
无需许可与需要协调的内容、路由申请	协调边界

Canonical Sources

标准源码

Published issuer documentation:

Contract sources, pinned:

Uniswap/v4-periphery

3245c3cb99c48fa1dc2459c3b60abc37d4294aba

—

src/hooks/permissionedPools/

(https://github.com/Uniswap/v4-periphery)

Uniswap/v4-hooks-public

7da5210f2c81a700820a6b4f585264233d91f349

—

src/permissioned-pools/PermissionedHooks.sol

(https://github.com/Uniswap/v4-hooks-public)

Uniswap/mixed-quoter

—

src/MixedRouteQuoterV2.sol

(https://github.com/Uniswap/mixed-quoter)

Addresses:

The complete, permissioned-specific table is the deploy guide's
```
#deployment-addresses
```
anchor.
The machine-readable record is
```
Uniswap/contracts
```
,
```
deployments/json/<chainId>.json
```
, under the
```
latest
```
key (https://github.com/Uniswap/contracts).
Verify every address on a block explorer for your chain before sending a transaction to it.

This skill: https://github.com/Uniswap/uniswap-ai

已发布的发行方文档：

固定版本的合约源码：

Uniswap/v4-periphery

3245c3cb99c48fa1dc2459c3b60abc37d4294aba

—

src/hooks/permissionedPools/