The standardized ethereum: URI format for payment requests (ethereum:0xaddress?value=... or ethereum:pay-.../transfer) that lets QR codes open a wallet with address, amount, and token details pre-filled.
EIP-681 defines the ethereum: URI scheme — Ethereum's counterpart to BIP-21 — for expressing payment and transaction requests as links and QR codes. It covers two patterns: simple native-currency transfers and contract interactions such as ERC-20 token transfers. A basic request looks like:
ethereum:0xfb6916095ca1df60bb79ce92ce3ea74c37c5d359?value=2.014e18
while a token payment uses the pay- request form that names the token contract, the chain, and the function to call with its parameters. A wallet scanning the QR code parses the URI, resolves the chain and contract, and presents a confirmation screen with the recipient, amount, and token pre-filled.
The two URL forms
The simpler form — ethereum: followed by an address with optional query parameters — handles plain ETH transfers: value denominates the amount in wei (the smallest ether unit, 10^-18 ETH), so 2.014e18 wei is 2.014 ETH. Scientific notation is explicitly supported for these large integers. The pay- form — ethereum:pay-<contractAddress>@<chainId>/<functionName>?<parameters> — describes a contract call, typically transfer on an ERC-20 token contract, with parameters like address=<recipient> and uint256=<tokenAmount>. The @chainId segment pins the request to a specific network (1 for Ethereum mainnet), preventing a mainnet payment from being replayed on a testnet or sidechain.
Why chain ID matters in a QR code
Including the chain ID is a security feature, not bookkeeping. Ethereum addresses are valid across all EVM-compatible chains, so a bare address is ambiguous: the same 0x... string could receive mainnet ETH, a testnet token, or funds on a completely different rollup. The pay- URL's @chainId removes that ambiguity at the URI level, and wallets must reject the request if they are not on the indicated chain rather than silently substituting the current one.
QR-specific considerations
EIP-681 URIs are longer than BIP-21 ones — contract addresses, chain IDs, function names, and parameters add up — but they still encode comfortably as static QR codes at modest versions. Because the payload contains the full transaction semantics, static encoding is the right choice: no redirect server should sit between the payer and the transaction details. The address checksum (EIP-55 mixed-case encoding) lets wallets validate the address offline before signing. Test scans against at least two wallets, verify the chain ID resolves to the intended network, and double-check token decimal handling: uint256 token amounts are in the token's smallest unit, and misplacing decimals is the most common expensive mistake.
EIP-681 versus plain addresses
Encoding just a raw 0x address in a QR code works — wallets will open a send screen — but it forfeits everything EIP-681 adds: the amount, the token contract, the chain binding, and any reference label. For invoices, donations with suggested amounts, and token payments, the full URI form is strictly better and costs only a slightly denser symbol.
Diagram description: Annotated EIP-681 pay- URL with contract address, chain ID, function name, and parameters labeled, mapped onto a wallet confirmation screen showing token, amount, and network.