SIP-26: Non-EVM protocol support #147

danroc · 2024-08-30T15:15:33Z

Abstract

This SIP presents an architecture to enable Snaps to expose blockchain-specific methods to dapps, extending MetaMask's functionality to support a multichain ecosystem.

Motivation

Currently, MetaMask is limited to EVM-compatible networks. This proposal aims to empower developers, both first- and third-party, to use Snaps to add native support for non-EVM-compatible chains within MetaMask.

Fixes: https://github.com/MetaMask/accounts-planning/issues/542

gantunesr

Left a couple of small comments, overall this looks like a good improvement to handle multichain requests and scale the wallet beyond EVM chains

SIPS/sip-26.md

gantunesr · 2024-09-22T23:28:41Z

SIPS/sip-26.md

+- **Account Router**: Native component that forwards signing requests to the
+  appropriate Account Snap or native implementation.


I see that the Account Router is the one that registers signing methods to the RPC Router, but how are the signing methods registered into the Account Router?

They are listed in the account object in the methods field.

But it made me think of another problem: the account doesn't list the supported chains (there is a method to get this information, but we should probably move it into the account object).

Co-authored-by: Gustavo Antunes <17601467+gantunesr@users.noreply.github.com>

SIPS/sip-26.md

Co-authored-by: Charly Chevalier <charlyy.chevalier@gmail.com>

rekmarks · 2024-09-26T04:37:09Z

SIPS/sip-26.md

+- **Account Address Resolution Snaps**: Snaps that implement the
+  `resolveAccountAddress` method to extract the account address from the
+  request object.


Can these Snaps be the same as Account and Protocol Snaps, or do they have to be separate?

After talking with @Mrtenz, I believe the Snaps should remain separate. Our goal is for these Snaps to operate without special permissions. Additionally, we should have only one Account Address Resolution Snap per blockchain. This will help simplify the Account (CAIP-2) Snap and prevent any confusion about which Account Address Resolution Snap to use.

adonesky1 · 2024-09-26T14:18:42Z

SIPS/sip-26.md

+- **Account Snaps**: Snaps that implement the Keyring API and are responsible
+  for signing requests and managing accounts.
+
+- **Protocol Snaps**: Snaps that implement protocol methods that do not require
+  an account to be executed.


I thought per our discussions with @rekmarks we'd determined that we can't enforce separation of Account + Protocol Snaps?

Oh I now see the language in your diagram saying that these can be combined. I think its more confusing to represent them as (sortof) separate in the diagram.

As I believe I said in our meeting I don't think we're really getting anything by having these non signing protocol snaps that implement non signing methods if the signing snaps can trivially handle those requests too.

In that case I feel like its clearer to call them something more general than "Account Snaps" since they are not just handling accounts. Maybe "Protocol Snaps" or "CAIP-2 Snaps" (though I'd prefer something that clearly states its purpose without external reference).

To restate what I said in a meeting: As I read it, they are just two separate permissions that a Snap may or may not put together, and some Snaps (e.g. hardware wallet or SCAs) may want to only ship the account part.

shanejonas · 2024-09-26T14:24:39Z

SIPS/sip-26.md

+      account: {
+          id: '74bb3393-f267-48ee-855a-2ba575291ab0',
+          type: 'eip155:eoa',
+          address: '0x1234567890123456789012345678901234567890',


this should be a caip-10 address to include the chainid which is missing context here when creating an account:

eip155:1:0xab16a96D359eC26a11e2C2b3d8f8B8942d5Bfcdb

Yea agreed. We will need some way to associate this account with the appropriate CAIP-2 identifier for routing purposes, whether its making these CAIP-10 addresses or adding a CAIP-2 property on the object.

This is not a 1:1 mapping to the blockchain account, and for EVM chains the address is the same accross all networks, so I think CAIP-2 addresses are not suitable here.

We have thought about using CAIP-2 namespaces, but it's not in the scope of this SIP, this snippet is an example of the existing API.

🤔 Do we have a plan for how to handle types that are not eip155:eoa (EVM SCAs and other non-evm chains where the account type might not provide enough to be sure that the account can be used on all subchains) then? Seems like we should include a CAIP-2 scope(s) property here?

is there documentation we could link to where this type property is defined/scoped?

shanejonas · 2024-09-26T14:25:00Z

SIPS/sip-26.md

+          type: 'eip155:eoa',
+          address: '0x1234567890123456789012345678901234567890',
+          methods: ['eth_signTypedData_v4'],
+          options: {},


what would go in options?

This is part of the Keyring API and is used by Snap devs to store implementation-dependent information about the account. An example would be to use it to store the tresholds, index, and other metadata used by MPC accounts.

SIPS/sip-26.md

* SIP-26: Update Snaps-specific parts of the specification * Minor updates * Reword slightly * Update SIPS/sip-26.md Co-authored-by: Alex Donesky <alex.donesky@consensys.net> --------- Co-authored-by: Alex Donesky <alex.donesky@consensys.net>

SIPS/sip-26.md

Co-authored-by: Frederik Bolding <frederik.bolding@gmail.com>

FrederikBolding · 2024-11-14T12:58:20Z

Awaiting sign off from @adonesky1 before merging

SIPS/sip-26.md

adonesky1 · 2024-11-14T14:52:59Z

SIPS/sip-26.md

+#### RPC Router
+
+The RPC Router will be a new native component responsible for routing JSON-RPC
+requests to the appropriate Snap or keyring.


Is it confusing to separate keyring from Snap here since all the keyrings we route to are Snap keyrings?

Suggested change

requests to the appropriate Snap or keyring.

requests to the appropriate Snap.

🤔 I dunno this isn't a big deal and maybe its better as is

Personally I think this is fine as-is since we don't wanna route directly to keyring Snaps, but to the native keyring controlling them. It is a minor detail though

SIPS/sip-26.md

adonesky1 · 2024-11-14T15:37:32Z

SIPS/sip-26.md

+        type: "eip155:eoa",
+        address: "0x1234567890123456789012345678901234567890",
+        methods: ["eth_signTypedData_v4"],


[nit] since this SIP is for non-evm snaps should we provide a non-evm example here?

Also I'm still wondering how we plan to standardize non-evm account types. Currently our documentation only appears to describe eip155:eoa or eip155:erc4337

I have been requesting this as well, we need a more generic type that allows any protocol. IIRC @danroc and team are thinking about how to do that.

Co-authored-by: Alex Donesky <alex.donesky@consensys.net>

SIPS/sip-26.md

danroc self-assigned this Sep 2, 2024

danroc added 6 commits September 12, 2024 10:39

Add draft of SIP-26

df817e7

Remove optional header fields

df59210

Add SIP number and remove unused optional fields

febeb1e

Rename diagram image

7709ea8

Rename components diagram in document

48b95a3

Update diagram and add components descriptions

ed17dd3

danroc force-pushed the dr/accounts branch from 5484024 to ed17dd3 Compare September 12, 2024 08:40

danroc marked this pull request as ready for review September 12, 2024 08:43

danroc requested review from Montoya, ziad-saab and a team as code owners September 12, 2024 08:43

danroc added 12 commits September 13, 2024 17:06

Rename "Address Resolution Snaps" to "Account Address Resolution Snaps"

da3182a

Update components diagram

1a782b5

Update resolveAccountAddress signature

3848c61

Add link to CAIP-2 and remove commented text

d514496

Add Protocol Snaps

33194a3

Update components diagram

0c9bb3f

Update resolveAccountAddress docs

b4f6618

Clarify: should -> MUST

ea35e35

Update resolveAccountAddress method

5260fba

Remove mention to SIP-25

9696ca7

Add note about Snap events

cab089f

Minor text improvements

b81138d

gantunesr reviewed Sep 22, 2024

View reviewed changes

Add mention to CAIP-2 chain IDs

7a99884

Co-authored-by: Gustavo Antunes <17601467+gantunesr@users.noreply.github.com>

ccharly reviewed Sep 24, 2024

View reviewed changes

SIPS/sip-26.md Outdated Show resolved Hide resolved

Update keyring-api repo URL

ddd9c7d

Co-authored-by: Charly Chevalier <charlyy.chevalier@gmail.com>

rekmarks reviewed Sep 26, 2024

View reviewed changes

adonesky1 reviewed Sep 26, 2024

View reviewed changes

shanejonas reviewed Sep 26, 2024

View reviewed changes

danroc added 2 commits September 30, 2024 16:52

Add note about Accounts Router and Protocol Snaps priority

a0c782c

chore: update SIP-26 following latest discussions

72fb0c2

danroc changed the title ~~SIP-26: Account Router Snap~~ SIP-26: RPC Router and support for non-EVM chains Nov 12, 2024

adonesky1 reviewed Nov 13, 2024

View reviewed changes

SIPS/sip-26.md Outdated Show resolved Hide resolved

adonesky1 reviewed Nov 13, 2024

View reviewed changes

SIPS/sip-26.md Outdated Show resolved Hide resolved

FrederikBolding reviewed Nov 14, 2024

View reviewed changes

SIPS/sip-26.md Outdated Show resolved Hide resolved

danroc changed the title ~~SIP-26: RPC Router and support for non-EVM chains~~ SIP-26: Non-EVM protocol support Nov 14, 2024

chore: update title

f59f3cc

Co-authored-by: Frederik Bolding <frederik.bolding@gmail.com>

FrederikBolding previously approved these changes Nov 14, 2024

View reviewed changes

Mrtenz previously approved these changes Nov 14, 2024

View reviewed changes

adonesky1 reviewed Nov 14, 2024

View reviewed changes

SIPS/sip-26.md Outdated Show resolved Hide resolved

adonesky1 reviewed Nov 14, 2024

View reviewed changes

SIPS/sip-26.md Outdated Show resolved Hide resolved

adonesky1 reviewed Nov 14, 2024

View reviewed changes

SIPS/sip-26.md Show resolved Hide resolved

adonesky1 reviewed Nov 14, 2024

View reviewed changes

SIPS/sip-26.md Outdated Show resolved Hide resolved

adonesky1 reviewed Nov 14, 2024

View reviewed changes

SIPS/sip-26.md Outdated Show resolved Hide resolved

adonesky1 reviewed Nov 14, 2024

View reviewed changes

Apply suggestions from code review

7b35ebc

Co-authored-by: Alex Donesky <alex.donesky@consensys.net>

FrederikBolding dismissed stale reviews from Mrtenz and themself via 7b35ebc November 14, 2024 15:46

FrederikBolding reviewed Nov 14, 2024

View reviewed changes

SIPS/sip-26.md Show resolved Hide resolved

Update SIPS/sip-26.md

8a0171a

FrederikBolding approved these changes Nov 14, 2024

View reviewed changes

adonesky1 approved these changes Nov 14, 2024

View reviewed changes

FrederikBolding merged commit d2a8c29 into main Nov 14, 2024
3 checks passed

FrederikBolding deleted the dr/accounts branch November 14, 2024 15:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SIP-26: Non-EVM protocol support #147

SIP-26: Non-EVM protocol support #147

danroc commented Aug 30, 2024 •

edited

Loading

gantunesr left a comment

gantunesr Sep 22, 2024

danroc Sep 23, 2024

rekmarks Sep 26, 2024

danroc Sep 26, 2024

adonesky1 Sep 26, 2024

adonesky1 Sep 26, 2024 •

edited

Loading

rekmarks Sep 26, 2024

shanejonas Sep 26, 2024

adonesky1 Sep 26, 2024

danroc Sep 30, 2024

adonesky1 Nov 13, 2024 •

edited

Loading

adonesky1 Nov 13, 2024

shanejonas Sep 26, 2024

danroc Sep 30, 2024

FrederikBolding commented Nov 14, 2024

adonesky1 Nov 14, 2024

adonesky1 Nov 14, 2024

FrederikBolding Nov 14, 2024

adonesky1 Nov 14, 2024 •

edited

Loading

adonesky1 Nov 14, 2024

FrederikBolding Nov 14, 2024

		- Account Router: Native component that forwards signing requests to the
		appropriate Account Snap or native implementation.

	requests to the appropriate Snap or keyring.
	requests to the appropriate Snap.

SIP-26: Non-EVM protocol support #147

SIP-26: Non-EVM protocol support #147

Conversation

danroc commented Aug 30, 2024 • edited Loading

Abstract

Motivation

gantunesr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adonesky1 Sep 26, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adonesky1 Nov 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

FrederikBolding commented Nov 14, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adonesky1 Nov 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

danroc commented Aug 30, 2024 •

edited

Loading

adonesky1 Sep 26, 2024 •

edited

Loading

adonesky1 Nov 13, 2024 •

edited

Loading

adonesky1 Nov 14, 2024 •

edited

Loading