CRYSTALS-Dilithium3

The Post-Quantum Digital Signature Standard securing the future of Sahyadri.

CRYSTALS-Dilithium3 is the primary digital signature algorithm used throughout the Sahyadri blockchain. Unlike traditional signature systems such as ECDSA or Schnorr, Dilithium3 is specifically designed to remain secure against both classical and quantum computers.

Following its selection by the National Institute of Standards and Technology (NIST), Dilithium became the world's first standardized lattice-based digital signature algorithm under FIPS 204. Sahyadri integrates Dilithium3 at the protocol level to provide long-term cryptographic security rather than treating post-quantum protection as an optional upgrade.

Why Dilithium?

Modern cryptocurrencies rely heavily on elliptic curve cryptography. Bitcoin uses ECDSA while many modern blockchains utilize Schnorr signatures based on the secp256k1 elliptic curve. Although these systems have proven secure for decades, they share one critical limitation: they become vulnerable once sufficiently powerful quantum computers become practical.

Shor's Algorithm demonstrates that quantum computers can efficiently solve the mathematical problems protecting elliptic curve cryptography. Once that becomes feasible, attackers could derive private keys directly from exposed public keys and forge digital signatures.

Dilithium eliminates this threat by replacing elliptic curve mathematics with lattice-based cryptography, a family of problems currently believed to resist both classical and quantum attacks.

Historical Background

In 2016, NIST initiated a global competition to standardize cryptographic algorithms capable of resisting quantum attacks. Researchers from universities and cryptographic institutions across the world submitted dozens of candidate algorithms.

After multiple years of public analysis, peer review, implementation testing and cryptanalysis, CRYSTALS-Dilithium emerged as one of the strongest candidates. It demonstrated excellent security margins, practical performance and implementation simplicity.

In August 2024, NIST officially published FIPS 204, making CRYSTALS-Dilithium an official United States Federal Information Processing Standard. This marked one of the most significant milestones in modern cryptography since the adoption of AES.

Security Level

Sahyadri implements the Dilithium3 parameter set, which corresponds to NIST Security Level 3. This security category is generally considered comparable to approximately 128–192 bits of classical security while remaining resistant against currently known quantum attacks.

Key Sizes

While Dilithium signatures are considerably larger than traditional ECDSA signatures, the increased size represents the trade-off required for post-quantum security. Storage and bandwidth costs continue to decrease every year, whereas broken cryptography cannot simply be repaired after deployment.

How Dilithium Works

Unlike elliptic curve cryptography, Dilithium is based on structured mathematical lattices. Rather than solving discrete logarithms, security relies upon extremely difficult lattice problems such as the Module Learning With Errors (MLWE) problem and Module Short Integer Solution (MSIS) problem.

These mathematical problems have resisted decades of cryptographic research and currently possess no efficient algorithms on either classical or quantum computers.

At a high level, Dilithium performs four primary operations.

1. Generate a public and secret key pair.
2. Create a digital signature for arbitrary data.
3. Verify signatures using the corresponding public key.
4. Reject forged signatures through deterministic verification.

Why Sahyadri Uses Dilithium3

• Native post-quantum security.
• Official NIST standard.
• Open academic research.
• Efficient software implementation.
• No dependence on elliptic curves.
• Long-term blockchain viability.
• Suitable for Web5 identity systems.
• Ideal for decentralized authentication.

Applications inside Sahyadri

Every critical component of the Sahyadri ecosystem relies upon Dilithium signatures. The algorithm secures considerably more than simple monetary transfers.

Comparison

Future Outlook

Quantum computing continues to advance rapidly through research conducted by universities, governments and private companies. Although practical cryptographically relevant quantum computers have not yet been realized, blockchain protocols often remain operational for decades. Waiting until quantum computers arrive before upgrading cryptography would expose billions of dollars worth of digital assets.

Sahyadri adopts a proactive approach by integrating post-quantum cryptography from genesis. This ensures that identities, digital assets and decentralized applications built on Sahyadri remain protected for future generations without requiring disruptive protocol migrations.

Summary

CRYSTALS-Dilithium3 forms one of the core security foundations of the Sahyadri ecosystem. By adopting the first globally standardized post-quantum digital signature algorithm, Sahyadri positions itself beyond the limitations of traditional blockchain cryptography and prepares the protocol for an era where quantum computing becomes a practical reality.

Plonky3

High-performance proving framework powering Sahyadri's next-generation zero-knowledge infrastructure.

Plonky3 is the primary cryptographic proving framework used within the Sahyadri ecosystem to build fast, scalable and recursive zero-knowledge proof systems. Rather than being a blockchain or consensus mechanism, Plonky3 provides the mathematical engine responsible for generating and verifying advanced cryptographic proofs with extremely high efficiency.

Sahyadri integrates Plonky3 alongside STARK-based proving systems to deliver privacy-preserving computation, decentralized identity verification, recursive proof aggregation and future Web5 applications without sacrificing transparency or decentralization.

Why Plonky3?

Modern decentralized applications increasingly require cryptographic proofs capable of verifying large amounts of computation without revealing sensitive information. Traditional verification methods require executing every computation directly, limiting scalability and increasing resource consumption.

Plonky3 enables Sahyadri to verify complex computations using compact cryptographic proofs, allowing validators and applications to confirm correctness without repeating the original computation.

Core Capabilities

• High-performance proof generation.
• Recursive proof composition.
• Parallel computation.
• Modular proving architecture.
• Low verification cost.
• Optimized for modern CPUs.
• Future GPU acceleration.
• Production-ready Rust implementation.

Applications inside Sahyadri

Plonky3 Architecture

Unlike monolithic proving systems, Plonky3 was designed with a modular architecture. Every component—including finite fields, hash functions, polynomial commitment schemes and proof systems—can be independently optimized or replaced without redesigning the entire framework.

This flexibility allows Sahyadri to continuously adopt new cryptographic improvements while maintaining compatibility with existing infrastructure.

Performance

Plonky3 + STARK

Sahyadri combines Plonky3 with STARK-based proving systems to create a transparent, post-quantum-friendly zero-knowledge infrastructure. Plonky3 provides the proving framework while STARK defines the underlying proof construction. Together they enable scalable verification without requiring trusted setup ceremonies.

Future Integration

Plonky3 forms one of the core cryptographic foundations for Sahyadri's long-term Web5 vision. As decentralized applications continue to evolve, the proving framework will support identity verification, private computation, recursive validation, decentralized storage verification and numerous advanced cryptographic protocols.

Plonky3 Architecture

The proving pipeline begins with an application constructing arithmetic constraints that represent computation. Witnesses are generated, transformed into polynomial commitments and finally processed through Plonky3's optimized proving engine to produce a STARK proof that can later be verified by any participant on the Sahyadri network.

Recursive Proof Aggregation

Recursive proving allows multiple independent proofs to be compressed into a single proof. Instead of verifying hundreds or thousands of individual proofs, the Sahyadri network verifies only one recursive proof, dramatically reducing verification costs while improving scalability.

Plonky3 + STARK Relationship

STARK defines the mathematical proof construction, while Plonky3 provides the implementation responsible for efficiently generating and verifying those proofs. Sahyadri integrates both technologies to provide scalable, transparent and post-quantum-ready verification.

Sahyadri Verification Pipeline

Every transaction inside Sahyadri begins with a Dilithium3 signature. The transaction can then be incorporated into recursive proving workflows powered by Plonky3 before validators verify proof correctness and finalize blocks through the BlockDAG consensus mechanism.

Future Web5 Integration

Future Web5 applications on Sahyadri will leverage Plonky3 to generate cryptographic proofs for decentralized identity, credential verification and privacy-preserving authentication without exposing user information to third parties.

Summary

Plonky3 provides the computational backbone for Sahyadri's zero-knowledge ecosystem. Combined with STARK proofs and CRYSTALS-Dilithium3 signatures, it enables a blockchain designed not only for today's decentralized applications but also for the cryptographic requirements of the coming decades.

STARK

Scalable Transparent ARguments of Knowledge – Transparent, Quantum-Resistant Cryptographic Proofs.

STARK (Scalable Transparent ARguments of Knowledge) is the primary proof system used within the Sahyadri ecosystem for verifiable computation, recursive verification, privacy-preserving applications, decentralized identity systems, and future Web5 infrastructure.

Unlike traditional proof systems that require trusted ceremonies or trusted setup assumptions, STARK proofs are completely transparent. Security is derived from publicly verifiable mathematics, cryptographic hash functions, low-degree polynomial commitments, and interactive oracle proof constructions.

Sahyadri integrates STARK technology through the Plonky3 proving framework, allowing the network to verify complex computations with minimal verification costs while maintaining full decentralization.

Why STARK?

Most blockchains verify transactions directly. As networks grow, verification becomes expensive, storage requirements increase, and scalability becomes difficult.

STARK proofs solve this problem by allowing a prover to generate mathematical evidence that a computation was executed correctly without requiring every node to repeat the entire computation.

Instead of verifying millions of operations, validators only verify a compact proof.

Core Properties

How STARK Works

At a high level, STARK transforms computation into a mathematical crest that can be efficiently verified.

The verifier never needs to execute the original computation. Verification only checks mathematical consistency between commitments and proof data.

Execution Trace

Every computation can be represented as a sequence of state transitions.

State 0
↓

State 1
↓

State 2
↓

State 3
↓

Final State

This sequence is called an execution trace.

STARK converts this trace into polynomial form so that mathematical constraints can be verified efficiently.

Polynomial Commitments

The execution trace is transformed into low-degree polynomials.

Instead of storing every individual computation step, the prover commits to polynomial representations that summarize the entire computation.

Hash commitments ensure that the prover cannot alter the trace after commitment.

FRI Protocol

One of the key innovations behind STARK proofs is FRI (Fast Reed-Solomon Interactive Oracle Proofs of Proximity).

FRI enables efficient verification that a polynomial has low degree without revealing the entire polynomial.

This dramatically reduces proof size while maintaining strong cryptographic security.

Quantum Resistance

One of the strongest advantages of STARK proofs is quantum resistance.

Many proof systems rely heavily on elliptic curve assumptions that may become vulnerable to large-scale quantum computers.

STARK security primarily relies on cryptographic hash functions and information-theoretic constructions.

Combined with Dilithium3 signatures, STARK proofs form a critical part of Sahyadri's post-quantum architecture.

Recursive Proofs

Recursive proving allows one proof to verify other proofs.

This enables thousands of transactions, identity verifications, and computations to be compressed into a single proof.

STARK in Sahyadri

Sahyadri uses STARK proofs across multiple components:

• Transaction verification
• Future privacy-preserving transfers
• Decentralized Identity (DID)
• Verifiable Credentials (VC)
• Web5 authentication
• Cross-chain verification
• Recursive aggregation
• Scalable state proofs

Relationship with Plonky3

STARK is the proof system.

Plonky3 is the framework that implements and optimizes STARK proving and verification.

Summary

STARK proofs provide Sahyadri with transparent verification, post-quantum security, scalable computation, recursive proof aggregation, and trustless validation.

Together with Dilithium3, Plonky3, PoW, BlockDAG, Decentralized Identity, Verifiable Credentials, and Web5 infrastructure, STARK technology forms one of the foundational cryptographic pillars of the Sahyadri ecosystem.

Web5

The decentralized web platform — identity-first, user-controlled.

Sahyadri is Web5-native — every account linked to a DID for portable digital identity.

Decentralized Identifiers (DID)

Self-Sovereign Digital Identity built directly into the Sahyadri Protocol.

Sahyadri introduces a native decentralized identity system designed for the Web5 era. Every wallet created on the Sahyadri network automatically becomes a decentralized identity capable of owning data, credentials, permissions, and digital assets without reliance on centralized identity providers.

Unlike traditional systems where identity is controlled by governments, corporations, social media platforms, email providers, or centralized databases, Sahyadri allows users to own and control their identity directly through cryptographic keys and decentralized verification mechanisms.

What is a DID?

A Decentralized Identifier (DID) is a globally unique identifier that does not depend on any central authority.

Traditional identities rely on trusted third parties:

• Email providers
• Social media accounts
• Government databases
• Bank accounts
• Username-password systems

DIDs eliminate these dependencies by allowing cryptographic ownership of identity.

did:sahyadri:csm1s3fj82j2m9s7w8d4x

The DID becomes the root identity of a user within the Sahyadri ecosystem.

DID Method

Sahyadri implements its own DID method:

did:sahyadri:identifier

Every DID resolves to a DID Document stored through Sahyadri's decentralized infrastructure.

DID Document

Each DID references a DID Document containing identity metadata and verification information.

{
  "id": "did:sahyadri:csm1sabc123",
  "verificationMethod": [
    {
      "id": "#dilithium-key",
      "type": "Dilithium3VerificationKey",
      "publicKey": "..."
    }
  ]
}

The DID Document allows wallets, applications, exchanges, marketplaces, and identity services to verify ownership without requiring centralized databases.

Identity Ownership

Ownership of a DID is determined exclusively by cryptographic signatures.

If a user controls the corresponding Dilithium3 private key, they control the DID.

No government, company, server operator, administrator, or validator can seize, freeze, modify, revoke, or transfer ownership.

Relationship Between Wallet and DID

Each wallet can control one or more DIDs, while every DID remains cryptographically linked to its owner.

Web5 Integration

Sahyadri DIDs form the foundation of Web5.

Applications no longer need usernames, passwords, email registrations, or centralized account systems.

Instead, applications authenticate users directly through their DID.

Benefits

• No usernames required
• No passwords required
• No centralized identity providers
• No platform lock-in
• Cross-platform identity portability
• Cryptographic ownership
• Privacy-preserving authentication
• Web5 compatibility
• Future-proof architecture
• Native integration with Verifiable Credentials

DID and Verifiable Credentials

DIDs become significantly more powerful when combined with Verifiable Credentials (VCs).

A DID identifies a user.

A Verifiable Credential proves facts about that user.

Future Vision

The long-term goal of Sahyadri DIDs is to provide a universal decentralized identity layer for users, applications, exchanges, financial systems, marketplaces, governments, enterprises, and future Web5 ecosystems.

A single identity should be capable of accessing services, proving ownership, receiving credentials, signing transactions, managing permissions, and controlling personal data without dependence on centralized intermediaries.

Summary

Sahyadri DID is a decentralized identity system built directly into the protocol. It provides self-sovereign identity ownership, cryptographic authentication, Web5 compatibility, and a foundation for Verifiable Credentials, decentralized applications, and future digital infrastructure.

Identity should not belong to platforms.

Identity should belong to people.

Crest Model

A structured identity system for post-quantum blockchains

What is the Crest Model?

Crest is Sahyadri's native decentralized identity model. It defines how Decentralized Identifiers (DIDs) are created, controlled, updated, resolved, and deactivated at the protocol level.

The Account Model handles monetary state such as balances, nonces, transactions, and fees. The Crest Model handles decentralized identity state and identity-related operations.

Unlike traditional flat DID documents where keys are stored as simple string arrays without any semantic meaning or purpose classification, the Crest Model introduces a typed identity system where every cryptographic key carries an explicit intent. When a verification method is defined within a Crest document, it must declare its specific purpose through the CrestPurpose enum, which includes Authentication for login and session establishment, KeyAgreement for encrypted communication channels, CapabilityInvocation for authorizing blockchain actions and transactions, CapabilityDelegation for granting temporary or permanent authority to external entities such as devices or agents, and Assertion for signing claims and issuing verifiable credentials about the identity holder.

This explicit purpose system solves a fundamental problem that has plagued decentralized identity implementations since their inception. In standard DID documents using JSON-LD formats, a signing key appears identical to an encryption key or a delegation key at the data structure level, forcing applications to implement inconsistent validation logic that varies between implementations and creates security vulnerabilities when an application mistakenly uses an authentication key for signing assertions or delegates a capability invocation key to an untrusted third party. The Crest Model eliminates this ambiguity by encoding purpose directly into the protocol layer, ensuring that every key usage can be validated against its declared intention before any cryptographic operation executes.

The Crest Model is an identity-state model that operates alongside monetary state models such as UTXO and Account models. Rather than replacing the way Sahyadri manages monetary state, Crest provides a dedicated protocol-level structure for decentralized identity, including identity controllers, verification methods, services, and versioned identity state.

At its core, a Crest functions as a self-describing identity document that answers four fundamental questions which any decentralized identity system must address. First, it establishes globally unique identification through the did:sahyadri naming scheme combined with cryptographic hashes derived from the initial creation transaction, ensuring no two entities can ever claim the same identifier through collision or malicious registration. Second, it defines controllership by binding each Crest to a specific Sahyadri address formatted as csm1s prefix followed by bech32-encoded bytes, creating an unambiguous ownership chain where only the private key holder controlling that address can authorize modifications to the identity document. Third, it enumerates the cryptographic capabilities available to the identity holder through verification methods that specify not only the public key material but also the algorithm type, currently restricted to CRYSTALS-Dilithium3 for quantum resistance, and the permitted usage contexts through the purpose enum. Fourth, it declares service endpoints where this identity can be contacted or where additional identity-related data resides, such as Decentralized Web Node hubs for storing verifiable credentials, discovery endpoints for finding other identities within the Sahyadri network, or custom application-specific URLs.

The relationship between the Crest Model and Verifiable Credentials forms a layered architecture where Crests establish the foundational identity anchor while credentials represent signed statements issued about that identity by itself or by third-party attesters. When an entity wishes to issue a Verifiable Credential asserting some claim such as educational attainment, professional certification, or access authorization, it uses the assertion-purpose verification method from its Crest to sign the credential payload. Recipients of such credentials can then resolve the issuer's Crest from the blockchain, verify the signature against the registered public key, confirm that the key possesses assertion purpose, and establish trust in the credential's authenticity without relying on any centralized certificate authority or intermediary service.

Implementation-wise, the Crest Model persists identity data through a dual-store architecture built on RocksDB that enables bidirectional lookups in constant time regardless of query direction. The primary store uses the hexadecimal prefix 0x646964732d73746f7265 representing the ASCII string "dids-store" as a namespace organizer, mapping each DID's hash component to its serialized CrestDocument containing all current identity information. Complementing this forward lookup path, the reverse index store under prefix 0x646964732d616464722d696e646578 maps controller addresses back to their associated DID references, allowing the network to answer questions like "which identity controls this address" without scanning all existing DIDs. This dual-indexing strategy proves essential for practical applications where a user presents an address from their wallet and the application needs to discover and display the corresponding identity profile, or when auditing systems must trace transactions back to their originating identity controllers.

Every mutation to a Crest follows strict validation rules enforced at the consensus layer rather than left to application discretion. Creation requires the requesting address to sign the initial document and pay the associated identity registration fee, preventing spam identity flooding while establishing clear economic stakes in identity ownership. Updates must reference the expected current version number, implementing optimistic concurrency control that prevents lost update problems when two modifications race against each other, with only the first submission succeeding and subsequent attempts failing with version mismatch errors that prompt clients to fetch the latest state before retrying. Key rotation preserves the purpose attribute of the replaced method while updating the public key material, maintaining the semantic contract that an authentication key remains an authentication key even after the underlying cryptographic material changes due to compromise suspicion or regular security hygiene practices. Deactivation sets a boolean flag marking the Crest as permanently immutable without actually deleting historical data, preserving the complete record for regulatory compliance, forensic analysis, and proving what the identity looked like at any point in its lifetime.

Account Model vs Crest Model

Sahyadri separates monetary state from decentralized identity state. The Account Model is responsible for value transfer, while Crest is responsible for decentralized identity.

This separation exists because financial transactions and identity management have completely different needs. Money moves fast and needs simple state. Identity persists for years and needs rich metadata. Mixing them creates problems: updating a service endpoint shouldn't touch your balance, rotating authentication keys shouldn't expose your CSM holdings, and regulatory history preservation shouldn't bloat every node's financial database.

The Account Model handles balances, nonces, CSM transfers, and fees. When you send tokens, it debits sender, credits recipient, increments nonce, and records the state change. This layer optimizes for speed and minimal storage because it runs millions of times daily. The Crest Model handles DIDs, identity documents, verification methods, and all identity operations. When you create a Crest, it generates a DID from your address but keeps it as an independent entity. You can share that DID publicly without revealing your balance. You can rotate keys without affecting your funds. You can register service endpoints that only identity queries ever see.

Each row shows how the two models handle similar concerns differently. A balance is just a number. A DID is a structured identifier resolving to rich data. A nonce prevents replay attacks. A DID Document contains nested objects with keys, services, and metadata. Fees are per-transaction costs. Verification methods are typed cryptographic keys declaring their specific purpose. Value state tracks token ownership. Identity tracks who can prove what claims using which keys.

This separation lets each layer optimize independently. Identity documents can grow large with metadata because only identity queries pay that cost. Account state stays tiny because financial validation never inspects service endpoints or key purposes. Post-quantum cryptography is mandatory for identity signatures while faster classical algorithms work fine for routine payments during the quantum transition period.

Crest Architecture

The Crest Model sits alongside the Account Model within the Sahyadri protocol. Both share the same blockchain foundation but operate on completely separate state partitions, communicating only when an identity operation needs to verify controllership against an address balance or when a transaction needs to resolve a DID for identity-based access control.

┌─────────────────────────────────────────────────────┐
│                    SAHYADRI L1                      │
│              (Consensus + Cryptography)             │
└───────────────────────┬─────────────────────────────┘
                        │
        ┌───────────────┴───────────────┐
        │                               │
        ▼                               ▼
┌───────────────┐               ┌───────────────┐
│  ACCOUNT      │               │    CREST      │
│   MODEL       │               │    MODEL      │
├───────────────┤               ├───────────────┤
│ Balance       │               │ DID           │
│ Nonce         │               │ Controller    │
│ CSM Transfer  │─── separate ──┤ Verification  │
│ Fees          │     state     │ Methods       │
│ Value State   │               │ Services      │
└───────────────┘               │ Version       │
                                │ Identity State│
                                └───────────────┘

The diagram shows two parallel branches under the same Sahyadri root. The left branch handles everything monetary: your CSM balance, transaction nonce, token transfers to other addresses, and overall value state that every validator must track. Fees associated with CSM transactions and applicable protocol operations. The right branch handles everything identity-related: your globally unique DID, the controller address that owns it, typed verification methods with explicit purposes, registered service endpoints, monotonically increasing version numbers for audit trails, and the complete identity state document.

Inside the Crest Model itself, each component serves a specific purpose. The DID is the public identifier you share with others, formatted as did:sahyadri followed by a hash derived from the creation transaction. The Controller is the csm1s address that proves ownership and authorizes any changes to the Crest. Verification Methods are cryptographic keys where each key declares whether it handles authentication, key agreement, capability invocation, capability delegation, or assertion through the CrestPurpose enum. Services are URLs pointing to external endpoints like Decentralized Web Node hubs where verifiable credentials get stored or discovery services where other identities can find you. Version is a counter incrementing on every update, enabling optimistic concurrency control and preventing lost modifications from racing updates. Identity State wraps all of this into a single coherent document that gets persisted in the dual-store architecture and resolved by any participant on the network.

When a user interacts with Sahyadri, they typically touch both models but through different operations. Sending CSM touches only the Account Model. Creating or updating a Crest touches only the Crest Model. The rare crossover happens during identity creation when the system verifies the controller address has sufficient balance to pay registration fees, or during credential issuance when the issuer's Crest verification method signs a payload that later gets anchored to an account transaction for immutability proof. This minimal coupling keeps both models independently optimizable while maintaining protocol-level consistency guarantees.

Crest Operation Lifecycle

Every Crest operation follows a validated execution path from client submission to finalized state. This lifecycle ensures that only authorized, well-formed mutations reach the canonical identity store.

┌──────────┐
│  Client  │  Wallet / SDK / CLI initiates operation
└─────┬────┘
      │
      ▼
┌──────────────┐
│   Crest      │  Create / Update / Rotate / Deactivate
│  Operation   │  Request struct built with payload
│  Request     │
└─────┬────────┘
      │
      ▼
┌──────────────────┐
│  Cryptographic   │  Controller signs with Dilithium3
│    Signature     │  Purpose-matched key verification
│   Verification   │
└─────┬────────────┘
      │
      ▼
┌──────────────────┐
│   Node           │  validate_proof() checks signature
│   Validation     │  Version check (optimistic concurrency)
│                  │  Purpose enum validation
│                  │  Controller ownership confirmation
└─────┬────────────┘
      │
      ▼
┌──────────────────┐
│  State           │  Dual-store RocksDB write
│  Transition      │  Primary: dids-store || did_hash → document
│                  │  Reverse: dids-addr-index || address → DID ref
│                  │  Version incremented atomically
└─────┬────────────┘
      │
      ▼
┌──────────────────┐
│   Consensus      │  PoW + DAG orders operation
│                  │  Block inclusion confirms finality
└─────┬────────────┘
      │
      ▼
┌──────────────────┐
│  Finalized       │  CrestDocument now immutable at new version
│  Crest State     │  Resolvable by any node via DID or address
└──────────────────┘

A Crest operation is validated by the node before it can modify the canonical identity state. This validation happens in multiple stages that together prevent unauthorized modifications, reject malformed requests, and maintain consistency across the distributed network.

At the client layer, the wallet or SDK constructs a typed request object matching the intended operation. For creation, this includes the desired verification methods and services. For updates, it specifies which fields to modify along with the expected current version number. For key rotation, it identifies the method to replace and provides the new public key material while preserving the existing purpose attribute. For deactivation, it includes only the target DID since no additional parameters are needed beyond authorization.

Signature generation uses the controller's private key through CRYSTALS-Dilithium3, producing a 2465-byte signature that covers the complete request payload. The signing key must match the operation type: authentication-purpose keys sign create and update requests, capability-invocation keys sign delegation operations, assertion keys sign credential issuance payloads. This purpose matching happens before the request leaves the client, catching obvious mismatches early.

Upon reaching a validating node, signature verification confirms the signer actually controls the claimed controller address. The node retrieves the current Crest state if it exists, extracts the public key corresponding to the declared purpose, and validates the Dilithium3 signature against the request bytes. Any mismatch between the signed payload and the serialized request, any corruption in the public key bytes, or any usage of an incorrect purpose key causes immediate rejection with a specific error code indicating what went wrong.

For update operations specifically, the node performs an optimistic concurrency check by comparing the expected version in the request against the actual stored version. If another update committed between when the client read the current state and when this request arrived, the versions will not match and the operation fails with a version conflict error. The client must then re-resolve the latest state, apply its changes on top of the new version, increment accordingly, and retry. This prevents silent lost updates where two concurrent modifications overwrite each other.

Once validation passes, the state transition writes to both stores in the dual-store architecture atomically. The primary store under the dids-store prefix records the updated or newly created CrestDocument with its incremented version number and fresh timestamp. Simultaneously, the reverse index under the dids-addr-index prefix maps the controller address to the DID reference, enabling future address-to-DID lookups without scanning. These writes use RocksDB batch operations ensuring either both succeed or neither persists, maintaining index consistency even if the node crashes mid-write.

Finally, consensus incorporation places the operation into a block through Sahyadri's Proof-of-Work plus DAG hybrid mechanism. Once sufficient work proves the block and DAG ordering establishes its position relative to concurrent blocks, the Crest state transition achieves finality. Other nodes receiving this block can independently verify the signature, replay the state transition, and arrive at identical Crest state without trusting the original proposing node. At this point, the operation is irreversible and globally visible to any participant resolving the affected DID.

Crest State Transition

┌─────────────────────────┐
│      Crest v1           │  Version: 1
│                         │  Controller: csm1sabc...
│  verification_methods:  │  Keys: [#key-auth, #key-agree]
│    #key-auth (Auth)     │  Services: [#hub]
│    #key-agree (KeyAg)   │  Status: Active
│  services:              │  Updated: 1704000000
│    #hub                 │
└──────────┬──────────────┘
           │
           ▼
┌─────────────────────────┐
│    Update Operation     │  Request: Add #key-delegate
│                         │  Expected Version: 1
│  {                      │  New Verification Method:
│    crest_id: "...",     │    id: "#key-delegate"
│    add_verification: [  │    type: "Dilithium3"
│      {                  │    purpose: CapabilityDelegation
│        id: "#key-del",  │    public_key: "<1952 bytes>"
│        purpose: CapDel  │  }
│      }                  │  Signature: controller signs payload
│    ],                   │
│    expected_version: 1  │
│  }                      │
└──────────┬──────────────┘
           │
           ▼
┌─────────────────────────┐
│      Validation         │  ✓ Signature valid?
│                         │  ✓ Controller matches signer?
│  Checks:                │  ✓ Purpose enum valid?
│  • Signature check      │  ✓ expected_version == stored_version?
│  • Ownership check      │  ✓ New key format correct?
│  • Purpose validation   │  ✓ Not deactivated?
│  • Version match        │
│  • Active status        │
└──────────┬──────────────┘
           │
           │  All pass → SUCCESS
           │  Any fail → ERROR (see below)
           ▼
┌─────────────────────────┐
│      Crest v2           │  Version: 2 ← Auto-incremented
│                         │  Controller: csm1sabc... (unchanged)
│  verification_methods:  │  Keys: [#key-auth, #key-agree, #key-delegate] ← NEW
│    #key-auth (Auth)     │  Services: [#hub] (unchanged)
│    #key-agree (KeyAg)   │  Status: Active (unchanged)
│    #key-del (CapDel) ◄──│  Updated: 1704086400 ← New timestamp
│  services:              │
│    #hub                 │
└─────────────────────────┘

What Gets Validated

Before any state transition occurs, the node runs validate_proof() which checks six conditions in sequence. First, it verifies the cryptographic signature using the controller's Dilithium3 public key from the current stored state, rejecting any request where the signature fails or was produced by a different key. Second, it confirms the signing address actually matches the controller field of the existing Crest, preventing unauthorized parties from submitting modifications even if they somehow obtain a valid-looking signature. Third, it validates that every purpose value in new verification methods corresponds to a recognized variant in the CrestPurpose enum, catching typos like "Authenticationn" or invented purposes before they reach storage. Fourth, it compares the expected_version in the request against the actual stored version number, detecting concurrent modifications that would cause lost updates. Fifth, it confirms the target Crest has not been previously deactivated since deactivated documents reject all further operations by design. Sixth, for update operations specifically, it verifies that no duplicate method IDs would result from applying the changes, maintaining uniqueness within each document.

What Actually Changes

A successful transition modifies only the fields specified in the operation request while preserving everything else unchanged. Adding a verification method appends it to the array without touching existing entries. Removing a service deletes that single entry while leaving all other services intact. Rotating a key replaces the public_key_base64 bytes for the targeted method ID while keeping its purpose, ID, and position identical. The controller address never changes through updates because transferring identity ownership requires deactivation followed by fresh creation under a new controller rather than an in-place modification. Timestamp fields update automatically to reflect when the transition committed, not when the client constructed the request. The dual-store architecture receives both writes atomically: the primary store records the complete new document under the DID hash, and the reverse index refreshes the address-to-DID mapping if the controller reference changed, which it typically does not during normal operations.

How Version Increments

Version numbers are monotonically increasing unsigned 64-bit integers starting at one for newly created Crests. Each successful write operation, whether it adds a single verification method or modifies multiple fields simultaneously, increments the version by exactly one. The system does not use fractional versions, semantic versioning schemes, or branch identifiers. If Crest currently sits at version forty-two and an approved update adds two services and rotates one key, the resulting document becomes version forty-three, not forty-four or forty-two-point-one. This simple incrementing scheme enables the optimistic concurrency control mechanism: clients read the current version, include it as expected_version in their modification requests, and the node rejects the operation if the stored version has advanced past what the client observed. Upon rejection, the client re-resolves the latest state, applies changes atop the newer version, and retries. No locking, no transactions spanning multiple blocks, no coordination between competing updaters beyond reading and comparing version numbers.

What Happens On Invalid Operations

When validation fails, the node returns a specific error variant from the CrestOpError enum and zero state changes occur. The original Crest remains at its current version with all fields untouched. Different failure modes produce different error responses so clients can handle each case appropriately. For signature failures, the error indicates which verification step failed, allowing the client to distinguish between corrupted signatures, wrong keys used for signing, and malformed public key bytes in the stored document. The typical fix is re-signing with the correct controller key. For version conflicts, meaning another update committed after the client last read the state, the error includes the current version number so the client can immediately construct a retry without an extra round-trip to fetch the latest state. The client bumps its expected_version to the reported value and resubmits. For ownership mismatches, where the signing address does not match the stored controller, the error makes clear that the requester lacks authorization. This typically indicates configuration errors in wallet software attempting operations with the wrong key pair. For deactivated target errors, meaning the Crest was already deactivated before this operation arrived, the response informs the client that no further modifications are possible. The only recourse is creating a fresh Crest under a new DID if identity re-establishment is needed. For invalid purpose or duplicate method errors, the specific problematic field is identified so the client can fix the request payload before retrying. These represent client-side bugs rather than transient conditions and typically require code fixes rather than automatic retries. In all error cases, the dual-store database receives zero writes. No partial updates, no orphaned index entries, no inconsistent state visible to other nodes or subsequent queries. The validation gate either passes completely and transitions occur atomically, or fails completely and nothing touches persistent storage.

Overview

The Crest Model is a typed identity framework designed for the Sahyadri blockchain. It provides structured, validated identity documents with native post-quantum cryptographic support through Dilithium3.

Unlike flat string-based DID documents, the Crest Model enforces type safety at the protocol level. Every verification method has an explicit purpose, every service endpoint is validated, and all state changes are versioned for auditability.

The model addresses three limitations in existing approaches:

• No key purpose differentiation: Traditional DIDs represent keys as string arrays with no semantic meaning. A signing key looks identical to an encryption key.


• No post-quantum support: ECDSA and Ed25519 will become vulnerable to quantum computers. Adding post-quantum cryptography as an afterthought creates integration complexity.


• No enforced validation: Flat JSON-LD documents rely on application-level validation, which may be inconsistent or absent.

Core Concepts

What is a Crest?

A Crest is a structured identity document representing an entity on the Sahyadri network. Entities can be individuals, organizations, devices, or autonomous agents.

Every Crest contains:

• Globally unique identifier: A DID in the format did:sahyadri:{hash}
• Controller address: A Sahyadri address (csm1s...) that owns and controls the identity
• Typed verification methods: Cryptographic keys with explicit purposes
• Validated service endpoints: Verified external service references
• Version number: Monotonically increasing counter tracking modifications
• Lifecycle state: Active or deactivated (tombstone pattern)

Data Model Comparison

Data Types

CrestDocument

The primary identity structure. All identities on Sahyadri are represented as CrestDocument instances.

pub struct CrestDocument {
    // Identifiers
    pub id: String,
    // Format: "did:sahyadri:{sha256(controller + created_at)}"
    
    pub context: String,
    // Default: "https://w3id.org/crest/v1"
    
    pub controller: String,
    // Sahyadri address: "csm1s..."
    // Immutable once set
    
    // Verification Methods
    pub authentication: Vec<CrestVerificationMethod>,
    // Keys for signing transactions
    
    pub key_agreement: Vec<CrestVerificationMethod>,
    // Keys for encryption/key exchange
    
    // Services
    pub services: Vec<CrestService>,
    // Validated external endpoints
    
    // State
    pub version: u64,
    // Starts at 1, increments on each mutation
    
    pub deactivated: bool,
    // false = active, true = tombstone (irreversible)
    
    // Timestamps
    pub created_at: u64,
    // Unix timestamp at creation (immutable)
    
    pub updated_at: u64,
    // Unix timestamp of last modification
}

CrestVerificationMethod

A cryptographic key with explicit purpose typing. This is the primary innovation over traditional DID key representations.

pub struct CrestVerificationMethod {
    pub id: String,
    // Format: "{controller}#key-{n}"
    // Example: "csm1sxq9...#key-1"
    
    pub key_type: String,
    // Currently supported: "Dilithium3"
    // Future: algorithm migration path
    
    pub controller: String,
    // Must match parent CrestDocument.controller
    
    pub public_key_bytes: Vec<u8>,
    // Raw key bytes
    // Dilithium3: exactly 1952 bytes
    
    pub purpose: CrestPurpose,
    // Typed purpose enumeration
    
    pub created_at: u64,
    // Key addition timestamp
    
    pub expires_at: Option<u64>,
    // Optional expiration for time-limited credentials
}

CrestPurpose Enumeration

The purpose enum defines what operations a key can perform. This prevents accidental misuse of keys across different security domains.

CrestService

A validated service endpoint attached to the identity. Services undergo protocol-level validation before inclusion.

pub struct CrestService {
    pub id: String,
    // Format: "{controller}#svc-{type}"
    
    pub service_type: String,
    // Standard types:
    // - "DIDComm": Decentralized messaging
    // - "Web5DWN": Web5 Data Network node
    // - "HubService": Universal resolver endpoint
    // - "LinkedDomains": Domain ownership verification
    // - "CredentialService": Verifiable credential issuance
    
    pub service_endpoint: String,
    // URL or DID reference where service operates
    
    pub validated: bool,
    // Protocol has verified endpoint accessibility
}

Storage Architecture

Dual-Store Design

The Crest Model uses two RocksDB stores to enable bidirectional lookups:

Store 1: Primary Identity Store
───────────────────────────────
Prefix: "dids-store" (0x646964732d73746f7265)

Key:   DidKey(did_bytes)
Value: DidDocument (JSON serialization)

Operation: resolve_crest(did) → CrestDocument
Lookup:  O(1) hash access


Store 2: Reverse Address Index  
───────────────────────────────
Prefix: "dids-addr-index" (0x646964732d616464722d696e646578)

Key:   DidKey(address_bytes)
Value: DidIndexEntry(did_string)

Operation: resolve_by_address(address) → CrestDocument
Lookup:  O(1) hash access (two-hop: address → did → document)

Why Dual Stores?

Cache Layer

Both stores use CachedDbAccess providing LRU caching:

pub struct DbDidStore {
    pub did_access: CachedDbAccess<DidKey, DidDocument>,
    // Primary store with LRU cache
    
    pub address_index: CachedDbAccess<DidKey, DidIndexEntry>,
    // Reverse index with LRU cache
}

// Cache characteristics:
// - Configurable maximum size (default: 100MB)
// - Least-recently-used eviction policy
// - Thread-safe via RwLock
// - Write-through on mutations
// - Expected hit rate: >95% for active identities

Identity Lifecycle

State Machine

                    ┌──────────────┐
                    │    CREATED   │
                    │  v=1, active │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              ▼            ▼            ▼
     ┌────────────┐ ┌──────────┐ ┌────────────┐
     │   RESOLVE  │ │  UPDATE  │ │  ROTATE    │
     │ (read-only)│ │ v=2,3,...│ │   KEY      │
     └────────────┘ └────┬─────┘ └────────────┘
                        │
              ┌─────────┴─────────┐
              ▼                   ▼
     ┌──────────────┐   ┌──────────────┐
     │ ADD SERVICE  │   │ ADD METHOD   │
     │REMOVE SERVICE│   │ROTATE METHOD │
     └──────────────┘   └──────────────┘
                        │
                        ▼
                 ┌──────────────┐
                 │ DEACTIVATE   │
                 │ (tombstone)  │
                 └──────────────┘
                      IRREVERSIBLE

Phase Descriptions

Creation

Creating a new Crest identity performs these validations:

1. Controller address format validation (must be valid csm1s... address)
2. Public key size validation (must equal 1952 bytes for Dilithium3)
3. Uniqueness check (address must not have existing DID via reverse index)
4. Initial verification method construction with purpose: Authentication
5. DID generation from controller + timestamp hash
6. Dual-store write (primary + reverse index)

// Creation request structure
pub struct CreateCrestRequest {
    pub controller: String,        // "csm1s..." 
    pub public_key: Vec<u8>,      // [u8; 1952] Dilithium3
    pub services: Option<Vec<CrestService>>,
    pub additional_keys: Option<Vec<CrestVerificationMethod>>,
}

// Response
pub struct CreateCrestResponse {
    pub did: String,               // Generated DID
    pub document: CrestDocument,   // Complete document
    pub created_at: u64,           // Timestamp
}

Resolution

Two resolution methods exist:

Both methods return CrestDocument. Resolution fails if the identity is deactivated.

Update

Allowed mutations during update:

• Add service (endpoint validated before inclusion)
• Remove service (by ID, must exist)
• Add verification method (with required purpose)

Each update increments the version field. Concurrent updates are detected via version conflict errors requiring client retry.

Key Rotation

Key rotation replaces an existing verification method with a new cryptographic key. Use cases include:

• Compromised key replacement (urgent)
• Scheduled cryptographic refresh (compliance)
• Algorithm migration (Dilithium3 → future standard)

Rotation requires proof of ownership via Dilithium3 signature over the rotation request.

Deactivation

Deactivation sets deactivated = true. This operation:

• Is irreversible
• Preserves complete history for audit
• Blocks all future operations
• Maintains address-DID binding (prevents re-registration)

Deactivation Semantics

┌─────────────────────────┐
│        ACTIVE           │  Status: active = true
│                         │  Operations: ALL ALLOWED
│  • Create               │    create ✓
│  • Update               │    update ✓
│  • Resolve              │    rotate_key ✓
│  • Rotate Key           │    resolve ✓
│  • Deactivate           │    deactivate ✓
└───────────┬─────────────┘
            │
            │  deactivate() called
            │  Controller signs request
            ▼
┌─────────────────────────┐
│      DEACTIVATING       │  Transitional state
│                         │  Validation runs:
│  • Signature check      │    ✓ Controller valid?
│  • Active status check  │    ✓ Currently active?
│  • Ownership check      │    ✓ Signer = controller?
└───────────┬─────────────┘
            │
            │  All checks pass
            ▼
┌─────────────────────────┐
│      DEACTIVATED        │  Status: deactivated = true
│                         │  Operations: SEVERELY RESTRICTED
│  • Resolve     ✓ YES    │    resolve ✓ (read-only)
│  • Update      ✗ NO     │    update ✗ BLOCKED
│  • Rotate Key  ✗ NO     │    rotate_key ✗ BLOCKED
│  • Deactivate  ✗ NO     │    deactivate ✗ ALREADY DONE
│  • Reactivate  ✗ NO     │    reactivation NOT POSSIBLE
│  • Reuse DID    ✗ NO    │    reuse permanently BLOCKED
└─────────────────────────┘

Can a Deactivated DID Still Be Resolved?

Yes. Deactivated Crests remain fully resolvable through both lookup paths in the dual-store architecture. When a node receives a resolve_crest request for a deactivated DID, it fetches the document from the primary store under the dids-store prefix exactly as it would for an active Crest. The returned CrestDocument contains all fields at their final state: verification methods as they existed before deactivation, service endpoints as last configured, version number at the final value, timestamps showing when the document was created and last updated, and the deactivated boolean flag set to true. This permanent resolvability serves important practical purposes. Auditors examining historical identity records can verify what keys a entity used at any point during its active lifetime. Applications that previously verified credentials issued by this identity can still confirm those credentials were signed by valid verification methods at issuance time. Legal and regulatory requirements often mandate preserving identity records for specified periods after closure, and immediate deletion would violate such mandates. Other entities referencing this DID in their own documents or credentials need the resolution to succeed so they can display meaningful information rather than broken references.

Are Updates Allowed After Deactivation?

No. Once the deactivated flag transitions from false to true, all mutation operations are permanently blocked for that DID. The implementation enforces this through an early return check in every write operation path. When update_crest receives a request targeting a deactivated Crest, it checks the stored document's deactivated field before performing any signature validation, version comparison, or state modification. If deactivated equals true, the function immediately returns the error variant AlreadyDeactivated containing the DID string, and zero database writes occur. The same guard exists in rotate_key, which returns the same AlreadyDeactivated error before attempting any key replacement logic. This design choice is intentional rather than technical limitation. Allowing updates to deactivated identities would undermine the semantic meaning of deactivation itself. If an entity publishes a statement that their identity has been retired, subsequent modifications to that identity would contradict the retirement announcement. Observers could not distinguish between legitimate pre-deactivation state and unauthorized post-deactivation tampering without complex version-tracking logic that would complicate every consumer of identity data.

Is Reactivation Possible?

No. Sahyadri's Crest Model does not support reactivation of deactivated identities. There is no reactivate_crest operation, no undelete mechanism, no administrative override that flips the deactivated flag back to false. This permanence reflects the security model where deactivation represents an explicit, intentional, irreversible decision by the controller. Common scenarios triggering deactivation include suspected key compromise where the controller wants to permanently retire the identity rather than risk continued use of potentially exposed keys, organizational dissolution where legal entities cease operations and must terminate their digital presence, or user-initiated account closure where individuals exercise their right to be forgotten or simply no longer wish to maintain the identity on-chain. If a controller who deactivated an identity later decides they need an active identity again, the only option is creating an entirely new Crest with a freshly generated DID derived from the new creation transaction hash. This new Crest has no connection to the old one, receives a new version starting at one, and requires registering fresh verification methods and services. Any external references to the old DID remain pointing to the deactivated document, which continues resolving correctly but shows its deactivated status.

Can the Same DID Be Reused After Deactivation?

No. DIDs are globally unique identifiers derived cryptographically from the creation transaction, and this derivation is deterministic and irreversible. The format did:sahyadri:{hash} uses a content-based hash that depends on the specific transaction bytes, controller address, timestamp, and initial payload at creation time. Recreating identical conditions would require producing a transaction with the exact same bytes at the exact same position in the blockchain, which the consensus mechanism prevents through standard double-spend protection and transaction uniqueness constraints. Furthermore, even if cryptographic reuse were somehow possible, the protocol explicitly prevents it through the primary store structure. The key "dids-store" || did_hash maps to exactly one CrestDocument. If a deactivated document occupies that slot, attempting to store a new document at the same key would overwrite the historical record, which the implementation does not allow. The create_crest operation generates a fresh DID hash for each invocation regardless of whether previous DIDs exist or their current status. From a practical standpoint, DID reuse would confuse any system that has ever resolved the original identity. Verifiable credentials signed by the original Crest's assertion keys would become ambiguous if the same DID pointed to a completely different entity with different keys. Service endpoints cached by applications would suddenly route to unintended destinations. The security implications of DID reuse are sufficiently severe that preventing it is considered a fundamental invariant rather than a policy choice.

In summary, deactivation is a one-way transition with well-defined semantics: the identity becomes immutable but remains readable, all mutations are permanently blocked, no reversal mechanism exists, and the identifier can never be recycled for a different purpose. These guarantees are enforced at the implementation level through conditional checks that reject disallowed operations before they can affect persistent state.

Operations API

Error Handling

All operations return typed errors via CrestOpError:

Cryptographic Foundation

Dilithium3 Integration

The Crest Model uses Dilithium3 (NIST FIPS 204) as the mandatory signature algorithm. Selection rationale:

1. NIST Standardization: Winner of Post-Quantum Cryptography Standardization Project (2022)
2. Lattice-based Security: Resistant to Shor's algorithm and quantum attacks
3. 128-bit Quantum Security Level: Sufficient for all practical threat models
4. Practical Performance: Reasonable operation speed compared to alternatives

Key Size Specifications

Transaction Format

struct SahyadriTransaction {
    // Header
    version: u16,
    chain_id: u32,
    
    // Identity (Crest-bound)
    public_key: [u8; 1952],      // Dilithium3 public key
    nonce: u64,                   // Account nonce (replay prevention)
    
    // Payload
    payload: TransactionPayload,  // DCRT transfer, DID operation, etc.
    
    // Signature
    signature: [u8; 2465],        // Dilithium3 signature
}

// Cryptographic overhead per transaction: ~4.4 KB

Legacy Migration

Conversion Process

Existing W3C-compliant DID documents convert to CrestDocuments via from_legacy():

Reverse conversion via to_legacy() enables interoperability with legacy tooling at the cost of type information loss.

Integration With Account Model

Sahyadri operates both models concurrently:

ACCOUNT MODEL                    CREST MODEL
──────────────                    ════════════
Balance (DCRT tokens)            Typed identity document
Nonce (transaction counter)      Verification methods (by purpose)
ScriptPublicKey                  Service endpoints
                                 Version history

Connection: Account.address == Crest.controller
           (same csm1s... address)

Workflow:
1. Create account (balance=0, nonce=0)
2. Create Crest (bound to account.address)
3. Sign transaction with Crest authentication key
4. Account nonce increments, balance changes
5. Crest remains unchanged (or updates independently)

The Account Model tracks ownership state. The Crest Model tracks identity state. They share addressing but serve orthogonal purposes.

Security Properties

Guarantees

Threat Mitigations

Performance Characteristics

Operation Latency

Storage Estimates

Per Crest Document:
Base overhead:         ~500 bytes (JSON metadata)
Per auth key:        ~2,000 bytes (includes 1952-byte pubkey)
Per agreement key:   ~2,000 bytes (includes 1952-byte pubkey)
Per service:           ~200 bytes (URL + type + validation flag)

Typical user identity (1 auth + 1 agreement + 2 services):
Total: ~4,700 bytes (~4.6 KB)

Scaling:
1,000 identities:       ~4.7 MB
100,000 identities:     ~470 MB
1,000,000 identities:   ~4.7 GB raw (~1.5-2 GB compressed)

Index overhead: ~50 MB per million identities
Cache memory: Configurable LRU (default 100 MB)

Implementation Status

Build status: Compiling successfully with cargo build --release -p sahyadri-consensus.

Reference

File Structure

consensus/src/model/stores/
├── crest_model.rs          # Data types, builder, migration
├── crest_operations.rs     # Business logic layer
├── did_store.rs             # Storage layer with dual indexes
└── mod.rs                   # Module exports

Dependencies

• RocksDB (embedded key-value store)
• serde / serde_json (serialization)
• thiserror (error handling)
• tokio (async runtime)

What is the Account Model?

An Account Model is a blockchain state management approach where each address maintains persistent state including balance, nonce, and transaction history. Unlike UTXO models that track unspent outputs, accounts track global state per address.

┌─────────────────────────────────────┐
│           ACCOUNT MODEL             │
├─────────────────────────────────────┤
│                                     │
│   csm1sabc123...  ─────►  Balance:  1000 CSM
│                         Nonce:    42
│                         Status:   Active
│                         Code:     None (EOA)
│                                     │
│   csm1sxyz789...  ─────►  Balance:  500 CSM
│                         Nonce:    15
│                         Status:   Active
│                         Code:     None (EOA)
│                                     │
└─────────────────────────────────────┘

Every Sahyadri address is an account. When you create a wallet, you get an address with zero balance and nonce at zero. As you receive CSM, your balance increases. As you send transactions, your nonce increments. The network globally tracks every account's current state.

Why Sahyadri Uses an Account Model

Sahyadri chose the Account Model over UTXO for three practical reasons that align with its identity-focused architecture. First, native compatibility with identity. The Crest Model binds DIDs to controller addresses. If addresses were ephemeral UTXO-style pointers without persistent state, identity controllership would require complex tracking layers. Accounts give every address permanent existence, making them natural anchors for Crest documents. Second, simpler developer experience. Developers send transactions from an address to another address without managing UTXO selection, change outputs, or dust thresholds. This lowers the barrier for wallet builders, SDK integrations, and application developers building on Sahyadri. Third, efficient storage. An account needs one database entry regardless of how many incoming payments it received. A UTXO model grows with transaction count, requiring users to consolidate inputs periodically. For a network targeting mainstream adoption, accounts reduce operational complexity.

Account Structure

Each account in Sahyadri's state contains four fields that together define its complete financial status:

struct Account {
    // ─── Address ───
    // Bech32-encoded: csm1s + HRP + checksum
    // Derived from public key (Dilithium3)
    // Example: csm1sxqghw7ue8...
    address: Address,
    
    // ─── Balance ───
    // CSM token amount in smallest unit (micro-CSM)
    // 1 CSM = 1,000,000 units
    balance: u64,
    
    // ─── Nonce ───
    // Transaction counter, starts at 0
    // Increments on EVERY outgoing tx
    nonce: u64,
    
    // ─── Code Hash ───
    // None = EOA (Externally Owned Account)
    // Some(hash) = Smart Contract (future)
    code: Option,
}

Address Format

Sahyadri addresses use bech32 encoding with human-readable prefix csm1s. The address derives from the Dilithium3 public key through SHA-256 hashing followed by bech32 encoding with error-checking checksum.

// Rust Reference
pub fn address_from_pubkey(pubkey: &DilithiumPublicKey) -> Address {
    let hash = sha256(&pubkey.to_bytes());
    bech32_encode("csm1s", &hash)
}

// Output format:
// csm1sxqghw7ue8xhn9j3v5z4q2y6w8r0t1u2i3o4p5k6m7n8

Balance

Unsigned 64-bit integer representing micro-CSM units. Maximum balance per account is approximately 18.4 million CSM before overflow protection triggers rejection of incoming transfers.

// Rust Reference
impl Account {
    pub fn credit(&mut self, amount: u64) -> Result<(), AccountError> {
        self.balance = self.balance.checked_add(amount)
            .ok_or(AccountError::Overflow)?;
        Ok(())
    }
    
    pub fn debit(&mut self, amount: u64) -> Result<(), AccountError> {
        if self.balance < amount {
            return Err(AccountError::InsufficientBalance);
        }
        self.balance -= amount;
        Ok(())
    }
}

Nonce

Monotonically increasing counter starting at zero. Every transaction from this account must include the expected nonce value. Network rejects transactions with nonces lower than stored (replay protection) or higher than stored (gap detection).

Transaction Flow

┌────────┐     ┌──────────┐     ┌────────┐     ┌────────┐
│ Wallet │────▶│  Mempool │────▶│ Block  │────▶│ State  │
│ / SDK  │     │          │     │ Builder│     │ Update │
└────────┘     └──────────┘     └────────┘     └────────┘
     │                │               │              │
     ▼                ▼               ▼              ▼
 Build Tx         Validate        Order by       Apply
 Sign with        Signature       Priority       Balance
 Private Key      Nonce Match      Fees           Change
                  Balance OK                     Increment
                                                  Nonce

A transaction flows through five stages from creation to final state update. The wallet constructs the transaction object specifying sender, recipient, amount, and the current nonce value retrieved from chain state. The private key signs the payload using Dilithium3, producing a signature proving authorization. The signed transaction enters the mempool where it waits for block inclusion. Validators check basic validity: signature verification, nonce matching sender's current account state, sufficient balance for both transfer amount and fees, and properly formatted recipient address. Block builders select transactions from mempool prioritizing by fee density (fees per byte). Selected transactions get ordered within the proposed block and broadcast to the network for consensus. Once consensus confirms the block through Proof-of-Work plus DAG finality, the state transition executes. Sender's balance decreases by amount plus fees. Recipient's balance increases by amount. Both nonces increment. The updated account state persists to RocksDB and propagates to all nodes.

State Transition

BEFORE TRANSACTION                    AFTER TRANSACTION
─────────────────                    ─────────────────

Sender (csm1sabc):                   Sender (csm1sabc):
  Balance: 1000 CSM                    Balance: 899 CSM  (-100 - 1 fee)
  Nonce: 42                            Nonce: 43        (+1)

Recipient (csm1sxyz):                 Recipient (csm1sxyz):
  Balance: 500 CSM                     Balance: 600 CSM  (+100)
  Nonce: 15                            Nonce: 15        (unchanged)

Transaction: 100 CSM + 1 CSM fee      Status: FINALIZED

State transitions are atomic. Either all changes apply successfully, or none do. If the sender has insufficient balance after including fees, the entire transaction rejects before any field modifies. Partial updates where balance deducts but recipient never credits cannot occur due to this atomicity guarantee.

Nonce & Replay Protection

Account Nonce Timeline:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━▶ Time

Nonce=0  Nonce=1  Nonce=2  Nonce=3  Nonce=4
  │        │        │        │        │
  ▼        ▼        ▼        ▼        ▼
 [Tx#1]   [Tx#2]   [Tx#3]   [Tx#4]   [Tx#5]
 Send     Send     Receive  Send     Rotate
 10 CSM   5 CSM    20 CSM   50 CSM   Key

✓ Valid: Tx with nonce=3 when stored nonce=3
✗ Reject: Tx with nonce=2 when stored nonce=3 (REPLAY)
✗ Reject: Tx with nonce=5 when stored nonce=3 (GAP)

The nonce mechanism prevents transaction replay attacks where captured or intercepted transactions get rebroadcast to drain funds. Each transaction includes the sender's current nonce. After processing, the stored nonce increments. A replayed transaction carries the old nonce which no longer matches, causing immediate rejection. Gap rejection prevents out-of-order delivery issues. If transactions with nonces 3, 4, and 5 are sent but arrive in order 5, 3, 4, the node accepts nonce 3 (matches), queues nonce 4 (waits for gap fill), and rejects nonce 5 (exceeds expected by more than one). This ordering enforcement ensures deterministic state across all nodes regardless of network arrival sequences.

Transaction Fees

Fees associated with CSM transactions and applicable protocol operations. Every transaction pays a base fee plus optional priority fee for faster inclusion during congestion periods.

// Fee Calculation (Rust Reference)
fn calculate_fee(tx: &Transaction, base_rate: u64) -> u64 {
    let size_bytes = tx.serialized_size();
    let base_fee = base_rate * size_bytes as u64;
    let priority = tx.priority_fee.unwrap_or(0);
    base_fee.saturating_add(priority)
}

// Example: Standard transfer
// Size: ~250 bytes, Base rate: 4 per byte
// Base fee: 1000 micro-CSM = 0.001 CSM

Account Model vs UTXO

Account ↔ Crest Relationship

┌─────────────────────────────────────────────┐
│              SAHYADRI PROTOCOL              │
│                                             │
│  ┌───────────────┐    ┌───────────────┐    │
│  │ ACCOUNT MODEL │◄──►│  CREST MODEL  │    │
│  │               │    │               │    │
│  │ • Balance     │    │ • DID         │    │
│  │ • Nonce       │    │ • Controller  │    │
│  │ • Transfers   │    │ • Keys        │    │
│  │ • Fees        │    │ • Services    │    │
│  └───────┬───────┘    └───────┬───────┘    │
│          │                    │             │
│          │    Controller      │             │
│          │◄═══════════════════┘             │
│          │    Address links them            │
│          │                                  │
│          ▼                                  │
│  ┌──────────────────────────────────┐       │
│  │         RocksDB Storage          │       │
│  │                                  │       │
│  │  accounts/ || addr → Account     │       │
│  │  dids-store/ || did → CrestDoc   │       │
│  │  dids-addr-index/ || addr → DID  │       │
│  └──────────────────────────────────┘       │
└─────────────────────────────────────────────┘

The two models connect through the controller address field. Every Crest stores its controller as a Sahyadri address. That address exists in the Account Model with its own balance and nonce. When a Crest operation requires signing, the private key controlling that account address produces the Dilithium3 signature. This separation means you can have funds without identity (pure EOA sending CSM), identity without funds (free Crest creation), or both linked through the same address. The reverse index enables looking up which DID belongs to any given address, bridging the two models for applications that need complete entity information.

Implementation / Rust Reference

The following code reflects the actual implementation within the Sahyadri consensus layer. These are the real structures and functions currently deployed.

// ════════════════════════════════════════════════════════
// FILE: consensus/src/model/stores/account_store.rs
// Actual Account Model implementation (~130 lines)
// ════════════════════════════════════════════════════════

/// Represents the state of an account in the Sahyadri network.
#[derive(Clone, Debug, Serialize, Deserialize, PartialEq, Eq, Default)]
pub struct AccountState {
    pub balance: u64,
    pub nonce: u64,
}

impl AccountState {
    pub fn new(balance: u64, nonce: u64) -> Self {
        Self { balance, nonce }
    }
}

/// A wrapper to make ScriptPublicKey compatible with RocksDB keys
#[derive(Clone, Eq, Hash, PartialEq)]
pub struct AccountKey(Vec);

impl AccountKey {
    pub fn new(spk: &ScriptPublicKey) -> Self {
        let mut bytes = spk.version().to_le_bytes().to_vec();
        bytes.extend(spk.script().iter());
        Self(bytes)
    }
}

/// Trait defining read operations for the Account Store.
pub trait AccountStoreReader {
    fn get(&self, script_public_key: &ScriptPublicKey) -> StoreResult;
    fn get_balance(&self, script_public_key: &ScriptPublicKey) -> StoreResult;
    fn get_nonce(&self, script_public_key: &ScriptPublicKey) -> StoreResult;
}

/// Trait defining write operations for the Account Store.
pub trait AccountStore: AccountStoreReader {
    fn set_batch(&self, batch: &mut WriteBatch, script_public_key: &ScriptPublicKey, state: AccountState) -> StoreResult<()>;
    fn update_balance_batch(&self, batch: &mut WriteBatch, script_public_key: &ScriptPublicKey, balance_change: i64) -> StoreResult<()>;
    fn increment_nonce_batch(&self, batch: &mut WriteBatch, script_public_key: &ScriptPublicKey) -> StoreResult<()>;
    fn decrement_nonce_batch(&self, batch: &mut WriteBatch, script_public_key: &ScriptPublicKey) -> StoreResult<()>;
}

const STORE_PREFIX: &[u8] = b"accounts-store";

/// Database-backed Account Store using RocksDB with caching
#[derive(Clone)]
pub struct DbAccountStore {
    access: CachedDbAccess,
}

impl DbAccountStore {
    pub fn new(db: Arc, cache_size: u64) -> Self {
        Self { 
            access: CachedDbAccess::new(
                db, 
                CachePolicy::Count(cache_size as usize), 
                STORE_PREFIX.to_vec()
            ) 
        }
    }
}

impl AccountStoreReader for DbAccountStore {
    /// Get full account state (returns default if not found)
    fn get(&self, script_public_key: &ScriptPublicKey) -> StoreResult {
        match self.access.read(AccountKey::new(script_public_key)) {
            Ok(state) => Ok(state),
            Err(StoreError::KeyNotFound(_)) => Ok(AccountState::default()),
            Err(e) => Err(e),
        }
    }

    /// Get only balance
    fn get_balance(&self, script_public_key: &ScriptPublicKey) -> StoreResult {
        self.get(script_public_key).map(|state| state.balance)
    }

    /// Get only nonce
    fn get_nonce(&self, script_public_key: &ScriptPublicKey) -> StoreResult {
        self.get(script_public_key).map(|state| state.nonce)
    }
}

impl AccountStore for DbAccountStore {
    /// Set account state directly
    fn set_batch(&self, batch: &mut WriteBatch, script_public_key: &ScriptPublicKey, state: AccountState) -> StoreResult<()> {
        self.access.write(BatchDbWriter::new(batch), AccountKey::new(script_public_key), state)
    }

    /// Update balance by signed amount (positive=credit, negative=debit)
    fn update_balance_batch(
        &self,
        batch: &mut WriteBatch,
        script_public_key: &ScriptPublicKey,
        balance_change: i64,
    ) -> StoreResult<()> {
        let mut state = self.get(script_public_key)
            .unwrap_or(AccountState { balance: 0, nonce: 0 });

        if balance_change >= 0 {
            state.balance = state.balance.saturating_add(balance_change as u64);
        } else {
            let decrement = balance_change.unsigned_abs();
            state.balance = state.balance.saturating_sub(decrement);
        }

        self.set_batch(batch, script_public_key, state)
    }

    /// Increment nonce by 1 (after valid transaction)
    fn increment_nonce_batch(&self, batch: &mut WriteBatch, script_public_key: &ScriptPublicKey) -> StoreResult<()> {
        let mut state = self.get(script_public_key)
            .unwrap_or(AccountState { balance: 0, nonce: 0 });
        state.nonce = state.nonce.saturating_add(1);
        self.set_batch(batch, script_public_key, state)
    }

    /// Decrement nonce by 1 (for rollback scenarios)
    fn decrement_nonce_batch(&self, batch: &mut WriteBatch, script_public_key: &ScriptPublicKey) -> StoreResult<()> {
        let mut state = self.get(script_public_key)
            .unwrap_or(AccountState { balance: 0, nonce: 0 });
        state.nonce = state.nonce.saturating_sub(1);
        self.set_batch(batch, script_public_key, state)
    }
}

// ════════════════════════════════════════════════════════
// FILE: consensus/src/model/stores/crest_model.rs
// Crest Model implementation (~750 lines)
// ════════════════════════════════════════════════════════

/// Core identity document representing an entity on Sahyadri
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct CrestDocument {
    pub id: String,                              // did:sahyadri:{hash}
    pub controller: String,                       // csm1s... address
    pub verification_methods: Vec,
    pub services: Vec,
    pub version: u64,
    pub created_at: u64,
    pub updated_at: u64,
    pub deactivated: bool,
}

/// Verification method with typed purpose (KEY INNOVATION)
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct CrestVerificationMethod {
    pub id: String,                               // #key-1, #key-auth
    pub method_type: String,                       // Dilithium3
    pub public_key_base64: String,                 // 1952 bytes
    pub purpose: CrestPurpose,                     // Explicit purpose!
}

/// Enum defining key usage contexts
#[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
pub enum CrestPurpose {
    Authentication,           // Login, sessions
    KeyAgreement,             // Encryption exchange
    CapabilityInvocation,     // Authorize actions
    CapabilityDelegation,     // Grant authority
    Assertion,                // Sign claims/VCs
}

/// Service endpoint registered under identity
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct CrestService {
    pub id: String,
    pub service_type: String,  // DWNEndpoint, Discovery
    pub endpoint: String,      // Validated URL
}

// ════════════════════════════════════════════════════════
// FILE: consensus/src/model/stores/did_store.rs
// Dual-store architecture for DID/Crest lookup
// ════════════════════════════════════════════════════════

/// Entry in reverse index mapping address → DID
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct DidIndexEntry {
    pub did_hash: [u8; 32],
    pub created_at: u64,
    pub version: u64,
}

/// Dual-store structure enabling O(1) bidirectional lookups
pub struct DbDidStore {
    /// Primary store: dids-store || did_hash → CrestDocument
    /// Prefix: 0x646964732d73746f7265 ("dids-store")
    pub did_access: CachedDbAccess,
    
    /// Reverse index: dids-addr-index || address → DidIndexEntry
    /// Prefix: 0x646964732d616464722d696e646578
    pub address_index: CachedDbAccess,
}

impl DbDidStore {
    /// Store new Crest in both indexes atomically
    pub fn put(&self, did: &DidKey, doc: &CrestDocument) -> Result<(), StoreError> {
        let batch = BatchWriter::new();
        
        // Primary store write
        batch.put(self.did_access.prefix(did.hash()), serialize(doc)?);
        
        // Reverse index write
        batch.put(self.address_index.prefix(&doc.controller), serialize(DidIndexEntry {
            did_hash: did.hash(),
            created_at: doc.created_at,
            version: doc.version,
        })?);
        
        self.db.write_batch(batch)
    }
    
    /// Resolve by DID (primary lookup)
    pub fn get_by_did(&self, did: &DidKey) -> Result, StoreError> {
        self.did_access.get(&did.hash())
    }
    
    /// Resolve by address (reverse index then primary)
    pub fn get_by_address(&self, addr: &Address) -> Result, StoreError> {
        let entry: DidIndexEntry = self.address_index.get(addr.bytes())?
            .ok_or(StoreError::NotFound)?;
        self.get_by_did(&DidKey::from_hash(entry.did_hash))
    }
}

Sahyadri Vector Engine (SVE)

AVX2 + Rayon Cryptographic Acceleration

A high-performance dual-layer optimization system combining Intel AVX2 SIMD vectorization with Rust Rayon multi-core parallelism for accelerating Dilithium3 post-quantum signature verification in the Sahyadri L1 blockchain.

A high-performance dual-layer optimization system combining Intel AVX2 SIMD vectorization with Rust Rayon multi-core parallelism for accelerating Dilithium3 post-quantum signature verification in the Sahyadri L1 blockchain.

1. What is Sahyadri Vector Engine?

Sahyadri Vector Engine (SVE) is a cryptographic acceleration layer built into the core of Sahyadri L1 blockchain's consensus engine. It is not a separate program or external library, but rather an integrated optimization strategy that leverages two powerful technologies working together: Intel's AVX2 instruction set for single-core parallelism, and Rust's Rayon library for multi-core distributed processing.

The engine targets specifically the Dilithium3 (CRYSTALS-Dilithium) signature verification algorithm, which is NIST's post-quantum cryptography standard selected to replace RSA and ECDSA against quantum computer attacks. Each Dilithium3 verification involves complex mathematical operations on polynomials (algebraic expressions with 256 terms), and SVE accelerates these operations dramatically.

Why "Vector Engine"?

The name comes from "vectorization" - the technique of performing one operation on multiple data points simultaneously. AVX2 uses 256-bit "vector registers" that hold 8 integers at once. When we add two vectors of 8 integers each, all 8 additions happen in a single clock cycle. This is like having 8 math workers inside one CPU core, plus Rayon adds 8 actual CPU cores, giving us 64 virtual workers total.

2. Why Sahyadri Uses It

To understand why SVE exists, we must first understand the problem it solves: Dilithium3 verification is computationally expensive, and Sahyadri processes thousands of these verifications every second.

The Workload Problem

Bottleneck Analysis Before SVE

BLOCK PROCESSING TIME BREAKDOWN (Before Optimization)

Network Receive     ████████████████████  200ms  (P2P propagation)
DAG Sorting         ██████████           50ms   (GhostDAG ordering)
Disk Write          ████                 20ms   (RocksDB storage)
State Update        ██                   10ms   (UTXO/DID changes)
────────────────────────────────────────────────────────────────
SIGNATURE VERIFY     █████████████████    500ms  ← BOTTLENECK (50%!)
────────────────────────────────────────────────────────────────
TOTAL               ~780ms (leaves only 220ms margin)

Without optimization, signature verification alone consumes over half the block time budget. This limits maximum TPS and creates risk of missed blocks under load. SVE reduces the crypto portion from 500ms to approximately 45ms, making network latency the new bottleneck instead.

Why Parallel Verification Works Here

Signature verification has a special property called "embarrassing parallelism" - verifying transaction A's signature has zero dependency on verifying transaction B's signature. They share no data, no ordering requirement, and no synchronization needed until all results are collected. This makes it perfect for both AVX2 (within one verification) and Rayon (across multiple verifications).

3. AVX2 Acceleration

AVX2 stands for "Advanced Vector Extensions 2" - Intel's 256-bit SIMD instruction set introduced in 2013 with Haswell processors. It is the key technology that enables SVE's single-core speedup.

How AVX2 Works (Visual Explanation)

NORMAL SCALAR OPERATION (1 number at a time):
┌─────┐     ┌─────┐     ┌─────┐
│  5  │  +  │  3  │  =  │  8  │    ← 1 addition, 1 clock cycle
└─────┘     └─────┘     └─────┘


AVX2 VECTOR OPERATION (8 numbers at once):
┌───────────────────────────────────────┐
│   5  │  12 │  7  │  23 │  1  │  9  │ 4 │ 15 │  ┐
└───────────────────────────────────────┘  │  VPADDQ instruction
┌───────────────────────────────────────┐  │  (256-bit add)
│   3  │  4  │  2  │  10 │  0  │  5  │ 2 │ 8  │  ├→ 1 operation, 1 clock cycle
└───────────────────────────────────────┘  │
┌───────────────────────────────────────┐  ▼
│   8  │  16 │  9  │  33 │  1  │ 14 │ 6 │ 23 │
└───────────────────────────────────────┘

RESULT: 8 additions in the time of 1! (8x speedup for this operation)

AVX2 Instructions Used in Dilithium3

CPU Compatibility Matrix

4. Rayon Parallel Verification

If AVX2 is like having 8 workers inside one office (CPU core), then Rayon is like opening 8 offices and giving each its own work. Rayon is Rust's data-parallelism library that automatically distributes work across available CPU cores using a work-stealing scheduler.

Rayon Architecture Diagram

                         RAYON THREAD POOL ARCHITECTURE
                         
    ┌─────────────────────────────────────────────────────────────┐
    │                    VERIFY_POOL (LazyLock static)            │
    │                     Thread Count: 7 threads                 │
    │                   Formula: (num_cpus - 1).max(1)            │
    └─────────────────────────────────────────────────────────────┘
                                        │
                    ┌───────────────────┼───────────────────┐
                    │                   │                   │
                    ▼                   ▼                   ▼
        ┌───────────────┐    ┌───────────────┐    ┌───────────────┐
        │   Thread 0    │    │   Thread 1    │    │  ... Thread 6 │
        │  (Worker #1)  │    │  (Worker #2)  │    │  (Worker #7)  │
        └───────┬───────┘    └───────┬───────┘    └───────┬───────┘
                │                    │                    │
                ▼                    ▼                    ▼
        ┌───────────────┐    ┌───────────────┐    ┌───────────────┐
        │ Signature #1  │    │ Signature #8  │    │ Signature #57 │
        │ Signature #2  │    │ Signature #9  │    │ Signature #58 │
        │ ...           │    │ ...           │    │ ...           │
        │ Signature #7  │    │ Signature #15 │    │ Signature #63 │
        └───────┬───────┘    └───────┬───────┘    └───────┬───────┘
                │                    │                    │
                ▼                    ▼                    ▼
        ┌───────────────┐    ┌───────────────┐    ┌───────────────┐
        │  dilithium-rs │    │  dilithium-rs │    │  dilithium-rs │
        │  + AVX2 math  │    │  + AVX2 math  │    │  + AVX2 math  │
        └───────┬───────┘    └───────┬───────┘    └───────┬───────┘
                │                    │                    │
                └────────────────────┼────────────────────┘
                                     ▼
                          ┌────────────────────┐
                          │  Results Collected │
                          │  [true, true,      │
                          │   false, true, ...]│
                          └─────────┬──────────┘
                                    ▼
                          Invalid TXs → REJECTED
                          Valid TXs  → PROCESSED

Work Stealing Explained

Rayon uses "work stealing" - if Thread 0 finishes its 7 signatures but Thread 1 still has 3 left, Thread 0 can "steal" work from Thread 1's queue. This ensures balanced load even when some verifications take longer than others (due to cache misses, branch prediction failures, etc.).

5. AVX2 + Rayon Combined Architecture

This is where the magic happens. AVX2 and Rayon operate at different levels of the computation stack, creating a multiplicative speedup effect.

Two-Dimensional Parallelism Diagram

                    TWO-DIMENSIONAL PARALLELISM MODEL
                    ════════════════════════════════

                        VERTICAL (Rayon)
                        ↑    Multi-Core
                        │
                ┌───────┼───────┬─────────┐
                │       │       │         │         HORIZONTAL (AVX2)
              Core 0  Core 1  Core 2    Core N      Single-Core SIMD
                │       │       │          │         ↓
            ┌───┴───┐ ┌─┴────┐ ┌─┴────┐  ┌─┴───┐    ┌─────────────────┐
            │AVX2 x8│ │AVX2x8│ │AVX2x8 │ │AVX2x8│   │  32-bit Integer │
            │workers│ │workers││workers│ │workers│  │   Coefficients  │
            └───┬───┘ └──┬───┘ └──┬────┘ └──┬───┘   │  c0,c1,...c255] │
                │       │       │       │           └─────────────────┘
                └───────┴───────┴───────┘
                        │
                  TOTAL PARALLELISM
                  = 8 cores × 8 AVX2 lanes
                  = 64 simultaneous operations
                
                SPEEDUP = 1.35 (AVX2) × 8 (Rayon)
                        ≈ 10.8x theoretical

Complete Execution Flow

STEP-BY-STEP: How SVE Processes A Block With 1000 Transactions

┌─────────────────────────────────────────────────────────────────────┐
│ STEP 1: BLOCK ARRIVAL                                               │
│ Block received from P2P network containing 1000 transactions        │
└─────────────────────────────────────────────────────────────────────┘                                    │
▼
┌─────────────────────────────────────────────────────────────────────┐
│ STEP 2: EXTRACTION                                                  │
│ Processor extracts 1000 (signature, pubkey) pairs into Vec buffer   │
│ Memory used: ~1000 × (2465 + 1952) bytes ≈ 4.4 MB                   │
└─────────────────────────────────────────────────────────────────────┘
                                    │
▼
┌────────────────────────────────────────────────────────────────────┐
│ STEP 3: RAYON DISPATCH                                             │
│ VERIFY_POOL.install(|| {                                           │
│     batch.par_iter().map(|(sig, pubkey)| {                         │
│         DilithiumKeyPair::verify(sig, pubkey)                      │
│     }).collect::>()                                      │
│ })                                                                 │
│                                                                    │
│ → 1000 signatures ÷ 7 threads ≈ 143 signatures per thread          │
└────────────────────────────────────────────────────────────────────┘
                                    │
            ┌───────────────────────┼───────────────────────┐
            ▼                       ▼                       ▼
    ┌───────────────┐       ┌───────────────┐       ┌───────────────┐
    │   THREAD 0    │       │   THREAD 1    │       │   THREAD 6    │
    │  Sigs 0-142   │       │ Sigs 143-285  │       │ Sigs 857-999  │
    └───────┬───────┘       └───────┬───────┘       └───────┬───────┘
            │                       │                       │
            ▼                       ▼                       ▼
    ┌───────────────┐       ┌───────────────┐       ┌───────────────┐
    │ STEP 4: AVX2  │       │ STEP 4: AVX2  │       │ STEP 4: AVX2  │
    │ PER-SIGNATURE │       │ PER-SIGNATURE │       │ PER-SIGNATURE │
    │               │       │               │       │               │
    │ 4a. Hash msg  │       │ 4a. Hash msg  │       │ 4a. Hash msg  │
    │ 4b. NTT(forward) AVX2 │ 4b. NTT(forward) AVX2 │ 4b. NTT(forward) AVX2│
    │ 4c. Poly mult  AVX2 │ 4c. Poly mult  AVX2 │ 4c. Poly mult  AVX2│
    │ 4d. NTT(inverse)AVX2 │ 4d. NTT(inverse)AVX2 │ 4d. NTT(inverse)AVX2│
    │ 4e. Compare    │       │ 4e. Compare    │       │ 4e. Compare    │
    └───────┬───────┘       └───────┬───────┘       └───────┬───────┘
            │                       │                       │
            └───────────────────────┼───────────────────────┘
                                    ▼
┌────────────────────────────────────────────────────────────────────┐
│ STEP 5: RESULT AGGREGATION                                         │
│ results = [true, true, false, true, true, ..., true]               │
│ (997 valid, 3 invalid signatures detected)                         │
└────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌────────────────────────────────────────────────────────────────────┐
│ STEP 6: TRANSACTION FILTERING                                      │
│ Valid TXs (997)  → Continue to UTXO/DID processing                 │
│ Invalid TXs (3)  → Rejected with "signature verification failed"   │
└────────────────────────────────────────────────────────────────────┘

TOTAL WALL-CLOCK TIME: ~25ms (vs ~500ms sequential without SVE)

Interaction Between Layers

6. Where It Is Used (Verification Call Sites)

SVE is integrated at 5 specific locations in the Sahyadri codebase where Dilithium3 signature verification occurs. Every location follows the same pattern but handles different transaction types.

Call Site Map

SAHYADRI CODEBASE - VERIFICATION LOCATIONS
═════════════════════════════════════════

consensus/src/
│
├── processes/transaction_validator/
│   └── tx_validation_in_isolation.rs
│       │
│       └── LINE 200-232  ◄───── SITE #1: Account Transaction Verification
│                           Handles CSM transfers between accounts
│                           Highest volume site (~80% of all verifications)
│
└── pipeline/virtual_processor/
    └── processor.rs
        │
        ├── LINE 742  ◄───── SITE #2: DID_CREATE Verification
        │                   New DID registration signatures
        │
        ├── LINE 810  ◄───── SITE #3: DID_UPDATE Verification  
        │                   Updating DID document attributes
        │
        ├── LINE 853  ◄───── SITE #4: DID_DEACTIVATE Verification
        │                   Permanent DID deactivation
        │
        └── LINE 907  ◄───── SITE #5: Account TX (Processor-level)
                            Secondary validation path

Verification Sites Detail Table

Code Pattern Used At Each Site

// This exact pattern appears at all 5 sites:

let is_valid = VERIFY_POOL.install(|| {
    DilithiumKeyPair::verify(&signature_bytes, &public_key_bytes)
});

if !is_valid {
    return Err(TransactionError::SignatureVerificationFailed);
}

// Variables differ per site:
// - Site 1: tx.sig, tx.pubkey (from UTXO input)
// - Site 2: did_create_tx.signature, did_create_tx.public_key  
// - Site 3: did_update_tx.signature, controller_pubkey
// - Site 4: did_deactivate_tx.signature, current_did.pubkey
// - Site 5: account_tx.signature, account_tx.pubkey

7. Implementation Details

Technology Stack

File Structure

sahyadri-final/sahyadri/
│
├── .cargo/
│   └── config.toml              ← AVX2 ENABLEMENT (rustflags)
│
├── Cargo.toml                   ← Workspace root (profile.release settings)
│
├── consensus/
│   ├── Cargo.toml               ← num_cpus dependency added
│   └── src/
│       ├── lib.rs / main.rs
│       │
│       ├── processes/transaction_validator/
│       │   └── tx_validation_in_isolation.rs
│       │       ├── Lines 10-19:  use rayon, LazyLock, VERIFY_POOL definition
│       │       └── Lines 220-232: verify_account_tx_signatures_batch()
│       │
│       └── pipeline/virtual_processor/
│           └── processor.rs
│               ├── Lines 58-62:  Imports + VERIFY_POOL definition
│               ├── Line 742:     DID_CREATE verification (SVE active)
│               ├── Line 810:     DID_UPDATE verification (SVE active)
│               ├── Line 853:     DID_DEACTIVATE verification (SVE active)
│               └── Line 907:     Account TX verification (SVE active)
│
└── crypto/dilithium/
    ├── Cargo.toml               ← dilithium-rs dependency
    └── src/lib.rs               ← sahyadri-dilithium wrapper

Build Configuration

# .cargo/config.toml (The magic file!)
[build]
rustflags = ["-C", "target-cpu=skylake"]

# What this does:
# 1. Tells LLVM to generate instructions for Skylake CPU
# 2. Skylake supports AVX2, AES-NI, CLMUL, other modern features
# 3. Compiler can freely emit VMOVDQU, VPADDQ, etc.
# 4. No runtime checks needed - binary assumes AVX2 present

# Alternative options:
# rustflags = ["-C", "target-cpu=native"]     ← Best for local machine
# rustflags = ["-C", "target-feature=+avx2"]  ← Only enable AVX2, nothing else

8. Performance and Benchmarks

Verified Metrics (From Actual Build)

Performance Scaling Table

Real-World TPS Estimate

THEORETICAL MAX (Crypto Limited):     ~21,600 signatures/sec
                                       ║
                                       ║ But real world has bottlenecks...
                                       ║
                                       ▼
┌─────────────────────────────────────────────────────────────────┐
│                  REAL-WORLD TPS ANALYSIS                        │
├─────────────────────┬──────────┬────────────────────────────────┤
│ Bottleneck          │ Latency  │ Max TPS Contribution           │
├─────────────────────┼──────────┼────────────────────────────────┤
│ Network P2P Prop    │ 50-200ms │ ~5,000-20,000 (but async)      │
│ DAG GhostDAG Sort   │ 10-50ms  │ ~20,000-100,000                │
│ Disk I/O RocksDB    │ 5-20ms   │ ~50,000-200,000                │
│ State UTXO Updates  │ 1-5ms    │ ~200,000-1,000,000             │
├─────────────────────┼──────────┼────────────────────────────────┤
│ CRYPTO (with SVE)   │ 0.046ms  │ ~21,600 ← NO LONGER LIMITING!  │
└─────────────────────┴──────────┴────────────────────────────────┘

CONSERVATIVE REAL-WORLD TPS: 1,000 - 5,000
OPTIMISTIC REAL-WORLD TPS:  5,000 - 10,000  
HARDWARE LIMIT (current):    ~10,000 - 15,000

Latency Breakdown Per Block

9. CPU Compatibility and Fallback

Compatibility Decision Tree

                    DOES YOUR CPU SUPPORT AVX2?
                              │
              ┌───────────────┴───────────────┐
              │                               │
             YES                              NO
              │                               │
              ▼                               ▼
    ┌─────────────────┐             ┌─────────────────┐
    │  BINARY RUNS    │             │  CRASH WITH     │
    │  SUCCESSFULLY   │             │  SIGILL ERROR   │
    │                 │             │  (Illegal       │
    │  Full SVE       │             │  Instruction)   │
    │  Performance    │             │                 │
    └────────┬────────┘             └────────┬────────┘
             │                              │
             ▼                              ▼
    Intel Haswell+ (2013+)         Intel pre-Haswell
    AMD Zen 1+ (2017+)            AMD Bulldozer/PileDriver
    Most modern servers           Some Atom/Celeron chips
    Apple Rosetta 2 (emulated)    Embedded/IoT devices
                                  
      COMPATIBLE                    NOT COMPATIBLE

Fallback Status

Recommended Deployment Targets

10. Security Considerations

Security Properties Matrix

What Optimization Does NOT Affect

CRYPTOGRAPHIC BOUNDARY OF OPTIMIZATION
══════════════════════════════════════

┌─────────────────────────────────────────────────────────────┐
│                      OPTIMIZATION ZONE                      │
│  (AVX2 + Rayon operate here - ONLY performance changes)     │
│                                                             │
│  • How fast polynomial multiply completes                   │
│  • How many signatures verified per second                  │
│  • Which CPU cores do the work                              │
│  • How data is arranged in registers                        │
└─────────────────────────────────────────────────────────────┘
                          ↑↓ NO CROSSING
┌─────────────────────────────────────────────────────────────┐
│                    CRYPTOGRAPHIC ZONE                       │
│  (Untouched by optimization - security properties fixed)    │
│                                                             │
│  • Which mathematical operations are performed              │
│  • What counts as valid vs invalid signature                │
│  • Security reduction to Module-LWE/SIS problems            │
│  • Resistance to forgery, replay, quantum attacks           │
└─────────────────────────────────────────────────────────────┘

11. Limitations

Current Limitations Detail

Scaling Limit Visualization

THREAD COUNT VS THROUGHPUT (Amdahl's Law Effect)
═════════════════════════════════════════════

Throughput (TPS)
    │
 25K│                                    ★ Ideal Linear
    │                                   ╱
 20K│                                  ╱
    │                                 ╱
 15K│                                ╱  ★ Actual (with SVE)
    │                               ╱
 10K│                              ╱
    │                             ╱
  5K│                            ╱
    │                           ╱
    │                          ╱
    │                         ╱
    │                        ╱
    │                       ╱
    │                      ╱
    │                     ╱
    │                    ╱
    │                   ╱
    │                  ╱
    │                 ╱
    │                ╱
    │               ╱
    │              ╱
    │             ╱
    │            ╱
    │           ╱
    │          ╱
    │         ╱
    │        ╱
    │       ╱
    │      ╱
    │     ╱
    │    ╱
    │   ╱
    │  ╱
    │ ╱
    │╱
    └────────────────────────────────────────
     1   2   3   4   5   6   7   8  16  32  64
                    CPU Core Count
    
    Note: Curve flattens due to:
    - Sequential portions (coordination, result collection)
    - Memory bandwidth saturation
    - Cache coherence overhead
    - OS scheduling overhead

12. Reproducibility

This section provides complete information needed to independently reproduce the benchmarks and build results presented in this document.

Environment Specification

Dependency Versions (Cargo.lock)

Sahyadri Account Model: CREST (Not UTXO)

Important: Sahyadri does NOT use traditional UTXO (Unspent Transaction Output) model like Bitcoin or Kaspa. Instead, Sahyadri implements CREST - Central Registry for Electronic Assets & Transactions.

CREST ACCOUNT MODEL ARCHITECTURE
═══════════════════════════════

┌─────────────────────────────────────────────────────────────┐
│                    CREST REGISTRY                           │
│     (Central State - Modified each block via processor)     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────┐  ┌─────────────────┐                   │
│  │ DID:did:sahy... │  │ DID:did:sahy... │                   │
│  │ Balance: 1000   │  │ Balance: 500    │                   │
│  │ PubKey: [1952B] │  │ PubKey: [1952B] │                   │
│  │ Status: ACTIVE  │  │ Status: ACTIVE  │                   │
│  └────────┬────────┘  └────────┬────────┘                   │
│           │                    │                            │
│           ▼                    ▼                            │
│  ┌──────────────────────────────────────────┐               │
│  │        CSM (CoinShareMineral) Ledger      │              │
│  │  Total Supply: ~21M cap (4-year halving)  │              │
│  └──────────────────────────────────────────┘               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

ACCOUNT TRANSACTION FLOW (Where SVE Site #1 Works):
                                                   
Sender (DID_A) ──TX[Sig_Dilithium3]──▶ Receiver (DID_B)
     │                                      │
     │          ┌───────────────────────────┘
     │          ▼
     │   ┌──────────────────┐
     │   │ SVE Verification │ ◄── AVX2 + Rayon Active Here!
     │   │ (Site #1)        │     verify_account_tx_signatures_batch()
     │   └────────┬─────────┘
     │            │ Valid?
     │            ▼
     │   ┌──────────────────┐
     │   │ CREST Update     │
     │   │ A.balance -= X   │
     │   │ B.balance += X   │
     │   └──────────────────┘
     │
     ▼
  Block Accepted to DAG

Why CREST Matters for SVE: In the CREST model, every account transaction requires Dilithium3 signature verification against the sender's DID public key stored in the registry. This is why Site #1 (tx_validation_in_isolation.rs) handles approximately 80% of all SVE verifications - it's the primary gateway for CSM transfers between DIDs.

Build Configuration Files

# File: .cargo/config.toml
[build]
rustflags = ["-C", "target-cpu=skylake"]

# File: Cargo.toml (workspace root) [profile.release]
opt-level = 3
lto = "thin"
codegen-units = 1
overflow-checks = false
strip = true

Exact Build Commands Executed

# Step 1: Remove old target-cpu from workspace (was causing warning)
sed -i '/target-cpu/d' ~/sahyadri-final/sahyadri/Cargo.toml

# Step 2: Create .cargo config for AVX2
mkdir -p ~/sahyadri-final/sahyadri/.cargo
cat > ~/sahyadri-final/sahyadri/.cargo/config.toml << 'EOF'
[build]
rustflags = ["-C", "target-cpu=skylake"]
EOF

# Step 3: Full clean build
cd ~/sahyadri-final/sahyadri
cargo clean
# Output: Removed 35935 files, 16.6GiB total

# Step 4: Release compilation
cargo build --release
# Output: Finished release profile in 8m 22s
# (Includes: proc-macro2, unicode-ident, quote, serde, sha2, 
#            sha3, dilithium-rs v0.2.0, sahyadri-wallet, etc.)

# Step 5: AVX2 instruction count verification
objdump -d target/release/sahyadri-cli | grep -cE "vmovdqu|vpaddq|vpxor|vpmuldq|vpunpck"
# Output: 25968

# Step 6: Dilithium test suite execution
RUSTFLAGS="-C target-cpu=skylake" cargo test --manifest-path crypto/dilithium/Cargo.toml -- --nocapture
# Output: 
#   running 9 tests
#   test tests::test_did_message_formats ... ok
#   test tests::test_auto_detect_sig ... ok
#   test tests::test_generate_and_sizes ... ok
#   test tests::test_keypair_serialize_roundtrip ... ok
#   test tests::test_seed_deterministic ... ok
#   test tests::test_sign_verify_roundtrip ... ok
#   test tests::test_wrong_message_fails ... ok
#   test tests::test_wrong_pubkey_fails ... ok
#   test tests::test_hex_roundtrip ... ok
#   test result: ok. 9 passed; 0 failed; 0 ignored; 0 measured

Expected Variance

Summary

Sahyadri Vector Engine represents a significant optimization investment in the Sahyadri L1 blockchain's transaction processing pipeline. By combining AVX2's 256-bit SIMD vectorization with Rayon's multi-core parallelism, the system achieves approximately 10.8x speedup in Dilithium3 signature verification, reducing the cryptographic bottleneck from ~500ms to ~46ms per 1000-transaction block. The compiled binary contains 25,968 AVX2 instructions covering polynomial arithmetic operations essential to lattice-based cryptography.

While the current implementation requires AVX2-compatible hardware (Intel Haswell/AMD Zen 1 or newer) and uses dilithium-rs v0.2.0 (upgrade to v0.3.0 recommended for production), the architecture successfully transforms signature verification from a potential limiting factor into a highly efficient component with capacity exceeding real-world network and disk bottlenecks. Future work includes runtime CPU detection for broader compatibility, small-batch optimization, and potential integration of AVX-512 instructions for newer hardware generations.

Verifiable Credentials (VC)

Cryptographically Verifiable Claims for Web5, Identity, Reputation, and Trust.

Cryptographically Verifiable Claims for Web5, Identity, Reputation, and Trust.

Verifiable Credentials (VCs) are digitally signed credentials that allow individuals, organizations, applications, and institutions to prove facts without relying on centralized databases.

Within the Sahyadri ecosystem, Verifiable Credentials serve as the foundation for trustless identity, decentralized reputation, human verification, access control, compliance systems, and future Web5 applications.

Unlike traditional certificates stored inside centralized servers, Verifiable Credentials are owned directly by the user and can be verified anywhere using cryptographic proofs.

What is a Verifiable Credential?

A Verifiable Credential is a digitally signed statement issued to a DID.

The credential may contain claims such as:

• Human Verification
• Age Verification
• Nationality Verification
• Educational Certificates
• Membership Credentials
• Employment Records
• Business Certifications
• Financial Reputation
• Access Permissions
• Digital Ownership Records

Every credential is cryptographically signed and can be independently verified without contacting the issuer.

Relationship Between DID and VC

The DID identifies the holder.

The VC proves facts about that holder.

Human Verification Credentials

Sahyadri introduces Human Verification Credentials, commonly referred to as Human Badges.

A Human Badge confirms that a decentralized identity belongs to a real unique human being.

Applications can verify humanity without accessing personal information.

Privacy Preservation

Traditional identity systems require users to expose documents, personal information, and sensitive records.

Sahyadri VCs allow selective disclosure.

Applications only receive proof that a claim is true.

Applications do not need access to the underlying data.

Credential Structure

Every Verifiable Credential follows a standardized structure.

{
  "id": "vc:sahyadri:001",
  "issuer": "did:sahyadri:issuer",
  "holder": "did:sahyadri:user",
  "type": "HumanBadge",
  "issued": "2026-01-01",
  "signature": "..."
}

Credentials can be verified independently by any verifier.

Credential Lifecycle

Revocation System

Credentials may occasionally become invalid.

Sahyadri supports decentralized credential revocation mechanisms.

• Expired Credentials
• Compromised Credentials
• Withdrawn Certifications
• Membership Revocation
• Compliance Violations

Revocation status can be verified directly through the Sahyadri network.

Future Web5 Applications

Verifiable Credentials form the foundation for future Web5 infrastructure.

• Decentralized Login
• Human Verification
• Reputation Systems
• DAO Governance
• Digital Passports
• Financial Reputation
• Education Records
• Professional Certifications
• Healthcare Credentials
• Enterprise Identity Systems

Sahyadri Vision

The long-term goal is to create a universal trust layer where identities can carry verifiable proofs across applications, organizations, governments, financial systems, and digital ecosystems without sacrificing privacy.

Users should own both their identity and their credentials.

No platform should control either.

Summary

Verifiable Credentials are cryptographically signed claims linked to a DID. They enable trustless verification, privacy-preserving authentication, decentralized reputation, and future Web5 identity systems.

DID answers: Who are you?

VC answers: What can you prove?

Together they form the identity layer of the Sahyadri ecosystem.

Sahyadri Wallet

Post-Quantum Secure • Self-Custodial • Identity Ready • Web5 Native

Sahyadri Wallet is the primary gateway to the Sahyadri ecosystem. It enables users to manage CSM, create decentralized identities (DIDs), store Verifiable Credentials (VCs), interact with decentralized applications, and securely control their assets using post-quantum cryptography.

Unlike traditional wallets that focus only on asset management, Sahyadri Wallet is designed to become a complete identity, payments, and Web5 access layer.

Download Wallet

API Reference

Complete REST & RPC API documentation for Sahyadri blockchain integration.

GET /api/v1/accounts/{address}/balance
POST /api/v1/transactions
GET /api/v1/did/{did}

Tokenomics

Fixed Supply • Proof-of-Work Distribution • Scarcity by Design

Sahyadri Coin (CSM) is the native asset of the Sahyadri blockchain. The monetary system is designed around predictable issuance, long-term scarcity, decentralized distribution, and sustainable network security.

Unlike fiat currencies, where supply can be expanded indefinitely, Sahyadri follows a mathematically enforced fixed-supply model. No central authority, administrator, validator, foundation, company, or government can create additional coins beyond the protocol limit.

Economic Philosophy

The Sahyadri monetary model follows three fundamental principles:

• Predictable issuance
• Fixed maximum supply
• Decentralized distribution through mining

Every coin enters circulation through Proof-of-Work mining. No hidden minting, no inflation controls controlled by humans, and no centralized issuance authority exist within the protocol.

Supply Overview

Distribution Model

CSM is distributed exclusively through mining rewards.

No pre-mine, no hidden minting process, and no centralized issuance mechanism exists. Every coin is generated through network participation and computational work.

Current Emission Rate

At the current issuance rate:

Current Reward
= 0.08318123 CSM

Block Time
= 1 Second

Blocks Per Day
= 86,400

Daily issuance:

0.08318123 × 86,400

= 7,186.858272 CSM / Day

Annual issuance:

7,186.858272 × 365.25

= 2,624,999.885 CSM / Year

4-year issuance:

2,624,999.885 × 4

= 10,499,999.54 CSM

Halving Mechanism

Sahyadri uses a Bitcoin-inspired halving model.

Rather than allowing perpetual inflation, issuance is periodically reduced to preserve scarcity and strengthen long-term economics.

Halvings occur every four years and are governed through the SahyadriScore system.

Under current assumptions:

Blocks Per Day
= 86,400

Blocks Per Year
= 31,557,600

Blocks Per 4 Years
= 126,230,400

Upon halving, the mining reward is reduced by 50%.

Reward Schedule

Scarcity Model

The maximum supply of 21 million CSM creates a naturally scarce digital asset.

As mining rewards decrease through successive halvings, new issuance becomes increasingly limited.

This mechanism encourages long-term network sustainability while preserving purchasing power and scarcity.

Miner Incentives

Miners secure the network and receive rewards for contributing computational work.

During the early years of the network, security is primarily funded through block rewards.

As issuance decreases, transaction fees gradually become a larger component of miner revenue.

Long-Term Sustainability

Once the maximum supply is reached, no additional CSM will ever be created.

Network security will continue to operate through transaction fees and economic activity generated by users, applications, decentralized identities, credentials, and Web5 infrastructure.

This transition mirrors the long-term economic vision established by Bitcoin while benefiting from Sahyadri's high-throughput BlockDAG architecture.

Summary

Sahyadri Coin (CSM) follows a fixed-supply monetary policy capped at 21,000,000 coins. Distribution occurs exclusively through Proof-of-Work mining, while periodic halvings reduce inflation and strengthen scarcity over time.

The result is a predictable, transparent, decentralized, and mathematically enforced economic system designed for long-term sustainability.

Genesis Block

The Origin of the Sahyadri Blockchain

The Genesis Block is the very first block of the Sahyadri blockchain. Every transaction, every block, every decentralized identity, every credential, and every future application built on Sahyadri ultimately traces its history back to this single block.

Unlike normal blocks, which reference one or more parent blocks, the Genesis Block has no parent. It exists as the starting point of the network and serves as the root of the entire blockchain history.

The Genesis Block is permanently embedded into the protocol and is included in every full node implementation. Every node joining the network begins synchronization from the Genesis Block and independently verifies all subsequent activity from that point forward.

Why Genesis Exists

A decentralized network requires a common starting point that every participant can trust and verify independently.

The Genesis Block establishes this foundation by defining the initial state of the blockchain before any transactions, mining rewards, identities, or applications exist.

• Creates the initial chain state
• Establishes network rules
• Activates consensus
• Provides a universal verification root
• Anchors future blockchain history
• Defines protocol initialization parameters

Role in Sahyadri

Within the Sahyadri ecosystem, the Genesis Block acts as the cryptographic foundation for the entire network.

Every Proof-of-Work calculation, BlockDAG relationship, Dilithium3 signature, Plonky3 proof, DID document, and Verifiable Credential can ultimately be traced back through the chain to the Genesis Block.

Immutability

Once the Genesis Block becomes part of the network, it is immutable.

Changing the Genesis Block would create an entirely different blockchain because every block, transaction hash, and network state depends on the chain's origin.

For this reason, the Genesis Block is often considered the digital birthplace of a blockchain.

Genesis Philosophy

The Genesis Block represents more than a technical starting point.

It symbolizes the beginning of a new economic and digital system where ownership, identity, verification, and trust are controlled by users rather than centralized platforms.

Everything built on Sahyadri begins here.

Audit

Audit Status:
Independent security audits are currently in progress. Audit reports and recommendations will be published publicly after completion.