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

# Multi-Signature Wallets and Threshold Signatures

> Distributing Trust and Enhancing Security

OmniSafe utilizes both multi-signature wallets and Threshold Signature Schemes (TSS) to distribute signing authority and enhance security. These technologies ensure that no single point of failure can compromise your assets.

## Multi-Signature Wallets: Shared Control for Enhanced Security

Multi-signature (MultiSig) wallets provide a foundational layer of enhanced security by requiring multiple approvals for any transaction. Instead of a single private key controlling a wallet, a MultiSig wallet mandates that a threshold number of authorized parties must sign a transaction before it can be executed. This is analogous to requiring multiple signatures on a check or multiple keys to open a safe.

Each MultiSig wallet is configured with *n* authorized signers and a threshold *t* (where *t* ≤ *n*). A transaction requires at least *t* valid signatures to be considered valid and executed. These signers use independent generation of their unique keys that are non-shared with other users. In order to send a transaction, the following steps need to be followed:

1. A user (or an automated process) initiates a transaction, specifying details like the recipient address and the amount. This transaction request is presented to each of the *n* authorized signers.
2. Signers who approve the transaction use *their unique private key* to generate a digital signature specific to that transaction, using ECDSA (Elliptic Curve Digital Signature Algorithm).
3. Once the threshold of *t* signatures is collected, the transaction is ready for submission to the blockchain.

The MultiSig contract in OmniSafe *validates the submitted signatures* against the public keys associated with each signer, *enforcing the t-of-n rule.*

A multisig transaction requires using smart contracts, so we have:

Signature Storage (Solidity) in the multisig contract.

* the contract stores details like 'v,r,s.'
* Retrieval is easy, as every wallet member can sign the details using `ecrecover.`
* Verifying is performed by the `verifySignature` function that validates the signature.

Only if the signatures are valid and meet the threshold requirement will the contract execute the transaction.

## Threshold Signature Scheme (TSS): Advanced Security Through Distributed Key Management

Going beyond MultiSig, OmniSafe offers Threshold Signature Schemes (TSS) as an advanced cryptographic approach for distributing signing authority. TSS takes security a step further: instead of each signer holding a separate *private key*, it splits a *single private key* into multiple shares. No single party holds the complete key, and a threshold number of shares must be combined to create a valid signature.

**Key Splitting & Distribution**:

1. The private key is split into *n* shares using cryptographic techniques like Shamir's Secret Sharing (SSS), as discussed previously.
2. A threshold *t* (where *t* ≤ *n*) is defined, representing the *minimum number of shares required to sign a transaction.*
3. These shares are distributed among independent parties or devices. Each party securely stores their share.

**Distributed Signing Process**:

1. When a transaction needs to be signed, a *secure multi-party computation (MPC) protocol* is initiated among the participating parties.
2. Each party uses their *individual key share* as input to the MPC protocol, along with a random number.
3. The MPC protocol allows these parties to *collaboratively generate a digital signature* that is valid under the original public key corresponding to the split private key.
4. Importantly, *the private key itself is never reconstructed* during this process, ensuring that it remains protected at all times. This removes the risk of human involvement and is a mathematical procedure.

**Security Benefits**:

* **No Single Point of Failure**: At no point does a single entity possess the entire private key. An attacker must compromise *at least* *t* shares to create a valid signature.
* **Robustness in Adverse Conditions**: Even if some participants are offline or compromised, as long as the threshold *t* is met, the system can still generate valid signatures.
* **Forward Secrecy**: By rotating key shares periodically, even if an attacker compromises shares at one point in time, they cannot use these shares to sign transactions indefinitely.