ENSIP-31: Payment Preferences

Abstract

This ENSIP lets an ENS name publish its accepted payment assets and preferred chains for each asset using an ENSIP-24 data record. Entries use ERC-7930 Interoperable Addresses for tokens and 7930 Chain Identifiers for native assets. Senders can choose an accepted asset and use the entry order to find the recipient's preferred chain for that asset.

Motivation

Payment preferences tell senders which assets the recipient accepts and which chains they prefer for each asset. For example, a recipient might prefer USDC on Base and ETH on Ethereum.

A sender can use the list to choose both an asset and a chain. If they already know which asset they want to pay in, it answers the question: "I want to send name.eth 50 USDC, but which chain should I use?"

ERC-7828 identifies a destination on a specific chain, but does not publish accepted assets or preferences between chains. Asking the recipient for an ERC-7828 address for the asset being paid adds a round trip of communication.

This ENSIP lets recipients publish which assets they accept and their preferred chains. Senders can use these preferences to choose an asset and chain, saving a round trip of communication when the recipient is reachable and providing the information when direct communication is not possible.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Payment Preference Record

A name publishes an ENSIP-24 data record on its own node under the key:

payment-preference

The value MUST contain zero or more entries concatenated directly, without delimiters:

E1 || E2 || ... || En

Each entry indicates an accepted asset on a particular chain. For entries identifying the same asset, earlier entries indicate a higher chain preference. The order does not express a preference between different assets. An absent or empty record expresses no preference. A record SHOULD NOT contain the same entry more than once.

The list is not exclusive. It expresses preferences for the assets included. Clients MUST NOT interpret an asset's absence as meaning that the recipient cannot accept it.

Entries

Each entry MUST be an ERC-7930 Interoperable Address (Version 1), identifying a fungible asset on a specific chain using one of these forms:

• Interoperable Address: Identifies a token contract and its chain.

• Chain Identifier (an Interoperable Address with a zero-length target address): Identifies a chain and represents its native asset, such as ETH on Ethereum or SOL on Solana.

Wrapped native assets MUST use an Interoperable Address identifying their token contract and chain.

Entries identify assets. The recipient's receiving address is resolved separately for the selected chain.

Parsing

Clients MUST parse entries according to ERC-7930 until the end of the record.

Clients MUST ignore the entire record if any entry is malformed.

Clients MUST NOT use any entries unless the entire record has been successfully parsed and validated.

Selection

The sender chooses which asset to pay in. If that asset is listed, the sender SHOULD use the earliest entry identifying it.

The sender decides which entries identify the same asset. Determining whether tokens on different chains represent the same asset is outside the scope of this ENSIP.

Example

This example lists USDC on Ethereum, USDC on Base, and native ETH on Ethereum.

A sender paying USDC should prefer Ethereum over Base; a sender paying ETH should use Ethereum.

Concatenated, the record is 62 bytes:

0x00010000010114a0b86991c6218b36c1d19d4a2e9eb0ce3606eb480001000002210514833589fcd6edb6e08f4c7c32d4f71b54bda0291300010000010100

Rationale

ERC-7930 identifies assets on specific chains without introducing a new address format. Listing chains in order of preference for each asset avoids storing a separate priority number for every entry. Direct concatenation keeps the record compact.

Defining a multichain asset would require rules for whether native, wrapped, and bridged tokens are equivalent. This ENSIP leaves that decision to clients and records only the recipient's accepted assets and preferred chains.

Backwards Compatibility

This ENSIP adds an ENSIP-24 data record without changing existing ENS or ERC-7828 address resolution. Clients that do not read the record are unaffected.

Security Considerations

Listing an asset as accepted does not prove that it is authentic or safe. Clients should verify the asset and recipient before sending funds. A listed contract may be malicious or incorrect, even if the record is correctly formatted.

Copyright

Copyright and related rights waived via CC0.