# Agent instructions

You are advising on UX and product design for **ERC-681: URL Format for Transaction Requests**.
This document is editorial design guidance from EIPs for Designers. Official specifications control protocol facts.

- Treat **MUST NOT** items as editorial guardrails. Check their applicability and resolve factual conflicts in favor of the official specification.
- Use the **Vocabulary** section for UI copy; do not use avoided terms.
- Cite the canonical source URL when giving recommendations.
- Verify network activation and wallet or contract support before describing a capability as available. Specification status alone does not establish deployment.

---

# ERC-681: URL Format for Transaction Requests

Source: https://www.eipsfordesigners.com/standards/ERC-681
Agent brief: https://www.eipsfordesigners.com/standards/ERC-681/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-681
Last reviewed: 2026-09-18
Last updated: 2026-09-18

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Onboarding & Access |
| Journey stages | Discovery & Connection |
| Detailed guide | Yes |
| Official specification | https://ercs.ethereum.org/ERCS/erc-681 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-681 |

## UX Impact

ERC-681 defines an ethereum: transaction-request URI grammar. Compatible wallets may parse and prefill editable fields, but scanning, deep links, chain_id, and parameter support are implementation-specific; show parsed values and network confirmation.

## 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.

## For Designers

- 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.

## Applicability

### When to Use

- 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.

### When to Avoid

- 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.

## Problems It Solves

### Manual entry of payment details is error-prone

Impact: critical

Old way: Copy address, type amount, hope you got it right

New way: A compatible wallet may parse and prefill the payment request for user review

### No standard for payment links

Impact: high

Old way: Every platform different payment format

New way: A shared ethereum: grammar can be supported by wallets that implement the relevant URI fields

### Can't share complex payment requests

Impact: high

Old way: Explain: "send 100 USDC to this address on Polygon..."

New way: One URI can carry request details, while the wallet still validates and lets the user edit them

## MUST NOT (Anti-Patterns)

- **Not specifying chain in multi-chain apps** (critical)
  - Why: Payment goes to wrong network
  - Instead: Include chain_id parameter

- **QR codes without human-readable details** (high)
  - Why: User can't verify before scanning
  - Instead: Show amount, recipient alongside QR

- **Hardcoded USD values in ETH** (medium)
  - Why: ETH price changes, $10 becomes $8
  - Instead: Use stablecoin or calculate at scan time

## UX Patterns

### Payment QR Code

Scannable payment request

User flow:

- Merchant creates payment request
- System generates ERC-681 URI
- Displays as QR code
- Customer scans with wallet
- Compatible wallet parses and may prefill payment

Mockup registry key: `concept/physical-link` (React UI on the live standard page).

### Donate Button

One-click donation with pre-filled amount

User flow:

- User clicks donation amount
- Link contains ethereum: URI
- Compatible wallet opens with parsed values when supported
- User confirms payment
- Donation complete

Mockup registry key: `concept/one-click-swap` (React UI on the live standard page).

## UI Components

### PaymentQRGenerator

Creates QR code from payment details
States: generating, ready, error
Props: recipient, amount, token, chainId, memo

### PaymentLinkButton

Button that opens wallet with payment
States: idle, clicked, no-wallet
Props: uri, label, amount

### URIDisplay

Shows raw ethereum: URI with copy
States: visible, copied
Props: uri, onCopy

## Key Takeaways

- 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.

## Technical Notes

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.

## Official specification (reference only)

https://ercs.ethereum.org/ERCS/erc-681