QNET BLOCKCHAIN @AIQnetLab

@OnlyHades_ How I finish what I wrote in this post

Hey everyone - it’s been a few quiet weeks on the feed, but development has been moving steadily behind the scenes. What’s been done: - Server node registration is live and working - Synchronization logic with the network is nearly complete - Reactivation logic implemented - nodes now handle reconnects correctly after migrations or long offline periods (same nuances as mobile nodes, just different complexity) - Security audit done: a vulnerability in the network was identified and patched What’s left: Finishing server node integration + polishing the node update mechanism. We’re close - genuinely the last stretch before testnet. Thanks for your patience. It means a lot. Testnet is coming. Soon.

Here's how light node proof-of-participation works in QNet. Every 4 hours the network checks whether your device is online. This isn't a simple ping - it's a cryptographic challenge-response. How it works: Each 4-hour window is split into 240 one-minute slots. Every node gets a unique randomized slot per window, derived from a hash of the node_id and window number. You can't predict in advance when the request will arrive. When your slot hits, a genesis node sends a challenge - a random 32-byte string - to your device via push notification. The device signs it and sends back the response. Three attempts, not one. If the primary genesis node doesn't get a response, two backup nodes retry with a delay, giving the primary time to complete first. Miss all three - the round is skipped. After 5 consecutive missed rounds, the node is marked inactive. There's a reactivate button in the app to bring it back. The ping key is separate from the wallet. At registration, the device generates a dedicated Dilithium3 key specifically for signing ping responses and issues it a delegation certificate signed by the main wallet key. This lets the app respond to challenges in the background even when the screen is off or the app is closed - the main wallet key is never touched. The response is signed with this delegated Dilithium3 key. The attestation is then propagated to all genesis nodes via gossip protocol. Rewards aren't instant. Participation data is collected into a MacroBlock at the end of the epoch, and payouts happen one epoch later - 4 hours after the window closes. This is an intentional delay to allow finalization through BFT consensus.

Huge block of tasks done. Completed the full light node cycle for QNet. Everything works now - from wallet creation to receiving rewards for participating in the network. How it works: Burn 1DEV - get a spot in the network App registers the device on-chain Every 4 hours the device sends a ping - proof of participation At the end of an epoch - rewards are accrued One-tap claim - tokens in the wallet, send anywhere The video shows the real thing: claiming light node rewards and transferring QNC to another wallet.

🎂 Exactly one year ago, I wrote the first lines of QNet Blockchain code. Over this time, I went through many AI models - each one better than the last, helping me solve problems faster and more efficiently. I want to repeat the core idea once more, because it truly matters. I wanted to build a system that rewards every user - constantly and automatically. When I started, I had no references, no other project attempting anything like this. And today, I still haven't seen a single one moving in this direction. QNet is: - No premine. Every participant gets an equal share after activation. - No technical knowledge needed. A couple of taps on your phone screen - that's it. - Rewards accumulate automatically. Hit claim whenever you want - no daily grind, no tapping required. Think of the legendary early Bitcoin faucet - but permanent, effortless, and accessible to absolutely everyone. This is the blockchain approach I always dreamed of. And we're on the final stretch. A few finishing touches remain in the consensus mechanism - and the user reward system will be fully complete. Very soon. And once again - a huge thank you to each and every one of you. Without your support and engagement, reaching this point would have been incomparably harder. More to come 👀

Still working on the app. Latest focus - backend fixes and background pings: your node stays active even when the app is closed or the screen is locked. Open the app once - the network handles the rest. No commits ≠ no progress. Not everything goes to the repo right away.

Here is what code recovery and Light Node activation look like on a real device

QNet Testnet - what's on the roadmap? Want to share a quick update on what I`m planning to ship: - Token creation tools for users within the QNet ecosystem - NFT collection launches - fully on-chain - In-wallet mini-activities - compete with other users, earn $QNC. A little on-chain gambling energy never hurt anyone 🎲 No hard dates yet - these features land after Light & Super Node activations are complete. But they're next in line. Building doesn't stop

Finished developing activation code recovery and the full node activation flow for light nodes — everything works smoothly. Next up: testing light node pings and reward distribution. After that, server node activation, then testnet launch. explorer.aiqnet.io/explorer/tx/de…

keyboard_arrow_left Previous keyboard_arrow_right Next

QNet activation code - public by nature, secure by design. Code = XOR(wallet, SHA3(tx_hash:type:amount)) - yes, anyone can technically reconstruct it from public Solana data. But it's useless without: - Dilithium3 (post-quantum) signature with your private key - Code embeds your wallet prefix - someone else's code won't match your wallet - 1 wallet = 1 node enforced in persistent storage forever The secret isn't the code. The secret is your private key.

keyboard_arrow_left Previous keyboard_arrow_right Next

Not long ago I ran stress tests on the network that showed around 100K TPS - but the problem was that the network broke down afterwards, likely due to issues with the cryptographic signatures at the time. Since then I reworked the signature system and ran new tests. Results: - Peak TPS: 54,162 - Average TPS: 53,516 - Transactions: 978,664 out of 999,996 (97.9% success) - Duration: 18.7 sec - Errors: 0 - Latency avg: 0.081 ms - Latency p99: 0.115 ms The network runs flawlessly after the tests - all 5 nodes are synchronized, 0 forks, 0 errors. It's possible to push TPS even higher, but that would require expanding the mempool and increasing block sizes, which could cause issues with block propagation and exchange between nodes due to their size. So I prefer to focus on finishing the node registration work for now. Either way I'm happy with the current 54K TPS - that's an insane result for an L1 blockchain with post-quantum Dilithium3 signatures. http://162.244.25.114:8001/api/v1/benchmark/results

In the latest big update, I've completely replaced the previous block producer selection mechanism (QRDS) with Dilithium3-VRF - a verifiable random function based on post-quantum cryptography, NIST FIPS 204 (ML-DSA-65). What this means in practice: Previously, producer selection was deterministic - all nodes computed the same hash function from public data, and the result was predictable in advance. This created an attack vector: knowing the future producer, an adversary could target them before block creation. Now each node privately evaluates a VRF using its secret key and a shared seed value. The result is unpredictable to everyone else, yet cryptographically verifiable - any network participant can confirm that the node genuinely had the right to produce the block, without knowing its private key. The winner is determined by the lowest VRF output among all claims, making result manipulation impossible. In parallel, I'm working on the node activation mechanism. The key security requirement: the activation code is cryptographically bound to the wallet address that received it. This means that even if the code is intercepted, it cannot be used from a different wallet - during server-side activation, an XOR-encrypted binding between the code and the address is verified. The owner's mnemonic phrase is the only way to confirm the right to launch a node.

Architecture & Testnet Update Removed the second reward pool where transaction fees were distributed among all super and full nodes - realized it was overcomplicating the architecture without adding real value. For the same reason, I removed full nodes entirely, leaving just two types: light nodes (which are essentially clients, not real nodes) and server nodes (super). Simpler is better. Before launching the testnet, I still need to test user node registration - both server and mobile. Also need to verify how light node ping functionality works end to end. Once all checks are done and final adjustments made, we can start full-scale testing. At launch, access will be Android-only. iOS support is coming - it just needs time. One thing at a time. Let's get to testnet first and go from there. Note: the Explorer is live and showing current network data, but the chain will likely be reset several times before the official testnet launch as I make fixes and adjustments. All existing blocks, transactions, and balances will be wiped with each reset.

Finished working on transactions - everything functions exactly as designed. Emission, reward claiming, transfers, fee distribution to block producers - each step goes through the full signature and consensus validation cycle. Updated the website with current project information and launched the Explorer - you can now track blocks, transactions, and network status in real time. explorer.aiqnet.io/explorer

👀

I started working on QNet from the beginning of March 2025. Almost every single day. And since the pump.fun launch (09/24/2025) I've had only 2 days off in 4 months. This is not a token made in one evening. This is a full-fledged Layer-1 blockchain with its own network, consensus, cryptography, and applications. Let me show you what exactly has been created. PROJECT SCALE ~200,000 lines of code. 1,760 files. 108 unique mechanisms. Three programming languages: Rust, TypeScript, Python. For comparison: a team of 5 senior developers would take 18-24 months with a budget of $1.5-3 million. BLOCKCHAIN CORE Written in Rust — 90,000 lines of code. Main modules: - node rs (23,017 lines) — main node logic, block processing, transactions, consensus - unified_p2p.rs (19,173 lines) — P2P network between nodes, peer discovery, gossip protocol - rpc rs (11,681 lines) — REST API for external applications - qnet-consensus (10,500 lines) — BFT consensus with adaptive timeouts - storage rs (6,099 lines) — RocksDB storage layer - qnet-core (4,910 lines) — base data structures - activation_validation.rs (2,786 lines) — node activation validation - qnet-mempool (2,506 lines) — unconfirmed transaction pool - quic_transport.rs (1,476 lines) — QUIC/TLS transport layer - qnet-sharding (990 lines) — sharding into 256 parts CRYPTOGRAPHY Quantum-resistant algorithms: - CRYSTALS-Dilithium3 — post-quantum digital signatures (NIST standard) - Hybrid scheme Ed25519 + Dilithium — compatibility with current systems plus protection against quantum attacks - Blake3 — hash functions for Proof-of-History NETWORK STACK - QUIC protocol — modern transport over UDP - TLS 1.3 — encryption of all connections - Bincode — binary data serialization - Length-prefixed framing — reliable message delivery - ACK mechanism — delivery confirmation for critical transactions - Reed-Solomon erasure coding — data recovery with up to 30% packet loss 108 MECHANISMS Transport: QUIC, TLS 1.3, Bincode, Port Offset, TCP Nodelay, Keepalive Shred Protocol: Chunking 128KB, Reed-Solomon, Adaptive Redundancy, Parity Chunks, Producer Certificate, Priority Delivery, Max Block Size 21.76MB, Unicast Sync, Chunk Pacing Routing: Kademlia DHT (K=20, α=3), XOR Distance Routing, Tree Propagation, Adaptive Fanout, Deterministic Chunk Targeting, Sorted Peers by Bucket Flow Control: Batch Sending, Pacing Delay, Semaphore Limiting, Backpressure, Retry Cooldown, Timeout Management, Adaptive Backpressure, Congestion Control Recovery: Chunk Cache, Repair Batching, Deduplication, Gap Detection, Parallel Download, Wave Sync, Retry Mechanism, Downloading Tracker, Pending Gap Queue, Retransmit Cache, Size-Based Batching, Macroblock Batching Stage Pipeline: BROADCAST_RUNTIME, SIGVERIFY_RUNTIME, BANKING_RUNTIME, REPLAY_RUNTIME Sharding: 256 Shards, Regional Clustering (EU, US, Asia), Lock-free DashMap, LRU Eviction, Adaptive Peer Limit Security: Dilithium Signatures, Ed25519 Hybrid, Rate Limiting, Nonce Validator, Soft Blacklist, Hard Blacklist, Malicious Behavior Detection, Invalid Blocks Tracker, False Emergency Tracker, Emergency Confirmations, Race Condition Protection, Privacy ID Logging Reputation: Reputation System, Consensus Score, Network Score, Reputation Migration, Qualified Producers Filter Compression: Zstd for macroblocks, LZ4 for certificates, Bincode+Zstd for signatures Parallelism: Parallel Executor Pipeline, Pre-Execution Cache, Dependency Analysis Consensus: PoH (Blake3), Adaptive BFT Timeouts, Commit-Reveal Protocol Networking: Gulf Stream TX Routing, Gossip Protocol, Health Ping, Peer Exchange Protocol, Bootstrap/Genesis Nodes, Heartbeat System, Peer Heights Tracking Failover: Emergency Failover, Failover Deduplication, Emergency Stop Production, Auto-Recovery, Regional Failover, Strict Sync Check, Peer Sync Filtering Certificates: Certificate Rotation, Certificate History Tracking, Hybrid Certificate (Ed25519+Dilithium), Certificate Cache with TTL Maintenance: Auto-Cleanup 24h, Inactive Peer Cleanup, QUIC Idle Cleanup, Stale Node Timeout Monitoring: RuntimeStats, Atomic Counters, Cache Actor, Load Balancing Metrics Fees and Snapshots: Gas Price / Priority Fees, State Snapshots (IPFS), Max TX per Block (100K) APPLICATIONS 70,000 lines of JavaScript/TypeScript. Browser Wallet Extension - 43,800 lines: Extension for Chrome, Edge, Firefox. Manifest V3. Support for Ed25519 and Dilithium signatures. Multi-network support. Secure seed phrase storage. Mobile App - 12,687 lines: React Native application for Android and iOS. Quantum signatures from mobile device. Push notifications. Ability to participate in the network from your phone. Web Explorer - 11,158 lines: Next.js 15 application. PostgreSQL synchronization. Real-time updates. Search by blocks, transactions, addresses. Explorer Backend — 1,939 lines: Sync service, database, rate limiting, monitoring, security middleware. INFRASTRUCTURE 20,000 lines of Python. infrastructure/qnet-node (11,737 lines) — API servers, economic model, discovery, security development/scripts (8,287 lines) — deployment, testing, benchmarks, monitoring TECHNOLOGY STACK Backend: Rust, Tokio (async runtime), Quinn (QUIC), RocksDB, Bincode, pqcrypto-dilithium Frontend: Next.js 15, React 19, React Native 0.76, TypeScript, TailwindCSS, PostgreSQL Infrastructure: Docker, Kubernetes, Prometheus, Grafana, TLS certificates TOKENOMICS Zero premine. Fair launch - everyone starts from zero. Rewards for running nodes. Ability to participate from mobile device. QNet is a full-fledged Layer-1 blockchain with quantum-resistant cryptography. ~200,000 lines of production code. 108 enterprise-grade mechanisms. Mobile app, browser extension, web explorer. Built by one person in 11 months of daily work. When you ask "when?" - remember that this is not a copy of someone else's code. This is a unique blockchain being built with decades ahead in mind.

QNet Blockchain: Development Report I expected to complete the reward system and full transaction functionality in a much shorter timeframe, but it turned out there were many more areas requiring optimization and fixes than initially anticipated. One important architectural note: according to the new design, rewards for the current epoch are distributed at the end of the following epoch. This delayed distribution model ensures all validator commitments are properly verified on-chain before rewards are calculated. The reward system and transactions are now nearly complete. The main reason this took so long is the testing cycle: after each build, I need to wait approximately 4 hours (one full epoch) to observe how the logic performs in practice, identify issues, make corrections, and repeat. This iterative process, while time-consuming, is essential for ensuring reliability. Thank you all for your tremendous support and belief in this project. Migration from Local Storage to On-Chain Logic A significant architectural shift during this period was moving critical validator data from local node storage and P2P gossip to verifiable on-chain transactions: HeartbeatCommitment Transactions Previously, validator heartbeats were stored locally on each node and shared via P2P gossip. Now, nodes submit HeartbeatCommitment transactions directly to the blockchain. This ensures: - Cryptographic proof of validator activity - Immutable record on-chain - No reliance on P2P message delivery for reward eligibility PingCommitment Transactions Validator ping proofs for Light node verification have been moved from local accumulation to on-chain PingCommitmentWithSampling transactions. Benefits include: - Transparent and auditable ping records - Elimination of local storage discrepancies between nodes - Deterministic reward calculation based on blockchain state On-Chain Node Registration Node registration data is now recorded directly on the blockchain rather than maintained in local registries synchronized via gossip. This migration eliminates trust assumptions, ensures all nodes have identical data for reward calculations, and provides full auditability of validator activity. Cryptographic Standards: NIST FIPS 202 Compliance Transaction signature verification has been migrated to SHA3-256 (Keccak) for full compliance with NIST FIPS 202 standards. The dual-hash strategy now uses: - SHA3-256 for all transaction signatures and cryptographic operations - Blake3 for Proof-of-History chains and internal performance-critical hashing Additionally, the hybrid signature system combining Ed25519 (classical) with Dilithium3 (post-quantum) has been fully integrated for consensus-critical transactions including HeartbeatCommitment and PingCommitment. Consensus Protocol Hardening Multiple critical fixes were implemented to ensure deterministic consensus and prevent network forks: - Epoch-Based Validator Set for deterministic producer selection - Zero Fork Guarantee through 5-layer macroblock protection - Per-round storage for commit-reveal consensus data, preventing round_override data loss - Emergency producer rotation with strict synchronization checks - Certificate extraction from VRF proofs for historical block validation - Round-based failover with unified SHA3-512 entropy source Network Resilience: QUIC Fallback System The latest release introduces a critical failover mechanism for network partitioning scenarios: When HTTP API (port 8001) becomes unreachable due to DDoS protection or rate limiting, nodes automatically fall back to QUIC transport (UDP port 10876) for: - Block existence verification during emergency failover - Peer reconnection when TCP connections fail - RequestBlocks and HealthPing message delivery Security measures include rate limiting (maximum 10 fallback requests per minute per node) and production metrics for monitoring fallback success rates. ShredProtocol Improvements Block propagation via ShredProtocol received significant attention: - Resolution of DashMap deadlocks in chunk assembly - Parallel broadcast with certificate grace period - Producer cache with asynchronous broadcast and automatic chunk repair - Producer certificate inclusion in SHRED_PROTOCOL chunks eliminating race conditions Explorer and Mobile Integration Production infrastructure for blockchain exploration: - PostgreSQL-based synchronization service with batch processing - Embedded RocksDB indexing for high-performance queries - Real-time WebSocket updates for transaction and block feeds - Genesis account handling and QNC balance integration in mobile application - Transaction type unification across Explorer UI Security Improvements - Replacement of all unsafe unwrap() calls with safe alternatives - On-chain slashing architecture replacing P2P-based slashing - Strict sync verification for emergency producer selection - Certificate validation for all historical blocks