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 Name | Simha Fintech sp. z o.o. |
| Country of Registration | Republic of Poland (EU) |
| KRS Number | 0001017042 |
| NIP (Tax ID) | 6762635441 |
| REGON | 524376440 |
| Legal Form | Spółka z ograniczoną odpowiedzialnością (LLC) |
| Registered Address | Kraków, Poland |
| e-Delivery Address (ADE) | AE:PL-55004-94640-IGCES-27 |
| Share Capital Status | Fully 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)
| Function | Computational work generation system |
| Output | SIMHA Reward Units (SRU) - Not immediately liquid |
| Design Principle | Separates "earned work" from "liquid token" to prevent inflation chaos. |
SIMHA NODE (Validation Layer)
| Function | Transaction validation and block verification |
| Role | Nodes filter inflation; they do not simply validate. |
SIMHA CORE (Settlement Layer)
| Function | Converts SRU → SIMHA token issuance |
| Key Mechanism | "Monetary Policy Engine" - Controls emission rate and applies difficulty adjustment. |
SIMHA VAULT (Staking Layer)
| Function | Lock SIMHA tokens to provide yield and stability |
| Design Goal | Acts as "liquidity sink" to create locked supply growth over inflation. |
SIMHA AI (Intelligence Layer)
| Function | Optimizes mining efficiency and adjusts reward distribution |
| Controls | Hash difficulty tuning, Vault APY, anti-manipulation detection. |
SIMHA DAO (Governance Layer)
| Function | Community governance system |
| Critical Constraint | DAO cannot directly mint tokens; it only adjusts parameters within CORE limits. |
SIMHA BRIDGE (Cross-Chain Layer)
| Function | Connect SIMHA to external chains (ETH, BNB) |
| Safety Design | Bridge 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 Model | NONE - Fixed Supply Cap |
| Circulating at Launch (TGE) | 5-10% (~500M - 1B SIMHA) |
Allocation Structure
| 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 1 | 20% | 800,000,000 | 800,000,000 |
| Year 2 | 18% | 720,000,000 | 1,520,000,000 |
| Year 3 | 15% | 600,000,000 | 2,120,000,000 |
| Year 4 | 12% | 480,000,000 | 2,600,000,000 |
| Year 5 | 10% | 400,000,000 | 3,000,000,000 |
| Year 6 | 8% | 320,000,000 | 3,320,000,000 |
| Year 7 | 6% | 240,000,000 | 3,560,000,000 |
| Year 8 | 5% | 200,000,000 | 3,760,000,000 |
| Year 9 | 3% | 120,000,000 | 3,880,000,000 |
| Year 10 | 3% | 120,000,000 | 4,000,000,000 |
Emission Visualization
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 Lock | 6–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 Lock | 80%+ | <50% |
| Staking Ratio | 40–60% | <20% |
| Inflation Rate | Decreasing yearly | Increasing |
| Active Wallet Growth | Increasing | Stagnant |
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 information | READY |
| Art. 5(1)(b) | Crypto-asset description | READY |
| Art. 5(1)(c) | Consensus mechanism | READY |
| Art. 5(1)(d) | Rights and obligations | READY |
| Art. 5(1)(e) | Technology & governance | READY |
| Art. 5(1)(f) | Token distribution | READY |
| Art. 5(1)(g) | Risk disclosures | READY |
| Art. 4 | Notification to Authority | PENDING LAUNCH |