The Arbitrum network: a lower-cost EVM L2 for payments

Arbitrum is an Ethereum layer-2: a separate chain that runs the same EVM execution and the same account and address model as Ethereum mainnet, but settles its own blocks at a fraction of mainnet gas. For a payment processor the load-bearing facts are that it is EVM-compatible (so wallets and addresses behave exactly as they do on Ethereum), that the customer's transaction fee is paid in ETH and is far cheaper than on mainnet, and that it is a distinct network with its own confirmations — not a discount mode of Ethereum. This page is about the network itself and how halfin accepts and pays out on it.

An Ethereum L2, not a separate world

Arbitrum is a layer-2 rollup built on Ethereum. The practical meaning of that for a payment is simple: it runs the Ethereum Virtual Machine, so the way a transaction executes, the way an account is identified, and the format of an address are the same as on Ethereum mainnet. A wallet that can pay on Ethereum can pay on Arbitrum with the same key and the same address — the customer switches the network in their wallet, not their identity. For a merchant this is the appeal: the familiar EVM payer experience, with the mainnet fee burden removed.

What makes it a layer-2 rather than just another chain is where it ultimately commits. Arbitrum executes transactions off Ethereum mainnet, batches them, and posts the result back to Ethereum, which acts as the settlement layer of record. That architecture is why fees are low — the heavy execution happens on the L2, and only compressed data is committed to mainnet — and it is also why Arbitrum is a network in its own right: it produces its own blocks, runs its own fee market, and is watched on its own settlement gate, distinct from the mainnet gate.

Because it shares Ethereum's account model, an Arbitrum address is an Ethereum-shaped address, and one address can receive any asset that settles on the chain. halfin presents the deposit address for an invoice; whatever supported asset the customer sends on Arbitrum lands at that address on the Arbitrum network. The asset choice changes the transaction type and the fee, not the address.

• EVM-compatible: same execution semantics, same account model, same address format as Ethereum.
• A rollup: transactions execute on the L2 and commit back to Ethereum as the settlement layer.
• A distinct network for settlement — its own blocks, its own fee market, its own confirmation behavior.

Gas is paid in ETH, and it is cheap

Arbitrum charges for transactions the same way Ethereum does — in gas, denominated in ETH. A customer paying on Arbitrum pays the network's fee in ETH, just as they would on mainnet, which is why ETH is the gas asset here too. The difference is the magnitude: because the L2 does the execution and only commits compressed data to Ethereum, the fee a payer pays to move value on Arbitrum is a small fraction of what the same transaction would cost on mainnet. That gap is the entire reason a rate-shopping payer reaches for an L2.

The fee is still a public-network cost paid by whoever sends the transaction — it goes to the network, never to halfin, and it is never a halfin charge. It matters to you as context: on a busy mainnet, moving a small payment can cost a meaningful fraction of the amount, and Arbitrum largely removes that friction. The gas price on the L2 floats with its own demand and with the cost of committing back to Ethereum, so it is not fixed, but in normal conditions it stays well below mainnet.

The same EVM rule applies as on Ethereum: a customer needs a little ETH on Arbitrum to pay gas, even when the asset they are sending is something else. A payer who has bridged value onto Arbitrum but holds no ETH there cannot move it until they have a small ETH balance for the fee. This is the familiar EVM friction, just at a much smaller absolute cost than on mainnet.

Confirmations and reorg-aware crediting

Arbitrum produces blocks quickly, which is part of why it feels responsive to a payer — a transaction is included into an L2 block soon after it is sent. But inclusion is not the same as settled, and a payment surface must not credit on first sight. As with every network halfin settles on, an Arbitrum deposit is not marked paid the instant it appears; halfin waits for the network's confirmation threshold before an invoice flips to paid.

That waiting matters because, like any chain, an L2 can reorganize a recently produced block before it has effectively committed. If halfin marked an invoice paid on a transaction's first appearance, a reorganization that later dropped that transaction would leave you having released goods against a payment that no longer exists. Instead, crediting accumulates confirmations toward the threshold, and only then does the invoice settle and a signed webhook fire. You wait for the paid event, not the first sight of a transaction.

halfin's crediting on Arbitrum is reorg-aware throughout, exactly as it is on Ethereum mainnet. If a reorganization unwinds a transaction that was already observed, halfin reflects that rather than pretending the payment still holds — the settled amount you see is one that actually held on-chain. For your integration the lifecycle is the same regardless of which EVM network cleared the payment: observe, accumulate confirmations, settle, emit a signed event.

Arbitrum in the EVM family

Arbitrum sits in the same family as Ethereum mainnet and the other EVM L2s halfin settles on — Base and Polygon. They share Ethereum's account and address model and EVM execution, which is what lets a payer use the same wallet across all of them, but each is a distinct network with its own blocks, fees, and settlement. A payment on Arbitrum is not a cheaper instance of a mainnet payment — it is a different deposit on a different chain, watched on its own gate.

That separation is deliberate and load-bearing for reconciliation. The network on which a payment settled comes back to you alongside the asset, on the invoice record and on every webhook event, so your ledger always knows whether a given transfer arrived over Arbitrum, over Base, or over Ethereum mainnet. Two customers paying the same fiat amount in the same asset over different EVM rails produce two unambiguous, separately attributable settlements.

The table is the practical comparison a payer makes inside the EVM family: where their value already sits and what the fee feels like. The choice between mainnet and an L2 is, in the end, a fee-versus-where-the-money-already-lives decision the customer makes — you present the asset-on-network options you accept and let them settle from whatever they hold.

How halfin accepts and pays out on Arbitrum

You do not integrate the Arbitrum network directly — you create an invoice and let the customer settle in whatever supported asset they hold. halfin presents the deposit address for that invoice; the customer pays on Arbitrum to it; halfin's Arbitrum gate watches the chain, matches the deposit to the invoice, waits for the confirmation threshold, and credits your balance. The network on which the payment settled is recorded on the invoice and on every webhook event, so an Arbitrum deposit is never confused with a mainnet or a Base one.

Inbound and outbound use the same network in mirror image. On the receive side, the gate ascribes a confirmed deposit to your balance. On the payout side, halfin can send from your balance to a destination address on Arbitrum as a single or batch payout, and the gas for that transaction is paid by the platform moving the funds, not your customer. Payouts are approval-gated and idempotent: a payout batch carries an idempotency_key so a retried request never double-sends, and the resolved network is part of the record.

Everything that happens on-chain is surfaced through signed webhooks — verify the HMAC signature before you act on any event, then fulfill, reconcile, or pay out. The request below commits to no network at all: you bill a fiat amount, and the customer's asset choice on checkout resolves the rail. The idempotency_key is a snake_case field in the request body, not a header. Field schemas live in the docs rather than being guessed from this snippet.

curl -X POST https://api.thehalfin.com/api/v1/invoices \
  -H "X-API-Key: $HALFIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount_fiat": "120.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "Annual plan",
    "idempotency_key": "00000000-0000-4000-8000-000000000004"
  }'

# The invoice commits to no network. If the customer settles on Arbitrum,
# halfin's Arbitrum gate waits for the confirmation threshold (reorg-aware)
# before crediting, and the resolved asset and network come back on the
# invoice and each signed webhook event. Field schemas: docs.thehalfin.com.