Arbitrum API: pagamenti ERC-20 sul Layer 2 di Ethereum

Arbitrum è un optimistic rollup. Le transazioni vengono eseguite sull'infrastruttura propria di Arbitrum, e la rete pubblica i dati compressi della transazione su Ethereum, dove chiunque può ricostruire lo stato della L2 a partire da ciò che è on-chain. "Optimistic" indica il modello di sicurezza: gli aggiornamenti di stato si presumono validi al momento della pubblicazione, e segue una finestra di contestazione durante la quale qualsiasi osservatore può presentare una prova di frode contro uno errato. Ethereum arbitra la disputa. Poiché i dati sottostanti risiedono su Ethereum, barare non può essere nascosto, e la L2 eredita la sicurezza di L1 invece di avviare un proprio insieme di validatori.

Il design spiega anche la struttura delle commissioni. Una commissione Arbitrum paga per due cose: l'esecuzione sulla L2, che è economica, e la quota della transazione nella pubblicazione dei dati del batch su Ethereum. Da marzo 2024 quei dati vanno nello spazio blob introdotto da EIP-4844, il che ha ridotto il costo di pubblicazione di circa il 90% e ha mantenuto le commissioni tipiche di Arbitrum a centesimi o meno per tutto il 2025 e il 2026. Centinaia di trasferimenti condividono un unico batch, quindi ciascuno porta una piccola frazione del costo L1 anziché una commissione di transazione L1 completa.

Esistono due chain pubbliche di Arbitrum, e i nomi si confondono. Arbitrum One è il rollup appena descritto: tutti i dati di transazione arrivano su Ethereum, e le assunzioni di fiducia si riducono a quelle di Ethereum stesso. Arbitrum Nova esegue invece il protocollo AnyTrust. I suoi dati di transazione sono tenuti off-chain da un Data Availability Committee, e il sistema resta solido finché almeno due membri del comitato si comportano onestamente; se il comitato non riesce a servire i dati, la chain torna alla modalità rollup completa. Tenere i dati fuori da Ethereum rende Nova nuovamente più economica, al prezzo di quell'assunzione di fiducia aggiuntiva.

Nella pratica la divisione è netta. Nova ospita applicazioni di gaming e social, carichi di lavoro con conteggi di transazione molto alti e valore basso per transazione, dove il compromesso del comitato è accettabile. Arbitrum One ospita i protocolli DeFi, la liquidità delle stablecoin e il supporto degli exchange. Quando un'integrazione di pagamento, una pagina di prelievo di un exchange o questo articolo dicono "Arbitrum" senza qualificatore, si intende Arbitrum One. È la chain dove risiedono davvero gli USDC e USDT dei tuoi utenti.

Un trasferimento ERC-20 su Ethereum mainnet è costato da uno a venti dollari nel corso del 2026 a seconda della congestione. Lo stesso trasferimento su Arbitrum costa circa due-venti centesimi, circa due ordini di grandezza in meno, perché la maggior parte della commissione copre l'esecuzione economica di Layer 2 anziché il gas di Ethereum.

Entrambe le reti applicano un pricing dinamico, quindi i numeri assoluti si muovono con il prezzo di ETH e il carico di rete, ma l'asta del gas su mainnet fa impennare la commissione esattamente quando l'attività raggiunge il picco, la peggiore correlazione possibile per un business di pagamenti. Il rapporto di circa due ordini di grandezza è la parte stabile.

Per un backend di pagamenti il rapporto conta più di ciascun numero assoluto, perché le operazioni di pagamento moltiplicano le commissioni. Un deposito cliente è un trasferimento in entrata, un consolidamento nell'hot wallet ed eventualmente un pagamento in uscita: tre eventi di commissione per un solo pagamento. Ai prezzi di mainnet, i team rispondono raggruppando i consolidamenti e ritardando i pagamenti, e i fondi ritardati appaiono come capitale circolante bloccato tra wallet di deposito sparsi. Ai prezzi di Arbitrum consolidi secondo programma e paghi su richiesta, e la voce commissioni scompare nel rumore contabile.

Tornano convenienti anche i pagamenti piccoli. Un trasferimento da dieci dollari su L1 può perdere una percentuale a due cifre in gas in una brutta giornata, motivo per cui nessuno fa pagare dieci dollari su mainnet. Su Arbitrum lo stesso trasferimento perde una frazione di punto percentuale. La fatturazione per transazione, l'utilizzo misurato e i piccoli rimborsi passano dall'essere economicamente assurdi all'essere irrilevanti.

Arbitrum è pienamente EVM-compatibile, e per i pagamenti quella frase ha un significato preciso: lo stesso formato di indirizzo 0x con lo stesso checksum EIP-55, la stessa interfaccia contrattuale ERC-20, lo stesso schema di firma. Un contratto token distribuito su Arbitrum espone la stessa funzione transfer della sua controparte su mainnet. Nulla dello standard token è stato reinventato per la L2, motivo per cui wallet, explorer e librerie costruiti per Ethereum gestiscono Arbitrum con un endpoint RPC cambiato e nient'altro.

Attraverso l'API questo si riduce a un segmento di percorso. POST /api/v2/ethereum/transactions/erc20 e POST /api/v2/arbitrum/transactions/erc20 accettano un payload identico: contract address, from, to, amount. La tua logica di validazione, il tuo handler webhook e lo schema del tuo database restano invariati, perché indirizzi e hash di transazione hanno la stessa forma su entrambe le chain. Il risultato pratico è un vantaggio detto in modo semplice: la stessa chiamata API, una chain diversa. I team che già eseguono Ethereum tramite Chaingateway di solito aggiungono Arbitrum in un pomeriggio, rendendo la chain una colonna in una tabella di configurazione invece che una biforcazione nel codice.

Una cosa non si trasferisce: i saldi. È l'argomento della sezione successiva.

Un saldo ERC-20 è una voce all'interno di un contratto su una chain specifica. USDT su Ethereum e USDT su Arbitrum sono due voci contrattuali distinte, e possederne una non ti dà nulla dell'altra. Prima che il tuo hot wallet possa inviare token su Arbitrum, quei token devono esistere su Arbitrum. L'API non può farli comparire dall'altra parte; nessuna API può farlo.

Due percorsi normali li portano lì. Il bridge di Arbitrum blocca i token su Ethereum e conia la loro rappresentazione sulla L2. Lo stesso meccanismo funziona al contrario per i prelievi verso L1, e quella direzione include la finestra di contestazione, quindi spostare valore indietro verso Ethereum tramite il bridge canonico richiede circa una settimana a meno che tu non paghi un bridge veloce di terze parti per anticipare la liquidità. Il percorso più semplice per la maggior parte degli operatori: prelevare da un exchange che supporta prelievi su Arbitrum, il che mette i token sulla L2 in un solo passaggio e salta del tutto la meccanica del bridge.

Metti a budget anche il gas. Le commissioni su Arbitrum si pagano in ETH, quindi un hot wallet ha bisogno di un piccolo saldo ETH sulla L2 accanto ai suoi token. Gli importi sono minimi, centesimi per trasferimento, ma un wallet con token e zero ETH non può muoversi affatto, e quella modalità di errore merita un avviso di monitoraggio prima ancora che un post-mortem.

Arbitrum produce blocchi ben sotto il secondo, quindi un deposito è visibile quasi appena l'utente lo invia. Chaingateway inoltra quell'evento al tuo backend invece di farti fare polling. Imposta un secret personale sul tuo account e ogni consegna webhook porta un header X-Signature — un HMAC-SHA256 in base64 del campo txid del payload — così puoi verificare che provenga da Chaingateway. Le consegne fallite vengono conservate in un elenco di notifiche fallite e possono essere reinviate tramite POST /api/v2/arbitrum/webhooks/notifications/{id}/retry.

GET /api/v2/arbitrum/webhooks/notifications restituisce la cronologia delle consegne, utile per audit o per riprodurre eventi dopo un downtime dal tuo lato. La guida ai webhook copre la configurazione e la verifica della firma.

Un flusso di deposito concreto, dall'inizio alla fine. Ogni cliente riceve un proprio indirizzo di deposito, il che è ciò che rende i pagamenti in entrata attribuibili senza campi memo che gli utenti dimenticano di compilare. Osservi quegli indirizzi tramite webhook, e osservare non richiede alcuna key.

Dal deposito all'accredito

Un cliente invia 200 USDC dal proprio account exchange e sceglie Arbitrum come rete di prelievo. I blocchi arrivano ben sotto il secondo, quindi il trasferimento è on-chain quasi immediatamente, e Chaingateway invia l'evento tramite POST al tuo endpoint. Il tuo handler verifica la firma HMAC, controlla il contratto del token contro un allowlist, e registra il deposito come pendente. Una volta che il deposito soddisfa la tua politica di conferma, il record passa ad accreditato. Su una chain così veloce, il cliente vive l'intera sequenza come istantanea, il che vale qualcosa al checkout: la differenza tra "pagamento ricevuto" che appare prima o dopo che l'utente inizi a chiedersi se ha funzionato.

Consolidamento e pagamenti

Poi arriva la manutenzione che le commissioni L1 rendevano un tempo dolorosa. Secondo un programma, o ogni volta che un saldo supera una soglia, consolidi i depositi nell'hot wallet con POST /api/v2/arbitrum/transactions/erc20, dall'indirizzo di deposito, all'hot wallet. A centesimi per consolidamento questo può girare ogni ora invece che ogni settimana, mantenendo i fondi concentrati dove il processo di pagamento può raggiungerli invece che sparsi su centinaia di indirizzi. I prelievi sono la stessa chiamata nella direzione opposta, dall'hot wallet all'indirizzo del cliente. Nulla nel flusso è specifico di Arbitrum tranne il segmento di percorso e il livello di commissione, e il livello di commissione è precisamente ciò che rende sostenibile il programma orario.

La piena compatibilità EVM significa che la conoscenza di Ethereum si trasferisce uno a uno: checksum degli indirizzi, contratti token e firma si comportano esattamente come su mainnet. Le commissioni sono una frazione di Ethereum L1, il che trasforma i piccoli trasferimenti da una perdita in un arrotondamento. La sicurezza deriva da Ethereum stesso, perché i dati di transazione vengono pubblicati su L1 e lo stato errato può essere contestato lì. E l'ecosistema non è una scommessa sul futuro: grandi protocolli DeFi girano su Arbitrum in produzione oggi, quindi liquidità, explorer e supporto wallet esistono già.

Chaingateway supporta i token standard su Arbitrum, sia stablecoin consolidate sia asset in bridge e lanci personalizzati. L'integrazione è la stessa su ogni chain supportata: costruiscila una volta, poi punta lo stesso codice a /api/v2/ethereum/, /api/v2/polygon/ o /api/v2/bsc/ quando espandi. La panoramica della blockchain API elenca tutte e sette le chain.

I casi d'uso corrispondono alle altre EVM chain: flussi di checkout che accettano stablecoin con liquidazione in secondi, monitoraggio depositi per piattaforme di trading, elaborazione prelievi da un hot wallet, airdrop e piani di vesting, fatturazione ricorrente per SaaS, trasferimenti transfrontalieri. Dove Arbitrum si distingue sono i casi che i prezzi di mainnet escludono: micropagamenti, consolidamenti ad alta frequenza e indirizzi di deposito per utente che necessitano ciascuno di occasionali transazioni di manutenzione.

La maggior parte dei team non costruisce il supporto Arbitrum da zero. Lo aggiunge come seconda chain a un'integrazione Chaingateway esistente, riutilizza lo stesso percorso di codice e cambia chain per richiesta.

Aggiungi X-Network: testnet a qualsiasi richiesta e viene eseguita contro la rete di test; la testnet pubblica di Arbitrum è Arbitrum Sepolia, e l'ETH di test arriva gratis dai faucet. Percorsi, payload e forme di risposta non cambiano, quindi il codice con cui ti eserciti è, byte per byte, il codice che rilasci.

Esegui l'intero ciclo di deposito almeno una volta prima di mainnet: trasferimento in entrata, consegna webhook, verifica firma, consolidamento. Gli errori che vale la pena scoprire, un handler che calcola l'HMAC sul campo payload sbagliato, o un endpoint su cui un load balancer va in timeout, si comportano in modo identico su testnet e in produzione. L'unica differenza è quanto ti costano. Andare in produzione significa eliminare l'header.

Errori client ed errori server richiedono trattamenti opposti. Un 4xx significa che la richiesta stessa è sbagliata, un token scaduto, un indirizzo malformato, un importo che il wallet non può coprire, e ripetere la stessa richiesta ripete il rifiuto; registralo e correggi l'input. Un 5xx o un timeout di rete non porta alcun verdetto sul tuo input, quindi riprova con backoff esponenziale e un limite massimo.

Il caso per cui vale la pena progettare è il timeout ambiguo su un invio. Il tuo client HTTP ha rinunciato, ma il trasferimento potrebbe comunque essere partito, e reinviare alla cieca è il modo in cui accadono i pagamenti duplicati. Prima di qualsiasi nuovo tentativo su un trasferimento, controlla cosa è effettivamente partito, GET /api/v2/arbitrum/transactions elenca i trasferimenti creati tramite l'API, e reinvia solo quando il primo tentativo è verificabilmente fallito. Costruisci quel controllo nel worker dei pagamenti fin dal primo giorno. Costa una GET extra per ogni nuovo tentativo e risparmia la conversazione molto più costosa in cui chiedi a un cliente di restituirti un pagamento doppio.