Jupiter

Che cos’è Jupiter?

Jupiter è un aggregatore di exchange decentralizzati e una suite di trading nativa di Solana che ottimizza l’esecuzione del trading on-chain instradando gli ordini tra molteplici sedi e programmi di liquidità, agendo di fatto come un “order router” per la DeFi su Solana piuttosto che come un DEX a singola sede. Il problema principale che affronta è semplice: la liquidità su Solana è frammentata tra AMM, pool a liquidità concentrata e programmi di market making personalizzati, e gli swap “ingenui” possono soffrire di pricing sfavorevole e slippage; il vantaggio competitivo di Jupiter sta nel fatto che internalizza la complessità del routing e concentra la distribuzione essendo il percorso di swap predefinito integrato in wallet e applicazioni, ottenendo così un vantaggio persistente in termini di dati, integrazioni e flusso di utenti (vedi la panoramica del prodotto su jup.ag e descrizioni di terze parti come l’articolo esplicativo di CoinGecko su Jupiter as a Solana “superapp”.

In termini di struttura di mercato, Jupiter viene discusso meno come un L1 e più come un’infrastruttura di trading critica all’interno del livello applicativo di Solana: il suo prodotto di aggregazione è uno strato di distribuzione ed esecuzione, mentre moduli adiacenti come i perpetual lo estendono a una classe di venue a maggiori commissioni e rischio più elevato.

All’inizio del 2026, dashboard pubblici e fonti di dati di mercato collocavano comunemente il token JUP nella parte bassa dell’universo delle large-cap (per esempio, CoinMarketCap elencava JUP intorno alla posizione #70–#80 per capitalizzazione di mercato al momento della rilevazione), mentre le fonti di analisi DeFi continuavano a mostrare Jupiter come uno dei protocolli Solana più grandi per collaterale bloccato e generazione di commissioni, con TVL a livello di protocollo spesso citata nell’ordine di alcuni miliardi di dollari USA, a seconda della metodologia e delle inclusioni.

Chi ha fondato Jupiter e quando?

Jupiter è emerso durante la fase di sviluppo DeFi di Solana successiva al 2021, quando l’esecuzione a bassa latenza e le transazioni economiche hanno creato un ambiente fertile per primitive di routing ordini e aggregatori che si erano già dimostrate durevoli su Ethereum (ad esempio 1inch). Il progetto è stato pubblicamente associato a un fondatore pseudonimo noto come “Meow” e ha successivamente formalizzato la governance comunitaria tramite la Jupiter DAO insieme al lancio del token di governance JUP nel gennaio 2024 attraverso il primo ciclo di airdrop “Jupuary” e l’airdrop di gennaio 2025.

Nel tempo, la narrativa su Jupiter si è ampliata da “miglior router di swap per il prezzo” a “trading full-stack su Solana”, trainata da due dinamiche che si rinforzano a vicenda: in primo luogo, la distribuzione dell’aggregatore (integrazioni con i wallet e routing via API) funge da imbuto verso prodotti a maggiore valore; in secondo luogo, i derivati on-chain e i prodotti strutturati su Solana sono maturati a sufficienza da sostenere perps e pool di liquidità in stile vault.

Questa espansione è visibile nel modo in cui i provider di analytics ora categorizzano Jupiter su più verticali (aggregazione spot, perps, strumenti DCA/ordini limite, wrapper legati allo staking e lending) e nel modo in cui la governance e il design del token hanno cercato sempre più di collegare il token al più ampio “ecosistema” piuttosto che a un’unica linea di commissioni sugli swap (come riflesso nella scomposizione da parte di DefiLlama di fee e ricavi tra i vari moduli di Jupiter e nelle successive analisi sui buyback finanziati dalle commissioni discusse in occasione degli annunci dell’era Catstanbul).

Come funziona la rete Jupiter?

Jupiter non è una rete di base-layer autonoma e non esegue un proprio meccanismo di consenso distinto; è un protocollo a livello applicativo distribuito su Solana, che eredita il set di validatori e l’ambiente di esecuzione Proof-of-Stake di Solana. In pratica, le proprietà di “rete” di Jupiter sono quelle di Solana: throughput, latenza e liveness sono principalmente funzioni della decentralizzazione dei validatori di Solana, della diversità dei client e del comportamento del runtime, mentre gli smart contract di Jupiter e le componenti off-chain (logiche di routing, quotazione, API e interfacce utente) determinano la qualità di esecuzione e l’esperienza utente.

Questa distinzione è importante a livello istituzionale perché i rischi tecnici dominanti non riguardano solo la correttezza degli smart contract, ma anche la congestione a livello Solana, le dinamiche delle priority fee, l’integrità degli oracle per i derivati e l’affidabilità degli RPC: variabili in parte esogene alla codebase di Jupiter ma che influiscono direttamente sulla qualità del servizio (DefiLlama caratterizza esplicitamente la Jupiter Perpetual Exchange come una venue per perps LP-to-trader basata su prezzi da oracle, illustrando la dipendenza dagli input degli oracle e dall’esecuzione su Solana).

Tecnicamente, il differenziale di Jupiter si comprende meglio come pathfinding e costruzione delle transazioni sotto i vincoli del runtime parallelizzato di Solana: il router cerca tra le venue, suddivide gli ordini e seleziona i percorsi che ottimizzano il prezzo di esecuzione effettivo gestendo al contempo slippage e probabilità di fallimento. Il prodotto perps introduce ulteriori livelli tecnici e di rischio, tra cui la scelta degli oracle, la contabilità del collaterale, le meccaniche di liquidazione e (per i design supportati da LP) la robustezza del pool di liquidità che prende il lato opposto del PnL dei trader; questi sistemi sono sensibili alla sicurezza anche quando la chain di base funziona normalmente.

Le note metodologiche di DefiLlama e la ripartizione dei ricavi per la venue dei perps evidenziano che l’economia dei perps di Jupiter è intrecciata con le strutture degli LP e i flussi di tesoreria, il che rende la governance degli smart contract e dei parametri di rischio particolarmente rilevante rispetto a un semplice router di swap senza stato.

Quali sono i tokenomics di JUP?

JUP è nato come token di governance con un’ampia supply massima e un esplicito piano di distribuzione comunitaria pluriennale tramite airdrop annuali “Jupuary”, per poi muoversi verso una supply massima dichiarata inferiore dopo una narrativa molto pubblicizzata di riduzione/bruciatura dell’offerta. All’inizio del 2026, i principali siti di dati di mercato mostravano comunemente una supply massima effettiva di circa 7 miliardi (anziché l’iniziale impostazione a 10 miliardi), insieme a una supply circolante nell’ordine dei pochi miliardi; per esempio, la pagina di Jupiter su CoinMarketCap riportava una max supply di 7B e una supply circolante di circa 3,2B al momento della rilevazione, e metteva anche in evidenza il dettaglio operativo importante che esistono ticker “JUP” dal nome simile per asset non correlati, una fonte non banale di confusione retail e rischio di igiene dei dati.

Dal punto di vista della diluizione, i tracker di token unlock di terze parti e le pagine di ricerca degli exchange continuavano a segnalare unlock ricorrenti e cliff periodici più ampi, il che implica che, anche con una riduzione effettiva della supply, il token presenta ancora emissioni/unlock futuri significativi rispetto alla base circolante (si vedano, ad esempio, le analisi di ricerca degli exchange che riassumono i calendari di unlock del 2026 e la necessità di trattare le notizie sui “burn” come distinte dal float circolante effettivo).

L’utilità e la cattura di valore sono più complesse del semplice schema “le fee vanno al token”, e questa complessità è parte integrante del modello: Jupiter ha sperimentato incentivi alla partecipazione alla governance tramite gli Active Staking Rewards (ASR) e, separatamente, narrative di buyback o costruzione di riserve finanziate dalle commissioni. La documentazione ufficiale di Jupiter descrive gli ASR come un programma trimestrale finanziato dall’allocazione comunitaria, con modifiche alle regole durante le pause di governance che hanno spostato le ricompense verso tutti gli staker piuttosto che solo verso i votanti attivi, indebolendo il legame diretto tra lavoro di governance e ricompensa e rendendo lo staking più simile a una spesa di incentivo generalizzata in determinati periodi, come indicato dal supporto Jupiter.

Nel frattempo, le pagine metodologiche sui ricavi di DefiLlama e i report di terze parti relativi agli annunci dell’era Catstanbul descrivono un modello in cui una parte dei ricavi del protocollo viene destinata a flussi collegati ai detentori del token, inclusi buyback o una contabilizzazione come “holders revenue”; a livello istituzionale, la domanda analitica chiave è se tali flussi siano discrezionali (controllati da governance/team), quanto siano verificabili on-chain e se persistano nei periodi di mercato ribassisti, quando i volumi e la cattura di commissioni si comprimono.

Chi utilizza Jupiter?

La maggior parte dell’utilizzo di Jupiter è meglio classificata come attività centrata sul trading piuttosto che come “utilità non finanziaria”: la funzione on-chain dominante è la discovery del prezzo e la riallocazione degli asset all’interno della DeFi su Solana, con flussi che spaziano dagli swap via wallet retail, al routing programmatico tramite API per integratori, fino a comportamenti più specializzati come ordini limite, esecuzione in stile DCA e posizionamento in derivati.

Questa distinzione è importante perché un alto “volume” può essere in parte riflessivo o guidato da incentivi, mentre un’attività sostenuta basata sugli indirizzi e un utilizzo ripetuto attraverso diversi regimi di mercato sono indicatori più solidi di product-market fit. Analisi pubbliche e post di ricerca riportano frequentemente range di indirizzi attivi giornalieri nell’ordine delle diverse migliaia per la venue dei perps e volumi cumulativi elevati per l’ecosistema, mostrando al contempo che l’attività è dipendente dal regime e sensibile al sentiment di rischio più ampio (si vedano, ad esempio, le osservazioni sugli indirizzi utente dei perps nei post di ricerca della community Jupiter e nei confronti tra venue DeFi, e gli aggregati di volume perps di DefiLlama per un benchmark cross-protocol più standardizzato).

Le affermazioni di “adozione istituzionale” nella DeFi sono spesso sovrastimate, quindi l’impostazione prudente è che la rilevanza enterprise più difendibile di Jupiter è come infrastruttura utilizzata indirettamente dai principali wallet Solana, interfacce di trading e partecipanti al mercato che cercano la best execution on-chain, piuttosto che come protocollo con controparti corporate nominate. Dove Jupiter si interseca con temi più vicini al mondo istituzionale è tramite prodotti che richiedono una maggiore rigore operativo – perpetual (motori di rischio, oracle, liquidazioni) e primitive legate a stablecoin o rendimento – perché queste attraggono utenti più sofisticati e, potenzialmente, intermediari più attenti alla compliance.

Detto ciò, partnership specifiche le affermazioni dovrebbero essere trattate come probabilistiche finché non siano confermate da fonti primarie; anche le narrazioni ampiamente ripetute (ad es. integrazioni con stablecoin ed espansioni nel lending) richiedono un’attenta verifica, perché “partnership” può significare qualsiasi cosa, da un semplice annuncio di co‑marketing a una relazione contrattuale profonda con responsabilità chiaramente definite.

Quali sono i rischi e le sfide per Jupiter?

L’esposizione regolamentare è in gran parte indiretta ma comunque rilevante. In quanto venue di trading DeFi su Solana con funzionalità perps, Jupiter si confronta con il modello generale statunitense in cui l’instradamento spot dei token è in genere meno colpito direttamente rispetto ai derivati con leva, ma il confine non è netto: il rischio regolamentare deriva da come le autorità interpretano il controllo sul protocollo, la gestione del front‑end, gli incentivi in token e se un prodotto perps sia considerato un “swap execution facility” non registrato o una venue di futures secondo i quadri normativi USA. È importante notare che, anche in assenza di un’azione di enforcement specifica contro il protocollo, il più ampio contesto di enforcement statunitense per gli intermediari crypto (incluse azioni e contenziosi che coinvolgono i principali exchange e la classificazione di vari token) crea rischi di “secondo ordine” tramite integrazioni con wallet, on/off‑ramp e pressioni per il geofencing; ciò può ridurre la base utenti accessibile o limitare la crescita nei mercati regolamentati senza un singolo titolo in prima pagina del tipo “causa contro Jupiter”.

Una seconda classe di rischio riguarda la centralizzazione e la dipendenza operativa: la qualità dell’instradamento e l’uptime dipendono da infrastrutture di quoting off‑chain, dall’accesso RPC e da una rapida iterazione da parte di un team core, il che può far sembrare il sistema decentralizzato on‑chain ma operativamente dipendente da un piccolo insieme di manutentori e fornitori di servizi.

La concorrenza è strutturalmente intensa perché la proposta di valore principale – la best execution – tende a diventare una commodity a meno che non sia abbinata a distribuzione e bundling di prodotti. Su Solana, Jupiter compete non solo con altri router e front‑end di DEX ma anche con venue verticalmente integrate che possono internalizzare il flusso ordini, nonché con concorrenti nativi perps come Drift e nuovi entranti che possono sovvenzionare la liquidità o innovare sui motori di rischio (DefiLlama elenca Jupiter Perpetual Exchange competitors e fornisce metriche comparabili di volume e TVL).

La minaccia economica è che, se la liquidità su Solana si consolidasse attorno a un piccolo numero di pool dominanti o se wallet/venue costruissero router proprietari, il take‑rate dell’aggregatore di Jupiter e il suo potere contrattuale potrebbero comprimersi; viceversa, se i perps diventassero il principale driver, Jupiter erediterebbe i ben noti tail risk dei derivati on‑chain – shock sugli oracle, cascate di liquidazioni, eventi di insolvenza per gli LP e meccaniche di perdita socializzata – in cui un singolo evento di stress può danneggiare in modo permanente la fiducia nel brand anche se la chain rimane sana.

Quali sono le prospettive future per Jupiter?

Le domande credibili sul “futuro” di Jupiter riguardano meno la checklist di funzionalità e più la capacità di mantenere un vantaggio difendibile come livello di esecuzione predefinito di Solana, gestendo al contempo il rischio e la gravità regolamentare dell’espansione in derivati, lending e prodotti adiacenti alle stablecoin. Roadmap pubbliche ed eventi ricorrenti dell’ecosistema (come il ciclo annuale di distribuzione Jupuary approvato via governance e il passaggio post‑Catstanbul verso narrative di buyback/fondi di riserva finanziate dalle fee descritte nei report) indicano che Jupiter probabilmente continuerà a usare incentivi in token e bundling di prodotti per rafforzare la distribuzione, ma questa strategia è limitata dalla percezione di diluizione, dai calendari di sblocco e dalla natura riflessiva del volume nei mercati risk‑on.

A livello di protocollo, la scomposizione continua di Jupiter in più linee di ricavo da parte di DefiLlama suggests che la prossima fase riguarda qualità di esecuzione più efficienza del capitale: migliorare la profondità di liquidità dei perps, ampliare in modo sicuro le tipologie di collaterale, rendere più robusti il design degli oracle e delle liquidazioni e rendere l’impronta della “superapp” resiliente alla congestione di Solana e alla frammentazione degli RPC, mantenendo al contempo governance e operazioni di tesoreria sufficientemente leggibili per allocatori sofisticati.