Boreas Protocol Upgrade

On 10 June 2026 we hard-forked Dusk mainnet with Boreas, the upgrade in the Rusk 1.7 release line. It reworked how transactions are represented and how the network executes them, and restarted the chain from block 4,414,095. New Phoenix (shielded) transactions were paused at the restart.

Boreas was the second and larger of two protocol upgrades we shipped in 2026. Aegis came earlier in the year and concentrated on security and cryptography; we wrote that one up separately. Boreas changed the protocol itself: how transactions work and how the network runs them.

What changed at the fork

Transaction forms

Before Boreas, the same transaction could be read in slightly different ways inside a node. Boreas settled on one clear definition of a transaction, from what a wallet submits to what gets written into a block, so every node now reads them the same way. Older Aegis-era transactions are still accepted, and every node keeps what it needs to replay the full history of the chain.

Fork-aware execution

The execution rules became version-aware too. After Boreas, every honest node arrives at the same result for a new block, while blocks from before the fork still replay exactly as they always did. A fork is the moment that consistency is easiest to lose, so the switch is handled carefully, by protocol version.

Ordering and reverted events

Boreas also tightened two finer rules. Slashing now applies before transactions within a block, so stake can't be moved ahead of a pending slash. And reverted contract events are recorded explicitly, with a clear marker, so anyone indexing the chain reads them as reverted instead of assuming every stored event counted.

Pausing new shielded transactions

Phoenix is our fully-shielded, private transaction model; Moonlight is the public, account-based one, and it stayed open for new transactions. As a precaution, we paused new Phoenix transactions at the restart while we finished a round of hardening on the shielded side, which shipped in the PLONK 0.24 and Phoenix circuits 0.9.0 releases. Phoenix isn't removed: every node keeps its full history and can still sync the chain from genesis. It's simply paused at the point of accepting new shielded transactions.

On testnet we ran the same change on a different schedule first, applying the pause later so we could watch the transition under real load before it reached mainnet.

A coordinated restart

Most upgrades switch on at a pre-agreed block height. Testnet worked that way, activating at height 3,378,000 on 27 May. Mainnet used a coordinated restart instead: it resumed from block 4,414,095, reusing the existing chain, so the first block kept its 6 June timestamp even though the new rules went live on 10 June.

Node operators upgraded to 1.7.0 before activation. Wallets and integrations didn't all have to move at the same time, because Rusk still accepts the previous transaction format, so the upgrade didn't force the whole ecosystem to cut over on one day.

Rusk 1.7 also did the quieter groundwork a safe fork depends on: full block headers became the source of truth for how state is committed, finalized and reverted; replacing a pending transaction now requires a higher gas price; and the node's HTTP interface gained access controls and rate limits. And we ran a full replay test across both 2026 upgrades, with real data, confirming every historical block still replays correctly under the new code.

For the full scope of Boreas, component by component, see the Boreas upgrade overview and the Rusk 1.7.0 changelog.