How to Build an MPC AA Wallet for Social Recovery

Why combine MPC and account abstraction

Traditional wallets force a trade-off: you either manage a single private key (high security, high risk of loss) or rely on a custodian (easy recovery, but you don’t hold the keys). Combining Multi-Party Computation (MPC) with Account Abstraction (AA) removes this binary choice. MPC handles the cryptography, while AA handles the user interface and logic.

MPC splits the private key into multiple "shares" using secret sharing schemes like Shamir’s Secret Sharing. No single device or server ever holds the full key. Instead, signature generation requires a cooperative computation between these shares [src-serp-2]. This eliminates the single point of failure inherent in traditional hot wallets [src-serp-4].

Account Abstraction, defined by ERC-4337, decouples the wallet from the blockchain’s native account model. It allows smart contracts to act as wallets, enabling custom validation logic, session keys, and gas sponsorship. Crucially, it introduces social recovery mechanisms that MPC alone cannot provide.

When you build an MPC AA wallet, you are essentially building a smart contract wallet that uses MPC for signing. The smart contract (AA) defines the rules for recovery—who can verify your identity and under what conditions. The MPC engine executes the signatures required to enforce those rules. This means you can recover your wallet via a social graph of guardians without ever exposing the private key, even to the recovery agents themselves.

Step 1: Choose your AA smart contract standard

The first technical decision is selecting the execution environment that will host your MPC signature verification logic. Account Abstraction (AA) provides a standardized interface for smart contract wallets, allowing you to bypass the traditional Externally Owned Account (EOA) model. This choice determines how your wallet interacts with the blockchain, handles gas fees, and processes transactions.

Select the ERC-4337 compatible module

ERC-4337 is the current industry standard for Account Abstraction. It decouples the transaction lifecycle from the blockchain's base layer by introducing a mempool for user operations. This allows your MPC wallet to batch transactions, sponsor gas fees, and implement custom validation logic without requiring a hard fork of the underlying chain. Most modern AA implementations rely on this standard to ensure compatibility with existing bundlers and paymasters.

Verify signature verification logic

Your smart contract must efficiently verify the MPC-generated signature before executing the user operation. Since ERC-4337 uses a UserOperation struct, your contract needs a robust validateUserOp function. This function checks the signature against the MPC public key shares and ensures the transaction meets your specific security policies. Efficiency here is critical; complex cryptographic checks can exceed block gas limits, so optimize your verification logic to fit within standard constraints.

Deploy factory contract

To manage multiple wallet instances, deploy a factory contract that creates new wallet accounts on demand. This factory acts as the entry point for wallet initialization, storing the MPC public key and any custom configuration parameters. By using a factory, you avoid redeploying the base wallet logic for every user, significantly reducing deployment costs and ensuring consistent behavior across your entire user base.

Select ERC-4337 compatible module

Choose ERC-4337 as the underlying standard to leverage existing bundler infrastructure and gas sponsorship mechanisms. This standard allows your MPC wallet to function as a smart contract, enabling custom validation logic and batch transactions without altering the blockchain protocol.

Verify signature verification logic

Implement a gas-efficient validateUserOp function in your smart contract. This function must verify the MPC-generated signature against the user's public key and ensure the transaction meets your specific security policies before allowing execution.

Deploy factory contract

Deploy a factory contract to manage the creation of new wallet instances. This approach reduces deployment costs by reusing the base wallet logic and ensures consistent configuration across all user accounts initialized with your MPC infrastructure.

Configure MPC key generation and sharding

Before the wallet can sign transactions, you must initialize the Multi-Party Computation (MPC) protocol. This process generates a single private key that is split into multiple "shards" distributed across different devices and guardian nodes. Unlike traditional wallets where a private key exists as a single file, MPC eliminates this single point of failure by ensuring no single party ever holds the complete key [src-serp-8].

Follow this sequence to set up the key generation protocol:

Define the threshold and shard count

Determine how many shards are needed and how many are required to sign a transaction. A common configuration for social recovery is a "2-of-3" or "2-of-4" threshold. For example, if you use three guardians (friends or devices) plus your phone, you might require two signatures to approve any action. This balance ensures that losing one device doesn't lock you out, while requiring two prevents a compromised device from draining funds. Consult the Fireblocks MPC 101 guide for details on how threshold signatures work in practice.

Initialize the secure multiparty computation session

Your application must launch a secure MPC session to begin the key generation. This step involves cryptographic handshake protocols between all participating nodes (your user device and the guardian nodes). During this phase, the nodes exchange public commitments but keep their secret inputs hidden. The session establishes the mathematical framework for Shamir's Secret Sharing, which will be used to divide the key. Ensure all network connections are encrypted and authenticated before proceeding to the actual key material generation.

Generate and distribute key shards

The MPC protocol now runs to generate the shards. Instead of generating a key and splitting it, MPC generates the shards simultaneously in a way that guarantees they form a valid key when combined. Each participant receives their specific shard. Your user device typically keeps one shard, while the remaining shards are distributed to the designated guardian nodes or social contacts. Verify that each shard is stored securely in the respective secure enclaves or encrypted storage locations.

Verify shard integrity and wallet readiness

Once the shards are distributed, perform a verification step to ensure the system is ready. This often involves a non-custodial test transaction or a signature challenge. The user device combines its shard with one guardian's shard to produce a valid signature for a dummy transaction. If the signature validates against the public key, the MPC wallet is successfully configured and ready for production use. This step confirms that the sharding logic is sound and that the guardians can actually participate in the signing process.

With the key shards generated and distributed, your MPC AA wallet is structurally ready. The next step is to implement the social recovery logic that allows users to replace lost shards.

Social recovery transforms your MPC wallet from a single point of failure into a resilient network. Instead of relying on one secret, you delegate partial signing authority to trusted contacts. This section details how to configure the recovery module within your Account Abstraction (AA) contract to enforce these rules.

Select your guardians

Choose 3 to 7 individuals who will act as guardians. These should be people you trust implicitly and who are likely to remain accessible. The ERC-4337 standard allows you to assign specific weights to each guardian, but a simple majority (e.g., 2 out of 3) is the most common and secure starting point.

Verify and register addresses

Add each guardian’s Ethereum address to the recovery module. Because these addresses control partial key shares, accuracy is critical. Double-check the addresses before committing them to the smart contract. A typo here could lock your assets permanently if the primary key is lost.

Set the recovery threshold

Define how many guardians must sign to recover the wallet. A threshold of 2 out of 3 balances convenience with security. If you add more guardians, such as 5 out of 7, you increase redundancy but make the recovery process more cumbersome. Adjust this based on how frequently you expect to use recovery.

Choose trusted contacts who are active and reachable.
Verify each guardian’s wallet address before adding them.
Set a recovery threshold (e.g., 2 of 3) that balances security and ease.

This configuration links the guardian addresses directly to the AA contract’s execute function. When you need to recover access, the guardians will sign a recovery payload that the contract validates against your pre-set threshold. This ensures that no single person can hijack your wallet, while still allowing you to regain access if you lose your device.

Test gasless transactions and signing

Before deploying your MPC AA wallet to production, you must verify that the smart contract correctly interprets the multi-party signature and that the gas abstraction layer functions as intended. This phase confirms that the user experience remains seamless: the user signs locally, the account pays fees via a Paymaster, and the chain validates the result.

Verify the MPC signature against the AA contract

The core logic of an Account Abstraction (AA) wallet is its ability to validate signatures outside the standard EOA flow. You need to confirm that your contract correctly reconstructs the signature from the MPC shares and accepts it as valid.

Construct the unsigned transaction: Prepare a standard EIP-1559 transaction object (to, value, data, gas limits) using your test RPC endpoint.
Generate the MPC signature: Send the transaction hash to your MPC node or key management service. Ensure it returns a valid signature (typically r, s, and v values, or a compressed ECDSA signature).
Submit via eth_sendRawTransaction: Pass the transaction along with the signature to the execute or executeBatch function of your AA contract.
Check the receipt: Use a block explorer to verify the transaction was mined. If the signature is incorrect, the contract should revert with a specific error (e.g., InvalidSignature), not a generic gas error.

Confirm Paymaster gas coverage

A defining feature of AA wallets is the ability to sponsor gas fees. You must ensure that the Paymaster contract correctly accepts the transaction and deducts fees from the user's allowance or the sponsor's balance.

Add Paymaster parameters: Extend your transaction object with the paymaster and paymasterInput fields required by your specific Paymaster implementation (ERC-4337 compliant).
Run a test transaction: Send the signed transaction to the bundler (e.g., Pimlico or Alchemy) or directly to the EntryPoint contract if you are running a local node.
Verify fee payment: Check the event logs for the UserOperationEvent. Look for the actualGasCost field and ensure it was covered by the Paymaster. If the user's token balance is insufficient, the Paymaster should either reject the operation or charge the sponsor, depending on your configuration.

Handle edge cases and reverts

Testing should not only cover happy paths. You must verify how the wallet behaves when signatures expire, when the Paymaster runs out of funds, or when the user attempts to call a restricted function.

Signature expiration: Set a short validity period for your MPC signatures (e.g., 60 seconds) and test that the contract rejects stale signatures.
Insufficient Paymaster balance: Drain the Paymaster's token balance and attempt a transaction. The bundler should return a clear error indicating the Paymaster cannot cover the fees.
Invalid function calls: Ensure the AA contract rejects calls to functions it is not authorized to execute, preventing accidental asset loss.

Common questions about MPC AA wallets

Users building or selecting a Multi-Party Computation (MPC) Account Abstraction wallet often ask how the underlying key management differs from traditional setups and what that means for recovery and compatibility. The core distinction lies in how the private key is handled: rather than a single secret stored on one device, MPC splits the key into mathematical shards distributed across multiple parties.

How does an MPC wallet work?

MPC wallets rely on secret sharing schemes, most commonly Shamir's Secret Sharing, to divide a private key into multiple shares. These shares are distributed to independent devices, servers, or parties. No single entity holds the complete private key. When a transaction needs signing, the parties collaborate to generate a valid signature without ever reconstructing the full key. This eliminates the "single point of failure" inherent in traditional wallets where a compromised key file means lost assets.

What is the difference between MPC and non-MPC wallets?

In a non-MPC wallet, the private key exists as a single file or string of text. If that file is stolen or the device is lost without a backup, the assets are inaccessible. MPC technology removes this vulnerability by breaking the key into fragments. Even if one shard is compromised, the attacker cannot sign transactions or access funds without the other required shards. This makes MPC wallets significantly more resilient to theft and loss than standard non-custodial setups.

Is Coinbase Wallet an MPC wallet?

Coinbase's Wallet as a Service (WaaS) infrastructure uses MPC for generating signatures on transactions. In this model, the key is secret-shared between the end user and Coinbase. This allows companies to build customizable wallets that benefit from MPC security while leveraging Coinbase's infrastructure. However, standard consumer-facing Coinbase Wallet apps may operate differently depending on the specific product line, so it is important to verify whether a specific wallet implementation uses MPC or traditional key storage.

How to create an MPC wallet?

Creating an MPC wallet typically involves a structured setup process through a provider's portal. For example, using Cobo Portal, you would log in, navigate to the Wallets section, and select MPC Wallets. You then choose a vault, click Create Wallet, name your wallet, and confirm. The process ensures that key shards are securely distributed to the designated parties before the wallet becomes active.