Referendum 87: Twelve Validators, and a Community Choosing Its Future

Part one of a three-part UseVara series on OpenGov, participation, and what comes next.

Somewhere underneath the applications, token swaps, community calls, and enthusiastic posts about the future, somebody has to keep the damn network running.

Servers need maintenance. Software needs updating. When something breaks, somebody needs to notice and know what to do about it. The blockchain continues being a blockchain because people do that work.

Referendum 87 put a concrete piece of that work before VARA holders: twelve validators operated by Ray0xNodes, twelve months of support, and $18,000 in funding from Gear Foundation.

Holders approved it.

We think that deserves some attention. Supporting capable independent validator operators is a worthwhile direction for Vara. So is putting ecosystem initiatives before the people who hold its token and giving them a public opportunity to decide whether they support them.

Ref 87 brought those two things together. We have a proposal, a recorded decision, and work to follow. That is a useful step toward the community taking more responsibility for Vara’s future.

What holders approved

The proposal was Validator Grant #1 for Ray0xNodes. Its headline terms were refreshingly easy to get your head around:

A year of support for a defined validator operation gives holders something tangible to consider. What does this operator contribute? What does the support pay for? How will we know the work is being done?

Those are reasonable questions about infrastructure the ecosystem depends on.

Vara’s documentation explains that validators elected to the active set help produce blocks and receive rewards for their contribution. Their responsibilities involve their own stake and the stake of the nominators backing them. See Vara’s validator guidance.

The job comes with machines to maintain, performance to monitor, and problems to address. A grant can help support that operational work over a defined period.

It also creates a useful opportunity for the community to learn what supporting an operator actually looks like, from the proposal through to delivery.

Why independent validator operators help Vara

Decentralization gets used so often in blockchain that it can start to sound like a feature you check off before launching a website.

In practice, it involves people, control, and infrastructure. Who runs the machines? Who holds the keys? Where are the servers? What happens if one organization, one provider, or one deployment has a bad day?

A broader group of independent operators can help spread those responsibilities. Different operators bring their own experience, their own administration, and their own reasons to care whether the network is healthy.

When their hosting providers and locations differ too, the network can gain resilience against shared failures. One provider’s outage can have a smaller footprint. One operator’s mistake can remain contained. More people are available to spot problems and contribute the expertise needed to solve them.

Those are useful things to have when your network is supposed to keep working around the clock.

We should also count accurately. Ray0xNodes is one operator proposing to run twelve validators. Twelve nodes do not become twelve independent organizations through the magic of a proposal title.

The potential benefit comes from the operator’s independence relative to Vara’s existing validator base, how the infrastructure is arranged, and whether the validators are elected and doing useful work. Those details deserve to be visible as the operation develops.

With that distinction understood, the direction makes sense. Vara benefits from a capable operator community with a broader base of control and expertise. Supporting an independent operation can contribute to building that base.

Decentralization needs people willing and able to do the work. Ref 87 gives the community a concrete operation to support and follow.

A community proposal becomes a community decision

There is another reason we like this referendum: it gave VARA holders something practical to do with their interest in the network’s future.

A community-originated proposal went before holders. They could inspect it, ask questions, discuss its value, and vote. The result became a public record.

That is how community governance starts acquiring substance.

Holding VARA gives people an interest in the ecosystem’s direction. OpenGov provides a way to exercise judgment about that direction. Ref 87 connected the two through a specific initiative with an operator, an amount, and a proposed period of work.

The proposal also gives future participants an example to learn from. Someone considering their own initiative can see a real decision rather than trying to infer the whole process from a documentation page.

The community gains experience too. Each concrete proposal is an opportunity to get better at evaluating terms, asking useful questions, and deciding what deserves support.

Vara holders taking a public role in those decisions is a good step for the network. We should encourage the habit.

What happened on-chain—and who pays

Here is the technical detail worth getting straight once: Ref 87 recorded approval of the grant. Gear Foundation pays it separately.

We asked the Foundation, through Luis Ramirez, exactly what the referendum authorized. Its response confirmed that it executed one system.remark call, recording this text:

Vara token holders approve Validator Grant #1: Ray0xNodes, 12 validators, 12 months, USD 18,000, funded by Gear Foundation.

The call moved no funds and granted nobody on-chain spending rights.

The Foundation also explained why it appeared on General Admin: that was the default track suggested by the VaraGov application for text proposals. OpenGov is the governance system; VaraGov is the application used to access it.

So the roles are clear. Holders supplied a recorded decision. The Foundation administers the funding. Ray0xNodes is the operator whose work the proposal asks the Foundation to support.

The record gives everyone a common point of reference for what holders approved. We can return to it when following the grant’s progress.

It also offers a useful lesson for reading future referenda: look at the executable call alongside the description. Different OpenGov tracks have different permissions and decision rules. The action tells you what passing the vote actually does. Vara’s governance documentation explains those distinctions.

In this case, it recorded the community endorsement the Foundation described.

The result

The final conviction-weighted tally was 3,090,268.52 VARA in Aye power and 116,660 VARA in Nay power, giving the proposal 96.36% approval.

The result is recorded in OpenGov and Subsquare. Subsquare also records successful execution of the remark.

A little care with the terminology helps here. Conviction voting lets holders increase the weight of their vote through a commitment to lock tokens for longer. A no-conviction vote carries 0.1 times its underlying balance. That is why raw balances and voting power can look quite different. OpenGov also applies separate support requirements and confirmation periods under the relevant track’s rules.

The proposal moved through the following milestones, as recorded by Subsquare. Dates and times here are UTC.

Approval percentage describes the balance of the participating voting power. Understanding the breadth of participation requires looking at the underlying balances, voting accounts, and delegation as well. Accounts are not necessarily separate people.

We will examine that participation in part two. For this article, the outcome is straightforward: the proposal passed, and the approved remark was successfully executed.

The community has a decision to follow through on.

Making the achievement visible

Now we get to the part where the servers earn their keep.

An implementation update identifying the funded validators, the operating period, and the agreed expectations would give holders a useful starting point. Periodic reporting would let the community follow what the support produces.

Vara already points users toward a validator dashboard with operational and staking information. Connecting the grant to identifiable accounts would help readers follow active-set participation and performance.

Our suggestion is simple: make the operation easy to find and its progress easy to understand. Publish the agreed terms that can be made public, then report against them.

That gives Ray0xNodes a way to demonstrate its contribution and gives holders something concrete to evaluate. It also gives the next proposer an example worth following.

A modest grant can establish good habits. Clear proposal. Public decision. Visible work. Those habits can carry forward as the ecosystem takes on larger initiatives.

A step worth celebrating

Ref 87 deserves recognition for what it accomplished: a community-originated infrastructure proposal received approval from participating holders, and that decision was recorded for everyone to inspect.

The approved work has the potential to contribute to Vara’s operational base. The process gives holders experience in exercising responsibility for the ecosystem’s direction.

We want more of that: capable operators, understandable proposals, substantive questions, and people taking an active interest in the network they own a stake in.

The next chapter is delivery. Following the approved work through will give the community something useful to point to when the next initiative comes along.

Vara’s future will be shaped by the people willing to propose, participate, and do the work. Ref 87 is a good step in that direction.

In part two, we look at who participated, where the decisive voting power came from, and what the community needs to strengthen before the next decision carries greater consequences.