Technology
Post-quantum security, M-of-N multisig, and Monero-grade privacy — working together.
Post-Quantum Cryptography
Quantum computers pose a long-term threat to the elliptic curve cryptography that secures most cryptocurrencies today. Shekyl addresses this by deploying a hybrid signature scheme that combines classical and post-quantum algorithms, so the chain remains secure regardless of which cryptographic assumption fails first.
Hybrid Spend Authorization
Every transaction requires both signatures to verify. An attacker must break both classical and post-quantum assumptions simultaneously.
This hybrid approach is deliberately conservative. It increases transaction size by approximately 5.3 KB of authentication material, but avoids betting the entire chain on a single transition-era primitive. The chain is secure if either classical assumptions hold or post-quantum assumptions hold.
TransactionV3
Shekyl’s rebooted chain introduces TransactionV3 as the required format for all user transactions. V3 keeps the existing CryptoNote-style prefix and RingCT body but adds a dedicated hybrid authorization structure called pqc_auth.
The signed payload covers the transaction prefix, the RingCT base, and the PQC auth header — but excludes the signature itself to avoid self-reference. Verification requires both Ed25519 and ML-DSA-65 signatures to succeed; if either fails, the spend is invalid.
Security Goals
- Make it materially harder for a future quantum attacker to steal funds
- Preserve existing privacy mechanisms (ring signatures, stealth addresses, confidential transactions)
- Augment rather than replace the proven CryptoNote privacy stack
- Use only NIST-standardized post-quantum primitives (ML-DSA, ML-KEM)
Post-Quantum Multisig
Shekyl replaces Monero’s classical multisig entirely with a purpose-built post-quantum system. M-of-N spend authorization lives in the pqc_auth layer, using the same proven hybrid primitives (Ed25519 + ML-DSA-65) with zero new cryptographic assumptions.
How It Works
Each participant generates their own hybrid keypair independently — no complex distributed key generation protocol is required. The ring/CLSAG layer uses a single classical key, while the M-of-N threshold lives entirely in the PQC auth layer.
Design Principles
Proven Primitives First
V3 multisig reuses the existing hybrid scheme with zero new cryptographic assumptions. Lattice threshold signatures are deferred until they mature.
Known Costs Over Unmodeled Risks
Each additional signer adds ~5.3 KB. This is a known, bounded cost. Multisig represents well under 1% of transaction volume.
Ring Privacy Preserved
All multisig coordination happens off-chain. On-chain transactions remain indistinguishable at the ring/CLSAG layer.
Staking Security
A single key controlling a staked position locked for months is a single point of failure. Multisig staked outputs address this directly.
Supported Configurations
The consensus cap is 7 participants maximum. Configurations from 1-of-2 through 5-of-7 are supported, with 2-of-3 and 3-of-5 being the most common for treasuries and staking security. Transactions with more than 7 signers are rejected at the protocol level.
| Configuration | Auth Size | vs Single |
|---|---|---|
| Single signer | ~5.3 KB | baseline |
| 2-of-3 | ~12.5 KB | 2.4x |
| 3-of-5 | ~19.7 KB | 3.7x |
| 5-of-7 (typical max) | ~30.2 KB | 5.7x |
Use Cases
Treasury Management
Development funds and community treasuries require that no single person can unilaterally spend. A 2-of-3 or 3-of-5 ensures cooperative authorization.
Staking Security
Long-tier staked positions (up to ~208 days) represent months of illiquidity. Multisig staked outputs require M-of-N authorization for claims and eventual unlock.
Inheritance & Recovery
A 2-of-3 where the owner holds two keys and a trusted party holds one allows normal operation while providing estate recovery if the owner is incapacitated.
Escrow
Buyer, seller, and arbitrator each hold a key in a 2-of-3. Direct settlement requires buyer + seller. Disputes are resolved by the arbitrator co-signing.
Why Not Classical Multisig?
Monero’s classical multisig implementation used additive N-of-M secret splitting on Ed25519. This design had known bugs until mid-2022, remains flagged as experimental, has no formal specification, no completed third-party audit, and was CLI-only with negligible real-world usage. Shekyl removes classical multisig entirely — all multisig on the rebooted chain is PQC-only, with GUI wallet integration designed from launch.
Privacy Technology
Shekyl inherits Monero's proven privacy technology stack — the strongest privacy guarantees in production cryptocurrency. The V3 hybrid scheme augments this stack without weakening the existing ring-member ambiguity.
Ring Signatures
Obscure the sender by mixing the real input with decoy inputs, making it computationally infeasible to determine which participant actually signed.
Stealth Addresses
Generate one-time destination addresses for each transaction, preventing observers from linking payments to recipients.
Confidential Transactions
Hide transaction amounts while maintaining verifiable integrity through Bulletproofs+ range proofs.
V3 Privacy Boundary
- Spend/ownership authorization
- Canonical payload hash binding
- Dual verification (Ed25519 + ML-DSA-65)
- Ring anonymity (CLSAG)
- Stealth address derivation
- Broader CryptoNote privacy stack
Anonymity Network Support
Shekyl integrates support for Tor and I2P anonymity networks. The design maximises the privacy of transaction sources by broadcasting them over an anonymity network, while using IPv4 for other node communication to resist surrounding-node (Sybil) attacks.
Transaction Routing
When an anonymity network is enabled, locally-originated transactions are only sent to peers on anonymity networks. If no anonymity peers are available, the transaction is held until a connection is established — it will never be broadcast over a public connection.
Both shekyl-wallet-cli and shekyl-wallet-rpc can connect through Tor or I2P, providing end-to-end anonymity from wallet to the network.
Cryptographic Roadmap
V3 protects the spend/ownership layer. The ring anonymity machinery (CLSAG, stealth addresses) remains classical. V4 addresses this gap with a phased approach. Shekyl follows a feature-driven upgrade policy: hard forks ship when the feature is ready, not on a fixed calendar. V4 depends on lattice-based privacy primitives that are not yet NIST-standardized, so no fixed timeline is committed.
V3 (HF1)
Active- Hybrid spend authorization (Ed25519 + ML-DSA-65)
- M-of-N PQC multisig (signature list, up to 7 participants)
- TransactionV3 format with dedicated pqc_auth container
- Multisig staking support for long-duration positions
V4: Research & Prototype
When ready- Survey lattice-based ring signatures and PQ zero-knowledge proofs
- Evaluate ML-KEM-768 for PQ stealth address derivation
- Prototype lattice-based composite threshold multisig (scheme_id = 3)
- Benchmark against V3 baseline (target: under 2x V3 transaction size)
V4: Testnet & Activation
When ready- Feature-gated V4 transaction format on testnet
- Privacy regression testing (ring-member ambiguity must not degrade)
- Hard fork activation with grace period for migration
- Compact lattice threshold signatures (fixed size regardless of M or N)
During the V4 transition, V3 multisig (signature list) remains valid. Wallets can offer both options. The V4 lattice threshold scheme produces a single compact signature regardless of M or N, addressing the linear size scaling of the V3 approach.