The 10,000-Account Problem: The Realities of Building Onchain with MPC and AA Today

This post is not meant to be an introduction to these concepts, rather a deeper look at the current state of affairs with the needs of developers in mind. If you want a primer, check out this MPC Intro and this Account Abstraction resource.

The Evolution of Embedded Wallets

The rapidly evolving embedded wallet space has significantly improved user experience for both users and developers, completely improving the onboarding process for newcomers. Today, embedded wallets provide seamless onboarding, allowing users to access crypto apps without needing to manage private keys directly.

As embedded wallets scale, distinguishing between authentication and authorization becomes essential. Technologies like MPC and Shamir Secret Sharing have come into the focus as the primary technology embedded wallets use to make their underlying wallet infrastructure more secure and resistant to hacks.

Many apps have adopted embedded wallets, increasing the prevalence of MPC wallets and their onchain complement, account abstraction (AA) wallets.

Despite significant advancements, new UX tools can create security gaps and confusion about how to use these tools effectively together. A recent wallet-as-a-service exploit underscored the importance of secure practices for generating, storing, and signing with embedded wallet signers

The Core Issues: Association and Fragmentation

The core issues fall into 2 main themes: association and fragmentation. Let's get into it.

1. Signer Association

The absence of a standardized association mechanism between AA wallets and MPC signers has resulted in several challenges. Currently, there's no reliable way to determine whether an AA wallet is already paired with an MPC signer—or vice versa—before integration.

From the start, this uncertainty forces developers to decide upfront whether the AA wallet or the MPC signer should serve as the user's primary wallet, leading to inconsistent implementation across platforms.

A lack of clear direction means developers often resort to workarounds such as obscuring wallet addresses or choosing which ‘account’ address to display to the user as their wallet and associated public key. When developers must resort to these user experience trade-offs, the security and usability of the application suffers.

Fragmented Signers

Account abstraction aims to improve wallet user experience, but its adoption has been hampered by embedded wallet walled gardens.

One key challenge is the variation in how embedded wallets are implemented. For example, some providers issue one new embedded key for each application a user interacts with, creating silo’d embedded wallets. Others (like Para), enable universal embedded wallets where the same wallet can be reused everywhere. App-specific embedded wallets per app vs. a universal embedded wallet for every app strongly influences UX.

Security is another major implementation concern, as developers can struggle with multi-signer management. Some developers simply add multiple owners to an account, which necessitates complex permission systems or forces an all-or-nothing approach to access management.

2.The (re)Discovery Problem

When users are confronted with a cluttered interface filled with multiple wallet choices (especially multiple wallets from multiple apps), the process of identifying and selecting the right wallet becomes overwhelming. With smart accounts and silo’d embedded wallets, this problem is exacerbated.

Many users end up with separate smart accounts for each application due to inadequate rediscovery mechanisms. Smart accounts created with one provider may not be compatible with those generated using another.

3. On and Offchain Permissions

Permissions are tough, and interfaces are challenging to get right for every type of use case. Thankfully, we can blend both onchain, and offchain permissions seamlessly into a unified experience.

ERC-7715 offers a unique to have wallets sign overtop of permissions, granting other keys (not just ECDSA 👀) to have the ability to sign on-behalf of an account. Effectively, 7715 resembles a JWT token. Users sign off on what an application can do with their account, all offchain, then the app co-signs every action against the JWT which is enforced onchain. This pattern is beautiful because it resembles what developers are used to (JWTs!) with the security that you expect from self-custody. Applications specific permissions, that are verifiable onchain.

However, not all permissions make sense to encode onchain – driving demand for offchain policy and permissioning systems.

Offchain permissions bring the convenience of multi-chain scalability, privacy, and easy upgradeability – however, they are very difficult to enforce in most traditional models. Put simply, any EOA wallet that has a permission layer requires intensive trust, as gaining possession of the private key (if held in a browser or enclave) is sufficient to bypass any permission controls that may be implemented.

This is where Distributed MPC comes in. Because keyshares are never recombined, there is a clear layer at which to enforce permissions. Further, proactive refreshing enables differentiated key shards per-app - reducing the risk of least-common-denominator app compromise.

These two innovations give rise to cross-chain and cross-app signers, all while keeping transparent guarantees signing access and minimizing key access.

4. Cross-Chain Compatibility

The challenges of fragmentation are further amplified when considering cross-chain compatibility. Users often forget to deploy their wallets across multiple chains, leading to discrepancies in smart contract wallet addresses.

Additionally, there is no guarantee that the same signers will be available on every chain because CREATE2 is not fully future-proof, making it difficult to maintain a consistent cross-chain experience. If an application does not exist on both chains and the signer is scoped to a specific domain, users may find themselves at an impasse with no clear solution for accessing their funds across chains.

While AA may offer a seamless wallet experience on one blockchain, the requirements and constraints of another chain’s VM can require significant modifications or even result in incompatibility.

To mitigate this, most teams need to adopt an MPC cross-chain signer + AA per-chain structure which can be difficult to manage (see Section 1). The story isn’t over at signing. To make the experience go the extra mile when building cross-chain, or even intent based applications, you need a solver. With all the components we’ve described above, providing clean delegation to a solver on your behalf (safely), enables beautiful UX for everyone.

The End Game

Making a decision today is still incredibly difficult. We’ve found that developers can get around these nuances by establishing using:

• A universal (cross-app, cross-chain, and fully portable) embedded wallet as an MPC signer that can be associated with account abstracted wallets on different chains/L2s
• The MPC signer as the canonical cross-chain public address for the user to limit funds loss

The ideal end game will need to look like:

• A universal way to associate AA wallets with MPC signers. This should solve the signer problem, x-chain problem, and discovery
• Better standardization across AA specs per chain per VMs

We’re excited to work together towards a unified approach to UX. Head over to our docs to get started with Para today. If you’re committed to reducing fragmentation, we’d love to chat!

About our Authors: Greg is the Founder of Chainsafe and Sprinter. Nitya is the Founder of Para.