SHA 3 in QVM

Role of SHA 3

SHA 3 is the canonical hashing primitive used throughout QVM for

• State root calculation
• Contract bytecode hashing
• Message authentication
• DAO proposal integrity
• Multisig threshold verification
• Deterministic execution proofs

Why SHA 3

• No structural similarity to SHA 2
• Resistant to length extension attacks
• Strong preimage and collision resistance under quantum threat models

Developer Usage

SHA 3 is accessible through native QVM instructions, not user defined implementations.

hash = qvm_hash_sha3(input_bytes)
      

Used in

• Contract storage keys
• Governance proposal IDs
• DAO voting snapshots
• Order matching in DEXs

Dilithium Signatures in QVM

Purpose

CRYSTALS Dilithium is the primary authorization signature scheme in QVM.

Used for

• Account authentication
• Smart contract execution approval
• DAO voting authority
• Treasury access
• Validator and governance actions

Security Properties

• Lattice based
• Resistant to Shor’s algorithm
• Deterministic verification
• Strong unforgeability

Execution Model

Caller → Provides Dilithium Signature
        │
        ▼
┌─────────────────────────┐
│ Dilithium Verify (QVM)  │
└──────────┬──────────────┘
           │
   ┌───────▼─────────┐
   │ Valid Signature │───► Continue Execution
   └───────┬─────────┘
           │
   ┌───────▼─────────┐
   │ Invalid Signature│──► Abort + Revert
   └─────────────────┘
      

Smart Contract Implication

Contracts do not trust external callers they rely on QVM to verify authorization cryptographically.

Falcon Signatures in QVM

Purpose

Falcon is used where compact signatures and performance efficiency are required.

Typical use cases

• Highfrequency DEX interactions
• Wallet transaction batching
• Layered multisig authorization
• Embedded device signing IoT / enterprise systems

Why Falcon

• Smaller signature sizes than Dilithium
• Faster verification
• Still quantum resistant

Dual Scheme Support

QVM allows protocol defined selection of signature schemes per execution context.

verify_signature(
  scheme = FALCON,
  pubkey,
  message,
  signature
)
      

This enables

• Hybrid authorization models
• Tiered security roles
• Cost optimized contract execution

Multisig & Organizational Security Models

QVM supports native multisig logic without external contracts relying on EOA patterns.

Example DAO Treasury Multisig

┌───────────────┐
│ Proposal Hash │
└───────┬───────┘
        │
┌───────▼────────────────────┐
│ Collect Signatures (PQ)     │
│   Dilithium (core signers)  │
│   Falcon (operational)      │
└───────┬────────────────────┘
        │
┌───────▼───────────┐
│ Threshold Met?    │
└───────┬───────────┘
        │
   Yes  ▼       No
┌────────────┐   ┌────────────┐
│ Execute     │   │ Abort      │
│ Treasury Tx │   │ Execution  │
└────────────┘   └────────────┘
      

Benefits

• No EOA private key risk
• No off chain coordination required
• Deterministic enforcement
• Cryptographically auditable governance

Wallet Integration QMask

QMask interacts with QVM using post quantum keypairs only.

Wallet responsibilities

• Generate Dilithium / Falcon keys
• Sign transaction payloads
• Submit PQR compatible transactions

QVM responsibilities

• Verify signatures
• Enforce authorization
• Reject invalid cryptography

Wallets never bypass VM verification.

DEX Execution QSwap

DEX logic in QVM uses

• SHA 3 for order hashing
• Falcon for frequent trade authorization
• Dilithium for administrative and governance actions

Order Submission
      │
      ▼
Hash Order (SHA 3)
      │
Verify Signature (Falcon)
      │
Match & Settle (QVM)
      

This eliminates

• MEV style signature spoofing
• Replay attacks
• ECC based exploit surfaces

DAO & Governance Logic

Governance logic executes under the same cryptographic assurance

• Proposal integrity via SHA 3
• Voting authority via Dilithium
• Execution authorization via threshold logic

Once approved, governance actions are executed directly by QVM, not by trusted operators.

Developer assurance

When building on QVM, developers can assume

• All cryptographic verification is enforced at protocol level
• No elliptic curve cryptography is present
• Deterministic execution across validators
• Long term cryptographic durability

This allows applications to be designed for multi decade security horizons without future migration risk.

Summary

QVM embeds SHA 3, Dilithium, and Falcon directly into its execution protocol, making cryptographic security

• Mandatory
• Deterministic
• Verifiable
• Quantum resistant

This architecture enables secure smart contracts, DAOs, DEXs, wallets, and enterprise workflows without relying on fragile cryptographic assumptions.

Security Threat Model & Formal Assumptions

QVM is designed under a conservative adversarial model that assumes attackers may possess advanced computational capabilities, including access to large scale quantum resources. The security model prioritizes cryptographic durability, deterministic execution, and protocol level enforcement over reliance on operational trust.

Threat Model Assumptions

QVM explicitly assumes

• Adversaries can observe all on chain data, including public keys, signatures, and contract bytecode.
• Adversaries may attempt to
• Forge transaction or contract execution authorization
• Replay previously valid messages
• Manipulate execution ordering
• Exploit cryptographic weaknesses over long time horizons
• Classical elliptic curve cryptography is considered insufficient under long term threat assumptions.

Cryptographic Assumptions

Security relies on the following formal assumptions

• Lattice based hardness assumptions underlying Dilithium and Falcon remain computationally infeasible for both classical and quantum adversaries.
• SHA 3 collision and preimage resistance remains intact under quantum attack models Grover style bounds considered.
• Private key material is never exposed by the protocol or VM execution environment.

No security Reassurance’s are derived from secrecy of algorithms or off chain enforcement.

Execution Assumptions

• QVM execution is deterministic and validated by a supermajority of validators.
• Invalid cryptographic proofs result in immediate execution failure and state rejection.
• No privileged execution paths exist for governance, contracts, or administrative actions.

Out of Scope Threats

QVM does not attempt to mitigate

• Endpoint compromise of user devices or wallets
• Social engineering or key mismanagement by users
• Physical compromise of signing hardware
• Validator collusion beyond consensus fault assumptions

These risks must be addressed at the operational and organizational layers.

Security Posture Summary

QVM’s security model is intentionally conservative all authorization, execution, and governance actions must remain secure even under future quantum capable adversaries, without requiring protocol migration or cryptographic replacement.