---
# System prepended metadata

title: Untitled

---

Solving the multi-resolver issue

## Technical
> Why did you build Multi Resolver Snap?


The user experience in web3 has long been overlooked. One area in which we see progress is account abstraction. It feels like there is a new naming service almost every week. The goal of these is to simplify the way we interact with each other in this space: names are more recognizable than wallet addresses and therefore build a base layer for identity and reputation systems. Additionally, original  (naming) standards can benefit the popularity of projects. For example, let us call a project “x”. The new naming standard this project proposes could be called x-domains or x-names. Success in the project would automatically help grow the naming service, while success in the naming service would do the same for the project - a win-win. Now, we are left with a fragmented picture of the namespace. Sure, there are people that try to use every naming service, which results in a race around names in the limited namespace we have in some (domain-based) naming services. Other naming services use more familiar handles, like emails, phone numbers, or more general social handles (Twitter username, IG handle) that people already possess, to eliminate potential markets around these identities.
Most people end up with one, maybe two handles from different naming services. Because of the variety of choices, developers need to integrate multiple naming service resolvers into their applications. When a new naming service takes over a sizable percentage of the market, it should also be integrated into one’s application as to not exclude users of that naming service. From the user’s perspective, searching for alternative applications with similar functionality that also support the naming service of their choice is annoying. Why not let people use whatever they are familiar with AND provide a solution that helps developers focus on creating the best application possible?
The Multi Resolver Snap does exactly that.

>Put your walkthrough video
>
https://youtu.be/4-MF76pOw1Y

> Can you walk us through the technical implementation?


### The gist
The snap was built for [Metamask Flask 10.20](https://github.com/MetaMask/snaps-monorepo/discussions/821#top). The current version uses the permissions `endowment:network-access` and `snap_confirm`. The first is used in a [preliminary version](https://github.com/idriss-crypto/multiresolver) to request resolved addresses and translate Twitter IDs to Twitter usernames. The latter shows a confirmation screen to the user highlighting the resulting address before a transaction is created.
Currently supported resolvers are IDriss and ENS. The Snap runs on localhost.
### Integration from dApp side
For a developer to integrate this Snap, and therefore all available resolvers, one must connect to a wallet and the Snap first:
```typescript
const connectSnap = async (
  snapId: string = defaultSnapOrigin,
  params: Record<'version' | string, unknown> = {},
) => {
  await window.ethereum.request({
    method: 'wallet_enable',
    params: [
      {
        wallet_snap: {
          [snapId]: {
            ...params,
          },
        },
      },
    ],
  });
};
```
Invoking happens through the method `resolve_send` and can be called through
```javascript
const resolveInput = async (id_?: string) => {
  return await window.ethereum.request({
    method: 'wallet_invokeSnap',
    params: [
      defaultSnapOrigin,
      {
        method: 'resolve_send',
        identifier: id_,
      },
    ],
  });
};
```
which returns the resolved address. Here, `id_` is the identifier that the user inputs into a sending field.
Using the new `multiChainProvider`, connecting to the snap is as simple as connecting to the wallet with the required permissions:
```javascript
import { MultiChainProvider } from "@metamask/multichain-provider";

const provider = new MultiChainProvider();
const { approval } = await provider.connect({
  requiredNamespaces: {
    eip155: {
      chains: [chains],
      methods: [
        permissions
      ],
    },
  },
});
const session = await approval();
```
The above-mentioned `resolve_send`  method can be renamed to `eth_sendTransaction`, allowing apps to use the Multi Resolver Snap without needing to change any integrations. Whenever `eth_sendTransaction` is called, the Snap is interposed and resolves the input before creating the transaction. Applications should allow for inputs of type `String` instead of throwing an error whenever an user input does not match an address. The Snap then takes care of the rest!

>What are the next steps if you would implement this?

As a next step, this Snap will be taken [open-source](https://github.com/idriss-crypto/multiresolver) to encourage other developers to hunt for bugs, improve the code, and even add their custom resolvers. Open-sourcing will unlock the true potential of this Snap: not a single developer or entity has to integrate all emerging naming services. A `contribute.md` file promotes this process. Additionally, further development from the MetaMask Snaps team will be tracked. 
Precicely, two specific things greatly benefit this Snap:
1. The `endowment:transaction-insight` permission for account-to-account transfers to remove the additional `snap_confirm` call before a transaction is triggered, and
2. UI injections into MetaMask. The goal is to implement the Snap into the sending field so users can utilize the Multi Resolver without connecting to a website.

Finally, a complete integration with the [IDriss resolver](https://github.com/idriss-crypto/ts-library) is sought. Full integration allows users to send crypto and NFTs to any email, phone number, and Twitter username without needing to be registered in the IDriss book. 

## Personal
>Can you tell us a little bit about yourself and your team?

My name is Lennard, and I have been interested in the blockchain space since 2017. For over a year, I have been building and co-founding [IDriss](https://www.idriss.xyz/), a decentralized mapping of emails, phone numbers, and Twitter usernames to wallet addresses. More generally, I focus on building tools toward a more usable web3, which motivated me to build this Snap. 


>When were you first introduced to MetaMask Snaps and what was your experience like?

The Snaps team is very present at conferences this year, so I have been running into them a couple of times now. The first time I interacted with the code base was after one of their presentations at EthCC 2022 in Paris. While the features were still limited, the documentation was already promising, and I am very hopeful for the future of Snaps.

>What makes MetaMask Snaps different from other wallets?

I have not seen a similar approach to including outside contributors in the development of wallets yet. While some other wallets have open-sourced their code, Snaps enable developers to expand the functionality of MetaMask directly. I am sure this approach will be adopted by other projects as well, as it can be better maintained.

>Tell us about what building Snaps with MetaMask is like for you and your team?

It was a great opportunity to build this Snap during a hackathon. Having the Snaps team around helped whenever questions came up. One thing that is still missing is the ability to customize MetaMask's UI. Additionally, some dependency issues are hard to debug, which takes over most of the development time.


>What does Snaps mean to you?

Snaps provide a playground for developers to integrate their projects or ideas directly into MetaMask in a permissionless way. For me, this means that the growth of any project can be accelerated, as users can suddenly enjoy more benefits using the tools (wallets) they already own.

>What opportunities do you see with MetaMask Snaps and the possibilities it unlocks for the Web3 space?

Snaps can help prevent scams through transaction insights, create a more network-inclusive experience with keyrings, and allow for a more user-friendly web3 experience using custom resolvers paired with UI enhancements. Together, this will bring more people into the space.


>Any advice you would like to share with developers keen to try MetaMask Snaps?

Go to hackathons! It is the best way to interact with the team directly and get instant feedback.


