Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ERC: Wallet Asset Discovery #709

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
222 changes: 222 additions & 0 deletions ERCS/erc-7811.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,222 @@
---
eip: 7811
title: Wallet Asset Discovery
description: JSON-RPC method for wallets to share a user’s full asset list with Dapps, including assets not easily found through on-chain data alone
author: Luka Isailovic (@lukaisailovic), Konrad Kopp (@kopy-kat)
discussions-to: https://ethereum-magicians.org/t/erc-7811-wallet-asset-discovery/21639
status: Draft
type: Standards Track
category: ERC
created: 2024-11-07
---

## Abstract

This ERC introduces a new RPC call, wallet_getAssets, for wallets to declare to the Dapp what assets are owned by the user. This allows for more accurate asset discovery and the use of assets that aren’t available on-chain but can be provided by the wallet

## Motivation

Currently, Dapps primarily rely on on-chain data to determine a user's balance, which can be limiting. Furthermore, a Dapp might restrict the user from initiating actions that the wallet could otherwise resolve, as it cannot account for the total assets a user has across different accounts or chains.

Wallets already have information about a user's assets, including those not visible on-chain, and need a way to communicate that information to Dapps.

## Specification

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

### Method: `wallet_getAssets`

#### Request schema

```ts
type WalletGetAssetsRequest = {
account: Hex;
requiredAssets?: Record<Hex, Hex[]>;
};
```

`account` is a required field that indicates for which account assets are requested.
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this an account address or CAIP-10?

Copy link
Author

Choose a reason for hiding this comment

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

Its account address, however I named it account to keep the naming consistent with other calls.


`requiredAssets` is an optional field that specifies only the assets Dapp cares about on the specific chains. If it is provided, the response from the wallet SHOULD include those assets.

#### Example request

```json
{
"account": "0x123",
"requiredAssets": {
"0x1": ["0x456", "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE"],
"0xa": ["0x789", "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE"]
}
}
```

#### Response schema

```ts
type Asset = {
address: Hex;
balance: Hex;
type: string;
metadata: any;
};
type WalletGetAssetsResponse = Record<Hex, Asset[]>;
```

The key **SHOULD** be [EIP-155](./eip-155.md) chainId
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not MUST?

Copy link
Contributor

Choose a reason for hiding this comment

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

What about cross-chain assets? E.g. Solana? Maybe this should be a CAIP-2?


Asset fields:

`address` is the address of the asset as Hex. Native assets **MUST** use `0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE` address specified by [ERC-7528](./eip-7528.md)
Copy link

@jxom jxom Nov 20, 2024

Choose a reason for hiding this comment

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

Kind of odd. Why do we need to include a stub address for native?

Copy link
Author

Choose a reason for hiding this comment

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

I wanted to keep the type for any asset

type Asset = {
  address: Hex;
  balance: Hex;
  type: string;
  metadata: any;
};

I wanted to make the address mandatory, instead of address?: Hex;
What do you think is better for the client implementations?

Copy link
Contributor

Choose a reason for hiding this comment

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

address: Hex | "native";

?


`balance` is the balance of the asset as Hex

**`type`:** A string indicating the type of the asset. Common asset types include but **aren’t limited to**:

- **`ERC20`:** For [ERC-20](./eip-20.md) tokens
- **`ERC721`:** For [ERC-721](./eip-721.md) tokens (NFTs)
- **`native`:** For the chain's native currency

**`metadata`:** An optional object containing additional information about the asset. The specific fields within the metadata object may vary depending on the asset type and the wallet's implementation."

#### Example response

```json
{
"0x1": [
{
address: "0x123",
balance: "0xcaaea35047fe5702",
Comment on lines +86 to +89
Copy link
Contributor

@chris13524 chris13524 Nov 21, 2024

Choose a reason for hiding this comment

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

Suggest using address as the key to simplify lookups

Suggested change
"0x1": [
{
address: "0x123",
balance: "0xcaaea35047fe5702",
"0x1": {
"0x123": {
balance: "0xcaaea35047fe5702",

Copy link

Choose a reason for hiding this comment

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

ah yeah, then you could have native key too

Copy link
Author

Choose a reason for hiding this comment

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

This is an interesting point, would simplify lookups a lot for the clients!

type: "ERC20",
metadata: {
name: "Token",
symbol: "TOK",
decimals: 18,
}
},
{
address: "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE",
balance: "0xcaaea35047fe5702",
type: "native"
}
Comment on lines +97 to +101
Copy link

@jxom jxom Nov 20, 2024

Choose a reason for hiding this comment

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

Wonder if we should have a rule that native asset must be the first item in the array. Would feel a bit weird to have a linear time complexity just to extract a native balances across chains (ie. there could be many many tokens on each chain).

Copy link
Contributor

Choose a reason for hiding this comment

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

Would this suggestion resolve your concern?

],
"0xa": [
{
address: "0x456",
balance: "0xcd5595",
type: "ERC721",
metadata: {
//...
}
}
],
};
```

### Asset definitions

This section specifies a structure for the most commonly used asset types.
This ERC does not specify an exhaustive list of asset types. Since the type is a generic string, there could be a mismatch between the type Dapp expects and the one returned by the wallet. It’s important that no two assets share the same type. Therefore, new asset types should be specified in ERCs, either in this ERC as an amendment or in another ERC.

**Native**

```ts
type NativeAsset = {
address: "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE";
balance: Hex;
type: "native";
metadata: any;
Copy link

Choose a reason for hiding this comment

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

should this be omitted for native?

};
```

Example:

```json
{
"address": "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE",
"balance": "0xcaaea35047fe5702",
"type": "native"
}
```

**ERC-20 Token**

```ts
type Erc20Asset = {
address: Hex;
balance: Hex;
type: "ERC20";
metadata: {
name: string;
symbol: string;
decimals: number;
[key: string]: any;
Copy link

Choose a reason for hiding this comment

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

What extra would go here? If this is different per wallet, might be a bit hard/unrealistic for applications to coerce. Can we keep it strict?

Copy link
Author

Choose a reason for hiding this comment

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

Good point, will update!

};
};
```

Example:

```json
{
address: "0x123",
balance: "0xcaaea35047fe5702",
type: "ERC20",
metadata: {
name: "Token",
symbol: "TOK",
decimals: 18
}
},
```

**ERC-721 Token**

```ts
type Erc721Asset = {
address: Hex;
balance: Hex;
type: "ERC20";
metadata: {
name: string;
symbol: string;
[key: string]: any;
};
};
```

### Capabilities

If the wallet is using CAIP-25 authorization, wallet **SHOULD** include `assetDiscovery` key in the CAIP-25 `sessionsProperties` object. Value should be an object with `supported` key and value `true`

```json
{
//...
"sessionProperties": {
"assetDiscovery": {
"supported": true
}
}
}
```

If the wallet supports [ERC-5792](./eip-5792.md) wallet **SHOULD** respond on `wallet_getCapabilities` request using the `assetDiscovery` key. Value should be an object with `supported` key and value `true`
Wallet **SHOULD** include this for every chainId.

```json
{
"0xa": {
"assetDiscovery": {
"supported": true
}
}
}
```

## Rationale

## Security Considerations

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).
Loading