-
Notifications
You must be signed in to change notification settings - Fork 487
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
base: master
Are you sure you want to change the base?
Add ERC: Wallet Asset Discovery #709
Conversation
The commit 06feb19 (as a parent of b321265) contains errors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Dysk
}; | ||
``` | ||
|
||
`account` is a required field that indicates for which account assets are requested. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
type WalletGetAssetsResponse = Record<Hex, Asset[]>; | ||
``` | ||
|
||
The key **SHOULD** be [EIP-155](./eip-155.md) chainId |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not MUST
?
There was a problem hiding this comment.
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?
name: string; | ||
symbol: string; | ||
decimals: number; | ||
[key: string]: any; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, will update!
address: "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE"; | ||
balance: Hex; | ||
type: "native"; | ||
metadata: any; |
There was a problem hiding this comment.
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?
{ | ||
address: "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE", | ||
balance: "0xcaaea35047fe5702", | ||
type: "native" | ||
} |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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?
|
||
Asset fields: | ||
|
||
`address` is the address of the asset as Hex. Native assets **MUST** use `0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE` address specified by [ERC-7528](./eip-7528.md) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
address: Hex | "native";
?
"0x1": [ | ||
{ | ||
address: "0x123", | ||
balance: "0xcaaea35047fe5702", |
There was a problem hiding this comment.
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
"0x1": [ | |
{ | |
address: "0x123", | |
balance: "0xcaaea35047fe5702", | |
"0x1": { | |
"0x123": { | |
balance: "0xcaaea35047fe5702", |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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!
|
||
## 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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 | |
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 |
Please put code in backticks, both here and throughout the rest of the document.
|
||
```ts | ||
type WalletGetAssetsRequest = { | ||
account: Hex; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not super familiar with TypeScript. Is Hex
a predefined type?
}; | ||
``` | ||
|
||
`account` is a required field that indicates for which account assets are requested. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`account` is a required field that indicates for which account assets are requested. | |
`account` is a REQUIRED field that indicates for which account assets are requested. |
You should uppercase the RFC 2119 keywords.
|
||
`account` is a required field that indicates for which account assets are requested. | ||
|
||
`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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
`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. | |
`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. |
### 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. | |
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 future ERCs. |
You cannot amend a Final ERC, so I'd recommend removing this bit.
status: Draft | ||
type: Standards Track | ||
category: ERC | ||
created: 2024-11-07 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
created: 2024-11-07 | |
created: 2024-11-07 | |
requires: 20, 155, 721, 5792, 7528 |
|
||
### 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` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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` | |
If the wallet is using [CAIP-25](https://github.com/ChainAgnostic/CAIPs/blob/0848f06f6cfc29ce619bccdd5035c1d500033b21/CAIPs/caip-25.md) authorization, wallet **SHOULD** include `assetDiscovery` key in the CAIP-25 `sessionsProperties` object. Value should be an object with `supported` key and value `true` |
``` | ||
|
||
## Rationale | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<!-- TODO --> | |
## Rationale | ||
|
||
## Security Considerations | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<!-- TODO --> | |
Friendly reminder to keep technical discussion on the Ethereum Magicians thread. Otherwise, once this pull request is merged, discussion will get fragmented as the proposal moves through the statuses. |
JSON-RPC method for wallets to share a user’s complete asset list with Dapps, including assets not easily discoverable through on-chain information alone.