Request

Che cos’è Request?

Request è un protocollo open‑source per richieste di pagamento crypto e riconciliazione che consente a un’azienda o a un utente di creare una richiesta di pagamento firmata simile a una fattura, archiviare i dati della richiesta su un’infrastruttura decentralizzata e abbinare i successivi pagamenti on‑chain a quella richiesta senza cedere la custodia dei fondi a un processore di pagamento. Il problema centrale che affronta non è il “movimento di token” in astratto, che molti wallet e gateway di pagamento gestiscono già, ma la creazione di un oggetto contabile verificabile intorno al pagamento: chi lo ha richiesto, quale importo era dovuto, quale valuta o unità di conto è stata utilizzata, dove è avvenuto il regolamento e se il pagamento può essere rilevato e riconciliato automaticamente.

Il vero vantaggio competitivo del protocollo è quindi l’integrazione nei flussi di lavoro più che il consenso di base: Request combina richieste di pagamento firmate, archiviazione su IPFS, ancoraggio on‑chain dei CID, eventi di riferimento di pagamento, webhook, strumenti API e instradamento dei pagamenti multi‑chain in un primitivo di back office finanziario, come descritto nella documentazione di Request Network e nella sua panoramica del protocollo. docs.request.network

Request non è un Layer 1 dominante, né un rollup o un grande money market DeFi; è un livello applicativo di nicchia per pagamenti e strumenti per sviluppatori costruito attorno a fatturazione crypto, rilevamento dei pagamenti e riconciliazione.

A fine maggio 2026, i fornitori di dati di mercato collocavano REQ nell’universo dei token a bassa/media capitalizzazione piuttosto che tra gli asset crypto sistemicamente importanti: CoinMarketCap mostrava Request intorno alla posizione #384, mentre CoinGecko e DeFiLlama riportavano dati di capitalizzazione di mercato che differivano in modo significativo a causa di metodologie e tempistiche diverse sulla supply in circolazione. Per questo tipo di protocollo, la TVL è un indicatore limitato: la pagina Request Network su DeFiLlama riporta dati sul treasury e sul mercato del token piuttosto che una TVL convenzionale da lending/AMM, il che è coerente con il ruolo di Request come infrastruttura di pagamento più che come pool di depositi degli utenti. Gli indicatori di scala più rilevanti sono il volume dei pagamenti e l’attività business processata; il sito della fondazione dichiara oltre 2 miliardi di dollari di volume processato e un’ampia copertura di stablecoin, mentre il community‑run Request Activity Dashboard traccia i pagamenti giornalieri e il volume dei pagamenti ma non fornisce una coorte DAU/MAU pulita e paragonabile ai wallet consumer o agli exchange. (coinmarketcap.com)

Chi ha fondato Request e quando?

Request è stato fondato nel 2017 da Christophe Lassuyt ed Etienne Tatur, entrambi legati al precedente progetto fintech MONEYTIS; Y Combinator elenca Request Network come una società del batch Winter 2017 con sede a Parigi, con Lassuyt come Founder/CFO e Tatur come Founder/CTO. Il contesto del lancio è importante: REQ è nato durante il ciclo ICO del 2017, quando molti progetti cercavano di generalizzare Ethereum oltre i semplici trasferimenti di token verso contabilità, commercio e automazione aziendale. Gli storici database sulle ICO collocano la token sale nell’ottobre 2017, con una supply iniziale di circa un miliardo di REQ, sebbene la supply attuale sia inferiore dopo burn e cambiamenti nella contabilità dei token. Quella “annata” rappresenta sia un vantaggio sia un onere: Request ha superato diversi cicli di mercato e mantiene software funzionante, ma porta anche con sé l’overhang reputazionale comune ai progetti con utility token del 2017, le cui prime narrative spesso superavano l’adozione nel breve termine. (ycombinator.com)

La narrativa del progetto si è ristretta nel tempo.

L’inquadramento originario era una ampia rete di pagamenti decentralizzata per fatture, audit trail, conformità al diritto commerciale e richieste di pagamento globali; l’enfasi del prodotto attuale è più operativa e meno ideologica, incentrata su pagamenti crypto basati su API, fatturazione on‑chain, rilevamento dei pagamenti, instradamento cross‑chain, pagamenti in batch, pagamenti ricorrenti e riconciliazione.

Questa evoluzione è visibile negli aggiornamenti della fondazione del 2025: Request ha rilasciato l’API V2, i pagamenti parziali, webhook migliorati, workflow crypto‑to‑fiat, pagamenti in batch e funzionalità di pagamento cross‑chain invece di cercare di diventare una nuova blockchain general‑purpose. In termini istituzionali, il pivot va da “PayPal su blockchain” verso un livello di middleware per team finance, payment service provider e aziende crypto‑native che hanno bisogno di record di pagamento strutturati su più chain. request.network

Come funziona Request Network?

Request non ha un proprio meccanismo di consenso proof‑of‑work, proof‑of‑stake, DAG, un set di validator, un sequencer o un rollup. È un protocollo ibrido off‑chain/on‑chain che conserva la maggior parte dei contenuti delle richieste su IPFS, ancora l’identificatore di contenuto IPFS on‑chain ed elabora i pagamenti tramite smart contract sulle chain di regolamento supportate.

La documentazione indica che le richieste vengono create archiviando i CID su Gnosis Chain, mentre i pagamenti possono avvenire su oltre 20 chain EVM‑compatibili supportate o su NEAR; il saldo della richiesta viene quindi calcolato indicizzando gli eventi di pagamento on‑chain associati a un riferimento di pagamento derivato. In termini tecnici, Request è un protocollo a livello applicativo e un’API per sviluppatori che eredita liveness e finalità da reti esterne come Gnosis, Ethereum, Base, Arbitrum, Optimism, Polygon e altre, invece di fornire un proprio security budget di base. docs.request.network

Il meccanismo distintivo del protocollo è il “payment reference”. Nel modello raccomandato basato su reference, un identificatore univoco derivato dai dati della richiesta collega il pagamento su blockchain alla fattura o richiesta di pagamento sottostante; i proxy contract inoltrano i fondi al destinatario ed emettono eventi contenenti l’importo del pagamento e il reference, mentre i subgraph indicizzano tali eventi per la successiva riconciliazione.

Il sistema non utilizza sharding o ZK‑rollup come primitive di scalabilità native, e il suo modello di verifica è più vicino a un regolamento basato su eventi indicizzati più metadati di richiesta firmati che alla verifica di proof crittografiche di rollup. I Request Node forniscono un gateway tra IPFS, smart contract e The Graph; la fondazione opera dei node per convenienza degli sviluppatori, ma consiglia ai builder in produzione di eseguire un proprio node, aspetto importante perché la dipendenza da gateway e API ospitati dalla fondazione rappresenta un vettore di centralizzazione, anche se i dati delle richieste e gli smart contract sottostanti sono open‑source.

Le richieste private aggiungono crittografia asimmetrica e AES: i contenuti della richiesta sono cifrati con una chiave AES, e quella chiave è cifrata con la chiave pubblica di ciascuna controparte prima di essere salvata su IPFS. docs.request.network

Quali sono le tokenomics di REQ?

REQ è un token ERC‑20 originariamente lanciato con circa un miliardo di unità, e il suo profilo di supply si comprende meglio come per lo più fisso con un meccanismo di burn moderato, piuttosto che come un asset con emissioni inflazionistiche. A fine maggio 2026, Etherscan elencava il contratto del token ERC‑20 a 0x8f8221afbb33998d8584a2b05749ba73c37a938a con una max total supply di circa 999,416 milioni di REQ, mentre CoinMarketCap riportava una circulating supply intorno a 796,7 milioni di REQ e CoinGecko mostrava una cifra diversa per la circulating supply, a sottolineare che la supply “in circolazione” dipende da come vengono classificati riserve, bridge e saldi inattivi.

Il dashboard della community riportava circa 583.000 REQ bruciati, una piccola frazione della supply originale, quindi l’effetto deflazionistico esiste ma non è abbastanza grande da costituire di per sé la tesi d’investimento centrale. (etherscan.io)

L’accumulo di valore di REQ è indiretto e va considerato con cautela.

La documentazione identifica contratti del token REQ e del meccanismo di burn che possono bloccare, bridgiare e bruciare REQ quando le richieste vengono archiviate, mentre la documentazione dell’API descrive una commissione di protocollo di 5 basis point sui pagamenti processati tramite l’API, con tetto intorno a 25 $ o 25 € per le principali stablecoin ancorate a USD ed EUR.

Questi non sono equivalenti a un classico rendimento di staking PoS, e Request non è protetto dallo staking di REQ nello stesso modo in cui Ethereum è protetto dai validator ETH. Alcune descrizioni di terze parti illustrano l’utilità di REQ in termini di anti‑spam, governance, staking, sconti e indipendenza, ma l’attuale documentazione tecnica ufficiale non presenta un grande mercato di liquid staking, uno schedule di reward per validator o un programma di emissioni ricorrenti per i detentori di REQ.

L’interpretazione delle tokenomics più difendibile è quindi che REQ sia un token di tipo legacy utility/governance con supply limitata e elementi di burn legati all’utilizzo, mentre la maggior parte dell’uso del protocollo nel breve periodo può riflettersi più direttamente sul livello di prodotto e sui servizi API gestiti dalla fondazione, piuttosto che accumularsi automaticamente ai detentori passivi del token. docs.request.network

Chi sta usando Request?

La differenza tra il trading speculativo di REQ e l’effettiva utilità di Request Network è sostanziale. Il volume del token sugli exchange riflette la liquidità di mercato e la rotazione degli investitori, mentre l’uso del protocollo è meglio misurato da richieste create, pagamenti rilevati, volume dei pagamenti, adozione dell’API e integrazione nei flussi di lavoro finanziari.

Nell’aggiornamento dell’ecosistema di maggio 2025, Request ha esplicitamente spostato l’enfasi del proprio reporting dal conteggio generico delle transazioni al “numero di pagamenti”, perché la creazione, l’approvazione, il rifiuto delle fatture e altre azioni possono gonfiare le metriche di transazione senza rappresentare una reale attività di regolamento.

Il dashboard della community riporta inoltre il volume dei pagamenti e il conteggio dei pagamenti sulle chain supportate, ma si tratta di indicatori giornalieri volatili che non dovrebbero essere interpretati come numeri stabili di utenti attivi. A livello settoriale, Request si colloca all’intersezione tra pagamenti crypto, regolamento in stablecoin, fatturazione, payroll, contabilità e operazioni di tesoreria, più che nella liquidità DeFi, nel gaming o nella speculazione NFT. request.network

La prova di adozione più solida è rappresentata dalle integrazioni con prodotti identificabili per la finanza o le operazioni crypto, non dal numero anonimo di wallet. Request’s Gli aggiornamenti dell’ecosistema 2025 hanno indicato come “active builders” Animal Social Club, intrXn, 0 Finance, Allora e Request Finance, mentre aggiornamenti precedenti menzionavano anche Huma Finance, BSOS, Joba Network e altri partecipanti all’ecosistema.

Nell’ottobre 2025, Kryptos ha annunciato di aver integrato la Request Network API per alimentare la fatturazione all’interno di Kryptos Enterprise, con Request che fornisce creazione delle fatture, regolamento on-chain, webhook di evento e riconciliazione; tale annuncio citava anche il proprio snapshot di adozione da parte di Kryptos, con oltre 200.000 utenti registrati, più di 50 aziende Web3 integrate nelle prime fasi e migliaia di integrazioni con wallet, CEX, DeFi e chain. Queste cifre vanno lette come scala della piattaforma partner piuttosto che come adozione diretta da parte dei detentori di REQ, ma restano comunque più sostanziali rispetto a semplici voci di collaborazione non verificate. request.network

Quali sono i rischi e le sfide per Request?

Il rischio normativo per Request è più sottile rispetto a quello per un exchange, un protocollo di lending o un mixer di privacy, ma non è nullo. Le ricerche pubbliche e il testo dei reclami SEC disponibili nei risultati di ricerca non mostrano REQ come token nominato nei principali procedimenti SEC del 2023 contro Coinbase o Binance, e non esiste, alla fine di maggio 2026, una causa SEC attiva e ampiamente riportata specificamente contro Request Network.

Ciò non equivale a una “safe harbor” regolamentare. REQ è stato venduto nell’era delle ICO del 2017, è negoziato sui mercati secondari e i regolatori statunitensi hanno storicamente esaminato con attenzione i token distribuiti per finanziare lo sviluppo di un protocollo.

L’attività di pagamenti del protocollo tocca anche temi di antiriciclaggio (AML), screening sanzionatorio, KYC, regolamentazione delle stablecoin, trasmissione di denaro e questioni di dichiarazione fiscale, soprattutto laddove Request supporta il settlement cripto-to-fiat, lo screening dei wallet e la fatturazione per le imprese. Il rischio di centralizzazione è anche pratico piuttosto che teorico: l’API gestita dalla fondazione, la dashboard, la pagina di pagamento sicura, i Request Nodes e l’infrastruttura di rilevamento dei pagamenti possono creare una dipendenza operativa anche se i contratti, l’SDK e il data model restano open source. sec.gov

La concorrenza è intensa perché il problema lato utente che Request affronta può essere attaccato da più direzioni. I tradizionali processori di pagamento stanno aggiungendo il settlement in stablecoin; i processori di pagamento cripto centralizzati possono offrire conformità, politiche di chargeback, off-ramp fiat e dashboard per i merchant; i wallet e gli exchange possono aggiungere direttamente i payment link; e i provider di contabilità cripto per le imprese possono integrare la riconciliazione delle fatture nei propri stack. All’interno del Web3, prodotti simili a Safe e Coinbase Commerce, strumenti di tesoreria multisig, piattaforme di payroll, provider di checkout in stablecoin, dashboard di contabilità on-chain e API di routing cross-chain possono ciascuno assorbire parti del flusso di lavoro di Request.

La minaccia economica è che la fee di 5 basis point di Request e il collegamento al burn di REQ possano essere erosi dalla concorrenza se il routing dei pagamenti e la riconciliazione diventeranno funzionalità API commoditizzate. La sua difendibilità dipende dal fatto che gli sviluppatori considerino l’oggetto “invoice” di Request, lo standard di payment reference e gli strumenti di riconciliazione come un livello di integrazione durevole piuttosto che come un semplice wrapper di convenienza facilmente sostituibile. docs.request.network

Qual è l’outlook futuro per Request?

La roadmap di breve termine di Request sembra concentrarsi sulla profondità del prodotto più che sulla reinvenzione del livello di consenso. Documentazione verificata del 2025 e dell’inizio 2026 indica la migrazione all’API V2, i pagamenti cross-chain in stablecoin, i pagamenti batch, i pagamenti parziali, i flussi cripto-to-fiat, i pagamenti ricorrenti, la personalizzazione delle fee, i miglioramenti nel cambio di wallet e network, un tracciamento dei pagamenti più ampio e il supporto per oltre 25 chain tramite la superficie API. I pagamenti cross-chain sono particolarmente importanti perché affrontano un problema operativo reale: i pagatori possono detenere USDT su Optimism mentre le fatture richiedono USDC su Base, e i team finance non vogliono gestire manualmente bridge, swap, token gas e riconciliazione.

La documentazione di Request afferma che i pagamenti cross-chain supportano USDC (USDC), USDT (USDT) e DAI (DAI) su Ethereum (ETH), Arbitrum One (ARB), Base e OP Mainnet (OP), con rotte classificate in base alle commissioni di transazione e alla velocità di elaborazione; la pagina pubblica del prodotto cross-chain dichiara che Request utilizza il routing di LI.FI mantenendo però un rilevamento dei pagamenti e una logica di webhook unificati. request.network

L’ostacolo strutturale è la densità di adozione. Request non deve battere Ethereum, Visa, Stripe o ogni processore di stablecoin in senso ampio; ha bisogno che un numero sufficiente di applicazioni business, prodotti di contabilità, PSP e team di finanza cripto-native si standardizzino attorno al suo layer di richiesta e riconciliazione. Lo scenario ribassista è che i pagamenti in stablecoin vengano incorporati direttamente in wallet, banche e API degli exchange, lasciando Request come un piccolo strumento per sviluppatori con una cattura di valore del token limitata.

Lo scenario rialzista è più misurato rispetto a una mera narrativa di prezzo: se il settlement in stablecoin continua ad espandersi e i team finance richiedono registri di pagamento verificabili, non-custodial e multi-chain, la combinazione di Request di richieste firmate, payment reference, webhook, flussi batch, pagamenti ricorrenti e routing cross-chain potrebbe restare un’infrastruttura valida.

Il futuro del progetto dipende quindi meno dalla domanda speculativa per REQ e più dalla capacità di Request di convertire la sua lunga storia operativa in integrazioni durature, metriche di utilizzo trasparenti e un modello di token il cui collegamento economico ai pagamenti reali sia sufficientemente chiaro perché utenti istituzionali e detentori del token possano valutarlo con cognizione di causa.