CAIP-XXX: Chain-Agnostic Wallet Address Request URI Scheme

[timjrobinson]

This CAIP adds a chain agnostic wallet:address URI for wallets, which they respond to with their CAIP-10 address.

I created this for a real life payment terminal to be able to request via NFC the customers wallet address so that it can determine the best chain/token to send a payment request for. Without this URI the merchant is unable to know what assets a customer has to pay with and so cannot send a good payment request.

Open Question: Should this be wallet:addresses and wallets can return more than one address? How should that be formatted, comma separated?

[bumblefudge]

yowza!

[timjrobinson]

What do you mean by this? I'd be happy to use any other chain-agnostic URI but I haven't seen one anywhere. Is there a better way?

[bumblefudge]

there's a couple, but it's the same amount of work distributed across difference governance surfaces, debatably 😅

i think konrad probably already sent you this, but preserving it here for future martian anthropologists:
https://kkonrad.substack.com/p/stop-inventing-custom-uris-use-urls

let's talk tomorrow on zoom and figure out what version of this is most productive for ya!

[bumblefudge]

Hey!

So, to answer your question, I think an array might be nice, because it's pretty bad UX to send back your preferred address only to have... nothing happen because the dapp/POS-machine/etc doesn't speak that chain/namespace. I would probably prefer "ranked by preference" (from most to least preferred) since JSON (and by extension JSON-RPC) doesn't canonicalize/sort arrays by default when serializing, but that may be a minority view, some people hate the overdetermining/re-semanticizing of JSON array order, which can be unstable (or force-sorted in some programming languages or frameworks).

More broadly, though, I'm a little confused here on the context. It feels like you're defining a genuinely useful API/handle-able URI protocol, but

1. I have to wonder whether IANA/IETF would even let you declare wallet://, with all the European Wallet stuff going down at the moment!
2. maybe given the way ERC-4804 leaves so much namespace open, it makes more sense to just define additional options after the //? that way you can just reuse/extend web3:// as a protocol
3. this lightweight datamodel seems to assume some amount of protocol without defining any-- maybe it makes more sense to add at least one protocol (or profile of a pre-existing one) in a second CAIP (but in the same PR) so that it's clearer what this "return" means? it feels more like a call/response protocol than a URI scheme as-is , so it might be helpful just to spell it out. what's this about an NFC POS use-case? EDIT: a demo has been brought to my attention

[timjrobinson]

I like the idea of using web3:// instead.

This is more of a call/response protocol. Also thinking it could be wallet_getAccounts and it returns an array of CAIP-10 formatted accounts for more flexibility and to be more similar to what walletconnect does.

Do you have any examples of other CAIP's I could follow to define a protocol separately? I'm not sure how to do that.

[lukaisailovic]

Interesting approach! Have you seen #358? It handles the problem in a different way

[timjrobinson]

@lukaisailovic this is great! This seems like it would be a great next step after requesting the wallet address, as then the requester could look up the senders tokens and send a CAIP-358 request for any tokens that the sender has that the requester supports.

Without knowing what tokens the sender has available it seems like a shot in the dark with the exponentially growing number of tokens/chains out there. Which is why I think it helps a lot to gather that information first.

[lukaisailovic]

@timjrobinson The goal of 358 was intentionally not to request the address beforehand. It allows the recipient to specify which tokens are accepted and then wallet to complete the request in any one of them.

It eliminates one more round trip, which is significant for the speed of checkout.

Also we can make some assumptions, like most likely token will be stablecoin, chains etc and growing number of wallets support some aspect of Chain/Token Abstraction (swap before execute) which makes it extremely likely for wallet to complete at least one of the payment requests.

[bumblefudge]

Suggested change

	This allows a user to use NFC or other simple intent methods to provide their wallet address without manual copying, scanning, or complex integrations. The [CAIP-10][] standard is chosen as it clearly indicates the blockchain namespace and reference.
	This allows a user to use NFC or other transports as a channel over which an application can query and a wallet can provideaddress without manually copying, scanning, or complex integrations. The [CAIP-10][] standard is chosen as it clearly indicates the blockchain namespace and reference.

[bumblefudge]

Suggested change

Currently there is no way for a service to request an address from a wallet in a chain agnostic way. This makes chain agnostic payments hard because the requester does not know what chains/tokens the payer supports before sending out a payment request. By requesting a wallet address the requester can look up the payers available tokens out of band (or via something like [EIP-7811][]) and then send them an appropriate chain-specific payment request.

Currently there is no way for a service to request an address from a wallet in a chain-agnostic way, except in the negotiations to open a CAIP-25 connection. This makes chain agnostic payments hard because the requester does not know what chains/tokens the payer supports before sending out a payment request. By requesting a wallet address the requester can look up the payers available tokens out of band (or via something like [EIP-7811][]) and then send them an appropriate chain-specific payment request.

[bumblefudge]

If this is an NFC-only or transport-agnostic protocol, the abstract should probably mention it!

And either way, a # Test Cases section (with both success cases and failure cases) would help, to make explicit what this query/return actually looks like as an NFC exchange, a JSON-RPC call/response, an HTTP GET/response, etc.

[bumblefudge]

@timjrobinson did you get any interest from implementers to take this over the line? I feel like it's 99% of the way there, just a few gaps to make this worth publishing as a draft to leave a hook in the [more public] water[s]...