ENSIP-31: Payment Preferences

Send 20 USDC to an ENS name. Which chain?

An ENS name can resolve a receiving address on many chains, so knowing the name is not enough. The sender still has to pick the chain, and the recipient’s answer often depends on the token. Today there is no way to learn that preference from ENS, so wallets guess, or the two sides sort it out over chat.

ENSIP-31 lets the recipient publish an ordered, token-specific list of preferred chains through their ENS name. A wallet can read the list before choosing a chain, then can resolve the receiving address on that chain exactly as it does today.

For example, alice.eth publishes that for USDC they prefer Base first and Ethereum second. A wallet asked to send them 20 USDC reads that record, picks Base, and resolves their Base address as normal.

The preference is stored as an ordinary ENSIP-24 data record with a key like payment-preference[<multichainTokenHash>], so no new resolver methods are needed.

I am especially interested in feedback on how the Multichain Token Registry fingerprints a token. Symbols such as USDC are not canonical. Contract addresses are canonical, but each address identifies a token on only one chain. Once a token exists across multiple chains, there is no single canonical identifier for the multichain token as a whole. ENSIP-31 currently addresses this by hashing an immutable snapshot of its chain-specific token representations. I am very open to other approaches for identifying a multichain token.

The proposal is a draft with the Pull Request open at ensdomains/ensips#87.

I would be appreciative of any feedback from the ENS community, and am, of course, happy to answer any questions.