Arbitrum API : paiements ERC-20 sur le Layer 2 d'Ethereum

Arbitrum est un rollup optimiste. Les transactions s'exécutent sur l'infrastructure propre d'Arbitrum, et le réseau poste les données de transaction compressées sur Ethereum, où quiconque peut reconstruire l'état du L2 à partir de ce qui est on-chain. « Optimiste » nomme le modèle de sécurité : les mises à jour d'état sont présumées valides au moment de la publication, et une fenêtre de contestation suit, durant laquelle tout observateur peut soumettre une preuve de fraude contre une mise à jour incorrecte. Ethereum arbitre le litige. Comme les données sous-jacentes se trouvent sur Ethereum, la tricherie ne peut pas être cachée, et le L2 hérite de la sécurité L1 au lieu de démarrer son propre ensemble de validateurs.

Le design explique aussi la structure des frais. Des frais Arbitrum paient deux choses : l'exécution sur le L2, qui est bon marché, et la part de la transaction dans la publication des données du lot sur Ethereum. Depuis mars 2024, ces données vont dans l'espace blob introduit par EIP-4844, qui a réduit le coût de publication d'environ 90 % et a maintenu les frais Arbitrum typiques à quelques centimes ou moins tout au long de 2025 et 2026. Des centaines de transferts partagent un seul lot, si bien que chacun porte une fraction du coût L1 plutôt que des frais de transaction L1 complets.

Il existe deux chaînes Arbitrum publiques, et les noms sont souvent confondus. Arbitrum One est le rollup décrit ci-dessus : toutes les données de transaction atterrissent sur Ethereum, et les hypothèses de confiance se réduisent à celles d'Ethereum lui-même. Arbitrum Nova utilise à la place le protocole AnyTrust. Ses données de transaction sont conservées hors chaîne par un Data Availability Committee, et le système reste fiable tant qu'au moins deux membres du comité se comportent honnêtement ; si le comité échoue à servir les données, la chaîne retombe en mode rollup complet. Garder les données hors d'Ethereum rend Nova à nouveau moins cher, au prix de cette hypothèse de confiance supplémentaire.

En pratique, la répartition est nette. Nova héberge les applications de gaming et sociales, des charges de travail avec un très grand nombre de transactions et une faible valeur par transaction, où le compromis du comité est acceptable. Arbitrum One détient les protocoles DeFi, la liquidité en stablecoins et le support des plateformes d'échange. Quand une intégration de paiement, une page de retrait d'exchange ou cet article dit « Arbitrum » sans qualificatif, c'est Arbitrum One qui est visé. C'est la chaîne où se trouvent réellement l'USDC et l'USDT de vos utilisateurs.

Un transfert ERC-20 sur Ethereum mainnet a coûté entre un et vingt dollars tout au long de 2026 selon la congestion. Le même transfert sur Arbitrum coûte environ deux à vingt centimes, soit environ deux ordres de grandeur de moins, car la majeure partie des frais couvre une exécution Layer-2 bon marché plutôt que du gas Ethereum.

Les deux réseaux tarifient dynamiquement, donc les chiffres absolus bougent avec le prix de l'ETH et la charge réseau, mais l'enchère de gas sur mainnet fait grimper les frais précisément quand l'activité atteint son pic, la pire corrélation possible pour une entreprise de paiement. Le ratio d'environ deux ordres de grandeur est la partie stable.

Pour un backend de paiement, le ratio compte plus que l'un ou l'autre nombre absolu, car les opérations de paiement multiplient les frais. Un dépôt client, c'est un transfert entrant, un balayage vers le hot wallet et éventuellement un paiement sortant : trois événements de frais pour un seul paiement. Aux prix du mainnet, les équipes réagissent en groupant les balayages et en retardant les paiements, et les fonds retardés apparaissent comme du fonds de roulement bloqué dans des wallets de dépôt épars. Aux prix d'Arbitrum, vous balayez selon le calendrier et payez à la demande, et la ligne de frais disparaît dans le bruit comptable.

Les petits paiements reviennent aussi. Un transfert de dix dollars sur L1 peut perdre un pourcentage à deux chiffres en gas un mauvais jour, c'est pourquoi personne ne tarife quoi que ce soit à dix dollars sur mainnet. Sur Arbitrum, le même transfert perd une fraction de pourcent. La facturation à la transaction, l'usage mesuré et les petits remboursements passent d'économiquement absurdes à insignifiants.

Arbitrum est entièrement compatible EVM, et pour les paiements cette phrase a un sens précis : le même format d'adresse 0x avec la même checksum EIP-55, la même interface de contrat ERC-20, le même schéma de signature. Un contrat de token déployé sur Arbitrum expose la même fonction transfer que son équivalent mainnet. Rien dans le standard de token n'a été réinventé pour le L2, ce qui explique pourquoi les wallets, explorateurs et bibliothèques construits pour Ethereum gèrent Arbitrum avec un endpoint RPC changé et rien de plus.

Via l'API, cela se réduit à un segment de chemin. POST /api/v2/ethereum/transactions/erc20 et POST /api/v2/arbitrum/transactions/erc20 prennent un payload identique : adresse du contrat, from, to, montant. Votre logique de validation, votre handler de webhook et votre schéma de base de données se transposent tels quels, car les adresses et les hachages de transaction ont la même forme sur les deux chaînes. L'avantage pratique tient en une phrase : le même appel API, une chaîne différente. Les équipes qui font déjà tourner Ethereum via Chaingateway ajoutent généralement Arbitrum en un après-midi, en faisant de la chaîne une colonne dans une table de configuration plutôt qu'une bifurcation dans le code.

Une chose ne se transpose pas : les soldes. C'est la section suivante.

Un solde ERC-20 est une entrée à l'intérieur d'un contrat sur une chaîne spécifique. L'USDT sur Ethereum et l'USDT sur Arbitrum sont deux entrées de contrat différentes, et détenir l'une ne vous donne rien de l'autre. Avant que votre hot wallet puisse envoyer des tokens sur Arbitrum, ces tokens doivent exister sur Arbitrum. L'API ne peut pas les faire apparaître par magie ; aucune API ne le peut.

Deux voies normales les y amènent. Le bridge Arbitrum verrouille des tokens sur Ethereum et mint leur représentation sur le L2. Le même mécanisme fonctionne en sens inverse pour les retraits vers L1, et cette direction inclut la fenêtre de contestation, donc déplacer de la valeur vers Ethereum via le bridge canonique prend environ une semaine, sauf à payer un bridge rapide tiers pour avancer la liquidité. La voie la plus simple pour la plupart des opérateurs : retirer d'une plateforme d'échange qui supporte les retraits Arbitrum, ce qui met des tokens sur le L2 en une seule étape et évite entièrement la mécanique de bridge.

Budgétez aussi le gas. Les frais sur Arbitrum sont payés en ETH, donc un hot wallet a besoin d'un petit solde ETH sur le L2 en plus de ses tokens. Les montants sont infimes, des centimes par transfert, mais un wallet détenant des tokens et zéro ETH ne peut pas bouger du tout, et ce mode de défaillance mérite une alerte de surveillance avant de mériter un post-mortem.

Arbitrum produit des blocs en bien moins d'une seconde, donc un dépôt est visible presque dès que l'utilisateur l'envoie. Chaingateway transmet cet événement à votre backend au lieu de vous faire sonder. Définissez un secret personnel dans votre compte et chaque livraison de webhook porte un en-tête X-Signature — un HMAC-SHA256 encodé en base64 du txid du payload — pour que vous puissiez vérifier qu'elle provient de Chaingateway. Les livraisons échouées sont conservées dans une liste de notifications échouées et peuvent être renvoyées via POST /api/v2/arbitrum/webhooks/notifications/{id}/retry.

GET /api/v2/arbitrum/webhooks/notifications retourne l'historique de livraison, pratique pour les audits ou pour rejouer des événements après une interruption de votre côté. Le guide des webhooks couvre la configuration et la vérification de signature.

Un flux de dépôt concret, de bout en bout. Chaque client reçoit sa propre adresse de dépôt, ce qui rend les paiements entrants attribuables sans champs de mémo que les utilisateurs oublient de remplir. Vous surveillez ces adresses via des webhooks, et surveiller ne requiert aucune clé.

Du dépôt au crédit

Un client envoie 200 USDC depuis son compte d'échange et choisit Arbitrum comme réseau de retrait. Les blocs atterrissent en bien moins d'une seconde, donc le transfert est on-chain presque immédiatement, et Chaingateway envoie l'événement par POST à votre endpoint. Votre handler vérifie la signature HMAC, vérifie le contrat de token contre une liste blanche, et enregistre le dépôt comme en attente. Une fois que le dépôt satisfait votre propre politique de confirmation, l'enregistrement bascule à crédité. Sur une chaîne aussi rapide, le client vit toute la séquence comme instantanée, ce qui vaut quelque chose au checkout : la différence entre « paiement reçu » qui apparaît avant ou après que l'utilisateur commence à se demander si ça a fonctionné.

Balayage et paiements sortants

Puis les tâches ménagères que les frais L1 rendaient pénibles. Selon un calendrier, ou chaque fois qu'un solde franchit un seuil, vous balayez les dépôts vers le hot wallet avec POST /api/v2/arbitrum/transactions/erc20, depuis l'adresse de dépôt, vers le hot wallet. À quelques centimes par balayage, cela peut tourner à l'heure plutôt qu'à la semaine, gardant les fonds concentrés là où le processus de paiement peut les atteindre plutôt qu'éparpillés sur des centaines d'adresses. Les retraits sont le même appel dans l'autre sens, du hot wallet vers l'adresse du client. Rien dans le flux n'est spécifique à Arbitrum sauf le segment de chemin et le niveau de frais, et c'est précisément le niveau de frais qui rend le calendrier horaire abordable.

La compatibilité EVM complète signifie que la connaissance d'Ethereum se transfère un pour un : checksums d'adresse, contrats de token et signature se comportent exactement comme sur mainnet. Les frais sont une fraction de ceux d'Ethereum L1, ce qui transforme les petits transferts d'une perte en une erreur d'arrondi. La sécurité dérive d'Ethereum lui-même, car les données de transaction sont publiées sur L1 et un état incorrect peut y être contesté. Et l'écosystème n'est pas un pari sur l'avenir : de grands protocoles DeFi tournent sur Arbitrum en production aujourd'hui, donc la liquidité, les explorateurs et le support wallet existent déjà.

Chaingateway supporte les tokens standards sur Arbitrum, les stablecoins établis ainsi que les actifs bridgés et les lancements personnalisés. L'intégration est la même sur chaque chaîne supportée : construisez une fois, puis pointez le même code vers /api/v2/ethereum/, /api/v2/polygon/ ou /api/v2/bsc/ quand vous vous étendez. L'aperçu de la blockchain API liste les sept chaînes.

Les cas d'usage correspondent aux autres chaînes EVM : flux de checkout acceptant des stablecoins avec règlement en quelques secondes, surveillance des dépôts pour plateformes de trading, traitement des retraits depuis un hot wallet, airdrops et paiements de vesting, facturation récurrente pour SaaS, transferts transfrontaliers. Là où Arbitrum se distingue, ce sont les cas que les prix du mainnet excluent : micropaiements, balayages à haute fréquence et adresses de dépôt par utilisateur nécessitant chacune des transactions de maintenance occasionnelles.

La plupart des équipes ne construisent pas le support Arbitrum à partir de zéro. Elles l'ajoutent comme seconde chaîne à une intégration Chaingateway existante, réutilisent le chemin de code et basculent de chaîne par requête.

Ajoutez X-Network: testnet à n'importe quelle requête et elle tourne contre le réseau de test ; le testnet public d'Arbitrum est Arbitrum Sepolia, et l'ETH de test est gratuit via des faucets. Chemins, payloads et formes de réponse ne changent pas, donc le code avec lequel vous vous entraînez est, octet pour octet, le code que vous livrez.

Exécutez le cycle de dépôt complet au moins une fois avant mainnet : transfert entrant, livraison de webhook, vérification de signature, balayage. Les erreurs qui valent la peine d'être détectées, un handler qui calcule le HMAC sur le mauvais champ de payload, ou un endpoint qu'un load balancer fait expirer, se comportent de façon identique sur testnet et en production. Seul ce qu'elles vous coûtent diffère. Passer en production consiste à supprimer l'en-tête.

Les erreurs client et les erreurs serveur veulent un traitement opposé. Un 4xx signifie que la requête elle-même est erronée, un jeton expiré, une adresse malformée, un montant que le wallet ne peut couvrir, et réessayer la requête identique répète le rejet ; loguez-la et corrigez l'entrée. Un 5xx ou un timeout réseau ne porte aucun verdict sur votre entrée, donc réessayez avec un backoff exponentiel et un plafond.

Le cas à concevoir en priorité est le timeout ambigu sur un envoi. Votre client HTTP a abandonné, mais le transfert a peut-être quand même été diffusé, et renvoyer aveuglément est ainsi que des paiements en double se produisent. Avant tout nouvel essai d'un transfert, vérifiez ce qui est réellement sorti, GET /api/v2/arbitrum/transactions liste les transferts créés via l'API, et ne renvoyez que si la première tentative a manifestement échoué. Intégrez cette vérification au worker de paiement dès le premier jour. Cela coûte un GET supplémentaire par nouvel essai et épargne la conversation bien plus coûteuse où vous demandez à un client de vous renvoyer un paiement en double.