Arbitrum API: ERC-20-Zahlungen auf Ethereums Layer 2

Arbitrum ist ein Optimistic Rollup. Transaktionen laufen auf Arbitrums eigener Infrastruktur, und das Netzwerk postet die komprimierten Transaktionsdaten auf Ethereum, wo jeder den State des L2 aus dem rekonstruieren kann, was on-chain steht. „Optimistic“ benennt das Sicherheitsmodell: State-Updates gelten beim Posten als gültig, und ein Challenge-Fenster folgt, in dem jeder Beobachter einen Fraud Proof gegen ein falsches einreichen kann. Ethereum entscheidet den Streit. Weil die zugrunde liegenden Daten auf Ethereum liegen, kann Betrug nicht verborgen werden, und das L2 erbt L1-Sicherheit statt eine eigene Validator-Menge aufzubauen.

Das Design erklärt auch die Gebührenstruktur. Eine Arbitrum-Gebühr bezahlt zwei Dinge: Ausführung auf dem L2, die günstig ist, und den Anteil der Transaktion am Posten der Batch-Daten auf Ethereum. Seit März 2024 gehen diese Daten in den mit EIP-4844 eingeführten Blob-Space, was die Posting-Kosten um etwa 90 % gesenkt und typische Arbitrum-Gebühren durch 2025 und 2026 im Cent-Bereich oder darunter gehalten hat. Hunderte Transfers teilen sich einen einzigen Batch, sodass jeder nur einen Splitter der L1-Kosten trägt statt einer vollen L1-Transaktionsgebühr.

Es gibt zwei öffentliche Arbitrum-Chains, und die Namen werden oft verwechselt. Arbitrum One ist der eben beschriebene Rollup: Alle Transaktionsdaten landen auf Ethereum, und die Vertrauensannahmen reduzieren sich auf die von Ethereum selbst. Arbitrum Nova läuft stattdessen mit dem AnyTrust-Protokoll. Seine Transaktionsdaten werden off-chain von einem Data Availability Committee gehalten, und das System bleibt solide, solange mindestens zwei Committee-Mitglieder sich ehrlich verhalten; sollte das Committee keine Daten liefern, fällt die Chain in den vollen Rollup-Modus zurück. Daten von Ethereum fernzuhalten macht Nova wieder günstiger, um den Preis dieser zusätzlichen Vertrauensannahme.

In der Praxis ist die Trennung sauber. Nova beherbergt Gaming- und Social-Anwendungen, Workloads mit sehr hohen Transaktionszahlen und geringem Wert pro Transaktion, wo der Committee-Trade-off akzeptabel ist. Arbitrum One hält die DeFi-Protokolle, die Stablecoin-Liquidität und die Börsenunterstützung. Wenn eine Zahlungsintegration, eine Börsen-Auszahlungsseite oder dieser Artikel „Arbitrum“ ohne Zusatz sagt, ist Arbitrum One gemeint. Es ist die Chain, auf der das USDC und USDT Ihrer Nutzer tatsächlich liegen.

Ein ERC-20-Transfer auf Ethereum Mainnet hat durch 2026 je nach Auslastung zwischen einem und zwanzig Dollar gekostet. Derselbe Transfer auf Arbitrum kostet etwa zwei bis zwanzig Cent, rund zwei Größenordnungen weniger, weil der Großteil der Gebühr günstige Layer-2-Ausführung deckt statt Ethereum-Gas.

Beide Netzwerke bepreisen dynamisch, sodass sich die absoluten Zahlen mit dem ETH-Preis und der Netzwerklast bewegen, aber die Gas-Auktion auf Mainnet lässt die Gebühr genau dann in die Höhe schnellen, wenn die Aktivität ihren Höhepunkt erreicht – die denkbar schlechteste Korrelation für ein Payments-Geschäft. Das Verhältnis von rund zwei Größenordnungen ist der stabile Teil.

Für ein Payments-Backend zählt das Verhältnis mehr als jede der beiden absoluten Zahlen, weil Payment-Operationen Gebühren multiplizieren. Ein Kunden-Deposit ist ein eingehender Transfer, ein Sweep in die Hot Wallet und irgendwann eine ausgehende Auszahlung: drei Gebühren-Events für eine einzige Zahlung. Zu Mainnet-Preisen reagieren Teams, indem sie Sweeps bündeln und Auszahlungen verzögern, und die verzögerten Gelder tauchen als in verstreuten Deposit-Wallets gebundenes Working Capital auf. Zu Arbitrum-Preisen fegen Sie nach Plan und zahlen auf Anfrage aus, und die Gebührenlinie verschwindet im Buchhaltungsrauschen.

Auch kleine Zahlungen kommen zurück. Ein Zehn-Dollar-Transfer auf L1 kann an einem schlechten Tag einen zweistelligen Prozentsatz an Gas verlieren, weshalb niemand auf Mainnet etwas für zehn Dollar bepreist. Auf Arbitrum verliert derselbe Transfer einen Bruchteil eines Prozents. Pro-Transaktion-Abrechnung, gemessene Nutzung und kleine Rückerstattungen wechseln von ökonomisch absurd zu unauffällig.

Arbitrum ist vollständig EVM-kompatibel, und für Zahlungen hat dieser Satz eine präzise Bedeutung: dasselbe 0x-Adressformat mit derselben EIP-55-Checksum, dieselbe ERC-20-Contract-Schnittstelle, dasselbe Signaturschema. Ein auf Arbitrum deployter Token-Contract stellt dieselbe transfer-Funktion bereit wie sein Mainnet-Gegenstück. Am Token-Standard wurde für das L2 nichts neu erfunden, weshalb Wallets, Explorer und Bibliotheken, die für Ethereum gebaut sind, Arbitrum mit einem geänderten RPC-Endpoint und sonst nichts handhaben.

Über die API kollabiert das zu einem Pfadsegment. POST /api/v2/ethereum/transactions/erc20 und POST /api/v2/arbitrum/transactions/erc20 nehmen ein identisches Payload: Contract-Adresse, from, to, Betrag. Ihre Validierungslogik, Ihr Webhook-Handler und Ihr Datenbankschema übertragen sich unverändert, weil Adressen und Transaktions-Hashes auf beiden Chains dieselbe Form haben. Der praktische Nutzen ist ein Vorteil klar ausgesprochen: derselbe API-Aufruf, eine andere Chain. Teams, die bereits Ethereum über Chaingateway betreiben, fügen Arbitrum meist an einem Nachmittag hinzu, indem sie die Chain zu einer Spalte in einer Config-Tabelle machen statt zu einem Fork im Code.

Eines überträgt sich nicht: Guthaben. Das ist der nächste Abschnitt.

Ein ERC-20-Guthaben ist ein Eintrag innerhalb eines Contracts auf einer bestimmten Chain. USDT auf Ethereum und USDT auf Arbitrum sind zwei verschiedene Contract-Einträge, und der Besitz des einen gibt Ihnen nichts vom anderen. Bevor Ihre Hot Wallet Token auf Arbitrum senden kann, müssen diese Token auf Arbitrum existieren. Die API kann sie nicht dorthin herbeizaubern; das kann keine API.

Zwei normale Wege bringen sie dorthin. Die Arbitrum-Bridge sperrt Token auf Ethereum und mintet ihre Repräsentation auf dem L2. Derselbe Mechanismus läuft umgekehrt für Auszahlungen zurück zu L1, und diese Richtung schließt das Challenge-Fenster ein, sodass Wert über die kanonische Bridge zurück nach Ethereum zu bewegen etwa eine Woche dauert, es sei denn, Sie zahlen für eine Fast-Bridge eines Drittanbieters, die die Liquidität vorstreckt. Der einfachere Weg für die meisten Betreiber: von einer Börse abheben, die Arbitrum-Auszahlungen unterstützt, was Token in einem Schritt auf das L2 bringt und Bridge-Mechanik ganz überspringt.

Budgetieren Sie auch Gas ein. Gebühren auf Arbitrum werden in ETH bezahlt, sodass eine Hot Wallet neben ihren Token ein kleines ETH-Guthaben braucht. Die Beträge sind winzig, Cent-Beträge pro Transfer, aber eine Wallet mit Token und null ETH kann sich gar nicht bewegen, und dieser Fehlermodus verdient einen Monitoring-Alert, bevor er einen Post-Mortem verdient.

Arbitrum produziert Blöcke deutlich unter einer Sekunde, sodass ein Deposit fast sofort sichtbar ist, nachdem der Nutzer es sendet. Chaingateway leitet dieses Event an Ihr Backend weiter, statt Sie pollen zu lassen. Setzen Sie ein persönliches Secret in Ihrem Konto, und jede Webhook-Zustellung trägt einen X-Signature-Header – ein base64-kodiertes HMAC-SHA256 der txid des Payloads –, sodass Sie verifizieren können, dass sie von Chaingateway stammt. Fehlgeschlagene Zustellungen werden in einer Failed-Notifications-Liste gehalten und lassen sich über POST /api/v2/arbitrum/webhooks/notifications/{id}/retry erneut senden.

GET /api/v2/arbitrum/webhooks/notifications gibt die Zustellungshistorie zurück, praktisch für Audits oder um Events nach Downtime auf Ihrer Seite erneut abzuspielen. Der Webhook-Guide behandelt Setup und Signaturverifizierung.

Ein konkreter Deposit-Flow, Ende zu Ende. Jeder Kunde bekommt eine eigene Deposit-Adresse, was eingehende Zahlungen ohne Memo-Felder zuordenbar macht, die Nutzer vergessen auszufüllen. Sie beobachten diese Adressen per Webhook, und Beobachten braucht keine Keys.

Vom Deposit zur Gutschrift

Ein Kunde sendet 200 USDC von seinem Börsenkonto und wählt Arbitrum als Auszahlungsnetzwerk. Blöcke landen deutlich unter einer Sekunde, sodass der Transfer fast sofort on-chain ist, und Chaingateway sendet das Event per POST an Ihren Endpoint. Ihr Handler verifiziert die HMAC-Signatur, prüft den Token-Contract gegen eine Allowlist und erfasst den Deposit als pending. Sobald der Deposit Ihrer eigenen Bestätigungs-Policy genügt, kippt der Datensatz auf credited. Auf einer so schnellen Chain erlebt der Kunde die gesamte Sequenz als sofort, was am Checkout etwas wert ist: der Unterschied zwischen „Zahlung erhalten“, das erscheint, bevor oder nachdem der Nutzer sich zu fragen beginnt, ob es funktioniert hat.

Sweeping und Auszahlungen

Dann die Hausarbeit, die L1-Gebühren früher schmerzhaft gemacht haben. Nach Plan, oder wann immer ein Guthaben einen Schwellenwert überschreitet, fegen Sie Deposits mit POST /api/v2/arbitrum/transactions/erc20 in die Hot Wallet, von der Deposit-Adresse zur Hot Wallet. Zu Cent-Beträgen pro Sweep kann das stündlich statt wöchentlich laufen und hält Gelder konzentriert dort, wo der Auszahlungsprozess sie erreicht, statt über Hunderte Adressen verstreut. Auszahlungen sind derselbe Aufruf in die andere Richtung, Hot Wallet zur Kundenadresse. Nichts im Flow ist Arbitrum-spezifisch außer dem Pfadsegment und dem Gebührenniveau, und genau das Gebührenniveau macht den stündlichen Zeitplan erschwinglich.

Volle EVM-Kompatibilität bedeutet, dass sich Ethereum-Wissen eins zu eins überträgt: Adress-Checksums, Token-Contracts und Signieren verhalten sich exakt wie auf Mainnet. Gebühren sind ein Bruchteil von Ethereum L1, was kleine Transfers von einem Verlust zu einem Rundungsfehler macht. Sicherheit leitet sich von Ethereum selbst ab, weil Transaktionsdaten auf L1 gepostet und falscher State dort angefochten werden kann. Und das Ökosystem ist keine Wette auf die Zukunft: große DeFi-Protokolle laufen heute produktiv auf Arbitrum, sodass Liquidität, Explorer und Wallet-Unterstützung bereits existieren.

Chaingateway unterstützt die Standard-Token auf Arbitrum, etablierte Stablecoins ebenso wie gebridgte Assets und eigene Launches. Die Integration ist über jede unterstützte Chain hinweg gleich: einmal bauen, dann denselben Code beim Erweitern auf /api/v2/ethereum/, /api/v2/polygon/ oder /api/v2/bsc/ richten. Die Blockchain-API-Übersicht listet alle sieben Chains.

Die Use-Cases entsprechen den anderen EVM-Chains: Checkout-Flows, die Stablecoins mit Abwicklung in Sekunden annehmen, Deposit-Monitoring für Trading-Plattformen, Auszahlungsverarbeitung aus einer Hot Wallet, Airdrops und Vesting-Auszahlungen, wiederkehrende Abrechnung für SaaS, grenzüberschreitende Transfers. Wo Arbitrum heraussticht, sind die Fälle, die Mainnet-Preise wegdrängen: Mikrozahlungen, hochfrequente Sweeps und Pro-Nutzer-Deposit-Adressen, die jeweils gelegentliche Wartungstransaktionen brauchen.

Die meisten Teams bauen Arbitrum-Support nicht von Grund auf. Sie fügen ihn als zweite Chain zu einer bestehenden Chaingateway-Integration hinzu, nutzen den Code-Pfad wieder und wechseln pro Request die Chain.

Fügen Sie X-Network: testnet zu jedem Request hinzu, und er läuft gegen das Testnetzwerk; Arbitrums öffentliches Testnet ist Arbitrum Sepolia, und Test-ETH kommt kostenlos von Faucets. Pfade, Payloads und Response-Formen ändern sich nicht, sodass der Code, mit dem Sie proben, byte-genau der Code ist, den Sie ausliefern.

Führen Sie den vollständigen Deposit-Zyklus mindestens einmal vor Mainnet durch: eingehender Transfer, Webhook-Zustellung, Signaturverifizierung, Sweep. Die Fehler, die es wert sind, gefunden zu werden – ein Handler, der das HMAC über das falsche Payload-Feld berechnet, oder ein Endpoint, den ein Load Balancer per Timeout abbricht – verhalten sich auf Testnet identisch zu Produktion. Der einzige Unterschied ist, was sie Sie kosten. Live gehen bedeutet, den Header zu löschen.

Client-Fehler und Server-Fehler wollen entgegengesetzte Behandlung. Ein 4xx bedeutet, dass der Request selbst falsch ist, ein abgelaufener Token, eine fehlerhafte Adresse, ein Betrag, den die Wallet nicht deckt, und den identischen Request zu wiederholen wiederholt nur die Ablehnung; loggen Sie ihn und korrigieren Sie den Input. Ein 5xx oder ein Netzwerk-Timeout trägt kein Urteil über Ihren Input, also wiederholen Sie mit exponentiellem Backoff und einer Obergrenze.

Der Fall, für den Sie konstruieren sollten, ist der mehrdeutige Timeout bei einem Send. Ihr HTTP-Client hat aufgegeben, aber der Transfer könnte trotzdem rausgegangen sein, und blindes erneutes Senden ist, wie doppelte Auszahlungen passieren. Prüfen Sie vor jedem Retry eines Transfers, was tatsächlich rausging, GET /api/v2/arbitrum/transactions listet die über die API erstellten Transfers, und senden Sie nur erneut, wenn der erste Versuch nachweislich fehlschlug. Bauen Sie diese Prüfung von Tag eins in den Auszahlungs-Worker ein. Sie kostet ein zusätzliches GET pro Retry und erspart das weit teurere Gespräch, in dem Sie einen Kunden bitten, eine doppelte Zahlung zurückzusenden.