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.

🎂 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 👀

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.

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.

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.

Super-node onboarding is finally complete - along with a lot of other work I'll share more about soon.
Now it's time to observe and test how the network runs after onboarding.
I'm genuinely happy to finally have visible progress to show, and to share it with you.

QNet - what's been done over the last 3 months

It's been quiet - because the work went into rebuilding the foundation, not cosmetics. The facts:

1. Consensus core rewritten → Checkpoint-BFT v2
The old macroblock consensus was three-phase (commit → reveal → finalize) with fixed ~12+12+6 sec windows and heavy post-quantum signatures collected at every phase - both slow (~30 sec per macroblock) and fragile (desync at phase boundaries → occasional forks and stalls). Replaced with a single-round Checkpoint-BFT v2: instead of three phases, one 2f+1 quorum certificate (QC), with no fixed windows and no dependence on clocks; producer selection is deterministic, and forks are impossible by construction. Post-quantum BFT on Dilithium / ML-DSA.

2. Scale - to millions of nodes
Emission and the node registry were rewritten to O(1) operations (previously the cost grew with the number of participants). The architecture is designed to hold millions of light nodes and super-nodes without degradation.

3. Security
Several audit rounds (120+ fixes), node identity-binding, and fail-closed key handling from the mnemonic.
4. Node onboarding
Solved the problem of a new node joining a live, running network without disruption. The first real super-node is connected.

By the numbers:
150 commits
168 files changed (21 new, 1 removed, 145 reworked)
+53,611 / −38,944 lines

Huge thanks to everyone for your patience. What's left: test reward claiming by a super-node, finish the node-update mechanism, and run my own final audits before the testnet launch.

Testing the full integration of a super-node with the mobile app - including reward claiming - and debugging all the processes.

Super Node rewards are LIVE.

Claim and receive your QNC rewards straight from the mobile wallet - one tap, on-chain verified, post-quantum secured.

QNet Wallet - early access on Android (APK)

I've decided to open early access for light nodes - just through the APK. That gives you a few days to test it out while I finish a round of fixes: audit items, plus removing all the non-quantum signature paths that blockchains normally use, so QNet stays fully post-quantum.

On the official launch: I've set up an LLC and I'm waiting on the documents to finish Apple's D-U-N-S verification. Once that paperwork clears, QNet goes live officially on both Google Play and the App Store.

Test tokens: https://aiqnet.io/testnet

Made a wallet during earlier testing? Create a fresh one - the wallet format changed, so old wallets may not import correctly and can come up invalid.

Important: In the faucet, enter your Solana wallet address - not your QNet address.

Then, in the mobile app, select Light node and tap Get activation code.

Once you receive the code, go to the Node section and tap Activate node.

Strange - it looks like the current activations aren’t going through on-chain. I’ll look into what’s causing this.

Going forward, when the network is restarted, those who have already burned and activated will only need to restore their activation code. Re-burning coins won’t be necessary.

I’m closing this topic for good - but first, I want everything to be completely clear.

I fund all of the development myself. Servers, AI tools, domains, company registration - I pay for all of it out of my own pocket. The only income this project currently brings me is the trading fees on pump fun. And right now, that isn’t even enough to cover development costs together with the bare minimum for rent and food.

I am an investor in this project just like you are, and I have never claimed that I wouldn’t sell my own tokens. Once every two weeks I sell a small portion - around 1 million tokens. This is not a dump, and it is not market manipulation. It’s what allows me to keep working on the project instead of looking for income elsewhere. And I do it openly, in plain sight, not through separate wallets.

For a year and a half I have lived this project - no days off, months on end, giving it everything I have. If someone believes I’m obligated to follow unwritten rules I never signed up for, that’s their right. But my responsibility lies elsewhere: to see this project through. And to do that, I need to stay standing - both physically and mentally.

Now, about what actually matters.

This project is my creation and one of the main goals of my life. I’ve already brought it almost to MVP, and I will see it through no matter what. That is not up for debate.

I’m genuinely grateful to everyone who holds and understands that there is real work behind this, not empty promises. It’s your support that keeps me from burning out on the final stretch. We’re already close - and I intend to make it. Thank you for being here.

QNet - testnet status

The previous testnet run stayed up for a few days and then stalled: in a rare scenario at an epoch boundary, finality stopped advancing and the network couldn't recover on its own.
So instead of slapping on a patch, I'm reworking consensus so this class of freezes is gone at the protocol level rather than papered over. That's the main reason for the delay.

Since I'm starting from a clean genesis anyway, I also folded in the things that can't be added after launch:
• full post-quantum security - ML-DSA-65 (FIPS-204) signatures and post-quantum transport;
• on-chain tokens and smart contracts - a token standard, mint/burn, a deterministic WASM VM.
Where I am now: I'm putting the consensus changes through their paces. The automated tests and audits pass, but the real test is live - new issues can still surface, and I'll fix them as they do. What's left is to bring up a fresh network and run it through many epoch boundaries - exactly the conditions where it used to freeze.

On timing: Once the network runs stably for several days with no freezes, I'll launch and open onboarding for light nodes and super nodes.
Thanks for waiting. I'm choosing the right launch over a fast one.

New wallet addresses in the new launch

I moved the wallet to post-quantum cryptography - ML-DSA-65 (FIPS-204) signatures. Because of that, your address changes.

A QNet address = hash of the public key, and the key is derived from your seed phrase through the signature algorithm. I changed the algorithm → the same seed phrase now yields a different key → a different address. I also fixed a mismatch, so the app and the node now produce the same address.

So in the new launch:
• update the wallet once I post the new version;
• request test tokens again from the faucet - to the new address;
• re-do node activation.

Your seed phrase doesn't change - same mnemonic.

“Reworking consensus” doesn’t mean rewriting it.

The core and consensus are built right - the design stands. The freeze was one rare edge case at an epoch boundary, not a flaw in the foundation. What’s left is closing that gap at the protocol level and catching the remaining edge cases so nothing else can stall the network.

No rebuild, no starting over - just finishing the last loose ends before launch.

QNet - what's been done this round

Three weeks on reworking consensus.

The cause of the stalls was a class of bug, not a single one. Some consensus decisions depended on what a node happened to hold on its own disk rather than on the block height, so two honest nodes could derive different participant lists and diverge - finality stopped with no attacker involved. Every such place is gone: elections are now a pure function of confirmed data, identical on every node. Alongside that, the specific epoch-boundary mechanisms: the participant set was sampled at the boundary while activity proofs stay admissible for another 90 blocks, the "is emission due" check returned a false yes at the very first boundary and the chain stopped ~4 hours in, and nothing actually required the emission at its height - a producer that couldn't build it shipped a valid empty block and the epoch lost both the issuance and its reward root.

A stall is no longer a dead end. Before, when finality stopped, production died three minutes later and there was no way out: recovery needs fresh activity proofs on chain, and those can't get there while production is stopped. Now the network keeps producing for ~48 more minutes on a frozen participant set that is identical everywhere, with no risk of splitting into two chains, and the set shrinks to drop the silent ones so the quorum threshold becomes reachable again. To be straight: making stalls impossible isn't achievable in any network of this type - if more than a third go quiet, finality stops, that's mathematics. What's removed are the reasons we stalled.

One nasty find. An honest producer that re-issued a block after a rollback could be banned on chain permanently, with no attacker present. And the reverse: a small detail in signature parsing let anyone fabricate a valid ban against any producer, and two of those were enough to stop finality for good. Rewritten.

Entry had a hole. Activation codes are tied to a wallet, but that check lived in the application, not the chain - a hand-built registration transaction sent straight to the network bypassed it. And the attestation step signed a binding to whatever beneficiary the caller named, with nothing proving they owned the wallet that actually burned, so anyone who saw a public burn on Solana could collect a legitimate quorum naming themselves. Ownership is now proven cryptographically on chain, and one burn activates exactly one node - previously a single entry could bring up both a super and a light node.

Rewards split 25/75 between operators and users.

Scale and hardening. Consensus messages went from ~3 MB to under 2 KB, registration attestations are collected in parallel (without it, onboarding at scale physically couldn't finish in time), the reward computation fits in memory for millions of recipients, and the state tree moved to disk. Around 250 places closed where a single request could take a node's process down; key substitution over the network removed; transport bound to its session against replays. Claiming rewards now requires the recipient's signature - an unsigned request could previously strip a wallet of all past earnings irreversibly. Storage rewritten: competing blocks at the same height are kept rather than discarded, and every check that quietly returned a partial result on a read error now stops instead of computing a wrong root.

As you may have noticed, rewards are now split 25/75 between operators and users.

The distribution model has been reworked in favour of server nodes. There are orders of magnitude more light clients than operators, and under an even split a server running around the clock earned the same as a phone. A separate share for operators brings the reward in line with what they actually carry. It barely affects users - precisely because there are so many more of them.

Beyond that, super nodes will require a mandatory stake - QNC locked for as long as the node runs.

This also creates the first real market for QNC: light clients earn it, prospective operators need it. Closer to that point I'll open a venue for direct peer-to-peer deals between people looking to buy or sell at the early stage.

First I run in the current system: the network runs, onboarding works under the current rules, node updates work. Then I relaunch with the stake - with the terms published in advance.

I measured QNet's real TPS. Here's the honest number — and why my old numbers were wrong.

The throughput figures I published earlier were what most chains actually publish: a lab benchmark — one node, localhost, transactions pumped straight into the engine, no network between machines, no finality. That measures how fast a single process can chew transactions. It's not a blockchain number. I've dropped it.

What I measured instead. A live 5-node testnet on ordinary budget VPS (~€10/month class; the weakest are plain 8-vCPU machines with slow disks) — real network gossip between five independent machines, producer rotation every 30 blocks, failover armed, post-quantum signature verification on every node, deterministic re-execution of every block by every validator, a Merkle state root every block. A transfer only counts when it is finalized by a BFT checkpoint — not when it lands in a mempool, not when it's merely included.

Result: 13,000 finalized transfers per second, sustained for 10 straight minutes. 99.8% of everything submitted was included AND finalized, on 1-second blocks (the 12k rung ran 932 blocks in exactly 932 seconds), hard finality ~109s median. Peak in 5-minute windows: 16,000/s. Push harder and the network degrades gracefully — it queues and self-drains, no forks and no network halt. 13k is the honest sustained ceiling of €10 machines, found by stepping the load up until it broke and confirming the last step that held.

Single transactions (one post-quantum signature each): ~450/s on this hardware. Not a design flaw — the price of quantum safety. An ML-DSA-65 signature is 3,309 bytes, and no standardized batch verification exists for ML-DSA — each signature verifies individually. For scale: one such signature doesn't even fit in Solana's 1,232-byte packet.

This is where QNet's architecture earns its keep. Batch transfers put up to 1,000 payments under ONE post-quantum signature — 3.3 bytes of signature per transfer. Every batch is signed and verified with plain, unmodified FIPS 204 ML-DSA — no custom crypto, the signature simply covers more payload. That's what makes PQ crypto practical at scale today, and it's why a network of €10 VPSes moves 13k quantum-safe transfers a second while a PQ-retrofitted classical chain would manage an estimated ~2-4k.

Potential: signature verification and block application scale with CPU. On Solana-validator-grade servers the same code projects to ~5k singles and 40-80k batched transfers per second.

What's next. The rolling node-update system and super-node onboarding are done and hardened. What's left is consensus soak-testing: if it runs clean for several days straight, I'm opening the testnet. The LLC is also nearly ready — which unlocks publishing the mobile apps to the stores.
Every number above is reproducible end-to-end over public RPC: submit → include → finalize.