# Let's reduce key loss with multi-factor keys (MPC) via MM Snaps | Bogota Hack

Its every other day that you hear stories of keys being lost, or accounts being drained because seed phrases were stolen.

This results in:
- Non-custodiality not being as popular/prevalent
- Backlash towards the web3 community in general
- Low adoption and fear amongst less tech saavy participants
- More people being on CEXs, so FTX is able to rug a bunch of people...

If we assume:
- On [Metamask's 40 million MAUs ](https://decrypt.co/95039/metamask-consensys-30-million-users#:~:text=Crypto%20software%20giant%20ConsenSys%20announced,30%20million%20monthly%20active%20users.)
- Average user has maybe $50 usd on their account
- If even 0.05% of users lose their account per month
- You're looking at 0.05% * 40 * 50 = 1.0M a month
- and worse, these users are likely to NEVER come back to web3

Enterprises have been keeping billions on different custody solutions, and the current golden standard for it is Multi-Party Computation.

Lets democratize MPC for everyone!

## Introducing Multi-Factor Keys(MPC) on MM snaps

*Onboarding flow for a user with multi-factor keys*

Build link: https://github.com/Web3Auth/openlogin-snap/

### So what's happening here?

The new snaps build of MM allows for an execution context inside of MM to securly run. With the [SIPs-2 proposal](https://github.com/MetaMask/SIPs/blob/main/SIPS/sip-2.md) fantastically implemented by @ritave, that has recently given access to multiple account types.

We used this with Web3Auth's MPC SDK to allow new users to setup keys. MPC works just like how a multi-factor account would today, we split a users key where a threhold number of factors would be required to sign signatures.

### Lets walk through the user setup

And whats happening behind the scenes:
1. User is setting up an account on MM, they first visit the Snaps site and click on login.
2. The user is going to setup a 2/3 (threshold 2, 3 factors - A B and C) on MM
3. The first factor A is setup with a typical user name and password
4. The second factor B is saved on metamask, with metamask's encrypt store API.
5. A third factor, C, is managed by the user

### Typical daily usage

*Looks the same huh? Cause it is\*!*

The user logs in with thier password access to factor A, chrome extension has factor B, and thus we can sign transactions.

**or it can be with an embedded UI hook on login via Snaps*

### Methods to backup factor C

**Standard pen & paper backup**


As you'd expect, your standard pen & paper backup

**Adding another device - Metamask mobile!**

Works just like an new device login with Apple or a Google account

1. First we start the process on the extension.
2. Then download mm mobile
3. Login with your multi-factor key account that you setup
4. Scan the QR code (or confirm the notification on extension)
5. Confirm the request, and you're done

------

### More on why this is awesome

- Always non custodial, only one factor ever lives in custody
- Intuitive to end users, users understand MFA and are used to it
- Phishing is eradicated, accidently putting your seed phrase in a site is now ONLY one factor
- Policies can be built on the server side to further secure users, black listing scam transactions/Metamask Transaction Insights(Snaps) , daily limits, so on and so forth
- For "high" security users, you can increase the threshold for signing to 3 factors. A flow thats basically extension, mm mobile to be used to sign - similar to a bank with OTPs

## Our experience and requests from Snaps

- We definitely need SIPs-2! Again @ritave, thanks for implementing the spec so far. Would love to chat about additional permissions/restrictions that we're thinking about to handle requests
- Webpack support, mm-snaps build uses browserify which has issues with some packages
- Spooky issues with mixed argument types in wasm (bug)
- Chrome Identity API / Firefox Web Authentication API for OAuth login from the extension
- Support for Socket.io, or at least a patch for XMLHttpRequest on socket.io-client
- Sockets do not pass event data (bug)
- Mobile Snaps Support for the 2nd device
- Hook on login UI for snaps for discovery for new users / Home page for snaps

And better docs for endowment:keyring would be nice haha..

## Thoughts with respect to Smart Contract Wallets/Abstraction and MPC

We think that SCWs provide an unparalleled computational flexibility and custom logic to accounts. This results in:
- Gas abstraction
- Limits, timelocks and other policies
- Onchain IAM/Multi-sigs
- Session keys
- Other usecases!

They're definitely the long term game, and in this vision, where does MPC fit in?

In the short term, assuming that account abstraction is not yet on the protocol level for most chains, MPC can help with:

1. With MPC, the multi-factor setup is done once across different chains - 1 account on all L2s. For SCWs, we'd need to deploy and maintain separate setups on each L2 or mainnet. It's a complex UI/UX and infra hurdle to work through, especially with different VMs and account abstraction implementations on different chains.
2. Works great as an EOA to SCWs in a gas abstracted setup and/or session keys
3. IAM's/multi-factor setups don't cost gas to deploy or to run as they're off-chain

Once account abstraction is implemented on the protocol level, it will nothing to deploy a SCW, which removes 3. However, 1. will still be a problem and having a personal IAM setup that follows the user across different L2s is valuable as it reduces user friction.

SCWs are definitely the way to go in the long-term, and MPC has complementary properties to SCWs that are valuable to the end user.

## Links references and screens

Build link: https://github.com/Web3Auth/openlogin-snap/
Screens & flows (Initial): https://www.figma.com/file/tJ5t4MgsPymIGOzs2purxI/Metamask-(MPC)?node-id=1072%3A566