Nulla

$NULLA team is now wrapping up Day 2 with this Ansible deployment of the two parachain collators that will be used in the coming days for stability checks.

We just completed day one of the 2-week plan. We’re currently building the wallets, management keys, and Ansible playbooks required to deploy the new version of the testnet. The deployment scripts will simultaneously upload the relay binaries across the new validator and bootnode set, and will be used for the overall management of the new $NULLA testnet infrastructure. These tools will also be shared with the community to help node operators properly deploy and manage their validators. nullascan.com/#/staking

github.com/NullaZK/nulla-… Shipping the operational layer for the Nulla Protocol testnet. These are the scripts we will run live to deploy last quantum updates on both chains — forkless runtime upgrades, parachain registration, and a cross-chain consistency auditor that checks the spend_tag/nullifier state across ProofHub and the RWA chain simultaneously. What's in this drop: * upgrade_proofhub_runtime.js — submits the WASM upgrade to ProofHub via sudo.sudo(system.setCode), waits for finalization, asserts spec_version == 109 * upgrade_rwa_runtime.js — same for the RWA parachain, asserts spec_version == 102. Includes a bug fix from this release: the version check was inverted and was silently reporting SUCCESS on failed upgrades. - audit_chain_state.js — queries both chains and runs 5 consistency checks: all spent spend_tags must have registered values, nullifier count must match or exceed spend_tag usage, Merkle leaves must match commitment counts, RWA purchase count must not exceed ProofHub nullifiers. - register_para.js — parametric parachain registration via parasSudoWrapper. Used to bring ProofHub (para 2000) and the RWA chain (para 2001) online.

github.com/NullaZK/nulla-… This is the receiving side of the $NULLA Protocol privacy flow. When a user completes a private purchase on the ProofHub parachain, an XCM Transact message is automatically dispatched to this parachain. The RWA Marketplace pallet records the purchase using the spend_tag scheme — replacing the old commitment field that could potentially be correlated with deposit events. No token transfer happens here. Payment is proven via ML-DSA-44 post-quantum signature on ProofHub. This chain only records ownership. QUANTUM CHANGES IN DETAIL -------------------------- 1. spend_tag replaces commitment in XCM dispatch (Phase 6) - Old: ProofHub sent `commitment` as the purchase identifier - New: ProofHub sends `spend_tag = BLAKE3("nulla_spend_tag_v1" || pk_bytes)` - The RWA chain stores spend_tag in ProofHubPurchaseRecord — no field links back to the deposit commitment visible on ProofHub - A chain analyst observing both chains cannot join the deposit event to the purchase record even with a quantum computer 2. Ownership commitment — BLAKE3 with domain separation - ownership_commitment = BLAKE3("nulla_rwa_ownership_v1" || rwa_id || blinding) - Stored in ProofHubPurchaseRecord at purchase time - Verified at claim time: buyer supplies blinding, pallet recomputes and compares - BLAKE3 is collision-resistant against quantum Grover at 128-bit security 3. xcm_record_purchase — sovereign-origin gated (call_index 4, pallet_index 51) - Only the ProofHub sovereign account can call this extrinsic - Enforces: asset registered, asset not already sold, correct origin - Parameters: rwa_id, buyer, spend_tag, nullifier, tx_id, ownership_commitment 4. Nullifier enforced on both chains independently - ProofHub marks NullifierUsed at purchase - RWA chain stores nullifier in ProofHubPurchaseRecord - Double-spend requires compromising both chains simultaneously RESULT ------ An observer watching both ProofHub and the RWA chain sees: - ProofHub: spend_tag (opaque BLAKE3 hash), nullifier - RWA chain: spend_tag (same opaque value), ownership_commitment There is no field that links the deposit commitment on ProofHub to the purchase record on the RWA chain. Identity is unlinkable by design.

This release hardens the $NULLA Protocol against quantum adversaries at every layer of the purchase flow. github.com/NullaZK/nulla-… This release hardens the Nulla Protocol against quantum adversaries at every layer of the purchase flow. Classical signatures (Ed25519, ECDSA) can be broken by a sufficiently large quantum computer running Shor’s algorithm. Any protocol that uses them to bind a deposit to a purchase leaks a traceable on-chain link, even with mixers or ring signatures, because the public key is the binding element. We replaced the entire signature stack with FIPS 204 post-quantum primitives and redesigned the deposit–purchase binding so that no on-chain link exists at all. QUANTUM CHANGES IN DETAIL: 1. ML-DSA-44 (FIPS 204) — lattice-based signatures - Public key: 1312 bytes | Signature: 2420 bytes - Replaces Ed25519/ECDSA throughout the proof flow - Verification runs in the pallet via the fips204 crate (no_std) - deposit_public stores the ML-DSA-44 public key hash, not an elliptic-curve key 2. Spend_tag unlinkability (Phase 6, this release) - Spend_tag = BLAKE3("nulla_spend_tag_v1" || deposit_pk_bytes) - The deposit is keyed by a commitment; the purchase is keyed by spend_tag - These two values share no on-chain fields—a chain analyst cannot join the deposit row to the purchase row, even with a quantum computer - SpendTagValues storage: spend_tag → deposited amount (written at deposit) - SpendTagUsed storage: spend_tag → bool (written at purchase) - The nullifier is still enforced separately for double-spend prevention 3. BLAKE3 commitments with quantum-safe domain separation - commitment = BLAKE3("nulla_commitment_v1" || pk || blinding) - spend_tag = BLAKE3("nulla_spend_tag_v1" || pk_bytes) - purchase proof = BLAKE3("nulla_purchase_v1" || ...) - ownership = BLAKE3("nulla_rwa_ownership_v1" || rwa_id || blinding) - BLAKE3 remains collision-resistant against Grover’s algorithm at ~128-bit security 4. verify_purchase in the verifier library - Reads bytes 0..32 from public_inputs as spend_tag (SCALE-invariant) - Derives the expected spend_tag from the ML-DSA-44 public key - Compares them, then runs full ML-DSA-44 signature verification - Any classical or quantum forgery attempt fails both checks independently.

What comes next before we share the code and move to testnet: This work was done on the dev chain. Before we push to the official testnet and open-source the updated code we need to: Update the desktop wallet to use #quantum-safe keys end-to-end for private notes (key generation is already in place, encryption of notes is the next step) Align the RWA parachain with the same cryptographic standards Once both are ready we will do a proper coordinated release, code, testnet deployment and full documentation together.

We have been working on one of the most important long-term upgrades to the $Nulla protocol: making the ProofHub parachain quantum-resistant. Today we want to share what we have accomplished so far. What we changed: The core of ProofHub is the verifier, the piece of code that runs inside the blockchain and checks that every private transaction is mathematically valid. We have replaced the original cryptographic primitives with quantum-safe alternatives: ML-DSA-44 (NIST FIPS 204 standard) replaces the classical signature scheme for balance proofs BLAKE3 replaces the elliptic-curve-based commitment scheme STARK proofs (Winterfell) replace the classical range proof system All three run entirely inside the on-chain WASM runtime, no off-chain trust assumptions. What we tested: We ran a full end-to-end test on our dev chain: a real transaction that generates a quantum-safe keypair, creates a BLAKE3 commitment, produces a STARK range proof, and submits everything as an unsigned extrinsic. The chain verified all three layers and emitted ProofAccepted on-chain. We are sharing a short video of this test running live.

github.com/NullaZK/NULLA-… Desktop wallet release!

From this evening, you will be able to use the new version of the desktop wallet, which includes the first stage of quantum shifting implemented by the NULLA team.

Just committed an audit report about parachain runtime upgrades. this test was important to be sure that we are able to change runtime of the parachains during the future avoiding breaking blocks. github.com/NullaZK/nulla-… $NULLA

Sunday update: We’re exploring several upgrades to strengthen our system’s security and future-proof its cryptography. Here’s what’s currently on the table: • QRNG-based entropy for improved randomness • Hash-based commitments (moving toward SHA3/BLAKE3) • CRYSTALS-Dilithium for post-quantum signatures Our focus is on pragmatic, incremental improvements that deliver real value without disrupting the existing chain. More updates soon as we validate and implement these enhancements. $NULLA

New Audit report update: github.com/NullaZK/nulla-… $NULLA

This report documents a planned restart and recovery test on the Nulla Relay Chain under a deliberate MAX_FINALITY_LAG finality stall scenario. The objective was to validate that operators can reliably detect the stall from node logs, execute a targeted purge-and-resync of a single validator, and restore GRANDPA/BEEFY finality without a chain wipe or genesis restart. The test confirmed that a 500‑block unfinalized fork caused by an approval-voting database gap is fully recoverable via a single-node database purge, full sequential sync, and subsequent election reset using staking.forceNewEra(), with no loss of finalized history and normal finality lag restored within approximately 90 seconds. We needed this confirmation to continue with auditing and fault‑proof testing. github.com/NullaZK/nulla-… $NULLA

We have registered the first RWA parachain. This will be used to test the private note workflow cross-chain. What we will do next is deploy a dApp where users with the Nulla faucet can interact with simulated RWAs, exchanging them using private notes with cross-chain messaging. Everything is maintained by the ProofHub parachain and orchestrated by Nulla-Relay. As you can see from this link: nullascan.com/#/parachains both parachains are included, and we have opened a channel between them. Stay tuned for future updates. $NULLA

After these first days of monitoring the stability of the relay, we are ready to deploy the second parachain that will bring $NULLA to life. In the next few days, we will register a simulation of the RWA parachain that will communicate with the ProofHub for the locking of assets and the generation of the private note. We will then be ready to test and audit the private note workflow between the parachains. This message shows a successful initial test of cross-parachain messaging.

The parachain collator is finally producing blocks and being included in the relay chain, thanks to our healthy set of validators. You can monitor parachain inclusions on our explorer: nullascan.com/#/parachains⁠ $NULLA

The first two community-run nodes are live. We can now begin the parachain testing phase. As soon as the validator set is active on the network and the parachain starts producing blocks, we will share updates on the progress of the audit and roll out monitoring and testing dashboards for the community. You can monitor the validation process on our explorer: nullascan.com/#/staking⁠ $NULLA

The subscription dashboard is now open. Please follow the validator onboarding guide: github.com/NullaZK/nulla-…⁠ Dashboard: nullafaucet.com⁠ $NULLA

UPDATE: We have just updated all instructions for this first faucet run on our official GitHub: github.com/NullaZK/nulla-…⁠ The registration portal opens Monday, March 2 at 10:00 AM EST and closes 48 hours later on Wednesday, March 4 at 10:00 AM EST. There you will find all the information needed to participate in the testnet validator set, along with additional details about upcoming updates. $NULLA

Roadmap update! We have just released the Nulla custom extension that users need to interact with the testnet: github.com/NullaZK/NULLA-… We also included a brief tutorial explaining how to upload the extension to the Chrome browser: github.com/NullaZK/NULLA-… For now, we ask users to run the extension in Chrome developer mode. Our plan is to publish the extension officially on the Chrome Web Store before going to mainnet. We have also prepared the faucet dashboard, which will be activated tomorrow (Monday) at 10 AM EST. Faucet registration will remain open for 48 hours. Tomorrow we will release complete documentation explaining what you need to prepare in order to qualify for the faucet request. Stay updated $NULLA