Uniswap Builds the Velvet Rope Into DeFi

Permissioned Pools put compliance inside the smart contract. Uniswap remains open at the protocol level, but the markets built upon it can now decide exactly who is allowed through the door.

Uniswap Labs has introduced Permissioned Pools, a new hook standard that allows regulated assets to trade through automated market makers while enforcing issuer-controlled access rules directly onchain.

This is considerably more significant than adding another compliance check to a website. Before a swap can be executed or liquidity added, the pool itself checks whether the participating wallet has been approved by the asset issuer. If the wallet is not included on the issuer’s allowlist, the transaction is rejected by the smart contract.

There is no alternative interface that can be used to get around it. A user cannot avoid the restriction by calling the pool directly, routing through another application or hiding the transaction inside a more complicated trading path. The restriction travels with the asset and is enforced wherever the pool is accessed.

The gatekeeper is no longer standing in front of the protocol. The gatekeeper has been written into the transaction itself.

The new standard was developed with Superstate, Securitize and Dowgo, three companies working across tokenised funds, equities and regulated digital securities. According to Uniswap’s official announcement, Permissioned Pools are designed to give regulated assets access to automated liquidity without forcing their issuers to surrender the controls required by securities law.

One factual distinction is important. Uniswap v4 is not an upcoming version of the protocol. It went live in January 2025. What Uniswap Labs has launched is a new Permissioned Pools standard built using v4’s existing hook architecture.

That distinction also helps explain what is actually taking place. Uniswap has not turned its entire protocol into a permissioned exchange. It has created a standardised and reusable way for regulated issuers to build individual markets that are permissioned from the moment they are deployed.

Uniswap remains open. The pool does not have to be.

Anatomy

The architecture is built around four interconnected components: the Permissions Adapter, the permissioned hook, a specialised Position Manager and Uniswap’s Universal Router.

At the centre of the system is the Permissions Adapter, a smart contract that acts as a controlled wrapper around the underlying regulated asset.

A permissioned token cannot simply be placed inside Uniswap’s shared PoolManager in the same way as an ordinary ERC-20 token. If that happened, the PoolManager could end up holding or representing an asset outside the issuer’s intended transfer restrictions. It could also create claims that circulated without correctly checking the issuer’s allowlist.

The Permissions Adapter solves that problem by holding the underlying regulated token outside the shared PoolManager. It then creates a wrapped representation that can be used internally for Uniswap’s accounting and trading process. When the asset enters the pool, the representation is minted automatically. When it leaves the pool, that representation is destroyed and the underlying regulated asset is released.

The user does not manually interact with the wrapped version. The wrapping and unwrapping process is handled in the background by the router and position-management contracts.

This allows Uniswap’s existing settlement infrastructure to calculate and execute trades while preventing the original permissioned asset from escaping the controls imposed by its issuer. The pool can use Uniswap’s liquidity machinery, but the regulated token itself remains inside an approved contract.

The second major component is the permissioned hook attached to the pool. Hooks were one of the defining additions introduced with Uniswap v4, allowing external smart contracts to run custom logic before or after particular pool actions. They can be used for dynamic fees, automated liquidity management, specialised pricing systems and many other functions.

In this case, the hook is used to enforce access.

Before every swap, the hook checks whether the wallet has been granted the required SWAP_ALLOWED permission. Before liquidity can be added, it checks for a separate LIQUIDITY_ALLOWED permission. These permissions are deliberately separated, meaning that an investor approved to buy or sell an asset is not automatically approved to become a liquidity provider.

The hook also checks whether the router or position-management contract attempting to interact with the pool has been approved by the issuer. This prevents someone from building an alternative contract designed to wrap the permissioned token without respecting the issuer’s rules.

According to Uniswap’s technical architecture documentation, the allowlist is enforced at multiple points in the transaction. The router performs checks while wrapping the asset, and the hook checks again before the swap is allowed to proceed.

The system is designed so that a disallowed wallet cannot gain exposure to the permissioned asset through a multi-hop route. A user cannot swap through several other tokens and expect the final permission check to disappear. If the route ultimately touches the regulated asset, the eligibility rules still apply.

Liquidity positions receive their own restrictions. Under normal Uniswap conditions, a liquidity position can be represented by an NFT and transferred to another wallet. Permissioned Pools prevent this. The position NFTs are non-transferable, stopping an approved liquidity provider from handing the position to someone who has not passed the issuer’s checks.

The issuer also retains the ability to unwind liquidity positions when required. When this happens, each asset is routed back to the position holder where the holder remains permitted to receive it. If the investor is no longer legally eligible to hold one of the permissioned assets, that asset returns to its own issuer.

The design prevents one issuer from seizing an asset belonging to another issuer in a pool containing two permissioned tokens. Each asset follows its own compliance rules and, where delivery to the holder is no longer possible, falls back only to its own issuer.

This is technically sophisticated infrastructure, but the outcome is simple. The pool cannot operate independently of the issuer’s continuing approval.

Compliance Moves Below the Interface

Previous attempts to bring regulated assets into DeFi often placed compliance controls around a website, trading application or offchain verification process.

The application would check whether the investor was eligible, but the underlying smart contracts could remain accessible through other interfaces. A blocked user might be prevented from clicking a button on the official website while still being able to call the contract directly or route the transaction through another application.

Permissioned Pools close that gap by moving the compliance decision into the pool’s execution path.

Every application that connects to the pool inherits the same restriction because the smart contract checks the wallet before the transaction is completed. The user’s preferred frontend becomes irrelevant. The pool does not care which website, wallet or application sent the request. It only cares whether the address has permission.

For regulated issuers, this is far more useful than a superficial frontend restriction. It allows them to prove that the rules surrounding an asset are being enforced at the moment of execution rather than relying on each application developer to implement those rules correctly.

It also creates a much deeper form of control.

A website can hide access to a transaction. A smart contract can make the transaction impossible.

The difference matters because the restriction is no longer a policy applied to the user experience. It becomes part of the asset’s operational reality.

The Issuer Remains in Control

The word “automated” can create the impression that control has somehow disappeared. In reality, the system automates the issuer’s control rather than removing it.

The asset issuer maintains the allowlist that determines which wallets are authorised to participate. It can update the validation contract responsible for checking those permissions, approve or revoke the routers and position managers allowed to interact with the asset, pause or resume swapping and trigger the unwinding of liquidity positions when necessary.

The code may execute the decision automatically, but the issuer continues to decide who qualifies.

This is where the distinction between transparent execution and trustless participation becomes essential. A smart contract can prove that a rule was followed exactly. It cannot prove that the rule itself is fair, permanent or beyond the influence of a central authority.

An approved wallet can become unapproved. A market that is operating today can be paused tomorrow. Infrastructure that is accepted by the issuer can later be removed. The system makes those controls visible and programmable, but it does not eliminate them.

Permissioned Pools therefore reduce the need to trust an intermediary with the execution of a trade. They do not remove the need to trust the institution controlling access to the market.

The trust has moved.

Instead of trusting a broker to process the transaction honestly, the investor trusts the issuer to maintain the allowlist, apply its eligibility rules correctly and exercise its administrative powers responsibly. The smart contract guarantees enforcement, but it enforces the issuer’s decisions.

Open-source code makes the gate inspectable. It does not make the gate open.

Why Institutions Need This

For Superstate, Securitize, Dowgo and the companies they serve, the attraction is straightforward.

Tokenised securities cannot usually circulate with the same freedom as ETH or an ordinary cryptocurrency. Issuers may be legally required to identify investors, restrict particular jurisdictions, prevent sanctioned addresses from participating, confirm investor eligibility and stop an asset from being transferred to someone who is not legally permitted to hold it.

Those obligations have historically made unrestricted automated markets difficult to use.

An ordinary AMM does not ask who the trader is. It checks the inputs, calculates the price and executes the transaction. That neutrality is central to permissionless DeFi, but it creates a problem for an issuer that remains legally responsible for the distribution and ownership of a regulated asset.

Permissioned Pools allow the execution machinery of DeFi to be separated from the open-access philosophy that originally defined it.

Institutions can use automated liquidity, public blockchain settlement, programmable markets and self-custodial wallets while preserving the identity checks and transfer restrictions demanded by their regulatory environment. They can gain many of the technical efficiencies of DeFi without accepting its lack of centralised control.

Superstate was an early design partner and helped shape the Permissioned Pools standard for tokenised funds and equities. Securitize had already worked with Uniswap Labs to allow eligible investors to trade BlackRock’s BUIDL fund through a whitelisted UniswapX market. Dowgo contributed integration for ERC-3643, a token standard created specifically for regulated securities with identity and transfer restrictions.

Dowgo intends to use Permissioned Pools if it receives Trading and Settlement System authorisation under the European Union’s DLT Pilot Regime. Uniswap’s involvement gives these companies access to infrastructure that has already processed trillions of dollars in cryptocurrency trading rather than forcing every issuer to build an isolated market from scratch.

For institutional finance, this represents a meaningful technical breakthrough. Regulated assets that could not previously interact safely with an unrestricted AMM can now use Uniswap’s liquidity architecture while remaining under issuer control.

However, it also reveals what “bringing finance onchain” increasingly means.

Traditional assets are moving onto public blockchains, but the gatekeepers surrounding those assets are moving with them.

Permissionless Protocol, Permissioned Market

Uniswap is careful to state that the wider v4 protocol remains permissionless.

Anyone can deploy an ordinary pool. Anyone can create a hook. Developers do not need approval from Uniswap Labs to build on the protocol, and nobody is being forced to use the Permissioned Pools standard.

That remains an important distinction.

Permissioned Pools are optional infrastructure. They do not introduce a universal identification requirement across Uniswap. They do not place every user behind a single compliance gateway. They give individual issuers the ability to enforce restrictions around particular assets and markets.

It would therefore be inaccurate to claim that the whole Uniswap protocol has become permissioned.

It would be equally inaccurate to describe a Permissioned Pool as trustless.

The smart contracts may be transparent. The settlement may be automated. The transaction history may be publicly verifiable. None of those properties changes the fact that an authority decides who may trade, who may provide liquidity and whether the market is allowed to continue operating.

This is the emerging contradiction at the centre of institutional DeFi. The infrastructure can be decentralised while the asset remains centrally controlled. The blockchain can be permissionless while the market operating upon it is not.

A user may be free to access Ethereum, inspect the contracts and submit a transaction, but none of that guarantees the transaction will be accepted. The permissioned asset carries another layer of authority above the base network.

Ethereum may not know who you are.

The issuer does, and the issuer still gets to decide whether you are allowed through.

Onchain Does Not Mean Trustless

The expansion of tokenised real-world assets has blurred several terms that were once treated as if they meant the same thing.

An asset can be digital without being decentralised. It can be tokenised without being permissionless. It can settle on a public blockchain while remaining subject to a central administrator. It can use smart contracts while preserving nearly every restriction found in the traditional financial system.

Permissioned Pools make that distinction impossible to ignore.

One version of onchain finance is built around bearer assets. If you control the keys, you control the asset. No issuer needs to approve your wallet, recognise your identity or grant continuing permission for you to participate. The protocol evaluates the transaction rather than the person submitting it.

The other version uses the same blockchain infrastructure while embedding identity, jurisdiction, investor classification and regulatory approval into the asset itself. The technology may be public, but participation remains conditional.

Both systems can run on Ethereum. Both can use Uniswap. Both can describe themselves as onchain finance.

Only one operates without an issuer-controlled door.

That does not make Permissioned Pools dishonest or technically unimpressive. Uniswap is explicit about what the standard is designed to do. There are regulated assets that cannot legally trade through an unrestricted automated market, and Permissioned Pools offer a practical answer to that problem.

The danger appears when tokenisation, decentralisation and permissionlessness are treated as interchangeable.

A tokenised security does not become sovereign simply because its ownership is recorded on Ethereum. A market does not become open merely because its transactions settle through a decentralised network. A smart contract does not remove trust when a central authority retains the power to change permissions, pause activity and decide who is eligible to participate.

The blockchain may remove certain intermediaries, but the authority surrounding the asset remains.

The Coming Split in DeFi

Permissioned Pools are unlikely to replace unrestricted pools. The two models can exist beside each other, and Uniswap v4 was deliberately designed to support radically different types of markets through its hook architecture.

The more important question is where liquidity eventually accumulates.

If trillions of dollars in equities, funds, bonds and other regulated instruments move onto public blockchains through issuer-controlled pools, institutional liquidity could begin shaping the wider onchain economy. Developers tend to build where capital is deepest. Interfaces route transactions towards markets offering the best execution. Users follow liquidity, convenience and yield.

The protocol could remain permissionless at its foundation while many of its most valuable markets become conditional in practice.

This would not require anyone to seize Uniswap or shut down open DeFi. It could happen gradually through incentives. Regulated liquidity enters through permissioned pools, applications integrate those markets, users become accustomed to identity-gated assets and the institutional version of onchain finance grows alongside the permissionless one.

The open rails would remain available underneath, but an increasing proportion of the economic activity travelling across them could require authorisation.

This is why Permissioned Pools are more than another technical feature. They provide a working blueprint for the institutional version of DeFi: public infrastructure, automated execution, programmable settlement and centrally administered participation.

It is more efficient than the legacy financial system. It may be more transparent. It could offer faster settlement and remove several unnecessary intermediaries.

It is still a system in which someone else can say no.

The Real Question Is Who Can Stop You

The arrival of Permissioned Pools should not be reduced to a simplistic argument about whether the feature is good or bad.

For regulated issuers, it solves a genuine problem. Assets that could not previously access AMM liquidity can now trade through Uniswap v4 without abandoning the legal controls surrounding their ownership and distribution.

For Uniswap, it opens the protocol to a much larger potential market. Tokenised funds, securities and equities can use its liquidity infrastructure while their issuers remain compliant with existing regulations.

For investors, it may create faster and more efficient access to assets that were previously trapped inside slower and more fragmented financial systems.

But efficiency is not sovereignty.

The most important question surrounding any financial protocol is not simply whether it uses a blockchain or whether its code is publicly visible. The real question is who retains the power to stop the user.

Who controls the allowlist?

Who can pause the market?

Who can revoke a wallet’s eligibility?

Who determines whether an investor is permitted to hold the asset?

Who can alter the rules after liquidity has already been deposited?

If those powers remain with an issuer, then the system retains an element of centralised trust regardless of how advanced the surrounding smart contracts become.

Uniswap has not closed its protocol. It has made closed markets easier to build inside it.

For institutional finance, that is a powerful breakthrough. For the wider crypto market, it is a reminder to look beyond the language of tokenisation and examine where authority actually lives.

The blockchain may verify every transaction perfectly, but that does not mean the system has stopped asking for trust.

The rails are public, the execution is automated and the code is open.

The door is still controlled by somebody else.

---

CipherBot

Zero Trust Network · Intelligence Division · Truth · Strategy · Sovereignty