Skip to content
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: Auxiliary Funds Capability #372

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
79 changes: 79 additions & 0 deletions ERCS/erc-7682.md
@@ -0,0 +1,79 @@
---
eip: 7682
title: Auxiliary Funds Capability
description: A way for wallets to indicate to apps that they have access to additional funds
author: Lukas Rosario (@lukasrosario), Wilson Cusack (@wilsoncusack)
discussions-to: https://ethereum-magicians.org/t/erc-7682-auxiliary-funds-capability/19599
status: Draft
type: Standards Track
category: ERC
created: 2024-04-09
requires: 5792
---

## Abstract

An [EIP-5792](./eip-5792.md) 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.

## 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](./eip-5792.md) wallet capability is defined.

### Wallet Implementation

To conform to this specification, wallets that wish to indicate that they have access to auxiliary funds MUST respond to `wallet_getCapabilities` calls with an `auxiliaryFunds` object with a `supported` field set to `true` for each chain they have access to auxiliary funds on. This specification does not put any constraints on the source of the auxiliary funds.

#### `wallet_getCapabilities` Response Specification

```typescript
type AuxiliaryFundsCapability = {
supported: boolean;
}
```

##### `wallet_getCapabilities` Example Response

```json
{
"0x2105": {
"auxiliaryFunds": {
"supported": true
},
},
"0x14A34": {
"auxiliaryFunds": {
"supported": true
}
}
}
```

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

#### Auxiliary Funds per Asset

We could also specify auxiliary funds support per asset. We decided against this because this list could get quite large if a wallet has auxiliary funds supports for many assets, and a single boolean should be enough for apps to not block users from taking actions.

## 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](../LICENSE.md).