MPC Threshold Signature Protocol

Secubit implements threshold ECDSA signatures using the Lindell 2017 protocol. Unlike multi-signature wallets where multiple signatures are combined at the blockchain level, threshold schemes produce a single ECDSA signature that is indistinguishable from a standard one. This makes the wallet compatible with any blockchain or application that already supports ECDSA.

In Secubit’s architecture, there are exactly two key shares:

HSM key share: Stored inside the HSM. It is encrypted and processed exclusively within the HSM.
Customer key share: The encrypted form of this share with PassKey is stored by the Secubit server. Since the server never has access to the PassKey, it cannot decrypt or misuse this share — only the user, with biometric authentication on their device, can unlock and use it.

To support multiple approvers, the customer share is replicated. Each approver has their own encrypted copy of the customer key share, bound to their personal PassKey. This ensures that authorization remains self-sovereign and distributed, even though Secubit helps coordinate the signing protocol.

Protocol Flow

The sequence diagram below illustrates how a transaction gets signed:

A transaction request is initiated by the customer system and sent to the Secubit server.
The Secubit server prepares the transaction data and sends the HSM-generated digest(s) along with the HSM’s MPC message to the customer system.
The customer system passes the digest(s), MPC message, and the user’s encrypted share to the user machine.
The user machine, protected by PassKey, decrypts the customer share, generates its own MPC message that includes customer signature share.
The customer MPC message is sent back to the server, which forwards them to the HSM.
Inside the HSM, the vault decrypts its encrypted share, and generates the HSM signature share.
The HSM combines its signature share with the customer’s share to produce a complete ECDSA signature.
The final signed transaction is returned to the server, which submits it to the blockchain.

sequenceDiagram
    participant H as 🔑 Secubit HSM
    participant S as Secubit Server
    participant C as Customer System
    participant U as 🔑 User Machine

    Note over U,H: round 1
    activate U
    U->>C: tx_request
    activate C
    C->>S: tx_request

    activate S
    S->>S: create tx_data from tx_request
    S->>H: tx_data


    activate H
    H->>H: prepare unsigned_tx and <br/> create digest(s)
    H->>H: generate mpc_message_1
    H-->>S: unsigned_tx + digest(s) + <br/> mpc_message_1
    deactivate H

    S->>S: store unsigned_tx and digest(s) in DB
    S->>S: fetch enc_customer_share from DB
    S-->>C: digest(s) + <br/> enc_customer_share + <br/> mpc_message_1
    deactivate S

    C-->>U: digest(s) + <br/> enc_customer_share + <br/> mpc_message_1
    Note over U,H: round 2
    U->>U: decrypt <br/> enc_customer_share <br/> by PassKey
    U->>U: generate mpc_message_2 (include sig_client)
    U->>C: mpc_message_2

    C->>S: mpc_message_2
    activate S
    S->>S: fetch unsigned_tx from DB
    S->>S: fetch enc_hsm_share from DB
    S->>H: unsigned_tx + <br/> enc_hsm_share + <br/> mpc_message_2 (sig_client)

    activate H
    H->>H: decrypt <br/> enc_hsm_share
    H->>H: generate sig_hsm
    H->>H: combine sig_hsm and sig_client
    H-->>S: signed_tx
    deactivate H

    S->>S: send signed_tx to network
    S-->>C: ok
    deactivate S

    C-->>U: ok
    deactivate C

    deactivate U

Key Generation and Rotation

Secubit is designed so that in non-custodial mode the full private key is never held by Secubit at any point, while still allowing the customer to independently recover their key without relying on Secubit. To achieve this, key generation is performed on the customer side.

The customer first generates local entropy and combines it with randomness produced by the HSM’s True Random Number Generator (TRNG). Because the HSM does not have access to the customer’s local entropy, it cannot reconstruct or learn the resulting key material. At the same time, incorporating HSM-generated randomness ensures that the final entropy remains cryptographically strong. This combined entropy is then used to derive the wallet’s master key.

In the next step, the customer generates a second piece of local entropy and combines it with a new random value from the HSM. This combined entropy is used to generate the customer’s key share. The corresponding HSM key share is then deterministically derived from the master key and the customer’s share.

Finally, the customer’s key share is encrypted using a customer-controlled public key secured via Passkey, while the HSM’s key share is encrypted using an HSM-resident public key, ensuring that only the HSM can decrypt it. After this step, both key shares on the customer machine are securely erased using zeroization to prevent residual data leakage.

Recovery Kit

During the key generation phase, prior to deriving the master key, a BIP-39 mnemonic is generated from the combined entropy, along with the corresponding BIP-32 fingerprint and an optional passphrase. Together, these elements form the Recovery Kit, which can be securely stored offline or in an air-gapped environment.

The Recovery Kit is not used during normal operations; customers interact solely with their distributed key shares for day-to-day transactions. However, in a disaster recovery scenario, the Recovery Kit enables the customer to fully reconstruct the wallet and regain complete control over their funds without any dependency on Secubit.

This mechanism acts as a final layer of assurance, providing strong guarantees against censorship, system failure, or permanent loss of access.

Combined Security Model

Secubit strengthens its threshold signature protocol by combining MPC signing, approver-based authorization, and Merkle tree validation into a unified workflow. Before the HSM decrypts its own key share and produces a partial signature, it first enforces approval verification against the wallet’s Merkle tree. This ensures that each approver or user is not only co-signing the transaction through their customer share, but also simultaneously authorizing the HSM to release its share for signing. In effect, the HSM share remains under customer control, serving primarily to split the private key and mitigate the risk of compromise of the customer share alone. By layering MPC with policy enforcement and Merkle-root–anchored approvals, Secubit delivers a secure self-sovereign non-custodial wallet that resists both insider and external threats while maintaining user ownership of keys.

Security Guarantees

Full customer control of the master key: The complete master key is known only to the customer and is never exposed to or reconstructed within Secubit’s HSM. This guarantees full ownership, independent access, and strong resistance to censorship.
Server compromise is harmless: even if the Secubit server is fully compromised, attackers cannot decrypt user shares or forge signatures, since every share is bound to PassKey authentication and HSM-enforced policies.
Multiple approvers supported: each approver holds an independently encrypted copy of the customer share, allowing secure multi-user wallets. Users can be added or removed while preserving the same wallet public key.
Policy enforcement with Merkle tree verification: before the HSM decrypts its share or generates a partial signature, it validates approver authorizations against the wallet’s Merkle tree. This means each approver simultaneously approves the HSM’s participation and co-signs the transaction, keeping the HSM share effectively under customer control.
Recovery without dependency: through the recovery kit, customers can reconstruct their full private key in an air-gapped environment using their password, ensuring that in extreme scenarios they retain ultimate control over funds without relying on Secubit.

The Secubit Whitepaper