Signature schemes
Quorum treats signer schemes as identity variants behind one voting interface.
Quorum is devnet software and should not be used to protect production funds before audit and mainnet readiness.
Supported identities
| Scheme | Basis | Primary use case | Quantum-resistant | State |
|---|---|---|---|---|
| Ed25519 | Elliptic curve | Native Solana continuity and easiest operational path today. | No | Stateless |
| Secp256k1 | Elliptic curve | EVM signer compatibility and cross-chain authorization patterns. | No | Stateless |
| Falcon-512 | Lattice-based FN-DSA | Compact post-quantum approvals that fit Solana transaction constraints. | Yes | Registered public key PDA |
| Winternitz | Hash-based one-time signatures | Conservative SHA-256 preimage assumption and assumption diversity. | Yes | One-time-use state PDA |
Post-quantum threshold
pq_threshold lets a multisig require post-quantum approvals even when the total threshold has already been met.
Every Winternitz vote must advance to the next state root. Reusing old state is a consensus failure, not a UI warning.
Verification path
Classical signatures can rely on established verification paths. Falcon and Winternitz verification are program modules with explicit account lifecycle rules.
Operational trade-offs
Falcon gives teams the most practical repeated post-quantum approval path today. Winternitz gives teams a hash-based fallback with stricter state-management requirements. Ed25519 and Secp256k1 remain useful for continuity, but they should not be treated as quantum-resistant signer classes.