ninacatcoin crypto new

VISIT www.ninacatcoin.es

https://niapool.ninacatcoin.es/

https://niachain.ninacatcoin.es/

https://github.com/ninacatcoin/ninacatcoin

https://x.com/ninacatcoin

http://discord.gg/U8Mtn2c3ru

NINACATCOIN WHITE PAPER

Version 2.0 — February 2026

Table of Contents

1. Preface: History and Meaning
2. Vision and Purpose
3. The Genesis Block
4. Emission Model: Halving and Rewards
5. High-Entropy Events: X2 and X200
6. Difficulty Algorithm: LWMA-1
7. Network Fees
8. Privacy and Anonymity
9. Enhanced RandomX Mining
10. Automatic Checkpoints: 51% Defense
11. Checkpoint Corruption Detection and Auto-Repair
12. Precomputed Block Hashes: checkpoints.dat
13. Intelligent Validation Enhancements
14. Discord Bot: Real-Time Events
15. Block Explorer
16. Technical Architecture
17. Roadmap and Future Development
18. Embedded Mini AI: NINA Intelligence Engine

1. Preface: History and Meaning

Project Origins

Ninacatcoin was born from the Monero codebase, one of the most respected cryptocurrency projects in terms of privacy and decentralization. Just as Monero was based on the CryptoNote protocol, Ninacatcoin uses Monero's solid, battle-tested architecture as its foundation, implementing fundamental improvements in several critical areas:

Anti-51% security: Automatic checkpoints every 60 minutes vs manual checkpoints updated every 6–12 months in Monero
Mining fairness: Enhanced RandomX with GPU penalty to prevent mining monopolies
Transparent emissions: X2 and X200 high-entropy events with anti-manipulation mechanisms
Real decentralization: No manual intervention required in critical processes
Rapid difficulty adjustment: LWMA-1 algorithm reacts within blocks, not days or weeks

This project respects and acknowledges the work of the Monero community as a technical foundation, while implementing an alternative vision of how a private cryptocurrency should operate. Monero represents the gold standard in privacy-focused cryptocurrencies, but several design choices — particularly around manual checkpoints, difficulty adjustment speed, and mining reward predictability — left room for meaningful improvement. Ninacatcoin fills these gaps while preserving privacy, fungibility, and resistance to surveillance.

The Name: Ninacatcoin

The name "Ninacat" is a direct, deeply personal tribute — it comes from the loss of a beloved companion: a cat named Nina who was the most fun, friendly, and joyful being anyone could meet.

Nina was synonymous with qualities that every cryptocurrency should embody:

Kindness: Always friendly with everyone — just as Ninacatcoin treats all miners equally
Generosity: She brought joy without asking for anything — just as X2/X200 events randomly reward miners
Fun: She constantly brought laughter — Ninacatcoin brings excitement to an otherwise deterministic process
Unconditional companionship: Present in difficult times — Ninacatcoin's automatic systems keep running even under attack

Her memory is immutably recorded in the blockchain — carved into the genesis block where it can never be erased.

In the genesis block (height 0), there is an engraved message dedicated to Nina:

Code:

const char kDefaultGenesisMsg[] =
  "Ninacat[Suspicious link removed]DBYE  "
  "No pude protegerte entonces, pero ahora voy a crear algo que se defienda solo y sea justo. "
  "I couldn't protect you back then, but now I am creating something that can defend itself and be fair.";

Element	Meaning
25/05/2014	Nina's birth date
16/02/2019	Date of passing
GOODBYE	Final farewell
"I couldn't protect you..."	A promise to create something fair and self-sufficient

Nina's Legacy: The X2 and X200 Events

Nina's kindness directly inspired the X2 and X200 event system. Nina gave without expecting anything in return, unpredictably, to everyone equally. That is what Ninacatcoin does — generously rewarding miners with random bonus payments:

X2 (Reward Doubler): Occurs ~183 times per year. A lucky miner receives 2x the base reward.
X200 (Special Multiplier): Occurs ~6 times per year. A miner receives 200x the base reward — a moment of extraordinary generosity.

Code:

NINA'S PHILOSOPHY           →  NINACATCOIN'S PHILOSOPHY
Generous kindness            →  Generous rewards (X2, X200)
Surprise love                →  Surprise events in mining
No predictable pattern       →  Fair random distribution
Everyone deserves the best   →  All miners can win, regardless of hashrate

A single CPU miner has the same percentage chance of receiving an X200 reward as a large farm. The probability is per block, not per miner.

The Hidden Secret: The Impossible Event (Simultaneous X2 + X200)

There is an infinitesimal probability that both X2 and X200 trigger on the same block — an emergent consequence of two independent systems:

Code:

Final Reward = Base Reward × 2 × 200 = Base Reward × 400x

Code:

if (is_x2_event(...)) base_reward *= 2;      // Executes independently
if (is_x200_event(...)) base_reward *= 200;  // Also executes independently
// Natural accumulation: original × 2 × 200 = original × 400

Because these are "if" statements (not "else if"), both can trigger on the same block:

Event	Probability	Frequency	Reward
X2 Only	1 in 1,400	~183 times/year	2x base
X200 Only	1 in 43,800	~6 times/year	200x base
X2 + X200	1 in ~1,432,000	~once every 5.5 years	400x base
Normal Block	~99.9%	Majority	1x base

Nina was generous without warning. Ninacatcoin honors this by allowing the protocol itself to be generous organically and unpredictably.

2. Vision and Purpose

Ninacatcoin is a private, secure, and truly decentralized cryptocurrency evolved from CryptoNote principles, inheriting ring signatures, stealth addresses, and confidential transactions while addressing key weaknesses in existing implementations.

Key innovations:

High-entropy emission events (X2 and X200) that reward miners unpredictably while maintaining strict supply bounds
Fully automatic checkpoints every 60 minutes, eliminating manual intervention
LWMA-1 difficulty algorithm reacting to hashrate changes in 3–5 blocks, not hundreds
Emergency Difficulty Adjustment (EDA) preventing network stalls after hashrate departures
Enhanced RandomX with GPU penalty and shorter epochs, keeping CPU mining viable

User fund control is ensured through:

Mandatory ring signatures in all transactions (enforced by protocol)
RingCT hiding amounts via Pedersen commitments and Bulletproof+ range proofs
Optional network anonymity via Tor, I2P, and Dandelion++ propagation
Decentralized architecture with no single points of failure

Development philosophy: security over features, automation over human intervention, fairness over efficiency, code transparency with user privacy. The team maintains an open process through GitHub and IRC (#ninacatcoin-dev).

3. The Genesis Block (Block Zero)

The genesis block paid an initial reward of 10,000 NINA, fixed and immutably defined in the chain configuration:

Code:

constexpr uint64_t GENESIS_REWARD = 10000 * COIN; // 10,000 NINA

These 10,000 NINA were immediately and permanently burned by sending them to an address for which no private key exists or can ever be derived:

Burn Address:

Code:

LmcAtBXwRf1WUEyHTYFXm7E5QhHNcGUrveXPkbFD2vC8jX1LM9kCGYCR9DUzKcPJqMKMNbP2eamG96snnvMdXqR62aNMheC

Why burned?

Total transparency: No developer retains access to the initial coins — there is no "premine"
Distribution fairness: All circulating NINA come from mining rewards, X2/X200, or fees
Immutable reference point: Block zero is the cryptographic seed of the emission system
Trust establishment: Anyone can verify the burn by checking the genesis block

The consensus layer ensures no chain variant can pay more than 10,000 NINA in block 0, and no fork can redistribute those coins.

4. Emission Model: Halving and Rewards

Base Reward and Automatic Halving

Total maximum supply: 900,000,000 NINA (nine hundred million)
Initial base reward: 4 NINA per block
Block time target: 120 seconds (2 minutes)
Halving interval: 262,800 blocks (~1 year at target block time)
Minimum reward floor: 2 NINA per block (permanent tail emission)

Halving Formula:

Code:

halvings = floor(height / 262,800)
base_reward = max(4 NINA >> halvings, 2 NINA)

Block Range	Year	Base Reward	Annual Emission
0–262,799	Year 1	4 NINA	1,051,200 NINA
262,800+	Year 2+	2 NINA	525,600 NINA

The 2 NINA Floor: Permanent Tail Emission

Unlike Bitcoin (which will eventually pay zero block rewards), Ninacatcoin maintains a permanent 2 NINA minimum. This ensures miner incentive permanence, network security regardless of fee market conditions, predictable supply growth (~525,600 NINA/year), and asymptotically decreasing inflation.

Safety Mechanisms

Soft brake: After the first halving (height 262,800), the reward stabilizes at 2 NINA per block permanently.
Hard brake: When fewer than 10,000 NINA remain to be emitted, all X2 and X200 events are disabled, ensuring the maximum supply is never exceeded.

Emission Including X2/X200 Events

Code:

X2 contribution:   183 events × 4 NINA extra = ~732 NINA/year
X200 contribution: 6 events × 796 NINA extra = ~4,776 NINA/year
Total extra:       ~5,508 NINA/year (~0.5% above base emission)

This modest acceleration is accounted for in the total supply calculations and protected by the hard brake mechanism.

5. High-Entropy Events: X2 and X200

What Are X2 and X200?

Ninacatcoin implements pseudorandom events that multiply the block reward at unpredictable intervals:

X2: Block pays 2x the base reward (e.g., 8 NINA in year 1)
X200: Block pays 200x the base reward (e.g., 800 NINA in year 1)

Expected frequency per year (~262,800 blocks):

X2: ~183 events/year (one every ~1,436 blocks, roughly every 2 days)
X200: ~6 events/year (one every ~43,800 blocks, roughly every 2 months)

These events are deterministic but unpredictable — every node calculates the same result, but no one can predict it before the previous block is mined.

Probability Calculation and Anti-Manipulation

Event detection is entirely deterministic based on the previous block hash, never on unseeded random numbers, system clocks, or external oracles:

Code:

auto get_event_roll = [&](uint8_t tag, uint64_t &out) {
    if (prev_block_hash) {
        std::array<uint8_t, sizeof(crypto::hash) + 1> buf{};
        std::memcpy(buf.data(), prev_block_hash, sizeof(crypto::hash));
        buf[sizeof(crypto::hash)] = tag;
        const crypto::hash h = crypto::cn_fast_hash(buf.data(), buf.size());
        std::memcpy(&out, &h, sizeof(uint64_t));
    }
};

Process:

Take the previous block hash (32 bytes, 256 bits)
Append an identifier tag (1 byte): tag=2 for X2, tag=200 for X200
Apply Keccak-256 (cn_fast_hash) to the combined 33-byte buffer
Extract the first 64 bits as an unsigned integer
Calculate: rnd % BLOCKS_PER_YEAR (262,800)
If result < 183 → X2 event; If result < 6 → X200 event

Why manipulation-resistant? Changing the block hash requires re-mining (full PoW), the miner doesn't know if the next block will be theirs, even with 100% hashrate the cost exceeds the expected reward, and Keccak-256 has no shortcuts.

Emission Limits

Supply limit: If already_generated_coins + (base_reward × multiplier) > MONEY_SUPPLY, the reward is reduced to exactly what remains
Hard brake: If fewer than 10,000 NINA remain, X2/X200 are completely disabled

Block at height 100 is always X2, demonstrating the system's functionality on the live network.

6. Difficulty Algorithm: LWMA-1

Target Block Time

Ninacatcoin targets a block time of 120 seconds (DIFFICULTY_TARGET_V2 = 120), producing approximately 30 blocks per hour, 720 blocks per day.

The Problem with Simple Moving Average (SMA)

The original Monero difficulty algorithm uses SMA over 720 blocks (~24 hours). It has severe limitations for smaller networks:

Slow reaction: 50% hashrate loss takes ~24 hours to adjust
Equal weighting: Old blocks influence difficulty as much as new ones
Timestamp sorting vulnerability: Manipulation possible
Hash-and-dump susceptibility: Network takes a full day to recover

In January 2025, Ninacatcoin experienced exactly this: a miner with ~210 KH/s departed, leaving ~1 KH/s against difficulty calibrated for 215 KH/s. With the old SMA, the network would have needed ~29 days to normalize.

LWMA-1: The Solution

Ninacatcoin uses the LWMA-1 algorithm (Linear Weighted Moving Average), designed by zawy12 — the industry standard for difficulty adjustment in small/medium cryptocurrencies.

Key parameters:

Code:

DIFFICULTY_WINDOW  = 60 blocks (~2 hours of data)
DIFFICULTY_LAG     = 2  blocks
DIFFICULTY_CUT     = 6  timestamps (excluded from extremes)

Core Formula:

Code:

next_difficulty = (sum_difficulty × T × (N + 1)) / (2 × sum_weighted_solvetimes)

Where:
  T   = target time (120 seconds)
  N   = number of intervals in window (up to 60)
  D_i = difficulty of block i
  st_i = solve time of block i, clamped to [-6T, 6T]
  weight_i = i (1 for oldest, N for newest)

LWMA-1 vs SMA comparison:

Feature	SMA (Monero)	LWMA-1 (Ninacatcoin)
Window size	720 blocks (~24h)	60 blocks (~2h)
Weighting	Equal for all blocks	Linear: recent weigh more
Timestamp handling	Sorted (loses order)	Unsorted (real solve times)
Reaction speed	Hundreds of blocks	3–5 blocks
Timestamp manipulation	Vulnerable	Clamped to [-6T, 6T]
99% hashrate loss recovery	~29 days	1–2 blocks (with EDA)

The most recent block contributes 60x more to the difficulty calculation than the oldest block, allowing the algorithm to react within 3–5 blocks (~6–10 minutes).

Emergency Difficulty Adjustment (EDA)

If a block takes more than 6x the target time (>720 seconds), EDA overrides LWMA and caps difficulty:

Code:

EDA Trigger: last_block_time > 6 × 120s = 720s (12 minutes)

adjusted_difficulty = last_difficulty × target / actual_solve_time
next_difficulty = min(LWMA_result, adjusted_difficulty)

Example — catastrophic hashrate departure:
Difficulty 9,000,000 (calibrated for 200 KH/s), hashrate drops to 1 KH/s, block takes 3,600s (1 hour):

Code:

adjusted = 9,000,000 × 120 / 3,600 = 300,000
→ Next block mined at difficulty 300,000 instead of 9,000,000

EDA convergence:

Block	Solve Time	Difficulty	Status
N	3,600s	9,000,000	EDA triggers
N+1	~360s	300,000	EDA triggers again
N+2	~180s	100,000	EDA not needed
N+3	~120s	~80,000	LWMA converging
N+10	~120s	~60,000	Stable

Protection against hashrate volatility:

Phase	SMA-720 (Old)	LWMA-60 + EDA
Large miner enters	Rises over 720 blocks	Rises in ~10 blocks
Large miner leaves	29 days to normalize	1–2 blocks (EDA)
Rent-and-dump	Devastating, 24h recovery	Negligible, 20 min recovery
Max slow blocks	Hundreds possible	1–2 before EDA

Difficulty Reset Mechanism

At height 4,726, a one-time difficulty reset occurred (DIFFICULTY_RESET_HEIGHT = 4726). The old SMA had 720 blocks of history at ~215 KH/s, while actual hashrate was ~1 KH/s. The reset prevented LWMA from looking back before the reset height. Difficulty dropped from 9.15M to ~68K within 60 blocks. Future fluctuations are handled entirely by LWMA-1 + EDA.

Solve Time Clamping

LWMA-1 clamps each solve time to [-6T, 6T] = [-720s, +720s], preventing future timestamp attacks, slow block exaggeration, and oscillation attacks.

7. Network Fees: Dynamic and Anti-Spam

Code:

FEE_PER_KB = 0.01 NINA                   (static fee per kilobyte)
FEE_PER_BYTE = 0.00001 NINA              (equivalent granular rate)
DYNAMIC_FEE_PER_KB_BASE_FEE = 0.005 NINA (dynamic minimum floor)

Dynamic Fee Calculation:

Static fee: fee_static = tx_weight × FEE_PER_BYTE
Dynamic fee: dynamic_fee = (0.95 × block_reward × 3000) / (median_weight²)
Final fee: fee_total = max(fee_static, dynamic_fee × tx_weight)

Scenario	Tx Size	Fee
Low congestion	2 KB	~0.02 NINA
Moderate congestion	2 KB	~0.04 NINA
High congestion	2 KB	~0.06 NINA
Spam attack	2 KB	~0.50 NINA

Blocks ≤ 300,000 bytes receive full reward. Larger blocks incur penalties, making spam unprofitable.

8. Privacy and Anonymity

Ring Signatures

Every transaction uses mandatory ring signatures — enforced at protocol level. The sender's real output is mixed with N-1 decoy outputs:

Default ring size: 11 (mixin 10) — 1 real + 10 decoys
Probability of guessing the real signer: ~9.1%
Future hard fork (v17) will increase to ring size 16 once the blockchain matures

Ring size 11 was chosen for the initial phase because a young blockchain has limited outputs available. Starting at 11 ensures strong privacy at every growth stage.

RingCT (Ring Confidential Transactions)

Pedersen Commitments: Amounts encrypted: C = aG + bH
Homomorphic property: Miners verify inputs = outputs without knowing amounts
Bulletproof+ range proofs: Compact proofs that amounts are non-negative
Enforced since hard fork v6

Stealth Addresses

Every transaction generates a unique, one-time address for the recipient. No two transactions ever send to the same on-chain address. An observer cannot link payments to a known public address.

Tor and I2P Integration

Nodes detect .onion and .b32.i2p addresses as anonymous endpoints
Dandelion++ provides transaction propagation privacy: Stem phase (single peer forward) → Fluff phase (network broadcast)
Impossible to determine the originating node

Information	Hidden?	Mechanism
Sender identity	Yes	Ring signatures (11 decoys)
Recipient identity	Yes	Stealth addresses
Transaction amount	Yes	RingCT + Bulletproof+
Transaction existence	No	Public ledger (by design)
Sender IP address	Yes (optional)	Dandelion++ / Tor / I2P

9. Enhanced RandomX Mining

RandomX is activated at block height 3,000 (hard fork v16). Blocks 0–2,999 used CryptoNight. Ninacatcoin implements three improvements over standard RandomX:

Improvement 1: Shorter Epochs

Code:

Monero:       SEEDHASH_EPOCH_BLOCKS = 2048 (68 hours)
Ninacatcoin:  SEEDHASH_EPOCH_BLOCKS = 1024 (34 hours)

More frequent seed changes make ASIC ROI mathematically impossible (design takes 6–12 months, seed changes every 34 hours).

Improvement 2: Variable Dataset

Code:

dataset_size = min(2GB + (network_hashrate_TH_s × 10MB), 4GB)

ASICs optimized for 2GB become suboptimal when the dataset grows. CPUs handle any dataset size transparently.

Improvement 3: Dual Mode with GPU Penalty

Every 5 blocks (20%), RandomX runs in "safe" mode (RANDOMX_FLAG_SECURE) with JIT disabled:

Code:

Block 0 (height % 5 == 0): GPU Penalty Mode (10x slower for GPUs)
Blocks 1–4: Normal mode
Average GPU efficiency: ~20% vs CPU baseline

CPU Mining: Democratic Access

RandomX uses only basic CPU instructions (integer arithmetic, L3 cache, memory latency). A used office computer from 2010 can mine profitably.

Hardware	Efficiency	Profitability
Modern CPU	100% (baseline)	Full
Old CPU (2010+)	30–60%	Moderate
GPU	~20%	Marginal
FPGA	~5%	Unprofitable
ASIC	0%	Impossible

10. Automatic Checkpoints: The Impossible Defense Against 51%

Why Checkpoints Matter

A 51% attack rewrites blockchain history using majority hashrate. Checkpoints make it cryptographically impossible to rewrite history, even with 100% of the hash power.

Checkpoint Architecture

A checkpoint is a pair (height, block_hash) that permanently locks a block. Once validated against a checkpoint, a block CANNOT be replaced.

Checkpoint interval: 30 blocks = 3,600 seconds = 1 hour
Distribution: HTTPS + seed nodes
Generation: Fully automatic, no human involvement

Automatic Generation

Unlike Monero's manual checkpoints (updated every 6–12 months), Ninacatcoin generates checkpoints automatically:

Total automation — no human intervention at any step
Continuous — 24/7, every 1 hour
No single point of failure — 3+ independent seed nodes
Decentralized — each seed generates independently
Fully auditable — open source code

Hybrid Distribution

Code:

LAYER 1: HOSTING (CDN — Fast Access)
├─ URL: https://ninacatcoin.es/checkpoints/
├─ Content: Last 15 days of checkpoints
├─ Update: Every 1 hour (automatic)
└─ Purpose: Fast sync for new nodes

LAYER 2: SEED NODES (Distributed Authority)
├─ 3+ independent servers
├─ Content: FULL HISTORY from genesis
├─ Update: Every 1 hour (automatic)
└─ Purpose: Backup, validation, redundancy

Why 51% and 100% Attacks Fail

Attacker's block hash ≠ checkpoint hash → rejected
Nodes contact hardcoded legitimate servers, never attacker's
3 independent seeds cannot all be compromised simultaneously
Open source — malicious recompilation is detectable

Formal proof: For the attack to succeed, the alternative chain R_A must match checkpoints. But checkpoints were generated from the honest chain R_H. So R_A = R_H at every checkpoint. Since blocks are chained, R_A = R_H everywhere. But then R_A IS R_H — not an alternative chain. Contradiction. QED.

Maximum Attack Window

Maximum 30 blocks (1 hour). Compare: Monero ~33 days, Bitcoin unlimited.

Feature	Ninacatcoin	Monero	Bitcoin
Checkpoint interval	60 min	~33 days	None
Checkpoint method	Automatic	Manual	N/A
Max reorg window	30 blocks	~33,000 blocks	Unlimited
51% resistance	Impossible (>1h)	Weak	Vulnerable

Ninacatcoin is approximately 720x more secure than Monero against reorg attacks.

11. Intelligent Detection and Auto-Repair System

Malware can modify checkpoint files after download. Ninacatcoin implements automatic detection and repair.

Four detection layers:

Hash Format Validation: Each hash must be exactly 64 hex characters
Genesis Block Validation: Compared against hardcoded genesis hash
Epoch Validation: Monotonic epoch_id progression
Seed Node Cross-Reference: Validated against multiple independent seeds

FAIL-SAFE Pause Mode:
When corruption is detected: Detect → Report → Pause → Retry every 30s → Auto-repair → Resume. Zero manual intervention required.

Attack	Detection	Response
Malware modifies file	Format validation	PAUSE + auto-repair
Replay attack	epoch_id validation	Reject + retry
False genesis block	Hardcoded comparison	Immediate rejection
Compromised seed	Multi-seed consensus	Use remaining seeds
Network outage	Retry loop	Wait with existing data

12. Precomputed Block Hashes: checkpoints.dat

Complementary to JSON checkpoints, checkpoints.dat verifies every block ever produced in groups of 512.

Feature	checkpoints.json	checkpoints.dat
Format	Readable JSON	Compact binary (Keccak-256)
Granularity	1 hash per hour	ALL blocks (by 512)
Protection	Point checkpoints	Complete chain verification

Binary Format:

Code:

[4 bytes]  ngroups (uint32 LE) = Number of groups of 512 blocks
Per group (64 bytes):
  [32 bytes] cn_fast_hash(block_hash_0 || ... || block_hash_511)
  [32 bytes] cn_fast_hash(block_weight_0 || ... || block_weight_511)

Triple Protection Architecture:

Code:

LAYER 1: COMPILED (compile-time)
├─ Hashes embedded in executable
└─ Cannot be modified without recompiling

LAYER 2: DOWNLOADED (runtime)
├─ Updated from https://ninacatcoin.es at startup
└─ Covers blocks mined after binary was compiled

LAYER 3: P2P VERIFICATION (network)
├─ Validated against blocks from peers
└─ Compromised CDN cannot fool the network

13. Intelligent Validation Enhancements

PHASE 1: Epoch-Based Validation

epoch_id prevents replay attacks. Metadata persists in .ninacatcoin_checkpoints_metadata.json. Requires ≥1/3 seed consensus.

PHASE 1.5: Tiered Ban System

Level	Duration	Trigger
TEMP_1H	1 hour	First violation
PERSISTENT_24H	24 hours (saved to disk)	Second violation
PERMANENT	Indefinite	Third+ violation

PHASE 2: Peer Reputation System

Auditable ban reasons: HASH_MISMATCH, EPOCH_VIOLATION, REPLAY_ATTACK, INVALID_HEIGHT, SEED_MISMATCH. All logged in structured JSON with the OBSERVE_INVALID_CHECKPOINT protocol.

Defense in Depth — 5 Independent Layers:

Layer	Mechanism	Protection
1	Proof-of-Work (RandomX)	Requires >50% hashrate
2	Auto Checkpoints (60 min)	History immutability
3	P2P Consensus (66%+)	Immediate detection
4	Dynamic Reputation	Incremental penalties
5	Auto Quarantine	1–6h isolation

An attacker must defeat ALL five simultaneously — no known attack has achieved even three.

14. Discord Bot: Real-Time Event Announcements

An automated Discord bot (discord_lottery_bot.py) provides real-time X2/X200 announcements.

Automatic Event Detection: Monitors blockchain via JSON-RPC
Verifiable Announcements: Includes all data for independent verification
Historical Recovery: On restart, catches up from last recorded height
Anti-Redundancy: State persistence, reorg detection, SHA256 deduplication

Discord Channels:

#x2-events — X2 multiplier events
#x200-events — X200 multiplier events (rare)
#block-updates — General block information

Source code is publicly available for auditing.

15. Block Explorer: Total Blockchain Transparency

The Ninacatcoin Block Explorer (https://niachain.ninacatcoin.es/) provides public access to all blockchain information.

Capabilities: Real-time blocks, transaction verification, network metrics, X2/X200 validation, emission tracking.

Privacy vs. Transparency:

Data	Visible?	Why?
Block exists	Yes	Public ledger
Transaction amount	No	RingCT
Sender	No	Ring signatures
Recipient	No	Stealth addresses
Fees	Yes	Miner auditing

Tech Stack: Node.js + Express.js backend, React.js + Tailwind CSS frontend, Redis cache, HTTPS with CDN. 99.9% uptime.

16. Technical Architecture

Core Components:

ninacatcoind — Full node (validates chain, mempool, P2P, JSON-RPC)
ninacatcoin-wallet-cli — Command-line wallet
ninacatcoin-wallet-rpc — JSON-RPC wallet for applications

Network Configuration:

Code:

P2P Port:     19080
RPC Port:     19081
ZMQ Port:     19082
Data Dir:     ~/.ninacatcoin/

Build Dependencies:

Code:

cmake 3.8+, C++17 compiler (gcc 7+ / clang 5+)
Boost >= 1.66, OpenSSL 1.1.1+, libsodium, libzmq, libunbound

Hard Fork Schedule:

Version	Height	Features
v1	1	Genesis — CryptoNight PoW
v16	3,000	RandomX, RingCT, CLSAG, Bulletproof+, View Tags
v17	TBD	Ring size increase to 16

Build Security: ASLR (-fPIE), Stack protector (-fstack-protector-strong), CFI (-fcf-protection), Fortify source (-D_FORTIFY_SOURCE=2), Non-executable stack (-z noexecstack).

Test Suite: Unit tests, core blockchain tests, functional end-to-end tests, fuzz testing.

17. Roadmap and Future Development

Near-Term (2026):

Hard fork v17: Ring size 11 → 16
Mobile wallet (Android/iOS)
Open-source mining pool software

Medium-Term (2026–2027):

Atomic swaps: BTC↔NINA, XMR↔NINA
Payment processor SDK for merchants
Enhanced block explorer analytics

Long-Term Vision:

Full Tor integration by default
Layer 2 payment channels
Continued ASIC resistance monitoring

18. Embedded Mini AI: NINA Intelligence Engine

Overview

Ninacatcoin ships with a Mini AI engine compiled directly into the daemon binary (ninacatcoind). This is not an external service or cloud dependency — it is a self-contained, sandboxed artificial intelligence module that runs inside the node process, providing real-time security, network optimization, and predictive analysis with zero external connections beyond the P2P protocol.

The AI module lives in src/ai/ and is organized into specialized subsystems:

Code:

/ninacatcoin/src/ai/
├── ai_module.hpp/cpp                 # Main AI singleton (coordinator)
├── ai_config.hpp                      # Immutable compile-time configuration
├── ai_sandbox.hpp/cpp                 # Filesystem sandbox (whitelisted paths only)
├── ai_network_sandbox.hpp/cpp         # Network sandbox (P2P ports 30000-30100 only)
├── ai_integrity_verifier.hpp/cpp      # SHA-256 AI code integrity verification
├── full_integrity_verifier.hpp/cpp    # SHA-256 FULL BINARY integrity verification
├── ai_financial_isolation.hpp         # Financial isolation barrier (read-only enforcement)
├── ai_forced_remediation.hpp/cpp      # Automatic self-healing from GitHub
├── ai_quarantine_system.hpp/cpp       # Permanent isolation of compromised nodes
├── ai_checkpoint_validator.hpp/cpp    # Hash-level checkpoint validation
├── ai_checkpoint_monitor.hpp/cpp      # Checkpoint seed health monitoring
├── ai_lwma_learning.hpp/cpp           # Difficulty pattern learning
├── ai_hashrate_recovery_monitor.hpp/cpp # Hashrate departure detection
├── ai_auto_updater.hpp/cpp            # P2P consensus-driven auto-update
├── nina_ia_auto_update.hpp/cpp        # Intelligent auto-update orchestrator (hard fork detection)
├── ai_version_checker.hpp/cpp         # Binary version verification
├── ai_advanced_modules.hpp            # 6-tier predictive/analytic modules (17 classes)
├── nina_smart_mempool.hpp/cpp         # Intelligent transaction pool analysis
├── nina_ring_enhancer.hpp/cpp         # Ring signature quality optimizer
└── nina_network_optimizer.hpp/cpp     # P2P connection intelligence

Core Functions

The Mini AI performs over 20 distinct functions, grouped into five categories:

CATEGORY 1: SECURITY & INTEGRITY

AI Code Integrity Verification: Every 60 seconds, the AI calculates SHA-256 hashes of all AI source files and compares them against canonical hashes obtained from 3 independent seed nodes (2/3 consensus required). Any tampering is detected within one minute.
Full Binary Integrity Verification: At compile time, CMake hashes ALL source files (.cpp, .hpp, .h, .c) composing the daemon binary and embeds the hash. At runtime, the AI recalculates and compares — protecting the ENTIRE binary, not just the AI subsystem.
Financial Isolation Barrier: Hardcoded compile-time restrictions ensure the AI can NEVER create transactions, send coins, or write to wallets. Any violation attempt triggers immediate quarantine with critical alerts. The AI is strictly READ-ONLY for all financial operations.
Forced Remediation: If code tampering is detected, the AI automatically downloads clean source from the official GitHub repository, verifies and recompiles it — up to 3 attempts with zero human intervention.
Quarantine System: After 3 failed remediation attempts, the node is permanently quarantined: all networking is blocked, mining is disabled, and the node is added to the global blacklist. Only a complete reinstallation can recover.
Checkpoint Validation: Advanced hash-level validation of checkpoint files, detecting epoch rollback attacks, modified hashes, replay attacks, and seed desynchronization.

CATEGORY 2: NETWORK INTELLIGENCE

P2P Network Optimizer: Scores every connected peer on latency, reliability, block validity ratio, and version. Automatically adjusts peer count based on measured bandwidth, preferring full-chain nodes during sync. Achieves +20-30% sync speed improvement and +15% block propagation.
Peer Reputation Tracking: Monitors peer behavior continuously, blacklisting nodes that provide invalid blocks or exhibit malicious patterns. Tiered ban system: 1-hour temporary → 24-hour persistent → permanent.
Hashrate Recovery Monitor: Observes the LWMA-1 difficulty algorithm in real time, detects sudden hashrate departures, and validates that EDA (Emergency Difficulty Adjustment) activates correctly.

CATEGORY 3: PREDICTION & ANALYSIS

Block Time Predictor: Learns from the last 100 blocks using outlier detection (3-sigma) and moving averages to predict next block time, identify trends, and detect anomalies (timestamp attacks, rapid difficulty oscillations).
LWMA Learning Engine: Observes every LWMA-1 difficulty calculation, classifies patterns ("stable", "recovering", "under_attack"), and alerts the network of concerning deviations — all without modifying consensus.
Attack Forecasting: Learns from past anomalies to predict future attack patterns (51% attack, eclipse attack, timestamp manipulation, replay attack), assigning probability scores and generating mitigation strategies automatically.
Smart Mempool: Analyzes transactions by fee/byte efficiency using structural fingerprinting (not sender addresses, which are hidden by ring signatures). Distinguishes legitimate trading bots from spam, monitors mempool health (HEALTHY/BUSY/CONGESTED/UNDER_ATTACK), and intelligently prioritizes transactions. Does NOT reject any transaction — only re-orders them.

CATEGORY 4: PRIVACY ENHANCEMENT — NINA Ring Enhancer

The Ring Enhancer is a wallet-side AI module that dramatically improves ring signature privacy. It does NOT change consensus rules — transactions enhanced by NINA are fully compatible with standard nodes. No hard fork required.

Five core capabilities:

Ring Quality Scoring: Every assembled ring is evaluated on a composite 0-100 scale across four sub-scores: temporal spread (Shannon entropy of time-bucket distribution), block diversity (ratio of unique blocks to ring size), age variance (coefficient-of-variation mapping), and clustering resistance (gap-analysis defense). A ring must pass all minimums: ≥6 distinct blocks, ≥4 of 6 time buckets covered, ≤2 members from the same block.
Adaptive Ring Size: Based on the blockchain's RCT output count, NINA classifies maturity as "young" (<50K outputs), "growing" (<200K), "mature" (<1M), or "established" (≥5M), and recommends ring sizes accordingly — ring 11 needs ≥5,000 outputs, ring 16 needs ≥100,000, ring 21 needs ≥500,000. This prevents using Ring 16 when the chain is too young to provide sufficient anonymity sets.
Intelligent Decoy Selection: Suggests target block heights for well-distributed decoy selection across 6 temporal zones: 0-100 blocks (~3h), 100-1K blocks (~1.4d), 1K-5K (~7d), 5K-20K (~28d), 20K-100K (~139d), and 100K+ (older). This counters temporal analysis attacks described in Miller et al. (2017).
Candidate Ranking: Ranks candidate decoy outputs from best to worst based on their contribution to ring diversity, allowing the wallet to always pick the best available decoys from the UTXO set.
Real-Time Improvement Check: Before adding each decoy to a ring, evaluates whether the candidate would actually improve quality — preventing sub-optimal ring assembly.

Academic References: Miller et al. (2017) — output traceability, Goodell et al. CLSAG (2019) — signature efficiency, Möser et al. (2018) — output merging analysis.

CATEGORY 5: INTELLIGENT AUTO-UPDATE

NINA IA Auto-Update Orchestrator: Autonomously monitors GitHub for new versions and upcoming hard forks. Analyzes remote cryptonote_config.h and hardforks.cpp to detect changes classified as HARD_FORK, SOFT_FORK, SECURITY_FIX, PERFORMANCE, or FEATURE. Schedules updates during low-activity windows, ensuring the node updates at least 500 blocks before any fork height. Includes full history logging and Discord notification callbacks.

Sandbox Architecture: Total Isolation

The Mini AI operates under strict dual-sandbox confinement:

Layer	Restriction	Details
Filesystem	Whitelist only	Only /src/ai/, /build/, /blockchain/, /ai_module/ accessible
Network	P2P protocol only	Ports 30000-30100, registered peers only. No HTTP, DNS, SSH
Memory	2 GB maximum	Warning at 95% (1,900 MB), hard limit at 2 GB
CPU	2 cores maximum	Does not interfere with RandomX mining

The AI cannot:

Read user files, wallet keys, or system data
Create transactions, send coins, or write to wallets (Financial Isolation Barrier — any violation triggers immediate quarantine)
Connect to external services (no HTTP, no DNS, no cloud)
Exceed its memory/CPU allocation
Modify consensus rules
Be disabled by the user (integral to node security)

Auto-Update via P2P Consensus

The AI includes a self-updating mechanism driven by peer consensus:

Code:

1. P2P network distributes AI code hashes
2. If >60% of peers (minimum 3) report a different hash → update triggered
3. Source downloaded from official GitHub (master branch)
4. Compiled in the original build directory
5. New hash verified against network consensus
6. Binary backed up, replaced, and daemon restarted gracefully
7. If verification fails → update aborted (no damage)

This ensures all nodes converge to the same verified codebase without centralized update servers.

6-Tier Advanced Learning Modules

The AI includes six progressive tiers of intelligence:

Tier	Module	Classes	Function
1	Prediction & Forecasting	BlockTimePredictorModule, AttackForecastingModule, DifficultyTrendModule	Block time prediction with outlier removal, attack probability forecasting, difficulty trend projection (24h/72h)
2	Transaction Analysis	AnomalousTransactionModule, MempoolWatcherModule	Multi-factor anomaly scoring (amount/time/address/clustering), mempool flood detection, spam ratio calculation
3	Network Intelligence	PeerReputationModule, NetworkHealthModule, GeoDistributionModule, PeerClusteringModule	Peer reputation scoring, network health (peer diversity + consensus + sync), geographic centralization detection, behavioral peer clustering
4	Optimization & Automation	FeeOptimizationModule, ConsensusParameterModule, NetworkSimulationModule	Fee recommendation (min/normal/priority), consensus parameter suggestions, 51% and eclipse attack simulation
5	Forensics & Security	TemporalAnalysisModule, BehavioralClusteringModule, BlockForgeryDetectionModule, TimingAttackDetectionModule	Hourly activity anomalies, address clustering (trading/mining/whale), block signature verification, instant-solve detection
6	Market Intelligence	MarketIntelligenceModule	Price correlation analysis (placeholder for future expansion), emission tracking

All 17 classes are coordinated by NInaAdvancedCoordinator, which generates comprehensive intelligence reports every 100 blocks.

Initialization Flow

Code:

Daemon Startup (ninacatcoind)
    ↓
AIModule::getInstance().initialize()
    ├─ Load immutable compile-time configuration
    ├─ Enforce Financial Isolation Barrier (read-only for wallets/coins)
    ├─ Validate AI code integrity (SHA-256 vs seed nodes, 2/3 consensus)
    │   └─ If mismatch → ForcedRemediation (up to 3 attempts)
    │       └─ If all fail → Quarantine (permanent isolation)
    ├─ Validate full binary integrity (SHA-256 vs compile-time hash)
    ├─ Initialize FileSystem Sandbox (whitelist paths)
    ├─ Initialize Network Sandbox (P2P only)
    ├─ Start integrity monitoring thread (every 60 seconds)
    ├─ Start LWMA learning observer
    ├─ Start Smart Mempool analyzer
    ├─ Start Network Optimizer (peer scoring + bandwidth tuning)
    ├─ Start Ring Enhancer (wallet-side quality improvement)
    ├─ Start NINA IA Auto-Update Orchestrator (GitHub + fork monitoring)
    ├─ Initialize 6-Tier Advanced Modules (17 classes via NInaAdvancedCoordinator)
    └─ Set state to ACTIVE

Performance Impact

Metric	Without AI	With AI	Improvement
Block sync speed	Baseline	+20-30% faster	Smart P2P routing
Block propagation	Baseline	+15% faster	Optimized peer selection
Eclipse attack risk	Standard	-70% reduced	Peer reputation system
Tamper detection	None	<60 seconds	Dual integrity (AI + full binary)
Ring privacy quality	Random decoy selection	AI-scored (0-100) with adaptive ring size	Temporal + block diversity enforcement
Memory overhead	—	~500 MB – 2 GB	Bounded by sandbox
CPU overhead	—	2 cores, 40-60%	Does not affect mining

Why a Mini AI Inside the Binary?

Zero dependencies: No cloud, no API keys, no external services — the AI runs entirely within the daemon process
Always available: Starts with the node, operates 24/7, cannot be deactivated
Trustless: All code is open source and auditable. Integrity verified by seed node consensus
Self-healing: Detects its own corruption and repairs itself from GitHub
Consensus-safe: The AI NEVER modifies consensus rules — it only observes, optimizes, and protects
Privacy-preserving: Cannot access user data, wallets, or system files. Sandboxed to its own directory

Ninacatcoin is the first CryptoNote-based cryptocurrency to embed a full AI security and optimization engine directly in the node binary, providing institutional-grade protection without sacrificing decentralization or privacy.

Summary: Why Ninacatcoin

Feature	Ninacatcoin	Monero	Bitcoin
Privacy	RingCT + Ring Sig + Stealth	RingCT + Ring Sig + Stealth	Pseudonymous only
51% Defense	60-min auto checkpoints	~33-day manual	None
Difficulty	LWMA-1 (60 blocks) + EDA	SMA (720 blocks)	Bitcoin DA (2,016)
Hashrate drop reaction	1–2 blocks (EDA)	Hundreds of blocks	~2 weeks
Mining	CPU-first, GPU penalized	CPU-first	ASIC-only
Bonus events	X2 (183/yr), X200 (6/yr)	None	None
Checkpoint repair	Automatic	Manual	N/A
ASIC resistance	Triple defense	Single (RandomX)	None
Ring size	11 (→16 at v17)	16	N/A
Embedded AI	Yes (20+ functions, sandboxed)	No	No
Block time	120s	120s	600s
Max supply	900M NINA	18.4M XMR + tail	21M BTC

License and Credits

Ninacatcoin is released under the BSD 3-Clause License. It builds upon the work of The Monero Project, CryptoNote, RandomX (tevador), and LWMA-1 (zawy12).

For developers and users who value true privacy, transparent emission, and decentralized security, Ninacatcoin is a clear and compelling choice.

In memory of Nina (25/05/2014 – 16/02/2019) — generous, kind, and unforgettable. Your kindness lives on in every block.