Auxiliary Funds Capability
Video
Original
Abstract
An EIP-5792 compliant capability that allows wallets to indicate to apps that they have access to funds beyond those that can be accounted for by looking up balances onchain given the wallet's address.
A wallet's ability to access auxiliary funds is communicated to apps as part of its response to an EIP-5792 wallet_getCapabilities
request. The following standard does not specify the source of these auxiliary funds, but some examples are:
- Funds from offchain sources that can be onramped and used just-in-time
- Wallets that manage many accounts, where assets across those accounts can be transfered to the required account before submitting a transaction requested by an app
Motivation
Many applications check users' balances before letting them complete some action. For example, if a user wants to swap some amount of tokens on a dex, the dex will commonly block the user from doing so if it sees that the user does not have that amount of tokens at their address. However, more advanced wallets have features that let users access funds from other sources. Wallets need a way to tell apps that they have access to additional funds so that users using these more advanced wallets are not blocked by balance checks.
Specification
One new EIP-5792 wallet capability is defined.
Wallet Implementation
To conform to this specification, wallets that wish to indicate that they have access to auxiliary funds MUST, for each chain they have access to auxiliary funds on, respond to wallet_getCapabilities
calls with an auxiliaryFunds
object with a supported
field set to true
.
Wallets may also optionally specify which assets they have additional access to with an assets
field, which maps to an array of addresses representing the assets the wallet might have additional access to. If a wallet does not respond with this optional array of assets, the application SHOULD assume the wallet has additional access to any asset.
This specification does not put any constraints on the source of the auxiliary funds.
In this specification, a chain's native asset (e.g. Ether on Ethereum) MUST be represented by "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE" as specified by EIP-7528.
wallet_getCapabilities
Response Specification
type AuxiliaryFundsCapability = { supported: boolean; assets?: `0x${string}`[]; }
wallet_getCapabilities
Example Response
{ "0x2105": { "auxiliaryFunds": { "supported": true, "assets": [ "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE", "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913" ] } }, "0x14A34": { "auxiliaryFunds": { "supported": true, "assets": [ "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE", "0x036CbD53842c5426634e7929541eC2318f3dCF7e" ] } } }
App Implementation
When an app sees that a connected wallet has access to auxiliary funds via the auxiliaryFunds
capability in a wallet_getCapabilities
response, the app SHOULD NOT block users from taking actions on the basis of asset balance checks.
Rationale
Alternatives
Advanced Balance Fetching
An alternative we considered is defining a way for apps to fetch available auxiliary balances. This could be done, for example, by providing a URL as part of the auxiliaryFunds
capability that apps could use to fetch auxiliary balance information. However, we ultimately decided that a boolean was enough to indicate to apps that they should not block user actions on the basis of balance checks, and it is minimally burdensome for apps to implement.
The shape of this capability allows for a more advanced extension if apps feel more functionality is needed.
Security Considerations
Apps MUST NOT make any assumptions about the source of auxiliary funds. Apps' smart contracts should still, as they would today, make appropriate balance checks onchain when processing a transaction.
Copyright
Copyright and related rights waived via CC0.
Adopted by projects
Not miss a beat of EIPs' update?
Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.
View all