MPC Service Guide
MPC is a distributed key management and signing service based on Multi-Party Computation. Instead of storing a private key in one place, key material is split across multiple nodes to maximize security. This document explains the key components and integration models of MPC.
For implementation details and code examples by integration model, refer to the documents below.
| Integration Model | Guide |
|---|---|
| Client Node (Server-side) | Client Node API Guide |
| WASM (Web) | For detailed guidance, please contact us at abcwaas@ahnlab.io. |
| Mobile SDK (Android/iOS) | Mobile SDK Guide |
Architecture Overview
MPC provides two integration models depending on your runtime environment.
Model A: Client Node (Server-side)
If your client does not use WASM or Mobile SDK, you can deploy the MPC Client Node (Docker) in your environment and use MPC capabilities on the server side. Your backend calls the Client Node via REST API.
This model is suitable when key-share operations are handled by your server. It is commonly used in services where key generation and signing are performed directly in the backend without installing SDKs on end-user devices.
Model B: WASM / Mobile SDK (Client-side)
If your client uses WASM (Web) or Mobile SDK (Android/iOS), the client can communicate directly with MPC nodes for key generation and signing, without Client Node.
This model is suitable when end users approve and sign transactions directly on device (for example, wallet apps and DApp browsers). Since key shares are processed directly on the client, they do not pass through your backend, reducing server-side key-share exposure risk. Your backend only needs to issue a auth token and pass it to the client.
Components
| Component | Operator | Description |
|---|---|---|
| Client Node | Customer | Gateway that coordinates communication with MPC nodes. Provided as a Docker image. Used in Model A |
| MPC Node 1 | ABC | MPC compute node for distributed key generation and signing |
| MPC Node 2 | Third-party institution | MPC compute node that independently manages key fragments. Operated separately from ABC |
| Mobile SDK | Customer app | Uses MPC features in Android/iOS native apps. Model B |
| WASM | Customer web app | Uses MPC features in the web browser. Model B |
MPC Node 1 and MPC Node 2 are independently operated by different organizations. This design ensures that compromising a single organization cannot expose private keys.
Core Principles
- No private key exposure: No single node ever holds a full private key. At no stage of the MPC protocol does a complete private key exist in one place.
- Distributed signing: Signing is executed through a multi-round protocol between MPC nodes. Even during signing, the private key is never reconstructed.
- Client-side encryption: Key shares are encrypted with the user password and stored on the client. The server only handles encrypted data and cannot access plaintext key shares.
- Independent operation: MPC Node 1 and MPC Node 2 are operated by different entities, so compromising one side alone is insufficient for signing or key recovery.
Main Features
MPC provides the following features. The same capabilities are available through Client Node, WASM, and Mobile SDK.
Key-share Generation
This is the first step to start using MPC. When key-share generation is requested, a multi-round MPC protocol runs across nodes, producing distributed key fragments without exposing a full private key anywhere. The generated key share is encrypted with the user-defined password, and the values below are returned.
| Return Value | Description |
|---|---|
keyId | Key identifier used for signing and key management |
encryptedShare | Encrypted key share; core data required for signing |
secretStore | Secret data required to decrypt the key share |
curve | Curve used (secp256k1 or ed25519) |
Key-share Recovery
If a locally stored key share becomes unavailable due to device change, app reinstallation, or data loss, you can recover it using key information registered on the server. Recovery also runs through the MPC protocol, so a new key share is generated securely.
Recovery issues a new keyId, but it uses the same public key as the original, so on-chain addresses and assets remain unaffected. The recovered key share can be used for signing in the same way as before.
Signing
Sign messages using key shares. The private key is never reconstructed during signing; signatures are created in distributed form through multi-round MPC communication. The output format is compatible with standard ECDSA/EdDSA signatures and can be submitted directly to blockchain networks.
Recommended signing method varies by curve.
| Curve | Recommended Method | Description |
|---|---|---|
| secp256k1 | MTA signing | Security-enhanced signing based on Multiplicative-to-Additive protocol |
| ed25519 | Default signing | Standard EdDSA signing |
Validation
Before signing, you can validate key-share and password integrity in advance. Since signing attempts with wrong passwords or corrupted key shares will fail in the MPC protocol, pre-validation is recommended to reduce unnecessary failures.
- Password validation: Verifies whether the password used during key-share generation is correct. Useful for detecting forgotten or mistyped passwords.
- Key-share validation: Verifies key-share integrity, including whether data was corrupted during storage and whether it can be decrypted correctly with the password.
Key-share Storage Considerations
The values returned during key-share generation (keyId, encryptedShare, secretStore) are critical signing data. Follow these guidelines based on your integration model.
Model A — Client Node (Server-side)
Data returned during key generation must be encrypted and stored securely in your backend. Leakage of this data can cause security risk, so strict storage/access control is required.
Model B — Mobile SDK (Client-side)
The SDK provides built-in storage support using mobile secure storage (Android Keystore, iOS Keychain). Even if you do not use automatic SDK storage, storing key shares in secure OS storage is strongly recommended.
Model B — WASM (Client-side)
In browser environments, key shares are stored client-side in the browser context. Apply additional protections such as encrypted storage and strict access control.
MPC Communication Model
MPC uses a 2-of-3 model. Three parties (client, MPC Node 1, MPC Node 2) each hold key fragments, and any two fragments are sufficient to perform signing.
In normal operation, client + MPC Node 1 participate in key generation and signing. MPC Node 2 acts as a recovery backup and is used when the client loses its key share.
| Participant | Role |
|---|---|
| Client | Holds a key fragment. Participates with MPC Node 1 for key generation/signing |
| MPC Node 1 (ABC) | Holds a key fragment. Participates with client for key generation/signing |
| MPC Node 2 (Third-party institution) | Holds a key fragment. Used for recovery when client key share is lost |
Three-party Communication Flow
All MPC operations (key generation, signing, recovery) are performed through multi-round communication between participants. Each participant communicates while holding only its own key fragment, and a full private key never exists in one place.
For key generation and recovery, all three participants (client, MPC Node 1, MPC Node 2) communicate and create their key fragments.
For signing, only client and MPC Node 1 participate (2-of-3). MPC Node 2 does not participate in signing.
Client Node Operational Overview
MPC Client Node is provided as a Docker image. Deploy it in your backend environment to handle communication with MPC nodes. You can start immediately by running the container and setting environment variables, without separate builds or source management.
Key Characteristics
- Docker-based deployment: Delivered as a container image, ready to run without build steps. Can be operated in orchestrators like Kubernetes or ECS.
- Stateless architecture: Client Node does not store key data. Requests are delegated to MPC nodes, so horizontal scaling is straightforward as traffic grows.
- Built-in Swagger UI: API docs are included, enabling browser-based API exploration/testing without separate documentation tooling.
- Environment-variable driven config: MPC node URLs, credentials, and app server values are configured via environment variables. ABC-provided credentials automatically establish MPC connectivity.
Main APIs
| Feature | Method | Path |
|---|---|---|
| Generate key share | POST | /v3/wallet/generate |
| Recover key share | POST | /v3/wallet/recover |
| Default sign | POST | /v3/wallet/sign |
| MTA sign | POST | /v3/wallet/sign/mta |
| Get public key | POST | /v3/wallet/publickey |
| Validate password | POST | /v3/wallet/validate/password |
| Validate key share | POST | /v3/wallet/validate/share |
| Get registered keys | GET | /v3/wallet/key |
| Register key | POST | /v3/wallet/key |
Operational Notes
- Since Client Node relays traffic to MPC nodes, deploy it in a low-latency network path. MPC signing is multi-round, so network latency directly impacts signing time.
- MPC node URLs and credentials are provided separately by ABC. Handle these credentials securely and do not include them in source code or public repositories.
- Restrict network access so only your backend can reach the Client Node.
For detailed setup and Docker run instructions, refer to Client Node API Guide.
Security Notes
- No private key exposure: A full private key is never reconstructed or stored in one place.
- Independent node operation: MPC Node 1 (ABC) and Node 2 (third party) are independently operated, preventing key exposure through single-entity compromise.
- Client-side encryption: Key shares are encrypted with user passwords. Servers only process encrypted data.
- Mobile secure storage: Mobile SDK supports secure storage using Android Keystore and iOS Keychain.
- Device isolation: Key shares stored by Mobile SDK are tied to the app on that device and are not restored automatically via backup/device migration.
- Concurrent signing restriction: MTA signing uses a multi-round protocol; avoid sending concurrent signing requests for the same key.