Proposed Network Upgrade: Barnard 1.10

Why Barnard Matters

Andromeda (v1.9) taught MultiversX to run, halving finality and proving the network can move at higher speed. Barnard (v1.10) teaches it to think. With self‑governance embedded into the protocol, the community, not just the core team, decides how fast and in which direction we accelerate next.

Barnard also introduces a fairer fee model for the protocol, sub‑second VM timing hooks, and a handful of developer goodies that remove friction from building on MultiversX. Together, they form the final prerequisite for Supernova.

‍

Core of the Upgrade: Onchain Governance

Until now, protocol decisions happened via off‑chain discussion and one‑time votes via separate contract deployments. Barnard anchors the entire process on‑chain:

• Anyone can submit a proposal by bonding 500 EGLD for the duration of the vote. Spam costs real money; good ideas get the bond back.
• Voting power equals your staked EGLD plus liquid‑staking tokens (sEGLD, HsEGLD, LEGLD, xEGLD). 
• Pass criteria:
  
  • ≥ 20 % quorum
  • ≥ 66.67 % YES
  • VETO < 33 %
• Outcomes:
  
  • Pass / Fail (Normal) → bond refunded.
  • Veto → bond transferred to the Community Governance Pool.

Behind the curtain, a brand-new vote‑tracking structure (V3) cleans up related state bloat and closes proposals automatically, keeping the chain lean.

‍

Developer Quality‑of‑Life Upgrades

• Sequential account iterator: new /address/iterate‑keys endpoint streams large account tries without manual pagination.
• Gas‑penalty factor dropped from 10× to 2×: gas overestimations are penalized sooner.
• VM hooks go sub‑second: apps now receive millisecond timestamps, unlocking real‑time mechanics.
• Go 1.23 tool‑chain & CI tweaks: faster builds, slimmer binaries.
• Reserved‑function flags & transfer‑with‑error support: richer smart‑contract UX.

‍

Important Things to Know

Although this vote executes onchain, it still runs on a manually deployed governance contract. Barnard is engineered to make this the last time we rely on manual deployments. Once live, the full governance framework becomes native to the protocol, opening proposals to anyone, enforcing the 500 EGLD anti‑spam bond, raising quorum, and officially welcoming liquid‑staking voters.

‍

Voting timeline

Milestone: Proposal visible on Governance Portal

Date: Monday, June 9 (immediately after the epoch change)

Voting window: 10 epochs — expected June 9 – June 19

‍

Voting power & snapshots

Snapshot window: May 23 – June 1

Calculation: Linear average of staked EGLD + liquid‑staking tokens

Example: A wallet that held a constant 100 staked EGLD throughout the snapshot interval receives 100 governance power.

‍

Quality & safety

Barnard v1.10 has passed multiple internal test cycles: end‑to‑end, integration, differential, smoke, chaos testing across several engineering teams. It is widely regarded as the upgrade that completes decentralization on MultiversX and prepares everyone for Supernova.

We are on track to upgrading the Public Testnet with it around the publishing of the proposal on governance.multiversx.com

‍

DNS V2 and Instant Staking Provider Transfers

These two community‑requested features are already coded but will not be included in Barnard:

DNS V2 – transferable Herotags & .mvx domains
Herotags finally become NFTs that you can trade, lease, or gift, and each tag maps 1‑to‑1 to a human‑readable .mvx domain. Wallets, dApps and explorers should be ready to resolve them out‑of‑the‑box, which would have required significant effort that is not a priority right now.

Instant staking‑provider‑to‑provider transfers (with 30‑day cooldown)
Stakers will be able to migrate their delegation from one provider to another without the unbonding period, waiting or missing rewards. A single transaction triggers the move; rewards continue to accrue during a 30‑day cooldown before the delegator is able to move the funds again.

Why not ship them now?
In short: Supernova first. Activating either feature would have added at least a month of extra testnet soak time, pushing back the sub-second milestone. We chose to fast‑track the core protocol upgrade and revisit DNS V2 and provider swaps immediately after Supernova lands on mainnet.

No action required for now, you’ll see the governance proposals to enable both features once Supernova proves stable.

‍

Conclusion 

Barnard v1.10 introduces on-chain proposals, refined developer tools, and lays the groundwork for Supernova, empowering both builders and community members to actively shape the protocol’s future. As the vote goes live, the direction of the network is no longer just a technical matter; it becomes a collective decision.

Join the discussion on Agora and mark your calendars for June 9 to vote on the proposal.