> ## Documentation Index
> Fetch the complete documentation index at: https://apidocs.finrock.io/llms.txt
> Use this file to discover all available pages before exploring further.

# How Finrock MPC Wallets Work: Threshold Key Signing

> Finrock uses Multi-Party Computation so your private key is never reconstructed. Understand threshold signing, DKG, and the node architecture.

Finrock's wallet infrastructure is built on Multi-Party Computation (MPC), a cryptographic approach that eliminates the concept of a single, unified private key. Instead of generating and storing one key that could be stolen or lost in a single event, Finrock mathematically splits key material into independent shares distributed across separate nodes — none of which can act alone to produce a valid signature.

<Note>
  The full private key **never exists** — not during wallet creation, not during transaction signing, and not at rest. There is no moment at which a complete key can be extracted or exposed.
</Note>

## What Are MPC Wallets?

A traditional wallet holds a private key in one place. If that location is compromised — whether through a software exploit, insider threat, or infrastructure failure — your funds are at risk. MPC wallets remove this single point of failure entirely.

In an MPC wallet, the private key is mathematically split into cryptographic shares distributed across independent signing nodes. These nodes collaborate through a secure protocol to produce a valid blockchain signature without any single node ever holding the complete key. The computation is distributed, so an attacker would need to compromise multiple independent nodes simultaneously — a significantly harder target.

## Cryptographic Foundation

Finrock MPC wallets are grounded in **threshold cryptography**. A private key is split into `N` shares, and any `T` of those shares (where `T ≤ N`) are sufficient to produce a valid signature. Shares below the threshold are mathematically useless on their own.

**Key generation** uses **Distributed Key Generation (DKG)** protocols, meaning the shares are created independently across nodes from the start — the full key is never assembled even during the setup phase.

### Supported Algorithms

| Algorithm | Curve     | Supported Chains                                  |
| --------- | --------- | ------------------------------------------------- |
| ECDSA     | secp256k1 | Bitcoin, Ethereum, and most EVM-compatible chains |
| EdDSA     | Ed25519   | Solana and Ed25519-based chains                   |

### Threshold Configurations

Finrock supports several standard configurations, as well as custom thresholds for enterprise deployments:

<CardGroup cols={3}>
  <Card title="2-of-3 MPC" icon="shield-halved">
    Any 2 of 3 nodes sign. One node can go offline without interrupting operations.
  </Card>

  <Card title="3-of-5 MPC" icon="shield">
    Any 3 of 5 nodes sign. Higher fault tolerance and stronger attack resistance.
  </Card>

  <Card title="Custom Enterprise" icon="sliders">
    Configure custom T-of-N thresholds to match your security policy and operational requirements.
  </Card>
</CardGroup>

## MPC Node Architecture

Each MPC wallet is backed by a set of independent signing nodes, each deployed in a separate infrastructure environment. Every node stores only its own cryptographic share — reconstructing the full key from a single node is computationally infeasible.

A typical Finrock deployment uses three nodes:

<Steps>
  <Step title="Node A — Application Server">
    Runs inside a virtual machine on your cloud infrastructure (AWS or Azure). This node integrates with the Finrock platform and initiates signing requests on your behalf.
  </Step>

  <Step title="Node B — User-Controlled Mobile Node">
    Resides in the **Finrock Mobile App**, which you control directly. This gives you independent authority over the signing process and ensures Finrock alone cannot unilaterally move funds.
  </Step>

  <Step title="Node C — Backup / Disaster Recovery Node">
    A dedicated backup or disaster recovery node that ensures signing continuity if Node A or Node B is temporarily unavailable. This node is kept isolated from normal operations until needed.
  </Step>
</Steps>

<Info>
  Nodes communicate exclusively through **secure, encrypted peer-to-peer (P2P) channels** during signing operations. No plaintext key material is ever transmitted between nodes.
</Info>

## Transaction Signing Workflow

When you initiate a transaction, Finrock orchestrates a multi-round MPC signing protocol across the participating nodes:

<Steps>
  <Step title="Transaction Request">
    You submit a transaction request to the Finrock API. The platform constructs the unsigned transaction payload and distributes signing requests to the eligible nodes.
  </Step>

  <Step title="Threshold Approval">
    The required number of nodes (meeting the T-of-N threshold) each compute their partial signature using their local key share. No node sends its share to another — only partial signatures are exchanged.
  </Step>

  <Step title="Signature Aggregation">
    The partial signatures are cryptographically combined into a single, valid blockchain signature. The full private key is never reconstructed at any stage of this process.
  </Step>

  <Step title="Broadcast">
    The fully signed transaction is broadcast to the blockchain network. From the network's perspective, it looks identical to a standard single-key signature.
  </Step>
</Steps>

## Why MPC Matters for Your Business

<CardGroup cols={2}>
  <Card title="No Single Point of Failure" icon="link-slash">
    An attacker must compromise multiple independent nodes across separate environments simultaneously — making key theft orders of magnitude harder than attacking a traditional wallet.
  </Card>

  <Card title="Institutional-Grade Security" icon="building-columns">
    MPC is the standard chosen by leading custodians and exchanges for securing billions in digital assets. Finrock brings the same architecture to your platform.
  </Card>

  <Card title="Operational Continuity" icon="rotate">
    Threshold configurations tolerate node failures. If one node goes offline, the remaining nodes above the threshold can continue signing without interruption.
  </Card>

  <Card title="Auditable & Transparent" icon="magnifying-glass">
    Every signing event is logged. Because key shares never move, audit trails map directly to infrastructure-level events rather than key custody transfers.
  </Card>
</CardGroup>