How Permissioned Pools Work on Uniswap v4

Uniswap v4 is permissionless by design. Anyone can create a pool, and anyone can trade in it. For most tokens, openness is the whole point.

Tokenized funds and securities are different. Their issuers are required to control who can hold them, so the token contract rejects any transfer to a wallet that isn't on the issuer's allowlist. That rule is what makes the asset viable, and it's also what has historically kept most of these assets off AMMs.

Uniswap v4 hooks change that. With the Permissioned Pools standard, issuers can apply their own transfer restrictions directly to a Uniswap v4 pool, so only wallets they've approved can swap or provide liquidity. The protocol underneath stays the same.

The whole design comes down to one decision: the permissioned asset never enters the pool. It sits in a dedicated contract the issuer has allowlisted, and the pool trades against a virtual representation of the balance. Every time real tokens cross into or out of that contract, the issuer's rules run.

Why standard transfer rules can't see inside a pool

First, the obvious question. If the token contract already rejects transfers to unapproved wallets, why can't it go straight into a standard pool? Because a pool doesn't move tokens the way wallets do. In Uniswap v4, all balances live in one central contract, the PoolManager. Ownership moves around inside it as virtual ERC6909 balances, and LP positions are NFTs. None of that triggers the token's transfer checks, so a permissioned token could pass through a wallet that was never approved, and the pool would have no way to know.

The token contract still checks every transfer in and out of the pool. It just never sees what happens inside. That's why the allowlist has to be enforced by the pool itself, on every swap and every liquidity action.

The architecture: siloed assets and virtual representations

The architecture splits the token into two components: the physical asset and its virtual proxy.

1. The Permissions Adapter

Instead of holding the restricted token, the PoolManager holds a virtual balance created by a dedicated contract called the Permissions Adapter, the only contract authorized to hold the underlying compliant asset.

When a user swaps or adds liquidity:

1. The underlying token is deposited into the Permissions Adapter
2. The adapter holds the token and creates a virtual representation directly in the PoolManager
3. The Uniswap pool performs all mathematical and state accounting using this virtual balance, which exists solely inside Uniswap's accounting and never touches an external wallet
4. To maintain strict security, only the PoolManager is allowed to hold these virtual tokens
5. When the pool pays out, the PoolManager calls the transfer function in take to transfer out the virtual tokens. The Permissions Adapter automatically converts them back to the underlying tokens during this transfer call, sending the physical, compliant tokens to the recipient; only after verifying their compliance status

2. The Pluggable Compliance Checker

The adapter doesn't keep the allowlist itself. It queries a checker contract the issuer writes and deploys, through a standard interface. That makes the design agnostic to the underlying standard. It works the same whether the issuer uses Securitize's DS Protocol, Tokeny's ERC3643, or a custom registry. The pool never needs to know how the list is built. It only needs the verdict.

Strict enforcement via Uniswap v4 hooks

The adapter keeps the asset contained; the hook blocks unauthorized transactions before they happen. Attached at pool creation, it runs the issuer's checks on the key callbacks:

• beforeSwap: Confirms the swapper is on the allowlist, and verfies the issuer hasn't paused swapping
• beforeAddLiquidity: Confirms that the wallet is approved specifically to provide liquidity

The two permissions are separate flags. A wallet cleared to swap isn't automatically cleared to LP.

Real-world enforcement: bounded LP position recalls

In traditional markets, a transfer agent can freeze or reassign a security under legal mandate. Issuers need the same lever onchain. Through the custom Position Manager, an issuer can call unwindPosition to force-close an LP position:

1. The position's non-transferable NFT is burned.
2. The liquidity is cleanly removed from the pool.
3. The underlying assets are returned to their respective owners.

Bounds on issuer power

A critical feature of this architecture is that the issuer’s power is strictly bounded to their own asset. In a pool pairing a permissioned token with ETH or USDC, a force-close sends the unrestricted token straight back to the liquidity provider. Only the permissioned token, which the holder is no longer authorized to hold, goes to the issuer's designated address. And because LP positions are non-transferable NFTs, an unapproved wallet can't buy its way into exposure on a secondary market.

Uniswap stays permissionless

All of this lives in hooks and a wrapper contract. The core protocol is unchanged, and every other pool behaves exactly as it always has. Swaps through Permissioned Pools route like any other swap, so the standard plugs into the rest of DeFi instead of sitting beside it.

The same primitives that settle open, permissionless trades now settle highly regulated, compliant transactions. Industry leaders like Superstate, Securitize, and Dowgo are already building on the standard, and it's live on Ethereum mainnet and Sepolia today.

To dive deeper into the technical specifications, check out the Permissioned Pools documentation.