On 23 July 2026, Uniswap Labs published Permissioned Pools, a standardized contract set that lets restricted tokens trade inside v4 with eligibility checked at the protocol level rather than at a frontend. The easy reading of the announcement is that regulated assets can now use Uniswap's AMM infrastructure, and tokenized securities are therefore about to become liquid.
The first half is true and technically interesting. The second does not follow.
What the standard solves is a compatibility problem, and a real one. In v4 every pool shares a single PoolManager, which is precisely what a restricted token cannot tolerate: an issuer cannot sensibly allowlist a singleton that holds every other asset on the protocol, and a restricted token placed directly into that singleton can be represented as an ERC-6909 claim, which is a route around the transfer controls the token exists to enforce. The new architecture closes both problems properly. It does not supply a price, a redemption facility, an arbitrage channel, or a balance sheet willing to quote two sides — and those are what produce liquidity.
There is a second, less obvious consequence, and it is the more interesting one. Once eligibility is enforced inside the pool, the allowlist stops being a compliance setting and starts behaving like market structure. It determines who may correct a stale quote, who may hold inventory, and under what conditions either group can be removed. That is a market-design question wearing compliance clothing, and it is currently unresolved in public documentation.
Two releases, two problems
The July announcements are routinely compressed into a single "Uniswap does RWA" story. They solve unrelated problems.
On 22 July, Uniswap published DualPool, a hook built with Spark that removes the binary choice between earning swap fees and earning yield on idle inventory. Between trades the inventory sits in an ERC-4626 vault; immediately before a swap the hook withdraws what the trade requires, places it as concentrated liquidity, executes an ordinary v4 swap, and returns the remainder to the vault in the same transaction, with no keeper. This is a market-making protocol built on top of v4, and its first natural home is stablecoin FX rather than the broad RWA universe.
On 23 July came Permissioned Pools: a permissions adapter, permissioned hooks, a permissioned position manager, permission-aware routing through the Universal Router, and an issuer onboarding path for appearing in the Uniswap app and API. Also not a core upgrade — a periphery-and-hook standard built on programmability v4 already had.
The accurate framing is narrow. Uniswap did not add KYC to v4. It standardized the plumbing that lets a token with transfer restrictions live inside a singleton it cannot trust.
What the standard actually does
The adapter carries the load. PermissionsAdapter holds the underlying permissioned token and issues a one-to-one representation that exists only inside the PoolManager; on exit the wrapped unit burns and the underlying moves to the final recipient. That closes the ERC-6909 bypass and means the issuer never allowlists the singleton itself.
PermissionedHooks implements four callbacks — beforeInitialize, beforeSwap, afterSwap, beforeAddLiquidity — and exposes two independent flags: SWAP_ALLOWED and LIQUIDITY_ALLOWED. That separation is correct and underappreciated. The right to buy an asset should not automatically confer the right to be its market maker and carry two-sided inventory; those are different regulatory postures and different risk profiles, and most compliance designs collapse them.
Positions get their own treatment through PermissionedPositionManager. The LP NFT is non-transferable, minting and increasing require the liquidity flag, decreasing and burning are deliberately not gated, and the issuer can force-unwind a position. If a former holder can no longer legally receive the restricted token, the asset routes back to its own issuer rather than to the counterparty issuer of the other side of the pool. This is lifecycle machinery, not a swap allowlist, and it is more considered than the announcement conveys.
Issuer-administered, not permissionless
"Compliance enforced directly onchain" is true and incomplete. Enumerate what the system trusts and the picture sharpens: the issuer controls the allowlist checker, can halt swaps, defines approved wrappers, relies on those wrappers to report the true msgSender, and can forcibly close an LP position. Appearing in the Uniswap app or API additionally requires backend allowlisting by Uniswap Labs.
None of this is a defect. For a regulated instrument, administrative authority is the point. But the accurate label is issuer-administered onchain enforcement rather than permissionless compliance, and the difference is not cosmetic: it determines who bears which risk and who can change the rules while a market is open.
One detail matters more than it looks. Although the v4 hook itself receives the swap parameters, the standard allowlist checker is passed only the account and token address. Its eligibility decision therefore cannot depend on trade size, direction, pool state, or counterparty context. Any transaction-specific rule — position limits, concentration caps, size-dependent suitability — has to be enforced by the underlying token, the router, or separately integrated logic. The standard eligibility test knows who. It cannot condition approval on how much or in which direction, and for a regulated instrument that is frequently where the operative rule lives.
What a hook cannot supply
Set the two lists side by side. Solved: singleton compatibility, wallet eligibility at swap time, a separate eligibility regime for liquidity, non-transferable positions, issuer pause, issuer recall, two permissioned assets from different issuers in one pool, and a standard routing and quoting surface. Not solved: fair value, NAV freshness, redemption availability, the source of two-sided inventory, spread width, adverse selection, market-hours mismatch, corporate actions and trading halts, defaults and workouts, the legal status of an AMM as a trading venue, pre- and post-trade transparency, and the economic reason for anyone to provide liquidity at all. Almost every item on the second list belongs to the infrastructure stack underneath the token rather than to the trading contract, which is why a better trading contract does not shorten it.
A pool can verify the trader. It cannot invent the price, the arbitrage path, or the balance sheet.
Permissioning governs eligibility to compete for arbitrage rent
Start with LP economics. Net return is swap fees, plus asset carry actually captured and attributable to LPs, plus any vault yield, minus loss-versus-rebalancing, minus hedging cost, minus inventory financing, minus contract and vault risk, minus operational and regulatory overhead. Permissioned Pools reduce the integration and compliance line. DualPool can make idle inventory productive. Neither touches LVR, hedge cost, or the need for capital.
Loss-versus-rebalancing formalizes a simple mechanic: an AMM publishes an executable price in advance, and when the reference market moves, a better-informed trader takes the stale quote. For many RWAs with an external reference market or a periodically struck NAV, this channel can be structurally worse than for continuously traded crypto assets. The reference market closes overnight and at weekends, NAV is struck periodically, price-relevant information originates offchain, and redemption may carry cutoffs, minimum sizes, or settlement delays. The quote can be stale for hours by construction rather than for milliseconds by latency.
Now the part that is specific to permissioned venues, and where it is easy to overclaim. Competition among arbitrageurs does not return the LP's loss to the LP. More searchers typically speed up convergence and compress any individual searcher's margin, and in open markets much of the residual surplus is captured by builders and validators through MEV auctions rather than by liquidity providers. So the correct statement is not that permissioning creates adverse selection or concentrates it by definition. It is narrower:
Permissioning does not eliminate arbitrage rent. It governs eligibility to compete for it.
The consequences are conditional, and the condition is the composition of the allowlist. If a reasonably broad set of independent approved market makers holds comparable hedging capability and comparable access to primary-market redemption, meaningful competition can persist inside a restricted venue, and price correction stays contestable. If the approved set is narrow, or nominally plural but operationally concentrated — same custodian, same hedging counterparty, same redemption window, same parent — then correction becomes less contestable and the right to monetize a stale quote is effectively allocated rather than won. Either outcome is possible under the same contracts. Which one obtains is decided by an administrative list, which is why the size, independence, and capability profile of that list belong in the diligence file next to the fee tier, not in a compliance appendix.
Who supplies the liquidity?
The second question follows immediately and is asked far less often. Liquidity provision requires LIQUIDITY_ALLOWED, positions are non-transferable, and the issuer can force them closed. Who, in practice, holds them?
No production Permissioned Pool with a disclosed address, TVL, or LP composition appears in the primary sources reviewed as of 28 July 2026, so the honest answer is that this is not yet observable. What can be done is to specify the two configurations the same contracts permit, because they are economically very different.
In the first, several independent approved LPs and market makers participate, with broadly comparable access to information, hedging, and primary-market redemption. This is still a restricted market, and eligibility is still administered — but competition inside it can be real, quotes are contestable, and the curve reflects inventory committed by more than one independent balance sheet.
In the second, the issuer or an affiliate supplies the inventory while the same administrative perimeter controls the allowlist, the pause, the forced unwind, and the redemption facility. If the issuer controls market membership, supplies or appoints the balance sheet, and controls the redemption anchor, the curve automates execution without making price formation independent of the issuer. That is not a criticism of the software. An always-on, atomically settling, composable execution rail is genuinely useful. But in this configuration it is better described as an issuer-administered execution venue: the curve automates execution without establishing independent price formation.
Which configuration a given pool is in is an empirical question with a short diligence list, and — as with most tokenization projects that fail before implementation — the answers are institutional rather than technical. Who owns the inventory? How many independent LPs and arbitrageurs are admitted, and are they independent operationally as well as legally? Do they have equal access to redemption and hedging? Can the issuer change their eligibility while the market is open? Who bears the cost of a forced unwind, and at what price is the position marked?
Who receives the asset's carry?
The LP-return formula above says asset carry actually captured and attributable to LPs rather than "native asset yield," and the qualifier is doing real work. A yield-bearing underlying does not automatically mean the LP position receives the yield. Three models behave differently, and the public documentation resolves them to different depths.
Accumulating NAV or share price. The token balance is constant while NAV per share rises. Economic carry stays with the holder of the position, which is the clean case — but it imposes a pricing obligation. The AMM price has to track a mechanically rising NAV, or the drift itself becomes a predictable stale-quote opportunity for whoever is eligible to take it. Superstate's fund documentation shows how much the dealing and pricing mechanics differ even within one issuer's product line: USTB is continuously priced with market-day liquidity, while CUSHY uses periodic redemptions. The same tokenization stack does not produce the same AMM asset.
Cash or additional-token distributions. Here the adapter, not the LP, is the onchain holder of the underlying. When a distribution arrives at the adapter, how is it attributed to individual LP positions, and who is entitled to it while the representation sits inside the PoolManager? The reviewed adapter source and public documentation do not describe a general mechanism for this. I am not asserting that none exists in any specific integration; I am noting that it is not specified in the standard, which makes it an integration question every issuer has to answer explicitly.
Rebasing and balance multipliers. The adapter's backing check is nominal: availableBalance = underlying.balanceOf(adapter) - adapter.totalSupply(). A positive rebase increases the underlying balance without increasing wrapped supply; a negative rebase can push backing below wrapped supply; splits and rebase-implemented dividends need a reconciliation path. This is not hypothetical for the asset class — Securitize's DS Token supports rebasing-style lifecycle operations for dividends and splits, while DualPool's documentation explicitly lists rebasing tokens as unsupported. The correct characterization is that the standard adapter appears nominally one-to-one and public documentation does not explain how rebasing permissioned assets are reconciled. That is a due-diligence and integration gap, not a demonstrated vulnerability, and it is worth a direct question to any issuer proposing to use the standard with a rebasing instrument.
An underlying asset can generate carry without that carry being technically or legally attributable to the LP position. Until an issuer answers this in writing, the yield term in the LP's return calculation is an assumption rather than a number.
Existing architectures point to a hybrid market
The most useful evidence comes from launch partners whose published architectures already include execution mechanisms other than a continuous AMM.
BUIDL, one of the highest-profile tokenized funds in the ecosystem, is available to trade through UniswapX's RFQ framework: investors and market makers are whitelisted in advance, several professional firms compete for the quote, Securitize Markets facilitates, and the selected bilateral trade settles atomically onchain. Quotes can be available continuously, but a market maker chooses the price and manages its own inventory. That is dealer market structure with onchain settlement.
Dowgo, a Permissioned Pools launch partner, describes its core secondary-market architecture as a central order book with market makers and maker-taker economics, 24/7 T+0 settlement, and securities issued natively as ERC-3643 permissioned tokens, with DLT-TSS authorization under the EU DLT Pilot Regime still pending as of 28 July 2026.
Neither choice contradicts the new standard, and neither proves that every RWA market will look the same. What they indicate is that sophisticated participants are retaining RFQ and order-book market structure alongside permissioned AMMs. The most plausible end state on current evidence is hybrid: a primary-market facility such as issuer redemption as the price anchor, RFQ for institutional blocks, an order book or dealer market where independent price discovery is required by the asset or the regulator, and a permissioned AMM for continuous smaller conversions, collateral rebalancing, and liquidation flows.
Where the curve actually fits
I previously argued that DeFi is the missing liquidity layer for tokenized assets. I still believe that — but DeFi composability and AMM liquidity are not the same claim, and this release is what forces me to separate them properly. An asset can benefit from onchain settlement, collateral utility, automated execution, and composability without belonging on a continuous AMM curve.
Permissioned Pools make that boundary legible by separating three things that "liquidity" often blurs: an onchain infrastructure layer, an execution venue, and the mechanisms that make its quotes credible and liquid — reference pricing, inventory, and an arbitrage or redemption path. The standard delivers the first and enables the second. The third must be supplied by market participants.
So the useful question is not whether AMMs suit RWA, but what a specific asset's price anchor is, what its arbitrage or redemption channel is, and what its flow looks like. Tokenized Treasury and money-market funds fit best, conditional on frequently updated NAV, predictable redemption, low volatility, and approved participants who can close deviations — and even there the curve's role is small-ticket conversion, collateral operations, and liquidations rather than primary price discovery. Tokenized equities are an auxiliary venue at best without further controls: the reference price forms elsewhere, hedging is expensive or unavailable when that market is closed, and corporate actions and halts require lifecycle handling the standard hooks do not provide. Private credit and real estate fit a continuous curve poorly in any configuration, given infrequent model-driven NAV and workouts rather than prices after a default. That taxonomy deserves its own treatment and will get one.
The composition gap
One constraint deserves flagging because it is the least obvious and the most consequential for anyone planning to build here. Permissioned Pools and DualPool cannot be combined by enabling two hooks. A v4 pool has one hook address, which a composite implementation could in principle satisfy — but the two designs conflict on custody, not merely on callbacks. The permissioned architecture permits the adapter's representation to be held only by the PoolManager, while DualPool must hold pool currencies in its own hook or vault between trades. Those requirements are mutually exclusive.
The standard implementations are therefore not composable as deployed. A permissioned pool with productive idle inventory would require a redesigned custody and wrapping flow, permission-aware LP accounting, forced-unwind semantics for internal shares, and a new audit. The possible architecture is the subject of a separate article.
What is confirmed, and as of when
Announcements are currently outrunning production, so the status distinctions matter.
Verified as of 28 July 2026: the Permissioned Pools contracts are published in official documentation with mainnet addresses; Universal Router 2.2.0 supports permissioned pools; Superstate, Securitize, and Dowgo are design and launch partners; Dowgo intends to use the standard once DLT-TSS authorization is granted. For DualPool, the canonical factory is deployed and accepts only bit-exact builds of the audited bytecode. OpenZeppelin audited the hook between 20 May and 17 June 2026; Uniswap's security documentation reports no critical or high-severity issues and states that all findings and notes were resolved, with the full audit report published in the repository.
Not established in the reviewed primary sources as of the same date: a production pool address, Pool ID, TVL, or volume for any Permissioned Pools partner. A separate audit of the full Permissioned Pools stack was not publicly disclosed or was not located in the reviewed sources — which is not the same as saying the contracts were not audited. Spark's $150 million did migrate to v4 and is live in stablecoin pools, but Uniswap's own announcement describes the DualPool hook as the intended destination for that liquidity rather than its current venue, so "DualPool code and factory are live" is accurate while "the $150 million runs through DualPool" is not yet evidenced.
Five days after launch, the absence of production pools proves nothing about the standard; it only means anyone citing partner liquidity this week is citing an intention. The market-structure argument does not depend on that timing and will not be settled by the first pool going live.
Compliance is a predicate. Liquidity is a balance sheet. v4 reduced the cost of building a market; it did not remove the cost of making one.