How io.sign signs transactions

io.sign produces threshold signatures. This page walks through how io.sign signs a transaction and covers the technical details. io.sign returns a raw signature: you can broadcast it to the blockchain yourself, or use io.vault, which integrates with io.sign and broadcasts automatically. Our core cryptography code is open source and has been audited by several independent security firms.

Signing with threshold signatures

io.sign signs transactions using threshold signature schemes. These schemes remove single points of failure by distributing ownership and control of private keys across signers. Here is what happens when you use your key share to sign a transaction:

Signature request: You submit a signing request to io.sign, specifying the message or transaction to sign.
Signer notification: io.sign notifies the designated signers for the vault about the pending request. Each human signer receives the request on their registered device. Automated signers (Virtual Signers) evaluate the request against their configured policies via an approval API or one of the other policy modes.
Distributed signature generation: Once the threshold of signers approves, they run a Multi-Party Computation (MPC) protocol specific to the required signature scheme (ECDSA, EdDSA, or others). No signer ever possesses or reveals their complete private key share during this process.
- For Threshold ECDSA:
  - Signers engage in an interactive protocol known as CGGMP.
  - They collectively generate shares of a secret nonce (k) without reconstructing the nonce itself.
  - Using advanced cryptographic techniques, they securely compute the signature's r value (derived from k*G, where G is the curve's base point) and individual signature shares (s_i). This distributed calculation ensures that the signature s can be computed without any party learning k or the private key x.
- For Threshold EdDSA, also known as Threshold Schnorr:
  - Signers engage in an interactive protocol for a threshold Schnorr structure.
  - Unlike standard EdDSA's deterministic nonce, this protocol uses a randomized approach compatible with EdDSA verification. Signers collectively generate a shared random nonce r and the corresponding curve point R. Each signer contributes randomness (r_i) such that r = Σ r_i.
  - They compute the hash challenge e = H(R, A, M) (where A is the public key, M is the message).
  - Each signer then computes their signature share s_i.
Signature aggregation: Once the required threshold (t+1) of signers has computed their shares, io.sign aggregates these shares to produce the final signature and returns it to you as a raw signature.
- For Threshold ECDSA:
  - The final signature (r, s) is reconstructed. The r value was determined collectively during the generation phase.
  - The final s value is typically calculated by combining the individual shares: s = Σ s_i mod q. The resulting (r, s) pair is a standard ECDSA signature, verifiable by any ECDSA verifier.
- For Threshold EdDSA:
  - The final signature (R, S) is formed. The R point was computed collectively during generation.
  - The final S component is reconstructed by summing the individual shares: S = Σ s_i mod q. The resulting (R, S) pair is a standard EdDSA signature, verifiable by any EdDSA verifier.

Broadcasting the signature

io.sign returns a raw signature. It does not broadcast the transaction. You have two options for getting the signed transaction on-chain:

Broadcast it yourself: Assemble the raw signature with the original transaction data and submit it to a blockchain node. The signature is a standard ECDSA or EdDSA signature, so any node accepts it.
Use io.vault: io.vault integrates with io.sign and broadcasts the signed transaction to the blockchain node network automatically once the signature is produced.

Either way, nodes on the blockchain network independently verify the signature using the standard ECDSA or EdDSA verification algorithm and the vault's public key. If the signature is valid, the transaction is included in a block, mined, and confirmed.

Cryptographic techniques

These protocols rely on several core cryptographic techniques, also known as primitives. io.sign combines the tools listed below to construct its signing algorithms, including secret sharing methods, zero-knowledge proofs, and elliptic curve mathematics.

Primitives for threshold EdDSA/Schnorr

Shamir Secret Sharing (SSS): Divides a secret (like a key or nonce share) into multiple pieces for distribution.
Lagrange Interpolation: Reconstructs the original secret from a sufficient number of shared pieces.
Feldman Verifiable Secret Sharing (VSS): Allows participants to verify the consistency of their secret shares during distribution using public commitments.
Schnorr Signature Algorithm (Core Logic): Provides the fundamental mathematical structure for generating and verifying the signatures.
Schnorr Zero-Knowledge Proof of Knowledge of Discrete Logarithm: Enables participants to prove they know their secret shares without revealing them.
Hash Functions (e.g., SHA-256, SHA-512): Creates unique fingerprints of data for commitments, signature challenges, and proofs.
Hash-Based Commitment Schemes: Allows participants to commit to a value publicly while keeping it hidden until a later reveal phase.
Elliptic Curve Group Operations: Performs the core mathematical operations (point addition, scalar multiplication) on the chosen curve.
Modular Arithmetic: Defines the rules for calculations involving integers within a specific range (modulo the group order q).

Primitives for threshold ECDSA (for example, the CGGMP family of protocols)

Shamir Secret Sharing (SSS) / Pedersen Verifiable Secret Sharing (VSS): Divides the private key into multiple verifiable pieces for distribution among participants.
Paillier Homomorphic Encryption (Additively Homomorphic Encryption): Allows computation on encrypted secret shares (like adding them) without decrypting them first.
Zero-Knowledge Proofs: Enables participants to prove they are following the protocol rules correctly without revealing their secret inputs.
Elliptic Curve Group Operations: Performs the core mathematical operations (point addition, scalar multiplication) on the secp256k1 curve.
Modular Arithmetic: Defines the rules for calculations involving integers within a specific range (modulo the group order n).
Hash Functions (e.g., SHA-256): Creates a unique fingerprint of the message to be signed as part of the ECDSA formula.
Lagrange Interpolation: Used implicitly or explicitly to reconstruct values (like the final signature component) from shares.

How signatures are verified

When a system such as a blockchain node receives a signed message or transaction, it confirms that the signature is authentic and came from the owner of the claimed public key. Verification uses the public key, the message, and the signature. The steps differ between ECDSA and EdDSA.

Verification using ECDSA (common in Bitcoin, Ethereum, and EVM forks)

The system checks that the two numbers making up the ECDSA signature (r and s) are valid, for example that they fall within the expected range.
It calculates a hash of the message.
Using the signature numbers (r, s) and the message hash, the system performs a set of mathematical steps that treat parts of the signature as inputs.
These calculations combine the results with the base point on the elliptic curve (G) and the sender's public key. This produces a final point on the curve.
The system takes the x-coordinate of this final point and compares it to the r value from the original signature. If they match, the signature is valid.

Verification using EdDSA (common in newer systems like Solana, Polkadot, and Cardano)

The system checks that the two parts of the EdDSA signature (R and S) and the public key are valid components.
It takes one part of the signature (R), the sender's public key, and the original message, bundles them together, and calculates a hash of this bundle.
EdDSA verification checks whether a specific mathematical equation balances. This equation involves:
- The second part of the signature (S).
- A standard starting point on the curve (B).
- The first part of the signature (R).
- The fingerprint calculated in the previous step (h).
- The sender's public key (A).
- Essentially, it checks if (S * B) equals (R + h * A) using the special math of elliptic curves.
If the two sides of the equation are equal, the signature is valid.

Why this matters

If the signature passes these checks, the verifier knows the message was signed by someone who holds the corresponding private key, without ever seeing the private key itself. This confirms the message's authenticity and integrity, so any verifier, such as a blockchain node, can accept the transaction.

Security considerations in threshold signing

Distributed key generation: Key shares are generated in a secure ceremony where no single party ever knows the complete private key.
Dynamic vault resharing: Add, remove, or re-allocate signing power among the signers of a vault without changing the public key or its associated addresses.
📘
Resharing Security Considerations
Upon resharing your vault, the old shares of the vault are still cryptographically valid and remain active for use.
The io.finnet app will proactively wipe old share data where possible, but malicious parties that took copies of their old keys could collude to sign transactions after a resharing operation has been done.
For maximum security, it is always recommended to do a full key rotation (a new vault creation) if there are substantial changes to a vault's membership structure, instead of doing a resharing.
Communication security: io.sign encrypts and authenticates all communication between signers to prevent attacks.
Nonce management: Proper nonce generation is critical to security, especially for ECDSA, where reusing or predicting nonces could leak the private key.
Fault tolerance: The threshold scheme lets the system keep operating even if some signers are unavailable, up to the predetermined threshold.

io.sign uses threshold ECDSA and EdDSA schemes, so transactions keep the security properties of these signature algorithms while adding distributed trust and fault tolerance. The resulting signature is indistinguishable from a signature generated with a single private key. It stays compatible with existing blockchain verification while removing single points of failure.