Sahyadri — Whitepaper v2.0

Sahyadri

A Sovereign Peer-to-Peer Digital Money System

Suraj Datir
surajdatir3@gmail.com
www.sahyadri.io

Abstract. A purely peer-to-peer version of electronic cash, built as a sovereign digital money system, would allow online payments to be sent directly from one party to another without going through a financial institution. Existing proof-of-work networks solve the double-spending problem but limit throughput to a single linear chain, discarding valid blocks when multiple miners discover them simultaneously. We propose a solution based on a directed acyclic graph structure, which accepts every valid block and orders them into a single deterministic history through a novel consensus protocol. The network is secured by a memory-hard proof-of-work algorithm that compresses the gap between specialized and general-purpose hardware. State is managed through an Account + Object model, enabling direct balance transfers without tracking individual unspent outputs, while a strictly capped supply with disinflationary emission ensures predictable monetary economics. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the finalized DAG ordering as proof of what happened while they were gone.

Introduction
Account + Object State Model
Transactions
SahyadriX — Proof of Work
Network Architecture
Consensus — SahyadriDAG
Block Rewards and Fee Economics
Blockchain Indexer and Explorer
Disk Space and Pruning
Instant Payment Verification
Privacy
Calculations and Economic Model
Security Model
Governance
Conclusion

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. The protocol focuses on secure, low-friction digital money rather than general-purpose programmability.

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

Property	Specification
Ticker Symbol	CSM (Cryptographic Sovereign Money)
Smallest Unit	Kana — 1 CSM = 100,000,000 Kana (8 decimals)
Maximum Supply	21,000,000 CSM (hard cap, protocol-enforced)
Block Time	1 second (deterministic)
Throughput	10,000 TPS (max_block_mass: 30,000,000)
Initial Block Reward	0.08318123 CSM per block (8,318,123 Kana)
Halving Interval	Every 4 years (126,230,400 blocks)
Block Reward Split	98% Miner / 2% Development Fund
TX Fee Split	90% Miner / 10% Development Fund
Minimum TX Fee	0.00001 CSM (1,000 Kana) — fixed flat fee
Consensus	Sahyadri Consensus
Mining Algorithm	SahyadriX (Blake3 + 16 MB memory loop)
State Model	Account + Object (balance + nonce per address)
Address Format	CSM32 (Bech32-derived, prefix: csm1...)
Network Ports	gRPC: 26110 \| P2P: 26111 \| wRPC: 27110

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:

sender.balance    -= (amount + fee)
receiver.balance  += amount
miner.balance     += fee * 0.90      // 90% of TX fee to miner
company.balance   += fee * 0.10      // 10% of TX fee to development fund
sender.nonce      += 1               // increment after confirmation

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.

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

Transaction {
  sender:    CSM32 address          // csm1q...
  receiver:  CSM32 address          // csm1q...
  amount:    u64 (in Kana)          // 1 CSM = 100,000,000 Kana
  fee:       u64 (in Kana)          // fixed: 1,000 Kana = 0.00001 CSM
  nonce:     u64                    // must equal sender.current_nonce
  tx_id:     SHA256(sender+receiver+amount+nonce+timestamp)
}

3.2 Full Transaction Lifecycle

USER INITIATES TRANSACTION | +--> wallet_api: POST /api/send-csm | +--> [VALIDATION] | |-- Sender account exists in accounts table? | |-- balance >= (amount + 0.00001 CSM fee)? | |-- nonce == sender.current_nonce? | |-- pending_locked + new_total <= sender.balance? | +--> [MEMPOOL INSERT] | |-- INSERT INTO pending_transactions (status='pending') | |-- INSERT INTO transactions (status='pending') | |-- UPDATE accounts SET nonce = nonce + 1 (anti-replay) | +--> Return: { txid, status:'pending', fee:0.00001 CSM } | | (waiting for miner to mine next block...) | MINER MINES NEXT BLOCK (~1 second) | +--> indexer_grpc.py: flush_second() | +--> [BLOCK REWARD] | |-- Decode payload -> actual_reward_kana | |-- miner.balance += reward * 0.98 | |-- company.balance += reward * 0.02 | +--> [PENDING TX CONFIRM] up to 10,000 per second | FOR each pending TX: |-- Re-check: sender.balance >= (amount + fee)? | YES -> confirm | NO -> status = 'rejected' | ON CONFIRM: |-- sender.balance -= (amount + fee) [NOW deducted] |-- receiver.balance += amount |-- miner.balance += fee * 0.90 |-- company.balance += fee * 0.10 |-- transactions.status = 'confirmed' |-- transactions.block_hash = current_block

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_api.py:

# Check total currently locked in mempool for this sender
SELECT COALESCE(SUM(amount + fee), 0)
FROM pending_transactions
WHERE from_address = %s AND status = 'pending'

# New TX accepted only if:
sender.balance >= pending_locked + (new_amount + new_fee)

3.4 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_api.py — 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.5 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:

Network	Fee Model	Fee at $100 transfer	Fee if coin = $10,000
Bitcoin	Variable (sat/vbyte)	$2 – $50	Same
Ethereum	Gas price (Gwei)	$1 – $20	Same
Solana	Fixed (lamports)	~$0.00025	~$0.00025
Sahyadri	Fixed flat (Kana)	0.00001 CSM	$0.10 (10 cents)

The fee is defined once and applies universally:

# wallet_api.py + indexer_grpc.py — 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_COMPANY_SPLIT = 0.10       # 10% to development fund

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.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

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_grpc.py │ │ 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_api.py │ │ 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

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_grpc.py — 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.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 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)

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, daa_score: u64) -> u64 {
    let base_reward: u64    = 8_318_123;      // 0.08318123 CSM in Kana
    let halving_interval: u64 = 126_230_400;  // 4 years = 126,230,400 blocks
    let halvings = daa_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_grpc.py)
BLOCK_COMPANY_SPLIT = 0.02   # 2%  development fund
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

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_grpc.py): 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 (>24h) | | 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).

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:

11. 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 (secp256k1 ECDSA).

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.

12. Calculations and Economic Model

12.1 Emission Formulas

s_k = s_0 \times 2^(-k) (block reward at epoch k)

I_k = H \times s_k (total emission in epoch k)

S(n) = 2 \times H \times s_0 \times (1 - 2^(-n)) (cumulative after n epochs)

S(\infty) = 2 \times H \times 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.

12.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 \times (s_k + f_avg) (r_yr = 31,536,000 blocks/yr)

12.3 Fee Revenue at Scale

Daily TX Volume	Daily Fee Revenue	Miner (90%)	Dev Fund (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

13. Security Model

13.1 Formal Conditions

Verify(tx) = TRUE iff sig_valid(tx.sig, sender_pubkey) AND accounts[sender].balance \geq (amount + fee) AND accounts[sender].nonce == tx.nonce

Accept(B) = TRUE iff VerifySahyadriX(B.header) AND \forall tx \in B: Verify(tx) = TRUE AND ConsensusFinalized(B) = TRUE

P_attack = α (attacker hash fraction) For α < 0.5: attack is economically irrational After finalization: P_reorg = 0 (deterministic)

13.2 Double-Spend Impossibility

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. 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% development fund
TX fee split: 90% miner / 10% development fund

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. Conclusion

Sahyadri presents a comprehensive design for a sovereign peer-to-peer digital money system. By combining SahyadriDAG parallel block production, SahyadriX memory-hard Proof-of-Work, an Account + Object state model, and a fixed flat fee structure, Sahyadri achieves a unique combination of properties unavailable in any other Proof-of-Work network:

Capability	Sahyadri	Bitcoin	Ethereum	Solana
TPS	10,000 (PoW)	7	15–30	65,000 (PoS)
Block Time	1 second	10 minutes	12 seconds	0.4 seconds
Finality	Deterministic (1 block)	Probabilistic	Probabilistic	Probabilistic
Consensus	PoW	PoW	PoS	PoS
TX Fee	0.00001 CSM (flat)	Variable	Variable gas	~$0.00025
Max Supply	21M hard cap	21M hard cap	No hard cap	No hard cap
State Model	Account + Object	UTXO	Account	Account

Sahyadri is the first blockchain to combine Proof-of-Work security with 10,000 TPS throughput, 1-second deterministic finality, and a permanently fixed flat transaction fee. The fixed monetary supply, transparent halving schedule, and protocol-enforced rules provide a stable, auditable, and predictable foundation for global value transfer — digital money that works reliably, fairly, and forever.

Download Whitepaper (.docx) View Previous Version (PDF)

Sahyadri Whitepaper — April 2026 www.sahyadri.io