Barnard 1.10 Protocol Upgrade

Description

Barnard adds self-governance capabilities, being the second of two essential upgrades on the way to Supernova. While Andromeda halved block-finality time, Barnard focuses on governance hardening, data-layer performance, fee economics optimizations and app adaptations for the planned 600ms blocktime reduction.

What does Barnard change?

• Governance improvement

  • Proposal creation - any wallet can open a proposal by bonding 500 EGLD for the duration of the vote. If the proposal fails with VETO, the entire sum is forfeited; otherwise the full bond is returned.

  • Voting - votes are ordinary transactions with vote data (yes, no, abstain, veto). The voting power is calculated based on staked EGLD plus any liquid-staking positions. Wallet UIs (Web Wallet, xPortal) handle the raw transaction construction. Also https://governance.multiversx.com will become usable for both initiating proposals and voting.

  • Quorum & passage - a proposal passes if (i) quorum ≥ threshold, (ii) YES > NO, (iii) YES ≥ pass-threshold % of total votes, and (iv) VETO stays under its fail threshold.

  • After Barnard - the governance contract will manage closed proposals and stale user votes, and let proposers cancel drafts before voting starts.

• Sequential account-storage iterator - new /address/iterate-keys endpoint lets users be more efficient when iterating over data tries.

• New gas-penalty factor - the “max higher gas factor” is now dropped from 10× to 2×, so the penalty for excess gas kicks in at a more realistic threshold and developers should evaluate twice before making any transaction.

• Blockchain Chronology VM Hooks - up until now we were dealing with timestamps in seconds and should have been enough. Supernova brings sub-second rounds, therefore we need better time management inside apps moving from seconds to milliseconds.

• Miscellaneous improvements - Go 1.23 tool-chain, VM hook extensions, automatic node-activation handling, GitHub CI optimizations, heartbeat simulator, and dozens of minor fixes.

Key benefits of Barnard

a. Advanced governance features - Framework for EGLD holders to propose protocol changes. Includes automatic cleanup to prevent stale proposals and vote bloat.

b. Developer-friendly pagination – dApps can stream account-state without timeouts or pagination workarounds.

c. Fairer gas-penalties – stricter in handling abusive gas limits; honest users don’t have to bid excessively just to compete with those who misuse block space.

d. Lean codebase & faster builds - Go 1.23 and workflow optimization.

e. VM hooks for advanced features – new reserved-function flags and transfer-with-error support open room for improved smart contracts.

f. Foundation for Supernova - Barnard’s governance, VM time hooks and fee adaptations are required before we drop the block time to 600 ms and enable parallel execution.

Testing and Testnets

Barnard 1.10.0 will be live on the public testnet for validators, builders, and users to test before mainnet rollout. Spin up a node, point your tools to the testnet explorer, and share feedback in Agora.

Read the full Barnard 1.10.0 changelog: https://agora.multiversx.com/t/barnard-release-rc-v1-10-0/499

Frequently Asked Questions

What is governance?

Governance democratizes decision-making, enabling interest alignment for all parties participating by allowing them to have a say in the future directions of the protocol.

Who can vote?

Voting power is based on the amount staked. All users holding at least 1 EGLD staked, averaged over the snapshot interval (May 23–June 1st), are eligible to vote.

IMPORTANT NOTE: The more staked EGLD you have during the snapshots period, the higher your voting power will be.

How many days will the vote last?

The voting procedure for this proposal will span over 10 epochs from June 11 to June 21.

How will the votes be cast?

Here are the 4 available voting options:

• Yes - You agree that the MultiversX Protocol should be updated with this release.
• No - You disagree that the MultiversX Protocol should be updated with this release.
• Veto - A ‘NoWithVeto’ vote indicates a proposal either (1) is deemed to be spam, i.e., irrelevant to MultiversX Protocol, (2) disproportionately infringes on minority interests, or (3) violates or encourages violation of the rules of engagement as currently set out by MultiversX governance. If the number of ‘NoWithVeto’ votes is greater than a third of total votes, the proposal is rejected.
• Abstain - will register your voting power as NEUTRAL to the switch - but even if it may seem unimportant, these votes actually help the proposal and thus put the power in the hands of the people who vote and care about the network. So we encourage users that don’t have a strong opinion to still vote, so that the decision for the proposal is made based on the governance votes rather than users who don’t bother.

How can the proposal pass?

In order for a proposal to pass it needs a simple majority, or otherwise said, more than 50% of votes should be YES votes.

Can I use my liquid staked EGLD in the upcoming governance vote?

Yes. LSTs eligible:

• sEGLD (Hatom)
• HsEGLD (Hatom)
• LEGLD (SALSA)
• xEGLD (XOXNO)

Held in your wallet at snapshot time.