Skip to main content

Meemaw: how does it work?

info

If you're not yet familiar with MPC wallets and TSS, we suggest you read our blog post on the subject first.

Meemaw is a wallet as a service, which means that it allows you as an developer to deploy a trustless wallet for each of your user. Those wallets are trustless because they are MPC wallets using TSS.

This page goes into more details about how Meemaw actually implements those MPC wallets, as a service.

Components of a Meemaw installation​

Meemaw can be understood as a set of 3 main components :

  • Server: the server runs on your backend (self-hosting) or on our servers (cloud). It generates and stores the server-side TSS shares of the wallets and manages the TSS process from the server side. It also checks if your users are who they say they are, and only lets them access their own wallets.
  • Client SDK: in order to manage the client-side TSS shares of your users' wallets, you can use Meemaw's client SDKs for each platform. It generates and stores the shares on the device and manages the TSS process from the client side. It also makes it easy to sign messages and transactions on Ethereum and other EVM blockchains.
  • Auth provider: Meemaw purposefully does not provide an auth provider. Instead, it makes it easy to plug your own. Whether you use a custom auth system or use a third-party one, you will be able to link it to your Meemaw setup. For some third-party providers, it's as simple as providing your API key.

In order to get started, you need to run each of these components. Don't worry, it's super easy 👌

What happens behind the scenes?​

During normal operations, the TSS process happens between the server and the device used by the user, thanks to the client SDK. The server communicates with the Auth provider to authenticate the user.

When the wallet gets created (DKG), the server confirms with the Auth provider that the user is who he says he is. Then the server and the device work in concert through the TSS process to generate separate shares. There is no "complete" wallet private key that ever appears on either side. The shares get stored separately, one in the server database, one in the client storage.

When a transaction needs to be signed (SIGN), the server confirms again with the Auth provider that the user is who he says he is. Then the server and the device work in concert through the TSS process to iteratively sign the transaction using their shares. Again, there is no "complete" wallet private key that ever appears on either side. The transaction ends up being fully signed and ready to be broadcast to the blockchain.

Meemaw requires 2 signatures out of N shares to send funds. There will always be at least a server share and a client share. On top of that, the user can add other devices or generate a backup, which will create additional shares. Those shares can be used in different ways depending on the use case:

Other flows​

Add device​

Meemaw allows you to add additional devices. This creates redundancy. If the user loses access to one device, he can use another one. Similarly, if the server loses all its data, the user can recover his wallet based on two devices. Read more

Backup​

Another way to add shares is to download a backup file. This allows the user to recover his wallet based on that backup file and the server share, even if the user loses access to all his devices. If the server loses all its data, the user can recover his wallet based on the backup file and another device. Read more

Technical implementation​

Meemaw does not reinvent the wheel. It uses battle tested technologies for all critical components.

The technical implementation of Meemaw revolves around a few elements:

Go library​

Meemaw uses a central Go library, based on the audited Alice implementation of TSS for all MPC operations.

The library is used in multiple parts of the project, leading to a few releases:

  • server: running on your backend or on our cloud
  • wasm: used by the Web SDK, running in Web browsers
  • mobile libraries: used by the Swift and Android packages

Websocket​

For now, the transport layer for TSS operations is Websockets. A secure connection is established between the client and the server, allowing for TSS processes to happen.

Storage​

The DKG process of the TSS protocol generates multiple keys (or shares) that need to be stored by each participant. Here is how those keys are stored:

  • iOS: storage on iOS devices uses the Secure Enclave of the device
  • Web: storage on Web browsers uses localstorage - this will need to be improved
  • Android (to be implemented): storage on Android devices uses the Trusted Execution Environment of the device