Blocknet’s Faraday upgrade explained

Follow Blocknet’s proposed Faraday upgrade and prepare the wallet, node and miner checks relevant to you. This guide incorporates the official October 27, 2026 explanation. Faraday is still being built and tested: the project says dates, figures and design details can change. Everything described below as a Faraday change belongs to that future plan.

What is the Blocknet Faraday upgrade?

How would privacy and spending proofs change?

The announced Faraday design replaces the elliptic-curve mechanisms protecting coins with post-quantum mechanisms. Spending would use hash-based proofs built with Plonky3, while wallets would detect incoming payments using ML-KEM. The project presents these as parts of the same upgrade. The current privacy guide explains the mechanisms on today’s network; it should not be read as a description of an activated Faraday network.

Today’s ring has 16 members. Under the new plan, a spend would hide among the full set of Faraday coins, which grows as coins enter that format. The announcement also describes combining individual spend proofs into a block proof, then discarding individual proofs after finality. These are design descriptions from the project, not features this guide has tested on mainnet. Follow the released implementation and its documentation as development progresses.

When is Faraday expected to activate?

The new announcement targets February 2027, near the first anniversary of mainnet, at block 103,680. The official overview gives an approximate February 16 date. The activation height and calendar estimate serve different purposes: actual block production determines when a height is reached, and testing can change the plan. Keep the project’s tentative status attached to both when making reminders.

The proposed migration period lasts one year after activation. Plan around the final activation and closing conditions that the project publishes, rather than assuming a calendar reminder confirms them. Record the official source and the date you last checked it. Revisit that record when a compatible wallet or core release appears; an article’s publication date does not mean the upgrade is already active.

How would existing coins migrate?

Faraday would continue the existing chain and its history, while holders move coins into the new format through their wallets. The announcement says the exact steps will be published before activation. It also proposes a wait of about one week before migrated coins can be spent again. Include that planned waiting period when preparing access to funds around migration, and verify the final wallet instructions before acting.

Coins left unmigrated after the one-year window would become permanently unspendable under the announced rules. Complete the documented migration within that window and check its result in the wallet. Keeping a wallet backup preserves recovery material, but does not itself migrate coins. No migration command is supplied here: use the procedure in the actual migration-capable release when it becomes available.

What happens to recovery words and addresses?

The official post says existing 12-word recovery phrases would continue working and new wallets would receive 24 words. For a wallet imported from keys that never had recovery words, the plan calls for creating a new wallet and moving coins into it. Check which recovery material your present wallet has and protect it now. The backup and restoration guide covers the currently released software, not future Faraday recovery commands.

The proposed Faraday post-quantum addresses are about 1,700 characters long. The announced ways to use them are copying, pasting and QR codes, with Blocknet ID names providing a shorter payment identifier. Follow the upgraded wallet’s address format when it is released and compare the resolved recipient before confirming a payment. A current address example should not be repurposed as a future-format test address.

How would block timing and rewards change?

The announcement proposes increasing target block time from 5 minutes to 10 minutes and doubling the block reward at the transition. Half as many target blocks with twice the reward would preserve the planned rate of coin issuance; it would not double the coins issued per day. The reward-schedule guide explains the current schedule. Future reward figures should always be read with their fork-month and timing assumptions.

The same proposal sets the maximum reorganization depth at 60 blocks and keeps newly mined coins waiting 60 blocks before spending. At the proposed 10-minute target, that wait corresponds to about 10 hours. Wallets would still wait 10 confirmations before marking a payment safe, corresponding to about 100 minutes. These are target-based estimates, not guaranteed deadlines: individual block intervals vary, and final release rules still need confirmation.

What should node operators and miners prepare?

Keep an inventory of your core version, network, data directory and dependent services. The announcement describes automatic node updates, but operators should still check their actual version policy and the release that implements the fork. The node guide covers current operation, including version pinning. Plan any required restart around wallets, explorers and pool services, then verify peers, chain progress and client reconnection afterward.

Mining also changes at the fork, and the announcement says it will have a separate post. It does not provide future seine flags, hardware rankings or a pool transition procedure. Use the current Argon2id guide and bntpool setup for today’s network. When compatible releases and transition instructions arrive, check the miner and pool together and verify fresh accepted shares after the instructed update.

Keep wallet migration and software updates separate

Use a short preparation record: where your verified backup is stored, which recovery material you have, the running wallet and core versions, and which official instructions still need to appear. Record node updates, miner updates and coin migration as separate tasks with separate completion checks. Downloading a release or seeing a node synchronize does not establish that your coins have migrated.

The official post describes ongoing verifier testing, comparisons between a reference implementation and proof circuits, and published benchmarking work. Those reports explain the project’s development process; the final release remains the source for operating instructions. Recheck the announcement as the schedule develops, update your reminders and record the wallet’s migration result when the workflow is available. Meanwhile, keep current backups and use the existing wallet guide for present-day operations.