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.
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.
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
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).