Skip to content

Conversation

@pedrouid
Copy link
Member

This CAIP defines a standard WalletInfo metadata object to identify and validate the wallet provider that a client application is interacting with. It can be used across RPC methods, APIs, and protocols to provide consistent, cross-chain wallet identification.


A `WalletInfo` object MUST contain the following fields:

- **uuid**: A globally unique identifier (UUIDv4) generated by the wallet provider to uniquely distinguish different wallet provider sessions that have otherwise matching properties. The cryptographic uniqueness of UUIDv4 ensures separate identification of independent sessions.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if these are identifying sessions, wouldn't a time-sortable UUID like v6 or v7 be justified here? or is there some danger in leaking temporal/sequence information in combination with the other properties?

## Abstract

The `WalletInfo` object provides a minimal, standardized set of fields that uniquely identify a wallet provider and allow dApps to confirm they are connected to the intended wallet.
The object is designed for use in [CAIP-25] session properties, [CAIP-282] messages, and other API contexts.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for use in [CAIP-25] session properties

tbh i got a little confused by whether you meant properties of a caip-25 session or sessionProperties specifically... and then went down the rabbithole of what situations would justify dapps sending the WalletInfo object to a wallet (tell me if you're not this wallet? correct this if you've upgraded since last session?)

Copy link
Collaborator

@bumblefudge bumblefudge Oct 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pedrouid reviewing this again a month later, I think i want the informational/privacy assumptions more clearly defined in ## Motivation ? happy to hash them out together on a call, it just makes it a little hard to review/approve without constraints on when to use this and when not to use this... would feel better about requesting review from people if the privacy assumptions (ideally including where NOT to use this or what NOT to share) were spelled out

@bumblefudge
Copy link
Collaborator

bumblefudge commented Sep 15, 2025

i know this is JSON-RPC and open payments API is a more conventional HTTPS GET, but I wonder what it would look like for a wallet to expose both metadata objects for different use-cases...
https://openpayments.dev/apis/wallet-address-server/operations/get-wallet-address/#200

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants