# MPC Key Management > **🚧 Development Status:** MPC functionality is currently under active development. This documentation describes the planned implementation and architecture. API endpoints for MPC operations will be available in a future release. For now, you can use Vilna with xPub keys generated from external MPC solutions. Multi-Party Computation (MPC) key management provides the highest level of security for digital asset custody by ensuring that private keys are never assembled in one place. Vilna implements the state-of-the-art CGGMP protocol for threshold signature generation. ## Overview Traditional key management approaches have inherent vulnerabilities: - **Single keys** create a single point of failure - **Multi-sig** reveals all participants on-chain - **Hardware wallets** can be lost or compromised MPC technology eliminates these risks by distributing key generation and signing across multiple parties, with no single party ever having access to the complete private key. ## The CGGMP Protocol Vilna uses the CGGMP (Canetti-Gennaro-Goldfeder-Makriyannis-Peled) protocol, which represents the cutting edge of threshold signature schemes: ```mermaid graph LR subgraph "Traditional Approach" PK[Private Key] --> SIGN[Signature] end subgraph "MPC Approach" S1[Shard 1] --> MPC[MPC Protocol] S2[Shard 2] --> MPC S3[Shard 3] --> MPC MPC --> SIG[Signature] end ``` ### Key Features - **No Key Reconstruction**: The private key is never reconstructed, even during signing - **Threshold Signatures**: Configure m-of-n signing policies (e.g., 2-of-3, 3-of-5) - **Proactive Security**: Rotate key shards without changing the public key - **Non-interactive Signing**: After initial setup, signing requires minimal rounds of communication ## Key Generation Process ### Step 1: MPC Ceremony Initialization (Planned) The MPC ceremony will begin with initialization where you specify the number of participants and threshold requirements. This functionality is not yet available via API. ### Step 2: Distributed Key Generation (Planned) Each participant will run the key generation protocol: ```mermaid sequenceDiagram participant P1 as Party 1 participant P2 as Party 2 participant P3 as Party 3 participant V as Vilna MPC P1->>V: Commitment P2->>V: Commitment P3->>V: Commitment V->>P1: All Commitments V->>P2: All Commitments V->>P3: All Commitments P1->>V: Key Share P2->>V: Key Share P3->>V: Key Share V->>V: Verify Shares V->>P1: Generation Complete V->>P2: Generation Complete V->>P3: Generation Complete ``` ### Step 3: Export and Import xPub Once key generation is complete (using external MPC solutions), the extended public key can be imported into Vilna Core using the standard [xPub API](/apis/spec#operation/createXpub) for wallet generation and monitoring. ## Shard Management ### Secure Storage Key shards must be stored securely across different environments: - **Cloud HSM**: AWS CloudHSM, Azure Key Vault, Google Cloud HSM - **Hardware Security Modules**: Physical HSMs in data centers - **Secure Enclaves**: Intel SGX, AWS Nitro Enclaves - **Mobile Devices**: iOS Secure Enclave, Android Keystore ### Shard Rotation (Planned Feature) In the future, Vilna will support shard rotation to maintain security by adding new participants and removing old ones without changing the public key. This feature is currently under development. ## Transaction Signing ### Signing Process (Planned) When MPC signing is available, the process will work as follows: 1. **Build Transaction**: Vilna will construct the transaction 2. **Request Signatures**: Each shard holder will receive signing request 3. **Partial Signatures**: Threshold number of parties will provide partial signatures 4. **Combine**: MPC protocol will combine partial signatures into final signature 5. **Broadcast**: Transaction will be broadcast to blockchain This functionality is currently under development. ### Signature Collection ```mermaid graph TD T[Transaction] --> R1[Request to Party 1] T --> R2[Request to Party 2] T --> R3[Request to Party 3] R1 --> S1[Partial Sig 1] R2 --> S2[Partial Sig 2] S1 --> C[Combine Signatures] S2 --> C C --> F[Final Signature] F --> B[Broadcast Transaction] ``` ## Security Model ### Protection Against Various Attacks | Attack Type | Protection Method | | --- | --- | | Key Theft | Key never exists in complete form | | Insider Threat | Threshold requirement prevents single malicious party | | Physical Compromise | Geographic distribution of shards | | Network Attacks | End-to-end encryption between parties | | Quantum Computing | Post-quantum cryptography roadmap | ### Compliance Benefits - **No Single Point of Control**: Meets regulatory requirements for distributed custody - **Audit Trail**: Complete logging of all signing operations - **Policy Enforcement**: Programmable signing policies - **Geographic Distribution**: Comply with data residency requirements ## Integration with Vilna ### Workflow Integration ```mermaid graph LR subgraph "MPC Module" KG[Key Generation] XPUB[xPub Export] end subgraph "Vilna Core" ADDR[Address Generation] MON[Monitoring] end subgraph "Transaction Module" TX[Transaction Creation] SIGN[MPC Signing] end KG --> XPUB XPUB --> ADDR ADDR --> MON MON --> TX TX --> SIGN ``` ### API Integration MPC operations will be accessible through Vilna's unified API once development is complete. Currently, you can import xPub keys generated through external MPC solutions using our [standard xPub endpoints](/apis/spec#operation/createXpub). ## Use Cases ### Institutional Custody Perfect for institutions requiring bank-grade security: - Cryptocurrency exchanges - Asset managers - Corporate treasuries - DeFi protocols ### Regulatory Compliance Meet strict regulatory requirements: - SOC 2 Type II compliance - ISO 27001 certification - CCSS Level 3 security - GDPR data protection ### High-Value Operations Secure high-value transactions: - Large transfers requiring multiple approvals - Smart contract deployments - Cross-chain bridges - DeFi position management ## Best Practices ### Key Ceremony 1. **Secure Environment**: Conduct key generation in controlled environment 2. **Identity Verification**: Verify all participants before ceremony 3. **Hardware Isolation**: Use air-gapped devices when possible 4. **Documentation**: Document entire process for audit purposes ### Operational Security 1. **Regular Rotation**: Rotate shards quarterly or after personnel changes 2. **Access Control**: Implement strict access controls for shard access 3. **Monitoring**: Monitor all signing requests and anomalies 4. **Backup Procedures**: Maintain secure backup and recovery procedures ### Disaster Recovery 1. **Shard Backup**: Securely backup shards in different geographic locations 2. **Recovery Testing**: Regularly test recovery procedures 3. **Emergency Contacts**: Maintain updated emergency contact list 4. **Incident Response**: Have clear incident response plan ## Getting Started ### Prerequisites - Vilna API access - Minimum 3 secure environments for shard storage - Understanding of threshold signatures ### Quick Start > **Beta Program:** MPC functionality is currently in development. Contact [support@vilna.io](mailto:support@vilna.io) to join the beta program and get early access to MPC features. 1. **Join Beta Program** - Contact support to participate in MPC beta testing 2. **Plan Your Setup** - Define your threshold requirements and participant structure 3. **Prepare Infrastructure** - Set up secure environments for shard storage 4. **Import Generated xPub** - Use the [standard xPub API](/apis/spec#operation/createXpub) to import keys into Vilna Detailed implementation guides will be available upon MPC feature release. ## Support For MPC-specific support: - Technical Documentation: [docs.vilna.io/mpc](https://docs.vilna.io/mpc) - Enterprise Support: [support@vilna.io](mailto:support@vilna.io) - Security Audits: Available upon request ## Next Steps - [Core Platform](/guides/core) - Learn about address generation and monitoring - [Transaction Processing](/guides/transactions) - Understand transaction signing flow - [API Reference](/apis/spec) - Complete API documentation