Build an MPC AA Wallet: A Developer’s Guide to Secure Custody

Why combine MPC and account abstraction

MPC and account abstraction (AA) are often framed as rivals: one prioritizes security, the other user experience. In practice, they are complementary. Merging them creates a wallet that is both programmable and secure enough for team-based custody.

MPC handles key security by splitting keys across multiple nodes, ensuring no single point of failure. AA handles the user experience and smart contract logic, enabling features like social recovery and gas sponsorship.

This combination solves the "custody vs. control" dilemma. Developers can build wallets that allow multi-signature approvals without sacrificing the seamless interaction users expect from modern dApps. The result is a secure, programmable wallet that scales with your team's needs.

Choose your cryptographic protocol

The first technical decision in building an MPC AA wallet is selecting the underlying cryptographic protocol and the threshold scheme. This choice dictates how private keys are split and how signatures are generated. Unlike traditional wallets that store a single private key, MPC wallets use secret sharing schemes to divide the key into multiple shards distributed among different parties [src-serp-8].

Select the threshold (k-of-n)

Define your threshold by deciding how many parties must collaborate to sign a transaction. A common setup is 2-of-3 or 3-of-5, where k is the minimum number of shards required and n is the total number of shards. This threshold balances security with availability. If you require high availability, a lower threshold allows faster signing even if some nodes are offline. However, a higher threshold increases security by requiring more consensus, reducing the risk of a single compromised node signing malicious transactions.

Pick the protocol: TSS vs. FROST

Two protocols dominate the MPC landscape today: Threshold Signature Schemes (TSS) and Flexible Round-Optimized Schnorr Thresholds (FROST).

• TSS (Threshold Signature Schemes): TSS is the most widely adopted protocol for MPC wallets. It allows multiple parties to jointly generate a signature without ever reconstructing the secret. TSS is robust and well-supported by most cryptographic libraries, making it the standard choice for general-purpose custody solutions [src-serp-6].
• FROST (Flexible Round-Optimized Schnorr Thresholds): FROST is a newer protocol that optimizes Schnorr signatures for threshold settings. It offers advantages in bandwidth efficiency and supports batch verification, which can reduce transaction costs on-chain. If your AA wallet requires high throughput or operates on networks that support Schnorr signatures (like Bitcoin Taproot or Ethereum), FROST may be the more efficient choice.

Evaluate risk tolerance

Your protocol choice should align with your team's risk tolerance. TSS provides a mature, battle-tested framework with extensive tooling. FROST offers performance benefits but requires careful implementation to avoid side-channel vulnerabilities. For most developer teams building an MPC AA wallet, starting with TSS provides a solid foundation, while FROST is recommended for specialized use cases where signature efficiency is critical.

Implement distributed key generation

Distributed Key Generation (DKG) is the cryptographic foundation of your MPC AA wallet. Unlike traditional key generation where a single random number creates a private key, DKG ensures that no single party ever sees the complete secret. The private key is mathematically split into shards, with each shard held by a different participant or node.

This process establishes a trustless setup. Even if one node is compromised or acts maliciously, the attacker cannot reconstruct the secret or sign transactions on their own. For developers building wallet-as-a-service infrastructure, implementing a robust DKG protocol is the critical first step in securing user assets [[src-serp-3]].

1

1. Initialize cryptographic parameters

Define the threshold scheme (t, n) where t is the minimum number of shards needed to sign, and n is the total number of participants. Generate a shared public modulus and ensure all nodes agree on the cryptographic group parameters before any data exchange begins.

2

2. Generate local key shards

Each participant independently generates a random polynomial. Using Shamir’s Secret Sharing, they derive their own private shard from this polynomial. At this stage, the shard is local and secret; it is never transmitted to other nodes.

3

3. Exchange commitment hashes

To prevent malicious actors from submitting invalid shards, each node broadcasts a hash commitment of their polynomial coefficients. This creates a verifiable audit trail. Nodes verify the integrity of incoming commitments before proceeding to the next phase.

4

4. Reconstruct the public key

Participants exchange their actual shard values. Each node uses the received shards to reconstruct the public key. Since the underlying polynomial is consistent across all honest nodes, they all arrive at the same global public key without ever seeing each other's private shards.

Previous

1234

Next

Once DKG completes, the resulting public key is deployed on-chain as the wallet address. The private key remains fragmented across the network. When a transaction is initiated, the AA smart contract coordinates the partial signatures from the required t nodes to produce a valid signature, maintaining the security guarantees established during generation.

Design the transaction signing flow

The signing flow is where the MPC architecture meets Account Abstraction (AA). Instead of a single private key signing a transaction, the process relies on collaborative computation. The user initiates a transaction, the AA smart contract validates it against custom rules, the MPC nodes generate signature shards, and those shards are aggregated into a valid signature before submission to the blockchain.

This sequence ensures that no single party ever sees the secret. The AA contract acts as the gatekeeper, enforcing policies like spending limits or time locks before the signing process even begins.

1

User initiates transaction

The process starts when the user creates a transaction via the frontend. The transaction data is passed to the AA smart contract on-chain. The contract first checks if the transaction complies with the configured policy rules, such as daily limits or allowed recipient addresses. If validation fails, the transaction is rejected immediately without involving the MPC nodes.

2

MPC nodes generate signature shards

Once the AA contract approves the transaction, it triggers the signing process. The MPC nodes, which hold the secret shares of the private key, begin a distributed computation. Each node calculates its own signature shard using its portion of the key and the transaction hash. This step is computationally intensive and requires secure communication between nodes to prevent tampering.

3

Aggregate shards and submit

The signature shards are collected and aggregated into a single, valid ECDSA or BLS signature. This aggregated signature is then passed back to the AA contract. The contract verifies the signature against the user’s public key. If the signature is valid, the contract executes the transaction on-chain, completing the flow without any single entity ever possessing the secret.

Previous

123

Next

Integrate policy and access controls

Account Abstraction (AA) transforms the wallet from a simple signature validator into a programmable smart contract. This programmability allows you to enforce team policies—such as daily limits, whitelists, and multi-sig requirements—directly on-chain, complementing the distributed key security of MPC.

To implement these controls, you must extend the execute or executeBatch entry points. Within these functions, insert conditional checks before the transaction is signed by the MPC nodes. For example, a daily spending limit requires tracking state variables (e.g., dailySpent and resetTimestamp) on the contract. If a transaction exceeds the remaining limit, the AA contract reverts, preventing the MPC nodes from ever signing an unauthorized operation.

Below is a comparison of common policy enforcement strategies available via AA smart contracts:

Test your MPC AA wallet integration

Before moving to mainnet, verify that your Multi-Party Computation (MPC) and Account Abstraction (AA) integration handles real-world conditions. Your testing phase must confirm that key recovery works reliably, signature latency remains acceptable under load, and gas sponsorship flows correctly. Treat this as a final security audit rather than a feature check.

Pre-launch verification checklist

Use the following checklist to guide your QA process. Each item addresses a critical failure point common in MPC AA deployments.

Frequently asked questions about MPC AA wallets