Dorsium Whitepaper

A Mission-Driven Blockchain Project with Decentralized Mining and Real Utility

Version: 2.20

Date: November 3, 2025

Dorsium is a community-centric blockchain ecosystem that democratizes cryptocurrency mining through mobile accessibility while maintaining enterprise-grade security and transparency. Built on Cosmos SDK with a revolutionary Hierarchical Delegated Consensus (HDC) mechanism, Dorsium transforms mobile devices into lightweight validators that perform cryptographic signature verification and transaction validation, rewarding users with DORS utility tokens for their network contribution rather than speculative returns.

Our platform utilizes a deterministic pre-mainnet reward calculation system for transparent token distribution, providing complete transparency and auditability through our public explorer. Post-mainnet, these will be replaced by on-chain smart contracts for full decentralization. With a total supply of 40 billion DORS tokens allocated through network validation work, Dorsium represents a sustainable alternative to energy-intensive proof-of-work systems and capital-intensive proof-of-stake networks.

1. Vision & Mission
2. Problem Statement
3. Solution Overview
4. Architecture
5. Pre-Mainnet Trust Model
6. Tokenomics
7. Security Framework
8. Governance Model
9. Economic Model
10. Banking Infrastructure
11. Roadmap
12. Legal & Compliance
13. Project History
14. Risk Factors Summary
15. Conclusion
16. Appendices
17. Version History

Vision

To create a decentralized blockchain infrastructure where network participation is accessible through contribution rather than capital requirements.

Mission

Dorsium develops accessible blockchain validation technology that enables broad participation in decentralized networks. Our objectives:

• Accessibility: Enable network validation through mobile devices without specialized hardware requirements
• Transparency: Provide auditable reward calculations with deterministic smart contracts
• Fairness: Distribute tokens based on validation work, independent of capital holdings
• Sustainability: Implement energy-efficient consensus mechanisms without compromising security
• Utility: Connect network participation with practical token use cases in decentralized applications

Design Principles

• Contribution-based participation over capital-based entry barriers
• Technical innovation focused on practical deployment
• Community governance transitioning from foundation to DAO structure
• Regulatory compliance within EU MiCA framework
• Long-term ecosystem development over speculative incentives

The current blockchain landscape presents several barriers to entry:

1. Mining Inaccessibility

• Bitcoin: Requires specialized ASIC hardware costing thousands of dollars
• Ethereum: Transitioned to proof-of-stake, requiring 32 ETH (~$80,000+) to validate
• Energy Consumption: Traditional mining consumes more electricity than entire countries

2. Wealth Concentration

• Early participants receive reward rates (pre-halving) for network
• Proof-of-stake systems favor the wealthy
• New participants have limited earning opportunities

3. Technical Complexity

• Running nodes requires technical expertise
• Complex wallet management
• High risk of user error and fund loss

4. Lack of Real Utility

• Many tokens are purely speculative
• Limited real-world applications
• Disconnect between network utility demand and ecosystem utility

Dorsium addresses these challenges through innovative technical and economic design:

Mobile-First Mining

• Mine directly from iOS/Android devices
• No specialized hardware required
• Energy-efficient validation process
• 24-hour mining sessions with activity verification

Hierarchical Delegated Consensus (HDC), Simple Explanation

HDC is Dorsium's innovative consensus mechanism that uses three layers of validation instead of one. Think of it like a triple-lock security system where each layer independently verifies transactions, making attacks practically impossible without controlling all three layers simultaneously.

Hierarchical Delegated Consensus (HDC), Attack Resistance Analysis

Multi-Tier Security Model

Dorsium's HDC implements defense-in-depth through three independently secured tiers:

Tier 1: Mobile Miners (Sybil-Resistant Layer)

• Function: Initial transaction validation and activity verification
• Consensus Requirement: 2/3 majority of assigned miners
• Threat: Mass fake account creation
• Defense Mechanisms:
  • Mandatory KYC for wallet access and mining participation
  • Device fingerprinting and attestation
  • Activity verification challenges (2-3 daily random checks)
  • Geographic distribution monitoring
  • Behavioral pattern analysis
• Attack Cost: Creating 1,000+ fake identities with valid KYC = Practically impossible at scale
• Economic Barrier: Even if achieved, mobile miners have no direct block proposal rights
• Result: Sybil attacks are economically irrational given KYC requirements and low individual influence

Tier 2: Nodes (Identity-Verified Layer)

• Function: Light validation, transaction relay, and block assembly
• Consensus Requirement: 2/3 majority of active nodes
• Threat: Purchasing 34%+ of node capacity
• Defense Mechanisms:
  • Video KYC verification with Dorsium staff
  • Full identity verification (email, banking details required for purchase)
  • Manual approval process for each purchase
  • Hardware serial number tracking
  • Bank transfer payment trail
• Attack Cost: 34% of 100 nodes = 34 × €635 = €21,590 + KYC bypass cost (calculated at the price of the very first public campaign price)
• Economic Barrier: Video verification and manual approval process makes mass purchase detection immediate
• Result: Coordinated node acquisition is detectably impossible without multiple verified identities

Tier 3: Validators (Maximum Security Layer)

• Function: Full consensus participation and blockchain finalization
• Consensus Requirement: 2/3 majority (BFT threshold)
• Threat: Controlling 34%+ of validator set
• Defense Mechanisms:
  • Same KYC requirements as Nodes
  • Higher hardware cost barrier (€950 per unit, as of November 2025)
  • Geographic distribution requirements (post-mainnet)
  • Reputation-based selection mechanism (post-mainnet)
  • Slashing for Byzantine behavior
• Attack Cost: 34% of 100 validators = 34 × €950 = €32,300 + KYC bypass cost
• Economic Barrier: Video KYC + manual approval + higher cost creates maximum deterrent
• Result: Validator set manipulation requires sophisticated identity fraud at scale

Cumulative Attack Cost Analysis

To compromise the network, an attacker must control 34%+ of ALL THREE tiers simultaneously:

Minimum Attack Budget:

• Mobile tier bypass: Effectively impossible (KYC requirement blocks mass account creation)
• Node tier: €21,590 (hardware) + KYC identity fabrication cost
• Validator tier: €32,300 (hardware) + KYC identity fabrication cost
• Total Hardware Cost: €53,890 minimum
• Total Real Cost: €53,890+ hardware + Unquantifiable KYC bypass cost (identity fraud at scale)

Critical Defense: The KYC video verification process makes it economically and practically infeasible to acquire sufficient hardware across all tiers without detection. Each hardware purchase requires:

1. Live video call with Dorsium staff
2. Valid government-issued identification
3. Bank transfer from verified account
4. Unique shipping address per unit

Comparative Security: This attack cost is comparable to networks with significantly higher market caps, demonstrating HDC's cost-effective security model.

Additional Safeguards:

• Real-time monitoring of consensus participation patterns
• Automated alerts for coordinated validator behavior
• Emergency governance intervention mechanisms
• Progressive slashing for Byzantine behavior
• Node Sentinel emergency backup system

Network Partition Resistance

Partition Prevention:

• Redundant tunnel infrastructure across multiple cloud regions
• Automatic failover to backup VPS instances
• Heartbeat monitoring with 5-second intervals
• Geographic diversity requirements for validators (post-mainnet)

Detection Mechanisms:

• Validator disconnection alert: 2 missed heartbeats
• Automatic rerouting through backup tunnels
• Consensus timeout: 30 seconds maximum
• Emergency validator substitution from Node Sentinels (AI-powered backup validators)

Mathematical Guarantee:

• Block time: 5 seconds
• Partition detection: 2 missed heartbeats
• Recovery time: <10 seconds (1-2 blocks maximum)
• Maximum inconsistency window: 15 seconds

Result: Network partitions are detected and resolved faster than a single block time, preventing any chain fork possibility. HDC's instant finality (BFT) means partitions cannot produce conflicting states - any partition is detected and resolved before the next block is finalized.

Partition Recovery Protocol:

1. Detection: Missed heartbeat triggers alert
2. Automatic failover: Traffic rerouted to backup VPS
3. State verification: Archive nodes confirm latest valid state
4. Consensus resumption: 2/3 majority re-established
5. Total recovery time: <15 seconds (3 blocks maximum)

Guarantee: HDC's instant finality (BFT) means partitions cannot produce conflicting states. Any partition is detected and resolved before the next block.

Consensus Flow

1. Transaction Creation: User initiates transaction through mobile app or wallet
2. Miner Validation (Tier 1): Mobile miners validate signatures and format (2/3 consensus required)
3. Node Processing (Tier 2): Nodes perform light validation, check balances, assemble into blocks (2/3 consensus required)
4. Validator Consensus (Tier 3): Full validators perform complete validation and finalize block (2/3 consensus required)
5. Finalization: Block written to chain with instant finality (no reorganization possible)

Total Consensus Time: ~5 seconds (single block time)

Transaction Validation Flow

User submits transaction
↓
┌────────────────────────────────────────┐
│  TIER 1: Mobile Miners (9-15 assigned) │
│  - Verify Ed25519/Secp256k1 signature  │
│  - Check transaction format            │
│  - Query light client for balance      │
│  - Vote: Valid or Invalid              │
│  - Requirement: 2/3 consensus (6+)     │
└─────────────┬──────────────────────────┘
↓ (if 2/3 agree Valid)
┌────────────────────────────────────────┐
│  TIER 2: Nodes (3-5 assigned)          │
│  - Advanced validation                 │
│  - Check nonce, gas, smart contracts   │
│  - Assemble into block                 │
│  - Requirement: 2/3 consensus          │
└─────────────┬──────────────────────────┘
↓ (if 2/3 agree Valid)
┌────────────────────────────────────────┐
│  TIER 3: Validators (All participate)  │
│  - Full transaction validation         │
│  - Block validation & finalization     │
│  - Write to blockchain                 │
│  - Requirement: 2/3 consensus (67+)    │
└────────────────────────────────────────┘
↓
Transaction finalized on-chain

Result: Invalid transactions filtered at Tier 1, reducing node computational load by ~40%.

Why HDC Is Cost-Effective

Traditional blockchains require massive hardware investments to achieve security:

• Bitcoin: Billions in ASIC hardware + electricity costs
• Ethereum: 32 ETH stake (~$80,000+) per validator

Dorsium achieves comparable attack resistance through:

• Identity verification instead of capital requirements
• Multi-tier consensus instead of single-point security
• KYC barriers instead of pure economic barriers
• Total Attack Cost: €53,890+ (competitive with much larger networks)

This makes Dorsium's security model sustainable and accessible while maintaining institutional-grade attack resistance.

Transparent Reward System

Pre-Mainnet (Current):

• Automated reward calculation system (backend scripts)
• Deterministic formulas ensure transparency
• SHA-256 hash verification for every transaction
• Complete auditability via public explorer
• Centralized database managed by Dorsium OÜ (bootstrap phase)

Post-Mainnet (2026+):

• On-chain smart contracts for all operations
• Decentralized execution via validator consensus
• Immutable transaction history
• Community-governed protocol upgrades

For detailed trust model and migration plan, see Pre-Mainnet Trust Model.

Fair Distribution Model

• Community-first distribution
• Activity-based rewards primarily
• Limited sales through Dorsium OÜ (future consideration)
• Multi-tiered referral system (2x cap prevents pyramid schemes)
• Transparent vesting schedules

System Overview

Dorsium implements a revolutionary three-tier network architecture that balances accessibility, security, and scalability:

┌─────────────────────────────────────────┐
│         Mobile Miners (Unlimited)        │
│   Android/iOS App - Activity Mining      │
└─────────────┬───────────────────────────┘
              │ Encrypted Tunnel
              ▼
┌─────────────────────────────────────────┐
│           Nodes (Unlimited)              │
│   Light Validators - Block Assembly      │
└─────────────┬───────────────────────────┘
              │ Encrypted Tunnel
              ▼
┌─────────────────────────────────────────┐
│       Validators (100-300)               │
│   Full Consensus - Blockchain Storage    │
└─────────────┬───────────────────────────┘
              │
              ▼
┌─────────────────────────────────────────┐
│      Archive Nodes (10-50)               │
│   Complete Historical Data Storage       │
└─────────────────────────────────────────┘

Hardware Requirements

Archive Nodes

Archive nodes maintain the complete blockchain history:

• CPU: Minimum 8 cores, 3.0 GHz
• RAM: Minimum 32GB DDR4
• Storage: 2TB NVMe SSD (expandable)
• Network: 1 Gbps connection
• OS: Ubuntu 22.04 LTS Server
• Note: Hardware specifications determined by Dorsium project administrator

Network Infrastructure

Tunnel System Architecture

Dorsium implements a VPS-based tunnel infrastructure to simplify network participation:

Purpose:

• Eliminates fixed IP requirements for Node/Validator owners
• Provides routing for peer-to-peer communication
• Reduces technical barriers to network participation

Technical Implementation:

Connection Routing:

• Mobile Miners → VPS Tunnel → Nodes
• Nodes → VPS Tunnel → Validators
• Validators → Direct P2P mesh (optional VPS fallback)

VPS Infrastructure:

• Capacity: 100-150 active connections per VPS instance (mixed mobile/node traffic)
• Hardware: AWS t3.large equivalent (2 vCPU, 8GB RAM, 1 Gbps network)
• Geographic Distribution:
  • Primary: EU-Central-1 (Frankfurt, Germany)
  • Backup: EU-West-1 (Ireland), EU-North-1 (Stockholm)
• Latency Optimization: Regional routing based on participant geographic location

Connection Details:

• Port Allocation: Dynamic ranges (30000-40000 for mobile miners, 40000-50000 for nodes)
• Encryption: WireGuard protocol with TLS 1.3 fallback
• Authentication: Certificate-based (public key infrastructure)
• Session Management: Automatic reconnection on disconnect

Scaling Strategy:

• Manual Provisioning (Pre-Mainnet): Dorsium team deploys new VPS instances as needed
• Monitoring: Real-time connection count tracking, alert at 80% capacity
• Capacity Planning: New VPS provisioned when 100+ connections sustained for 24 hours
• Post-Mainnet: Community-run VPS nodes with incentive structure (future consideration)

Cost Structure:

• Current: Project-funded VPS instances (~$60-120/month per instance)
• Estimated Need: 1 VPS per 100 active participants
• At 1,000 miners: 10 VPS instances required (~$600-1,200/month)
• At 10,000 miners: 100 VPS instances required (~$6,000-12,000/month)

Fallback Mechanisms:

• VPS Failure: Automatic rerouting to backup region (EU-West-1)
• Full Outage: Participants can configure direct P2P connections (advanced users only)
• Recovery Time: <5 minutes (automatic health checks every 30 seconds)

Limitations:

• Pre-Mainnet: VPS management (Dorsium team controls)
• Scalability: Manual intervention required for capacity expansion
• Single Point of Failure: VPS provider downtime affects all routed connections
• Post-Mainnet: Transition to decentralized tunnel operators via incentive model

Why This Approach:

• Simplifies onboarding (no port forwarding, no fixed IP)
• Reduces technical support load
• Enables mobile mining without complex networking
• Provides geographic redundancy
• Temporary centralization (acceptable for bootstrap phase)

Critical Clarification: VPS Does NOT Centralize the Blockchain

The VPS tunnel infrastructure is ONLY a networking convenience layer:

What VPS Tunnels DO:

• Route encrypted connections between participants
• Eliminate need for fixed IPs or port forwarding
• Provide connection redundancy
• Simplify network participation for non-technical users

What VPS Tunnels DO NOT DO:

• Process or validate transactions
• Participate in consensus
• Store blockchain data
• Control node/validator operations

Key Point: The blockchain remains fully decentralized. Nodes and validators run independently on user hardware. If all VPS servers failed simultaneously, the network would continue operating through direct P2P connections between participants who configure their own networking.

Analogy: VPS tunnels are like postal forwarding services - they help deliver messages but don't control what's in them or who sends them.

Partition Prevention Guarantees

For detailed partition resistance analysis including infrastructure redundancy, detection mechanisms, and mathematical guarantees, see the Network Partition Resistance section in Solution Overview.

Quick Reference:

• Primary VPS: EU-Central-1 (Frankfurt)
• Backup regions: EU-West-1, EU-North-1
• Detection time: 6 seconds (2 missed heartbeats)
• Recovery time: <15 seconds

Result: Network partitions are detected and resolved faster than a single block time, preventing any chain fork possibility.

Network Participants

Mobile Miners - Transaction Validation Layer

Mobile miners form the first line of defense in Dorsium's HDC consensus, performing lightweight but cryptographically significant validation work.

Core Functions

1. Transaction Collection & Validation

• Signature Verification: Verify Ed25519/Secp256k1 signatures for incoming transactions
• Format Validation: Check transaction structure against protocol specifications
• Balance Verification: Query light client state for sufficient sender balance
• Relay to Nodes: Forward validated transactions to assigned nodes via encrypted tunnel
• Computational Cost: ~0.1% battery drain per hour (equivalent to background music streaming)

2. Light Client Synchronization Mobile miners maintain a lightweight blockchain state:

• Block Headers Only: Download and verify block headers (not full blocks)
• Merkle Proof Verification: Verify transaction inclusion without full block data
• State Sync: Periodic synchronization with full nodes (every 100 blocks)
• Storage Requirement: ~50MB for 1 year of headers
• Bandwidth: ~5MB/day average

3. Peer-to-Peer Network Participation

• Connection Maintenance: Maintain active connections to 3-5 nodes
• Gossip Protocol: Propagate valid transactions across the network
• Transaction Pool: Hold pending transactions until node pickup
• Network Resilience: Redundant paths for transaction propagation

4. Proof-of-Activity (Anti-Sybil)

• Random Challenges: 2-3 verification requests per 24-hour cycle
• Response Window: 30 seconds to complete device attestation
• GPS Verification: Confirm geographic distribution (optional, privacy-preserving)
• Device Integrity: Hardware-based attestation to prevent emulation
• Purpose: Prevent automated bot farms, not primary validation work

Hardware Requirements

• CPU: Any modern smartphone (2015+ models)
• RAM: Minimum 2GB (1GB reserved for mining process)
• Storage: 100MB for app + light client data
• Battery Impact: <2% per hour with screen off
• Network: WiFi or mobile data (4G/5G), ~10MB/day usage

Security Contribution

Transaction Validation Capacity:

• Each mobile validates 50-100 transactions/day
• 10,000 active mobiles = 500,000-1,000,000 validations/day
• Invalid transactions rejected before reaching nodes (reducing node load)

Network Security Benefits:

1. Distributed Validation: Thousands of independent verification points
2. Sybil Resistance: KYC + PoA makes fake mobile miners economically irrational
3. Geographic Distribution: Global mobile participation prevents regional attacks
4. Early Fraud Detection: Invalid transactions caught at first consensus layer
5. Network Redundancy: Multiple transaction propagation paths

Attack Resistance:

• To inject invalid transactions: Must control 34%+ of mobile validators
• With 10,000 mobiles + KYC: Requires 3,400+ fake identities (impossible at scale)
• Cost: ~€0 hardware but infinite KYC bypass cost
• Detection: Real-time behavioral analysis flags coordinated attacks

KYC & Activation Requirements

Two-Step Activation Process:

Mining participation requires identity verification to prevent Sybil attacks and ensure regulatory compliance.

Step 1: Registration & Mining Activation

• User creates account with verified email address
• Basic KYC Required:
  • Full name (as appears on government ID)
  • Date of birth
  • Country of residence
  • Government-issued ID upload (passport or national ID)
  • Selfie verification with ID document
  • Automated identity verification via EU-compliant KYC provider
• Upon KYC Completion: Mining sessions can begin immediately
• Status: ACTIVE MINER (earning DORS tokens)

Step 2: Wallet Creation & Token Withdrawal

• Knowledge Test Required (before first token withdrawal):
  • 20-question assessment covering Dorsium project fundamentals and general cryptocurrency concepts
  • 70% passing score (14/20 correct answers)
  • Free learning materials provided (documentation, video tutorials)
  • 24-hour cooldown between attempts if failed
• Upon Test Completion: Non-custodial wallet creation enabled, token withdrawal unlocked
• Status: VERIFIED MINER (full access)

Node & Validator Additional Requirements:

• All Basic KYC + Knowledge Test (same as miners)
• Plus: Live video call verification with Dorsium staff
• Plus: Full banking details for hardware purchase audit trail
• Rationale: Higher hardware cost and consensus responsibility warrant enhanced verification

Compliance Framework:

• KYC provider: EU-compliant (GDPR-compliant)
• Data retention: 2 years minimum (regulatory requirement)
• User rights: Data access, correction, deletion requests supported
• Cost: Absorbed by project (no fees passed to users)

Why This Approach:

1. Sybil Resistance: Basic KYC prevents mass fake account creation
2. Regulatory Compliance: Aligns with EU AML/KYC requirements under MiCA regulation
3. Educated Community: Knowledge Test ensures users understand token utility and risks before withdrawal
4. Fair Access: Same KYC level for all mining participants (mobile, node, validator)
5. User-Friendly: Mining starts immediately after KYC, Knowledge Test only required before token access

Why Mobile Mining is Real Mining

Common Misconception: "Mobiles just do daily check-ins"

Reality:

• Signature Verification: Computationally identical to full node signature checks
• Transaction Validation: Same cryptographic operations as validators (just on fewer transactions)
• Network Contribution: Essential for transaction propagation and redundancy
• Economic Value: Reduces infrastructure costs by distributing validation work

Comparison to Traditional Mining:

Dorsium's Innovation: Distribute validation work across thousands of lightweight clients instead of concentrating it in expensive hardware.

Rewards Structure

• Reward Rate: Equivalent to 2.72 DORS per 24-hour validation session (1x multiplier)
• Requirement: 95% uptime (23 hours/day active mining)
• PoA Compliance: Pass 2-3 daily activity challenges
• Referral Bonuses: Up to +2.0x multiplier
• Vesting: 20% immediate, 80% vested over 18 months

Technical Implementation

Mining Session Lifecycle:

1. Session Start: User activates mining in app
2. Tunnel Connection: Encrypted connection to VPS established
3. Node Assignment: Assigned to 3-5 nodes for redundancy
4. Active Mining:
   • Receive transaction broadcast from nodes
   • Validate signatures and format
   • Vote on transaction validity (2/3 consensus)
   • Relay to other miners via gossip protocol
5. PoA Check: Random challenge appears (30-second response window)
6. Session End: 24 hours later, rewards calculated

Consensus Participation:

• Miners vote on transaction validity in groups of 9-15
• 2/3 consensus required to forward transaction to nodes
• Failed consensus = transaction returned to pool
• Each miner participates in 5-10 votes/hour during active mining

Network Requirements

Minimum Operational Thresholds:

• Miners: 10 (transaction collection)
• Nodes: 3 (block assembly)
• Validators: 2 (blockchain writing)
• Node Sentinels: 3 (backup system)

Optimal Operational Thresholds:

• Miners: 100+ (transaction collection)
• Nodes: 10+ (block assembly)
• Validators: 5+ (blockchain writing)
• Node Sentinels: 3 (backup system)

Failover Mechanism:

When minimum thresholds not met:

1. Alert sent to all online participants
2. Node Sentinels activate after 5 minutes
3. Sentinels take over missing roles (no rewards earned)
4. Normal operations resume when real nodes return

Insufficient Consensus Handling (<2/3):

At Miner Level:

1. Transaction returned to pool
2. 30-second wait period
3. Retry with different miner group
4. After 3 failed attempts: Transaction rejected with error log

At Node Level:

1. Block assembly suspended
2. Retry in next time slot
3. If 3× failed: Node Sentinels activated

At Validator Level:

1. Block rejected, nodes notified for reassembly
2. Critical alert if no consensus for 5 minutes
3. Emergency governance intervention if 15+ minutes

Misconceptions vs. Reality

Future Enhancements (Post-Mainnet)

• Adaptive Validation: Miners with higher reputation validate more transactions
• Reputation Scoring: Consistent accurate validation increases rewards
• Sharding Support: Miners validate specific transaction shards
• Cross-Chain Bridges: Mobile validation for bridged transactions

Nodes

• Function: Light validators and transaction relay
• Hardware Requirements:
  • CPU: Minimum 4 cores, 2.0 GHz
  • RAM: Minimum 8GB DDR4
  • Storage: 256GB SSD
  • Network: 100 Mbps stable connection
  • OS: Ubuntu 22.04 LTS or compatible
• Rewards: 3x base mining rate
• Requirements: 24/7 operation, stable internet
• Note: Hardware currently assembled by Dorsium project administrator

Validators

• Function: Full consensus participants
• Hardware Requirements:
  • CPU: Minimum 4 cores, 2.5 GHz
  • RAM: Minimum 16GB DDR4
  • Storage: 512GB SSD (NVMe preferred)
  • Network: 500 Mbps dedicated connection
  • OS: Ubuntu 22.04 LTS or compatible
• Rewards: 6x base mining rate
• Requirements: 24/7 operation, high-speed internet
• Note: Hardware currently assembled by Dorsium project administrator

Network Participation Requirements

To ensure network security and prevent spam, certain roles require minimum DORS holdings:

Validator Requirements:

• Minimum 1,000 DORS held (not staked, just held in wallet)
• Purpose: Demonstrate commitment to network security
• Tokens remain liquid and usable for transactions
• No additional rewards for holding

Node Requirements:

• Minimum 500 DORS held (not staked, just held in wallet)
• Purpose: Anti-spam measure for consensus participation
• Tokens remain liquid and usable for transactions

Mobile Miner Requirements:

• No minimum DORS holding required
• Rewards earned through active validation work only

Important Distinction: These are holding requirements, NOT staking. Tokens are not locked and earn no passive rewards. This mechanism solely prevents Sybil attacks by requiring skin-in-the-game without creating investment-like passive income.

Automated Network Infrastructure

Dorsium implements automated systems to maintain network integrity and operational continuity:

Documentation Intelligence System (Dorsium Lux)

Dorsium Lux maintains project consistency through automated documentation analysis:

Technical Implementation:

• Foundation Model: Anthropic Claude (currently Claude Sonnet 4.5, upgradeable)
• Training Data: Project documentation corpus (.md files, business logic, technical specs, governance decisions)
• Core Function: Cross-reference validation across all documentation repositories
• Update Mechanism: Automated retraining after each production release

Operational Role:

• Identifies inconsistencies across project documentation
• Suggests corrections based on established patterns
• Assists governance decision-making with historical context
• Maintains documentation version control and change logs

Technical Architecture:

• Model: Anthropic Claude API (model-agnostic, swappable)
• Context Window: 200K tokens (full project documentation)
• Storage: Version-controlled .md files (GitHub)
• Deployment: Serverless function (Vercel)

Limitations:

• Advisory role only (no autonomous decision-making)
• Requires human approval for all documentation changes
• Limited to text-based analysis (no code execution)

Development Status: Active (operational since Q3 2025)

Emergency Validator Backup (Node Sentinels)

Three automated backup validators ensure network continuity during low participation:

Function:

• Monitor real-time validator participation rates
• Activate automatically when validator count drops below minimum threshold (3 validators)
• Provide temporary consensus participation until human validators return online
• No mining rewards earned (emergency-only operation)

Technical Implementation:

• Automated monitoring scripts (Node.js)
• Heartbeat detection (5-second intervals)
• Automatic failover protocol
• Geographic distribution (EU-West-1, EU-Central-1, EU-North-1)

Activation Trigger:

• Active validators < 3: Immediate activation
• Alert sent to all validator owners
• Normal operations resume when human validators return

Development Status: Planned (testnet deployment Q4 2025)

Archive Node System (Archive Engine)

Dedicated infrastructure for complete blockchain history storage:

Function:

• Maintains full blockchain state (all blocks, transactions, state transitions)
• Provides historical query API for developers and governance
• Indexes all governance proposals and protocol upgrades
• Enables on-chain analytics and audit trails

Technical Implementation:

• Hardware: 2TB NVMe SSD, 32GB RAM, 8-core CPU
• Database: PostgreSQL (timeseries optimization)
• API: GraphQL endpoint (public read access)
• Backup: Daily snapshots, 30-day retention

Development Status: Planned (mainnet deployment Q1 2026)

NFT Minting Validation (Mint Guardian)

Automated rule-based validation for NFT minting requests:

Function:

• Validates NFT minting requests against whitepaper criteria
• Automated approval/rejection based on predefined business rules
• Prevents unauthorized or invalid NFT creation

Technical Implementation:

• Rule engine: Deterministic logic (no ML/AI)
• Validation criteria: Hardcoded business rules from whitepaper
• Approval workflow: Multi-signature requirement for edge cases

Development Status: Future consideration (post-mainnet, 2026+)

Consensus Mechanism: HDC

For complete HDC technical details including attack resistance analysis, consensus flow, and security guarantees, see Hierarchical Delegated Consensus in Solution Overview.

Pre-Mainnet Reward System

For detailed information about the bootstrap trust model, see Pre-Mainnet Trust Model.

Current System (Off-Chain):

• Welcome rewards for new users
• Referral multiplier calculations
• Early adopter bonuses (10 DORS for first 1000 users)
• Development contributor rewards

Verification:

• Public explorer: https://dorsium.com/off-chain-explorer↗
• Verification guide: https://dorsium.com/docs/verification↗
• SHA-256 audit trail for all transactions

Migration: All off-chain balances will be migrated to on-chain during genesis block creation (January 2026). See migration protocol for details.

Bootstrap Philosophy

Dorsium's pre-mainnet phase operates on a centralized trust model by design. This approach was chosen to enable project development and community building without requiring external investors or venture capital, preserving the project's decentralized future.

Key Principle: Centralized bootstrap → Decentralized mainnet

Current System Architecture (Pre-Mainnet)

System Operator

• Entity: Dorsium OÜ (Estonian company)
• Founder: Grávuj Miklós Henrich
• Responsibility: Off-chain database management, reward calculations, system maintenance

Technical Infrastructure

• Reward System: Deterministic backend scripts (Node.js/TypeScript)
• Database: Supabase PostgreSQL (centralized, Dorsium OÜ controlled)
• Calculation Logic: Open-source formulas (publicly verifiable)
• Backup Strategy: Daily snapshots with 7-day retention
• Audit Trail: Every transaction logged with SHA-256 hash for verification
• Public Explorer: https://dorsium.com/off-chain-explorer↗
• Verification Guide: https://dorsium.com/docs/verification↗

What is Controlled

• Off-chain database writes (reward distributions)
• Welcome rewards for new users (MiCA-compliant utility distribution)
• Referral multiplier calculations
• Mining rate adjustments (based on whitepaper formulas)

What is NOT Controlled

• User private keys (users maintain full custody)
• Token distribution percentages (locked in whitepaper)
• Halving schedule (predetermined algorithms)
• Governance rules (community-defined post-mainnet)

Security & Transparency Guarantees

Audit Trail System

Every off-chain transaction includes:

• Transaction ID (SHA-256 hash)
• Timestamp (UTC)
• Sender/Receiver addresses
• Amount and token symbol
• Calculation formula (publicly verifiable)

Verification: Any user can audit their transactions via the public explorer and verify calculations against published formulas.

Disaster Recovery

• Server Failure: Automatic daily backups with geographic redundancy
• Database Corruption: Point-in-time recovery (7-day window)
• Security Breach: Immediate freeze, investigation, restoration from last verified snapshot

Genesis Migration Protocol

Migration Timeline

Phase 1: Database Freeze (December 31, 2025, 23:59 UTC)

1. Off-chain database enters read-only mode
2. Final snapshot created with complete transaction history
3. All balances exported to CSV format

Phase 2: Verification & Export (January 1-7, 2026)

1. Complete database export with SHA-256 verification hash
2. CSV file includes:
   • User wallet addresses
   • Immediate available balances
   • Vested token amounts
   • Complete vesting schedules (start date, cliff, duration)
   • Transaction history hashes
3. Public release of snapshot CSV and verification hash
4. Community verification period: 7 days

Phase 3: Genesis Block Creation (January 8, 2026)

1. Genesis block initialized with:
   • All user addresses from snapshot
   • Immediate balances credited on-chain
   • Vested balances locked in genesis vesting contracts
   • Complete vesting schedules encoded
2. Genesis hash published for public verification

Phase 4: Dispute Resolution (January 8-15, 2026)

1. Users verify their balances against snapshot
2. Dispute submission window: 7 days
3. Manual review of disputed balances with audit trail evidence
4. Final adjustments made via on-chain governance multisig

Phase 5: Mainnet Finalization (January 16, 2026)

1. Genesis block finalized (no further changes possible)
2. On-chain vesting contracts activated
3. Off-chain system archived (permanent read-only)
4. Full transition to decentralized operations

Migration Verification

User Verification Steps:

1. Download genesis snapshot CSV from official source
2. Verify CSV file hash matches published SHA-256 hash
3. Locate personal address in CSV
4. Confirm balances match off-chain explorer records
5. If discrepancy found, submit dispute with audit trail evidence

Technical Verification:

bash
# Example verification command
sha256sum genesis_snapshot.csv
# Output should match: [PUBLISHED_HASH]

Migration Schedule

Automatic Transfer Protocol:

• Migration executes during low network activity periods
• Gradual transfer over 48-72 hours to avoid network congestion
• Real-time monitoring dashboard for community oversight
• Priority given to live transactions during migration window

Trust Assumptions & Limitations

Pre-Mainnet Centralization Risks

What Users Must Trust:

• Dorsium OÜ maintains accurate off-chain records
• Database backups are reliable and complete
• Reward calculations follow published formulas
• Genesis migration executes as described

Mitigation Measures:

• Public audit trail for all transactions
• Open-source calculation formulas
• Community watchdog program (early adopters monitor system)
• Third-party security audit before migration (planned Q4 2025)
• Multi-signature controls on critical operations

Post-Mainnet Decentralization

After genesis migration, trust shifts from Dorsium OÜ to:

• On-chain smart contracts (code is law)
• Validator consensus (distributed validation)
• DAO governance (community control)
• Open-source verification (anyone can audit)

Founder Token Vesting: To align incentives, founder tokens are subject to 10-year vesting with 12-month cliff and 2-year non-tradeable period. This ensures long-term commitment beyond migration.

Why This Approach?

Alternative Paths Not Taken

Option 1: Wait for mainnet before any activity

• No community building
• No early adopter rewards
• No development funding
• Cold launch with no user base

Option 2: Raise venture capital

• Early investor control
• Profit-driven decisions
• Centralization pressure
• Weak negotiating position

Option 3: ICO/Token sale

• Regulatory complexity
• Speculative pricing
• Securities classification risk
• Wealth concentration

Dorsium's Choice: Bootstrap with Off-Chain

• Community-first approach
• Fair distribution through activity
• Development funding via utility tokens
• Strong position for future partnerships
• Regulatory compliance (utility, not security)

Post-Migration Governance

After mainnet launch and successful migration:

1. Off-chain system becomes historical archive (immutable record)
2. All future operations on-chain only
3. DAO governance activated (Phase 2: 2026-2027)
4. Dorsium OÜ transitions to service provider role
5. Community controls protocol upgrades via governance

Transparency Commitment

Pre-Mainnet:

• Quarterly transparency reports
• Real-time explorer access
• Open calculation formulas
• Community Q&A sessions

Post-Mainnet:

• Full on-chain auditability
• Governance proposal transparency
• Developer bounty program
• Annual security audits

Status: This is a bootstrap phase, not the final state. Decentralization is the destination, not the starting point.

DORS Token Fundamentals

Token Supply Rationale

Strategic Supply Design

The 40 billion DORS total supply represents a strategic balance between multiple factors:

1. Global Accessibility

• Sufficient granularity for micropayments across all economies
• Avoids psychological barriers of fractional ownership (0.0001 BTC vs. 100 DORS)
• Enables meaningful token holdings for millions of users globally
• Supports diverse pricing tiers for dApp services

2. Economic Sustainability

• Conservative Year 1 emission: Only 2B DORS (5% of total supply)
• Halving mechanism ensures long-term scarcity (10+ year distribution)
• Comparable to successful projects: Cardano (45B), XRP (100B), Stellar (50B)

3. Controlled Inflation

• Daily emission at 100K miners: 272,000 DORS
• Annual emission Year 1: ~99M DORS (0.25% of total supply)
• Multiple deflationary mechanisms offset emission (fee burns)
• Net result: Supply growth slower than demand growth post-Year 2

4. Psychological Advantage

• Owning "100 DORS" feels more substantial than "0.0001 BTC"
• Whole numbers easier to understand for non-technical users
• Cultural preference in Asian/LATAM markets for "many tokens"
• Reduces friction for mainstream adoption

Comparison with Successful Projects:

Conclusion: 40B supply positions Dorsium for global scale while maintaining scarcity through controlled emission and deflationary mechanisms.

Daily Reward Design

Why 2.72 DORS per Day?

The base mining rate of 2.72 DORS per day was determined through economic modeling to ensure sustainable token distribution:

1. Emission Control

• Target Year 1 emission: ~2B DORS (5% of total supply)
• At 100,000 active miners: 272,000 DORS/day = 99.2M DORS/year
• Ensures conservative inflation rate of 0.25% of total supply annually
• Halving mechanism maintains scarcity as adoption grows

2. Fair Distribution Timeline

• 20B DORS mining pool distributed over 15-20+ years (halving-adjusted timeline)
• Early participants receive full rate before halvings
• Late participants benefit from higher token utility demand
• Balanced incentive structure across adoption curve

3. Comparative Analysis

| Project | Daily Base Rate | Year 1 Emission | Emission % |
|---------|----------------|-----------------|------------|
| Bitcoin (2009) | ~7,200 BTC | ~2.6M BTC | ~12.4% of max supply |
| Ethereum (2015) | ~28,800 ETH | ~10.5M ETH | ~14.6% of genesis supply |
| **Dorsium** | **~272K DORS** | **~99M DORS** | **~0.25% of total supply** |

Result: Dorsium's emission rate is significantly more conservative than established projects, ensuring long-term sustainability.

4. Network Utility Context

The 2.72 DORS daily rate provides meaningful network participation reward when DORS tokens are used for:

• Paying transaction fees (required for all on-chain operations)
• Accessing dApp premium features
• Participating in governance (1,000 DORS proposal fee)

Key Insight: Token utility determines the real-world value of network participation reward. The rate is calibrated for sustainable distribution, not arbitrary mathematical symbolism.

Token Distribution

Total Supply: 40,000,000,000 DORS

┌─ Network Validation Reward (50%): 20,000,000,000 DORS
│   └─ Distributed through mobile, node, and validator mining
│
├─ Ecosystem Development (20%): 8,000,000,000 DORS
│   └─ dApps, partnerships, developer grants
│   └─ 4-year vesting with 1-year cliff
│
├─ Team & Advisors (10%): 4,000,000,000 DORS
│   ├─ Founder Allocation: 400,000,000 DORS (1% of total)
│   │   ├─ 10-year linear vesting with 12-month cliff
│   │   └─ First 2 years: non-stakeable and non-tradeable
│   ├─ Co-Founder Allocation: 400,000,000 DORS (1%)
│   │   ├─ 10-year linear vesting with 12-month cliff
│   │   ├─ First 2 years: non-stakeable and non-tradeable
|   |   └─ Note: Co-founder position to be filled by November 30, 2025
│   └─ Team & Advisors: 3,200,000,000 DORS
│       ├─ 3-year vesting schedule
|       └─ Allocated based on contribution and milestones
│
├─ Treasury (10%): 4,000,000,000 DORS
│   └─ DAO controlled after governance launch
│
├─ Initial Distribution (5%): 2,000,000,000 DORS
│   ├─ Allocation subject to community governance vote (by Nov 30, 2025)
│   └─ Potential uses: Ecosystem development, marketing, operational costs
│
└─ Reserve (5%): 2,000,000,000 DORS
    └─ Emergency fund, burns, future needs

Token Distribution Status

Finalized (Locked):

• Total Supply: 40,000,000,000 DORS (unchangeable)
• Network Validation Reward: 50% (20B DORS)
• Team & Advisors: 10% (4B DORS)
  • Founder: 1% (400M DORS)
  • Co-Founder: 1% (400M DORS, position to be filled by Nov 30, 2025)
  • Team/Advisors: 8% (3.2B DORS)
• Initial Distribution: 5% (2B DORS)
• Base Mining Rate: 2.72 DORS/day
• Halving Schedule: User-based + time-based triggers
• Vesting Schedules: As specified in Vesting Mechanism table

Subject to Optimization (By November 30, 2025):

• Ecosystem Development: 15-25% (6B-10B DORS range)
• Treasury: 5-15% (2B-6B DORS range)
• Reserve: 0-5% (0-2B DORS range)

Rationale for Flexibility: Pool allocations between Ecosystem, Treasury, and Reserve may be optimized based on:

• Developer adoption and grant demand
• Strategic partnership opportunities
• DAO governance structure requirements
• Early ecosystem traction

Hard Deadline: All percentages locked by November 30, 2025, before Testnet launch.

Reward System Overview

Dorsium's reward structure is designed for transparency and fairness. Here's how users earn DORS tokens:

Simple Earning Formula

Base Reward = Base Rate × Hardware Multiplier × (1 + Referral Multiplier)

Where:

• Base Rate: 2.72 DORS/day (for mobile miners)
• Hardware Multiplier: 1x (mobile), 3x (node), 6x (validator)
• Referral Multiplier: 0x to 2.0x (based on referral count)

Quick Examples

Example 1: Mobile Miner (No Referrals)

• Base Rate: 2.72 DORS/day
• Hardware: 1x (mobile)
• Referrals: 0x
• Total: 2.72 DORS/day = 81.6 DORS/month

Example 2: Mobile Miner (10 Referrals)

• Base Rate: 2.72 DORS/day
• Hardware: 1x (mobile)
• Referrals: +0.87x (1×0.15 + 4×0.10 + 5×0.07)
• Total: 2.72 × 1.87 = 5.09 DORS/day = 152.7 DORS/month

Example 3: Node Owner (5 Referrals)

• Base Rate: 2.72 DORS/day
• Hardware: 3x (node)
• Referrals: +0.55x (1×0.15 + 4×0.10)
• Total: 2.72 × 3 × 1.55 = 12.65 DORS/day = 379.5 DORS/month

Example 4: Validator Owner (20 Referrals)

• Base Rate: 2.72 DORS/day
• Hardware: 6x (validator)
• Referrals: +1.37x (1×0.15 + 4×0.10 + 5×0.07 + 10×0.05)
• Total: 2.72 × 6 × 2.37 = 38.69 DORS/day = 1,160.7 DORS/month

Monthly Reward Calculator

Use this table to estimate your monthly DORS reward based on your setup:

⚠️ These are protocol-defined reward rates for network participation. NOT financial projections, employment income, or investment returns.

Notes:

• Calculations assume 30-day month and 95% uptime
• Immediate: 20% available instantly
• Vested: 80% released over 18 months (shown as monthly average)
• Community Growth Rewards (500/400/250 DORS) not included in table (one-time only)

How to Use This Table:

1. Find your hardware type (Mobile/Node/Validator)
2. Locate your referral count
3. See your monthly reward in "Monthly" column
4. "Immediate Monthly" = tokens available for immediate use
5. "Vested Monthly" = average tokens released per month over 18 months

Important Note: The following table shows TECHNICAL REWARD RATES for network validation work. These are NOT investment returns or profit projections. Token value depends entirely on utility demand for network services, not speculation.

Protocol Reward Mechanism

Dorsium compensates network participants for cryptographic validation work and infrastructure operation.

Mobile Validation Work:

• Rate: 2.72 DORS per 24-hour validation session
• Requirements: Active signature verification, transaction validation, 95% uptime
• Work Performed:
  • Ed25519/Secp256k1 signature verification
  • Transaction format validation
  • Balance checking via light client
  • Proof-of-Activity challenges (2-3 per day)
• No Infrastructure Cost: Uses existing smartphone

Node Operation:

• Total Rate: 8.16 DORS per 24-hour session
  • 2.72 DORS: Base validation work (same as mobile)
  • 5.44 DORS: Infrastructure operation reward
• Requirements: 24/7 uptime, 100 Mbps internet, 8GB RAM, 256GB SSD
• Work Performed:
  • All mobile validation work
  • Transaction relay across network
  • Block assembly
  • Light state verification
• Infrastructure Cost: Electricity, internet, hardware wear

Validator Operation:

• Total Rate: 16.32 DORS per 24-hour session
  • 2.72 DORS: Base validation work (same as mobile)
  • 13.60 DORS: Infrastructure operation reward
• Requirements: 24/7 uptime, 500 Mbps internet, 16GB RAM, 512GB NVMe SSD
• Work Performed:
  • All node validation work
  • Full consensus participation (BFT voting)
  • Complete blockchain storage
  • Block finalization
• Infrastructure Cost: Electricity, internet, hardware wear

Reward Rationale:

• Base Rate (2.72 DORS): Compensates cryptographic validation work (identical across all roles)
• Infrastructure Reward: Reimburses operational costs for dedicated hardware (electricity, bandwidth, storage)
• Progressive Structure: Higher infrastructure costs justify higher reward (cost recovery, not profit)

Legal Classification: This structure aligns with employment reward frameworks (work + expense reimbursement), not investment returns (capital + ROI).

Note: Reward is for active network validation work, not passive holding.

Referral Multiplier System

Dorsium rewards users who grow the community, but with strict anti-pyramid safeguards:

Referral Bonus Structure:

⚠️ These are protocol-defined reward rates for network participation. NOT financial projections, employment income, or investment returns.

Maximum Referral Multiplier: +2.0x (hard cap, never exceeds)

Why This is NOT a Pyramid Scheme:

1. Fixed Cap: No exponential growth possible (max 2x bonus, never 10x or 100x)
2. Declining Returns: Each tier earns LESS than previous (0.15x → 0.02x)
3. No Recruitment Requirement: Mining works with 0 referrals
4. Actual Work Required: Must actively mine to earn (referrals alone = nothing)
5. Community-Voted: Approved by 30 early adopters via Google Forms
6. MiCA Compliant: Utility token, not investment scheme

Comparison to MLM/Pyramid:

Real-World Example:

Scenario 1: No Referrals

• Peter mines daily: 2.72 DORS/day
• Month 1: 81.6 DORS
• Referral bonus: 0 DORS
• Total: 81.6 DORS/month

Scenario 2: 10 Referrals

• Peter mines daily: 2.72 × 1.87 = 5.09 DORS/day
• Month 1: 152.7 DORS
• Referral bonus: 0 DORS (if referrals don't buy hardware)
• Total: 152.7 DORS/month

Scenario 3: 10 Referrals + 2 Buy Validators

• Peter mines daily: 5.09 DORS/day = 152.7/month
• Referral bonus: 2 × 500 DORS = 1,000 DORS (one-time)
• Total: 1,152.7 DORS in Month 1, then 152.7/month

Key Takeaway: Referrals are a BONUS, not the primary income. Mining is the core activity.

Community Onboarding Reward

Purpose: Compensate verified educators for technical onboarding work (hardware setup assistance, KYC guidance, mining troubleshooting).

Reward Structure:

"Successful Onboarding" Definition: A referred user is considered "successfully onboarded" when ALL of the following requirements are met:

1. KYC Verification: Complete identity verification (government ID + selfie)
2. Knowledge Test: Pass 70% minimum on Dorsium fundamentals test
3. Active Participation: Mine actively for 30 consecutive days (95% uptime)
4. Hardware Purchase (Optional): If user purchases Node/Validator, reward triggers upon 30-day mining completion

Work Requirements: To qualify for reward, the referring user must demonstrate:

• Pre-Purchase Consultation: Answer hardware questions (documented via Discord/Telegram)
• KYC Assistance: Guide through identity verification process
• Hardware Setup Support: Provide technical assistance during configuration
• Mining Troubleshooting: Resolve issues during first 30 days

Documentation & Verification:

• Reward requests require Discord/Telegram chat logs showing support provided
• Dorsium team reviews requests to confirm genuine educational work
• False claims result in reward denial + account warning

Why Reward Decreases:

• 1-10 users: High individual effort (detailed explanations, extensive troubleshooting)
• 11-20 users: Improved efficiency (educator develops expertise, standardized processes)
• 21+ users: Scaled operations (less time per user, established support patterns)

Legal Classification: This is service reward for educational work, not recruitment-based income:

• Reward for documented technical support (labor)
• 30-day mining requirement proves genuine participation (not fake signups)
• Hardware purchase is user's independent decision (not purchase requirement for reward)
• Declining rates reflect reduced effort per user (work-based, not pyramid-based)
• NOT passive recruitment income (active work required)
• NOT MLM structure (mining is primary income, education is optional bonus)

MiCA Compliance:

• Utility token distribution for community building work
• Active participation requirement (30-day mining)
• No investment promise or ROI guarantee
• Documented labor justifies reward

Future Activity Bonuses

Additional multipliers planned post-mainnet for:

• Consistent mining participation
• Network contribution metrics
• Governance engagement Details to be finalized based on network activity patterns.

Adaptive Halving System

Primary Trigger: User-Based

• 100,000 active miners → 1st halving (2.72 → 1.36 DORS/day)
• 500,000 active miners → 2nd halving (1.36 → 0.68 DORS/day)
• 2,000,000 active miners → 3rd halving (0.68 → 0.34 DORS/day)
• 5,000,000 active miners → 4th halving (0.34 → 0.17 DORS/day)
• 10,000,000 active miners → 5th halving (0.17 → 0.085 DORS/day)

Fallback Trigger: Time-Based (If User Target Not Met)

• 2 years from mainnet → 1st halving (if <100K miners)
• 4 years from mainnet → 2nd halving (if <500K miners)
• 6 years from mainnet → 3rd halving (if <2M miners)
• 8 years from mainnet → 4th halving (if <5M miners)
• 10 years from mainnet → 5th halving (if <10M miners)

Emergency Trigger: Supply-Based (Overrides All)

• 15 billion DORS mined → Immediate halving (regardless of user count or time)
• 18 billion DORS mined → Final low-emission phase (0.01 DORS/day)
• 19.5 billion DORS mined → Mining ends (0.5B reserve for bugs/emergencies)

Priority Order:

1. User-based (primary) - activates first if target met
2. Time-based (fallback) - activates if user target missed by deadline
3. Supply-based (emergency) - overrides both if emission too fast

Example Scenarios:

• Fast Growth: 100K miners reached in 6 months → 1st halving triggers immediately (time trigger irrelevant)
• Slow Growth: 50K miners after 2 years → Time trigger forces 1st halving (protects supply)
• Runaway Emission: 15B DORS mined in 18 months → Emergency halving triggers (regardless of miner count)

Transparency:

• Real-time dashboard shows: current miners, DORS mined, days until time trigger
• Community alerts 30 days before any halving trigger

Vesting Mechanism

Vesting Explained (Simple)

Vesting ensures long-term commitment and prevents mass sell-offs that could crash token price.

Utility-Driven Value

DORS tokens provide access to network services. Token demand derives from:

1. Transaction Fees (Required)

• All on-chain operations require DORS payment
• Smart contract execution fees
• Data storage fees proportional to usage
• Non-optional for network access

2. dApp Ecosystem Access

• Premium features require DORS payment
• In-app purchases use DORS
• Service payments within ecosystem
• Developer revenue sharing in DORS

3. Governance Participation

• Proposal creation: 1,000 DORS required
• Voting rights based on holdings
• Parameter adjustment proposals
• Community-driven decision making

Future Utility Expansion (Post-Mainnet): Additional use cases will be developed based on community feedback and market demand, potentially including hardware accessories, branded merchandise, and third-party integrations.

How It Works (Example)

You mine 100 DORS today:

Day 1 (Immediate):

• 20 DORS unlocked (20%)
• 80 DORS locked in vesting contract

Month 1-18 (Linear Release):

• 80 DORS ÷ 18 months = 4.44 DORS released per month
• Each month, more tokens become available

Month 19 (Fully Unlocked):

• All 100 DORS now available for the user

Visual Timeline

Day 1:    [████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░] 20 DORS available
Month 6:  [████████████████████████████████████░░░░░░░░░░░░░░░░░░░░░░] 46.6 DORS available
Month 12: [████████████████████████████████████████████████████░░░░░░] 73.3 DORS available
Month 18: [████████████████████████████████████████████████████████████] 100 DORS available

Why Vesting Matters

Without Vesting:

• User mines 1,000 DORS
• Sells all 1,000 immediately
• Token price crashes from sell pressure

With Vesting:

• User mines 1,000 DORS
• Can only sell 200 immediately
• 800 released over 18 months
• Price remains stable

Exception: Community Growth Rewards

Community Growth Rewards (500/400/250 DORS for hardware purchases) are NOT vested:

• 100% available immediately
• Reward for growing the community
• Lower amounts prevent market impact

Vesting Status Checker

Users can check their vesting status anytime:

• Login → "My Vesting Schedule" (available from 2026)
• See exact unlock dates and amounts

Adoption Metrics (Not Price Predictions)

Network health indicators track utility demand, not speculative value:

Technical Metrics:

• Active validators: Target 100+ by end of 2026
• Daily transaction volume: Target 1,000 TPS by 2027
• dApp integrations: Target 10+ by end of 2026
• Global user base: Target 100,000+ active miners by end of 2026

Utility Metrics:

• Transaction fees paid in DORS (network usage)
• dApp revenue generated in DORS (ecosystem health)
• Hardware purchases with DORS (direct utility)
• Governance proposals submitted (community engagement)

Important Note: Token value is determined by market forces based on utility demand. This whitepaper provides no price predictions, investment advice, or return expectations. DORS is a utility token for network access, not a financial investment.

Supply Design Philosophy

Why 40 Billion DORS?

Dorsium's 40 billion token supply is strategically designed for global-scale adoption while maintaining meaningful per-network utility demand:

Comparison with Major Cryptocurrencies:

Key Insights:

• Dorsium's Year 1 emission is conservative: Only ~2B DORS (5% of supply) distributed in first year
• Cardano (45B supply) achieved Top 10 market cap, proving 40B+ supply is viable
• Lower circulating supply in Year 1 = Less sell pressure than established projects

Why 2.72 DORS/day?

The base rate of 2.72 DORS per day (Euler's constant e ≈ 2.71828) balances multiple factors:

1. Psychological Appeal: A memorable, mathematically elegant number
2. Economic Sustainability:
   • 100,000 miners × 2.72 DORS/day = 272,000 DORS/day
   • 99.2M DORS/year = Only 0.25% of total supply
3. Scalability: Rate halves as user base grows, maintaining scarcity
4. Fair Distribution: Accessible rewards without devaluing early adopters

Alternative Supply Scenarios:

Result: 40B supply with 2.72 DORS/day provides optimal granularity for global adoption while maintaining scarcity through controlled emission.

Value Accrual Mechanisms

How DORS Captures Value:

1. Deflationary Pressure (Supply Reduction)

• Transaction Fee Burns: 50% of all network fees permanently burned
• Projected Burn Rate:
  • At 1,000 TPS: ~43M DORS burned/year
  • At 10,000 TPS: ~430M DORS burned/year
• Governance Burns: Community-voted quarterly burns from treasury
• Result: Circulating supply decreases over time, increasing scarcity

2. Token Utility Requirements (Demand Creation)

• Network Operations: DORS required for all transactions (non-optional)
• Governance Participation: 1,000 DORS to submit proposals
• dApp Ecosystem: DORS required for in-app purchases and premium features

3. Vesting-Induced Scarcity (Limited Liquidity)

• 80% of mined DORS vested for 18 months
• Team tokens vested for 3-10 years
• Year 1 liquid supply: ~400M DORS (only 1% of total)
• Result: Low circulating supply despite high total supply

4. Hardware Purchase Utility (Direct Demand)

• All accessories and peripherals ONLY purchasable with DORS
• Projected demand: 10,000 users × 100 DORS/accessory = 1M DORS locked
• Result: Direct buy pressure independent of speculation

Supply vs. Demand Balance

Supply-Side (Emission):

• Year 1: ~2B DORS (5%)
• Year 2-3: ~2B DORS (halving triggered)
• Year 4-5: ~1B DORS (second halving)
• Total Year 1-5: ~5B DORS (12.5% of supply)

Demand-Side (Consumption/Lock):

• Transaction fees: 50M-500M DORS/year (burned)
• Hardware purchases: 1M-10M DORS/year (locked temporarily)
• dApp usage: 10M-100M DORS/year (circulating)
• Total Demand: 1.5B-3.5B DORS/year

Net Effect: Network utility requirements are projected to exceed token emission after Year 2, supporting long-term utility value.

Why Critics Are Wrong About Supply

Common Criticism #1: "40B is too much, Bitcoin only has 21M"

Reality:

• Supply number is arbitrary; adoption metrics matters
• Cardano (45B), XRP (100B), Stellar (50B) all achieved Top 20
• Psychology: 100 DORS feels better than 0.0001 BTC for everyday users

Common Criticism #2: "2.72 DORS/day is worthless"

Reality:

• DORS purchasing power reflects network usage demand, not token quantity
• Token utility determines real-world applicability across different economies
• Halvings ensure scarcity as adoption grows
• Comparison: Early Bitcoin gave 50 BTC/block (initially minimal utility), now has global utility demand

Dorsium's Advantage: Controlled emission + multiple demand drivers + deflationary mechanism

Token Utility

Primary Use Cases

1. Network Operations

   • Transaction fees
   • Smart contract execution
   • Data storage fees

2. Governance

   • Proposal creation (1,000 DORS)
   • Voting power
   • Parameter adjustments

3. dApp Ecosystem

   • In-app purchases
   • Premium features
   • Service payments

4. Hardware Ecosystem

   • Accessories and peripherals
   • Branded merchandise

Deflationary Mechanisms

• Fee Burns: 50% of transaction fees burned
• Governance Burns: Community-voted token burns
• Future Mechanisms: Additional deflationary measures as voted by governance

Brand Protection Strategy

• Trademark: DORS name and logo registration
• Domain Names: Key domains secured
• Social Media: Official handles reserved
• Future Bridges: Cross-chain expansion post-mainnet

Technology Stack

• Blockchain: Cosmos SDK (transitioning to custom HDC)
• Backend: Node.js/TypeScript, PostgreSQL
• Mobile: React Native with Expo
• Web: Next.js
• Current Performance: 50-100 TPS (testnet target)
• Launch Performance: 100-300 TPS (Q1 2026)
• Future Target: 1,000+ TPS (2027+, subject to optimization)

Infrastructure

• Hosting: AWS EU-Central-1
• CDN: CloudFlare
• CI/CD: GitHub Actions
• Monitoring: Basic CloudWatch
• Future: Multi-region expansion as needed

KYC-Based Attack Prevention

Hardware Purchase Security

All Node and Validator purchases follow a strict verification process:

1. Registration: User submits personal information (name, email, country)
2. Email Confirmation: Verification link sent to provided email
3. Video KYC Scheduling: User schedules mandatory video call with Dorsium staff
4. Identity Verification: Live video call confirms identity and intent
5. Manual Approval: Dorsium staff reviews and approves/rejects application
6. Payment: Bank transfer to company account (full audit trail)
7. Hardware Shipping: Tracked delivery with serial number registration

Attack Prevention:

• Mass purchases trigger immediate detection (same person on multiple video calls)
• Bank transfer records create legal accountability
• Serial number tracking prevents hardware resale attacks
• Geographic clustering detection prevents regional dominance

Mobile Miner Anti-Sybil Protection

All mining participants undergo mandatory identity verification:

Basic KYC Requirements (All Roles):

• Government-issued ID verification
• Selfie with ID document
• Automated identity verification (EU-compliant KYC provider)
• Knowledge Test (70% passing score)
• One account per verified identity

Additional Requirements (Node/Validator):

• Live video call with Dorsium staff
• Banking details verification
• Hardware serial number registration

Attack Prevention:

• Creating 1,000 fake miner accounts requires 1,000 verified government IDs (impossible at scale)
• Knowledge Test prevents bot automation
• Real-time behavioral analysis flags suspicious patterns
• Progressive penalties for fraudulent activity

Result: Creating fake mobile miners at scale is economically and practically impossible given the KYC barrier, Knowledge Test requirement, and monitoring systems.

Multi-Layer Security Model

Level 1: Mobile Validation

• Cross-device validation
• Activity verification checks
• Biometric authentication

Level 2: Node Protection

• Encrypted tunnel communication
• DDoS protection
• Geographic distribution
• Redundant validation

Level 3: Validator Security

• BFT consensus (2/3 requirement)
• Penalty mechanisms for misbehavior
• Key management best practices
• Multi-signature treasury wallets

Anti-Fraud Systems

Proof-of-Activity

• Random daily challenges (2-3 times)
• 30-second response window
• Device integrity verification

Suspicious Activity Detection

• Impossible uptime patterns
• Static GPS coordinates
• Automated response timing
• Multiple account detection

Progressive Penalty System

1. First Offense: 24h suspension + warning
2. Second Offense: 7-day suspension + 50% multiplier reduction
3. Third Offense: Account termination

Cryptographic Standards

Current Implementation

Dorsium uses industry-standard cryptographic algorithms proven secure for the foreseeable future:

Digital Signatures:

• Primary: Ed25519 (Cosmos SDK native)
• Alternative: Secp256k1 (Ethereum compatibility)
• Security Level: 128-bit equivalent (secure until 2030+)

Hashing:

• Algorithm: SHA-256 for all cryptographic operations
• Security Level: 256-bit (no known practical attacks)

Key Management:

• Hardware wallet support (Ledger/Trezor)
• Mobile secure enclave (iOS Keychain, Android Keystore)
• BIP39 mnemonic backup (industry standard)
• Multi-signature options for treasury wallets

Future-Proofing

Dorsium's modular architecture enables cryptographic upgrades through governance when necessary:

Upgrade Capability:

• Governance-approved protocol changes
• Backward compatibility during transition periods
• Community-driven security improvements

Timeline:

• Current (2025-2030): Existing algorithms remain secure
• Future (2030+): Evaluate post-quantum cryptography adoption based on:
  • NIST PQC standardization maturity
  • Industry-wide implementation patterns
  • Demonstrated quantum computing threats
  • Community governance decisions

Why This Approach:

• Focus on immediate security needs (KYC, BFT consensus, encryption)
• No unnecessary complexity for distant threats
• Governance allows future upgrades without premature commitment
• Industry alignment (Bitcoin/Ethereum also use SHA-256/Ed25519)

Note: Quantum computing threats are estimated to be 5-10+ years away. Dorsium will monitor developments and upgrade when industry consensus emerges, not before.

Security Audit Program

Pre-Mainnet Requirements

• External audit (Certik/Halborn)
• Penetration testing
• Load testing (10x capacity)
• Community bug bounty

Bug Bounty Rewards

Progressive Governance Structure

Dorsium's governance evolves through three phases, transitioning based on measurable milestones rather than arbitrary dates:

Phase 1: Foundation-Led (Current - Until Mainnet + 6 months)

Leadership:

• Project founder + core team (operational decisions)
• Hardware owners (30+ validators/nodes) - advisory input
• Community voting on key decisions (Google Forms → Web3 platform)

Decision-Making Process:

• Operational: Founder decides (infrastructure, development priorities, timeline)
• Strategic: Community votes (referral multipliers, tokenomics adjustments, major partnerships)
• Example: Referral multiplier system voted by 30 early adopters (Google Forms, Q2 2025)

Community Participation:

• Quarterly Google Forms surveys on governance topics
• Discord/Telegram feedback channels (monitored by founder)
• Quarterly transparency reports (financials, roadmap updates)

Why This Phase Exists:

• Bootstrap phase requires fast decision-making
• Community too small for full DAO (30 members → 100+ needed)
• Founder accountability (PFA/OÜ legal entity, trademark holder)
• Hardware sales require operational control (KYC, shipping, support)

Transition Trigger to Phase 2:

• Milestone 1: Mainnet launch (Q1 2026)
• Milestone 2: 1,000+ active miners
• Milestone 3: 100+ hardware owners (validators/nodes)
• Milestone 4: 6 months post-mainnet stability

Expected Timeline: Q3 2026 (6 months after mainnet)

Phase 2: Hybrid Governance (Mainnet + 6 months - Until Full DAO)

Transition Mechanism: When ALL Phase 1 milestones are met:

1. Founder announces transition proposal (Discord + web platform)
2. Community votes (all hardware owners + top 100 miners by balance)
3. 75% approval required to proceed
4. 2-week transition period (Advisory Board elections)

Leadership:

• Advisory Board: 5-7 community members (elected by token-weighted vote)
• Founder: Operational role (development, infrastructure)
• Multi-sig Treasury: 3-of-5 signatures required (2 Board + 1 Founder + 2 Validators)

Decision-Making Process:

• Operational: Founder proposes, Advisory Board approves (3/5 votes)
• Strategic: Community votes on web3 platform (dorsium.com or dorsium.io)
• Proposal Rights: 1,000 DORS minimum to submit governance proposal
• Voting Period: 7 days discussion + 14 days voting
• Quorum: 5% participation required

Advisory Board:

• Election: Annual elections via token-weighted voting
• Term: 1-year term (re-election allowed)
• Responsibilities:
  • Review founder proposals (infrastructure, partnerships, budget)
  • Propose strategic initiatives to community
  • Represent community interests in negotiations
• Reward: 10,000 DORS/year (vested over term)

Web3 Voting Platform:

• Built on Dorsium chain (post-mainnet)
• Snapshot-style voting (no gas fees for voting)
• Proposals visible at dorsium.com or dorsium.io
• Token-weighted voting (1 DORS = 1 vote + activity bonus)

Why This Phase Exists:

• Community large enough for governance (1,000+ members)
• Mainnet stability allows governance experimentation
• Founder still needed for operations, but oversight via Board
• Prepares community for full DAO transition

Transition Trigger to Phase 3:

• Milestone 1: 10,000+ active miners
• Milestone 2: 500+ hardware owners
• Milestone 3: 50+ governance proposals submitted
• Milestone 4: 12 months of Phase 2 operations (stability test)

Expected Timeline: Q3 2027 (12 months after Phase 2 start)

Phase 3: Full DAO (2027+)

Transition Mechanism: When ALL Phase 2 milestones are met:

1. Advisory Board proposes Full DAO transition
2. Community votes (all DORS holders)
3. 75% approval + 10% quorum required
4. 3-month transition period (legal entity setup, smart contracts)

Leadership:

• DAO-Controlled Entity: Estonian OÜ or Swiss Foundation
• Board Members: 7-9 elected by token-weighted vote
• Founder Role: Community member (no special privileges)

Decision-Making Process:

• All Decisions: Token-weighted voting on-chain
• Proposal Fee: 1,000 DORS (refunded if >25% approval)
• Voting Period: 7 days discussion + 14 days voting
• Quorum: 10% participation required
• Execution: Automated via on-chain governance contracts

DAO Treasury:

• Multi-signature wallet (5-of-9 Board members)
• Budget proposals require community vote
• Quarterly financial reports (on-chain + explorer)

Legal Entity:

• Board elected annually (token-weighted voting)
• Board manages legal compliance (EU regulations, tax, partnerships)
• Board has NO authority to override DAO votes
• Smart contracts enforce DAO decisions

Why This Phase:

• Community mature enough for full decentralization
• No single point of failure (not founder-dependent)
• Legal compliance via elected Board (not arbitrary control)
• Dorsium achieves true decentralization vision

Governance Transition Timeline (Summary)

Milestone Adjustment Mechanism

If expected timelines are not met, the community can propose milestone adjustments:

Adjustment Process:

• Any holder with 10,000+ DORS can propose milestone adjustment
• Proposal must include: reason, new milestone/timeline, transition plan
• Voting: 75% approval + 10% quorum required
• Quarterly review: Founder reports progress toward milestones in transparency reports

Example Scenarios:

• Slower Growth: Q3 2026 arrives, only 500 miners (target was 1,000)
  • Option A: Wait until 1,000 miners reached (delayed Phase 2)
  • Option B: Adjust milestone to 500 miners + additional conditions
  • Option C: Proceed to Phase 2 with interim governance structure
• Faster Growth: 1,000 miners reached in Q1 2026 (6 months early)
  • Community can vote to accelerate Phase 2 transition if other milestones also met

Rationale: Milestone-based governance is more important than time-based. If growth is slower/faster than expected, community decides how to proceed rather than being locked into arbitrary dates.

Community Participation (All Phases)

Current Tools (Phase 1):

• Google Forms surveys (quarterly governance topics)
• Discord polls (strategic decisions like referral multipliers)
• Telegram feedback (operational questions)

Upcoming Tools (Phase 2+):

• Web3 voting platform (dorsium.com or dorsium.io)
• Snapshot-style proposals (no gas fees)
• On-chain governance portal (Phase 3)

Example Past Votes:

• Q2 2025: Referral multiplier structure (30 early adopters voted via Google Forms)
• Result: Current referral system (0.15x → 0.02x declining structure)

Future Votes:

• Token distribution optimization (Ecosystem/Treasury/Reserve percentages)
• Hardware pricing adjustments
• Strategic partnership approvals
• Major protocol upgrades

Why This Phased Approach?

Comparison to Other Projects:

Key Insight: Dorsium's 2.5-year transition is FASTER than most major blockchains, but still realistic for community maturity.

Transparency & Accountability

Quarterly Reports (All Phases):

• Development progress (GitHub commits, testnet/mainnet metrics)
• Financial overview (hardware sales, operational costs - aggregated, not detailed)
• Community growth (miner count, hardware owners, governance participation)
• Upcoming decisions (what will be voted on next quarter)

Founder Accountability:

• 10-year vesting (400M DORS, 1% of supply)
• 12-month cliff + 2-year non-tradeable period
• Aligned with long-term project success (not exit-focused)

Community Watchdog Program:

• Early adopters monitor system (off-chain explorer audits)
• Report discrepancies to Discord/Telegram
• Quarterly Q&A sessions (founder answers community questions)

Addressing Concerns

Concern 1: "2027 is too long for decentralization"

Response:

• Most blockchains took 3-7 years (Ethereum, Cardano, Cosmos)
• Dorsium: 2.5 years (faster than average)
• Community needs time to mature (governance participation skills)

Concern 2: "Founder has too much control in Phase 1"

Response:

• Community votes on strategic decisions (referral system voted by 30 members)
• Whitepaper locks distribution (founder can't change)
• Quarterly transparency reports (community oversight)
• Transition milestones are measurable (not arbitrary)

Concern 3: "What if founder doesn't transition?"

Response:

• Milestones are public (1K miners, 100 hardware owners)
• Community can verify milestones (on-chain data)
• Founder token vesting (10 years) aligns incentives
• Community can fork if founder refuses (open-source code)

Concern 4: "What if milestones are not met on time?"

Response: Milestones are more important than timelines. If growth is slower or faster than expected, the community has the power to adjust:

Flexible Timeline Adjustment:

• If milestones not met within expected timeline, community can vote to:
  • Extend timeline (e.g., Phase 2 starts at 1K miners even if takes 24 months instead of 18)
  • Adjust milestones (e.g., reduce to 500 miners if growth slower than expected)
  • Add additional conditions (e.g., "500 miners + 6 months stability + external audit")
• 75% approval + 10% quorum required for any changes
• Quarterly transparency reports track progress toward milestones

Why This Matters:

• Dorsium's success isn't guaranteed on a specific timeline
• Community should control governance transition, not arbitrary dates
• Flexibility allows adaptation to real-world conditions

Example: If Q3 2026 arrives with only 500 miners (not 1,000), the founder CANNOT unilaterally stay in Phase 1. Community votes on one of:

1. Wait for 1,000 miners (Phase 1 continues)
2. Proceed with 500 miners + stricter oversight
3. Modify milestones based on ecosystem maturity

Protection Against Abuse:

• 10,000 DORS minimum to propose adjustment (spam prevention)
• 75% approval is high bar (not easy to manipulate)
• Quarterly reviews keep founder accountable
• Community can always fork if founder refuses transition

Status: Governance is NOT fully decentralized day 1, but transition is transparent, milestone-based, and faster than most major blockchains.

Balanced Voting Power System

Dorsium implements a balanced governance model that prevents plutocracy while rewarding active participation.

Formula:

Voting Power = sqrt(DORS allocated) + Role Bonus + Activity Score + NFT Bonus

Mandatory Requirement:

• KYC verification required to participate in governance (prevents Sybil attacks)
• DORS allocated to voting are locked until voting period ends (shows commitment)

1. Token Weight (Square Root)

Allocated DORS are converted to voting power using square root to prevent whale domination:

| DORS Allocated | Voting Power | Effect |
|---------------|--------------|---------|
| 100 | 10 | Entry level participation |
| 1,000 | ~32 | Active member weight |
| 10,000 | 100 | Significant holder |
| 100,000 | ~316 | Large holder (diminishing returns) |
| 1,000,000 | 1,000 | Whale (capped influence) |

2. Role Bonus (Hardware Commitment)

Fixed bonus based on network role:

• Mobile Miner: +10 votes (KYC verified)
• Node Owner: +30 votes (hardware investment)
• Validator Owner: +60 votes (maximum commitment)

3. Activity Score (Maximum 50 points)

Rewards consistent participation:

• Mining Consistency: +1 point per consecutive month (max 30 points)
• Governance History: +2 points per proposal voted in last 6 months (max 20 points)
• Note: Resets to 0 if inactive for 90 days

4. NFT Bonus (Unlimited)

Rewards early adopters and achievement holders:

• Genesis Miner NFT: +2 votes (first 1,000 users)
• Validator Node NFT: +3 votes (hardware commitment)
• Achievement NFTs: Variable bonus votes (community milestones)
• Stacking: Additive (multiple NFTs sum up)
• Note: NFT benefits are permanent and auto-active

Example Voting Power Calculations

Scenario 1: Small Active Miner

• Allocates: 500 DORS (sqrt = ~22)
• Role: Mobile Miner (+10)
• Activity: 15 months mining + voted 5 times (15 + 10 = 25 points)
• NFT: None (0)
• Total: 22 + 10 + 25 + 0 = 57 voting power

Scenario 2: Large Passive Holder

• Allocates: 1,000,000 DORS (sqrt = 1,000)
• Role: None (0)
• Activity: None (0)
• NFT: None (0)
• Total: 1,000 + 0 + 0 + 0 = 1,000 voting power

Scenario 3: Active Validator Owner

• Allocates: 10,000 DORS (sqrt = 100)
• Role: Validator (+60)
• Activity: 24 months mining + voted 10 times (24 + 20 = 44 points)
• NFT: None (0)
• Total: 100 + 60 + 44 + 0 = 204 voting power

Scenario 4: Early Adopter with Genesis NFT

• Allocates: 1,000 DORS (sqrt = ~32)
• Role: Mobile Miner (+10)
• Activity: 12 months mining + voted 3 times (12 + 6 = 18 points)
• NFT: Genesis Miner (+2)
• Total: 32 + 10 + 18 + 2 = 62 voting power

Scenario 5: Collector with Multiple NFTs

• Allocates: 5,000 DORS (sqrt = ~71)
• Role: Node Owner (+30)
• Activity: 20 months mining + voted 8 times (20 + 16 = 36 points)
• NFT: Genesis Miner (+2) + Validator Node (+3) + Achievement (+1) = +6
• Total: 71 + 30 + 36 + 6 = 143 voting power

Key Benefits

1. Whale Resistance: Square root ensures 1M DORS ≠ 1M votes
2. Commitment Reward: Hardware owners get meaningful bonus
3. Activity Matters: Consistent participants have stronger voice
4. Early Adopter Recognition: NFT holders receive permanent voting bonus
5. Sybil Protection: KYC requirement prevents fake accounts
6. Skin in the Game: Locked DORS during voting ensures genuine interest

Voting Process

1. Proposal Phase: 1,000 DORS fee to submit (refunded if >50% approval or 50% refund if >25% approval)
2. Discussion: 7 days for community debate
3. Allocation Window: 24 hours to allocate DORS to vote
4. Voting Period: 14 days (DORS locked during this time)
5. Execution: If passed, proposal executed; DORS unlocked for all

Note: This system balances token holder rights with active participant influence and early adopter recognition, preventing both plutocracy and mob rule.

Governance Proposal Requirements

Proposal Fee: 1,000 DORS

• Initial setting (adjustable via governance vote)
• Paid from proposer's wallet at submission
• Fee sent to treasury

Refund Mechanism:

• Proposal passes (>50% approval + quorum) → 100% refund from treasury
• Proposal fails but serious (>25% approval) → 50% refund from treasury
• Proposal spam (<25% approval) → No refund (fee stays in treasury)

Why This Fee Level:

• Accessible: 1,000 DORS = ~10 days mining (mobile) or 3 days (node)
• Deterrent: High enough to prevent spam
• Adjustable: Community can vote to increase/decrease if needed

Spam Protection:

• Fee threshold deters frivolous proposals
• Optional KYC means mass fake accounts unlikely (would need token holdings)
• 3-day review period allows spam flagging before voting

Why This System Works

For Small Holders:

• Optional identity verification gives base voting power (6,000+ votes)
• Can participate meaningfully without large holdings
• Proposal fee accessible (10 days mining work)

For Large Holders:

• Token weight ensures stake-based influence
• Cannot be diluted by Sybil attacks (identity weight capped)
• Aligned incentives (more DORS = more voice)

For Privacy-Conscious Users:

• Can participate without KYC (token weight only)
• No mandatory identity verification for governance
• Choice between privacy and identity bonus

For Network Security:

• Sybil attacks expensive (need DORS holdings + optional identity)
• Spam proposals deterred by 1,000 DORS fee
• Treasury funded by spam attempts (non-refunded fees)

For MiCA Compliance:

• No price oracles (fixed DORS amount)
• Optional KYC (not mandatory discrimination)
• Adjustable parameters via decentralized governance

Governance Voting Process

Phase 1: Proposal Submission

1. User pays 1,000 DORS fee (sent to treasury)
2. Proposal enters 3-day review period
3. Spam flagging allowed (Phase 2: Advisory Board, Phase 3: Community)

Phase 2: Discussion (7 days)

• Open forum debate
• Proposer clarifies details
• No voting yet

Phase 3: Voting (14 days)

• Users vote: Yes / No / Abstain
• Voting power calculated at snapshot block
• Quorum required (10% for Phase 3 DAO)

Phase 4: Execution

• Pass (>50% + quorum) → Refund 1,000 DORS, execute proposal
• Fail (>25%) → Refund 500 DORS
• Spam (<25%) → No refund, fee stays in treasury

Status: Balanced voting system with optional identity verification, accessible proposal fees, and MiCA-compliant fixed DORS amounts.

DAO Transition Risks

Timeline Uncertainty: The 2.5-year DAO timeline assumes:

• Predictable user growth (100K+ miners by Q3 2026)
• Stable technical operations (no major bugs/attacks)
• Community engagement maturity (50+ proposals by Q3 2027)

If these milestones are NOT met, the transition may extend to 3-5 years. Community votes to adjust timeline if needed (see Milestone Adjustment Mechanism).

Sustainability Framework

Revenue Streams

1. Transaction Fees: Network operations
2. dApp Fees: Ecosystem services
3. NFT Marketplace: Trading commissions
4. Enterprise Services: Private chain deployment

Cost Structure

1. Development: 35% of revenue
2. Operations: 20% of revenue
3. Marketing: 15% of revenue
4. Reserve: 10% of revenue
5. Profit Margin: 20% of revenue

Market Dynamics

Supply Control

• Emission Schedule: User-dependent halving
• Maximum Supply: Hard cap at 40B DORS
• Burn Mechanisms: Deflationary pressure
• Vesting Schedules: Controlled release

Demand Drivers

• Utility Requirements: Network usage
• Governance Rights: Decision power
• dApp Integration: Ecosystem growth
• Hardware Purchases: DORS-only payment model
• Pre-mainnet Revenue: Multiple income streams before token launch

Pre-Mainnet Revenue Streams

Advertising Revenue

• In-App Ads: Non-intrusive banner and interstitial ads
• Sponsored Content: Featured dApps and services
• Partnership Promotions: Co-marketing opportunities
• Projected Revenue: $50,000-100,000/month at 100k users

In-App Purchases

• Premium Features: Advanced analytics and tools
• Cosmetic Items: Profile customization
• Subscription Tiers: Monthly premium memberships

Hardware Sales Margins

• USB Devices: 40% margin in DORS equivalent
• Network Equipment: 35% margin in DORS equivalent
• Bundled Packages: 45% margin for complete sets
• Enterprise Solutions: Custom pricing with higher margins

Bootstrap Funding Model

Founding Philosophy

Dorsium is intentionally self-funded through community hardware sales, avoiding venture capital to preserve decentralization and community ownership.

Why No VC Funding?

Traditional crypto projects raise millions from VCs, creating immediate pressure:

• Focus on quick ROI over long-term value
• Token price manipulation for investor exits
• Centralization pressure (VCs want control)
• Community becomes exit liquidity

Dorsium's Alternative: Community Bootstrap

• Hardware sales fund development directly
• No external investors demanding returns
• Community owns the project from day one
• Sustainable revenue without speculation
• Decisions made for users, not investors

Revenue Sources (Pre-Mainnet)

1. Hardware Sales (Primary)

• Node units: €635 per unit (November 2025 price)
• Validator units: €950 per unit (November 2025 price)
• All hardware assembled and shipped by Dorsium team
• Centralized sales model ensures KYC compliance and quality control
• Post-mainnet: Prices may increase based on demand

Why Centralized Hardware Sales?

• Security: Video KYC verification built into purchase process
• Quality: Consistent hardware specs, no compatibility issues
• Support: Direct customer support from Dorsium team
• Attack Prevention: Mass hardware purchases detected immediately
• Fair Distribution: Geographic diversity enforced through shipping limits

2. Future Revenue Streams

• Kickstarter campaign (post-OÜ formation, until Q1 2026)
• dApp ecosystem fees (post-mainnet, 2026+)
• Transaction fee revenue (mainnet launch, 2026)
• NFT marketplace commissions (future consideration)

Transparency Commitment

What We Share:

• Token distribution locked in whitepaper
• Hardware prices publicly listed
• Development roadmap published
• Quarterly progress reports

What Remains Private:

• Exact monthly revenue (competitive business information)
• Detailed cost breakdown (operational security)
• Cash reserves (unnecessary for community trust)

Why This Approach?

• Protects competitive advantage
• Prevents copycat projects
• Maintains operational security
• Community trusts actions, not spreadsheets

Sustainability Plan

Short-Term (2025-2026):

• Hardware sales fund development
• 30+ early adopters already contributing (as per November 2025)
• Target: 100+ hardware units sold by testnet (December 2025)

Medium-Term (2026-2027):

• Mainnet transaction fees begin
• dApp ecosystem revenue activated
• Kickstarter campaign for ecosystem expansion
• Hardware sales continue as secondary revenue

Long-Term (2027+):

• Self-sustaining through transaction fees
• DAO treasury funds development
• Community-driven revenue strategies
• Hardware sales shift to third-party manufacturers

Comparison: Bootstrap vs. VC-Funded

Risk Acknowledgment

Pre-Mainnet Risks:

• Development speed limited by hardware sales
• No safety net if sales decline
• Founder-dependent operations

Mitigation:

• Conservative development timeline
• Focus on quality over speed
• Build strong community early
• Establish OÜ for legal protection

Post-Mainnet Transition:

• Transaction fees replace hardware revenue
• DAO treasury provides funding
• Community controls development priorities

Status: Dorsium is proudly community-funded, proving decentralization starts from day one, not after VCs exit.

Quality Assurance & Development Standards

Dorsium follows industry-leading development practices to ensure platform reliability and security.

Development Approach

• Agile Methodology: Iterative development with continuous improvement
• Code Review Process: Mandatory peer review for all code changes
• Automated Testing: Comprehensive test suite covering critical paths
• Continuous Integration: Automated testing on every commit

Pre-Mainnet Quality Standards

• Security Audit: External security audit by Certik or Halborn (Q4 2025 or Q1 2026)
• Penetration Testing: Third-party security assessment
• Load Testing: Network stress testing at 10x expected capacity
• Test Coverage Goal: 80% code coverage before mainnet launch

Post-Mainnet Monitoring

• Real-time Alerts: Automated monitoring for network anomalies
• Performance Metrics: Transaction latency, block time, node uptime
• Community Bug Bounty: Rewards for security vulnerability reports
• Quarterly Audits: Regular security reviews throughout lifecycle

Economic Security

Attack Cost Analysis

• 51% Attack: Requires control of all three tiers
• Sybil Attack: Personal verification barrier
• Economic Attack: Limited by vesting and caps
• Technical Attack: Multi-layer consensus protection

Banking Partnership

Dorsium is establishing banking relationships to enable fiat-crypto conversion and regulatory compliance.

Core Services

• Fiat Gateway: EUR to DORS conversion via bank transfer
• KYC/AML: Basic identity verification for Node/Validator purchases
• Compliance: MiCA-compliant operations in EU

Roadmap

• Q4 2025: Banking partner selection
• Q1 2026: Fiat gateway launch
• Q2 2026: Additional payment methods

Note: Full banking services subject to regulatory approval and market demand.

Phase 1: Foundation (Q1-Q2 2025)

• Private validator & node campaigns
• Website launch
• Registration system
• Referral infrastructure

Phase 2: Launch (Q3-Q4 2025) - CURRENT

• Public campaigns
• Mobile app alpha
• Mining protocol v1
• Hardware onboarding
• Testnet launch (December 2025)

Phase 3: Mainnet (Q1-Q2 2026)

• Mainnet deployment
• NFT reward system
• Token utility activation
• First dApp integrations
• Global mining expansion

Phase 4: Ecosystem (Q3-Q4 2026)

• Developer SDK release
• DAO governance portal
• Enhanced mobile mining efficiency
• Validator reputation system
• Archive Engine launch

Phase 5: Maturity (2027+)

• DEX strategy evaluation
• Community-driven development
• Enterprise partnerships
• Global market presence
• Full ecosystem autonomy

Milestone Triggers

Technical Milestones

• 100,000 active miners → First halving activation
• Network stability at high load → Infrastructure scaling
• 100+ active validators → Enhanced network security

Business Milestones

• 10 dApps on Dorsium chain → SDK public release
• 1 million registered users → Major partnership announcements
• Users from 50+ countries → Regional expansion programs

Regulatory Framework

MiCA Compliance

Dorsium is designed as a utility token under EU Markets in Crypto-Assets Regulation:

• Utility Function: Network access and services
• Non-Financial: Not a security or investment
• No ROI Promise: No return expectations
• Decentralized: No single point of control

Prohibited Activities

• Speculative marketing
• Price predictions
• Investment advice
• Unregistered securities offering

Utility Token Characteristics

DORS tokens are EXCLUSIVELY utility tokens that:

• Provide mandatory access to network services (cannot use network without DORS)
• Have no profit-sharing mechanism
• Generate no passive income (mining requires active work)
• Cannot be staked for returns (holding requirements are anti-spam only)
• Derive value solely from network usage demand

Corporate Structure

Current Status

• Initial Structure: Romanian PFA (Authorized Natural Person) for bootstrap phase
• Purpose: Pre-mainnet hardware distribution and development
• Transition: Estonian OÜ formation planned (Q4 2025, contingent on operational milestones)

Intellectual Property Management

Trademark Ownership:

• Current Holder: Project founder (Grávuj Miklós Henrich)
• Registration: EUIPO (EU Trademark Office), 10-year renewable
• Status: Secured for Dorsium name and logo

DAO Transition Commitment: Upon DAO governance activation (Phase 3, 2027+), founder SHALL transfer trademark ownership to DAO-controlled legal entity through the following binding process:

1. Transfer Trigger: When Phase 3 milestones met (10K miners, 500 hardware owners, 50 proposals, 12 months Phase 2 stability)
2. Transfer Price: Fair market value as determined by independent EUIPO trademark valuation
3. Payment Source: DAO treasury funds the purchase
4. Timeline: Transfer completed within 6 months of Phase 3 activation
5. DAO Approval Required: Community votes to authorize payment and accept terms (75% approval + 10% quorum)

Interim License (OÜ Phase: 2025-2027):

• Founder grants Dorsium OÜ exclusive 2-year license to operate under Dorsium brand
• License terminates upon trademark transfer to DAO entity

DAO-Controlled Entity:

• Entity type: Estonian OÜ or Swiss Foundation (determined by DAO vote)
• Board members: Elected annually by DAO token-weighted voting
• Board authority: Operational decisions (renewals, enforcement)
• Major decisions: Require DAO approval (sale, exclusive licenses, rebranding)

Legal Enforcement:

• Binding commitment documented before OÜ formation (Q4 2025)
• Agreement publicly disclosed before testnet launch (December 2025)
• Dispute resolution: Estonian courts (OÜ jurisdiction)

Why This Structure:

1. Founder Reward: Fair market value protects trademark investment
2. Community Control: DAO buys and owns brand after paying fair price
3. Operational Continuity: 2-year license ensures business operations during transition
4. No Exit Risk: Binding commitment prevents founder from retaining control indefinitely

Future Structure

• Operating Entity: Estonian OÜ (Q4 2025)
• Foundation: Swiss non-profit (future consideration, 2027+)
• DAO: Ultimate governance and IP ownership (2027+)

Data Protection

GDPR Compliance

• Minimal data collection
• User consent required
• Right to deletion
• Data encryption
• Regular audits

KYC/AML

• Node/Validator hardware purchases: Full KYC required
• Mining participation: Basic email verification only
• EU-compliant provider

Data Retention (GDPR Compliance):

• Retention period: 2 years from last mining activity
• Automatic deletion after 2 years (unless active legal dispute)
• User can request early deletion (subject to regulatory audit requirements)
• Encrypted backups retained for 90 days post-deletion
• No data sharing with third parties (except KYC provider for verification)

Disclaimers

Investment Risk: DORS tokens are utility tokens, not investments. The network utility demand may fluctuate. Never invest more than you can afford to lose.

No Guarantees: The project makes no guarantees about future development, network utility demand, or platform success.

Regulatory Changes: Cryptocurrency regulations may change. Users are responsible for compliance with local laws.

Technical Risks: Blockchain technology carries inherent risks including potential bugs, attacks, or failures.

Legal Opinion: MiCA Compliance

Token Classification

DORS is designed as a utility token under EU Markets in Crypto-Assets Regulation (MiCA).

Utility Token Definition (MiCA Article 3(1)(5)):

"A type of crypto-asset that is intended to provide digital access to a good or service, available on distributed ledger technology, and is only accepted by the issuer of that token."

Dorsium Compliance Analysis:

Primary Function: Network Access

• Transaction processing (fees required)
• Smart contract execution (fees required)
• Data storage (proportional fees)
• dApp service payments (utility function)
• Governance participation (voting rights)

NOT a Security Token:

• No profit-sharing mechanism
• No dividend payments or distributions
• No equity representation in company
• No debt instrument or loan structure
• No investment contract (Howey Test fails)

NOT an Asset-Referenced Token:

• Not backed by fiat currency reserves
• Not backed by commodities
• Not backed by other crypto-assets
• Value derives solely from utility demand

Mining Rewards = Work Rewards

Legal Framework: Mining rewards compensate network validation work, not passive investment returns.

Distinction from Investment:

Legal Precedent:

• Bitcoin mining: Accepted as work-for-pay globally
• Ethereum pre-PoS mining: Not classified as security
• EU/US legal framework: Mining = labor reward
• MiCA guidance: Utility distribution for contribution = compliant

Referral System = Community Building

Legal Framework: Referral bonuses compensate community growth efforts (education, support, outreach), not passive recruitment.

Distinction from MLM/Pyramid:

Compliance Safeguards:

• Referral bonuses capped to prevent pyramid structure
• Active participation required (not passive)
• Utility token distribution, not financial product sales
• Education/support work is compensated activity
• Real network value created (security through distribution)

Regulatory Declarations

1. No Investment Advice: This whitepaper does not constitute investment, financial, or tax advice. DORS tokens are utility tokens providing network access, not investments or financial products.

2. No Price Predictions: Any numerical examples are illustrative only for understanding utility reward rates. Actual token value determined by free market forces based on utility demand.

3. No Return Guarantee: Mining reward rates are for network validation work. No guaranteed returns, profits, or financial gains are promised or implied.

4. Regulatory Compliance Commitment: Dorsium commits to ongoing compliance with MiCA and all applicable EU cryptocurrency regulations. Regular legal reviews ensure continued alignment.

5. Legal Jurisdiction: All disputes subject to Estonian law (Dorsium OÜ registered in Estonia, EU).

Risk Disclosure

Users Must Understand:

⚠️ DORS tokens are NOT investments

• Designed for network utility, not financial returns
• Value may fluctuate based on utility demand
• No guaranteed liquidity or exchange listings

⚠️ Regulatory Risk

• Cryptocurrency regulations may change
• Users responsible for local legal compliance
• Tax obligations vary by jurisdiction

⚠️ Technical Risk

• Blockchain technology carries inherent risks
• Potential bugs, attacks, or failures possible
• Smart contract risks post-mainnet

⚠️ No Profit Promise

• Mining compensates work, not investment
• Token utility determines value, not speculation
• Market forces determine exchangeability

Third-Party Legal Review

Status: Legal opinion sought from EU-licensed crypto law firm (Q4 2025)

Purpose: Independent verification of MiCA compliance before mainnet launch

Commitment: Whitepaper adjustments as needed based on professional legal guidance

Review Cycle: Quarterly legal compliance reviews to reflect regulatory evolution

Document Information:

• Last Updated: November 2, 2025
• Prepared By: Dorsium Legal Team
• Next Review: February 1, 2026
• Legal Counsel: [To be appointed Q4 2025]

Development Timeline

Q1 2025: Concept development, HDC mechanism design Q2 2025: Private validator/node campaigns (30 participants) Q3 2025: Public launch, deterministic backend scripts, mobile app alpha Q4 2025: Testnet launch (upcoming)

Key Innovations

• Hierarchical Delegated Consensus: Energy-efficient alternative to PoW/PoS
• Pre-Mainnet Reward System: Deterministic backend scripts with full auditability
• Mobile-First Mining: Accessibility without special hardware

Core Philosophy

Dorsium was built to solve three problems:

1. High barriers to crypto participation
2. Energy-intensive consensus mechanisms
3. Lack of real token utility

The project prioritizes accessibility and fairness over pure technical metrics, aiming to enable blockchain participation for everyone, not just the technically savvy or wealthy.

Technical Risks

• HDC untested at scale (testnet validates in Q4 2025)
• Partition recovery assumes reliable VPS infrastructure
• Smart contract bugs possible (mitigated by external audit)

Operational Risks

• Founder-dependent pre-mainnet (single point of failure until Q1 2026)
• Hardware sales centralized (KYC compliance trade-off)

Regulatory Risks

• MiCA regulation may evolve (ongoing legal review commitment)
• Country-specific crypto bans unpredictable
• KYC requirements may tighten (compliance team monitoring)

Market Risks

• No exchange listings promised (organic market development)
• Community growth may be slower than projected

Mitigation Strategies

• Quarterly transparency reports
• External security audits (Q4 2025)
• Governance transition milestones (community-controlled)
• Legal counsel engagement (Q4 2025)

Dorsium solves the accessibility problem of blockchain technology through mobile mining, HDC consensus, and transparent governance. With 30 early adopters already onboard and mainnet launching in Q1 2026, we're building the infrastructure for mass blockchain adoption.

Our technical innovations - from deterministic backend scripts to three-tier consensus - ensure scalability without sacrificing decentralization. The 40 billion DORS supply, vesting mechanisms, and halving schedule create sustainable economics for long-term growth.

Join us as we build toward 100,000 miners, deploy the first dApps, and transition to full DAO governance. Your role - whether miner, node operator, validator, or developer - shapes Dorsium's future.

"We're building slow to build strong."

A. Technical Specifications

Blockchain Parameters

• Block size limit: Maximum 512 KB per block
• Transaction limit: Maximum 1000 transactions per block
• Transaction size: 250KB maximum per transaction
• Block assembly timeout: 30-60 seconds adaptive
• Signature algorithm: Ed25519 (primary), Secp256k1 (compatibility)
• Hash function: SHA-256 for all cryptographic operations
• Network protocol: TCP/IP with TLS 1.3
• Consensus finality: Instant (single-slot finality)

Transaction Identification

• TXID Generation Formula:

  TXID = SHA-256(sender_address || receiver_address || amount || token_symbol || timestamp || nonce)
  

• TXID Format: 64-character hexadecimal string
• Collision Prevention: Timestamp + nonce ensures uniqueness
• Indexing: Primary index on TXID for O(1) lookup

Consensus Parameters

• Miner Consensus Threshold: 67% (2/3 majority)
• Node Consensus Threshold: 67% (2/3 majority)
• Validator Consensus Threshold: 67% (2/3 majority)
• Timeout Settings:
  • Propose: 3 seconds
  • Prevote: 1 second
  • Precommit: 1 second
  • Commit: immediate
• Byzantine Fault Tolerance: Up to 33% malicious actors per tier

Performance Targets & Roadmap

Dorsium's performance capabilities will scale through phased optimization. Note: These are ESTIMATED targets based on Cosmos SDK baseline performance and HDC architectural analysis. Actual performance will be validated through testnet load testing (December 2025).

Cosmos SDK Baseline Performance:

• Single-tier consensus: 1,000-10,000 TPS (proven in production)
• BFT overhead: ~30% throughput reduction per consensus layer

HDC Theoretical Performance:

• Three-tier validation = 3x BFT overhead (compounding latency)
• Estimated throughput reduction: 70-80% vs. single-tier Cosmos SDK
• Calculated range: 200-3,000 TPS (depending on optimization)

Phase 1: Testnet (Q4 2025)

• Target: 50-100 TPS
• Goal: Stability testing, not performance optimization
• Validators: 20-50
• Status: Load testing planned for December 2025

Phase 2: Mainnet Launch (Q1 2026)

• Target: 100-300 TPS
• Goal: Production-ready with proven stability
• Validators: 100+
• Improvements: Optimized gossip protocol, efficient state management

Phase 3: Optimization (Q2-Q4 2026)

• Target: 300-1,000 TPS
• Validators: 150-200
• Improvements:
  • Parallel transaction processing
  • State pruning
  • Signature verification batching
  • Database query optimization

Phase 4: Scale (2027+)

• Target: 1,000+ TPS (aspirational, subject to real-world testing)
• Validators: 200-300
• Requirements:
  • Archive nodes (full historical data)
  • Potential sharding implementation
  • Cross-chain bridges (future consideration)

Why Conservative Estimates?

1. HDC is untested at scale - no production deployment yet
2. Three-tier consensus is slower than single-tier by design (security priority)
3. Better to under-promise and exceed expectations than overpromise and disappoint

Validation Plan:

• Testnet load testing: December 2025 - January 2026
• Results published: February 2026 (before mainnet launch)
• Performance targets adjusted based on actual testnet data

Comparison (Launch Performance):

Transparency Commitment:

• All testnet performance data will be publicly released
• No cherry-picked benchmarks - full results including failures
• Community can verify testnet performance via public explorer

B. Contact Information

• Website: dorsium.com↗
• Email: hello@dorsium.com

C. Glossary

• HDC: Hierarchical Delegated Consensus
• DORS: Dorsium utility token
• dApp: Decentralized application
• TVL: Total Value Locked
• DAO: Decentralized Autonomous Organization
• MiCA: Markets in Crypto-Assets Regulation
• BFT: Byzantine Fault Tolerance
• TPS: Transactions Per Second

D. Go-to-Market Strategy

Campaign Phases

Phase 1: Foundation Building (Q1-Q3 2025)

• Target: Early adopters and crypto enthusiasts
• Channels: Crypto communities, forums, social media
• Incentives: Early adopter rewards, exclusive NFTs
• Goal: 30 registered users

Phase 2: Community Expansion (Q4 2025)

• Target: Broader crypto community
• Channels: Influencer partnerships, content marketing
• Incentives: Referral bonuses, multiplier rewards
• Goal: 3,000 registered users

Phase 3: Mainstream Adoption (Q1-Q2 2026)

• Target: General public interested in crypto
• Channels: App store featuring, PR campaigns
• Incentives: Simplified onboarding, educational content
• Goal: 25.000 registered users

Phase 4: Global Scaling (Q3 2026+)

• Target: International markets
• Channels: Regional partnerships, localization
• Incentives: Regional campaigns, local payment methods
• Goal: 500.000+ users

Early-Bird Strategies

Mobile Miner Launch

• First 1000 Users: Early Adopter NFT + 10 DORS
• First 10,000 Users: Launch Pioneer badge
• First 100,000 Users: Genesis Community status

Community Building Approach

Core Principles

1. Transparency First: Regular updates and open communication
2. Community Ownership: Real influence on project direction
3. Value Creation: Focus on utility over speculation
4. Education: Comprehensive learning resources
5. Inclusivity: Accessible to all skill levels

Engagement Strategies

• Weekly AMAs: Direct team communication
• Community Challenges: Gamified participation
• Ambassador Program: Regional community leaders
• Developer Grants: Funding for ecosystem projects
• Bug Bounties: Security-focused community involvement

Content Strategy

• Educational Series: Blockchain basics to advanced topics
• Use Case Demonstrations: Real-world applications
• Success Stories: Community member highlights
• Technical Deep Dives: For developer audience
• Market Updates: Regular ecosystem reports

Partnership Development

• Strategic Alliances: Complementary projects
• Exchange Relationships: Early listing discussions
• Institutional Outreach: Enterprise adoption
• Academic Collaboration: Research partnerships
• Regional Partners: Local market penetration

E. References

1. Cosmos SDK Documentation
2. CometBFT Consensus Papers
3. MiCA Regulatory Framework
4. NIST Post-Quantum Cryptography
5. Byzantine Generals Problem (Lamport, 1982)

F. Threat Model & Attack Cost Analysis

Key Insight: The combination of KYC requirements, video verification, and three-tier consensus makes Dorsium's attack cost comparable to much larger networks, despite lower hardware costs.

G. Mathematical Security Proof

Byzantine Fault Tolerance Guarantee

HDC implements BFT consensus at each tier with the following mathematical guarantees:

Theorem: A system with n validators can tolerate up to f Byzantine (malicious) validators where:

f < n/3

For Dorsium with n=100 validators per tier:

• Maximum Byzantine nodes: f = 33
• Honest majority required: 67+ validators
• Attack success probability: P(attack) ≈ 0 when f < 34

Proof of Multi-Tier Security:

For an attacker to compromise the network across all three tiers:

P(success) = P(Mobile) × P(Node) × P(Validator) ≈ 0 × 0 × 0 = 0

Where:

• P(Mobile) ≈ 0 (KYC makes mass fake accounts infeasible)
• P(Node) ≈ 0 (Video KYC + €21,590 cost)
• P(Validator) ≈ 0 (Video KYC + €32,300 cost)

Economic Security Threshold:

Minimum attack cost C for 34% control across all tiers:

C = (0.34 × 100 × €635) + (0.34 × 100 × €950) + KYC_bypass_cost
= €21,590 + €32,300 + ∞ (KYC practically impossible at scale)
≈ €53,890+

Conclusion: HDC's security is not just probabilistic (like PoW) but also identity-bound (like PoA), making it resistant to both economic and Sybil attacks.

© 2025 Dorsium. All rights reserved.