ERC‑681 spec highlights
ERC‑681 defines a standard way to express payment requests and ABI-specified contract interactions as ethereum: URIs. This page is a “working engineer’s” summary; the canonical reference is the EIP text.
At a high level, an ERC‑681 request looks like:
request = schema_prefix target_address [ "@" chain_id ] [ "/" function_name ] [ "?" parameters ]
schema_prefix = "ethereum" ":" [ "pay-" ]
target_address = ethereum_address
chain_id = 1*DIGIT
function_name = STRING
ethereum_address = ( "0x" 40*HEXDIG ) / ENS_NAME
parameters = parameter *( "&" parameter )
parameter = key "=" value
key = "value" / "gas" / "gasLimit" / "gasPrice" / TYPE
value = number / ethereum_address / STRINGKey points:
- target_address is mandatory — beneficiary for native payments, or contract address for calls.
- @chainId is optional and uses decimal chain IDs.
- If /function is omitted, the URI requests a native transfer.
- Values are in atomic units (wei for ETH). Scientific notation is encouraged.
ethereum:0xfb6916095ca1df60bb79Ce92ce3ea74c37c5d359?value=2.014e18Here, value is in wei (atomic units).
ethereum:0x89205a3a3b2a69de6dbf7f01ed13b2108b2c43e7/transfer?address=0x8e23ee67d1332ad560396262c48ffbb01f93d052&uint256=1The target address is the token contract; the function is transfer; parameters are typed keys (e.g. address, uint256).
ERC‑681 allows ENS names as addresses. Resolution is the payer’s job; hexadecimal addresses must take precedence over ENS lookups.
ERC‑681 encodes the function name and typed parameter keys, but wallets still need ABI context to build calldata safely for arbitrary calls.
In practice, many wallets restrict support to native transfers and a small set of well-known token operations. See the adoption matrix and the discussion on Ethereum Magicians.