Protocollo Percolator: Trading Perpetuo su Solana

Comprendere il protocollo perpetuo Percolator su Solana — senza il gergo.

Cos'è Percolator?

Percolator è un protocollo di futures perpetui on-chain costruito su Solana. In termini semplici: permette alle persone di fare trading di posizioni long/short con leva su un asset (ad es. SOL) che non scadono mai, con collaterale detenuto in un vault condiviso e prezzi provenienti da oracoli (ad es. Chainlink, Pyth). Il protocollo è sperimentale e non verificato — solo per scopi educativi e di test, non per produzione o fondi reali.

Pensalo come un "motore di perp" decentralizzato e programmabile: un programma contiene tutto lo stato del mercato in un singolo account slab, e programmi matcher esterni definiscono come vengono prezzate le operazioni.

Questa separazione lo rende flessibile: puoi gestire mercati standard o invertiti, LP passivi o pricing in stile Market maker automatizzato (AMM) personalizzato.

Protocollo Percolator — Idee Principali

1. Lo Slab = Un Mercato, Un Grande Account

Tutto per un singolo mercato risiede in un account on-chain chiamato slab:

• Header — magic, versione, admin, flag (ad es. "resolved" per mercati binari).

• Configurazione mercato — collateral mint, vault, ID feed oracolo, scala invert/unit, parametri di finanziamento e soglia di rischio, autorità oracolo opzionale.

• Motore di rischio — saldo vault, fondo assicurativo, parametri di rischio (margini, commissioni, liquidazione), indice di finanziamento, stato crank/sweep e una bitmap + array di fino a 4096 account (utenti e LP).

Quindi: uno slab = un mercato perpetuo (o uno binario).

Distribuire un altro slab = un altro mercato.

2. Due Tipi di Account: Utenti e LP

Ogni account nello slab è uno:

• Utente — un trader. Depositano collaterale, aprono/chiudono posizioni (long = dimensione positiva, short = dimensione negativa) e hanno PNL, margine, finanziamento, ecc.

• LP (fornitore di liquidità) — fornisce liquidità e prende l'altro lato delle operazioni. Hanno anche capitale e una posizione (opposta al netto delle posizioni utente che hanno abbinato). Gli LP sono vincolati a un matcher (programma + contesto) che definisce come vengono prezzate le operazioni.

Gli account sono indicizzati (0..N). Lo slab traccia quali indici sono utilizzati tramite una bitmap e memorizza il capitale di ogni account, posizione, prezzo di ingresso, indice di finanziamento, programma/contesto matcher (per LP) e proprietario.

3. Gli Oracoli Forniscono i Prezzi; Opzionale Override dell'Autorità

I prezzi provengono dagli oracoli (ad es. ID feed Pyth Pull o Chainlink). Lo slab memorizza:

• Massima obsolescenza e filtro di confidenza.

• Autorità oracolo opzionale: se impostata, un admin può inviare un prezzo (utilizzato per test, regolamento binario o ambienti controllati). Quando il prezzo dell'autorità è impostato e recente, sovrascrive il feed esterno.

Quindi: operazione normale = Pyth/Chainlink; casi speciali = prezzo controllato dall'admin.

4. Mercati Invertiti

Un mercato può essere invertito: internamente il protocollo utilizza 1/prezzo (ad es. USD per SOL → SOL per USD). È utile quando il collaterale è SOL e si desidera un'esposizione in stile "long USD / short USD": long = profitto quando SOL scende, short = profitto quando SOL sale. Stesso motore di rischio, diversa interpretazione del prezzo.

5. Matcher: Chi Decide il Prezzo di Trading?

Le operazioni possono avvenire in due modi:

• Trade (no CPI) — Solo il programma percolator viene eseguito. Utente e LP firmano; esecuzione e pricing sono gestiti all'interno di percolator (ad es. concordati off-chain o con una regola semplice). Nessun altro programma viene chiamato. Buono per test o coppie LP–utente affidabili.
• Trade (CPI) — Percolator invoca un programma matcher esterno tramite CPI. Il matcher (ad es. percolator-match) riceve l'oracolo e il suo contesto, calcola il prezzo di esecuzione e lo restituisce. Percolator quindi applica quel prezzo (dimensione, commissioni, margine) e aggiorna lo stato.

CPI qui significa Cross-Program Invocation su Solana.

Quindi i matcher sono il "livello di pricing": passivo (ad es. oracolo ± 50 bps), in stile vAMM (spread + impatto), o completamente personalizzato. Il protocollo garantisce che il programma/contesto matcher dell'LP corrisponda e che il matcher verifichi il PDA LP come firmatario (quindi viene utilizzata solo la liquidità di quel LP).

6. Keeper Crank: Finanziamento, Mark e Liquidazione

Un keeper crank è un'istruzione senza permesso che:

• Aggiorna il prezzo mark e il finanziamento dall'oracolo e dalla posizione netta LP.

• Applica il finanziamento alle posizioni aperte.

• Esegue la logica di liquidazione/chiusura forzata (ad es. account sotto margine di mantenimento liquidati al prezzo dell'oracolo; posizioni dust pulite).

Il finanziamento viene calcolato on-chain dall'inventario LP in modo che long/short si paghino a vicenda (e il protocollo può prendere una quota). Le operazioni che aumentano il rischio richiedono un crank "recente" (ad es. entro ~200 slot) in modo che mark e finanziamento siano aggiornati.

7. Assicurazione e Rischio

• Un fondo assicurativo (ricaricato da admin o commissioni) assorbe le perdite quando le posizioni vengono liquidate o chiuse forzatamente. C'è una soglia; sotto di essa, il mercato può entrare in modalità "solo riduzione del rischio" (solo operazioni di riduzione della posizione consentite).

• Logica haircut-ratio (aggregati O(1): capitale totale, PNL positivo) viene utilizzata in modo che il sistema possa gestire insolvenze senza una pesante sweep Riduzione automatica della leva finanziaria (ADL). La conservazione è mantenuta: vault ≥ capitale + assicurazione + PNL positivo (con piccola tolleranza di arrotondamento).

8. Binario / Premarkets

Lo stesso slab può essere utilizzato come mercato binario (evento): risultato YES/NO. L'admin imposta un'autorità oracolo, invia un prezzo di regolamento (ad es. 1.0 = YES, ~0 = NO), poi chiama resolve-market. Dopo di che, niente nuove operazioni/depositi; keeper crank chiude forzatamente tutte le posizioni al prezzo di regolamento. Una volta chiuso tutto, l'admin può prelevare l'assicurazione e gli utenti prelevano il capitale rimanente. Quindi: un codebase per perpetui e regolamento eventi.

Casi d'Uso

1. Futures Perpetui (Standard o Invertiti)

• Standard: ad es. perp SOL/USD con SOL o USDC come collaterale; long/short SOL.

• Invertito: ad es. collaterale SOL, prezzo = 1/SOL in termini USD; long = bullish USD (bearish SOL), short = bearish USD (bullish SOL). Buono quando vuoi mantenere il collaterale in SOL ed esprimere una visione su "SOL che sale o scende."

Usa la CLI (o SDK) per: init market → init user → deposit → run keeper crank → trade (trade-cpi o trade-nocpi). Stesso flusso per entrambi, solo invert e unit_scale differiscono in init-market.

2. Fornitura di Liquidità (Passiva o vAMM)

• LP Passivo: un matcher (ad es. percolator-match) con uno spread fisso (ad es. 50 bps). L'LP deposita collaterale, init-lp con quel contesto matcher; i trader ottengono oracolo ± spread.

• LP in stile vAMM: matcher con spread base + impatto + commissione. Spread più stretti per dimensioni piccole, più larghi per grandi; puoi eseguire script come add-vamm-lp.ts per aggiungere tali LP. I bot (ad es. random-traders.ts) possono instradare al miglior LP tramite prezzo simulato.

Caso d'uso: market-making, guadagnare spread/commissioni o eseguire una strategia di pricing personalizzata nel tuo matcher.

3. Keeper / Infrastruttura

• Bot Crank: chiama keeper-crank ogni pochi secondi in modo che finanziamento e mark siano aggiornati e le liquidazioni vengano eseguite. Richiesto per operazioni che aumentano il rischio (controlli di obsolescenza).

• Liquidatore: monitora gli account e chiama liquidate-at-oracle quando un account è sotto margine di mantenimento. Senza permesso; il liquidatore guadagna una commissione.

Caso d'uso: eseguire beni pubblici (crank) o profittare dalle commissioni di liquidazione.

4. Mercati Binari / Evento (Premarkets)

• Crea uno slab senza feed esterno (ad es. ID feed Pyth = zeri, modalità "Hyperp"), imposta il prezzo mark iniziale (ad es. 0.5 = 50% implicito), imposta l'autorità oracolo su admin.

• Gli utenti fanno trading come in un perp; quando l'evento si risolve, admin push-oracle-price (YES=1e6, NO≈0), poi resolve-market, poi crank fino a quando tutte le posizioni sono chiuse forzatamente, poi preleva assicurazione e capitale utente.

Caso d'uso: mercati di previsione, contratti di eventi o qualsiasi risultato binario che si regola a un singolo prezzo.

5. Test e Stress Testing

• Autorità oracolo: invia prezzi fissi o estremi per testare liquidazioni, finanziamento o casi limite senza muovere mercati reali.

• Script: ad es. stress-haircut-system.ts, stress-worst-case.ts, oracle-authority-stress.ts, pentest-oracle.ts per sicurezza/stress; test-*.ts per invarianti e flussi.

• Devnet: setup-devnet-market.ts crea un mercato SOL/USD invertito completo con Chainlink e un LP finanziato; puoi eseguire bot e test contro di esso.

Caso d'uso: team di protocollo, auditor o integratori che convalidano il comportamento prima di mainnet.

6. Admin e Regolazione dei Parametri

• update-config: cambia orizzonte di finanziamento, K, scala, premio massimo, soglia floor/risk/interval/step/alpha/min/max (comportamento di finanziamento e soglia di rischio).

• set-risk-threshold, set-maintenance-fee: ottimizzare rischio e costo.

• topup-insurance, withdraw-insurance (quando risolto e vuoto): gestire fondo assicurativo.

Caso d'uso: operatori di mercato che si adattano alla volatilità o alla domanda.

Potenziale e Direzioni

1. Perpetui su Solana

Percolator mostra che un motore perpetuo single-program, single-slab può vivere su Solana con Pyth/Chainlink, più LP e crank/liquidatori senza permesso. Questa è una base per:

• Mercati perp pubblici (ad es. SOL, BTC, ETH) con collaterale SOL o stablecoin.

• Mercati invertiti dove il collaterale è l'asset nativo e i trader vogliono esposizione con leva "dall'altro lato" della coppia.

2. Matcher Pluggable

Poiché il pricing è in programmi matcher esterni, il protocollo principale rimane minimale e sicuro mentre:

• I team possono spedire nuovi matcher (ad es. stile order-book, RFQ o ibrido) senza cambiare il motore di rischio.

• Più matcher (passivi, vAMM, ecc.) possono coesistere in un mercato; trader e bot scelgono il prezzo migliore (come in best-price e random-traders).

Potenziale: un ecosistema di matcher (order book centrale, request-for-quote, spread sensibili alla volatilità) su un motore perp condiviso.

3. Mercati Binari ed Eventi

Lo stesso slab e motore di rischio supportano resolve + force-close al prezzo di regolamento, quindi:

• I mercati di previsione e i contratti di eventi possono essere costruiti sulla stessa codebase dei perp.

• Gli operatori possono gestire sia perp che mercati binari con una distribuzione e una CLI/SDK.

Potenziale: livello unificato "futures + eventi" su Solana.

4. Componibilità e Automazione

• API programmatica: la CLI è un wrapper sottile su istruzioni e parsing slab; le funzioni encode*, buildAccountMetas e parse* del repo sono un piccolo SDK. UI, bot e altri programmi possono comporre sopra.

• Incentivi keeper/liquidatore: crank senza permesso e liquidate-at-oracle consentono a terze parti di eseguire infrastruttura e guadagnare commissioni senza permesso.

Potenziale: integrazioni con wallet, aggregatori e strategie automatizzate.

SOLO PER SCOPI EDUCATIVI. Il programma Percolator e questa CLI non sono stati verificati. Non utilizzare in produzione o con fondi reali. Utilizzare a proprio rischio.

Fonte

Questo articolo si basa sul codebase percolator-cli (https://github.com/aeyakovenko/percolator-cli) e repo correlati (percolator, percolator-prog, percolator-match).

Protocollo Percolator: Trading Perpetuo su Solana è stato originariamente pubblicato in Coinmonks su Medium, dove le persone stanno continuando la conversazione evidenziando e rispondendo a questa storia.