A payment network quantum-safe on every operation.
L2SOQ runs eLTOO payment channels with ML-DSA-44 co-signatures over Soqucoin's post-quantum Layer 1: a measured 1,710 end-to-end payments per second on a single 8-vCPU node, with two NIST FIPS 204 signatures behind every payment.
L2SOQ is a payment channel network in which every operation is authorized by post-quantum digital signatures. Built on the eLTOO channel-update protocol over Soqucoin's ML-DSA-44 Layer 1, L2SOQ sustains a measured 1,710 end-to-end payments per second on a single 8-vCPU cloud VPS, where each payment is co-signed by two ML-DSA-44 signatures (NIST FIPS 204). To our knowledge, no other payment network sustains four-figure throughput with post-quantum signatures on every operation.
We deliberately avoid head-to-head “faster than X” claims: a bilateral payment channel, a global-consensus L1, and a centralized card network measure fundamentally different things. The honest framing is that a single quantum-safe node reaches throughput in the same order of magnitude as a high-performance L1's user-transaction rate and the low end of a global card network's average authorization volume, while providing instant channel finality and quantum-safe custody at every layer.
Every major payment network and blockchain in production today relies on elliptic-curve cryptography (ECDSA or Ed25519) for transaction authorization. In August 2024, NIST finalized FIPS 204, standardizing ML-DSA (formerly CRYSTALS-Dilithium) as a signature algorithm for the post-quantum era. U.S. federal guidance targets migration away from quantum-vulnerable cryptography by 2035, with planning milestones earlier in the decade.
The problem is architectural. A blockchain's signature scheme is not a swappable component. It is bound into the genesis block, the address format, transaction serialization, the consensus rules, and every wallet that has ever generated a key. Retrofitting post-quantum signatures onto a chain that launched with ECDSA requires either a hard fork (breaking every existing address) or a hybrid scheme that carries the weight of both algorithms indefinitely.
Soqucoin took a different approach: launch from a fresh genesis block with ML-DSA-44 as the only signature algorithm. There is no classical cryptography in the consensus path, and no migration plan is needed because there is nothing to migrate from.
L2SOQ extends this property to the payment-channel layer. Where Bitcoin's Lightning Network uses LN-Penalty channels with ECDSA signatures, L2SOQ uses eLTOO channels with ML-DSA-44 co-signatures, so that quantum-safe cryptography authorizes every channel operation: opens, state updates, cooperative closes, and unilateral dispute resolution.
2.1 · Why eLTOO, not LN-Penalty
Lightning's original channel protocol (LN-Penalty, or Poon–Dryja channels) requires each party to retain every prior channel state in order to penalize a counterparty that broadcasts a revoked state. Storage grows linearly with the number of updates.
eLTOO replaces this with a simpler rule: any newer state can spend any older state, regardless of how many updates have occurred. This works because eLTOO update transactions use a rebindable sighash (SIGHASH_ANYPREVOUT), letting a signature commit to outputs without committing to a specific input outpoint.
For L2SOQ, eLTOO provides three advantages: constant storage (each party holds only the latest update and settlement transaction), simpler dispute resolution (the highest-sequence-number state wins; no penalty mechanism, no justice transactions), and clean co-signing (exactly two signatures per update, mapping directly onto ML-DSA-44 co-signing between the user's wallet and the LSP).
2.2 · Why ML-DSA-44 specifically
ML-DSA-44 (NIST FIPS 204, security category 2) was selected on three criteria: security margin, signature size, and signing cost.
| Property | ML-DSA-44 | ML-DSA-65 | ML-DSA-87 |
|---|---|---|---|
| NIST security category | 2 | 3 | 5 |
| Signature size | 2,420 B | 3,309 B | 4,627 B |
| Public-key size | 1,312 B | 1,952 B | 2,592 B |
| Relative signing cost | baseline | higher | highest |
Category 2 offers a security margin comparable to AES-128 against classical attack and is designed to resist quantum attacks against its underlying module-lattice problem. Because each channel state is signed fresh (there is no long-term key reuse accumulating signatures against a single key), category 2 is the right balance of margin and throughput for this workload.
The decisive empirical point (§5) is that signing is not the bottleneck: the signing engine sustained far more signatures per second than the end-to-end payment path required. ML-DSA-44's 2,420-byte signatures impose bandwidth and storage cost, but not a throughput ceiling at the rates we measured.
3.1 · System components
3.2 · Channel lifecycle
Open. A channel is established by funding a 2-of-2 ML-DSA-44 multisig output on Soqucoin L1. Both parties contribute public keys; the funding transaction is broadcast and confirmed on-chain. In the self-custodial configuration (validated in live testing, not yet the shipped app default), the user funds the multisig directly from the SoquShield wallet.
Update. Each payment creates a new eLTOO state: an update transaction (which can spend any prior update) and a settlement transaction (which distributes the balance after a CSV delay). Both parties co-sign each update with ML-DSA-44; the LSP persists the latest state to SQLite using group-commit batching.
Close (cooperative). Both parties sign a final settlement transaction that spends the funding output directly, bypassing the CSV delay, and the balance settles on-chain immediately.
Close (unilateral). If one party is unresponsive, the other broadcasts the latest update transaction, waits out the CSV delay, then broadcasts the settlement. If the counterparty holds a newer state they may broadcast it during the delay; the highest-sequence-number state always wins.
3.3 · State persistence
Channel state is persisted to SQLite in WAL mode with synchronous=NORMAL. Group-commit batching coalesces multiple state writes into a single fsync, reaching roughly 3,700 persist operations per second on commodity cloud VPS hardware. A monotonic state index prevents rollback, and the recovery engine (LoadFromStore) restores all channel states on restart, including pending-funding channels not yet confirmed on-chain.
L2SOQ settles on Soqucoin Layer 1, which has the following properties:
- Consensus
- Scrypt Proof-of-Work (Bitcoin/Litecoin family)
- Signature algorithm
- ML-DSA-44 (NIST FIPS 204) exclusively
- Merged mining
- AuxPoW Scrypt parents (e.g. Litecoin) · chain ID 0x5351 · from genesis
- Block time
- ~60 s
- Emission
- 100,000 SOQ/block 4 halving epochs (250K blocks each) → 2,500 tail · ~46.875B head · no cap · no premine
- Audit
- Halborn 30/30 remediated (L1)
- eLTOO support
- ANYPREVOUT + CTV
4.1 · Post-quantum from genesis
Soqucoin's L1 uses ML-DSA-44 as its sole signature algorithm from genesis block zero. There is no classical signature path: the ECDSA/secp256k1 verification code has been removed from the consensus engine. Every address is derived from an ML-DSA-44 public key; every transaction, including each coinbase, is signed with ML-DSA-44.
L2SOQ channels therefore inherit quantum safety by construction. The 2-of-2 multisig funding output uses ML-DSA-44 public keys; co-signed state updates use ML-DSA-44 signatures; settlement transactions resolve to ML-DSA-44 addresses. At no point in the channel lifecycle does classical cryptographic material participate in value custody.
4.2 · Practical Attestation Technique (PAT)
Soqucoin's consensus includes the Practical Attestation Technique (patent pending), a Merkle-based scheme for aggregating ML-DSA-44 signatures into a constant-size 100-byte commitment at the block level.
To be precise about the compression (because the distinction matters under scrutiny), the 100-byte figure is the commitment, and full on-chain verification carries an additional witness. For a batch of n = 1,024 signatures the realistic on-chain footprint is approximately 98 KB (a 100-byte commitment, a ~320-byte Merkle path, and ~98 KB of witness triples), versus roughly 2.5 MB for the raw signatures, an end-to-end reduction of about 25×. The commitment alone is ~24,780× smaller than the raw signature set. At the L2SOQ settlement boundary, PAT lets batched channel-close settlements impose materially lower signature bandwidth on the L1 than carrying raw 2,420-byte signatures would.
5.1 · Test environment
- Hardware
- 8 vCPU · 16 GB RAM DigitalOcean droplet
- Storage
- Network-attached SSD
- OS
- Ubuntu 24.04 LTS
- Driver
- loadupdatebench (Go) co-located with the LSP on the same VPS
- Concurrency
- C = 128
- Measurement
- Internal benchmark · 2026-06-26
5.2 · What was measured
Each “payment” executes the full end-to-end path, with no mock signing and no in-memory-only state:
- Validate the request (amount, channel state, balance).
- Construct the eLTOO update and settlement transactions.
- Co-sign both with ML-DSA-44 (two round-trips to the signer; two 2,420-byte signatures).
- Persist the new channel state to SQLite (WAL, group-commit).
- Return confirmation to the caller.
5.3 · Results
| Stage | Persist TPS | End-to-end TPS | Change |
|---|---|---|---|
| Original (pre-fix) | ~175 | ~175 | modernc.org/sqlite ignored the WAL pragma; full fsync per commit |
| Step 0: WAL pragma fix | ~3,500 | ~1,440 | Explicit journal_mode=WAL; synchronous=NORMAL |
| Step 1: Group-commit + lock fix | ~3,700 | ~1,710 | Batch writes; release the manager mutex before persist |
Final measured result: 1,710 end-to-end payments per second on this node.
5.4 · Component rates and the binding constraint
We want to be careful about why 1,710 is the ceiling, because the honest answer is “not fully isolated yet.” Signing ran far above the payment rate; SQLite persist (group-commit) reached ~3,700 writes/s, roughly twice the end-to-end rate. Two factors bound the result and we have not cleanly separated them: disk fsync latency on virtualized cloud storage, and driver co-location: the benchmark driver shares the same 8 vCPUs as the LSP and signer, so a meaningful share of CPU generates load rather than serving it.
The clear, defensible finding is the negative one: post-quantum signing did not impose the limit. Whether the next bottleneck is storage or driver contention is the subject of follow-up benchmarking (§7).
5.5 · What did not move the needle
An in-process signer (eliminating HTTP), a Unix-domain-socket signer, and raising concurrency past C = 128 each produced no significant gain: transport was not the constraint and throughput plateaued. The one-time software win (175 → 1,710, ~9.8×) came from the WAL pragma and group-commit fixes, consistent with a constraint that is storage- and/or CPU-contention-bound rather than protocol-bound.
| Network | Layer | Throughput | What it measures | PQ? |
|---|---|---|---|---|
| Bitcoin L1 | Base | ~7 | On-chain confirmed txs (~1 MB / ~10 min blocks) | No |
| Bitcoin Lightning | L2 | n/a | Mostly private; no authoritative per-node or network figure | No |
| Ethereum L1 | Base | ~15–30 | On-chain txs (12 s blocks, variable gas) | No |
| Arbitrum / Optimism | Rollup | tens | Sequencer throughput, sustained (bursts higher) | No |
| Solana | L1 | ~1,000s | Non-vote user txs; disputed, varies by measurement | No |
| Visa | Central | thousands | Authorization messages; peak ~65K on global infra | N/A |
| L2SOQ (measured) | L2 chan. | ~1,710 / node | End-to-end: validate + persist + 2× ML-DSA-44 co-signs | Yes |
6.1 · vs. Bitcoin L1
On a single node, L2SOQ processes roughly two-and-a-half orders of magnitude more payments per second than Bitcoin's base layer (~1,710 vs. ~7), with the caveat we apply to every cross-layer comparison: this is an L2 channel node versus a global base layer, not a like-for-like benchmark. Both use a UTXO model, and L2SOQ payments resolve to on-chain settlement via eLTOO closes.
6.2 · vs. Bitcoin Lightning
A direct comparison is not possible: Lightning publishes no authoritative per-node or network-wide payment-throughput figure, because most channel activity is private. The meaningful difference is architectural. Lightning uses LN-Penalty channels with ECDSA; L2SOQ uses eLTOO channels with ML-DSA-44. We make no claim about relative volume.
6.3 · vs. Solana L1
L2SOQ's single-node throughput is in the same order of magnitude as Solana's measured non-vote user-transaction rate, but the architectures differ fundamentally: Solana reaches global consensus across thousands of validators for every transaction, whereas L2SOQ updates are bilateral between two channel parties. We do not claim L2SOQ is “faster than Solana.” The defensible statement is narrower: a single quantum-safe node on commodity hardware reaches four-figure throughput.
6.4 · vs. Visa
A single 8-vCPU node reaches the low end of Visa's reported average authorization volume. Visa's peak capacity (tens of thousands of messages per second on decades of global infrastructure) is far higher. The claim is not “faster than Visa”; it is that one decentralized node running post-quantum cryptography reaches a card-network-scale floor.
6.5 · The differentiator
We are not aware of another payment network that sustains more than 1,000 payments per second with post-quantum signatures on every operation. Every other network in the table relies on classical cryptography (ECDSA or Ed25519) that U.S. federal guidance targets for migration. L2SOQ uses FIPS 204 ML-DSA-44 and reaches comparable per-node throughput despite 2,420-byte signatures (vs. 64-byte ECDSA).
7.1 · Vertical scaling (projected, not yet validated)
Because we have not isolated the binding constraint (§5.4), the figures below are engineering projections, not measurements. They will be validated on dedicated hardware before any are presented as results.
| Lever | Expected impact | Rationale |
|---|---|---|
| Move the load driver off-box | unknown, possibly large | The co-located driver consumes CPU that could serve payments; cheapest thing to test first |
| More CPU cores (same storage) | uncertain | Depends on whether the limit is CPU contention or storage |
| NVMe VPS or bare metal | est. 3–10× | If storage-bound: NVMe fsync (~0.05–0.5 ms) vs. network SSD (~several ms) |
The first experiment is to move the driver off-box and re-measure; only then can the storage-vs-CPU question be answered and the NVMe projections confirmed or discarded.
7.2 · Horizontal scaling (more nodes)
Each LSP node is independent: its own database, signer, channels, and HTTP server, with no shared state. Off-chain payment throughput therefore scales nearly linearly with node count: roughly ~1,700/s measured on one node, ~5,100/s projected on three, ~17,000/s projected on ten, with operating cost scaling roughly linearly. Linearity is bounded in practice by channel routing (users connect to one node, so load balancing is needed), L1 settlement (opens/closes share block space), and liquidity (each node funds its own channels).
7.3 · Theoretical ceiling
With signing well above the payment rate and storage no longer the limit, per-node throughput would be bounded by the signing engine (a function of the NIST-standardized algorithm and available CPU), and a multi-node cluster would aggregate from there. Reaching that regime depends on the storage and driver work in §7.1; we present it as a direction, not a number.
L2SOQ does not operate in isolation. Soqucoin Labs has developed the SOQ-TEC cross-chain gateway (“Quantum Express,” patent pending) and the XMSS-Lite Revolving Vault (patent pending) to enable post-quantum asset transfers between Soqucoin and external blockchains.
8.1 · SOQ-TEC Quantum Express
Phase 1 (instant receipt, < 30 s). On detecting an irreversible token burn on the source chain (e.g., Solana), the relayer releases the equivalent SOQ on Soqucoin L1. Security derives from the physical irreversibility of the burn, not from an economic bond or challenge period.
Phase 2 (deferred PQ attestation, ~every 60 blocks). Pending receipts are aggregated, reconciled, and signed with ML-DSA-44 threshold signatures, and the attestation Merkle root is published to both chains.
The bridge vault uses ML-DSA-44 exclusively for custody, with no classical cryptography in the signing path. pSOQ on Solana is designed to bridge 1:1 to SOQ at mainnet.
8.2 · End-to-end quantum-safe custody
Combined with the XMSS-Lite Revolving Vault on the source-chain side, the custody chain is post-quantum at every step:
- User opens an XMSS-Lite vault on Solana (WOTS+ hash-based signatures).
- Bridges out via WOTS+ sign → Quantum Express relay → SOQ released under ML-DSA-44 custody.
- Opens an L2SOQ channel with ML-DSA-44 co-signing.
- Transacts within the channel via ML-DSA-44 state updates.
- Bridges back, minting directly into the XMSS-Lite vault.
Post-quantum signatures gate every custody operation in this flow; on the Solana side the vault adds a WOTS+ authorization layer above the chain's native Ed25519 runtime.
9.1 · Channel security
Liveness. Either party can unilaterally close by broadcasting the latest state. The CSV delay (configurable; default 144 blocks ≈ 2.4 hours) gives the counterparty a window to respond with a newer state if one exists.
Safety. eLTOO guarantees the latest state wins; there is no penalty mechanism. An old state broadcast by a malicious counterparty is simply superseded by the latest state.
Quantum resistance. Every state transition is authorized by ML-DSA-44. An adversary with a quantum computer cannot forge a newer state without the private keys.
9.2 · Signer security
The soq-signer service implements layered defenses: a fleet health gate (a BOOTING → HEALTHY → DEGRADED → UNSAFE → HALTED state machine that gates all signing on fleet-wide health), UTXO verification (querying gettxout on-chain to confirm cached values before signing, preventing sighash mismatches from stale values), and multi-node broadcast (relaying signed transactions to multiple independent nodes for redundancy).
9.3 · Recovery
The LSP recovery engine restores all channel states on restart, including pending_funding channels, and the watchtower client re-arms monitoring for recovered channels. Funding outpoints (txid and vout) are preserved through recovery so that confirmFunding verification succeeds.
Soqucoin Labs has filed a portfolio of U.S. provisional patent applications with the USPTO covering technologies described in this paper and the broader Soqucoin platform. Applications are assigned to Soqucoin Labs Inc.
| Title | Relevance to L2SOQ |
|---|---|
| Practical Attestation Technique (PAT) | Block-level signature aggregation for L1 settlement |
| Lattice-BP++ Post-Quantum Privacy | Future: private L2 channel balances |
| Post-Quantum Wallet (SoquShield) | ML-DSA-44 key generation for channel participants |
| LatticeFold UTXO-Bound Batch Verification | Batch verification of settlement transactions |
| XMSS-Lite Revolving Vault | Cross-chain custody without classical key exposure |
| Quantum Express Cross-Chain Transfer | Sub-30 s bridge with deferred PQ attestation |
| USDSOQ Post-Quantum Stablecoin | Stablecoin issuance |
| PQ Compliance Assessment (PQCAT) | Enterprise PQ-readiness scanning; HNDL risk quantification |
Patent pending. Application numbers on file with Soqucoin Labs.
L2SOQ demonstrates that post-quantum cryptography does not require sacrificing payment-network performance. A single 8-vCPU cloud node sustains 1,710 end-to-end payments per second with ML-DSA-44 co-signing on every payment, and signing is comfortably above that rate. The limiting factor is infrastructure (storage and/or load-driver contention), not the cryptography.
What the measurements support
- 1,710 quantum-safe payments per second on a single commodity 8-vCPU cloud node, end-to-end.
- Roughly two-and-a-half orders of magnitude more payments per second than Bitcoin's base layer, per node (an L2-channel-vs-base-layer comparison, §6.1).
- To our knowledge, the only payment network sustaining four-figure throughput with post-quantum signatures on every operation.
- Per-node throughput in the same order of magnitude as a high-performance L1's user rate and a card network's average-volume floor.
- Near-linear horizontal scaling across independent nodes.
What we are not claiming
- “Faster than Solana”: different architecture (bilateral channel vs. global L1 consensus).
- “Faster than Visa”: Visa's peak is far higher, on global infrastructure.
- Any vertical-scaling multiple (NVMe, bare metal) as a result: those are projections until benchmarked.
- Any aggregate multi-node figure beyond the single measured node.
The path to higher per-node throughput is identified (isolate and remove the infrastructure constraint: off-box driver first, then faster storage), and we will validate it on dedicated hardware before mainnet. Every other network in this paper is secured by cryptography that federal guidance has scheduled for migration. L2SOQ is not.
- [1] C. Decker, R. Russell, A. Osuntokun. “eltoo: A Simple Layer-2 Protocol for Bitcoin.” 2018.
- [2] NIST FIPS 204. “Module-Lattice-Based Digital Signature Standard (ML-DSA).” August 2024.
- [3] NIST SP 800-208. “Recommendation for Stateful Hash-Based Signature Schemes.” October 2020.
- [4] Halborn Security. “Soqucoin L1 Security Assessment.” 2026. 30/30 findings remediated.
- [5] Visa Inc. “Visa Fact Sheet.” 2025.
© 2026 Soqucoin Labs Inc. · 228 Park Ave S, PMB 85451, New York, NY 10003 · Patent applications pending · Halborn-audited (L1) · Fair-launched