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 Ashwa 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 cSHAKE256 (a NIST-standardized quantum-resistant hash function) 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 + Crest model. Rather than tracking individual unspent outputs (UTXOs), the protocol maintains per-address balances. Each transaction atomically deducts from the sender and credits the receiver, with balance finality enforced at the block confirmation boundary. This model delivers account + crest based ergonomics with the security of Proof-of-Work.

1.1 Key Protocol Parameters

2. Account + Crest Model

Sahyadri employs a hybrid Account + Crest model stored in RocksDB. The Account layer manages balances for rapid money transfers, while the Crest layer anchors identity data without congesting the consensus layer. 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)
• recent_flashes: Bounded, self-pruning set of accepted Flash Transaction identifiers (flash_id + expiry_daa_score), see Section 3.5

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
treasury.balance   += fee * 0.10
sender.recent_flashes.record(flash_id, expiry_daa_score)

2.2 Crest Layer — Sovereign Identity

The Crest layer stores state commitments in a Merkle trie rooted in each block header. Each block header commits to a crest-based state root — a hash cryptographically summarising the entire current ledger state.

Crest Documents support typed verification methods with explicit purposes (Authentication, KeyAgreement, CapabilityInvocation, CapabilityDelegation, Assertion) and dual-indexed storage for O(1) resolution by DID or controller address.

This enables:

• Efficient light-client verification via Merkle proofs
• Safe pruning once a state root is committed
• Fast sync via verified state snapshots
• Native Web5 DID anchoring without state bloat

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 ensure that partial updates are impossible.

2.4 Native Web5 Identity Anchoring

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

2.5 Sparse Merkle Tree (SMT)

Every block header commits to a Sparse Merkle Tree (SMT) root — a single 32-byte hash that summarises the entire account state. The tree has 256 levels; each account occupies exactly one leaf, keyed by the SHA3-256 hash of its CSM32 script.

The SMT is content-addressed: a node's hash is fully determined by its children, and the root depends only on the set of (key, value) pairs — never on insertion order, never on state transition history. Two independent nodes processing the same accounts arrive at the identical root.

Domain-Separated Hashing

Leaf:   Poseidon2_W8("SAHYADRI_SMT_LEAF_V1"   || key || value)
Branch: Poseidon2_W8("SAHYADRI_SMT_BRANCH_V1" || left || right)
Empty:  [0u8; 32]

The domain prefixes prevent second-preimage attacks that could otherwise substitute a leaf for a branch. They are enforced at the crate level — not a convention, an invariant.

Single-Leaf Compression

Subtrees holding a single leaf are compressed into that leaf. Effective depth is under 64 in practice. Proof sizes stay small; generation costs stay bounded — regardless of how many accounts the network holds.

Storage & Complexity

Nodes are content-addressed in RocksDB. Updating one account writes a fresh path from leaf to root; untouched nodes are shared with the previous block and never rewritten. Storage cost is proportional to state changes, not state size.

The SMT is the state layer that powers state proofs (§10.1), light-client verification (§10.2), and SyncWave bootstrap (§9.5).

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 flash_id replay 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
  receiver:  CSM32 address
  amount:    u64 (in Kana)
  fee:       u64 (fixed: 1,000 Kana = 0.00001 CSM)
  expiry_daa_score: u64
  salt:      [u8; 16]
  flash_id:  SHA3-256(sender+recipient+amount+fee+expiry_daa_score+salt)
  tx_id:     SHA3-256(sender+receiver+amount+flash_id+timestamp)
}

3.2 Full Transaction Lifecycle

USER INITIATES TRANSACTION
  |
  +--> Submit to node (P2P)
         |
         +--> [VALIDATION]
         |     |-- Sender account exists?
         |     |-- balance >= (amount + fee)?
         |     |-- flash_id not in recent_flashes, expiry not passed?
         |
         +--> [MEMPOOL]
         |     |-- Add to pending queue
         |     |-- Lock balance (anti-spend)
         |     |-- Record flash_id (anti-replay)
         |
         +--> Return: { txid, status: 'pending' }
                              |
MINER MINES NEXT BLOCK (~1 second)
  |
  +--> Block produced
         |
         +--> [BLOCK REWARD]
         |     |-- miner.balance    += reward * 0.95
         |     |-- treasury.balance += reward * 0.05
         |
         +--> [TX CONFIRMATION]
               |-- sender.balance    -= (amount + fee)
               |-- receiver.balance  += amount
               |-- miner.balance     += fee * 0.90
               |-- treasury.balance  += fee * 0.10
               |-- status = 'confirmed'

3.3 Mempool and Pending Queue

The mempool is maintained locally by each node in memory, providing persistence across node restarts and double-spend protection through locked-balance accounting.

# Double-spend prevention
# Check total locked in mempool for sender
locked = mempool.get_locked(sender)

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

3.4 Mempool Fairness & Anti-Bot Shield

• Per-Account Rate Limit: Maximum 50 pending transactions per account.
• Zero-Pending VIP Rule: If mempool reaches 80% capacity, only addresses with 0 pending transactions can submit new TXs.
• Spam Shield: Node enforces rate limits and rejects excessive transactions.

3.5 Replay Attack Prevention (Flash Transactions)

Every transaction carries a flash_id and an expiry_daa_score. The node checks the flash_id against the sender's bounded recent_flashes replay window and confirms the current DAA score has not passed expiry_daa_score, before accepting the transaction:

# Node validation
if current_daa_score > tx.expiry_daa_score:
    return error('FlashTx expired')
if account.is_flash_replay(tx.flash_id):
    return error('FlashTx replay detected')

# Record on mempool accept
account.recent_flashes.push(tx.flash_id, tx.expiry_daa_score)

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:

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

# Fixed fee parameters
TX_FEE_KANA           = 1000       # 0.00001 CSM - fixed forever
TX_FEE_MINER_SPLIT    = 0.90       # 90% to block miner
TX_FEE_TREASURY_SPLIT = 0.10       # 10% to treasury

4. SahyadriX — Proof of Work

SahyadriX — an application-layer Proof-of-Work combining cSHAKE256 (SHAKE-256 family) with an 8-stage XOR memory loop requiring 16 MB of random-access memory.

4.1 Algorithm (Rust Implementation)

// SahyadriX: cSHAKE256 + 16MB Memory Loop
// File: crypto/hashes/src/pow_hashers.rs

const MEM_SIZE: usize = 16 * 1024 * 1024;  // 16 MiB memory
const ROUNDS:   usize = 1024;               // ASIC killer
const WINDOW:   usize = 32;                 // bytes per access

pub fn hash(data: &[u8]) -> Hash {
    // Step 1: Initial cSHAKE256 hash
    let mut hasher = cshake256::Hasher::new();
    hasher.update(data);
    let mut current_hash = *hasher.finalize().as_bytes();

    // Step A: Fill 16MB memory from seed hash
    // Step B: 1024 random-access mixing rounds
    // Memory NOT wiped between hashes = maximum 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 requires full recomputation:

// 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());
    data.extend_from_slice(&self.timestamp.to_le_bytes());
    data.extend_from_slice(&nonce.to_le_bytes());
    SahyadriX::hash(&data)  // 16MB computation
}

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 larger memory dataset (~256MB), while SahyadriX utilizes a smaller 16MB working set designed to balance participation between CPUs and GPUs.
• GPU-heavy approaches optimize arithmetic throughput, while SahyadriX focuses on repeated random-access XOR memory mixing, prioritizing memory latency constraints.

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

4.3 Device Balance Comparison

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.

The protocol may evolve its memory-hard parameters through future network upgrades when necessary. Sahyadri treats ASIC resistance as an ongoing security objective rather than a fixed one-time property.

4.4 Quantum-Resistant Hashing Layer

All transaction hashes, block headers, and Merkle trees use SHA3-256 (Keccak), providing 256-bit quantum security against Grover's algorithm attacks. This replaces Blake2b which offered only 128-bit quantum security.

4.5 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. The consensus layer remains independent of the signature algorithm, allowing future cryptographic upgrades without affecting monetary rules.

Sahyadri Vector Engine uses AVX2 SIMD and Rayon Multi-Core Parallelism to achieve high-throughput Dilithium-3 verification required for the 10,000+ TPS target, despite the larger signature sizes inherent to post-quantum cryptography.

4.6 Post-Quantum STARK Attestation Compression (Live)

Sahyadri natively integrates Plonky3 recursive STARK aggregation for Dilithium-3 signature compression. Each block's Dilithium-3 attestations are recursively aggregated into a single root STARK proof, reducing per-block verification cost from N independent verifications to a single O(1) proof check.

This layer is implemented and running on devnet — not a future roadmap item.

Measured on commodity hardware (Core Ultra 5, 18 threads):

Proof size grows sub-linearly and asymptotes near ~750 KB as N increases. Verification time is constant (35 ms) regardless of N. Aggregation runs on a dedicated background thread, ensuring block production is never blocked. Mining hashrate remains preserved at 89–99% depending on the configured thread budget — a property no other Proof-of-Work chain offers.

Tamper rejection is validated: any single byte mutation in a child proof causes aggregation to reject at prove time with InvalidProofShape.

5. Network Architecture

The Sahyadri network operates as a fully decentralized peer-to-peer system. Nodes communicate over three primary channels: gRPC (port 27113) for client-node communication; 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, recent_flashes } |
|   SahyadriDAG: parallel blocks, 1s finality               |
|   SahyadriX PoW: CShake256 + 16MB memory loop                |
|   coinbase.rs: 0.08318123 CSM reward, 4yr halving         |
+------------------+----------------------+-----------------+
                   | gRPC :27113          | P2P :26111
                   |                      |
+------------------+---------+   +--------+-----------------+
|   Client / Wallet          |   |  Other Sahyadri Nodes    |
|   - Send transactions      |   |  worldwide (P2P gossip)  |
|   - Check balance          |   +--------------------------+
|   - Query blocks           |
+----------------------------+

5.2 Node Types

5.3 Network Security Matrix

A standard 1952-byte Dilithium-3 signature at 10,000 TPS results in approximately ~19.5 MB/s of signature data alone, which is why Sahyadri implements AVX2 SIMD and Rayon multi-core parallelism for high-throughput verification.

6. Consensus — SahyadriDAG

Ashwa 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:

Second 1:
+----------+   +----------+   +----------+
| Block A  |   | Block B  |   | Block C  |
+----+-----+   +----+-----+   +----+-----+
     |              |              |
     +--------------+--------------+
                    |
     Ashwa Consensus: deterministic ordering
                    |
     +--------------+-------------+
     |   FINALIZED BLOCK SET      |
     |  (all 3 contribute to DAG) |
     +----------------------------+

6.1.1 Deterministic BFT-Equivalent Finality

Ashwa Consensus achieves BFT-equivalent deterministic finality through mathematical DAG ordering rather than validator voting. The Sahyadri Score calculation 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
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 x 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

6.4.1 Security Assumptions

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

6.5 Consensus Mechanics

Traditional blockchain architectures suffer from linear bottlenecks, where only one block can be processed at a time. Sahyadri fundamentally shifts this paradigm by utilizing a Directed Acyclic Graph (DAG) structure. Multiple miners can propose blocks concurrently, and parallel blocks are cryptographically woven into the DAG.

Sahyadri solves the finality problem by decoupling block generation from block finalization. The Ashwa Consensus algorithm calculates a deterministic 'Sahyadri Score' by weaving parallel blocks into a chronological order, delivering BFT-grade deterministic finality within approximately 1 second without requiring any centralized validator committee.

6.6 Throughput Assumptions

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, and propagation latency.

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 {
    let base_reward: u64    = 8_318_123;
    let halving_interval: u64 = 126_230_400;
    let halvings = blue_score / halving_interval;
    if halvings >= 64 { return 0; }
    base_reward.checked_shr(halvings as u32).unwrap_or(0)
}

// Indexer split (indexer.rs)
BLOCK_TREASURY_SPLIT = 0.05
BLOCK_MINER_SPLIT    = 0.95

7.2 Halving Schedule

"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 Data Storage

Sahyadri nodes store the complete blockchain data locally using RocksDB — a high-performance embedded key-value database. No external database, no cloud dependency, no centralized indexer required. Every node independently maintains the full ledger from genesis.

8.1 Node Data Storage

Node (RocksDB) Stores:
+---------------------------+
| Account balances          |
| Transaction history       |
| Block headers             |
| DAG structure             |
| Current state             |
+---------------------------+
Size: 5-10 GB (pruned) or full archive

8.2 Node Sync Process

NODE SYNC (sahyadrid):

1. Start node
2. Connect to P2P network (port 26111)
3. Download blocks from peers (genesis → current)
4. Validate each block independently
5. Build local RocksDB state
6. Node fully synced — ready to mine/validate

8.3 API Endpoints (Built-in)

9. Disk Space and Pruning

Sahyadri nodes are designed to be lightweight. The default node stores only current state and recent blocks, automatically pruning old data to maintain a stable 5-10 GB footprint. Archive nodes store the complete history for explorers and analytics.

Pruned Node (Default):          Archive Node:
+---------------------------+   +---------------------------+
| Current state             |   | Full history              |
| Recent blocks             |   | All transactions          |
| DAG structure             |   | All blocks                |
+---------------------------+   +---------------------------+
Size: 5-10 GB stable            Size: Grows continuously

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. With a default pruning duration of 108,000 seconds (30 hours), node storage remains extremely lightweight and stable (5-10 GB).
• High-Throughput Batch Processing (10,000 TPS Engine): The Sahyadri Indexer utilizes a RAM-based batch insertion engine, reducing database round-trips from tens of thousands per block to just 4 optimized queries.
• Archival Offloading via PostgreSQL: Archival Nodes preserve complete transaction history using the --archival flag.
• Mempool Pruning: 24-hour automated pruning of terminal transactions keeps query times minimal.
• Security against Misconfiguration: Removing --archival flag halts the node with warning.

9.5 SyncWave — Fast Node Bootstrap

A fresh node does not need to replay the chain from genesis. It downloads a verified SyncWave — an untrusted snapshot of SMT state at a recent checkpoint block — proves it locally against the checkpoint header's account_commitment, and resumes ordinary sync from the checkpoint forward.

This collapses fresh-node startup from hours of full IBD to seconds of verified download, without weakening the trust model by a single bit.

The Bootstrap Problem

SyncWave offers a third path: download untrusted state, verify it cryptographically against a header the client already trusts. The peer's role collapses to that of a dumb pipe.

SyncWave Structure

SyncWave {
  metadata:       SyncWaveMetadata,
  smt_nodes:      Vec<(H256, SyncWaveNode)>,
  account_states: Vec<(Hash, SyncWaveState)>,
}

SyncWaveMetadata {
  block_hash:      Hash,     // checkpoint block
  block_height:    u64,      // Sahyadri Score
  account_root:    Hash,     // == header.account_commitment
  total_smt_nodes: u64,
  total_accounts:  u64,
  chunk_size:      u32,
  total_chunks:    u32,
}

Wire Protocol

Metadata is fetched first — a few hundred bytes — so the client knows the checkpoint block hash, its height, and how many chunks to expect. Chunks are bincode-encoded slices of the concatenated [smt_nodes..., account_states...] sequence. The client fetches chunks from any peer, in any order, retrying from alternate peers on corrupt chunks.

Verification

Verification is entirely local — no network calls. It runs four checks:

• Content-address: every node's hash equals its declared key (rejects fabricated nodes)
• Dangling reference: the walk from account_root resolves every reference (rejects truncated trees)
• Count match: the walk visits exactly total_smt_nodes (rejects inflated metadata)
• State hash: every account state's content-hash matches its key (binds balances to leaves)

If all four pass, the SyncWave is the state at the checkpoint block. There is exactly one tree with that root, and the client has reconstructed it.

Atomic Load

Nodes and states are content-addressed, so writes are idempotent — a crash mid-load leaves a partial but self-consistent tree. Re-running the load completes it. The checkpoint root mapping lands in a single write batch and is either fully persisted or absent.

Bootstrap Flow

1. Fetch metadata from any peer
2. Verify the checkpoint header (PoW, DAG ordering, account_commitment)
3. Download all chunks, retrying from alternate peers on failure
4. Reassemble and run verify() — sub-millisecond for typical trees
5. Insert nodes and states; persist the checkpoint root last
6. Sync tip from checkpoint forward — seconds, not hours
7. Node online, serving RPC and P2P

CLI

sahyadrid \
    --sync-wave grpc://seed-node:27113 \
    --sync-wave-checkpoint <optional-hash>

Bootstrap runs before the node opens its RPC and P2P ports. A node launched with --sync-wave is fully synced to the checkpoint by the time it appears on the network. Every full node serves SyncWave on its standard gRPC port; no special configuration is required on the serving side.

Security Analysis

There is no trusted third party. The verifier's only assumption is that the checkpoint header was produced by honest consensus — the same assumption every full node makes. SyncWave adds zero new trust assumptions.

Measured Performance

On a 2-node local testnet (real mining, real SMT state, real cryptographic verification), bootstrap completed in ~10 ms for a small state of 5 SMT nodes and 2 accounts. Production-scale networks project to seconds — dominated by download bandwidth, not verification cost, which stays O(depth) regardless of state size.

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 Ashwa Consensus. Sahyadri IPV is immediate: 1 block confirmation = absolute finality. This enables point-of-sale terminals to accept payments as fast as block confirmation, merchants to settle with cash-equivalent confidence, and embedded payment processors to operate with minimal bandwidth.

The Merkle inclusion proof consists of:

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

10.1 State Proofs

A state proof is a compact cryptographic witness that a key-value pair is (or is not) present in the SMT at a specific block. It lets any client verify an account balance without holding the full database, without trusting the node that served the proof, and without replaying any block history.

Proof Structure

Proof {
  siblings: Vec<H256>,    // one hash per level, root-down
  terminal: Terminal,     // leaf or empty subtree at the end
}

Terminal::Empty                     // proof of absence
Terminal::Leaf { key, value }       // proof of presence

Verification

The verifier reconstructs the root upward from the terminal, choosing left/right at each level based on the corresponding bit of the query key. Success requires:

• The recomputed root equals the trusted root, and
• The terminal leaf's key matches the queried key.

The second condition binds the proof to the actual key being asked about — without it, an adversary could substitute a leaf with a different key and still produce a valid path.

Exclusion Proofs

An SMT proves not only what exists, but what does not. If the path terminates in an empty subtree, the account is provably absent. If it terminates at a leaf whose key differs from the query but shares the correct prefix up to the divergence, the account is absent via a divergent leaf.

Proof Size & Verification Cost

Typical proofs are smaller than a single Dilithium-3 signature. The verification path contains no elliptic-curve operations, no pairings, no trusted setup. The only assumption is that the block header was produced by honest consensus — the same assumption every full node makes.

10.2 Light Client Architecture

A Sahyadri light client stores only block headers and requests state proofs on demand. It does not hold the SMT, the state database, or the transaction history. Total storage is bounded by the header chain the client chooses to retain.

Trust Model

The client trusts exactly one thing: the header chain it has independently verified. Everything else — every balance it displays, every payment it authorizes — is a cryptographic consequence of a header the client already trusts. The node that serves a proof carries no trust weight.

Verification Flow

1. Verify a block header (or fetch a trusted checkpoint); extract account_commitment.
2. Request get_account_proof(address, block_hash) from any peer.
3. Recompute the SMT root from the proof — a few hundred SHA3 hashes, under 1 ms.
4. Compare against the trusted root. Match means valid; mismatch means the peer is lying.
5. Use the verified state.

Storage Footprint

Deployment Targets

The verification core is designed for browser deployment, to no_std + alloc for embedded POS terminals, and to native mobile targets through the Sahyadri JS SDK, with additional platform targets planned. The algorithm and proof format are identical on every platform.

Security Properties

• No ECDSA in the verification path — no algorithm broken by quantum adversaries
• No trusted setup — only SHA3-256, no ceremony
• No network trust — correctness depends on a header the client verified itself
• No privacy loss by default — the client reveals only which account it queries

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 + Crest 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 Crest. 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 Ashwa 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.

Sahyadri natively integrates Plonky3 recursive STARK aggregation for post-quantum signature compression. Validator attestations signed with ML-DSA-65 (CRYSTALS-Dilithium-3) are recursively aggregated into a single root STARK proof per block, reducing bandwidth requirements while maintaining post-quantum security. Measured on commodity hardware: N = 8 attestations compress to a 735 KB root proof in 31 s with 35 ms verification time. Proof size remains constant as N grows — a light client verifying an entire block downloads less data than a single HD photo.

13. Calculations and Economic Model

13.1 Emission Formulas

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

13.3 Fee Revenue at Scale

14. Security Model

Double-spend resistance at four layers: mempool, confirmation, flash-id replay, and consensus. Post-quantum security via ML-DSA (Dilithium-3).

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
  current_daa_score <= tx.expiry_daa_score  AND
  tx.flash_id NOT IN accounts[sender].recent_flashes

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

P_attack = a  (attacker hash fraction)
For a < 0.5: attack is economically irrational
After finalization: probability of successful
reorganization approaches zero

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 means TX rejected
• Flash-id layer: Each TX carries a unique flash_id bound to an expiry_daa_score; the same flash_id cannot be replayed within its validity window
• 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.

14.5 Post-Quantum STARK Attestation Compression

To preserve post-quantum security while maintaining high throughput, Sahyadri integrates Plonky3 recursive STARK aggregation. Instead of transmitting and verifying thousands of individual Dilithium-3 signatures, validators recursively aggregate large attestation batches into a single compact root STARK proof.

Measured benchmarks (live implementation):

Verification time is constant regardless of N. Proof size grows sub-linearly and asymptotes near ~750 KB as N increases. The STARK system relies on Plonky3, Goldilocks field arithmetic (2⁶⁴ − 2³² + 1), Poseidon2 W8 hashing, FRI commitments with 100 queries, and Poseidon2-based Fiat-Shamir transcript generation. Mining hashrate is preserved at 89–99% during aggregation — a property unique among Proof-of-Work chains.

15. Governance

Minimal governance — all core monetary parameters are permanently fixed at genesis. Changing them requires a hard fork.

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: 95% miner / 5% 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: 5% 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: • Ashwa 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. Ashwa 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). CShake256 Cryptographic Hash and PRF.
[4a] NIST. SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions (FIPS 202).

[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] TBD (Jack Dorsey). Web5 — A Decentralized Web Platform. Public announcement, 2022.

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

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

18. Conclusion

Sahyadri presents a comprehensive design for a sovereign peer-to-peer digital money system with deterministic finality, high throughput, and a strictly capped supply. The protocol combines a directed acyclic graph structure for parallel block production, a memory-hard Proof-of-Work architecture designed to preserve long-term mining accessibility, an Account + Crest state model for simplified value transfer, and a fixed flat fee structure for predictable costs.

Sahyadri is proof-native: every block carries a recursively aggregated STARK proof that any light client verifies in 35 ms with a constant-size 735 KB root proof. This is achieved through Plonky3 recursive STARK aggregation over the Goldilocks field, with a mining-aware thread pool that preserves 89–99% of Proof-of-Work hashrate during aggregation. To our knowledge, no other Proof-of-Work chain combines deterministic DAG finality, post-quantum signatures (Dilithium-3), and recursive STARK aggregation into a single coherent design.

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.

Sahyadri Whitepaper