1. Introduction

Sahyadri Core introduces CSM — a sovereign digital money designed as a resilient, auditable, and highly accessible settlement layer. Sahyadri is a peer-to-peer monetary system built to enable trust-minimized value transfer at global scale while preserving simplicity, predictability, and broad participation. While avoiding the severe state-bloat of general-purpose Turing-complete smart contracts, the protocol focuses on secure, low-friction digital money coupled with native Web5 Decentralized Identity (DID) primitives.

Sahyadri is implemented on SahyadriDAG, a directed acyclic graph (DAG) data structure that permits parallel block creation by independent miners. Unlike traditional single-chain blockchains that discard concurrent blocks as orphans, SahyadriDAG embraces them: every valid block contributes to the ledger, and the Sahyadri Consensus protocol produces a single deterministic total ordering of all transactions. This eliminates the wasted-hash problem of single-chain designs.

The network is secured by SahyadriX — an application-layer Proof-of-Work combining Blake3 with an 8-stage XOR memory loop requiring 16 MB of random-access memory per hash operation. This architecture is genuinely memory-hard, compressing the performance gap between ASICs and general-purpose hardware, ensuring mining remains accessible to a broad population of participants.

Sahyadri operates on a hybrid Account + Object state model. Rather than tracking individual unspent outputs (UTXOs), the protocol maintains per-address balances and nonces. Each transaction atomically deducts from the sender and credits the receiver, with balance finality enforced at the block confirmation boundary. This model delivers account + object based ergonomics with the security of Proof-of-Work.

1.1 Key Protocol Parameters

2. Account + Object State Model

Sahyadri employs a hybrid Account + Object state model stored in RocksDB. Unlike pure UTXO systems which track individual unspent outputs, the account model maintains a global state table where each address has an associated balance (in CSM) and a monotonically increasing nonce. This eliminates the "dust" problem inherent in high-frequency UTXO systems at 1-second block times.

2.1 Account State Structure

Each account entry in RocksDB contains:

• address: CSM32-encoded public key hash (csm1...)
• balance: Current spendable balance in CSM (8 decimal precision)
• nonce: Transaction sequence number (prevents replay attacks)

When a transaction is confirmed in a block, the state transition is atomic:

2.2 Object Layer

The Object layer complements accounts by storing state commitments in a Merkle trie rooted in each block header. Each block header commits to an object-based state root — a hash cryptographically summarising the entire current ledger state. This enables efficient light-client verification via Merkle proofs, safe pruning once a state root is committed, and fast sync via verified state snapshots.

2.3 Why Not Pure UTXO?

At 1-second block times and 10,000 TPS, pure UTXO models generate millions of small outputs ("dust") that fragment user balances. The account model resolves this: each address maintains a single unified balance. Atomic state transitions at block confirmation boundaries ensure that partial updates are impossible — either the full transaction succeeds or the state remains unchanged.

2.4 Native Web5 Identity Anchoring

The Object layer serves as the cryptographic registry for Decentralized Identifiers (DIDs). Users can anchor their lightweight DID documents on-chain, acting as the foundational layer for Web5 Verifiable Credentials without congesting the consensus layer.

3. Transactions

A Sahyadri transaction is a cryptographically signed state-transition instruction authorizing a transfer of value from a sender account to a receiver account, subject to nonce validation, balance sufficiency, and fee payment. Transactions are pending until included in a miner-confirmed block; only then do balance changes take effect.

3.1 Transaction Structure

3.2 Full Transaction Lifecycle

3.3 Mempool and Pending Queue

The mempool is implemented as a PostgreSQL table (pending_transactions) rather than an in-memory structure. This provides persistence across node restarts, atomic conflict prevention via ON CONFLICT DO NOTHING, double-spend protection through locked-balance accounting, and 10,000 TX capacity per 1-second block.

Double-spend prevention in wallet.rs:

3.4 Mempool Fairness & Anti-Bot Shield

• Per-Account Rate Limit: Maximum 50 pending transactions per account in the mempool.
• Zero-Pending VIP Rule (Network Emergency): If mempool reaches 80% capacity, only addresses with 0 pending transactions are allowed to submit new TXs. This guarantees 100% uptime for genuine users during spam attacks.
• API Spam Shield: Wallet API enforces the 50 TX limit and returns HTTP 429 (Too Many Requests) to prevent database flooding before it hits the Rust node.

3.5 Nonce and Replay Attack Prevention

Every account carries a monotonically increasing nonce. The wallet API validates that the submitted nonce equals the current on-chain nonce, and increments it immediately on mempool acceptance. This prevents replay attacks — the same signed transaction cannot be submitted twice:

# wallet.rs — nonce validation if nonce != current_nonce: return error('Invalid nonce. Expected: %d' % current_nonce) # Immediately on mempool accept (before block confirmation): UPDATE accounts SET nonce = nonce + 1 WHERE address = %s

3.6 Transaction Fee Model

Sahyadri uses a fixed flat fee of 0.00001 CSM (1,000 Kana) per transaction, regardless of transfer amount. This is the lowest transaction fee of any major blockchain:

Method	Fee Model	Fee at $100 transfer
Sahyadri	Fixed flat (Kana)	0.00001 CSM (constant & negligible)
Payment Application	Percentage-based	$1.50 – $3.00
Bank Transfer (domestic)	Flat or percentage	$1.00 - $10.00
Bank Wire (international	Flat + hidden fees	$15.00 - $50.00
Money Transfer Service	Flat + percentage	$5.00 - $30.00

Even at CSM = $10,000 USD, the fee is only $0.10 per transaction. The fee is defined once in code and applies universally:

# wallet.rs + indexer.rs — single source of truth TX_FEE_KANA = 1000 # 0.00001 CSM — fixed forever TX_FEE_CSM = TX_FEE_KANA / 1e8 TX_FEE_MINER_SPLIT = 0.90 # 90% to block miner TX_FEE_TREASURY_SPLIT = 0.10 # 10% to sahyadri treasury

4. SahyadriX — Proof of Work

SahyadriX is the application-layer Proof-of-Work function used by the Sahyadri network. It combines Blake3 (a cryptographic hash function offering SIMD-optimized speed) with an 8-stage XOR memory loop operating over a 16 MB random-access memory pad. This construction is genuinely memory-hard: the evaluating device must maintain a 16 MB working set throughout computation, resisting ASIC implementations that rely on small, fast on-chip caches.

4.1 Algorithm (Rust Implementation)

// SahyadriX: Blake3 + 16MB RandomX-style Memory Loop // File: crypto/hashes/src/pow_hashers.rs const MEM_SIZE: usize = 16 * 1024 * 1024; // 16 MiB memory requirement const ROUNDS: usize = 1024; // random-access rounds (ASIC killer) const WINDOW: usize = 32; // bytes read per memory access pub fn hash(data: &[u8]) -> Hash { // Step 1: Initial Blake3 hash of block data let mut hasher = blake3::Hasher::new(); hasher.update(data); let mut current_hash = *hasher.finalize().as_bytes(); MEM_PAD.with(|pad| { let mut mem_pad = pad.borrow_mut(); // Step A: Fill 16MB memory deterministically from seed hash let mut seed_hash = current_hash; let mut i = 0usize; while i < MEM_SIZE { let mut h = blake3::Hasher::new(); h.update(&seed_hash); h.update(&(i as u64).to_le_bytes()); let out = h.finalize(); mem_pad[i..i+WINDOW].copy_from_slice(&out.as_bytes()[0..WINDOW]); seed_hash = *out.as_bytes(); i += WINDOW; } // Step B: 1024 random-access mixing rounds for _ in 0..ROUNDS { let idx1 = (u32::from_le_bytes(current_hash[0..4] .try_into().unwrap()) as usize) % max_index; let idx2 = (u32::from_le_bytes(current_hash[4..8] .try_into().unwrap()) as usize) % max_index; let mut h = blake3::Hasher::new(); h.update(¤t_hash); h.update(&mem_pad[idx1..idx1+WINDOW]); // random memory read 1 h.update(&mem_pad[idx2..idx2+WINDOW]); // random memory read 2 current_hash = *h.finalize().as_bytes(); } // Memory NOT wiped between hashes = maximum mining speed }); Hash::from_bytes(current_hash) }

4.2 PoW Bound to Block Contents

SahyadriX is cryptographically bound to the exact block template. Any change to block contents (transaction ordering, amounts) requires full recomputation — precomputation and silent reordering are infeasible:

// PowHash — connects SahyadriX to specific block pub fn finalize_with_nonce(&self, nonce: u64) -> Hash { let mut data = Vec::with_capacity(48); data.extend_from_slice(self.pre_pow_hash.as_bytes()); // block contents hash data.extend_from_slice(&self.timestamp.to_le_bytes()); data.extend_from_slice(&nonce.to_le_bytes()); SahyadriX::hash(&data) // 16MB computation over this exact template }

4.2.1 Comparative Design Philosophy

SahyadriX differs from existing Proof-of-Work algorithms in both memory profile and hardware optimization goals.

• RandomX emphasizes CPU-centric mining through a substantially larger memory dataset (~256MB), while SahyadriX utilizes a smaller 16MB random-access working set designed to balance participation between CPUs and GPUs.
• GPU-heavy approaches such as Sahyadri HeavyHash primarily optimize arithmetic throughput and matrix-style computation. SahyadriX instead focuses on repeated random-access XOR memory mixing, prioritizing memory latency constraints over raw parallel arithmetic performance.

The primary objective of SahyadriX is not to eliminate specialized hardware entirely, but to compress the efficiency gap between commodity hardware and ASIC implementations sufficiently to preserve broad mining accessibility.

4.3 Device Balance Comparison

Device	Memory	SahyadriX Compatibility	Relative Efficiency
ASIC (custom)	Limited on-chip	Constrained by 16 MB req.	~2-3x GPU
GPU (consumer)	4+ GB VRAM	Full parallel execution	Baseline
CPU (modern)	System RAM	Competitive single-thread	~0.3-0.5x GPU

4.3.1 ASIC Resistance Philosophy

SahyadriX does not claim absolute ASIC resistance. The objective is to continuously preserve broad mining accessibility by maintaining a Proof-of-Work design that prioritizes memory-latency costs and real-world hardware balance rather than raw arithmetic throughput. The protocol may evolve its memory-hard parameters through future network upgrades when necessary to maintain the intended security model, reduce excessive hardware centralization, and preserve competitive participation across general-purpose computing devices. As with all Proof-of-Work systems, long-term hardware dynamics are expected to evolve over time. Sahyadri therefore treats ASIC resistance as an ongoing security objective rather than a fixed one-time property. Independent benchmarking, public research, and real-world network data will continue to guide future optimization decisions.

4.4 Post-Quantum Signature Layer

All wallet signatures in Sahyadri are secured using ML-DSA (CRYSTALS-Dilithium-3), a NIST-standardized post-quantum digital signature scheme. Transaction authentication, account ownership, and DID control rely on Dilithium-3 keypairs rather than classical lattice-based post-quantum cryptography.

The consensus layer remains independent of the signature algorithm, allowing future cryptographic upgrades without affecting monetary rules, block production, or Sahyadri Consensus.

5. Network Architecture

The Sahyadri network operates as a fully decentralized peer-to-peer system. Nodes communicate over three primary channels: gRPC (port 26110) for client-node communication used by the indexer and wallet API; P2P (port 26111) for block and transaction propagation between nodes; wRPC/WebSocket (port 27110) for browser-based and light-client interfaces.

5.1 Full System Architecture

SAHYADRI NETWORK ARCHITECTURE ┌─────────────────────────────────────────────────────────┐ │ sahyadrid (Rust Node) │ │ RocksDB: accounts { address, balance, nonce } │ │ SahyadriDAG: parallel blocks, 1s finality │ │ SahyadriX PoW: Blake3 + 16MB memory loop │ │ coinbase.rs: 0.08318123 CSM reward, 4yr halving │ └──────────────────┬──────────────────────┬───────────────┘ │ gRPC :26110 │ P2P :26111 │ │ ┌──────────────────▼───────┐ ┌──────────▼──────────────┐ │ indexer.rs │ │ Other Sahyadri Nodes │ │ - Historical sync │ │ worldwide (P2P gossip) │ │ - Live block listen │ └─────────────────────────┘ │ - 1s reward merge │ │ - TX confirmation │ │ - Fee 90/10 split │ └──────────────────┬───────┘ │ SQL ┌──────────────────▼───────────────────────────────────┐ │ PostgreSQL Database │ │ blocks | transactions | pending_transactions │ │ rewards | accounts │ └──────┬───────────────────────────────────┬───────────┘ │ REST :3000 │ REST :5000 ┌──────▼──────────────┐ ┌─────────────▼─────────────┐ │ server.js │ │ wallet.rs │ │ Block Explorer API │ │ Send TX | Balance | Fee │ └──────┬──────────────┘ └─────────────┬─────────────┘ └──────────────────┬─────────────────┘ │ ┌─────────────────────────▼──────────────────────────────┐ │ Frontend: sahyadri-scan Explorer + wallet.html │ └────────────────────────────────────────────────────────┘

5.2 Node Types

Node Type	Data Retained	Use Case	Storage
Full Archive Node	All blocks + full TX history	Explorer, auditing	Growing (GB–TB)
Pruned Full Node	Current state + recent blocks	Mining, validation	5–10 GB stable
Light Client	Block headers + Merkle proofs	Wallet verification	Minimal

5.4 Network Security Matrix and Post-Quantum Evolution Strategy

Continuous state execution inside high-throughput DAG architectures introduces strict boundaries regarding block propagation times and state-bloat minimization. Traditional linear frameworks face critical architectural traps when trying to handle the high byte-load required by post-quantum cryptographic primitives like Crystals-Dilithium (ML-DSA) or SPHINCS+ (SLH-DSA). A standard 4KB signature block at a targeted 10,000 Transactions Per Second (TPS) results in a network overhead expansion of roughly ~40MB per slot, which chokes regular consumer internet configurations and violates the principles of pure decentralization.

To reconcile our hard design goals of 10,000 TPS, 1-second finality, and total network sovereignty, the Sahyadri protocol decouples client-side cryptographic latency from physical ledger mutations. Sahyadri executes a twin-tier evolutionary roadmap:

• Phase I (Genesis to Settlement): The transaction layer relies on standard high-efficiency hashing protocols ensuring 0.0001ms local wallet signing speeds. The public identity remains shielded on-chain via one-way cryptographic hashes of the destination variables.
• Phase II (Future Cryptographic Upgrades): The system integrates a native Abstract Crypto Pipeline Layer. When cryptographic migrations become mandatory across global financial markets, the layer expands to support future post-quantum signature schemes beyond Dilithium-3 while maintaining backward compatibility. These heavy outputs are processed utilizing off-chain distributed ZK-Prover clusters (such as Plonky3 frameworks) which compress the heavy 4KB signatures into singular, computationally light ~500-byte verification tokens before they are ordered canonically by the Sahyadri Consensus mechanism. This preserves our lightweight block limits while guaranteeing military-grade, long-term quantum security from cold storage up to active node execution.

6. Consensus — SahyadriDAG

Sahyadri Consensus is a deterministic finality engine that operates on the SahyadriDAG data structure to produce a single, total, immutable ordering of all blocks and transactions. Unlike probabilistic longest-chain consensus, Sahyadri provides absolute finality: once a block is finalized, its position in the ordering is permanent.

6.1 Parallel Block Production

Multiple miners may simultaneously mine different blocks at the same height. All valid blocks contribute to the ledger — none are discarded as orphans. The indexer handles parallel blocks with a second-buffer mechanism:

Second 1: ┌────────┐ ┌────────┐ ┌────────┐ │Block A │ │Block B │ │Block C │ (all valid, same second) └────┬───┘ └────┬───┘ └────┬───┘ └────────────┴────────────┘ │ Sahyadri Consensus: deterministic ordering │ ┌────────────▼────────────┐ │ FINALIZED BLOCK SET │ (all 3 contribute to DAG) │ 1 combined miner reward │ (from best_block_hash) └─────────────────────────┘
# indexer.rs — second-buffer grouping second_buffer = defaultdict(list) # timestamp_sec -> [blocks] def process_block(block, conn): timestamp_sec = timestamp_ms // 1000 second_buffer[timestamp_sec].append(block) if timestamp_sec > last_second: flush_second(last_second, second_buffer[last_second], conn)

6.1.1 Deterministic BFT-Equivalent Finality

Sahyadri Consensus achieves BFT-equivalent deterministic finality through mathematical DAG ordering rather than validator voting. The Sahyadri Score calculation — defined as the size of the largest mutually-referencing finalized cluster within the DAG — is independently computable by every honest node without coordination or leader election.

Because every node deterministically derives the identical total ordering from the same finalized DAG structure, the network converges on a single immutable transaction history without requiring a validator committee, staking system, or delegated authority.

Under honest-majority assumptions, finalized blocks become computationally impractical to reorganize, providing deterministic finality characteristics comparable to Byzantine Fault Tolerant systems while preserving the permissionless security model of Proof-of-Work.

6.2 10,000 TPS Configuration

Transaction throughput is governed by max_block_mass in consensus parameters. Each account-model transaction has a mass of approximately 3,000 units:

// consensus/core/src/config/params.rs // Applied to all 4 configs: mainnet, testnet, simnet, devnet max_block_mass: 30_000_000, // Calculation: // 30,000,000 mass / 3,000 mass-per-tx = 10,000 TX per block // 10,000 TX per block × 1 block per second = 10,000 TPS

6.3 Dual Finality: Transaction vs. Reward

Block creation occurs in ~1 second, but deterministic financial finality (where rewards are issued) is achieved within a few seconds based on Sahyadri Score confirmation.

6.4 Finality Properties

Property	Sahyadri	Bitcoin	Ethereum
Finality type	Deterministic	Probabilistic	Probabilistic
Blocks for finality	1 block	6 blocks (~60 min)	~12 blocks
Reorg possible?	No	Yes	Yes
Orphaned blocks	None (all contribute)	Yes (wasted hash)	Yes (uncles)

6.4.1 Security Assumptions and Finality Model

Sahyadri Consensus operates under the standard honest-majority assumption used by Proof-of-Work systems. Finality is deterministic once blocks are ordered and finalized within the SahyadriDAG. Network partitions, propagation delays, and temporary latency spikes may delay finalization but cannot create conflicting finalized histories among honest nodes. An attacker attempting to rewrite finalized history must control a majority of effective network hashpower and simultaneously overcome deterministic DAG ordering rules. Under honest-majority assumptions, finalized history remains immutable.

Formal security analysis, adversarial simulations, and independent academic review remain ongoing areas of future research.

6.5 Consensus Mechanics: Achieving Practical BFT Finality in Seconds and 10,000 TPS

• Unlocking 10,000 TPS with SahyadriDAG

The protocol’s theoretical throughput ceiling is derived from the configured max_block_mass parameter and transaction mass calculations. Based on current consensus parameters, the architecture is designed to support up to approximately 10,000 TPS under optimal conditions. Empirical benchmarking across geographically distributed live-node environments remains ongoing. Initial internal testing demonstrates stable high-throughput transaction processing under controlled conditions, while further public benchmarking and independent audits are planned.

Traditional blockchain architectures suffer from linear bottlenecks, where only one block can be processed and appended at a time. Sahyadri fundamentally shifts this paradigm by utilizing a Directed Acyclic Graph (DAG) structure. In the Sahyadri network, multiple miners can propose blocks concurrently. Because parallel blocks are not orphaned but instead cryptographically woven into the DAG, the network's throughput increases exponentially. This parallel processing architecture allows Sahyadri to scale up to 10,000 Transactions Per Second (TPS) without compromising the decentralized, permissionless nature of Proof-of-Work.

• Bridging PoW with 1-Second BFT Finality

Typically, Proof-of-Work relies on probabilistic finality (waiting for multiple block confirmations), which results in long settlement times. Sahyadri solves this by decoupling block generation from block finalization. While the PoW mechanism drives the rapid, parallel creation of blocks within the DAG, the Sahyadri Consensus algorithm calculates a deterministic 'Sahyadri Score' by weaving parallel blocks into a chronological order. Because the protocol relies on absolute mathematical ordering rather than probabilistic longest-chain rules, this hybrid approach delivers irreversible, BFT-grade deterministic finality within approximately 1 second—without requiring any centralized validator committee.

Once parallel blocks are proposed, the network's validation layer rapidly orders them and cryptographically attests to their position within the graph. Because BFT consensus relies on absolute voting thresholds rather than longest-chain rules, this hybrid approach delivers irreversible, deterministic finality within approximately 1 second. Users get the instant settlement of BFT with the robust security foundation of PoW.




In live network conditions, the Rust node accepts multiple parallel blocks per second (observed at ~5-10 BPS depending on hash rate), while the Indexer calculates deterministic Blue Score finality to issue rewards and state updates, perfectly maintaining the separation between rapid block creation and immutable financial finality.

6.6 Throughput Assumptions and Benchmarking

The 10,000 TPS figure represents the theoretical upper bound derived from consensus configuration parameters and transaction mass calculations. Actual throughput depends on network topology, hardware configuration, database performance, transaction composition, geographic node distribution, and propagation latency. The protocol includes RAM-based batching and optimized PostgreSQL insertion pipelines to reduce database bottlenecks. Public benchmark reports and independent performance measurements will be published separately.

7. Block Rewards and Fee Economics

Sahyadri's incentive structure combines predictable block issuance with a flat transaction fee. All monetary parameters are fixed at genesis and cannot be altered without a consensus-breaking hard fork.

7.1 Block Reward Calculation

// consensus/src/processes/coinbase.rs pub fn calc_block_subsidy(&self, blue_score: u64) -> u64 { // blue_score represents Sahyadri Score let base_reward: u64 = 8_318_123; // 0.08318123 CSM in Kana let halving_interval: u64 = 126_230_400; // 4 years at 1block/sec let halvings = blue_score / halving_interval; if halvings >= 64 { return 0; } // max supply protection base_reward.checked_shr(halvings as u32).unwrap_or(0) // bitshift halving } // Indexer split (indexer.rs) BLOCK_TREASURY_SPLIT = 0.02 # 2% sahyadri treasury BLOCK_MINER_SPLIT = 0.98 # 98% miner

7.2 Halving Schedule

Epoch (k)	Block Reward (CSM)	Years	Annual Emission	Cumulative
0 (Genesis)	0.08318123	0 – 4	~437,459 CSM	~437,459
1	0.04159062	4 – 8	~218,729 CSM	~656,188
2	0.02079531	8 – 12	~109,365 CSM	~765,553
3	0.01039765	12 – 16	~54,682 CSM	~820,235
...	...	...	...	...
63	~0	>252 years	~0	~21,000,000

"Halving is triggered by Sahyadri Score, not raw block count. Since parallel blocks exist in the DAG, raw block count is higher than Sahyadri Score. Halving occurs when Sahyadri Score reaches 126,230,400 (representing ~4 years of chronological time), maintaining the strict 21M cap."

8. Blockchain Indexer and Explorer

Because Sahyadri nodes prune old block data (retaining only current account state in RocksDB), a separate indexer captures and permanently archives the full transaction history in PostgreSQL. This two-tier architecture keeps nodes lightweight (5–10 GB) while the explorer maintains complete historical records.

8.1 Indexer Startup Sequence

INDEXER STARTUP (indexer.rs): 1. Connect to sahyadrid via gRPC localhost:26110 2. Query PostgreSQL: SELECT MAX(blue_score) FROM blocks 3. Historical sync: LOOP: getBlocksRequest(lowHash, includeTransactions=true) FOR each block WHERE blue_score > last_processed: process_block(block, conn) IF no new blocks: BREAK low_hash = last_batch[-1].hash 4. Subscribe live: notifyBlockAddedRequest → gRPC stream FOR each blockAddedNotification: getBlockRequest(hash, includeTransactions=true) process_block(block, conn)

8.2 Database Schema

Table	Key Columns	Purpose
blocks	block_hash, blue_score, timestamp	Block registry
transactions	tx_id, from_address, to_address, amount, fee, status, block_hash	All user TXs
pending_transactions	tx_id, from_address, to_address, amount, fee, nonce, status	Mempool queue
rewards	tx_id, block_hash, miner, amount, created_at	Mining rewards
accounts	address, balance, nonce	Current state cache

8.3 API Endpoints

API	Endpoint	Description
Explorer (port 3000)	GET /api/blocks	Recent blocks with pagination
Explorer	GET /api/block/:hash	Block detail + miner reward
Explorer	GET /api/address/:address	Balance + TX history
Explorer	GET /api/stats	Supply, wallets, total TXs
Wallet API (port 5000)	GET /api/balance/:addr	Current balance
Wallet API	POST /api/send-csm	Submit pending transaction
Wallet API	GET /api/nonce/:addr	Current nonce for address
Wallet API	GET /api/fee	Current network fee info

9. Disk Space and Pruning

The protocol architecture cleanly separates what the node keeps (current state) from what the explorer keeps (full history). This design keeps nodes permanently lightweight regardless of network age.

Node (RocksDB) KEEPS: Node AUTO-PRUNES: +---------------------------+ +---------------------------+ | Current account balances | | Raw block bodies (>30h) | | Current nonces | | Old transaction history | | Recent blocks (consensus) | | Old state snapshots | | DAG tips (new blocks) | | | +---------------------------+ +---------------------------+ Size: ~5-10 GB (stable) Grows then discarded PostgreSQL Explorer NEVER PRUNES: +---------------------------+ | Every block ever mined | | Every transaction ever | | Every reward ever issued | +---------------------------+ Size: grows continuously (full archive)

Storage estimates: 1M transactions ≈ 500 MB. At 10 TX/sec sustained: ~432 MB/day. At full 10,000 TPS capacity: ~4.3 TB/day. Current testnet load (1–100 TX/sec) generates manageable growth suitable for Oracle Cloud Free Tier (200 GB).

9.1 State Management: 30-Hour Pruning & Archival Offloading

High-throughput blockchains typically suffer from massive state bloat, making it prohibitively expensive to run a full node. Sahyadri addresses this through a strict Blue Score-based pruning architecture, separating lightweight consensus from archival storage.

• The Pruned Consensus Layer (Default): By default, Sahyadri nodes operate as pruned nodes. The protocol enforces a deterministic pruning depth calculated via a mathematical lower bound combining finality depth (12 hours), merge depth, and mergeset limits. With a default pruning duration of 108,000 seconds (30 hours), a 10 BPS network retains approximately 1,080,000 blocks of DAG history in its local RocksDB. This ensures that node storage remains extremely lightweight and stable (5-10 GB), allowing CPU/GPU resources to be dedicated entirely to securing the network rather than managing historical data.
• High-Throughput Batch Processing (10,000 TPS Engine): To handle the theoretical maximum of 10,000 TPS without bottlenecking at the database layer, the Sahyadri Indexer utilizes a RAM-based batch insertion engine. Instead of executing individual INSERT queries for each transaction, the indexer computes double-spend and nonce validations entirely in memory, calculating balance transitions as a unified state array. This data is then pushed to PostgreSQL using execute_values in massive arrays, reducing database round-trips from tens of thousands per block to just 4 optimized queries. This ensures 10,000 TPS is processed smoothly without latency.
• Archival Offloading via PostgreSQL: To preserve the immutability and availability of the complete transaction history for Block Explorers, CEXs, and audits, Sahyadri utilizes Archival Nodes. By running the node with the --archival flag, the protocol bypasses all local data deletion. The PostgreSQL Indexer connects to this Archival Node, seamlessly archiving all transactions into an external database.
• Mempool Pruning & Data Optimization: To prevent the mempool (pending_transactions table) from becoming a storage sink, the indexer implements automated 24-hour pruning. Transactions that have reached a terminal state (confirmed or rejected) are purged from the pending queue after 24 hours. This constant garbage collection ensures that the mempool only retains active, pending transactions, keeping query times minimal even under sustained high network load.
• Security against Misconfiguration: If an operator attempts to remove the --archival flag from a previously archival node, the node halts with an explicit warning and requires manual confirmation, preventing accidental data deletion and ensuring the integrity of the network's historical record.

10. Instant Payment Verification (IPV)

Instant Payment Verification allows lightweight clients to confirm transaction finality without downloading the full blockchain. Because Sahyadri uses deterministic consensus rather than probabilistic longest-chain, finality is absolute: a transaction confirmed in a block cannot be reversed.

A light client verifying a payment needs only: the finalized block header (contains state root and block hash), a compact Merkle inclusion proof linking the TX to the block, and proof that the block has been finalized by Sahyadri Consensus. Sahyadri IPV is immediate: 1 block confirmation = absolute finality. This enables:

The Merkle inclusion proof consists of:

(01) the transaction hash,
(02) sibling hashes along the path from the TX leaf to the state root,
(03) the finalized block header containing the state root.


Verification requires O(log n) hashes — feasible on any mobile device or embedded processor.

11. Web5 and Sovereign Identity

Sahyadri extends the concept of sovereignty beyond digital money into digital identity by natively supporting Web5 protocols at the base layer. Traditional Layer-1 networks treat identity as an afterthought, often relying on centralized off-chain servers or state-heavy smart contracts. Sahyadri integrates identity directly into its Account + Object model without compromising its 10,000 TPS capacity or 30-hour pruning architecture.

11.1 Decentralized Identifiers (DIDs)

Users can cryptographically generate and control a unique Sahyadri DID (e.g., did:sahyadri:csm1...). The DID document—containing only cryptographic public keys and service endpoints—is anchored in the Sahyadri Object state. This allows passwordless authentication and true self-sovereign ownership of digital identity.

11.2 Decentralized Web Nodes (DWNs) for State Efficiency

To maintain high throughput and prevent state bloat, heavy identity metadata (such as profile information, KYC documents, or encrypted messages) is never stored on the Sahyadri blockchain. Instead, the network utilizes Decentralized Web Nodes (DWNs). The on-chain DID simply points to the user's off-chain DWN, ensuring the Sahyadri consensus node remains ultra-lightweight (5-10 GB) while users retain absolute, censorship-resistant control over their personal data.

11.3 Verifiable Credentials (VCs) and Compliance

Sahyadri's native DID support enables seamless integration with institutional platforms, payment gateways, and Centralized Exchanges (CEXs) through Verifiable Credentials (VCs). Users can cryptographically prove real-world attributes (e.g., KYC clearance or jurisdiction) to an exchange without exposing their underlying sensitive data. This provides a compliant, privacy-preserving bridge between sovereign digital money and regulatory frameworks, solving the compliance trilemma natively.

11.4 Decentralized Web Nodes (DWN) and Encrypted Data Vaults

To complement the sovereign identity layer, Sahyadri implements a Local-First Data Architecture utilizing Decentralized Web Nodes (DWNs). This ensures that while the blockchain handles financial finality, the user's personal data remains under their absolute cryptographic control.

• Sovereign Storage & Encrypted Vaults
• Peer-to-Peer (P2P) Messaging Layer
• State Efficiency

12. Privacy

Privacy in Sahyadri is achieved by separating value transfer from identity. All transactions are publicly verifiable on the explorer, but the protocol does not associate transfers with real-world identities. Ownership is defined exclusively by cryptographic control of private keys using ML-DSA (CRYSTALS-Dilithium-3), a NIST-standardized post-quantum digital signature scheme.

Each user generates a CSM32 address derived from their public key. Users are encouraged to generate fresh key pairs for each receiving address. The Account model provides less transaction graph ambiguity than UTXO systems, but the protocol does not require identity disclosure. Sahyadri does not include built-in mixing or confidential transactions at the base layer — privacy emerges from standard cryptographic primitives and normal transaction behavior.

However, through the Web5 identity layer, users have the power of 'Opt-in Identity.' They can choose to selectively disclose verified attributes via Verifiable Credentials (VCs) when interacting with compliant entities or exchanges, maintaining a perfect balance between base-layer pseudonymity and institutional composability.

Each CSM32 address is a one-way hash of a Dilithium-3 public key. The mapping from address to real-world identity is never stored on-chain. Users are advised to generate a new address for each transaction to minimize transaction graph analysis.

13. Calculations and Economic Model

13.1 Emission Formulas

s_k = s_0 × 2^(-k) (block reward at epoch k)
I_k = H × s_k (total emission in epoch k)
S(n) = 2 × H × s_0 × (1 - 2^(-n)) (cumulative after n epochs)
S(∞) = 2 × H × s_0 = 21,000,000 CSM (hard cap)

Where s_0 = 0.08318123 CSM, H = 126,230,400 blocks (4 years at 1 BPS), k = halving epoch number.

13.2 Revenue and Fee Formulas

R_k = s_k + f_avg (total per-block miner revenue)
φ_k = f_avg / (s_k + f_avg) (fee fraction of revenue)
AnnualRevenue_k = r_yr × (s_k + f_avg) (r_yr = 31,536,000 blocks/yr)

13.3 Fee Revenue at Scale

Daily TX Volume	Daily Fee Revenue	Miner (90%)	Sahyadri Treasury (10%)
10,000 TX/day	0.1 CSM	0.09 CSM	0.01 CSM
1,000,000 TX/day	10 CSM	9 CSM	1 CSM
100M TX/day	1,000 CSM	900 CSM	100 CSM
864M TX/day (10k TPS full cap)	8,640 CSM	7,776 CSM	864 CSM

14. Security Model

14.1 Formal Conditions

Transaction signatures are validated using ML-DSA (CRYSTALS-Dilithium-3). The security of account ownership relies on post-quantum cryptographic assumptions rather than elliptic-curve discrete logarithms.

Verify(tx) = TRUE iff sig_valid(tx.sig, sender_pubkey) AND accounts[sender].balance ≥ (amount + fee) AND accounts[sender].nonce == tx.nonce
Accept(B) = TRUE iff VerifySahyadriX(B.header) AND ∀ tx ∈ B: Verify(tx) = TRUE AND ConsensusFinalized(B) = TRUE
P_attack = α (attacker hash fraction) For α < 0.5: attack is economically irrational After finalization: After deterministic finalization under honest-majority assumptions, the probability of successful reorganization approaches zero and becomes economically impractical.(deterministic)

14.2 Double-Spend Resistance

Double-spend attacks are prevented at four independent layers:

• Mempool layer: Pending locked balance check prevents overdraft before block confirmation
• Confirmation layer: Sender balance re-checked at confirmation; insufficient balance → TX rejected
• Nonce layer: Each TX carries a unique nonce; same nonce cannot be reused after increment
• Consensus layer: Finalized blocks are irreversible; deterministic ordering eliminates reorg risk

14.3 Network Layer Protection:

The P2P layer (port 26111) includes in-built IP banning for transaction flooding, protecting nodes from DDoS attacks at the network edge.

14.4 Post-Quantum Security

Sahyadri utilizes ML-DSA (CRYSTALS-Dilithium-3) for transaction signatures. The protocol therefore provides resistance against attacks enabled by large-scale fault-tolerant quantum computers that could compromise traditional elliptic-curve signature systems.

15. Governance

Sahyadri adopts a minimal governance model. All core monetary parameters are permanently fixed at genesis and not subject to modification through proposals or voting. The following are immutable at the protocol level:

• Total supply: 21,000,000 CSM
• Initial block reward: 0.08318123 CSM
• Halving interval: 126,230,400 blocks (~4 years)
• Minimum TX fee: 0.00001 CSM
• Block reward split: 98% miner / 2% sahyadri treasury
• TX fee split: 90% miner / 10% sahyadri treasury

Changing any monetary parameter requires a consensus-breaking hard fork, effectively creating a new chain. No central governance body, no token-weighted voting, and no on-chain governance process exists. The protocol evolves through rough consensus and running code.

15.1 Treasury Transparency

Treasury funds originate exclusively from protocol-defined allocations: 2% of block rewards and 10% of transaction fees. Treasury addresses are publicly visible on-chain and auditable through the Sahyadri Explorer. Treasury expenditures, development grants, infrastructure funding, audits, and ecosystem support initiatives are expected to be publicly disclosed to maintain transparency and community trust.

15.2 Security Audit Roadmap

The protocol intends to undergo independent security reviews covering: • Sahyadri Consensus • SahyadriX Proof-of-Work • Wallet Infrastructure • Dilithium-3 Integration • Indexer and Database Components Audit reports will be published publicly when available.

16. Threat Model

16.1 Hashpower Attacks

An adversary controlling a majority of network hashpower may attempt transaction censorship, delayed confirmations, or chain manipulation. Sahyadri Consensus increases attack cost by requiring dominance across both Proof-of-Work production and deterministic DAG ordering.

16.2 Spam Attacks

Spam attacks are mitigated through fixed transaction fees, mempool limits, per-account rate controls, and emergency admission rules.

16.3 Eclipse Attacks

Nodes maintain multiple peer connections and independently validate all received consensus data. Future releases may introduce additional peer diversity protections.

16.4 Long-Range Attacks

Deterministically finalized blocks are treated as immutable. Historical rewrites become computationally impractical under honest-majority assumptions.

17. References

[1] Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.

[2] Sompolinsky, Y., Zohar, A. (2015). Secure High-Rate Transaction Processing in Bitcoin (GHOST Protocol).

[3] Sompolinsky, Y. et al. (2020). PHANTOM and GHOSTDAG Protocols.

[4] O’Connor, J. et al. (2020). BLAKE3 Cryptographic Hash and PRF.

[5] W3C. (2022). Decentralized Identifiers (DIDs) v1.0.

[6] Aumasson, J. et al. RandomX Proof-of-Work Algorithm.

[7] TBD / Block Inc. Web5 Initiative — Decentralized Identity and Personal Data Sovereignty Architecture (2022).

[8] Dorsey, J. — Web5 and Decentralized Identity Discussions, TBD / Block Inc.

[9] Plonky3 Project – High Performance STARK Proving System.

[10] National Institute of Standards and Technology (NIST). FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA), 2024.

Ducas, L., Kiltz, E., Lepoint, T., et al. CRYSTALS-Dilithium: A Lattice-Based Digital Signature Scheme.

17. Conclusion

Sahyadri presents a comprehensive design for a sovereign peer-to-peer digital money system. By combining a directed acyclic graph data structure for parallel block production, a memory-hard Proof-of-Work algorithm for inclusive security, an Account + Object state model for simplified value transfer, and a fixed flat fee structure for predictable costs, the protocol achieves deterministic finality in seconds with high-throughput transaction processing. The strictly capped monetary supply, transparent halving schedule, and protocol-enforced immutable parameters provide a stable, auditable, and predictable foundation for global value transfer — digital money that works reliably, fairly, and forever.

---

View Whitepaper (PDF) Download Whitepaper (PDF)

Sahyadri Whitepaper
www.sahyadri.io