Proposed JSON-RPC method: wallet_getAssetBalance

With intents, multi-chain transactions, and other tools, accounts will increasingly be making use of “just in time” funding when transacting. Apps can no longer rely on calls like address.balance or erc20.balanceOf to know an account’s spending power.

I propose a new wallet RPC to help, something like wallet_getAssetBalance(account_address, chainId, asset_address).

Very open to feedback. Want to start a conversation. One question I have: should this RPC try to make use of some more universal asset identifier? Or, because most apps care about a specific asset on a specific chain, chain + address is sufficient.

5 Likes

Feel like this could be a good fit as a CAIP-25 extension actually.

When it comes to a universal asset identifier, I imagine it might be a bit overkill and could be implemented by the wallet at the library level. Especially with quirks like some tokens having a different amount of decimals on different chains, bridged → native token migrations, etc.

Or how were you imagining it?

3 Likes

hmm how do you think as a CAIP-25 extension? Would be part of handshake? Seems like a lot to ask about all possible asset balances. E.g. imagine connecting to Uniswap.

Re universal identifier, maybe the field is just 32 bytes long so that people have some space for extra info. E.g. in the ERC1155 case, you would want to pass both the asset address and the token id.

1 Like

Oh no a CAIP extension would not require all the balances to be given at once, it would just mean that the dapp would check during the handshake whether the wallet supports wallet_getAssetBalance (and the wallet would confirm or deny), and the dapp would use that method if supported, otherwise fall back to erc20 getBalance

2 Likes

Ah yeah, that’s a good idea.

Also wondering if we could just add a method to viem/wagmi that optimistically tries this Wallet RPC, and falls back to a normal balance change.

Also thinking more about the asset identifier maybe

{ 
  type: bytes12 // "ERC20" | "ERC1155" | "..."
  address: Address
}

or we could pull chainId into the asset identifier as well

{ 
  chainId: uint24
  type: bytes9 // "ERC20" | "ERC1155" | "..."
  address: Address
}

Bytes9 might be too constraining for type. Fitting this all into bytes32 is somewhat of an ar

1 Like

the way this is done in today’s CAIP-25 (no new extensions needed) is that a dapp would request an RPC method like wallet_getAssetBalance and, (if both wallet and dapp both support the “custom RPC endpoints”), a stable URL where that RPC is defined (i.e., if there is an OpenRPC API dictionary published somewhere that wallet and dapp can defer to for the canonical definition of that API; could be the URL of an EIP, for example).

1 Like

Just like Uniswap has token list, similarly as asset list could be maintained for other types of assets as well.

You mentioned ‘just in time’ funding of accounts. Can you give an example of this? Like how would this rpc will return a different result as compared to erc20.balanceOf() ?

1 Like

Sir, I really agree with you. Appreciate your efforts.