Barnard Release - rc/v1.10.0

[schimih]

Contents

This document explains the contents of the release codenamed Barnard. It is split in 2 sections:

• the features list containing detailed insights of the feature along with the external impact and the relevant
  pull requests list
• the smaller features and fixes area contains the one-pull request small features or fixes along with the
  external impact details

This documentation is relevant for the rc/barnard branch.

Features

1. Governance updates #6490

This pull request introduces several enhancements and refactors to the governance smart contract:

• It adds stricter voting period validations, introduces a new mechanism for tracking and clearing ended proposals and user votes, and implements support for a new user vote tracking structure (V2) with backward compatibility for V1.
• Additional improvements include enhanced gas management, configurable voting delay, and more precise handling of proposal closure and results computation.
• Some redundant or outdated methods (like the old user vote history view) are removed, and formatting/percentage calculations are improved for accuracy and clarity.

It improves the governance smart contract by:

• tightening voting rules, adding better tracking and cleanup for proposals and user votes
• supporting a new vote tracking format (V2) while keeping V1 compatibility.
• improves gas use, allows voting delays, and refines how proposals are closed and results calculated.
• Outdated methods are removed, and formatting and percentage handling are more accurate.

Important details

Anyone should be able to submit proposal but it has to respect some rules:

• Off-chain - a proposal should be uploaded with at least 15 days on agora for debates and analysis.
• Submission - proposer has to deposit 500EGLD.
• Voting - 10 days.
• Settlement - by the contract.

Deposit return logic:

• Pass or fail normaly by NO voting → 500 EGLD returned to proposer.
• Veto → 500 EGLD transferred to “Community Governance Pool”.

Voting options:

• YES → counts in Quorum & “YES” → Implement the proposal
• NO → counts in Quorum & “NO” - > Reject the proposal but no slash
• Abstain → counts in Quorum & ignored for both YES or NO → I am neutral
• VETO → counts toward Quorum + veto → Reject and punish proposer.

Tally Rules:

• Quorum: AT LEAST 20% of total voting power (sum of all four voting options) must participate or the proposal fails automatically
• Acceptance threshold: YES/ (YES+NO+NO_WITH_VETO) >= 66.67%
• Veto: if VETO votes exceeds 33% of TOTAL PARTICIPATING voting power, the proposal is rejected and the deposit is transfered to Community Governance Pool

Impact:

• Configuration changes:
  • There are two new enable epoch definitions for this feature, called GovernanceDisableProposeEnableEpoch and GovernanceFixesEnableEpoch
• No Node CLI arguments changes
• No Node HTTP API endpoints changes

Relevant PRs:

• #5857 - Accept multiple delegateVoting
• #5877 - MaxVotingDelayPeriodInEpochs
• #5872 - Add gasUsage for changeConfig
• #5922 - Add clean method
• #6496 - Add cancel method before voting start
• #6868 - Float64 conversion issue fix

2. Accounts storage iterator #6547

This feature enables retrieval of tokens from a data trie in a sequential order, with the possibility of continuing from a checkpoint if the data trie has lots of leaves, thus iterating thorough all the leaves in multiple accesses.

Impact:

• No configuration changes
• No Node CLI arguments changes
• New node API endpoint was added, /address/iterate-keys

Relevant PRs:

• #6086 - Accounts storage iterator
• #6696 - Integrate new account storage iterator

3. Change penalise gas #6264

This feature brings a configurable maximum higher factor, modifying it from 10 to 2, so the penalization would apply starting from lower gas values provided.

Impact:

• economics.toml has a new entry for the FeeSettings called MaxGasHigherFactorAccepted that is now set to 2. Previously, this was a constant set to the value of 10.
• No Node CLI arguments changes
• No Node HTTP API endpoints changes

Smaller features or fixes

• #6511 - Update compiler to go 1.23
• #6932 - VM reserved functions activation flag integration [integrates mx-chain-vm-go #913]
• #6793 - Automatic activation of nodes disabled
• #6548 - New epoch start blockchain hooks
• #6893 - Add get ESDT token type vm hook [integrates mx-chain-vm-go #909]
• #6852 - Integrate transfer and execute with return error [integrates mx-chain-vm-go #907]
• #6791 - VM integration for backtransfers improvements [integrates mx-chain-vm-go #899]
• #6774 - vm integration for get all transfers value hook, get code hash hook and internal errors masking [integrates mx-chain-vm-go #895, #897, #898]
• #6327 - Check only dbs that are older than the given epoch
• #6518 - Optimize GitHub workflows
• #6519 - Optimize GitHub workflows
• #6612 - Heartbeats chain simulator
• #6997 - Fix epoch start trigger missing prev header

[metothex]

If I understand correctly, NO_WITH_VETO only counts for the deposit and only if it’s >= than the minimum NO (+NO_WV) required to reject the proposal?

If for a vote NO_WITH_VETO/(YES+NO+NO_WITH_VETO) is 34%, but NO_WITH_VETO/(YES+NO+NO_WITH_VETO+ABSTAIN) = 32% (and let’s say NO=0), then NO_WITH_VETO acts as a simple NO.

Also if NO_WITH_VETO/(YES+NO+NO_WITH_VETO) = 33.0% and NO = 0, the proposal is accepted.

I was expecting for NO_WITH_VETO to be more powerful (considering the “veto” word), for example if NO_WITH_VETO/(NO+NO_WITH_VETO) >= 50% and the proposal is rejected, then the proposer to be punished

[joaquim]

I would actually debate the opposite. No with Veto is already extremely powerful.
It allows to punish someone from making a spam/unproductive proposal and waste everyone’s time by taking their deposit.

But it’s not because a proposal isn’t accepted that it is inherently a bad one. It could simply be a controversial one or that the majority doesn’t align with it.
Doesn’t mean the person should be punished for it. Quite the opposite as it would deter people from submitting proposals.

Veto traditionally means that a single veto vote has the power to cancel a proposal, which isn’t the case here.
I would rather call it No with Slashing.

Also, I would like to clarify the VETO part. Does it mean that even if YES has the majority but NO_WITH_VETO has more than 33% the proposal is refused and the proposer punished?

If that’s the case it would motivate actors that are against a proposal to vote with Veto as it makes their vote weight much more than a regular no.

[joaquim]

Just checked the code and it does indeed check for veto before checking for the majority.

I would advocate for only counting the veto if YES/(YES/NO/NO_WITH_VETO) is lower than 0.5. As in this scenario we could be punishing a proposal that was voted yes by the majority

Original Code

// computeEndResults computes if a proposal has passed or not based on votes accumulated
func (g *governanceContract) computeEndResults(proposal *GeneralProposal, baseConfig *GovernanceConfigV2) bool {
	totalVotes := big.NewInt(0).Add(proposal.Yes, proposal.No)
	totalVotes.Add(totalVotes, proposal.Veto)
	totalVotes.Add(totalVotes, proposal.Abstain)

	totalStake := g.getTotalStakeInSystem()
	minQuorumOutOfStake := core.GetIntTrimmedPercentageOfValue(totalStake, float64(baseConfig.MinQuorum))

	if totalVotes.Cmp(minQuorumOutOfStake) == -1 {
		g.eei.Finish([]byte("Proposal did not reach minQuorum"))
		return false
	}

	minVetoOfTotalVotes := core.GetIntTrimmedPercentageOfValue(totalVotes, float64(baseConfig.MinVetoThreshold))
	if proposal.Veto.Cmp(minVetoOfTotalVotes) >= 0 {
		g.eei.Finish([]byte("Proposal vetoed"))
		return false
	}

	minPassOfTotalVotes := core.GetIntTrimmedPercentageOfValue(totalVotes, float64(baseConfig.MinPassThreshold))
	if proposal.Yes.Cmp(minPassOfTotalVotes) >= 0 && proposal.Yes.Cmp(proposal.No) > 0 {
		g.eei.Finish([]byte("Proposal passed"))
		return true
	}

	g.eei.Finish([]byte("Proposal rejected"))
	return false
}```

[schimih]

After carefully considering community feedback from the public Developers Telegram Channel, we’re moving forward with the 2x gas penalty threshold in Barnard v1.10, with one important addition: a transaction simulator will launch alongside Barnard.

We understand this change needs thoughtful execution. The simulator will give developers good visibility into gas usage before submission, eliminating guesswork and improving reliability across dApps and tooling.

Barnard is designed to align incentives across the network, encouraging accurate gas estimates without introducing unnecessary friction.

REMINDER: The updated governance proposal goes live June 11. Voting is open until June 21.

Make your voice count.
Post your feedback on Agora only. It’s the one place where comments are logged in the governance record and visible to the whole community. Telegram chat is fine for quick back-and-forth, but it reaches only a sliver of EGDL stakers and won’t count toward the formal process.

[mwfiae]

If the team decides to disregard the opinion of the dev community in regards to #3 (Change penalise gas), I think it is only fair to provide a proper reasoning for why it was rejected.

Why is such a drastic change necessary? No reasoning was provided in the merge linked either:

Why not implement a staged rollout where the value is slowly adjusted to give devs time to adjust to the new tooling?

You mentioned not introducing unnecessary friction, however such a drastic change and new tooling will introduce a lot of friction for the whole ecosystem:

1. Dapp developers will need to update their apps and use new tooling, create extra requests (meaning sending transactions will take longer to prepare, makes dapps run into ratelimits faster creating a subpar user experience, as well as increase the load on the public infrastructure in general meaning additional slowdowns and more overloaded api issues).

2. If the dapp developers don’t make those adjustments the users pay the price for that as the penalty will take the maximum amount of gas from the user.

3. And lastly Smart Contract developers are encouraged to use up extra gas in the transaction as to not incur the penalty which is an anti-pattern and also results in extra work for the validator nodes.

As you can see this results in a negative experience for everyone, especially if there is no transitional period, and as a result I myself see this change very critically and don’t understand the teams decision.
So I’m kindly asking everyone to please use their vote on vetoing this proposal.
(Unfortunately the proposals are not differentiated on a per-feature level, so we can only decline or accept the whole release, this is another issue that needs to be addressed in the future)

The feedback was initially not posted on Agora so as to encourage a free discussion with everybody involved, especially those with the highest stakes in it (the developers and builders), which also worked quite well and quickly and some of the most active devs came to a similar conclusion as myself. Unfortunately there was no actual discussion with the members of the team, at least not in the public telegram group. And I fear that posting it in the Agora will also not result in a fruitful discussion either as telegram holds clear advantages in both the amount of users present, the target audience (developers and builders) and in the fact that there are realtime notifications directly to everyones phones.

[robert]

Hello,

The changePenalty from 10x to 2x was first announced in October 2024. Since then, we had various developers / validator calls and we have been speaking about this topic. The change is needed, because the txSelection algorithm, the MEV protection, the block creation process works much better if the penalty is lower, or if their is not penalty.

First of all, in the sharded design and how the consensus and block creation process works, the protocol needs to actually know what gas will be used, before actually starting to process the txs. 10x buffer for gas overestimation was a super early call and at that time tools were not ready, also contracts were simpler. A good gas estimation means more txs can be put in the blocks. Right now, we have to preselect 10 times more transactions, and have a set of heuristics according to which we do the block creation, intra and cross shard as well. If this number would be 2x a lot of code would be simplified.

This simplification is needed for SuperNova, and it is actually needed for better economics, for better block space usage. There are a set of contracts and bots who use the 10x buffer just to fill up the blocks with useless things. This bites back hard when there is a real big need for the blockspace for bigger economic activities.

2x change right now is needed and this creates the base for a lot of bow things, like dynamic local fee markets, more txs per blocks, more capacity, more revenue.

Right now, there are contracts who use useless gas until they reach the 10x, the same will happen with 2x. This is not a penalty per se, but slightly more gas is paid if the estimation is wrong. With the current price this means around 0.001$ in case of overestimation. Is this sum so big? It is 1/10th of a cent.

There were big problems on the network last year, when there the liquidation events were happening for example, or some big mints of NFTs. Why? Because bots were pushing txs with 600million gas, they were not penalised at all, and in the end, after the consensus for a block processing was finished, we saw that only 25% of the block was full, while the transaction pool was full. We had to add a bunch of code and extra verifications at txSelection mechanism, just because the 10x was so big, and after processing, a lot of space was left out. This is wrong for intra and cross shard as well.

As we go towards SuperNova with 0.6s blocks, filling the blocks in the most critical cases is a must and in order to fill the blocks better and have the MEV protection and have everything we like right now, we need the penalty to go to 2x. This is the technical reason for it.

Staged rollout does not make sense, it would make a small painful work for dApp developers, slowly adjusting their gas, while they can take a few hours of work and adjust the gas for each of their calls. In case of xExchange, all transactions are well within the 2x range and they are working on reducing everything to be at 5-10% from the actual gas used.

1. Most of the dApps have fixed costs for transactions, like >95% of them. Fixed costs can be easily calculated with the current tooling, or looking simply at explorer and checking what was the last call for the txs. For dynamic executions, you can still create a microservice, which takes into account a few properties and adjusts the gasProvided according to that. dApp developers can run their own little infrastructure for gas simulations.
2. The user’s will pay extra around 0.001$ at the current price. Will they really feel this?
3. No, they are not encouraged to do this. Microservices are encouraged to calculate the exact needed gas for their transactions.

Lastly, we have been asking for feedback for everything through various channels, developer calls, and there was no raised issue at all in the last 8 months or so.

[robert]

Here’s a breakdown of the reasoning behind this design:

1. Protection Against the “Tyranny of the Majority”

In a simple majority-rules system (51% wins), a coalition of stakeholders holding just over half the voting power could pass any proposal they want. This could be used to:

• Change network parameters to unfairly benefit themselves.

• Allocate community pool funds to their own projects.

• Enact changes that are technically sound but deeply opposed by a significant and vital minority of the network.

The veto mechanism ensures that no proposal can pass if a substantial, united minority believes it is actively dangerous or fundamentally against the network’s interests. It protects the rights and investment of minority stakeholders.

2. Differentiating Between Disagreement and Harm

Cosmos governance has four voting options, and understanding the difference between “No” and “NoWithVeto” is key:

• No: This vote expresses simple disagreement. A voter might think, “I don’t think this is the best use of funds,” or “I prefer a different technical approach.”

• NoWithVeto (NWV): This vote expresses a belief that the proposal is actively harmful, malicious, spam, or reckless . It’s a voter saying, “This proposal is an attack on the chain or its community and should be rejected outright and penalized.”

The 33.4% threshold is intentionally high. It requires a very large and coordinated part of the network to agree that a proposal is not just bad, but dangerous.

3. The Economic Disincentive: Burning the Deposit

This is a critical part of the mechanism. When a proposal is submitted, the proposer must put up a deposit.

• If the proposal fails to reach quorum or is rejected by a simple majority, the proposer gets their deposit back.

• If the proposal is vetoed (i.e., more than 33.4% vote NoWithVeto), the proposer’s deposit is burned.

This creates a strong economic disincentive against submitting spam, frivolous, or clearly malicious proposals. It forces proposers to think carefully and build social consensus before putting a proposal on-chain, lest they lose their stake. The veto is the community’s tool to enforce this penalty.

4. Alignment with the Underlying Security Model

The MultiversX ecosystem is sPoS using the pBFT mathematical consensus modeling, which can tolerate up to 1/3rd of its validators being malicious or offline without halting or compromising the network.

The governance veto threshold of >1/3rd mirrors this security threshold. The logic is that if a group of actors large enough to potentially halt the chain (more than one-third of the voting power) is vehemently opposed to a change, that change is too contentious to be safely implemented. Forcing it through could risk a network split (a hard fork) or cause major stakeholders to exit the ecosystem, threatening the chain’s security and value.

---

Analogy: The UN Security Council Veto

A useful, though imperfect, analogy is the veto power held by the permanent members of the UN Security Council. A resolution can have overwhelming support from member states, but if one of the five permanent members vetoes it, it fails. This is not meant for everyday policy disagreements but is reserved for issues deemed a threat to national or international security by that member.