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 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 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 + 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)
• 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
treasury.balance   += fee * 0.10
sender.nonce       += 1

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.

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
  receiver:  CSM32 address
  amount:    u64 (in Kana)
  fee:       u64 (fixed: 1,000 Kana = 0.00001 CSM)
  nonce:     u64
  tx_id:     SHA3+256(sender+receiver+amount+nonce+timestamp)
}

3.2 Full Transaction Lifecycle

USER INITIATES TRANSACTION
  |
  +--> Submit to node (P2P)
         |
         +--> [VALIDATION]
         |     |-- Sender account exists?
         |     |-- balance >= (amount + fee)?
         |     |-- nonce == sender.current_nonce?
         |
         +--> [MEMPOOL]
         |     |-- Add to pending queue
         |     |-- Lock balance (anti-spend)
         |     |-- Increment nonce (anti-replay)
         |
         +--> Return: { txid, status: 'pending' }
                              |
MINER MINES NEXT BLOCK (~1 second)
  |
  +--> Block produced
         |
         +--> [BLOCK REWARD]
         |     |-- miner.balance    += reward * 0.98
         |     |-- treasury.balance += reward * 0.02
         |
         +--> [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 Nonce and Replay Attack Prevention

Every account carries a monotonically increasing nonce. The node validates that the submitted nonce equals the current on-chain nonce, preventing replay attacks:

# Nonce validation
if nonce != current_nonce:
    return error('Invalid nonce')

# Increment on mempool accept
account.nonce += 1

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.

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, nonce }           |
|   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

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:

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

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

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.

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 Sahyadri 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.02
BLOCK_MINER_SPLIT    = 0.98

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.

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:

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

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, nonce, 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
  accounts[sender].nonce == tx.nonce

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

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: 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). 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] 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.

[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 — digital money that works reliably, fairly, and forever.

Sahyadri Whitepaper