{"id":"ERC-681","name":"URL Format for Transaction Requests","status":"Final","chain":"both","category":{"id":"onboarding","name":"Onboarding & Access","description":"Getting users into web3 without friction"},"journeyStages":[{"id":"discovery","name":"Discovery & Connection","description":"Finding and connecting wallet to dApp"}],"uxImpact":"ERC-681 defines a URI grammar for transaction requests that a compatible wallet may parse into editable payment or contract-call fields. It can carry a recipient, optional chain_id, amount, and function parameters, but the format does not require wallets to scan, deep-link, or support every parameter.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-681","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-681","specConstraints":[{"id":"payment-request-review","constraint":"Payment URLs require an integrity check and an explicit review of the destination and amount.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"Since irreversible transactions can be initiated with parameters from such URLs, the integrity and authenticity of these URLs are of great importance.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-681#security-considerations","designImplication":"Treat a scan as a proposed transaction, not consent to send. Show the resolved chain, recipient, amount and units. If token metadata is untrusted or unavailable, disclose the unit uncertainty rather than inventing a decimal conversion."},{"id":"hex-address-precedence","constraint":"A hexadecimal address takes precedence over a matching ENS name.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"To prevent malicious redirection of payments using ENS, hexadecimal interpretation of Ethereum addresses must have precedence over ENS lookups.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-681#security-considerations","designImplication":"Parse a full hexadecimal address directly. Do not resolve it as an ENS name; show the final recipient for review and warn about deceptive lookalikes."},{"id":"chain-id-optional","constraint":"The chain_id parameter is OPTIONAL; without it, the client's current network setting remains effective.","appliesTo":"wallet","normativity":"normative","specSection":"Specification > Semantics","specUrl":"https://ercs.ethereum.org/ERCS/erc-681#semantics","designImplication":"Show an explicit target-network state: a provided chain_id selects the request's network, while an absent value requires clear current-network confirmation.","specQuote":"`chain_id` is optional and contains the decimal chain ID, such that transactions on various test- and private networks can be requested. If no `chain_id` is present, the client's current network setting remains effective."},{"id":"editable-payment-amount","constraint":"The indicated amount is a suggestion, and users SHOULD be prompted to enter an amount when it is absent.","appliesTo":"wallet","normativity":"normative","specSection":"Specification > Semantics","specUrl":"https://ercs.ethereum.org/ERCS/erc-681#semantics","designImplication":"Prefill the suggested amount but keep it editable, and make the missing-amount state an explicit input step before signing.","specQuote":"Note that the indicated amount is only a suggestion (as are all the supplied arguments) which the user is free to change. With no indicated amount, the user should be prompted to enter the amount to be paid."},{"id":"amount-notation-guidance","constraint":"Scientific notation is strongly encouraged for monetary values, and the exponent should represent the token's nominal unit.","appliesTo":"wallet","normativity":"rationale","specSection":"Rationale","specUrl":"https://ercs.ethereum.org/ERCS/erc-681#rationale","designImplication":"Format large or small amounts in an inspectable notation and show the nominal-unit basis used for conversion.","specQuote":"The proposed format is chosen to resemble `bitcoin:` URLs as closely as possible, as both users and application programmers are already familiar with that format. In particular, this motivated the omission of the unit, which is often used in Ethereum ecosystem. Handling different orders of magnitude is facilitated by the exponent so that amount values can be expressed in their nominal units, just like in the case of `bitcoin:`. The use of scientific notation is strongly encouraged when expressing monetary value in ether or [ERC-20](./eip-20.md) tokens. For better human readability, the exponent should be the decimal value of the nominal unit: 18 for ether or the value returned by `decimals()` of the token contract for [ERC-20](./eip-20.md) tokens. Additional parameters may be added, if popular use cases requiring them emerge in practice."},{"id":"ens-lookalike-warning","constraint":"Client software MAY alert or reject ENS addresses that are visually similar to hexadecimal addresses.","appliesTo":"wallet","normativity":"security-considerations","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-681#security-considerations","designImplication":"Use a visible lookalike warning or rejection path as an optional phishing defense, while keeping the resolved recipient explicit.","specQuote":"To prevent malicious redirection of payments using ENS, hexadecimal interpretation of Ethereum addresses must have precedence over ENS lookups. Client software may alert the user if an ENS address is visually similar to a hexadecimal address or even outright reject such addresses as likely phishing attacks."},{"id":"payment-amount-display","constraint":"Payment interfaces SHOULD make the amount and order of magnitude inspectable, using trusted token units when available and showing uncertainty otherwise.","appliesTo":"wallet","normativity":"security-considerations","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-681#security-considerations","designImplication":"Display amount, unit, and order of magnitude together; distinguish contract-derived units from URL-provided units and label uncertainty before signing.","specQuote":"In order to make sure that the amount transacted is the same as the amount intended, the amount communicated to the human user should be easily verifiable by inspection, including the order of magnitude. In case of [ERC-20](./eip-20.md) token payments, if the payer client has access to the blockchain or some other trusted source of information about the token contract, the interface should display the amount in the units specified in the token contract. Otherwise, it should be displayed as expressed in the URL, possibly alerting the user to the uncertainty of the nominal unit. To facilitate human inspection of the amount, the use of scientific notation with an exponent corresponding to the nominal unit of the transacted token (e.g. 18 in case of ether) is advisable."}],"summary":"ERC-681 defines a URI grammar for transaction requests that a compatible wallet may parse into editable payment or contract-call fields. It can carry a recipient, optional chain_id, amount, and function parameters, but the format does not require wallets to scan, deep-link, or support every parameter.","applicability":{"whenToUse":["Payment or contract-call links can reduce manual entry when the selected wallet supports the URI fields.","The UI can show and let users review the parsed recipient, amount, token, and chain.","The flow has an explicit fallback for wallets that do not scan, deep-link, or parse every field."],"whenToAvoid":["The wallet cannot parse ERC-681 or the required deep-link transport.","The recipient, amount, or target chain requires a server-authorized request instead of editable URI parameters.","The app cannot provide an explicit review and fallback when a URI is only partially parsed."]},"designerTakeaways":["Show the URI's recipient, amount, token, and target chain beside the QR or link.","Let users review and edit parsed values before signing.","Detect partial parsing and provide an explicit network or wallet fallback."],"problemsSolved":[{"problem":"Manual entry of payment details is error-prone","oldWay":"Copy address, type amount, hope you got it right","newWay":"A compatible wallet may parse and prefill the payment request for user review","impact":"critical"},{"problem":"No standard for payment links","oldWay":"Every platform different payment format","newWay":"A shared ethereum: grammar can be supported by wallets that implement the relevant URI fields","impact":"high"},{"problem":"Can't share complex payment requests","oldWay":"Explain: \"send 100 USDC to this address on Polygon...\"","newWay":"One URI can carry request details, while the wallet still validates and lets the user edit them","impact":"high"}],"uxPatterns":[{"name":"Payment QR Code","description":"Scannable payment request","userFlow":["Merchant creates payment request","System generates ERC-681 URI","Displays as QR code","Customer scans with wallet","Compatible wallet parses and may prefill payment"]},{"name":"Donate Button","description":"One-click donation with pre-filled amount","userFlow":["User clicks donation amount","Link contains ethereum: URI","Compatible wallet opens with parsed values when supported","User confirms payment","Donation complete"]}],"uiComponents":[{"name":"PaymentQRGenerator","description":"Creates QR code from payment details","states":["generating","ready","error"],"props":["recipient","amount","token","chainId","memo"]},{"name":"PaymentLinkButton","description":"Button that opens wallet with payment","states":["idle","clicked","no-wallet"],"props":["uri","label","amount"]},{"name":"URIDisplay","description":"Shows raw ethereum: URI with copy","states":["visible","copied"],"props":["uri","onCopy"]}],"antiPatterns":[{"pattern":"QR codes without human-readable details","why":"User can't verify before scanning","instead":"Show amount, recipient alongside QR","severity":"high"},{"pattern":"Not specifying chain in multi-chain apps","why":"Payment goes to wrong network","instead":"Include chain_id parameter","severity":"critical"},{"pattern":"Hardcoded USD values in ETH","why":"ETH price changes, $10 becomes $8","instead":"Use stablecoin or calculate at scan time","severity":"medium"}],"keyTakeaways":["ERC-681 defines a transaction-request URI grammar, not a guaranteed wallet handoff.","Show and let users review the recipient, amount, token, and target network.","Treat chain_id and function parameters as optional, editable request data.","Feature-detect scanning, deep links, and supported fields.","Provide a manual or direct-wallet fallback when parsing is incomplete."],"technicalNotes":"ERC-681 defines ethereum:address[@chain_id][/function]?[parameters]. value, gas, gasPrice, and function arguments are URI parameters that a compatible wallet may parse; chain_id is optional. The URI does not mandate scanning, deep links, field support, or immutable values. Show the parsed request and let the wallet/user review the final transaction.","lastUpdated":"2026-09-18","sources":[{"label":"ERC-681 official specification","url":"https://ercs.ethereum.org/ERCS/erc-681","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-681","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-681","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-681","markdown":"https://www.eipsfordesigners.com/standards/ERC-681/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-681/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-681","official":"https://ercs.ethereum.org/ERCS/erc-681","discussion":"https://ethereum-magicians.org/search?q=ERC-681"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}