Vaulta (fka EOS) Node Operator Meeting: MSIG Plans, System Contract Changes, And Gossip Network Testing

The latest Vaulta Node Operator Meeting on June 11, 2025, covered some big changes coming up. They talked about a new multi-signature (MSIG) plan for system contracts, a full rework of how staking and rewards will work, and how they'll handle BPay claims. There was also a lot of discussion about testing the new Antelope Spring v1.2 RC3 on the Jungle network. It sounds like things are moving fast, and everyone's getting ready for these updates.

Key Takeaways

A major Vaulta system contract update is planned for July, which will change how staking and rewards work, moving everything to the $A token.
The new system will only allow staking and unstaking in $A tokens, and rewards will also be claimed in $A.
The team is working with proxy operators to help them switch over to the new token system gradually.
There's a plan to add a wrapper for BPay claims to make sure they still work with the new token system.
Node operators are testing Antelope Spring v1.2 RC3, especially the new gossip-based peering, to make sure it's ready for prime time, with recommendations for production setups.

Upcoming Vaulta MSIG for System Contract Deployment

So, the Vaulta Foundation is planning a multi-signature (MSIG) transaction. Word on the street is they're aiming for a proposal around July 8th. The goal? To get it executed by July 15th, but that depends on getting enough approvals.

This MSIG is all about updated system contracts, bringing together changes to staking, rewards, and peer key registration.

What's changing, exactly?

First off, they want to make staking and un-staking only happen through the core.vaulta contract. Think of it as streamlining the whole process.
BP's will be able to register peer keys. This is needed for the Spring v1.2.0 gossip-based BP peering.
You won't be able to stake $EOS anymore. Only staking in $A will be available through core.vaulta.
Same goes for unstaking – no more unstaking to $EOS. $A is the way to go via core.vaulta.
And BP reward claims in $EOS? Nope. Gotta claim those rewards in $A through core.vaulta.

Staking and Claim Rewards Overhaul

Okay, so the system is getting a bit of a makeover when it comes to staking and claiming rewards. Basically, everything will need to happen in tokenized form. No more direct EOS issuance for rewards, which is kind of a big deal.

Think of it like this:

Staking and unstaking? All through tokens.
Claiming rewards? Yep, tokens again.
The goal? Tighter control over how tokens are distributed. Makes sense, right?

I know the lead developers are still working out the nitty-gritty details, but the main idea is to streamline things and keep a closer eye on the token flow. It's all about making the system more efficient and, I guess, easier to manage in the long run.

Proxy Infrastructure Coordination

There was some talk about how to work with the big staking proxies during the changeover. The main thing is making sure everyone's on the same page as Vaulta moves to a new system.

Some proxies will start taking fees in the new $A token but still pay out rewards in $EOS for a bit. It's like a halfway point.
The plan is to eventually switch over to a fully $A token-based reward system. It's a gradual thing.
Node operators should speak up if they know of any other proxies or pools that might be affected by these changes. The more info, the better.

BPay Claim Handling Gap

So, it looks like the current system contract updates kind of forgot about the eosio.bpay claim reward integration. Oops! This means block producers might not be able to claim their rewards properly during the transition.

To fix this, the idea is to add a wrapper action. Basically, this wrapper would let BPs claim their rewards in the new token format. This is important for a few reasons:

It keeps things running smoothly during the switch.
It makes sure no one misses out on rewards they're owed.
It gives everyone a little breathing room, so there's less chance of something breaking.

Basically, it's a quick fix to avoid a potential headache. The timing is flexible, so it shouldn't mess anything else up.

Claim Window Restriction Review

So, there's this old rule that says you can only claim stuff within a 24-hour window, plus one extra second. It's kind of annoying, right? Well, there's talk about changing it. Someone suggested making that window bigger or just getting rid of the restriction altogether with a contract update.

Node operators seem to be on board with the idea, but they think it's best to wait until after the MSIG thing is done. Makes sense, one thing at a time. A future MSIG could include this change for a smooth deployment. Basically, they don't want to mess with it right now and risk causing more problems than it solves. It's all about keeping things stable, you know?

Antelope Spring v1.2 RC3 Testing and Enhancements

Antelope Spring v1.2 RC3 is here, and it's bringing some interesting changes. This release focuses on fixing some annoying issues and making things a bit more flexible for node operators.

It's not a mandatory upgrade for test participation, so no pressure there. Here's a quick rundown:

The update trims server addresses. This should help cut down on misconfiguration errors. We've all been there, right?
It now allows duplicate gossip peer IPs. This is good news for those running more complex setups.
Gossip peering behavior will stay the same as RC2. So, if you're already testing, things should feel pretty familiar.

Gossip-Based Peering Network Validation

So, the next test round is all about making sure the automated peer discovery and connection stuff actually works. The goal is to see if nodes can connect just by using the gossip data they receive.

Here's the plan:

Everyone participating needs to remove all their manual peer entries, except for one designated node. This forces the system to rely on gossip.
The idea is to confirm that nodes are connecting only based on the gossip data they're getting.
The Jungle Testnet Telegram group will be coordinating all the configuration and scheduling. So, keep an eye on that for updates.

Production Peering Recommendations

When it comes to production block producers (BPs), direct external peering is generally not a good idea from a security standpoint. It's much safer to implement a more layered approach.

Here's what's recommended:

Set up a "Canary Node" architecture: BP → Canary Node → External Network.
Keep your gossip configurations on the canary nodes, not directly on the BPs.
This setup helps with firewall compatibility and keeps your BP operations isolated from any network weirdness. Basically, it's like having a buffer zone to protect the core of your operation.

Conclusion

So, that Vaulta Node Operator Meeting on June 11, 2025, covered a lot of ground. They talked about the upcoming multi-signature (MSIG) plan, which is a big deal for new system contracts. This means changes to how staking and rewards work, moving everything to $A tokens. They also discussed working with proxy operators and testing the Jungle network for Antelope Spring v1.2 RC3. Plus, they brought up issues with BPay claims and how they might fix reward claim timing later on. It seems like a lot of moving parts, but it's all about making the system better.

This article was created with support from AI-driven technology, drawing on multiple reputable sources. The final content has been thoroughly reviewed and edited by BlockzHub's editorial team to ensure accuracy, clarity, and coherence. Original reporting sources are credited whenever appropriate and as required. The opinions expressed in this article do not necessarily represent the official views or positions of BlockzHub. This article is intended for informational purposes only and should not be considered financial or professional advice. Investing involves risk, and you should consult a qualified financial advisor before making any investment decisions.