How to Build an MPC AA Wallet for AI Agents

How an MPC AA Wallet Works

An MPC AA wallet merges Account Abstraction (AA) logic with Multi-Party Computation (MPC) security, allowing AI agents to sign transactions autonomously without holding a vulnerable private key. AA defines the smart contract rules for execution, while MPC handles the cryptographic distribution of key shares.

In this architecture, the private key is never assembled in one place. It is split into encrypted shares distributed across nodes. When an AI agent executes a transaction, the AA layer validates the request against predefined rules—such as spending limits. Once validated, the MPC protocol combines the key shares to produce a valid signature. This separation ensures that no single component can compromise the funds.

Compare MPC and AA features

Standalone MPC and AA wallets solve different problems. MPC focuses on key storage and sharing, while AA focuses on transaction processing and gas sponsorship. Neither offers the full suite of capabilities required for autonomous AI agents.

MPC wallets split private keys into encrypted shares across multiple devices. This eliminates the vulnerability inherent in traditional wallets where a compromised key means lost assets [src-serp-2]. However, MPC wallets remain "dumb" smart contracts on-chain. They lack the ability to sponsor gas fees or implement custom security logic without significant developer overhead.

AA wallets upgrade the standard Ethereum account to a smart contract. This allows for social recovery, session keys, and gas sponsorship. While this improves user experience, a standalone AA wallet still relies on a single private key for signing. If that key is stolen, the agent's assets are immediately vulnerable.

The hybrid approach combines MPC's key security with AA's on-chain flexibility. This creates a wallet that is both secure against key compromise and flexible enough to handle the complex, high-frequency transactions typical of AI agents.

Set up the key infrastructure

Before an AI agent can sign a transaction, the underlying cryptographic infrastructure must be initialized. This phase involves two distinct but interdependent processes: Distributed Key Generation (DKG) to create the wallet’s master key, and the selection of a threshold signing protocol to handle future transactions. Unlike traditional wallets where a private key exists as a single file, an MPC AA wallet distributes trust across multiple nodes.

Generate key shares with DKG

Distributed Key Generation (DKG) is the process where multiple participants collaboratively generate a new public-private key pair without any single party knowing the full private key. In this step, your AI agent’s infrastructure nodes (e.g., backend servers, hardware security modules, or third-party MPC providers) interact to create encrypted key shares.

Each node generates a random polynomial and exchanges commitments with other nodes. Through a series of cryptographic exchanges, the nodes derive their individual key shares. The public key derived from these shares becomes the wallet’s address. Crucially, the private key is never reconstructed in full; it remains mathematically split across the network. This eliminates the vulnerability inherent in traditional key management.

Select the threshold signing protocol

Once the key shares are generated, you must choose a threshold signing protocol that defines how these shares interact to sign transactions. The most common standards are GG20 and CGGMP21.

GG20 is a widely adopted protocol that offers efficient threshold signatures but requires significant computational overhead during the signing phase. CGGMP21 is a newer protocol that optimizes for speed and bandwidth, making it often better suited for high-frequency AI agent interactions. Your choice will impact latency and API costs. For AI agents requiring rapid, automated transactions, CGGMP21 is often the preferred default.

Configure the threshold parameters

The final step in setup is defining the threshold value (t-of-n). This determines how many key shares are required to authorize a transaction. For example, in a 3-of-5 setup, any three nodes must collaborate to sign.

For an AI agent wallet, a higher threshold increases security but reduces availability if nodes go offline. A common configuration for enterprise-grade AI agents is a 2-of-3 or 3-of-5 arrangement, balancing fault tolerance with security. Ensure your infrastructure nodes are configured to communicate securely via TLS and that the threshold logic is hardcoded into your smart contract or MPC provider SDK.

1

Initialize DKG Protocol

Configure your node environment to support the DKG handshake. Ensure all participant nodes have synchronized clocks and secure channels established. Run the DKG initialization command to begin the key generation phase.

2

Exchange Key Shares

Nodes exchange encrypted polynomial commitments. Verify that each node receives and validates the shares from all other participants. This step ensures that no single node can predict or manipulate the final key material.

3

Deploy Threshold Logic

Lock in the threshold (t-of-n) configuration. Deploy the smart contract or MPC provider integration that enforces this threshold. Test a dummy transaction to confirm that the required number of nodes can successfully produce a valid signature.

Previous

123

Next

Configure smart contract logic

The smart contract acts as the rulebook for your AI agent. It defines what the agent can do, how much it can spend, and which operations are permitted. By implementing ERC-4337 compatibility, you allow the agent to initiate transactions without holding private keys directly, relying instead on the MPC infrastructure to sign them.

Start by defining the core execution rules. Your contract should include a verifyUserOp function that validates incoming requests. This is where you enforce business logic: check if the agent is authorized, verify the spending limit hasn't been exceeded, and ensure the operation type is allowed. For example, you might restrict the agent to only swap tokens on Uniswap or transfer assets to pre-approved addresses.

Next, implement the spending limits and time-based constraints. Use a mapping to track daily or monthly spending caps per agent. When a transaction is submitted, the contract checks the current balance against the limit. If the limit is reached, the transaction is rejected. You can also add time windows, allowing the agent to operate only during specific hours or days.

Finally, set up the access control. Use a role-based system to distinguish between different agents or operators. The MPC wallet contract should only execute operations signed by valid MPC shares. This ensures that even if the smart contract is compromised, the attacker cannot move funds without the MPC key shares.

1

Define ERC-4337 compatible entry points

Implement the verifyUserOp function to validate incoming transactions. Check the agent's authorization status and ensure the operation type is permitted by your business rules. This function is the gatekeeper for all agent actions.

2

Enforce spending limits and constraints

Add logic to track spending per agent. Use a mapping to store daily or monthly limits. Before executing a transaction, subtract the amount from the available balance. If the balance is insufficient, revert the transaction.

3

Configure access control and roles

Implement role-based access control to distinguish between agents. Only allow operations signed by valid MPC shares. This ensures that even if the contract is compromised, funds remain secure without the key shares.

Previous

123

Next

Integrate AI agent triggers

Connecting an AI agent to an MPC AA wallet requires a clear handoff between decision-making and cryptographic execution. The agent generates a transaction proposal, but the MPC network handles the actual signing. This separation ensures the AI never sees, stores, or exposes the private key shares.

1. Define the execution policy

Before integrating, establish strict rules for what the AI can do. Define allowed operations, maximum transaction values, and approved recipient addresses. These constraints act as a guardrail, preventing the agent from executing unauthorized or risky transactions. The policy should be stored in a configuration file or smart contract that the wallet interface reads before proceeding.

2. Generate the transaction payload

The AI agent processes its input (e.g., market data, user request) and creates a standard transaction payload. This includes the recipient address, asset amount, and gas parameters. The payload is not yet signed; it is simply a data structure representing the intended action. Ensure the payload format matches the wallet's expected input schema to avoid parsing errors during the signing phase.

3. Submit to the MPC signing service

Pass the unsigned payload to the MPC signing service via a secure API endpoint. The service verifies the agent's identity and checks the transaction against the defined execution policy. If the transaction passes validation, the service initiates the threshold signature protocol. The agent does not participate in the cryptographic computation; it only observes the result.

4. Receive and broadcast the signature

Once the MPC network completes the signing process, it returns a valid signature to the agent or the wallet interface. The agent then broadcasts the signed transaction to the blockchain network. Because the signature was generated by the distributed key shares, it is cryptographically valid without any single party ever reconstructing the full private key.

1

Define execution policy

Set allowed operations, max values, and approved addresses in a config file or smart contract. This guardrail prevents unauthorized AI actions.

2

Generate transaction payload

The AI creates an unsigned payload with recipient, amount, and gas. Ensure the format matches the wallet's expected schema for smooth processing.

3

Submit to MPC signing service

Send the payload to the MPC API. The service verifies identity, checks policy compliance, and initiates the threshold signature protocol without exposing keys.

4

Receive and broadcast signature

Receive the valid signature from the MPC network and broadcast the transaction to the blockchain. The agent never reconstructs the private key.

Previous

1234

Next

Test the signing workflow

Verify that threshold signatures are generated correctly and that the system handles partial failures gracefully. This phase confirms that the AI agent can sign transactions securely.

Run a standard transaction test first. Send a small amount of testnet funds to an address controlled by the agent. Monitor the signing process to ensure each node contributes its share without exposing the master key. If the signature fails, check the network connectivity between the key shards and the smart contract verifier.

Next, simulate partial node failure. Disconnect one or more signing nodes while keeping the threshold requirement above the number of active nodes. The system should reject the transaction or wait for the missing shares. This proves that the wallet remains secure even under adverse conditions.

Check that the smart contract correctly validates the aggregated signature against the public key shares. Ensure the transaction hash matches the expected output. Any mismatch indicates a flaw in the cryptographic aggregation logic that must be fixed before mainnet deployment.

Pre-launch checklist