The Upgrade That Passed and Didn't Happen

---

Early Saturday morning, October 24, the Vara Network was supposed to get an upgrade.

The code was published. The referendum had passed. Forty-four voting addresses had participated, every single one voting Aye. Not one Nay in the bunch.

And when the appointed hour arrived, the blockchain took one look at the instructions and said, essentially, not so fast, buddy.

CallIsNotWhitelisted

That's the error Vara recorded when Referendum #89 attempted to execute at 1:38 AM Eastern.

The upgrade didn't happen. The network kept running on its existing runtime, spec version 11000, instead of moving to the proposed version 20101.

Nobody had voted against the upgrade. There was no governance rebellion, no contentious showdown between competing factions, and no evidence that the network itself had malfunctioned.

The problem was considerably more mundane.

Somebody hadn't finished the paperwork.

And because this is blockchain, the paperwork was a cryptographic authorization requiring a separate Fellowship referendum, an exact matching call hash, and a decision deposit.

Here's the really funny part.

The technical Fellowship had already approved another version of the same upgrade.

Unfortunately, that wasn't the version the public had voted on.

The upgrade that was authorized hadn't received a public vote. The upgrade that received the public vote hadn't been authorized.

Two halves of a perfectly good sandwich, sitting on opposite sides of the kitchen.

And while all this was happening, Vara had paused its Ethereum bridge for a major security upgrade that appears closely related to the runtime change in question.

So I started digging.

What I found was a surprisingly revealing look at how Vara governance actually works, where its human coordination can fall short, and why a blockchain refusing to execute an approved referendum can sometimes be a sign that its security mechanisms are working exactly as intended.

Pull up a chair.

First, what the hell were we upgrading?

On October 16, the Gear development team published runtime release v2.1.1.

This wasn't a fresh coat of paint or a minor housekeeping update.

The release changes the activation requirements for BEEFY, a blockchain finality mechanism with a particularly useful application: allowing another blockchain to verify information originating on Vara without simply trusting somebody's word for it.

For example, an Ethereum smart contract can use cryptographic proofs to verify finalized information from Vara.

That's a big deal for bridges.

Historically, moving assets between blockchains has often involved trusting intermediaries, groups of signers, or other operators to attest that something happened on one chain before corresponding assets are released on another.

Light-client verification takes a different approach. Instead of asking somebody to promise that a transaction happened, the receiving chain can verify cryptographic evidence.

It doesn't eliminate every security risk. There are still smart contracts, validators, relayers, software, and implementation details to get right.

But it reduces the need to trust a middleman.

And for a network like Vara, which has considerable ambitions around interoperability, that's useful infrastructure.

Fifty-nine validators walk into a bar

Before v2.1.1, activating BEEFY required unanimous key registration across the relevant validator set.

Unanimous. As in, everybody.

If 58 of 59 validators registered their keys and the last one was on vacation, asleep, or having an argument with their server, activation could stall.

The new runtime replaces that unanimity requirement with a quorum.

For 59 validators, the threshold is 40. For 60 validators, it's 41.

That requirement applies independently to both the active validator set and the queued validator set.

The upgrade doesn't kick the other validators out or create a smaller permanent committee. The complete validator set remains in place.

It simply makes activation possible without waiting for every last participant.

There is a tradeoff. The release notes explicitly warn that operating at the minimum quorum leaves no spare capacity for signer outages.

Forty of 59 may be sufficient to activate, but having substantially more validators registered would provide a healthier operational margin.

The upgrade also introduces procedures for registering owner-bound validator keys through author_rotateKeysWithOwner and session.setKeys(keys, proof).

In short, this is a meaningful piece of engineering.

But publishing code doesn't make it the code running on the blockchain. To do that, Vara has to get it through governance.

And that's where our little adventure begins.

The Fellowship, the whitelist, and the problem with almost identical instructions

Vara's OpenGov system has a track called Whitelisted Caller.

It's designed for operations that require powerful permissions, including changing the runtime code of the blockchain itself.

Normally, a runtime upgrade requires Root authority.

The Whitelisted Caller process provides another route: Vara's technical Fellowship can authorize one specific operation, and token holders can subsequently approve its execution through a governance track designed for preauthorized calls.

The Fellowship isn't granting permission to do whatever somebody feels like doing. It's approving an exact operation.

That operation is identified by a cryptographic hash, essentially a fingerprint of the instructions.

Change the instructions and you change the fingerprint. Even if the underlying runtime code is identical.

That distinction is going to become very important.

Because the v2.1.1 upgrade ended up with two different governance proposals.

Referendum #88: The one with the technical approval

Referendum #88 proposed upgrading the runtime through a straightforward system.setCode operation.

That's the instruction that replaces the blockchain's runtime code.

Its corresponding Fellowship proposal, Fellowship #73, authorized that specific call.

On October 20, Fellowship #73 executed successfully. The operation was whitelisted.

Everything was lined up on the technical authorization side.

There was just one problem.

Referendum #88 never received the decision deposit needed to advance into formal voting.

It sat there with zero votes.

We had an authorized upgrade without an advancing public referendum.

Referendum #89: The one everybody voted for

Referendum #89 proposed the same underlying runtime code.

But it packaged the operation differently.

Instead of a plain system.setCode, it used a utility.withWeight wrapper.

That wrapper provides an explicit execution-weight budget.

The likely reason was to specify the resources available for a large runtime upgrade, although we haven't found a published explanation for why the wrapper was used in this particular proposal.

Whatever the reason, it changed the call's hash.

And that meant the whitelist authorization for #88 didn't apply.

Referendum #89 needed its own authorization from Fellowship #74.

No problem, right?

Except Fellowship #74 hadn't completed its process.

Meanwhile, #89 was sailing through public governance.

Forty-four addresses voted. Forty-four Ayes. Zero Nays.

It entered confirmation on Friday evening, October 23, and completed confirmation shortly afterward.

The referendum was approved.

And then came Saturday morning.

The vote passed. The upgrade didn't.

At approximately 1:38 AM Eastern on October 24, Referendum #89 reached its execution block.

For the technically curious, that's block 37,136,376.

The chain attempted to dispatch the approved operation.

And returned:

CallIsNotWhitelisted

The operation wasn't on the authorized list. So the blockchain refused to execute it.

No runtime upgrade. No change to spec version 20101.

Vara continued operating under its existing runtime.

And here's something important that could easily get lost in the comedy of errors.

The blockchain did exactly what it was supposed to do.

It checked whether the exact privileged operation had received the required authorization.

It hadn't. So the chain rejected it.

Imagine if the system had shrugged and said, Well, the Fellowship approved something pretty similar, and the voters seem happy, so let's go ahead.

That would be a serious security problem.

Instead, the authorization mechanism enforced its rules.

The governance vote succeeded. The dispatch failed. And the runtime remained unchanged.

Those are three separate facts, and understanding the difference is essential to understanding what happened.

The missing deposit: Six days and one very expensive-looking oversight

Now we get to the part that initially made this whole business so confusing.

Fellowship #74 had been submitted on October 19. It was supposed to authorize the exact operation that Referendum #89 would execute.

But before we go further, we need to explain something about Vara governance.

Submitting a referendum doesn't automatically put it up for a vote.

OpenGov requires what's called a decision deposit before an eligible proposal can enter its formal decision-making period.

Think of it like putting down a security deposit to get your proposal onto the official agenda.

A specified amount of VARA has to be reserved as collateral.

It's not a payment to validators. It's not a fee to purchase approval. And it's not money being spent on whatever the referendum proposes.

It's a financial commitment required by the governance process, generally returned according to the protocol's deposit rules when the referendum concludes.

The purpose is straightforward.

Without some cost or commitment associated with advancing proposals, anybody could flood governance with endless referenda and consume the network's limited decision-making capacity.

And here's another important detail.

The person placing the deposit doesn't necessarily have to be the person who submitted the referendum.

Another account can step forward and provide it.

Until that happens, though, the proposal can remain in its preliminary stage.

It doesn't matter how brilliant the code is, how important the upgrade might be, or how many people are ready to approve it.

No required deposit, no formal decision period.

Which brings us back to Fellowship #74.

Submitted October 19. Waiting for its deposit.

October 20 came and went. Then October 21. Then October 22.

On October 23, the public referendum it was supposed to authorize finished confirmation.

Still no completed Fellowship authorization.

Then October 24 arrived, and #89 attempted execution. The chain rejected it.

And finally, on the morning of October 25, somebody placed the decision deposit for Fellowship #74.

Six days after the Fellowship proposal was submitted. More than a day after the public referendum had already failed.

The deposit came from the same address that submitted Fellowship #74, beginning kGgQq and identified on-chain as ukint-vs.

Shortly afterward, Fellowship #74 proceeded.

At approximately 8:42 AM Eastern on October 25, it executed successfully.

The call was finally whitelisted.

The authorization arrived roughly 31 hours after the original referendum had tried to use it.

I don't know why the deposit was delayed.

Maybe somebody overlooked it. Maybe there was a coordination problem. Maybe there was a reason that isn't visible in the public record.

I'm not interested in inventing an explanation where we don't have one.

But the sequence itself is clear.

The Fellowship proposal existed. The required deposit wasn't placed in time.

The public referendum executed without the authorization. And the blockchain rejected the upgrade.

Six days of waiting for a governance prerequisite, followed by a failed execution and a belated authorization.

That's one hell of a way to discover that somebody forgot to put a coin in the meter.

Forty-four voters, zero opposition, and some interesting numbers

Let's look at the public vote itself.

Referendum #89 finished with approximately 161.5 million VARA in conviction-adjusted Aye voting power, zero Nay voting power, and approximately 1.6 billion VARA in support.

Those numbers require a little explanation.

Vara uses conviction voting. Token holders can choose different conviction levels, trading longer token lockups for greater voting weight.

At the low end, 0.1x conviction provides reduced voting weight without the same post-vote locking commitment.

Several large participants in #89 used 0.1x conviction.

The largest recorded voter committed approximately 87.2 million VARA at that level.

Six other accounts each committed approximately 60.56 million VARA, also at 0.1x.

Those balances represent substantially more underlying capital than their conviction-adjusted voting power.

That's why the Aye tally and support figure are so different.

The 161.5 million weighted Ayes represented approximately 1.6% of the roughly 10.15 billion VARA electorate.

The support figure was closer to 15.8%.

Those are different governance measurements, not two competing estimates of turnout.

And neither should be confused with the number of unique people participating. We can count 44 voting addresses, but one person or organization can control multiple addresses.

Still, the result is pretty unambiguous.

Among the addresses that voted, there was no recorded opposition.

This wasn't an upgrade that failed because the community couldn't agree on whether to deploy it.

The participating voters agreed.

The problem happened afterward.

Who was minding the Fellowship?

The Fellowship voting records add another interesting dimension.

According to the records examined for this investigation, four of seven Fellowship members participated in #74.

All four voted Aye. Their combined rank-weighted voting total was 19.

Vadim Smirnov, identified on-chain as ukint-vs, contributed 10 weighted votes as a rank-6 Fellow.

Alexander Volkov, an account identified as PV, and Andrei Panin each contributed three weighted votes as rank-4 Fellows.

Three rank-6 members did not participate in the recorded tally, including Dmitry Novikov, Nikolay Volf, and one Fellow without an identified on-chain name.

The earlier Fellowship #73 had three participating members and 16 weighted votes.

There was also substantial overlap in who submitted the proposals.

The address associated with ukint-vs appears as the proposer of Referenda #88, #89, and #91, along with Fellowship proposals #73 and #74.

The GitHub release also identifies that handle as its author.

In other words, one contributor appears to have played a central role in preparing the release, submitting the governance proposals, and participating in their technical authorization.

That's not inherently suspicious.

Small technical communities often rely on a handful of highly active developers.

And the public voting record doesn't tell us what independent code reviews, testing, security assessments, or engineering discussions happened outside governance.

But it does show how concentrated the visible governance activity was.

Which raises a fair question.

With the same contributor involved in both sides of the process, how did the required Fellowship deposit remain outstanding until after the public referendum failed?

Was somebody responsible for checking that the whitelist would be ready? Was there a deployment checklist?

Did anyone notice that #89 was heading toward execution without its prerequisite authorization?

We don't know. And I would genuinely like to.

Because the issue here doesn't appear to be a shortage of engineering talent.

It appears to be a shortage of coordination.

Referendum #91: Let's try that again

By Sunday morning, October 25, a replacement proposal had appeared.

Referendum #91 was submitted at approximately 7:08 AM Eastern.

It uses the same preimage as #89.

That means it's another attempt to execute the same proposed operation, rather than introducing an entirely different runtime payload.

And now Fellowship #74 has completed the authorization that #89 was missing.

The new referendum also specifies a much shorter enactment delay: 100 blocks, compared with 5,000 for #89.

The actual timing of execution still depends on the referendum meeting its governance requirements.

As of our October 25 afternoon review, #91 was in its deciding phase with zero recorded votes.

At least the new proposal includes descriptive information and links to the software releases, an improvement over #89, which initially appeared without a meaningful title or explanation.

Assuming the whitelist remains valid and no other execution problems arise, #91 appears positioned to complete the upgrade that #89 couldn't.

The specific authorization problem has been addressed.

Now the network needs another successful public vote and execution.

Sometimes progress looks like writing revolutionary new software.

Sometimes it looks like getting the deposit paid before the deadline.

Meanwhile, the Ethereum bridge is sitting on the sidelines

On October 23, Vara Network announced that its Vara-to-Ethereum bridge had been paused while a major security upgrade was rolled out.

The team described a move toward light-client-based verification.

It also said wrapped assets would remain redeemable one-to-one when the bridge reopened and that pending transfers would be completed.

No specific reopening date was announced.

The team said reopening would follow deployment and testing on mainnet.

Now, the technical relationship between that announcement and runtime v2.1.1 is hard to ignore.

The upgrade changes BEEFY activation.

BEEFY provides exactly the kind of cryptographic finality information that can support light-client verification on Ethereum.

So the runtime upgrade appears to be an important piece of the infrastructure Vara is preparing.

But there's an important distinction.

We haven't found an explicit public statement from the team confirming that Referendum #89, or its replacement #91, is the particular upgrade referenced in the bridge-pause announcement.

The connection is a strong technical inference, not a confirmed dependency.

And we haven't found a published post-mortem explaining what prompted the pause.

That doesn't mean an exploit occurred. It doesn't mean user funds were lost.

And it doesn't establish that the failed referendum caused the bridge pause.

Those would be conclusions unsupported by the information available.

What we do know is that the bridge is paused, a major security upgrade is underway, and Vara is attempting to enact runtime changes directly relevant to light-client verification.

That's enough to warrant attention without adding a bunch of speculative drama.

How much money is actually involved?

DefiLlama reported approximately $199 in total value locked for Vara Bridge in the data reviewed for this article.

That's a remarkably small figure.

But it's important not to mistake a reported TVL metric for a complete accounting of bridged assets.

It doesn't necessarily include every outstanding wrapped-token liability or every transfer awaiting completion.

So we can't use that number alone to establish how much user money may be affected by the pause.

And frankly, I think the more interesting question is what happens as Vara's interoperability infrastructure matures.

A bridge can be small today and strategically important tomorrow.

If Vara wants to attract applications, liquidity, and users from other ecosystems, secure and dependable cross-chain infrastructure is going to matter.

Getting that infrastructure deployed properly is part of the job.

Even if #91 passes, don't expect the bridge to spring back to life

There's another misconception worth heading off.

Passing #91 won't automatically turn on BEEFY.

And turning on BEEFY won't automatically reopen the Ethereum bridge.

The v2.1.1 release notes are explicit about that.

There are several separate steps.

First comes runtime enactment.

The new code must successfully replace the existing runtime.

Then comes validator key registration.

Enough validators must register their owner-bound BEEFY keys to satisfy the quorum in both the active and queued sets.

Then comes BEEFY activation.

The release notes identify a separate operation, beefy.setNewGenesis(1), which requires its own approval.

And then comes bridge cutover.

That includes the appropriate relayer changes, smart-contract integration, testing, and any additional governance procedures.

This is not a single switch somebody flips.

It's a staged deployment. And every stage introduces its own operational requirements.

So if #91 passes and the runtime successfully upgrades, that's meaningful progress.

But it isn't the finish line.

We'll still need to see validators register their keys, BEEFY activate, and the bridge complete its own deployment process.

Patience, my fellow bears. The machinery is substantial.

Here's the part I actually find encouraging

It's easy to look at this story and conclude that Vara governance is broken.

I don't think that's what the evidence shows.

Quite the opposite, in one important respect.

The system refused to execute a privileged operation that lacked the required authorization.

That's good. That's exactly what we should want.

The blockchain didn't decide that a similar-looking authorization was close enough.

It didn't ignore the whitelist requirement because token holders had voted overwhelmingly in favor.

It didn't quietly install new runtime code and hope nobody noticed.

It rejected the operation.

The security boundary held.

What appears to have failed was the human process responsible for getting the necessary approvals completed in the correct order.

And that's a much more manageable problem than discovering the authorization mechanism itself doesn't work.

It also illustrates why decentralized governance can be both powerful and maddening.

The rules are explicit. The records are public. The transactions can be inspected.

But the process still depends on people understanding the requirements and coordinating their actions.

You can build a wonderfully sophisticated governance machine.

Somebody still has to remember to put the deposit down.

Vara governance is growing up in public

We've been spending a lot of time looking at governance lately.

Referendum #87 funded a grant for 12 independent validators.

Referendum #90 is asking the community whether Vara should pursue a community-governed treasury.

And now #88, #89, and #91 are giving us a front-row seat to the mechanics of upgrading the blockchain itself.

These are very different proposals.

But they expose a common challenge.

Ordinary token holders shouldn't need to become forensic blockchain analysts to understand what they're voting on.

In the case of #89, the original public proposal had no meaningful title or explanation.

One commenter asked for the call to be decoded and pointed out the lack of context.

That's not ideal when the operation in question is capable of replacing the runtime code of the entire network.

And the language used by governance interfaces can be confusing.

A referendum can show that it reached execution even when the attempted operation returned an error.

The word executed doesn't necessarily mean the intended change succeeded.

That's a pretty consequential distinction.

It's also one of the reasons we've been building VoteVara.

Not to tell people which way to vote. Not to manufacture controversy.

And certainly not to turn every procedural hiccup into a five-alarm fire.

But to help ordinary VARA holders understand what the network is being asked to do, what the votes mean, and whether the thing everybody voted for actually happened.

Because as #89 demonstrated, those are not always the same thing.

A few questions for the Gear team

The public record gives us a detailed picture of the sequence.

It doesn't explain every decision behind it.

And there are a few things I'd genuinely like to understand.

Why wasn't Fellowship #74's decision deposit placed before #89 reached execution?

The proposal was submitted October 19. The deposit didn't arrive until October 25. Was that an oversight, a coordination issue, or something else?

Why were two versions of the same runtime upgrade submitted?

Referendum #88 used a plain system.setCode, while #89 wrapped it in utility.withWeight. Was that wrapper technically necessary, or was there another reason for the difference?

Was anybody tracking the whitelist prerequisite?

The public referendum was able to finish confirmation while its required Fellowship authorization remained incomplete. Was there a process for checking that the call would be whitelisted before execution?

What happens to #88?

Its associated operation was whitelisted through Fellowship #73, but the public referendum never advanced. Will it simply expire?

What technical review happened outside the visible Fellowship votes?

The on-chain record shows a relatively small number of participating Fellows. We'd be interested in understanding the broader review process behind the release.

How ready are validators for the BEEFY upgrade?

Are enough validators prepared to register their keys promptly, and what happens if registration stalls near the minimum quorum?

And finally, how does this fit into the Ethereum bridge reopening plan?

Is v2.1.1 the specific runtime dependency referenced in the bridge-pause announcement? What other technical and governance milestones remain?

These aren't accusations. They're questions arising from the public record of a significant upgrade.

And answering them would help token holders understand what's happening.

What to watch next

The immediate item on the calendar is Referendum #91.

You can follow it here:

Vara Referendum #91 on Subsquare

You can also access Vara governance through the official OpenGov portal.

Token holders can review the proposal, connect a compatible wallet, and make their own voting decisions.

For those who want to inspect the underlying software, the Gear v2.1.1 release includes the production runtime WASM artifact and its published SHA256 checksums.

Our investigation found that the runtime code in #89 matched the published v2.1.1 artifact, including the expected spec version 20101.

That verification concerns the runtime payload. The surrounding governance calls have their own hashes, which is precisely why the distinction between #88 and #89 mattered.

After #91, we'll be watching validator key registrations, any proposal to activate BEEFY, and the eventual bridge cutover.

And of course, whether the Gear team provides additional context about the original failure.

The upgrade that passed and didn't happen

There's something wonderfully absurd about this whole affair.

The developers wrote the upgrade.

The Fellowship authorized one version.

The public approved another.

The blockchain checked the instructions and told everybody to come back when they had the right paperwork.

And then, after the public referendum had already failed to execute, somebody finally paid the deposit that would have allowed the required authorization to proceed.

You couldn't write a better bureaucratic comedy if you tried.

But beneath the comedy is something worth paying attention to.

Vara is building real infrastructure.

Moving toward light-client-based bridge verification is a meaningful security improvement. Making BEEFY activation possible without unanimous validator registration addresses a genuine operational obstacle.

Those are worthwhile engineering goals.

And the governance system's refusal to execute an unauthorized call is evidence that an important security boundary is doing its job.

But writing good software and successfully deploying that software through decentralized governance are two different disciplines.

Both require care. Both require coordination.

And both are part of building a network people can rely on.

The good news is that the authorization mechanism worked.

The bad news is that it apparently took a failed public referendum to get the missing authorization completed.

Now Referendum #91 gives Vara another opportunity to finish what #89 started.

Forty-four voting addresses already approved the underlying operation.

The chain is still waiting for the upgrade.

Let's get the ducks in a row this time, boys.

Go Vara!

---

The numbers behind the story

Governance figures and statuses are snapshots. Voting, deposits, execution states, and runtime versions can change as additional transactions are recorded.

Sources

1. Gear v2.1.1 release notes and runtime artifacts
2. Vara Referendum #88
3. Vara Referendum #89
4. Referendum #89 execution record — Subsquare API
5. Vara Referendum #91
6. Fellowship Referendum #73
7. Fellowship Referendum #74
8. Vara Network's October 23 bridge announcement
9. Vara Network's bridge-upgrade follow-up
10. DefiLlama protocol data
11. Vara OpenGov portal

Methodology: This investigation draws on public Vara governance records, Subsquare API data, on-chain transaction analysis, and the Gear v2.1.1 release documentation. The reported execution failure was decoded against runtime metadata. The detailed Fellowship deposit chronology, voting distribution, and runtime checksum comparison derive from the underlying on-chain investigation. Times are Eastern Time. No unpublished internal explanation from the Gear team has been assumed.

UseVara is an independent, unapologetically pro-Vara publication. We support the network's success, which includes paying attention when something doesn't go according to plan.