TSN — a post-quantum, privacy-first Layer 1.

Abstract

TSN (Trust Stack Network) is a Layer-1 blockchain written entirely in Rust, designed from the ground up to withstand quantum attacks. Unlike existing blockchains that will eventually need to migrate their cryptography, TSN natively integrates NIST post-quantum standards: ML-DSA-65 (NIST FIPS 204) signatures, the Poseidon2 hash function optimized for arithmetic circuits, and the Plonky2 proofs proof system with transparent setup.

The project represents 79,500 lines of Rust code spread across 312 files, structured into 16 modules, with hundreds of git commits. The codebase compiles cleanly against stable Rust and follows idiomatic Clippy conventions.

1. Introduction

The emergence of quantum computing poses an existential threat to current cryptosystems. Shor's and Grover's algorithms, executed on a sufficiently powerful quantum computer, are capable of breaking RSA, ECDSA and most signature schemes used by today's blockchains — Bitcoin, Ethereum, Solana included.

TSN addresses this threat with a quantum-native approach: rather than grafting post-quantum protections onto an existing architecture, every layer of the protocol — signatures, zero-knowledge proofs, hashing — was designed for quantum resistance from day one.

Motivations

• Cryptographic urgency — NIST finalized its post-quantum standards in 2024. Existing blockchains have not yet migrated. TSN implements these standards natively.
• Rust performance — Rust guarantees near-C performance with memory safety and no garbage collector. Ideal for a blockchain node.
• Continuous development — a small team of specialized engineers covering architecture, core, cryptography, networking, devops and security.

Project goals

1. Provide a Layer-1 blockchain resistant to quantum attacks.
2. Implement the NIST PQC signature standard, ML-DSA-65 (FIPS 204).
3. Offer zero-knowledge proofs via Plonky2 proofs with transparent setup.
4. Maintain performance comparable to classical blockchains.
5. Provide comprehensive documentation and development tools.

2. Architecture

TSN follows a modular architecture composed of 16 interconnected modules. The codebase totals 79,500 lines of Rust spread across 312 files, organized according to the principle of separation of concerns.

Codebase modules

3. Post-quantum cryptography

The crypto module is the heart of TSN with 24,873 lines spread across 78 files. It implements three post-quantum cryptographic pillars, each resistant to known quantum algorithms.

3.1 ML-DSA-65 — digital signatures

NIST FIPS 204. ML-DSA-65 (Module-Lattice-Based Digital Signature Algorithm) is TSN's signature scheme, implemented on top of the fips204 Rust crate. Its security reduces to the hardness of the Module-LWE and Module-SIS problems over structured lattices — problems for which no efficient quantum algorithm is known, unlike the discrete-logarithm and factoring problems Shor's algorithm breaks.

Properties

• Stateless — no counter to maintain, simplifying key management.
• Lattice-based — security reduces to Module-LWE / Module-SIS hardness, not to hash-collision resistance alone.
• Fiat–Shamir with aborts — the signing paradigm used by the whole Dilithium/ML-DSA family.
• NIST standardized — a single parameter set, ML-DSA-65, used uniformly for every signature TSN produces.

3.2 Poseidon2 — ZK-friendly hashing

2,548 lines. Poseidon2 is an algebraic hash function optimized for arithmetic circuits (R1CS, Plonkish). It replaces SHA-256 in every context where a zero-knowledge proof must be generated over the hash.

Advantages over SHA-256

• Far fewer constraints in ZK circuits — roughly 300 for Poseidon2 versus roughly 30,000 for SHA-256.
• Optimized permutation — SPN structure with partial and full round functions.
• Native finite fields — operates over the Goldilocks field for proof-of-work and BN254 for legacy ZK circuits.
• Merkle trees — TSN's Merkle trees use Poseidon2 for ZK compatibility.

3.3 Plonky2 proofs — zero-knowledge proofs

2,290 lines. Plonky2 is the zero-knowledge proof system used by TSN. Developed by Polygon, it offers a critical property: transparent setup with no trusted ceremony.

Why Plonky2

• Transparent setup — no trusted ceremony required, fully verifiable.
• STARK-based — AIR security with hash commitments, inherently post-quantum.
• AIR arithmetization — Algebraic Intermediate Representation for flexible constraints.
• FRI commitment — Fast Reed-Solomon IOP, proven post-quantum secure.

4. MIK consensus

8,806 lines · 25 files. TSN uses a hybrid consensus mechanism called MIK — Mining, Identity, Knowledge — combining the resilience of proof-of-work with identity and reputation mechanisms.

Consensus components

• Mining (M) — proof-of-work with a numeric difficulty target and a 512-bit nonce. Mining uses Poseidon2 over the Goldilocks field, giving ASIC resistance and ZK-friendly hashing.
• Identity (I) — an identity system based on ML-DSA-65. Nodes accumulating seniority and a correct validation history receive a trust bonus.
• Knowledge (K) — a reputation mechanism based on the quality of proposed blocks: valid transactions, optimal size, propagation latency.

Difficulty adjustment

TSN's difficulty adjustment uses a sliding window with exponential dampening, avoiding the abrupt oscillations seen on Bitcoin. The adjustment interval is 72 blocks, giving more stable hashrate tracking. Target block time is held stable through a PID controller integrated into the consensus module.

Fork protection

• Heaviest chain rule — fork choice based on cumulative proof-of-work (sum of all block difficulties), not longest chain — the same approach used by Bitcoin Core.
• Max reorg depth of 100 blocks — any chain reorganization deeper than 100 blocks is rejected outright, regardless of cumulative work.
• Anti-fork sync gate — miners must be synchronized within 2 blocks of the network tip before they are allowed to submit new blocks.
• Checkpoint finality — every 100 blocks a checkpoint is established; no reorganization is permitted beyond the latest checkpoint.
• Genesis hash verification — every node verifies the genesis block hash at startup, preventing silent chain forks from misconfiguration.
• State snapshots — every 1,000 blocks a full state snapshot is saved, enabling fast synchronization for new nodes.
• Fast-sync protocol — new nodes can download a compressed state snapshot from any peer over HTTP, then sync only the missing blocks, cutting initial sync from hours to minutes.

TSN Upgrade Protocol (TUP)

TSN implements version-bits signaling for coordinated protocol upgrades. Each block header carries 3 version bits, allowing up to 7 simultaneous upgrade proposals. An upgrade activates once 75% of miners signal support within a measurement window, followed by a 200-block grace period for non-upgraded nodes to update.

5. Zero-knowledge proofs

Zero-knowledge proofs are a foundational pillar of TSN, enabling verification of a claim's validity without revealing the underlying data. TSN integrates ZK proofs at multiple levels of the protocol.

Applications in TSN

• Private transactions — amounts and addresses masked via Plonky2 circuits. Only the net balance is publicly verifiable.
• Proof of solvency — a node can prove it holds a sufficient balance without revealing the exact amount.
• Compact validation — Plonky2 recursive proofs allow compressing the verification of N transactions into a single proof.
• Anti-abuse faucet — the testnet faucet uses Plonky2 proofs to rate-limit requests without tracking IP addresses.

6. P2P network

18,148 lines · 43 files. The network module is the second-largest in TSN. It implements a complete P2P protocol with peer discovery, block/transaction propagation and distributed routing.

6.1 Kademlia DHT

2,098 lines. TSN uses the Kademlia protocol for its distributed hash table. Kademlia provides O(log n) discovery guarantees and natural resilience to node departures.

Implementation characteristics

• XOR distance — a symmetric distance metric between node identifiers.
• K-buckets — 256 buckets of size k=20, organized by logarithmic distance.
• 4 RPC primitives — PING, STORE, FIND_NODE, FIND_VALUE.
• Iterative lookup — alpha=3 parallel queries for discovery.
• PQ identity — node IDs are derived from ML-DSA-65 public keys.

Propagation protocol

Blocks and transactions propagate via a structured gossip protocol. Each node maintains a set of known peers and propagates messages epidemically with hash-based deduplication, including a back-pressure mechanism to prevent saturation during activity spikes.

7. Storage

1,822 lines · 8 files. TSN uses Sled as its embedded storage engine — a key-value database written in Rust offering performance comparable to RocksDB with an idiomatic Rust API.

Why Sled

• Pure Rust — no C/C++ dependencies, simplifying compilation and cross-compilation.
• Lock-free — concurrent operations without global locks.
• ACID — atomic transactions with write-ahead logging.
• Compression — built-in Zstd compression to reduce disk footprint.

Storage structure

8. Tokenomics

TSN's economic model is designed for fair distribution, progressive deflationary emission, and incentives aligned with network security.

Key parameters

Block reward distribution

Every block reward — starting at 50 TSN, halving every 4,200,000 blocks — is split three ways:

Distribution philosophy

• 100% mined — no pre-mine, no team or investor allocation. Every TSN in existence is distributed through mining.
• Transaction fees — an adapted EIP-1559 model: base fee burned, tip to miner. Deflation accelerates with adoption.
• Testnet faucet — free distribution on testnet via Plonky2 proofs, enabling testing without investment.

9. Node roles & incentives

TSN supports a multi-role node architecture where participants specialize based on hardware capability and economic goal. This keeps the network resilient while aligning incentives with the service each node actually provides.

Node types

Relay & prover incentives

Service nodes earn their share of the pool based on a scoring system: block-propagation priority, measured uptime, and a signed RelayReceipt used to claim rewards. Users lacking the hardware to generate ZK proofs locally can delegate to Prover nodes through a P2P marketplace protocol — a ProofJob request, a ProofQuote response, and a ProofResult delivered with the fee paid atomically.

Node identity

Each node is identified by a deterministic name derived from the Poseidon2 hash of its ML-DSA-65 public key. This gives human-readable identification without exposing IP addresses or requiring registration — names follow an adjective-noun pattern, e.g. "swift-falcon", "bright-zenith".

10. Proof system

TSN has migrated its entire zero-knowledge proof stack from Halo2 (PLONK-based) to Plonky2, a modular STARK proving framework developed by Polygon. Plonky3 was evaluated as a successor and not adopted; production proofs are Plonky2. This migration eliminated all elliptic curve dependencies, achieving truly post-quantum ZK proofs based on AIR arithmetization and hash functions.

Why Plonky2, and not Plonky3

• Truly post-quantum — STARKs rely only on hash function security (collision resistance), not discrete logarithm assumptions vulnerable to quantum attacks.
• No trusted setup — unlike Groth16/BN254, no ceremony required. Fully transparent.
• Modular architecture — supports multiple fields (Goldilocks, BabyBear, Mersenne31), hash functions, and commitment schemes.
• Performance — FRI-based proofs with fast recursive verification. Proven in production (SP1 zkVM, Polygon zkEVM).
• Single proof system — removed the complexity of maintaining both Halo2 and Plonky2 in parallel.

Migration plan

11. zkVM & smart contracts

TSN introduces a zero-knowledge virtual machine (zkVM) enabling programmable smart contracts while preserving privacy. Contracts execute off-chain inside ZK proofs — only the proof of correct execution is verified on-chain.

Architecture

• Off-chain execution — contract code runs on the user's machine or a Prover node. The chain only verifies the STARK proof of correct execution.
• Privacy by default — contract inputs, outputs and state transitions are hidden; only validity is proven.
• Plonky2 native — the zkVM is built directly on Plonky2's constraint system.
• Multi-asset UTXO — outputs carry an asset_id field, enabling multiple tokens on the same chain.

Capabilities

12. Launch timeline

13. Gold-backed stablecoin — ZST (post-mainnet)

After mainnet launch, TSN will introduce ZST (Zero Stable Token), a privacy-preserving stablecoin pegged to the price of gold (XAU), deployed as a Layer-2 smart contract on the TSN zkVM.

Mechanism

• 1 ZST = 1 gram of gold — value derived from the global gold spot price.
• Over-collateralized — users lock 150% of the ZST value in TSN as collateral.
• Decentralized oracle — multiple oracle nodes submit signed XAU/USD prices; the median is used as reference.
• Liquidation — positions below a 120% collateral ratio are automatically liquidated to maintain solvency.
• Shielded conversions — mint and burn operations use ZK proofs; the conversion amount stays private.

14. Conclusion

TSN represents a fundamentally different approach to building a blockchain. By integrating NIST post-quantum cryptographic standards from inception, TSN avoids the costly and risky migration that existing blockchains will eventually have to undertake.

With 79,500 lines of functional Rust across 16 modules — cryptography, networking, consensus, storage — and 113 test files, TSN has moved beyond the prototype stage into a substantial implementation.