crypto ninacatcoin

VISIT www.ninacatcoin.es

https://github.com/ninacatcoin/ninacatcoin

https://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

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

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
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.