Boreas
Boreas was a broad transaction, execution, and state-transition upgrade delivered by the Rusk 1.7 release line. It first activated on testnet and later became the protocol boundary used for the coordinated mainnet restart.
Activation
Section titled “Activation”| Network | Activation time (UTC) | Activation height | Required Rusk | Release line |
|---|---|---|---|---|
| Testnet | May 27, 2026, 13:03 | 3,378,000 | Boreas-capable 1.7 RC | Rusk 1.7.0 |
| Mainnet | June 10, 2026 deployment | 4,414,095 | 1.7.0 | Rusk 1.7.0 |
Testnet reached its configured activation block before the final 1.7.0 release. Mainnet resumed from block 4_414_095 during the coordinated June 10 deployment. Because that restart reused an existing chain snapshot, its first block retained a June 6 header timestamp; June 10 is the date the Boreas rules actually went live on mainnet.
Phoenix disablement followed a separate testnet schedule:
| Network | Activation time (UTC) | Height | Behavior |
|---|---|---|---|
| Mainnet | June 10, 2026 deployment | 4,414,095 | Phoenix disabled with the Boreas restart |
| Testnet | August 7, 2026, 12:54 | 4,000,000 | Phoenix disabled after the Boreas trial period |
Protocol Changes at the Fork
Section titled “Protocol Changes at the Fork”Canonical and versioned transactions
Section titled “Canonical and versioned transactions”Boreas introduced explicit boundaries between transactions accepted from clients, their canonical in-memory representation, and the ledger format committed into blocks. Rusk now:
- decodes live ingress according to the active protocol version;
- accepts legacy Aegis envelopes at the network boundary and normalizes them;
- canonicalizes locally sealed transactions before committing them; and
- retains the historical decoders needed to replay pre-Aegis and pre-Boreas blocks.
This prevents the mempool, block producer, consensus validation, and historical replay paths from interpreting the same bytes under different transaction rules.
VM execution and gas accounting
Section titled “VM execution and gas accounting”Boreas changed consensus-critical execution policy in several places:
- deployment gas checks and initialization charging became fork-aware;
- SHA-256, KZG verification, secp256k1 recovery, and Keccak host queries use the network’s configured activation and pricing rules;
- hash-query gas is charged from the amount of input processed;
- VM cache keys include the active hard-fork and verifier semantics; and
- reference-type deployment validation is selected from the historical feature timeline.
The gates preserve the old behavior for replay while making post-Boreas gas accounting deterministic across nodes.
State-transition ordering
Section titled “State-transition ordering”After Boreas, slashes are applied before transaction execution. This closes a same-block ordering case in which stake could otherwise be changed before the pending slash was applied. Pre-Boreas blocks retain their original ordering during replay.
Reverted-event semantics
Section titled “Reverted-event semantics”Boreas made reverted contract events explicit across execution, block headers, archive storage, and provisioner updates:
- reverted events are retained with a
revertedmarker for archive consumers; - they are removed from the canonical block bloom after Boreas; and
- reverted stake events are excluded from the provisioner’s state updates.
Historical event decoding remains supported so existing archives and old blocks can still be read.
Phoenix retirement
Section titled “Phoenix retirement”Mainnet disabled new Phoenix transactions at the restart boundary. Nodes still keep Phoenix decoding and historical execution support because old blocks must remain replayable. Testnet kept Phoenix available beyond its Boreas activation and disabled it later at block 4_000_000.
The disablement applies at transaction admission and execution boundaries. It does not erase historical Phoenix state or remove the code required to synchronize the chain.
Node and API Changes in Rusk 1.7.0
Section titled “Node and API Changes in Rusk 1.7.0”The release also shipped operational changes that were not all direct fork-height rules:
- full ledger headers became the source of truth for VM session commit, finalization, revert, and provisioner queries;
- startup recovers the current tip header from the chain database;
- future-nonce Moonlight transactions can be queued during HTTP propagation;
- mempool replacement requires an improving gas price;
- HTTP ingress gained ACL and endpoint-class rate and concurrency limits;
- wallet and wallet-core gained Boreas-compatible transaction, deployment, and history handling; and
- the compatibility replay suite began exercising filled state and transactions across the Aegis and Boreas boundaries.
Operator and Developer Impact
Section titled “Operator and Developer Impact”Operators had to upgrade before the activation applicable to their network. Mainnet’s change was a coordinated restart rather than an ordinary future-height transition.
Clients may continue to submit supported Aegis transaction envelopes because Rusk normalizes them at live ingress, but blocks use the active canonical ledger format. New Phoenix transactions are rejected after the network-specific disable height; Moonlight remains the supported transaction model. Archive and indexer consumers should use the reverted marker rather than assuming every stored event contributed to canonical state.
For current node maintenance procedures, see Upgrade a Node.