The Base network: a low-cost Ethereum L2 for USDC

Base is an Ethereum layer-2: a separate chain that runs the same Ethereum Virtual Machine and uses the same account and address model as mainnet, but settles transactions for a fraction of mainnet gas. For a payment processor the three facts that matter are that Base is EVM-compatible (so the wallet flow and address format a payer already knows carry straight over), that it is cheap enough to make small stablecoin payments practical, and that it is most commonly reached for as a USDC rail. This page is about the network — why an L2 is cheaper, what assets settle here, and how halfin accepts and pays out on Base — not about USDC as an asset.

What an Ethereum L2 actually is

A layer-2 is a separate blockchain that does its own transaction execution but anchors its results back to Ethereum mainnet. Base runs the same Ethereum Virtual Machine as mainnet, so the smart contracts, the account model, and the address format are the EVM ones a payer's wallet already speaks. The difference is where the work happens: transactions execute on Base's own blocks, and the network periodically posts its data to Ethereum, which is what lets Base inherit Ethereum's security rather than bootstrapping its own validator economics from scratch.

That two-layer arrangement is the whole reason Base is cheap. On Ethereum mainnet, every transaction competes for the same blockspace, and gas is priced by that competition. On Base, execution happens off mainnet and only the compressed result is settled to Ethereum, so the cost of moving value is a small fraction of doing the same transfer on mainnet. Gas on Base is still denominated in ETH — the L2's gas asset is ETH, exactly as on mainnet — but the amount of it a transfer consumes is far lower.

Because Base is EVM-compatible, an address is an EVM address and a transfer behaves like its mainnet equivalent: native ETH moves as a balance change, and a token like USDC moves as a smart-contract call. What changes versus mainnet is the fee and the chain a payment lands on, not the shape of the transaction. To a customer the experience is a familiar wallet flow at a lower cost; to your ledger it is a deposit on Base, a distinct network from Ethereum mainnet.

• Base is a separate EVM chain that posts its data back to Ethereum mainnet — it inherits Ethereum's security, not its fees.
• Gas on Base is paid in ETH, same as mainnet, but a transfer consumes far less of it.
• EVM addresses and transaction mechanics carry over from Ethereum unchanged — only the fee and the settling chain differ.

USDC is the common rail on Base

Base is most often reached for as a USDC rail. USDC on Base is its own token contract — a deployment of the dollar-denominated stablecoin on the Base chain, distinct from USDC on Ethereum mainnet and from USDC on Solana. It is not a bridged copy that redeems somewhere else; it is the canonical USDC on this network, which is exactly why Base has become a low-friction place for a payer to send dollars. halfin settles USDC on Base, alongside USDC on Ethereum and Solana, so a customer can pay from whichever network their USDC already sits on instead of bridging it first.

Native ETH also settles on Base — it is the gas asset, so a payer who holds ETH on the L2 can pay in it directly. But the practical pull of Base for a merchant is the combination of a widely held stablecoin and low send cost: a small USDC payment that would carry a meaningful gas fee on mainnet stays cheap to send on Base. That keeps the customer's cost down on exactly the amounts where mainnet gas would otherwise bite, which is why rate-shopping stablecoin payers gravitate to it.

What a customer should not assume is that USDC is one rail. USDC on Base and USDC on Ethereum are separate deployments with separate addresses; a balance on one cannot pay an address on the other. halfin keeps the asset and the network explicit, hands the customer the correct Base deposit address when they pick that rail, and records the settled network on the invoice — so a USDC payment on Base is never confused with one on mainnet during reconciliation.

• USDC on Base is its own canonical token contract — not the same deployment as USDC on Ethereum or Solana, and not interchangeable with them.
• Native ETH settles on Base too, since ETH is the L2's gas asset.
• Base's appeal is a widely held stablecoin at low send cost — strongest on the small amounts where mainnet gas would dominate.

Confirmations and reorg-aware crediting

Like every network halfin settles on, Base does not have a payment credited the instant a transaction first appears in a block. A freshly included transaction is observed but not yet committed — the L2's recent blocks can still be reorganized before they settle. Crediting on Base therefore waits for the network's confirmation threshold: enough blocks on top that the deposit has effectively committed before an invoice flips to paid. This is the same discipline halfin applies to Ethereum mainnet, calibrated to Base's own settlement behavior rather than mainnet's.

halfin's crediting on Base is reorg-aware throughout. If a reorganization unwinds a transaction that was already observed, halfin reflects that instead of pretending the payment still stands — the settled amount you see is one that actually held on-chain. For your integration the lifecycle is the trustworthy one to build against: a deposit is observed, confirmations accumulate toward the threshold, and only then does the invoice settle and a signed webhook fire. You act on the paid event, not on the first sighting of a transaction.

Because Base is an L2 whose final security rests on data posted to Ethereum, the confirmation threshold is the practical line a merchant cares about: it is the point at which halfin treats a Base deposit as committed and credits your balance. You do not configure it per invoice — halfin applies Base's threshold to every deposit on the chain — and the network the payment settled on comes back to you on the record, so a Base deposit is never ambiguous against a mainnet one.

Base in the EVM family

Base is one of three EVM layer-2 networks halfin settles on, alongside Arbitrum and Polygon, all of which share Ethereum's account and address model while charging a fraction of mainnet gas. They are distinct chains: each has its own blocks, its own fee market, and its own settlement, so halfin watches each on its own settlement gate with its own confirmation behavior. A USDC payment on Base is a different deposit on a different chain from a USDC payment on Ethereum mainnet — not a cheaper version of the same thing.

That separation is deliberate and load-bearing for reconciliation. The network a payment settled on comes back to you alongside the asset, on the invoice record and on every webhook event, so your ledger always knows whether a given USDC transfer arrived over Base, over mainnet, or over Solana. The table below is the real supported surface for Base — what an invoice can actually draw from on this chain, not an aspirational list.

How halfin accepts and pays out on Base

You do not select Base when you create an invoice. You bill a fiat amount; the customer chooses an asset; and halfin resolves the asset to its network. If the customer settles in USDC on Base or in native ETH on Base, halfin presents the correct Base deposit address, its Base gate watches the chain, 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 a Base deposit is never ambiguous against an Ethereum-mainnet 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 USDC or native ETH from your balance to a destination address on Base as a single or batch payout — and the gas for that transaction is paid by the platform moving the funds, not your customer, which on Base is a low cost to begin with. 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. 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": "40.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "Top-up",
    "idempotency_key": "00000000-0000-4000-8000-000000000007"
  }'

# The invoice commits to no network. If the customer settles on Base
# (USDC or native ETH), halfin's Base 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.