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:
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.
One new EIP-5792 wallet capability is defined.
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 Specificationwallet_getCapabilities Example ResponserequiredAssets ParameterWhen a wallet indicates support for the auxiliaryFunds capability (i.e., supported: true), applications that use the wallet_sendCalls method MAY include a requiredAssets parameter in the capabilities.auxiliaryFunds object to enable the wallet to leverage this capability.
A wallet's signaling support for the auxiliaryFunds capability does not necessarily mean they can interpret or use the requiredAssets metadata. The requiredAssets parameter is an optional capability that wallets may or may not support, even when they support the base auxiliaryFunds capability.
Native Asset Handling: Wallets SHOULD deduce native asset requirements (e.g., ETH on Ethereum mainnet) from the call.value field in the calls array rather than requiring explicit specification in requiredAssets. The requiredAssets parameter is primarily intended for token assets that cannot be inferred from call data alone.
This parameter may be necessary because transaction call data alone does not reliably indicate which assets and amounts are needed for successful execution. Calls may involve complex logic or multiple contracts, making it difficult for wallets to infer requirements. By specifying required assets and amounts explicitly, apps ensure wallets have the information needed to provision, bridge, or swap assets as necessary for the transaction to succeed.
wallet_sendCalls Extended ParameterIf included, the requiredAssets parameter MUST be specified within the capabilities.auxiliaryFunds object of the wallet_sendCalls request.
Note: The
capabilitiesobject is specified in EIP-5792 wherewallet_sendCallsis first defined: "The capabilities field is how an app can communicate with a wallet about capabilities a wallet supports. For example, this is where an app can specify a paymaster service URL from which an ERC-4337 wallet can request a paymasterAndData input for a user operation."
Suppose a user wants to deposit DAI into Aave on Chain X, but their wallet address on Chain X has no DAI or native gas token. However, the wallet has access to funds on Chain Y (e.g., Ethereum mainnet). The app, upon detecting the auxiliaryFunds capability, can construct a wallet_sendCalls request as follows:
The wallet, upon receiving this request, can:
This mechanism allows advanced wallets to abstract away the complexity of cross-chain or offchain funding, enabling seamless user experiences even when the user's onchain balance is insufficient on the target chain.
This specification currently supports three token standards with the following field requirements:
amount field onlyamount and tokenId fieldsamount and tokenId fieldsThe amount field semantics vary by token standard:
Future token standards MUST specify additional required fields as properties on the asset object root to maintain extensibility.
Auxiliary funds provisioning (bridging, swapping, or other asset retrieval operations) is independent of the wallet_sendCalls execution lifecycle. The atomicRequired field applies only to the call bundle execution, not to auxiliary funds provisioning.
The following error codes are defined for auxiliary funds provisioning failures.
| Code | Message | Description |
|---|---|---|
| 5770 | Auxiliary funds provisioning failed | Wallet attempted to provision funds but failed (e.g., bridge/swap error). |
| 5771 | Asset not supported | The requested asset is not available through the wallet's auxiliary fund system. |
| 5772 | Auxiliary funds capability not available | The wallet no longer supports auxiliary funds on the requested chain. |
| 5773 | Invalid requiredAssets | The structure of the requiredAssets object is malformed. |
Applications SHOULD use the wallet_getCallsStatus method to track the status of call bundles that involve auxiliary funds provisioning, as the provisioning process may take time to complete. The status response will indicate whether the auxiliary funds provisioning is in progress, completed, or failed.
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.
Apps MAY include the requiredAssets parameter in the capabilities.auxiliaryFunds object to ensure the wallet has the necessary information to provision assets as needed for successful execution. However, apps should be aware that this is an optional capability and should handle cases where wallets do not support or cannot process the requiredAssets metadata gracefully.
The wallet MUST cross-check the amount value in requiredAssets against the decimal() value specified on the asset's contract to ensure that the amount is interpreted correctly according to the asset's decimal precision.
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.
requiredAssets parameter if the wallet advertises the auxiliaryFunds capability.auxiliaryFunds capability with optional: true to provide metadata to wallets that support this optional capability while maintaining compatibility with wallets that do not.Copyright and related rights waived via CC0.