Multi-App & Permissions

In crypto, users often need to access the same wallet across different applications. Let's say a wallet is accessible to to three applications A, B, and C. If a user trusts these applications, there are no challenges on the surface. However, if application C becomes compromised, so does the user's wallet in its entirety. This, among other related challenges with wallet portability and trust assumptions, are a common cause of attacks.

Capsule mitigates this by allowing the same embedded wallet to be accessed across applications. Capsule leverages a permissions scheme that specifies what types of transactions an application can do and which ones require a user's approval.

For example, one application may have the permission to sign certain messages, while another might be allowed to do swaps with certain smart contracts. This ensures that even in a shared access environment, the user's assets remain safe, and the application's ability to transact in-context is preserved within their desired scope. Check out some more examples of permission schemes in our blog post.

How it Works

Account Creation: Choosing Existing Wallet

During the account creation process, users are presented with the option to either create a new wallet or use an existing one. When redirected to the Capsule Portal, users can see the set of permissions that the new app will require. Once these permissions are approved, the new app can sign with the encrypted device key (k1) for the duration of the user session.

Connecting a New App to an Existing Wallet

The process of creating a new wallet and connecting to an existing one is quite similar from the application developer's perspective. Once users verify their email, they're presented with a list of existing wallets and the permissions that the application will require.

After the user makes a selection, the client encrypts the private key (k1) with the new app's key and sends it, along with the app's public key, to Capsule. This process also includes a signature generated using the portal enclave key for authorization purposes.

Capsule then adds the new app's public key to its allow-list. This step is crucial as it grants the new app the necessary permissions to interact with the wallet.

Upon being redirected back to the application, the client requests the account from Capsule to receive the encrypted k1 private key and the account public key. The client then decrypts the k1 key using the enclave-based app key and securely stores the k1 private key in the KeyChain.

This process allows Capsule wallets to be securely and efficiently used across multiple applications, while ensuring protection of user assets and data.