Uniswap Labs ha introdotto le Permissioned Pools per Uniswap v4, un’architettura basata su hook pensata per consentire agli emittenti di fondi tokenizzati, titoli e altri asset reali di controllare chi può negoziare o fornire liquidità in pool specifiche, lasciando permissionless il protocollo Uniswap sottostante.

Il modello affronta una tensione centrale nella finanza decentralizzata: gli asset regolamentati o con accesso controllato spesso richiedono verifiche di idoneità, mentre gli automated market maker sono progettati per la partecipazione aperta. Nel design di v4, le restrizioni si applicano solo alle pool che scelgono di utilizzare l’hook permissioned, non a Uniswap nel suo complesso.

Secondo Uniswap Labs, le nuove Permissioned Pools usano allowlist gestite dagli emittenti e applicate onchain. Solo gli indirizzi approvati possono interagire con la pool pertinente. La documentazione per sviluppatori descrive due autorizzazioni separate: SWAP_ALLOWED, che determina se un indirizzo può negoziare, e LIQUIDITY_ALLOWED, che determina se può aggiungere o rimuovere liquidità (Uniswap Developers).

Cosa significano le Permissioned Pools in Uniswap v4

Le Permissioned Pools sono costruite attorno agli hook di Uniswap v4. In questo contesto, un hook controlla ogni swap e ogni azione di liquidità rispetto a un’allowlist mantenuta dall’emittente dell’asset o dal suo operatore designato. Se un indirizzo è approvato, l’azione può procedere. Se non è approvato, la transazione viene annullata.

Gli hook sono una delle principali funzionalità di estendibilità di Uniswap v4 e consentono l’esecuzione di logiche personalizzate a livello di pool attorno ad azioni come swap e modifiche della liquidità. Questo rende il permissioning una regola specifica dell’applicazione, invece di una modifica a ogni pool del protocollo.

Il design non trasforma Uniswap in un exchange ad accesso controllato. Aggiunge invece una logica specifica per pool per asset che richiedono accesso controllato. Le pool permissionless di Uniswap restano aperte, mentre la logica permissioned si applica solo dove una pool ha scelto di adottarla.

Uniswap Labs ha descritto questa struttura nell’annuncio del 23 luglio 2026 come un modo per consentire a fondi tokenizzati e altri asset regolamentati di negoziare tramite AMM senza che il protocollo di base prenda in custodia gli asset o gestisca processi know-your-customer. L’emittente gestisce l’idoneità offchain e riflette tale stato onchain tramite l’allowlist.

Perché gli asset reali hanno bisogno di controlli di idoneità

Treasury tokenizzati, fondi del mercato monetario, note di credito privato e strumenti assimilabili ad azioni possono comportare requisiti legali, giurisdizionali o legati allo status dell’investitore. Gli emittenti potrebbero dover sapere chi sono le controparti e, in alcuni casi, conservare la possibilità di congelare, rimborsare o intervenire in altro modo in base ai documenti regolatori.

Le allowlist creano un meccanismo per portare questi requisiti nella DeFi. L’emittente determina l’idoneità fuori dal protocollo, mentre l’AMM continua a gestire pricing, inventario e regolamento. Il ruolo dell’hook è limitato a verificare se un wallet è autorizzato a partecipare.

Per trader e fornitori di liquidità, questo significa che l’accesso può richiedere una verifica con l’emittente o un registrar prima che un indirizzo possa effettuare swap o fornire liquidità. Se un indirizzo non è approvato, la pool non funzionerà per quel wallet.

Come funziona l’hook

La documentazione per sviluppatori di Uniswap descrive due impostazioni di autorizzazione distinte. SWAP_ALLOWED determina se un wallet può negoziare gli asset nella pool. LIQUIDITY_ALLOWED determina se può depositare o prelevare liquidità. Un indirizzo può avere un’autorizzazione senza l’altra, consentendo a un emittente di approvare alcuni partecipanti per il trading ma non per la fornitura di liquidità.

Le posizioni di liquidità nelle pool permissioned sono rappresentate da NFT, ma tali NFT di posizione non sono trasferibili. La documentazione afferma che le chiamate a transferFrom e safeTransferFrom vengono annullate con TransferDisabled. La restrizione è pensata per impedire che una posizione LP approvata venga trasferita a un indirizzo o a un’entità che non ha superato il processo di idoneità dell’emittente.

L’admin dell’adapter ha anche la possibilità di chiamare unwindPosition per chiudere una posizione LP quando richiesto dalla policy. In pratica, ciò significa che l’emittente o l’operatore designato detiene specifici poteri amministrativi definiti a livello di contratto. Uniswap stesso non approva investitori né gestisce file KYC; l’hook legge l’allowlist e applica l’esito per la pool.

Cosa cambia per trader e fornitori di liquidità

Per i trader, il cambiamento più immediato è un controllo di accesso prima dell’esecuzione. Se un wallet non è nella relativa allowlist, uno swap tramite la pool permissioned fallirà. Alcune interfacce frontend potrebbero essere in grado di verificare l’idoneità in anticipo e invitare gli utenti a richiedere l’approvazione.

Il regolamento resta non custodial. Gli utenti continuano a firmare transazioni dai propri wallet, e il pricing resta basato sull’AMM. Slippage, profondità della liquidità e commissioni della pool continuano a contare nello stesso modo in cui contano nelle altre pool AMM. La differenza è che solo gli indirizzi approvati possono interagire con la pool.

Per gli LP, la non trasferibilità degli NFT di posizione è un cambiamento operativo importante. Le entità che si basano sul trasferimento di posizioni LP tra wallet, conti o affiliate dovrebbero tenere conto della restrizione. Gli LP devono inoltre comprendere i diritti di unwind dell’emittente, incluse le circostanze in cui l’admin dell’adapter può forzare la chiusura di una posizione.

Gli emittenti possono anche indirizzare i programmi di liquidità verso specifici market maker o allocator. Questo può modellare l’accesso alla pool e influenzare chi è in grado di fornire profondità per l’asset.

Trade-off di conformità e neutralità del protocollo

Le pool permissioned rappresentano un compromesso tra architettura DeFi aperta e requisiti degli asset regolamentati. Gli emittenti di determinati asset potrebbero non essere in grado di supportare un mercato onchain senza controlli di accesso. L’architettura a hook di Uniswap v4 consente a tali controlli di esistere a livello di pool, mantenendo neutrale il protocollo di base.

L’approccio separa le responsabilità. Gli emittenti gestiscono le allowlist e gli obblighi di conformità, mentre il protocollo fornisce l’infrastruttura di mercato. All’interno di una pool approvata, funzioni DeFi come pricing AMM, routing e contabilità onchain possono comunque operare, soggette alle restrizioni dell’hook.

Questa separazione è rilevante perché mantiene le decisioni di conformità legate all’asset e al suo emittente, invece di incorporare in Uniswap un requisito universale di identità. Significa anche che i partecipanti devono valutare ogni pool permissioned in base ai propri termini, poiché policy e controlli amministrativi possono variare da un emittente all’altro.

Il design introduce anche dei trade-off. L’admin dell’adapter diventa un’importante superficie di rischio, perché un uso improprio o la compromissione delle chiavi amministrative potrebbe incidere su una pool. Gli utenti affrontano inoltre attriti aggiuntivi derivanti dai processi KYC e dall’associazione del wallet. La privacy è un’altra considerazione, perché i wallet collegati a identità verificate possono rendere più semplice associare l’attività onchain a una persona o entità.

RWA, appchain e implementazione cross-chain

Uniswap ha collegato il lancio delle pool permissioned alla più ampia crescita degli asset tokenizzati e dell’attività di mercato cross-chain. In un post su Substack, Uniswap ha dichiarato che la sua implementazione sulla nuova Robinhood Chain ha superato $6 miliardi di volume in una settimana, inclusa la sua prima giornata da $1 miliardo.

Le pool permissioned si inseriscono in questo ambiente cross-chain perché gli emittenti vogliono accesso a sedi di liquidità e interfacce utente mantenendo al contempo controlli a livello di asset. Se Uniswap v4 è distribuito su una chain e un emittente può mantenere un’allowlist, la policy di accesso della pool può viaggiare con l’asset tramite il design dell’hook.

Uniswap ha anche citato il movimento dell’ecosistema verso funzionalità abilitate dagli hook di v4. Nei suoi ultimi aggiornamenti, Uniswap ha affermato che Spark ha spostato circa $150 milioni di liquidità in stablecoin in vista di funzionalità come DualPool, che utilizza la stessa architettura a hook su cui si basano le pool permissioned.

Insieme all’annuncio di Uniswap del 23 luglio, questi sviluppi mostrano come gli asset regolamentati possano cercare liquidità AMM e componibilità pur operando entro guardrail definiti dagli emittenti.

Rischi e modalità di errore

Le pool permissioned aggiungono percorsi di codice supplementari tramite gli hook, rendendo importanti per i partecipanti la revisione dei contratti, gli audit e i controlli sugli upgrade. Gli utenti dovrebbero capire se il bytecode distribuito corrisponde al codice sottoposto ad audit e se l’hook o l’adapter possono essere aggiornati.

Anche i poteri amministrativi richiedono un esame attento. L’ambito dell’autorità dell’admin dell’adapter può includere funzioni come unwindPosition, modifiche dei parametri o altri controlli a seconda dell’implementazione. Time lock, configurazioni multisig e policy scritte dell’emittente possono incidere in modo sostanziale sul rischio.

L’accuratezza dell’allowlist è un altro potenziale problema. Se un registro offchain è in ritardo o errato, un indirizzo può essere bloccato o rimanere approvato quando il suo status avrebbe dovuto cambiare. Anche modifiche giurisdizionali o di policy dopo che un utente ha fornito liquidità possono alterare l’idoneità di un indirizzo.

Il routing può creare ulteriori casi limite. Gli aggregatori possono tentare di instradare transazioni attraverso una pool permissioned. Se l’indirizzo dell’utente non è in allowlist, la transazione verrà annullata a meno che il frontend o il router non filtri la pool in anticipo.

Checklist prima di usare una pool permissioned

I partecipanti che valutano una pool permissioned dovrebbero esaminare l’identità dell’emittente, lo stato di registrazione e la documentazione pubblica, ove applicabile. Dovrebbero inoltre analizzare la policy dell’allowlist, incluso chi approva gli indirizzi, quali documenti sono richiesti, quanto tempo richiede l’approvazione e come vengono gestite le revoche.

Anche il codice dell’hook, lo stato degli audit e il bytecode distribuito sono elementi centrali. Gli utenti dovrebbero identificare i poteri esatti dell’admin, incluso se l’admin può mettere in pausa l’attività, chiamare unwindPosition o modificare parametri. Gli LP dovrebbero esaminare commissioni, incentivi, lockup e le implicazioni degli NFT di posizione non trasferibili.

Il supporto della chain è un altro fattore operativo. Una pool può essere disponibile solo dove Uniswap v4 è distribuito e dove un emittente sceglie di lanciarla. Anche sistemi di custodia, workflow di conformità e strumenti di routing devono supportare la chain e la struttura della pool pertinenti.

Confronto con altre strutture di mercato

Gli utenti i cui mandati vietano sedi con accesso controllato da admin possono aggirare le pool permissioned tramite routing alternativo. Molti aggregatori consentono agli utenti di inserire in blacklist indirizzi specifici di pool.

Domande frequenti

Le pool permissioned rendono Uniswap un exchange regolamentato?

No. Il protocollo di base resta permissionless. I controlli di autorizzazione risiedono in hook specifici per pool controllati dall’emittente. L’emittente gestisce KYC e policy offchain ed espone un’allowlist che l’hook può leggere.

Come può un utente essere inserito in allowlist per negoziare o fornire liquidità?

Ogni emittente definisce il proprio processo. In una struttura tipica, un utente invia informazioni KYC e collega un indirizzo wallet. Una volta approvato, l’indirizzo compare nell’allowlist e può effettuare swap o fornire liquidità senza che il controllo di autorizzazione annulli la transazione.

Gli LP possono trasferire o vendere i loro NFT LP?

Non nelle pool permissioned. Gli NFT di posizione sono non trasferibili per progettazione. Secondo la documentazione per sviluppatori, le chiamate per spostarli vengono annullate, e l’admin dell’adapter può effettuare l’unwind delle posizioni se la policy lo richiede.

Cosa succede se un aggregatore instrada attraverso una pool permissioned?

Se l’indirizzo dell’utente non è in allowlist, la transazione verrà annullata. I frontend possono prefiltrare questi percorsi, e gli utenti possono anche disabilitare pool specifiche nelle impostazioni del router dove supportato.

Questo incide sui titolari di token UNI o sulle commissioni del protocollo?

Le pool permissioned non modificano direttamente il fee switch o la governance del protocollo core. Sono hook opzionali a livello di pool. Qualsiasi effetto su volumi o flussi di commissioni dipende dall’adozione da parte degli emittenti e dalla domanda dei trader.

Le pool permissioned sono disponibili su ogni chain in cui opera Uniswap?

Le pool permissioned sono una funzionalità di Uniswap v4. La disponibilità dipende da dove v4 è distribuito e da dove un emittente sceglie di lanciare. Gli utenti devono verificare il supporto della chain e l’integrazione con la custodia prima dell’onboarding.

Le pool permissioned sono solo per i titoli?

No. Sono progettate per asset che richiedono controlli di idoneità, che possono includere fondi, prodotti strutturati e altri token disciplinati da regole di accesso.

Disclaimer: Questo articolo è fornito esclusivamente a scopo informativo. Non è offerto né inteso come consulenza legale, fiscale, di investimento, finanziaria o di altro tipo.