TCC Chain — The Post-Quantum
Blockchain for the Next Decade

Executive Summary

TCC Chain is a next-generation Layer-1 blockchain engineered to survive the quantum-computing era. Every account, every transaction, and every block is secured by CRYSTALS-Dilithium3 — one of the algorithms standardized by NIST for post-quantum cryptography.

The project targets three core objectives: (1) long-term security through post-quantum cryptography, (2) high throughput via optimistic parallel execution (BlockSTM) and batched SMT commits, and (3) economic scalability through a stake-centric model with delegation, Cosmos-F1 rewards, and a complete suite of ERC-standard token primitives.

Background & Problem Statement

2.1 The Quantum Threat

Most production blockchains rely on ECDSA (secp256k1) or Ed25519. Both can be broken by Shor's algorithm once a sufficiently large quantum computer becomes available. Once a private key is derived from its public key, every asset tied to that address is permanently lost — including assets transferred years before.

"Harvest now, decrypt later" is a real concern: on-chain data is permanently public, and adversaries can store transactions today to decrypt them in the future. TCC Chain chooses prevention from block #0 rather than a painful migration after the fact.

2.2 The Sequential-Execution Bottleneck

Many L1s still execute transactions sequentially, wasting the CPU parallelism of modern hardware. As smart contracts become the dominant workload, sequential throughput simply cannot keep up. TCC Chain integrates BlockSTM at the core, scaling near-linearly with CPU cores.

2.3 Fair Staking Rewards

Naive "snapshot-per-block" reward distribution is easily gamed by time-of-snapshot delegation. TCC Chain adopts Cosmos F1 reward index — rewards accrue continuously and are time-weighted, irrespective of when delegators choose to claim.

Design Philosophy

The TCC Chain codebase was rewritten from scratch under six invariant principles:

1. Compile-first. No non-compiling code is committed. Every module ships with tests.
2. Strong types. Avoid ad-hoc Vec<u8> — use fixed [u8; N] arrays or newtype structs.
3. No unwrap on the main path. Errors flow through Result<T, Error> with thiserror.
4. Domain separation. One module per concern: crypto / tx / state / mempool / network / rpc.
5. Future-proof transaction format. Every tx carries version, chain_id, and expires_at from day one.
6. Single source of truth. One canonical signing_message definition shared between server and WASM client.

The consequence: any engineer reading any file in the repository sees consistent conventions, with no parallel "legacy version" and no dead code. The domain tag "tcc/v1/tx" prefixes every signed hash to prevent cross-protocol replay.

Post-Quantum Cryptography

4.1 Why Dilithium3?

CRYSTALS-Dilithium is a digital signature family based on the Module-LWE / Module-SIS lattice problems and has been officially standardized by NIST as a primary post-quantum signature scheme. Of its three security levels, TCC adopts Dilithium3 — a balance of signature size and verification speed, with classical security comparable to AES-192.

4.2 WASM SDK for Browser Clients

All Dilithium3 operations run directly in the browser via a precompiled WebAssembly module (web3-app/public/pkg/). The web wallet generates keys and signs transactions entirely offline — no seed material ever leaves the client.

4.3 Hashing & Domain Separation

Blake3 is the single hash function across the system: address derivation, signing messages, Merkle trees, and SMT. Each domain has its own prefix (tcc/v1/tx, tcc/v1/block, tcc/v1/leaf) to eliminate cross-layer collision risk.

Transaction Layout

TCC transactions are serialized with Protocol Buffers — cross-language and schema-versioned, the industry standard. The V1 layout is fixed with every field needed for future extensibility:

message Transaction {
  uint32  version    = 1;   // 1 = current, soft-fork format
  uint64  chain_id   = 2;   // 1 mainnet, 2 testnet, 3 devnet
  bytes   from       = 3;   // 32-byte Address
  bytes   to         = 4;   // 32-byte Address
  uint64  nonce      = 5;   // counter mode
  bytes   amount     = 6;   // u128 little-endian, 16 bytes
  uint64  gas_price  = 7;   // wei / gas
  uint64  gas_limit  = 8;
  int64   timestamp  = 9;
  int64   expires_at = 10;  // mempool drops tx past this
  Payload payload    = 11;
  bytes   signature  = 12;  // 4001 bytes (sig_type + raw)
  bytes   public_key = 13;  // 0 or 1952 bytes (empty = lookup)
}

Two fields are critical for attack resistance:

• chain_id — prevents replay between testnet/mainnet (EIP-155 style).
• expires_at — the mempool drops stale tx; the user controls timing.

After the first transaction, a public key is cached on-chain; subsequent transactions only need the address, saving ~35% of bytes per tx (4.1 KB versus 6.3 KB originally).

Consensus: Stake-Centric Proof-of-Stake

6.1 Stake-Centric (Not Validator-Centric)

Unlike the traditional "1 validator key = 1 stake" model, TCC Chain separates the owner key (which receives rewards) from the staking_address (the vault that holds bonded tokens). A single owner may operate N independent stake accounts, each with its own weight in leader election.

6.2 Stake Lifecycle

• StakeRegister — create a stake account, locking self_stake.
• StakeDelegate — a delegator sends tokens to a stake and receives shares.
• StakeUndelegate — withdraw with unbonding period, auto-claims F1 rewards.
• StakeDeactivate + StakeWithdraw — a validator exits the producer set.
• StakeSubmitEvidence — submit equivocation evidence for slashing.

6.3 Cosmos F1 Reward Distribution

Every validator maintains a global reward index that increases over time proportional to total rewards and total stake. When a delegator claims:

reward = stake_share × (index_now − index_at_delegation)

This is time-weighted and fair — long-term delegators receive exactly their share, never diluted by delegators who entered right before a snapshot. Auto-claim runs on Undelegate so rewards are never lost.

6.4 Liveness & Slashing

A combination of grace period, liveness percentage, and auto-rejoin cleanly distinguishes downtime (operational fault) from equivocation (malicious fault). Downtime only temporarily removes a validator from the producer set, with automatic rejoin. Equivocation directly debits the vault, and falling sub-MIN permanently revokes producer eligibility.

6.5 Auto-Reorg with Copy-on-Write SMT

State lives in a Sparse Merkle Tree with copy-on-write journaling 10 blocks deep. When a node observes a heavier chain, it rolls back to the common ancestor, replays the new fork's transactions — no stop/restart required.

BlockSTM — Optimistic Parallel Execution

TCC Chain integrates BlockSTM (inspired by Aptos) from Slice 44 — not as an add-on. The scheduler is built on rayon:

1. Sort transactions in deterministic order.
2. Spawn N worker threads to execute optimistically in parallel, each writing to a private RwSet.
3. Validate in order: if tx i's read set conflicts with tx j's writes (j < i), re-execute tx i.
4. Commit in order — no race conditions.

Hot Spot #1: Batched SMT Commits

Before Slice 48.A each SMT write was a separate RocksDB transaction. After consolidating into the SmtBatch typed cache with a single atomic write_batch flush:

The state-commit path is no longer a bottleneck — Phase 3 contract storage now has comfortable headroom (~57k slot writes per 10-second block budget).

Smart Contract Engine (Wasmer + CPI)

8.1 WebAssembly Virtual Machine

Contracts compile to WASM from the Rust toolchain (cdylib with opt-level=z + LTO). The runtime is Wasmer 4.4 with the Cranelift compiler and a metering middleware for precise per-instruction gas accounting.

8.2 Cross-Program Invocation (CPI)

Contracts invoke other contracts via the tcc_invoke host import. Specification:

• Depth limit: up to 4 levels (Solana standard).
• Gas budget: the caller declares a budget; any unused gas is refunded.
• Args passing: via tcc_get_args, with truncation signaling when the buffer is too small.
• Return data: via tcc_set_return; uniform ABI [status:4 LE][payload].

8.3 SPL-Style Token Program (shipped)

Unlike Ethereum (one contract per token), TCC adopts the SPL multi-mint pattern: a single program serves N tokens. Storage keys are namespaced by prefix:

• mint:<id> → JSON MintInfo (decimals, supply, authority, cap).
• bal:<mint>:<owner> → u128 LE balance.
• allow:<mint>:<owner>:<spender> → u128 LE allowance.

Full 9-instruction surface: initialize_mint, mint_to, transfer, burn, approve, transfer_from, balance_of, allowance, total_supply. A strict ERC-20 superset.

8.4 ERC-1155 Multi-Token (shipped)

A multi-token program with operator approval (set_approval_for_all), built-in NFT mode (decimals=0 + max_supply=1), and (next) batch operations with MAX_BATCH_COUNT=64.

8.5 Token-Standard Roadmap

• ERC-20 — covered by the SPL-style Token program. ✅
• ERC-1155 — multi-token (fungible + NFT, batch ops). 🟢 In progress.
• ERC-721 — dedicated NFT program (slice 48.D). 📋
• ERC-6551 — Token Bound Accounts. 📋

Node Architecture

Each node is a single Rust process (tcc-node) composed of multiple workers running concurrently on the Tokio runtime. Domains are cleanly separated and workers communicate through channels:

9.1 RocksDB Column Family Layout

9.2 Deployment Stack

TCC Chain ships with a production-ready Docker stack: a multi-stage image built with the mold linker, a Caddy reverse proxy with automatic Let's Encrypt certificates, and a tfdomain container routing public traffic to the backend. A 3-node devnet is available via docker-compose.devnet.yml for local fork/recovery testing.

9.3 Web3 Frontend

The web app (5 single-page HTML files) auto-detects its endpoint: localhost → :30100; production domain → /rpc same-origin via Caddy. The Dilithium3 SDK is precompiled to WASM with no browser-extension requirement. The pages are wallet.html (multi-account wallet), nodes.html + node.html (validator dashboards), and delegations.html (delegation management).

Comparison with Existing Layer-1s

TCC Chain does not aim to replace Ethereum, Solana, or Aptos. Its purpose is to be the post-quantum bedrock for long-term use cases — assets held for 10+ years, identity, on-chain legal contracts.

Tokenomics

11.1 Total Supply & Emission

TCC is the native coin; the smallest unit is wei (1 TCC = 10¹⁸ wei). Emission is capped:

11.2 Gas Model

Gas prices are denominated in wei/gas (u64, accommodating up to 10¹⁹). The per-block gas limit is generous enough for very large transaction batches. The faucet pool has its own dedicated wallet on devnet/testnet, with per-address throttling stored in the faucet column family (last_claim_at).

11.3 Staking Reward Distribution

Rewards accumulate in an epoch payout pot and are distributed at each epoch's start based on a locked delegation snapshot. Cosmos F1 indexing makes the result fair across time. Delegators can claim at any moment via tcc_claimRewards.

Use Cases

The combination of quantum-safety + parallel execution + WASM smart contracts opens up application areas that current L1s struggle to serve well:

Development Roadmap

TCC Chain ships in slices — each slice is a compiling, tested, deployable piece of functionality. Current status:

Phase labels marked "In progress" or "Queue" reflect engineering targets at the date above; specifics may shift with community input and benchmarks.

Technical Specifications

Core RPC Methods

• tcc_sendRawTransaction — submit a signed transaction (base64).
• tcc_getBalance — query a u128 balance.
• tcc_getNextNonce — fetch the next nonce.
• tcc_getTransaction — read a receipt by tx hash.
• tcc_listValidators — list active stake accounts.
• tcc_claimRewards — claim F1 rewards for a delegator.
• tcc_callContract — call a smart contract (read-only / mutating).

Governance, Security & Community

15.1 Security Model

• Cryptographic. Lattice-based Dilithium3, resistant to Shor and Grover. Blake3 with domain separation prevents cross-protocol replay.
• Economic. Slashing directly debits the vault; sub-MIN means permanent loss of producer status. Equivocation evidence can be submitted on-chain.
• Operational. Seed-sensitive RPCs (enable_dev_wallet_rpc) are gated by a config flag, OFF by default in production.
• Code. Zero cargo clippy warnings. Every public API ships with tests. CI blocks non-compiling merges.

15.2 Open Source

TCC Chain is released under the Apache-2.0 license. The full source, tests, and memory docs are public — see ARCHITECTURE.md and the memory/ folder for the design history of every slice.

15.3 Get Involved

To run a personal devnet, follow DEVNET_QUICKSTART.md. To operate a mainnet validator, read memory/deploy.md and memory/devnet-ops.md. Contributions go through standard review (CONTRIBUTING.md).

Frequently Asked Questions

Macroeconomic Model & Long-Term Vision

Tokenomics tells you the numbers. This chapter explains how the numbers create a self-sustaining economy — who plays, what they exchange, why cooperation beats defection, and where the system is going.

17.1 Network Actors

Four roles share the TCC network — each with a distinct cost, a distinct earning channel, and a distinct risk profile:

17.2 Value Flow (Operating Model)

Every block redistributes value through two streams. Inflation funds early security; fees take over as the chain matures.

17.3 Collaboration Model

The system is engineered so that cooperation is more profitable than defection at every level:

• Validators cannot run away with delegated stake. Tokens live in staking_address vaults that no private key controls. Withdrawal requires explicit Undelegate with an unbonding lock.
• Delegators discipline validators. Poor uptime, high commission, aggressive behavior → delegators leave → validator's earning power drops. The market self-corrects without a central referee.
• Developers grow the user base. Every dapp tx generates fees feeding validators and the dev fund, raising stake utility, attracting more delegation, and reducing TCC volatility — a positive flywheel.
• Slashing aligns incentives in extremis. Equivocation triggers permanent disqualification + vault debit. The economic cost dominates any rational attack value short of state-actor adversarial capital.

17.4 Sustainability — Why This Doesn't Collapse

Three structural properties keep the economy alive long after launch hype fades:

1. Capped emission. Base reward 100 TCC × halving every 3.15M blocks (~1 year) asymptotes to ~630M TCC ever issued. Holders are not diluted indefinitely.
2. Fee floor handover. Once block-reward halving drops below transaction-fee revenue, the network transitions to a fee-dominated economy without governance intervention. Same shape as Bitcoin's curve, different cryptography underneath.
3. Validator skin in the game. Producer status requires MIN_STAKE self-stake. Falling sub-MIN means permanent loss of producer rights. Long-term commitment is structural, not optional.

17.5 Long-Term Vision — Grand, But Honest

We are not chasing the highest transactions-per-second number. We are building the rail for assets that must still be safe in 2050 — when an estimated 20–50 million qubits will have been built somewhere, and "harvest now, decrypt later" stops being theory.

Glossary

Dilithium3

A post-quantum digital signature scheme based on Module-LWE, standardized by NIST. Security comparable to AES-192.

Blake3

A modern, parallelizable hash function, several times faster than SHA-256. TCC uses it everywhere with explicit domain separation.

BlockSTM

Software Transactional Memory for blocks — an optimistic parallel-execution algorithm that re-executes transactions whose read sets conflict with earlier writes.

SMT

Sparse Merkle Tree — a state-commitment structure with O(log n) proofs. TCC uses a Copy-on-Write variant that journals the last 10 blocks for auto-reorg.

CPI

Cross-Program Invocation — contract A calling contract B via a host import. TCC caps depth at 4 (Solana convention) with gas budgeting and refund.

Cosmos F1

A time-weighted, fair staking-reward algorithm: each validator maintains a global reward index, and each delegator earns (index_now − index_at_delegation).

Stake account

The producer unit in TCC. Unlike the traditional "validator-centric" model, one owner may operate N independent stake accounts with separate weights.

Stake-centric

TCC's philosophy: cleanly separate the owner key (which receives rewards) from the staking_address (the vault). Enables multi-stake per owner with isolated economic state.

Equivocation

A validator signing two different blocks at the same height. Evidence can be submitted on-chain via StakeSubmitEvidence, triggering slashing and permanent disqualification.

Unbonding period

The lock duration after Undelegate before tokens can be withdrawn. Protects the chain against long-range attacks: validators slashed during unbonding still get debited.

Gossipsub

A libp2p pubsub protocol used for transaction and block propagation. TCC has two topics: tcc/tx/v1 and tcc/block/v1.

Wasmer / Cranelift

A Rust-based WebAssembly runtime with a fast and safe JIT compiler. TCC integrates a metering middleware for precise gas accounting.

Wei

TCC's smallest unit: 1 TCC = 10¹⁸ wei. Mirrors Ethereum's convention.

Faucet

The devnet/testnet test-token dispenser. TCC isolates the faucet pool in its own wallet with per-address throttling via last_claim_at.

Mempool

The queue of unconfirmed transactions. TCC's mempool uses two DashMaps — by_hash and by_sender_nonce — for O(1) replace-by-fee.

RBF

Replace-By-Fee — submitting a new tx with the same (from, nonce) at a higher gas_price to displace the older one in the mempool. Deduplication is handled at the mempool layer.