Arbitrum API: ERC-20 payments on Ethereum's Layer 2

Arbitrum is an optimistic rollup. Transactions execute on Arbitrum's own infrastructure, and the network posts the compressed transaction data to Ethereum, where anyone can reconstruct the L2's state from what is on-chain. "Optimistic" names the security model: state updates are assumed valid when posted, and a challenge window follows during which any observer can submit a fraud proof against an incorrect one. Ethereum arbitrates the dispute. Because the underlying data sits on Ethereum, cheating cannot be hidden, and the L2 inherits L1 security instead of bootstrapping its own validator set.

The design also explains the fee structure. An Arbitrum fee pays for two things: execution on the L2, which is cheap, and the transaction's share of posting batch data to Ethereum. Since March 2024 that data goes into the blob space introduced by EIP-4844, which cut the posting cost by roughly 90% and has kept typical Arbitrum fees at cents or below through 2025 and 2026. Hundreds of transfers share a single batch, so each one carries a sliver of the L1 cost rather than a full L1 transaction fee.

Two public Arbitrum chains exist, and the names get mixed up. Arbitrum One is the rollup just described: all transaction data lands on Ethereum, and the trust assumptions reduce to Ethereum's own. Arbitrum Nova runs the AnyTrust protocol instead. Its transaction data is held off-chain by a Data Availability Committee, and the system stays sound as long as at least two committee members behave honestly; should the committee fail to serve data, the chain falls back to full rollup mode. Keeping data off Ethereum makes Nova cheaper again, at the price of that extra trust assumption.

In practice the split is clean. Nova hosts gaming and social applications, workloads with very high transaction counts and low value per transaction, where the committee trade-off is acceptable. Arbitrum One holds the DeFi protocols, the stablecoin liquidity and the exchange support. When a payment integration, an exchange withdrawal page or this article says "Arbitrum" without a qualifier, Arbitrum One is meant. It is the chain where your users' USDC and USDT actually sit.

An ERC-20 transfer on Ethereum mainnet has run one to twenty dollars through 2026 depending on congestion. The same transfer on Arbitrum costs roughly two to twenty cents, about two orders of magnitude less, because most of the fee covers cheap Layer-2 execution instead of Ethereum gas.

Both networks price dynamically, so the absolute numbers move with ETH's price and network load, but the gas auction on mainnet makes the fee spike exactly when activity peaks, the worst possible correlation for a payment business. The ratio of about two orders of magnitude is the stable part.

For a payment backend the ratio matters more than either absolute number, because payment operations multiply fees. One customer deposit is one incoming transfer, one sweep into the hot wallet and eventually one outgoing payout: three fee events for a single payment. At mainnet prices, teams respond by batching sweeps and delaying payouts, and the delayed funds show up as working capital stranded across scattered deposit wallets. At Arbitrum prices you sweep on schedule and pay out on request, and the fee line disappears into accounting noise.

Small payments come back too. A ten-dollar transfer on L1 can lose a double-digit percentage to gas on a bad day, which is why nobody prices anything at ten dollars on mainnet. On Arbitrum the same transfer loses a fraction of a percent. Per-transaction billing, metered usage and small refunds go from economically absurd to unremarkable.

Arbitrum is fully EVM-compatible, and for payments that phrase has a precise meaning: the same 0x address format with the same EIP-55 checksum, the same ERC-20 contract interface, the same signing scheme. A token contract deployed on Arbitrum exposes the same transfer function as its mainnet counterpart. Nothing about the token standard was reinvented for the L2, which is why wallets, explorers and libraries built for Ethereum handle Arbitrum with a changed RPC endpoint and nothing else.

Through the API this collapses into a path segment. POST /api/v2/ethereum/transactions/erc20 and POST /api/v2/arbitrum/transactions/erc20 take an identical payload: contract address, from, to, amount. Your validation logic, your webhook handler and your database schema carry over as they are, because addresses and transaction hashes have the same shape on both chains. The practical upshot is one advantage stated plainly: the same API call, a different chain. Teams already running Ethereum through Chaingateway usually add Arbitrum in an afternoon, by making the chain a column in a config table instead of a fork in the code.

One thing does not carry over: balances. That is the next section.

An ERC-20 balance is an entry inside a contract on one specific chain. USDT on Ethereum and USDT on Arbitrum are two different contract entries, and holding one gives you nothing of the other. Before your hot wallet can send tokens on Arbitrum, those tokens have to exist on Arbitrum. The API cannot conjure them across; nobody's API can.

Two normal routes get them there. The Arbitrum bridge locks tokens on Ethereum and mints their representation on the L2. The same mechanism runs in reverse for withdrawals back to L1, and that direction includes the challenge window, so moving value back to Ethereum through the canonical bridge takes about a week unless you pay a third-party fast bridge to front the liquidity. The simpler route for most operators: withdraw from an exchange that supports Arbitrum withdrawals, which puts tokens on the L2 in one step and skips bridge mechanics entirely.

Budget gas as well. Fees on Arbitrum are paid in ETH, so a hot wallet needs a small ETH balance on the L2 alongside its tokens. The amounts are tiny, cents per transfer, but a wallet holding tokens and zero ETH cannot move at all, and that failure mode deserves a monitoring alert before it deserves a postmortem.

Arbitrum produces blocks in well under a second, so a deposit is visible almost as soon as the user sends it. Chaingateway forwards that event to your backend instead of making you poll. Set a personal secret in your account and each webhook delivery carries an X-Signature header — a base64-encoded HMAC-SHA256 of the payload's txid — so you can verify it came from Chaingateway. Deliveries that fail are kept in a failed-notifications list and can be re-sent through POST /api/v2/arbitrum/webhooks/notifications/{id}/retry.

GET /api/v2/arbitrum/webhooks/notifications returns the delivery history, which is handy for audits or for replaying events after downtime on your side. The webhook guide covers setup and signature verification.

A concrete deposit flow, end to end. Each customer gets a deposit address of their own, which is what makes incoming payments attributable without memo fields that users forget to fill in. You watch those addresses through webhooks, and watching requires no keys.

From deposit to credited

A customer sends 200 USDC from their exchange account and picks Arbitrum as the withdrawal network. Blocks land in well under a second, so the transfer is on-chain almost immediately, and Chaingateway POSTs the event to your endpoint. Your handler verifies the HMAC signature, checks the token contract against an allowlist, and records the deposit as pending. Once the deposit meets your own confirmation policy, the record flips to credited. On a chain this fast, the customer experiences the whole sequence as instant, which is worth something at checkout: the difference between "payment received" appearing before or after the user starts wondering whether it worked.

Sweeping and payouts

Then the housekeeping that L1 fees used to make painful. On a schedule, or whenever a balance crosses a threshold, you sweep deposits into the hot wallet with POST /api/v2/arbitrum/transactions/erc20, from the deposit address, to the hot wallet. At cents per sweep this can run hourly instead of weekly, keeping funds concentrated where the payout process can reach them instead of dribbled across hundreds of addresses. Withdrawals are the same call in the other direction, hot wallet to customer address. Nothing in the flow is Arbitrum-specific except the path segment and the fee level, and the fee level is precisely what makes the hourly schedule affordable.

Full EVM compatibility means Ethereum knowledge transfers one to one: address checksums, token contracts and signing behave exactly like mainnet. Fees are a fraction of Ethereum L1, which turns small transfers from a loss into a rounding error. Security derives from Ethereum itself, because transaction data is posted to L1 and incorrect state can be challenged there. And the ecosystem is not a bet on the future: large DeFi protocols run on Arbitrum in production today, so liquidity, explorers and wallet support already exist.

Chaingateway supports the standard tokens on Arbitrum, established stablecoins as well as bridged assets and custom launches. The integration is the same across every supported chain: build once, then point the same code at /api/v2/ethereum/, /api/v2/polygon/ or /api/v2/bsc/ when you expand. The blockchain API overview lists all seven chains.

The use cases match the other EVM chains: checkout flows that accept stablecoins with settlement in seconds, deposit monitoring for trading platforms, withdrawal processing from a hot wallet, airdrops and vesting payouts, recurring billing for SaaS, cross-border transfers. Where Arbitrum stands out is the cases mainnet prices away, micropayments, high-frequency sweeps and per-user deposit addresses that each need occasional maintenance transactions.

Most teams do not build Arbitrum support from scratch. They add it as a second chain to an existing Chaingateway integration, reuse the code path and switch chains per request.

Add X-Network: testnet to any request and it runs against the test network; Arbitrum's public testnet is Arbitrum Sepolia, and test ETH comes free from faucets. Paths, payloads and response shapes do not change, so the code you rehearse with is byte for byte the code you ship.

Run the full deposit cycle at least once before mainnet: incoming transfer, webhook delivery, signature verification, sweep. The mistakes worth catching, a handler that computes the HMAC over the wrong payload field, or an endpoint that a load balancer times out, behave identically on testnet and in production. The only difference is what they cost you. Going live is deleting the header.

Client errors and server errors want opposite treatment. A 4xx means the request itself is wrong, an expired token, a malformed address, an amount the wallet cannot cover, and retrying the identical request repeats the rejection; log it and fix the input. A 5xx or a network timeout carries no verdict on your input, so retry with exponential backoff and a cap.

The case to engineer for is the ambiguous timeout on a send. Your HTTP client gave up, but the transfer may have gone out anyway, and blind resending is how duplicate payouts happen. Before any retry of a transfer, check what actually went out, GET /api/v2/arbitrum/transactions lists the transfers created through the API, and resend only when the first attempt verifiably failed. Build that check into the payout worker on day one. It costs an extra GET per retry and saves the far more expensive conversation where you ask a customer to send a double payment back.