Technology
Full-chain anonymity, post-quantum security, and M-of-N multisig — working together from genesis.
Full-Chain Anonymity (FCMP++)
Traditional privacy coins hide the sender among a small, fixed-size group of decoys — typically 11 or 16 possible signers per input. While observers cannot tell which one actually spent, the anonymity set is inherently limited. Shekyl takes a fundamentally different approach.
FCMP++ (Full-Chain Membership Proofs)
FCMP++ proves that the spent output exists somewhere in the entireset of outputs ever created on the chain — without revealing which one. There is no decoy selection, no ring construction, and no fixed anonymity window. The anonymity set is every output that has ever been added to the chain.
FCMP++ uses a curve tree— a Merkle-like data structure that organizes every output into a tree built over two alternating elliptic curves (Helios and Selene). When you spend, you prove your output is a leaf in this tree without pointing to it. The proof is compact, fast to verify, and reveals nothing about which output you own.
Curve Tree Structure
Each output occupies a leaf in the tree as a 4-scalar tuple (128 bytes) containing the output public key, key image, Pedersen commitment, and a hash of the post-quantum public key. The 4th scalar cryptographically binds the PQC key to the curve tree, creating the foundation for Shekyl’s dual-layer security model. The tree is append-only: spent outputs remain permanently so that removing them never reveals which output was spent.
Curve Tree
A Merkle-style tree over the full output set, alternating Helios and Selene curves. Every block commits to the tree root, anchoring proofs to a specific chain state.
Stealth Addresses
One-time destination addresses per transaction prevent observers from linking payments to recipients.
Confidential Amounts
Transaction amounts are hidden using Bulletproofs+ range proofs. Verifiers confirm amounts are valid without seeing them.
Dual-Layer Security
Every spend on Shekyl passes through two independent but linked verification layers. Both must succeed for a transaction to be valid.
- Zero-knowledge curve tree proof
- Full output set as anonymity set
- Commits H(pqc_pk) as 4th leaf scalar
- Hybrid Ed25519 + ML-DSA-65 signature
- Per-output keys from hybrid KEM
- M-of-N via scheme_id = 2
- Proves output exists in the full output set
- Full-chain anonymity — no decoy selection
- Binds PQC key hash inside the zero-knowledge proof
- Hybrid Ed25519 + ML-DSA-65 signature
- Quantum-resistant spend authorization
- Per-output keys from hybrid KEM derivation
An attacker must break both classical and post-quantum cryptography simultaneously to steal funds.
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 chain uses TransactionV3 as the required format for all user transactions. V3 uses FCMP++ full-chain membership proofs for anonymity and a dedicated hybrid authorization structure called pqc_auth for spend authorization.
The signed payload covers the transaction prefix, the FCMP++ proof 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.
Per-Output Quantum-Resistant Keys
Every output on Shekyl has its own post-quantum keypair, derived automatically during the sending process. When someone sends you coins, the transaction includes an encrypted key exchange using a hybrid KEM (Key Encapsulation Mechanism) that combines classical X25519 with ML-KEM-768 (a NIST-standardized post-quantum algorithm). From the shared secret, a unique ML-DSA-65 signing key is derived for each output.
Even if a future quantum computer breaks the classical cryptography, the post-quantum key protects your funds. And because every output has a different PQC key, compromising one output does not affect any other.
Bech32m Addresses
Shekyl uses a segmented Bech32m address format that carries both the classical keys and the post-quantum public key needed for hybrid key encapsulation. For everyday use, wallets display the short classical portion. The full address (including PQC material) is used behind the scenes when sending funds.
Security Goals
- Make it materially harder for a future quantum attacker to steal funds
- Preserve and enhance privacy mechanisms (FCMP++ full-chain anonymity, stealth addresses, confidential transactions)
- Use only NIST-standardized post-quantum primitives (ML-DSA, ML-KEM)
- Per-output PQC keys so compromising one output does not affect others
Post-Quantum Multisig
Shekyl uses a purpose-built post-quantum multisig system. Classical multisig has been removed entirely. All 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.
Architecture: Single Classical Key + PQC Multisig
The FCMP++ membership proof uses a single classical key held by the coordinator. The M-of-N threshold lives entirely in the PQC auth layer. This eliminates the dual-layer coordination problem: there is no sequencing of membership-proof multisig rounds followed by PQC signing rounds. The FCMP++ layer is always single-key; the PQC layer handles all multi-party authorization.
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.
On-Chain Indistinguishability
All multisig coordination happens off-chain via file-based signing rounds. On-chain, transactions are indistinguishable at the FCMP++ membership proof 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 (scheme_id = 1) | ~5.3 KB | baseline |
| 2-of-3 (scheme_id = 2) | ~12.5 KB | 2.4x |
| 3-of-5 | ~19.7 KB | 3.7x |
| 5-of-7 (consensus 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.
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 ships with FCMP++ (full-chain anonymity) and hybrid PQC spend authorization from genesis. Stealth address derivation remains classical. V4 addresses this gap with post-quantum stealth addresses and compact lattice threshold multisig. Shekyl follows a feature-driven upgrade policy: hard forks ship when the feature is ready, not on a fixed calendar.
V3 (HF1)
Active- FCMP++ full-chain membership proofs (entire output set as anonymity set)
- Hybrid spend authorization (Ed25519 + ML-DSA-65)
- Per-output PQC keys via hybrid KEM (X25519 + ML-KEM-768)
- M-of-N PQC multisig via signature list (scheme_id = 2, up to 7 participants)
- File-based multisig signing rounds with GUI wallet integration
- Bech32m segmented address format with PQC key material
- Multisig staking support for long-duration positions
V4: Research & Prototype
When ready- Post-quantum stealth address derivation
- Prototype lattice-based composite threshold multisig (scheme_id = 3)
- Compact lattice threshold signatures (fixed size regardless of M or N)
- 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 (anonymity set must not degrade)
- Hard fork activation with grace period for migration
- Full post-quantum privacy stack (stealth + membership + authorization)
During the V4 transition, V3 FCMP++ and multisig (signature list) remain valid. Wallets can offer both options. The V4 lattice threshold scheme will produce a single compact signature regardless of M or N, addressing the linear size scaling of the V3 multisig approach.