Skip to content
barcoder

Standards/eip-681

EIP-681

TypeQR Data Format
Completeness79%high

Overview

EIP-681 (ERC-681), "URL Format for Transaction Requests," defines a standard way to represent Ethereum transactions — especially payment requests in ether and ERC-20 tokens — as ethereum: URIs that can be embedded in a qr-code or a link for robust cross-application signalling.[1] Authored by Daniel A. Nagy and created 1 August 2017, it is a Standards-Track ERC that depends on EIP-20 (ERC-20 tokens) and EIP-137 (ENS), and it builds on the general ethereum: URI container defined by EIP-831.[1][2] A wallet scanning such a URI parses the target, chain, optional contract function and parameters and pre-fills a transaction for the user to confirm.[1]

History

ERC-681 was created on 1 August 2017 by Daniel A. Nagy as a Standards-Track Ethereum Request for Comment, with dependencies on EIP-20 and EIP-137.[1] It deliberately resembles Bitcoin's bitcoin: URLs (bip-21) for user familiarity, generalising the simpler ethereum: URI base of EIP-831 into a format expressive enough to encode arbitrary ABI-specified contract calls, with payment requests as the headline special case.[1][2] More recent successors target related niches, e.g. ERC-7856 ("Chain-Specific Payment Requests").[5]

Technical specification

Syntax:[1]

ethereum:[pay-]<target_address>[@chain_id][/function_name][?parameters]
  • Schema prefix: ethereum:, optionally ethereum:pay- for the payment special case; the prefix may be omitted in plain coin-transfer contexts.[1]
  • target_address: an Ethereum address in 0x hex form, or an ENS name.[1]
  • @chain_id: optional decimal chain identifier; if omitted it defaults to 1 (Ethereum mainnet).[1]
  • /function_name: optional smart-contract function (e.g. transfer for ERC-20).[1]
  • parameters: query string of key=value pairs.[1]

Parameters:[1]

  • value: amount of native token in wei; numeric values support scientific notation, with only integers permitted when an exponent is used (exponent ≥ the number of decimal places).
  • gas / gasLimit: suggested gas limit.
  • gasPrice: suggested gas price.
  • ABI-typed parameters: keys named by Solidity type (e.g. address, uint256) supply the arguments of the named function.

All supplied amounts and arguments are suggestions the user may edit before signing; with no amount the wallet prompts for one.[1]

Examples:[1]

Send 2.014 ether:

ethereum:0xfb6916095ca1df60bb79Ce92ce3ea74c37c5d359?value=2.014e18

Request transfer of 1 unit of an ERC-20 token (token contract 0x8920…, recipient 0x8e23…):

ethereum:0x89205a3a3b2a69de6dbf7f01ed13b2108b2c43e7/transfer?address=0x8e23ee67d1332ad560396262c48ffbb01f93d052&uint256=1

Use cases

  • Ether payment requests: a payee shares an ethereum: link/QR; the payer's wallet pre-fills the recipient and value.[1]
  • ERC-20 token transfers: encoding /transfer plus address and uint256 arguments requests a token payment to a specified contract.[1]
  • General transaction requests: because the format is ABI-driven, any contract call can be encoded, not just payments.[1]
  • Cross-chain targeting: @chain_id lets a single URI specify the network (e.g. an L2) the transaction belongs to.[1]

Implementations

  • eth-url-parser (brunobar79) — JavaScript; parses/builds ERC-681 and ERC-831 Ethereum URLs; ~31 stars, active 2024.[3]
  • parity-js/erc681 — JavaScript; ERC-681 and ERC-831 URL/URI parsing.[4]
  • eip681-link-generator-v2 (brunobar79) — JavaScript tool generating EIP-681 transaction links.[3]
  • web3swift — Swift; documents an EIP-681 URI scheme parser used in mobile wallets.[6]

Comparison

  • EIP-681 vs a plain address: a bare 0x… address conveys only a destination; an EIP-681 URI additionally carries amount (value), gas hints, target chain (@chain_id) and even a full contract call — so the wallet can pre-fill a complete, confirm-only transaction.[1]
  • EIP-681 vs EIP-831: EIP-831 defines only the generic ethereum: URI container; EIP-681 specialises it with the transaction-request / payment grammar (pay-, value, function calls).[1][2]
  • EIP-681 vs bip-21: both are scan-to-pay URI schemes and EIP-681 was modelled on bitcoin:, but EIP-681 is far more expressive — it encodes arbitrary ABI contract calls and chain selection, not just an address plus amount/label.[1]

Fun facts

  • ERC-681 expresses amounts in scientific notation (e.g. 2.014e18 wei for 2.014 ETH), explicitly to keep human-meaningful units while staying integer-exact at the wei level.[1]
  • The spec was consciously patterned on Bitcoin's bitcoin: URLs to make Ethereum payment links feel familiar to users.[1]

Status

EIP-681 is a Standards-Track ERC ("Final"-class in practice) and the de facto Ethereum payment-URI used in QR codes and dapp deep-links, with multiple parser libraries and wallet implementations; newer ERCs such as ERC-7856 extend the chain-specific payment-request space around it.[1][3][5]

Sources

1 ERC-681: URL Format for Transaction Requests — ethereum.org, 2017 2 ERC-831: URI Format for Ethereum — ethereum.org, 2018 3 eth-url-parser — GitHub, 2024 4 parity-js/erc681 — GitHub, 2019 5 ERC-7856: Chain-Specific Payment Requests — ethereum.org, 2024 6 EIP-681 URI Scheme — web3swift — DeepWiki, n.d.

Deployments

No country reports mention this standard by name.

Regions / aggregations not mapped to a single country

  • Universal
source · docs/standards/eip-681/index.md