Digital signature algorithms
Understand how TSS and MPC work together to produce standard digital signatures
Digital signatures are a cryptographic primitive that underpins the security of blockchains and digital asset custody solutions like io.vault. They provide three properties:
- Authentication verifies the identity of the signer.
- Non-repudiation prevents the signer from denying they signed the message.
- Integrity detects if the message has been altered since signing.
How TSS and MPC work together
A Threshold Signature Scheme (TSS) allows a private key to be held as separate shares across signers. To produce a signature, participating signers must collectively meet a defined threshold of signing power. For example, with three equally weighted signers and a threshold of two, any two can sign together. See Vaults, signers, and thresholds for how signer weights determine which combinations can sign.
Multi-Party Computation (MPC) is how those signers perform the cryptographic work together while keeping their individual shares secret. They exchange protocol messages to generate a key pair and later produce signatures, without assembling the complete private key.
TSS defines the threshold needed to sign; MPC provides the underlying computation that makes threshold signing possible. The result is a standard digital signature that can be verified using the public key.
In io.sign, the backend coordinates this process, while mobile or server-based signers perform the cryptographic operations. The complete private key is reconstructed only through the separate backup and recovery process.
The signature algorithm determines how the resulting signature is created and verified. The table below lists the supported algorithms and curves, including ECDSA, EdDSA, and BIP-340 Schnorr.
Curve and signature support
io.vault supports the following algorithms and elliptic curves.
| ECDSA | EdDSA | BIP-340 (Schnorr) | |
|---|---|---|---|
| Curve | secp256k1 / NIST P-256 | Edwards25519 | secp256k1 |
| COSE Name | ES256K / ESKEC256 / ESP256 | ED25519 | — |
| Threshold Algorithm | CGGMP21 | NIST IR 8214B (3-round approach) | NIST IR 8214B (3-round approach) |
| Public Key Size | 33 bytes (compressed), 65 bytes (uncompressed) | 32 bytes | 33 bytes (compressed) |
| HD Wallets | Yes, Unhardened | Yes, Unhardened | Yes, Unhardened |
| XPub Format | Standard BIP32 | BIP32-like with 00 prefix and 32-byte key | Standard BIP32 |
| Bitcoin Address Type | SegWit | — | Taproot |
| Example Chains | Bitcoin, Ethereum, XRPL | Solana, TON, Cardano, NEAR | Bitcoin Taproot, Polkadot |
Elliptic Curve Digital Signature Algorithm (ECDSA)
ECDSA is the signature scheme used in Bitcoin, Ethereum, and many other blockchains. It relies on the algebraic structure of elliptic curves over finite fields.
Key facts about ECDSA:
- It relies on the assumed difficulty of the Elliptic Curve Discrete Logarithm Problem (ECDLP).
- It uses a curve and base point defined in a standard, e.g. secp256k1 in Bitcoin.
- The private key is a random integer; the public key is a point on the curve.
- Signing involves generating a random nonce and computing a signature (r, s).
- Verification checks a mathematical relationship between the message, public key, and signature.
ECDSA has good performance and relatively short signature sizes, making it well-suited for blockchain use.
Edwards-curve Digital Signature Algorithm (EdDSA)
EdDSA is a more recent signature scheme based on twisted Edwards curves. It is designed to be faster and more secure than ECDSA.
Notable differences from ECDSA:
- Uses a different curve form for better performance and implementation security.
- Deterministic nonce generation prevents common ECDSA pitfalls.
- Includes a hash of the private key in the signature for better malleability resistance.
- Cleaner and more efficient to implement.
EdDSA is seeing increasing adoption, particularly in newer blockchain platforms. The most common variant is Ed25519, which uses Curve25519 and the hash function SHA-512.
io.finnet supports both ECDSA and EdDSA across different blockchains. The MPC and TSS schemes are agnostic to the underlying signature algorithm.
Hierarchical Deterministic (HD) wallets
HD wallets (defined in BIP32) allow a single seed to deterministically derive a structured tree of keypairs. io.vault fully supports HD wallet semantics across all supported curve types.
HD wallets in io.vault:
- Unhardened derivation is supported for all curve types (secp256k1, secp256r1, Ed25519), allowing public key derivation without knowledge of private keys.
- BIP44 path structure (e.g.
m/44/60/0/0/0) follows chain-specific conventions. - XPub/XPrv formats are standardised:
- For ECDSA: Standard BIP32 format with version bytes (
xpub,ypub, etc.) - For EdDSA: BIP32-like format with a fixed prefix and 32-byte keys
- XPrvs can be exported when all key shards are collected as part of a Disaster Recovery process.
- For ECDSA: Standard BIP32 format with version bytes (
- io.vault does not persist raw seeds. Instead, it creates wallets with MPC-generated sharded seeds distributed across devices and kept in encrypted storage.
- A single HD wallet can derive keys across multiple blockchains and signature schemes, enabling multi-asset custody from one root.
Why HD wallets matter in secure custody:
- A single seed gives access to billions of keypairs, all deterministically derived, enabling operational scalability.
- Clear derivation paths enable hierarchical access control, user-level partitioning, and deterministic tracking of key lineage.
- In io.vault, HD key derivation is performed under threshold control, so no single party ever sees the root or derived key material.
Note
io.vault's HD wallet implementation provides cryptographic isolation and full determinism across all derived keys. This makes it suitable for regulated institutions requiring deterministic audit trails and secure backup strategies with multiple addresses from a single MPC-secured seed.
Lattice-based signatures (post-quantum)
As the cryptography field moves toward the "Q-Day" scenario (the arrival of cryptographically relevant quantum computers), lattice-based cryptography has become the standard for quantum-resistant digital signatures. Unlike ECDSA or EdDSA, which rely on the discrete logarithm problem, these algorithms are built on the hardness of lattice problems.
What is coming
Following the NIST standardization finalization in 2024, we are actively monitoring the transition to the following schemes:
- ML-DSA (Module-Lattice-Based Digital Signature Algorithm): Formerly known as Dilithium. This is the primary NIST standard for digital signatures due to its balance of security and high performance.
- SLH-DSA (Stateless Hash-Based Digital Signature Algorithm): Formerly known as SPHINCS+. A robust backup standard based on hash functions rather than lattices.
- FN-DSA (FFT over NTRU-Lattice-Based Digital Signature Algorithm): Formerly known as Falcon. Designed for cases requiring minimized signature sizes.
The hybrid transition
We anticipate the industry will adopt hybrid schemes for the immediate future. In this model, a transaction is signed by both a classical key (ECDSA) and a post-quantum key (ML-DSA). This ensures security against future quantum threats without breaking backward compatibility with existing blockchain infrastructure.
The state of academic research in 2026
While single-party lattice signatures are now standardised, threshold lattice signatures remain an active area of academic research. Implementing these in a distributed MPC environment presents unique engineering challenges compared to Threshold ECDSA.
- The rejection sampling problem. Lattice signatures like ML-DSA require "rejection sampling", a process where the signer retries signature generation until the output satisfies a statistical distribution (preventing key leakage). In a distributed MPC setting, coordinating these retries across multiple parties without leaking private data is computationally expensive.
- Recent breakthroughs. The field is moving quickly. Notable recent developments include:
- In May 2024, a new signature scheme specifically designed to be "threshold-friendly" by removing the need for rejection sampling known as TRaccoon was introduced, making it a strong candidate for future MPC implementations.
- In June 2025, a paper by Niot and del Pino of PQShield proposed a novel threshold scheme that achieves signature sizes comparable to standard Dilithium for small committees.
- In August 2025, a paper named Unmasking TRaccoon explored adding "Identifiable Abort" to the original TRaccoon protocol.
- Standardisation timeline. NIST is currently evaluating these approaches under the Multi-Party Threshold Cryptography (MPTC) project (see NIST IR 8214C).
Until these threshold protocols are standardised and audit-proven, io.vault will prioritise proven threshold schemes while preparing our infrastructure for a hybrid post-quantum future.
Updated about 1 month ago
What’s Next
Dive deeper into how these signature algorithms are used in practice to secure blockchain transactions.