Not on a plain public pool: anyone could receive the token, breaking transfer restrictions, and a compliant security token would revert. A permissioned AMM using Uniswap v4 hooks that check an allowlist before each swap makes it workable.
The mechanics matter more than the headline. Here is where a public AMM breaks and what design actually holds.
Why
A security token enforces compliance at the transfer layer. Standards like ERC-3643 gate every transfer against an on-chain identity and eligibility check; ERC-7943 (uRWA) generalizes the same idea. If the receiver is not an eligible, verified holder, the transfer reverts.
A plain Uniswap pool assumes tokens move freely to anyone who swaps. Drop a transfer-restricted token into a public pool and one of two things happens. Either the pool contract is not an approved holder and every swap reverts, so nothing trades. Or you whitelist the pool itself, the tokens land in the pool, and then any wallet on earth can swap in and receive a security it was never eligible to hold. That defeats the lockup and eligibility rules the token exists to enforce.
The edge cases
Uniswap v4 changes the equation with hooks: contracts that run your own logic at defined points in a pool’s lifecycle, including a beforeSwap callback that fires before a swap settles. A permissioned AMM puts a compliance check there. The hook reads the swapper’s identity or KYC attestation, confirms they are on the allowlist, and only then lets the swap proceed. Both sides of the trade stay inside the eligible set, so the token’s own transfer check never has to revert.
That design is real, but be honest about its limits:
- Liquidity fragmentation. A permissioned pool only trades among verified wallets. It cannot share liquidity with the open market, so depth is thin and price discovery is weak.
- Who provides LP. Public pools rely on anonymous liquidity providers chasing fees. For a security, every LP must also be an eligible holder. That is a small, screened group, not the retail crowd Uniswap is built on.
- The wrapper does not disappear. Making a token “tradeable on Uniswap” is a plumbing choice. It removes none of the securities-law obligations: the offering exemption, holder eligibility, and transfer restrictions all still apply. A hook enforces those rules; it does not waive them.
What this means for your structure
If you need secondary liquidity for a tokenized security, the venue is not the constraint, the eligibility set is. A v4 permissioned pool is one tool. A regulated ATS or broker-dealer venue is another, often with deeper compliant liquidity. Decide who is allowed to hold and trade first, then pick the venue that enforces it.
Stobox enforces compliance at the token transfer layer, backs ERC-7943 (uRWA), and works with ERC-3643. We issue security tokens primarily on Base, and also on Arbitrum, Canton, and other EVM chains. Whether a permissioned AMM fits depends on your holder base and jurisdiction, not on the AMM alone.
Gene Deyev’s take
People keep asking which venue makes a security token “tradeable,” and that is the wrong first question. The token already decides who may hold it at the transfer layer; a v4 hook or an ATS is just plumbing that reads the same eligibility set. Build that allowlist right — non-custodial, portable, and enforced in the token itself — and the venue becomes a swappable detail. Get it wrong and no amount of hook logic saves you: you have either a pool that reverts on every trade or a security leaking to wallets that were never eligible.
— Gene Deyev, CEO & Co-Founder, Stobox. Co-author of the Stobox Tokenization Framework and the STV3 protocol; ERC-7943 backer; SEC Crypto Task Force roundtable participant (2025).
Related questions
- How do you provide liquidity for a security token?
- ERC-3643 vs ERC-7943: which transfer-restriction standard?
- How do you choose a tokenization platform?
Last updated: 2026-07-12.