By Eco research. Updated Apr 2026.
​

ERC-7856 is a URI scheme standard for chain-specific payment requests, letting a sender or application specify "send X amount of token Y to address Z on chain W" in a single unambiguous string. Proposed by Jack Chuma on January 1, 2025, it uses CAIP-10 account identifiers to encode both the chain and the recipient, replacing the optional and often-omitted chain_id field of ERC-681 with a mandatory component that eliminates ambiguity across multi-chain environments.
​

ERC-7856 is a Standards Track ERC submitted to the Ethereum ERCs repository on January 1, 2025 by Jack Chuma (@jackchuma). It proposes the cspr:// (chain-specific payment request) URI scheme, which encodes a complete multi-chain payment instruction in a single parseable string. The scheme is intentionally simple: four required components plus two optional callbacks. Its key innovation over earlier Ethereum payment URL standards is the mandatory use of CAIP-10 account identifiers for the recipient, making the target chain a first-class, required element rather than an inferred or optional hint.
​

ERC-7856 is distinct from smart account standards like ERC-4337 and ERC-7579; it operates at the application layer as a data format, not as a contract interface. A wallet reads a cspr:// URI, parses the recipient and chain ID, prompts the user to confirm the exact amount and token, and submits the transaction. No onchain contract is required to support the format itself; compliance is a wallet and application concern.
​

The base URI structure defined by the specification is:
​

cspr://<recipient>/<amount>/<token-address>?on-success=<url>&on-error=<url>
​

Each component has a defined type and behavior. The recipient is a full CAIP-10 account identifier, which encodes three pieces of information: the blockchain namespace (for EVM chains this is eip155), the chain ID under that namespace, and the wallet address. On Ethereum mainnet, a CAIP-10 identifier looks like eip155:1:0xab16a96D359eC26a11e2C2b3d8f8B8942d5Bfcdb; on Base mainnet it looks like eip155:8453:0x1111111111111111111111111111111111111111.
​

The amount field accepts either an integer or a decimal value representing the token quantity. The specification requires wallets to display the amount in proper token units when the token's decimals are accessible onchain, and to display a unit-uncertainty warning when they are not. Scientific notation matching the token's nominal exponent (18 for ETH, 6 for USDC on Ethereum) is the recommended display format.
​

The token-address field is a base64-encoded contract address for ERC-20 tokens. The special value native requests the chain's native currency. Base64 encoding was chosen to avoid ambiguity with URI-reserved characters that appear in hexadecimal addresses. Wallets MUST block native currency requests on chains that do not have native currency support, as defined by the specification.
​

Two optional query parameters let the payment request issuer define redirect targets: on-success is a URL the wallet navigates to after a confirmed transaction, and on-error is a fallback for rejection or failure. These are analogous to the callback URLs used in traditional payment gateway integrations. The ERC-7856 official specification page includes full examples for both ETH and USDC payment requests across different chains.
​

Two concrete examples from the specification illustrate the format:
​

1 ETH on Base mainnet:
​

cspr://eip155:8453:0x1111111111111111111111111111111111111111/1/native?on-success=https://example.com
​

100 USDC on Ethereum mainnet:
​

cspr://eip155:1:0xab16a96D359eC26a11e2C2b3d8f8B8942d5Bfcdb/100/0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48
​

The expansion of Ethereum into a multi-chain ecosystem created a category of user error that previous payment URI standards could not prevent: sending tokens on the wrong chain. When a merchant or dApp displays a payment request, the recipient may exist on a dozen chains simultaneously. Without a standard that encodes the chain as a mandatory, machine-readable field, wallets default to their current network setting, and users who hold USDC on Base while their wallet is connected to Ethereum mainnet either fail silently or pay on the wrong chain.
​

ERC-681, proposed in 2017, addressed Ethereum payment links but made the chain ID optional. The specification notes that "if no chain_id is present, the client's current network setting remains effective," which is a correct description of the ambiguity rather than a solution to it. ERC-831, which defined the broader Ethereum URI prefix standard, was similarly Ethereum-centric. Neither standard was designed for a world where USDC exists on Ethereum, Base, Arbitrum, Polygon, Solana, and Stellar simultaneously. As of Q1 2026, Circle's USDC is issued natively on more than 15 blockchains, and wallets like MetaMask and Phantom support four or more networks in the same interface.
​

ERC-7856 makes the chain ID structurally required through CAIP-10: a URI that omits the network namespace is malformed and MUST be rejected by compliant wallets. This shifts the error from a user mistake at transaction time to a parse failure at URI display time, catching the problem earlier in the flow.
​

Three payment URI standards preceded ERC-7856 on Ethereum. The comparison below covers chain scope, chain encoding method, non-EVM support, and whether a missing chain causes an error or a fallback.
​

ERC-7856's closest peer is CAIP-358, the Chain Agnostic Improvement Proposal for universal payment requests. CAIP-358 uses a similar multi-chain approach with CAIP-10 recipient encoding, though with a different URI prefix. ERC-7856 is positioned as the Ethereum-aligned version of this concept, submitted through the ERC process to sit alongside ERC-681 and ERC-831 in the formal Ethereum standards corpus. The specification's backward-compatibility note acknowledges that the cspr:// prefix is intentionally incompatible with the ethereum: prefix to prevent mis-parsing by older wallets that would attempt to process a chain-agnostic URI as an Ethereum-only request.
​

ERC-681 remains widely supported in existing QR code and deep-link tooling. ERC-7856 does not replace it for single-chain Ethereum use cases where the issuer knows all customers are on mainnet. The new standard targets specifically the multi-chain context where token issuers, merchants, and DeFi protocols cannot control which network a user's wallet is currently connected to.
​

ERC-7856 targets three categories of applications where multi-chain payment request precision matters: e-commerce checkout flows, DeFi liquidity requests, and peer-to-peer transfers between users on different chains.
​

A merchant accepting USDC on Base can generate a cspr:// QR code that encodes Base's chain ID in the recipient field. A customer whose wallet is connected to Ethereum mainnet sees a wallet prompt for the correct network, not a silent transaction to the wrong chain. The on-success callback URL lets the merchant redirect to an order confirmation page after the transaction is confirmed onchain, completing a payment UX that matches the redirect behavior of card payment gateways. This is the use case the specification describes as its primary motivation in the January 2025 Fellowship of Ethereum Magicians discussion thread.
​

A DeFi protocol or treasury can encode a precise request for a counterparty to provide USDT on a specific chain, including the exact contract address, without relying on the counterparty to configure their wallet correctly. Smart contract wallets built on ERC-4337 can parse cspr:// URIs programmatically, enabling fully automated liquidity fulfillment flows where a UserOperation is constructed directly from the URI without human wallet interaction.
​

Two users on different chains who want to settle a stablecoin payment face the same ambiguity problem as a merchant. User A on Arbitrum can generate a cspr:// link specifying Arbitrum's chain ID (eip155:42161) so User B's wallet, regardless of its current network, presents the exact chain and amount before confirmation. The CAIP-10 format also supports non-EVM chains: a Solana address encoded as solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp:recipient_address can appear as the recipient in a cspr:// URI, though wallet support for non-EVM CAIP-10 parsing is still nascent as of Q1 2026.
​

ERC-7856 handles payment requests, which trigger irreversible onchain transactions. The specification calls out four categories of security concern that wallet implementors must address: source trust, callback URL validation, amount verification, and token address verification.
​

Source trust is the fundamental constraint. A cspr:// URI is only as trustworthy as its source. An attacker who intercepts or replaces a legitimate payment request URI can substitute their own CAIP-10 address and collect the payment. The specification states clearly that users must obtain URIs from verified, secure sources, and wallet UI design should surface the origin clearly at confirmation time. This is the same trust model as a wire transfer instruction: the data format is neutral, but the provenance must be verified out-of-band.
​

Callback URL validation is the second risk vector. The on-success and on-error fields redirect the wallet browser after a transaction. A malicious URI could specify a phishing page as the success callback, impersonating the legitimate merchant confirmation page. Wallets implementing ERC-7856 MUST rigorously validate callback URLs against browser security standards, and the specification recommends treating them with the same skepticism as OAuth redirect URIs.
​

Amount and token verification require the wallet to display the exact token amount in human-readable units before confirmation, and to fetch the token's decimals from the contract to compute the correct display value. If decimals are unavailable, the wallet SHOULD display a unit-uncertainty warning rather than proceeding silently. The ERC-7856 specification recommends scientific notation matching the nominal token exponent to reduce the risk of off-by-magnitude errors (paying 100 USDC vs. 100 USDT where the token contract differs).
​

Token address verification is a phishing vector because base64-encoded contract addresses are opaque to human inspection. Wallets should resolve the token name and symbol from the contract before confirmation, and flag requests where the on-chain token name does not match expectations based on the encoded address.
​

As of April 2026, ERC-7856 is a Draft-status Standards Track ERC submitted via pull request PR #823 to the Ethereum ERCs repository. Draft status means the interface is defined and under community review but has not completed the formal review process required to reach Final status. The Ethereum Magicians discussion thread from January 2025 covers callback mechanics, privacy considerations, and CAIP alignment, with active responses from the author addressing concerns raised by the community.
​

Wallet adoption of cspr:// URIs is not yet widespread, but the CAIP-10 foundation is already implemented in multi-chain wallets including MetaMask and WalletConnect's sign-in-with-Ethereum flows. The incremental work to add cspr:// URI parsing on top of existing CAIP-10 support is small for wallets that already handle CAIP-10 account identifiers. The standard's backwards incompatibility with ethereum: URIs means there is no risk of breaking existing ERC-681 integrations by adding support.
​

ERC-681 uses the ethereum: prefix and makes the chain ID optional, defaulting to the wallet's current network. ERC-7856 uses cspr:// and encodes the chain as a mandatory CAIP-10 component of the recipient field. A missing chain in an ERC-7856 URI is a parse error, not a fallback. ERC-7856 also supports non-EVM chains; ERC-681 is Ethereum-only.
​

No. ERC-7856 is a URI scheme standard, not a contract interface standard. There is no onchain component to deploy. Compliance lives entirely in wallets and applications that parse, generate, and display cspr:// URIs. Any existing smart account or EOA can be the recipient of an ERC-7856 payment request without changes.
​

Yes in principle. The CAIP-10 format supports any blockchain that has a CAIP-2 namespace. A Solana address can be expressed using the solana: namespace. Practical wallet support for non-EVM CAIP-10 identifiers in cspr:// URIs is limited as of Q1 2026, but the specification does not restrict the scheme to EVM chains.
​

The wallet will not recognize the cspr:// URI scheme and will display an error or ignore the link. This is the correct behavior: an unsupported URI should not fall back to a partial parse that strips the chain ID and sends to the wrong network. The cspr:// prefix prevents accidental mis-processing by wallets that only understand ethereum: URIs.
​

The specification requires wallets to read the token's decimals from the contract onchain and display the amount in nominal units. If decimals are unavailable, the wallet SHOULD warn the user rather than proceed with an ambiguous amount. Amount display in scientific notation aligned to the token's nominal exponent (for example 18 for ETH, 6 for USDC on Ethereum mainnet) is the recommended pattern to make magnitude errors visible.
​

Sources and methodology. EIP specification sourced from eips.ethereum.org/EIPS/eip-7856 (created January 1, 2025, author Jack Chuma). CAIP-10 specification from chainagnostic.org/CAIPs/caip-10. ERC-681 specification from eips.ethereum.org/EIPS/eip-681. USDC chain count from Circle USDC ecosystem page as of Q1 2026. Community discussion context from the Ethereum Magicians forum thread, January 2025.
​

Eco Routes handles stablecoin settlement across more than 15 EVM-compatible chains. As payment request standards converge on CAIP-10 for chain-specific addressing, infrastructure that can route and settle stablecoin transfers across those chains becomes the execution layer that ERC-7856-style payment requests ultimately depend on to fulfill cross-chain instructions.
​