Glossary

EVM

The EVM, or Ethereum Virtual Machine, is the runtime that executes smart contracts on Ethereum. It defines how contract code runs, how account balances are tracked, and what an address looks like. An "EVM-compatible" chain is a separate blockchain that runs the same virtual machine, so the same contracts, tooling, and address format work across all of them — Ethereum itself plus Base, Arbitrum, Polygon, and BNB Smart Chain.

01

What the EVM actually is

Every Ethereum node runs a small, deterministic computer called the Ethereum Virtual Machine. When a transaction calls a smart contract, the EVM executes that contract's compiled code one instruction at a time, and every node reaches exactly the same result — that agreement is what makes the network trustworthy. The EVM also defines the shape of the system around it: how accounts and balances are stored, how a transaction is structured, and the format of an address (the familiar 42-character `0x…` hex string).

Running contracts costs gas, a unit that meters computation and is paid in the chain's native coin. The EVM is the part that counts the gas: each instruction has a fixed cost, and a transaction that runs out of gas reverts. None of this is specific to one company or one chain — the EVM is a published specification, which is why other blockchains can implement it independently.

02

EVM-compatible chains

A chain is "EVM-compatible" when it runs the same virtual machine as Ethereum. It is still a distinct blockchain — its own validators, its own blocks, its own native coin, its own confirmation behavior — but because the execution environment is identical, a smart contract written for Ethereum can be deployed unchanged, the same wallets work, and addresses use the same `0x…` format. That shared format is why an Ethereum address and a Base or Polygon address look identical: they are produced the same way.

halfin's EVM gates cover Ethereum together with three Ethereum layer-2 / sidechain networks — Base, Arbitrum, and Polygon — and BNB Smart Chain (BSC). They share the address format and the contract model, but they are not interchangeable: a coin or token exists on one specific chain, and a payment must be sent over the chain the invoice expects. Native coins and fees differ too — Ethereum's fee is paid in ETH, BSC's in BNB, Polygon's in POL — and busier chains tend to confirm more slowly and cost more in gas. Because addresses look the same across all of these, sending funds on the wrong EVM chain is a real and unrecoverable mistake, which is one reason a checkout names the exact network a customer must use.

03

Why it matters for accepting crypto

EVM compatibility is what lets a payment processor support many chains without a bespoke integration per chain. halfin watches receiving addresses, decodes native and token transfers, and credits them the same way across every EVM network it gates, then applies each chain's own reorg-aware confirmation threshold before an invoice is marked paid. The mechanics a merchant cares about — detection, crediting, finality — are consistent precisely because the underlying machine is.

It also shapes how you think about assets. The Ethereum versions of USDT and USDC are ERC-20 tokens — contracts running on the EVM — and the EVM is what makes accepting a token as straightforward as accepting the native coin: both are transfers the gate can read. Since halfin invoices are fiat-anchored, you bill a fiat amount and let the system map it to the payable figure on whichever EVM chain and asset the customer chooses; the customer pays a concrete amount, and the network they pick changes only the fee and confirmation speed, not how the payment is credited.