Mission 6 — Governance

Owning $A gives you an asset. Participating in governance gives you a voice in how the network is operated.

Vaulta uses a Delegated Proof-of-Stake (DPoS) governance model in which token holders can vote for the infrastructure operators known as Block Producers, or delegate that voting decision to a proxy. The current Vaulta system contracts use those votes to determine the active producer set, while Antelope Spring provides the node software and Savanna consensus used by those producers.

Vaulta docs: Node operators

Antelope.io, version Spring, is the software framework which powers the Vaulta blockchain.

Key idea: Holding an asset isn't the only way users participate in a blockchain network. On the Vaulta blockchain, token holders can also use staked voting power to influence which 21 Block Producers operate the network.

What are Block Producers?

Block Producers, usually abbreviated BPs, are infrastructure operators running Vaulta nodes.

Among other responsibilities, they:

• produce blocks containing transactions;

• maintain reliable network infrastructure;

• participate in network governance and upgrades;

• operate the infrastructure required for Vaulta's consensus and finality.

Vaulta currently has 21 active Block Producers. The system contract ranks eligible producers by vote weight and builds the active producer set from the highest-ranked candidates. Under Savanna, the active producers also participate in finality.

Blocksfinity sometimes uses the more familiar interface term Validator. In the underlying Vaulta system contract, the corresponding entities are called producers, which is why the transaction you will sign uses the action:

eosio::voteproducer

You do not need to understand the internals of Spring for this mission. The useful mental model is:

Token holders
      ↓
vote
      ↓
Block Producer candidates
      ↓
highest eligible vote totals
      ↓
21 active Block Producers
      ↓
Spring / Savanna consensus
      ↓
blocks + finality

Spring itself is the C++ implementation of the Antelope protocol with Savanna consensus. The higher-level election mechanism is implemented by Vaulta's system contracts. GitHub

How can you evaluate a Block Producer?

Choosing a BP is not only about recognizing a name. Infrastructure quality, reliability, transparency and ecosystem contributions may all be relevant.

Aloha Blocks and other entities operate public research tools for this purpose. The Aloha Block Producer Benchmarks compare infrastructure execution performance, while its Reliability Tracker shows metrics such as missed blocks, missed rounds and availability. Aloha itself warns that these statistics should be treated as useful signals rather than absolute proof of a producer's quality.

Vaulta Block Producer Benchmarks

Vaulta Block Producer Reliability

Herdcheck provides information about how healthy the Block Producer nodes are while the EOS Community is hosting a BP election website, where Operators present what they are contributing. Here the example for the EOS Support BP (scroll down for the English version).

What actually gives you voting power?

This is an important distinction:

Your liquid token balance is not automatically your voting power.

The current Vaulta system contract calculates a voter's staked amount from two sources:

1. the underlying value of the account's REX position; and

2. any value still held in the legacy CPU/NET allocation/staking structure.

The contract's voteupdate action explicitly reconstructs the voting stake by adding the account's REX vote_stake and its delegated CPU/NET stake. GitHub

Therefore:

Liquid $A
    ↓
does NOT add voting power


$A staked in REX
    ↓
DOES add voting power


Legacy value staked (allocated) to CPU/NET
    ↓
also adds voting power

You do not need to allocate $A to CPU or NET just to vote. If you completed the previous REX mission, your REX position already provides voting stake.

The same principle applies to legacy $EOS: simply holding liquid $EOS does not create voting power.

Does REX in Savings count?

Yes. The voting calculation is based on the underlying value of the REX you still hold. Moving REX tokens between Savings, the 21-day unstaking period and mature REX does not itself sell the REX.

Once REX is actually sold, the system reduces the REX voting stake accordingly. GitHub

So conceptually:

REX Savings
     │
     ▼
21-day unstaking
     │
     ▼
Matured REX
     │
     │ still REX
     │
     ▼
Sell REX
     │
     ▼
Voting stake decreases

Why do parts of the system still say $EOS?

Vaulta transitioned from $EOS to $A, but some of the underlying system-contract architecture still uses the legacy $EOS representation internally.

The current core.vaulta contract is the $A-facing system interface. For example, when $A is staked, core.vaulta performs the necessary conversion before forwarding the operation to the underlying eosio system contract. Voting itself is then forwarded to the existing eosio::voteproducer action. GitHub

For this mission, think in terms of your $A voting stake. The legacy internal accounting does not mean that liquid $EOS or liquid $A automatically counts as votes.

Direct voting

Vaulta allows one account to vote for up to 30 Block Producers.

An interesting detail is that your voting power is not divided by the number of producers you select. The system contract applies your calculated vote weight to every producer in your selected list. GitHub

For example:

Your voting weight
       │
       ├────► Block Producer A
       ├────► BP B
       └────► BP C

Each selected BP receives your vote weight.

Your tokens do not move to those Block Producers. You are changing an on-chain governance record in a defined system smart contract.

What is a voting proxy?

Researching and continually monitoring up to 30 infrastructure providers requires time.

Vaulta therefore supports voting proxies.

Instead of maintaining your own BP list, you can delegate your voting power to a registered proxy:

Your account
     │
     │ voting power
     ▼
Voting proxy
     │
     ├────► BP A
     ├────► BP B
     ├────► BP C
     └────► ...

The proxy decides which BPs its combined voting weight supports.

Important: Delegating to a voting proxy does not transfer your $A, REX, private keys, permissions or custody of your account. The proxy receives voting weight, not authority to spend your assets.

The system contract stores your chosen proxy in your voter record and adds your vote weight to that proxy's proxied_vote_weight. The proxy then applies its own voting weight plus delegated voting weight to its BP selections. GitHub

This also explains why a proxy account can show a very small amount of its own voting stake but a much larger total proxy voting strength: most of that influence may have been delegated by other accounts.

You cannot directly vote and use a proxy at the same time

The system contract explicitly prevents a voter from specifying both a proxy and a list of producers in the same voting state.

That means this mission intentionally demonstrates both methods in sequence:

First:
You → eossupportbp

Then:
You → eossprt.spt proxy → proxy's BP selections

When you perform the second action, the proxy selection replaces your direct BP selection. It is not added on top of it.

What is vote decay?

Vaulta's voting system contains an unusual time component.

The current contract calculates voting weight approximately as:

staked amount × 2^(weeks / 52)

The time factor therefore doubles approximately every 52 weeks. But when you cast or update a vote, the calculated result is stored as your last_vote_weight. It does not automatically recalculate itself every week merely because time passed.

This creates what is commonly called vote decay.

Your old vote is not literally reduced every day. Instead, newly refreshed votes use a newer, larger time multiplier, so an old vote becomes relatively weaker compared with a freshly updated vote.

For example, after approximately one year, an unchanged vote has roughly half the weight it would have if the same stake were freshly recalculated at that time.

Key idea: Vote decay encourages active participation to update their votes or confirm their votes regurarly rather than allowing an old governance decision to retain full relative influence forever.

Do I have to vote again every week or every month?

No. There is no protocol rule requiring a weekly or monthly vote.

Your BP selection or proxy selection remains on-chain until you change it.

However, re-submitting your vote recalculates its current vote weight. The system also updates voting weight during certain staking operations because changes to REX or other voting stake need to be reflected in governance.

A sensible governance habit is therefore to periodically review whom you are supporting and refresh your vote when appropriate, rather than treating voting as a one-time action that never needs attention.

Vote directly for a Block Producer

Open the current Blocksfinity voting interface:

Blocksfinity — Vote

Blocksfinity currently supports direct BP voting and proxy voting and preselects eossupportbp for the one-step direct-vote example used in this mission.

1. Select EOS Support

Open the Validators tab.

For this exercise, select:

eossupportbp

Blocksfinity allows you to select up to 30 producers, but we will use only one so that the resulting transaction is easy to inspect.

Click Vote.

2. Inspect the signing request

Do not sign immediately.

The Authenticator shows two actions in this example.

The first is:

core.vaulta::noop

Blocksfinity labels this as CPU/NET cover. It is a no-operation action used as part of covering/sponsor resources for your request; it does not move your tokens.

The governance action is:

eosio::voteproducer

Check:

Voter:     your account
Proxy:     empty
Producers: eossupportbp

The empty Proxy field is important: this is a direct producer vote.

Checkpoint: Confirm your account, the eosio::voteproducer action, an empty proxy field and eossupportbp in the Producers field before signing.

Sign the transaction.

Now delegate your voting power to a proxy

Next we will intentionally replace the direct vote with a proxy.

Return to:

Blocksfinity — Vote

3. Open Proxies

Select the Proxies tab.

Blocksfinity presents eossprt.spt as the preselected proxy for this exercise.

The proxy is the EOS Support Proxy:

eossprt.spt

You can also inspect the proxy entry and its information before selecting it.

Either scroll down:

or Aloha Blocks also provides an overview.

On Blocksfinity, click the button Proxy to eossprt.spt.

4. Inspect the proxy transaction

The Authenticator again displays the voting action:

eosio::voteproducer

But look carefully at the parameters.

You should now see:

Voter:     your account
Proxy:     eossprt.spt
Producers: empty

That is materially different from the previous transaction.

Checkpoint: The proxy should be exactly eossprt.spt, while the Producers field should be empty. This transaction replaces your direct producer selection with proxy voting.

Sign the transaction.

Verify your account

Open your account in Blocksfinity, scroll down to “Chain Data” and select Votes (Proxying).

After proxying, Blocksfinity should identify the account as proxying its votes to:

eossprt.spt

This is your on-chain evidence that your governance setting changed.

Your assets stayed in your account and REX position. What changed was where the system directs your voting weight.

Verify what the proxy is voting for

Delegating voting power should not mean voting blindly.

Search for or open the EOS Support proxy account directly here:

Blocksfinity — eossprt.spt account

Select Votes (Proxying).

Blocksfinity shows the Block Producers that the proxy currently supports.

The screenshot used for this mission shows the proxy voting for 29 producers, but that is only a snapshot. A proxy can change its BP selections over time.

That flexibility is the purpose of using a proxy: you choose the proxy, while the proxy maintains the producer list.

It also means you should occasionally check whether the proxy's current selections, actions and value contributions to the network still match the reason you chose it.

Technical references

The current Vaulta Block Producer docs are available here:

Vaulta Guides — Block Producers

The voting implementation discussed in this mission is visible directly in the current Vaulta system-contract release:

Vaulta system-contracts v3.10.0 — voting.cpp

REX voting stake can be inspected here:

Vaulta system-contracts v3.10.0 — rex.cpp

The $A-facing wrapper that forwards Vaulta voting and staking operations to the underlying eosio system contract is here:

Vaulta core.vaulta system wrapper — system.entry.cpp

And the node/consensus implementation used by Vaulta is:

Antelope Spring — GitHub

What just happened?

In this mission you did more than press a voting button:

1. You learned that the active Block Producer set is determined by on-chain voting.

2. You learned that staked voting value counts toward governance while a liquid $A or $EOS balance does not.

3. You first signed eosio::voteproducer with eossupportbp as a direct producer selection.

4. You then signed the same system action with eossprt.spt as a proxy, which replaced your direct selection.

5. You delegated voting power, not custody, tokens or account permissions.

6. You verified the proxy relationship on your own account.

7. You inspected the proxy itself to see which Block Producers currently receive its combined voting weight.

8. You learned why voting is not necessarily a one-time decision: vote weight becomes relatively weaker when it is not periodically refreshed.

What you should remember

• Vaulta uses DPoS (Delegated proof of stake) to select its active Block Producers.

• The active producer set consists of 21 Block Producers.

• An account can directly vote for up to 30 producers.

• The same vote weight is applied to each selected producer; it is not divided among them.

• Liquid $A or liquid $EOS does not create voting power.

• REX value contributes to voting power while the REX position is still held.

• Legacy CPU/NET stake can also contribute to voting power.

• A voting proxy receives voting weight, not your assets or account authority.

• Direct BP voting and proxy voting are mutually exclusive.

• Selecting a proxy replaces your direct producer list.

• A proxy can later change which BPs it supports without moving your tokens.

• Your vote does not expire after a week or month, but an old vote becomes relatively weaker compared with freshly updated votes because of the protocol's time-weighting mechanism.

• You can change your producers or proxy later by submitting another vote.

Quick Quiz

1. Which value currently contributes to Vaulta voting power?

• A. Every liquid $A held in the account

• B. Value represented by REX and legacy CPU/NET stake/allocation

• C. RAM owned by the account

• D. Every token visible in Blocksfinity

2. What happens if you directly select several Block Producers?

• A. Your vote weight is divided equally among them

• B. Only the highest-ranked producer receives your vote

• C. Your calculated vote weight is applied to each selected producer

• D. Your $A is transferred to the producers

3. What authority does eossprt.spt receive when you select it as your proxy?

• A. Authority to transfer your $A

• B. Your active private key

• C. Your voting weight for Block Producer selection

• D. Ownership of your REX

4. You directly voted for eossupportbp and then select eossprt.spt as your proxy. What happens?

• A. Both voting methods remain active simultaneously

• B. The proxy selection replaces your direct producer selection

• C. Your REX is transferred to the proxy

• D. Your previous vote becomes permanent

5. You selected a proxy several months ago and have not changed anything since. Which statement best describes the situation?

• A. The proxy relationship automatically expires every 30 days

• B. You must vote every week or your tokens are unstaked

• C. Your proxy selection remains, but your stored vote weight can become relatively weaker compared with freshly updated votes

• D. The proxy gains control over your account after six months

Answer footnote: Q1:2; Q2:3; Q3:3; Q4:2; Q5:3.