Status & Roadmap

This page is the single source of truth for what is live versus what is built but not activated. If another page disagrees with this one, this page wins — please open an issue.

Last reviewed: 2026-10-16 (mainnet height 261).

RougeChain is post-quantum-secured at the L1 level. The current production XRGE bridge remains on the hardened R1 architecture. A V3 XRGE bridge using ML-DSA-65 post-quantum authorization has been built and rehearsed; it is not deployed and awaits an external audit.

⚠️ Current node release: 1.6.8 (blocks 235, 245 and 260 have passed)

Mainnet activated mintable tokens and contract royalty reads at block 235, the monetary-integrity rule at block 245 (2026-10-05) and AMM_INTEGRITY at block 260 (2026-10-10). Every mainnet node must run release 1.6.7 or later to follow the chain (release 1.6.7). Release 1.6.8 (2026-10-15) fixes a bug that could stop a node producing and importing blocks while processing certain public NFT mints. It is not a consensus change, is recommended for every node, and is what the operator nodes run (release notes). Nodes installed with the one-line installer update themselves. The full schedule is in Upgrade schedule.

Suspended since block 245

The monetary-integrity rule makes a block invalid if it carries one of these transaction types: shield, shielded_transfer, unshield, token_lock, token_unlock, create_staking_pool, token_stake, token_unstake, create_proposal, cast_vote, execute_proposal, delegate, undelegate, token_approve, token_transfer_from. The features behind them — shielded transfers, token locking, token staking pools, on-chain governance and voting, vote delegation — are therefore not available, however an older page or client describes them.

• Why. Their ledger effects were applied without the state checks they depend on. The V1 shielded pool's proof established value balance only and did not bind a withdrawal to a specific note, and its prover has no zero-knowledge mode, so it did not deliver privacy. The other types were never used on mainnet. The mainnet shielded pool was empty when it was suspended; no funds are affected.
• What replaces them. A redesigned shielded pool (V2) is specified and in development: a Plonky3-based STARK with a hiding mode (proofs of about 190 KB, verify about 6 ms, prove about 3 s on a phone), launching under a 1,000,000 XRGE pool cap before the external audit. It is not audited, and nothing may claim audited privacy until it is. The other types are being rebuilt with their checks in consensus; no activation height exists. Token allowances are unaffected (approve / transfer_from stay enabled). Treasury decisions for Regenerate use the node-hosted votes in the meantime.

Earlier mandatory node upgrade (block 49)

If you run a RougeChain mainnet node or validator, you must upgrade. On 2026-09-18 mainnet activated a protocol upgrade at block 49 (bridge security hardening and a fix to validator-stake accounting). The upgraded code is on the public repository: rougechain-node main.

A node running a build from before 2026-09-18 may show the correct block height, but it executes blocks with the old rules and ends up with incorrect balances and validator state. There is no partial fix: upgrade and resync. Stake is unaffected — an un-upgraded validator simply is not participating.

sudo systemctl stop rougechain-validator
cp -a ~/.quantum-vault/mainnet ~/.quantum-vault/mainnet.backup     # keep a backup
cd ~/rougechain && git pull --ff-only
source ~/.cargo/env && cd core && cargo build --release --locked -p quantum-vault-daemon
mv ~/.quantum-vault/mainnet ~/.quantum-vault/mainnet.old
mkdir -p ~/.quantum-vault/mainnet
cp ~/.quantum-vault/mainnet.backup/node-keys.json ~/.quantum-vault/mainnet/
sudo systemctl start rougechain-validator

Paths and the service name are those of a source-build install (repository in ~/rougechain, data in ~/.quantum-vault/mainnet); adjust them to your setup. A node installed with the current install-validator.sh runs a signed release binary instead (/usr/local/bin/quantum-vault-daemon, with the rougechain CLI from the same release in /usr/local/bin/rougechain; data in /var/lib/rougechain/mainnet) and is upgraded by re-running the installer, which verifies the release signature before installing anything — see Signed releases. node-keys.json is your validator identity — keep it and never share it. A fresh sync takes under a minute.

Verify you are on the canonical chain:

• block 49 has hash 4c7ec92d9fc4dd24146036474128072d07d146d5cde93a0d31c0462eea895abb (curl -s "localhost:5100/api/blocks?limit=100")
• state_root from curl -s localhost:5100/api/stats equals the one at https://api.rougechain.io/api/stats at the same height

Live today

The production XRGE bridge still relies on classical (ECDSA / Safe multisig) authorization on the Base side. It is hardened, capped and monitored, but it is not post-quantum on Base. The ETH/USDC contract is owned by a single operator hot key. No bridge component has been externally audited.

Validators and staking, as they run today

Built and tested — NOT activated

Consensus redesign — decided 2026-10-06, NOT built

A redesign of consensus was decided on 2026-10-06. Nothing of it is implemented or scheduled; it is gated on a consensus simulator and an independent review, and will ship as staged forks A–E whose heights will be announced in advance. It supersedes the earlier "Release 2b" and "Release 3" plans.

FINALITY_V2_ACTIVATION_HEIGHT is 150 (active). V3_BRIDGE_ACTIVATION_HEIGHT is None: no activation height has been chosen for the V3 bridge.

Scope of V3

• V3 changes the XRGE withdrawal authorization path on Base to ML-DSA-65.
• qETH and qUSDC are outside the V3 scope. They stay on RougeBridge with classical Base-side authorization.
• The Bitcoin bridge is a separate system and is not part of V3. See Bitcoin Bridge.

Roadmap

Activation will be announced in advance with the exact block heights. Until then, nothing on this page in the "not activated" table protects user funds.