Add ERC-7846: Wallet Connection API

[ilikesymmetry]

This proposal defines a new RPC for wallet connection with an emphasis on extensibility. Builds on the notion of optional “capabilities” defined in ERC-5792 to add new functionality modularly. This proposal defines one capability to reduce separate interactions for connection and authentication, but otherwise seeks to leave capability definitions open-ended.

[eip-review-bot]

✅ All reviewers have approved.

[pedrouid]

While I understand the motivation for creating EVM-specific standards for Wallets... there is nothing new or extra that ERC-7846 provides that isn't already covered by CAIP-222

https://chainagnostic.org/CAIPs/caip-222

Why restrict such an important pattern like "Connect + Sign" to only EVM wallets?

[johanneskares]

This proposal defines a new RPC for wallet connection with an emphasis on extensibility. Builds on the notion of optional “capabilities” defined in ERC-5792 to add new functionality modularly. This proposal defines one capability to reduce separate interactions for connection and authentication, but otherwise seeks to leave capability definitions open-ended.

one huge problem still:

For passkey wallets, e.g. Signing Up with Coinbase Smart Wallet, you would still need 2 interactions with this ERC. First TouchID to get the Ethereum Address, second one to sign the message. Sign In With Ethereum is not a good solution. The address should not be part of the signed message. It's implicit from the signature.

I'd suggest changing this ERC to allow signing an arbitrary message, makes it simpler and leaves the kind of signature to the dApp.

[bumblefudge]

Why restrict such an important pattern like "Connect + Sign" to only EVM wallets?

I would tend to agree that having a multi-VM/multi-L1 syntax for every context except EVM and an EVM-specific context is needlessly inharmonious, if using the CAIP-222 RPC message would be functionally identical to this bespoke one.

That said, we have an ERC here that seems to work, and are comparing it to the hypothetical ERC which achieves the same properties with a CAIP-222-conformant message. Would it help to write a competing ERC that has all the same properties and additional can be parsed by a multi-chain/CAIP-222 system like WalletConnect's? I'd rather not be the one to write it, but if no one else is offering AND evaluators of this ERC would appreciate an apples-to-apples ERC, I can write one... who knows, maybe the exercise of writing out CAIP-222 as an ERC for EVM-specific contexts will tease out subtle differences?

[github-actions[bot]]

The commit d91b259bb093ab3c349496002b4b36632b7ca4ed (as a parent of 5fa6bd2238e81ef9fe84d85927838c196e5e4feb) contains errors. Please inspect the Run Summary for details.

[stephancill]

Hi @SamWilsn and @glitch-txs thanks for the feedback. I've worked with @ilikesymmetry to update the PR