MiCA PRE-AUDIT DOCUMENTATION

SIMHA Ecosystem Tokenomics

Pre-Compliance Review & Technical Specification

Document Version

1.0.0-DRAFT

Document Type

DRAFT / PRE-AUDIT

Target Authority

KNF (Poland)

Investor Launch

24 May 2025

Public Launch

Q4 2025 (Est.)

Executive Summary

This document serves as the Pre-Audit Technical Specification for the SIMHA Mining Ecosystem, prepared for internal compliance review and prospective MiCA notification. SIMHA is designed as a self-regulating digital economy, structured around computational mining, decentralized validation, staking-driven stability, AI-based optimization, and DAO governance.

Regulatory Classification (Proposed)

SIMHA is intended to be classified as a Utility Token under MiCA Article 2(5). It provides access to the SIMHA ecosystem services, including mining conversion, network validation, and governance. It does not represent equity, debt, or a claim on issuer assets.

Core Vision

"To create a mining-driven, AI-optimized blockchain ecosystem where value is continuously generated, validated, stabilized, and governed through interconnected protocol layers."

Issuer Information Summary

Legal Entity Name Simha Fintech sp. z o.o.
Jurisdiction Republic of Poland (EU)
KRS Number 0001017042
NIP (Tax ID) 6762635441
Target Competent Authority Komisja Nadzoru Finansowego (KNF)
Document Status DRAFT FOR INTERNAL REVIEW

Detailed Issuer Information

Legal Entity Details
Registered Legal NameSimha Fintech sp. z o.o.
Country of RegistrationRepublic of Poland (EU)
KRS Number0001017042
NIP (Tax ID)6762635441
REGON524376440
Legal FormSpółka z ograniczoną odpowiedzialnością (LLC)
Registered AddressKraków, Poland
e-Delivery Address (ADE)AE:PL-55004-94640-IGCES-27
Share Capital StatusFully Paid

Protocol Architecture

System Flow Model

MINING (HASH)
   ↓ Generates Work
SRU (Internal Reward Unit)
   ↓
VALIDATION (NODE)
   ↓ Secures Network
CORE (Emission Control Engine)
   ↓ Converts SRU to SIMHA
SIMHA TOKEN (Circulation)
   ↓
VAULT (Staking / Locking)
   ↓ Reduces Supply Pressure
DAO (Governance Decisions)
   ↓ Controls Parameters
AI (Optimization Layer)
   ↓ Balances System
BRIDGE (External Expansion)
   ↺ Feeds back demand
          

Layer Definitions

SIMHA HASH (Production Layer)

FunctionComputational work generation system
OutputSIMHA Reward Units (SRU) - Not immediately liquid
Design PrincipleSeparates "earned work" from "liquid token" to prevent inflation chaos.

SIMHA NODE (Validation Layer)

FunctionTransaction validation and block verification
RoleNodes filter inflation; they do not simply validate.

SIMHA CORE (Settlement Layer)

FunctionConverts SRU → SIMHA token issuance
Key Mechanism"Monetary Policy Engine" - Controls emission rate and applies difficulty adjustment.

SIMHA VAULT (Staking Layer)

FunctionLock SIMHA tokens to provide yield and stability
Design GoalActs as "liquidity sink" to create locked supply growth over inflation.

SIMHA AI (Intelligence Layer)

FunctionOptimizes mining efficiency and adjusts reward distribution
ControlsHash difficulty tuning, Vault APY, anti-manipulation detection.

SIMHA DAO (Governance Layer)

FunctionCommunity governance system
Critical ConstraintDAO cannot directly mint tokens; it only adjusts parameters within CORE limits.

SIMHA BRIDGE (Cross-Chain Layer)

FunctionConnect SIMHA to external chains (ETH, BNB)
Safety DesignBridge does NOT mint new supply; it only wraps CORE-issued SIMHA.

Smart Contract Architecture

The SIMHA ecosystem uses a modular contract system. Below are the simplified skeletons for audit review.

1. SIMHA Token Contract (ERC-20 Base)

// Fixed supply, minting controlled by CORE only
contract SIMHAToken is ERC20 {
    address public coreContract;
    address public owner;

    constructor() ERC20("SIMHA", "SIMH") {
        _mint(msg.sender, 10_000_000_000 * 10**18);
    }

    modifier onlyCore() {
        require(msg.sender == coreContract, "Not CORE");
        _;
    }

    // Minting ONLY controlled by CORE
    function mint(address to, uint amount) external onlyCore {
        _mint(to, amount);
    }
}

2. SIMHA CORE Contract (Economic Engine)

// Converts SRU to SIMHA based on emission rules
contract SIMHACore {
    SIMHAToken public token;
    uint public emissionRate;
    uint public totalMinted;

    function convertSRU(address miner, uint sruAmount) external {
        uint reward = calculateReward(sruAmount);
        require(totalMinted + reward <= MAX_SUPPLY, "Cap reached");
        token.mint(miner, reward);
        totalMinted += reward;
    }

    function adjustEmission(uint newRate) external onlyDAO {
        emissionRate = newRate;
    }
}

3. SIMHA HASH Contract (Mining Layer)

contract SIMHAHash {
    mapping(address => uint) public minerPower;

    function submitWork(uint workHash) external {
        require(validate(workHash), "Invalid work");
        minerPower[msg.sender] += computeSRU(workHash);
    }
}

4. SIMHA VAULT Contract (Staking)

contract SIMHAVault {
    mapping(address => uint) public stakes;

    function stake(uint amount) external {
        stakes[msg.sender] += amount;
    }

    function calculateAPY(address user) public view returns (uint) {
        return stakes[user] * 10 / 100; // Example 10% APY
    }
}

Tokenomics Model

Supply Overview

Supply Metrics
Total Supply (Fixed)10,000,000,000 SIMHA
Inflation ModelNONE - Fixed Supply Cap
Circulating at Launch (TGE)5-10% (~500M - 1B SIMHA)

Allocation Structure

40%
20%
15%
10%
5%
10%
Category Percentage Amount Purpose
SIMHA HASH (Mining Rewards) 40% 4,000,000,000 Network security + miner incentives
SIMHA VAULT (Staking) 20% 2,000,000,000 Staking rewards + liquidity lock
Ecosystem + Development 15% 1,500,000,000 Protocol development + infrastructure
DAO Treasury 10% 1,000,000,000 Governance-controlled funds
Bridge Reserve 5% 500,000,000 Cross-chain liquidity stability
Team + Founders 10% 1,000,000,000 Long-term team alignment (4-year vesting)

Emission Model

Controlled Emission Philosophy

Miners never receive tokens directly. Flow: Miners → SRU (Internal Unit) → CORE → Token Release. This prevents inflation collapse.

Mining Reward Release Schedule (Decay Model)

Allocation: 4,000,000,000 SIMHA (40% of Total Supply)

Year % Released Annual Emission Cumulative
Year 120%800,000,000800,000,000
Year 218%720,000,0001,520,000,000
Year 315%600,000,0002,120,000,000
Year 412%480,000,0002,600,000,000
Year 510%400,000,0003,000,000,000
Year 68%320,000,0003,320,000,000
Year 76%240,000,0003,560,000,000
Year 85%200,000,0003,760,000,000
Year 93%120,000,0003,880,000,000
Year 103%120,000,0004,000,000,000

Emission Visualization

Year 1800M
20%
Year 2720M
18%
Year 3600M
15%
Year 4480M
12%
Year 5400M
10%

Launch Roadmap

Timeline

Investor Launch

24 May 2025

Private sale, initial liquidity deployment, TGE.

Public Launch

Q4 2025 (Est.)

Post-MiCA approval, CEX listings, full ecosystem activation.

Phase Breakdown

Phase 0: Pre-Launch (Audit & Security)

  • Smart contract finalization (Token, Core, Vault, Hash, DAO)
  • Full audit completion (Minimum 1-2 firms)
  • Liquidity allocation setup
  • Token vesting contracts locked

Phase 1: Initial Liquidity Deployment (Investor Launch)

  • Seed Liquidity Pool on DEX (Uniswap/PancakeSwap)
  • Pair: SIMHA/USDT or SIMHA/ETH
  • Initial LP Size: $100,000 – $500,000
  • LP Lock: 12–24 months (Investor-grade trust)

Phase 2: Token Generation Event (TGE)

  • Circulating Supply: Only 5–10%
  • Trading enabled on DEX
  • Mining (HASH) activated with capped emissions
  • VAULT staking opens within 24–48h

Phase 3: Stability & Expansion (Post-Launch)

  • Increase LP depth gradually
  • Add SIMHA/USDC pair
  • DAO governance activation
  • Cross-chain Bridge activation (wSIMHA)

Initial Market Parameters

Target Initial Market Cap$3M – $5M
Launch Price Range$0.0003 – $0.0006
Liquidity Lock6–12 months minimum
Max Wallet Cap (Anti-Whale)1–2% supply (first 48–72h)

Risk Analysis

Critical Failure Modes

Project Killers

The following risks are the most critical to the SIMHA ecosystem.

1. Liquidity Failure

Symptom: Thin liquidity pool, early dump, no price floor.

Prevention: Lock LP 12–24 months, increase stablecoin depth, avoid over-distribution at launch.

2. Emission Overload (Inflation Death)

Symptom: Too many SIMHA released via mining, Supply > Demand.

Prevention: CORE-controlled emission caps, Decay-based mining, VAULT locking pressure.

3. Low Staking Adoption

Symptom: Users don't lock tokens, high circulating supply.

Prevention: High APY early-stage, bonus mining rewards for stakers, DAO power tied to VAULT.

4. Bridge Exploit Risk

Symptom: Cross-chain bridge hacked → supply inflation.

Prevention: Multi-sig bridge control, time-locked transfers, capped daily bridge volume.

System Health Metrics

Metric Healthy Range Warning Sign
Liquidity Lock80%+<50%
Staking Ratio40–60%<20%
Inflation RateDecreasing yearlyIncreasing
Active Wallet GrowthIncreasingStagnant

Compliance & Audit Preparation

Smart Contract Audit Checklist

Token Contract Checks

  • Unauthorized mint function exists outside CORE
  • No max supply enforcement at contract level
  • Owner can bypass emission rules
  • Mint ONLY via CORE contract
  • Hard cap enforced (10B immutable)

Core Contract Checks

  • Unrestricted emission rate changes
  • Missing DAO timelock
  • Infinite mint loop risk
  • DAO timelock (24–72h)
  • Emission caps per block/year

Bridge Contract Checks (High Risk)

  • Double minting attack vector
  • Cross-chain replay attack
  • Multi-signature validator set
  • Mint/burn symmetry enforcement
  • Daily transfer caps

MiCA Compliance Matrix (Preliminary)

Article Requirement Status
Art. 5(1)(a)Issuer informationREADY
Art. 5(1)(b)Crypto-asset descriptionREADY
Art. 5(1)(c)Consensus mechanismREADY
Art. 5(1)(d)Rights and obligationsREADY
Art. 5(1)(e)Technology & governanceREADY
Art. 5(1)(f)Token distributionREADY
Art. 5(1)(g)Risk disclosuresREADY
Art. 4Notification to AuthorityPENDING LAUNCH