The latest DeFi Working Group and Validator Connect call provided a detailed look at how the Casper blockchain is evolving and what validators and developers should expect from this evolution. You can watch the recording on our YouTube Channel.
With Casper 2.0 now live on testnet, the conversation revolved around what the upgrade brings; but it didn’t stop there. From validator performance to decentralization and marketing strategy, the session covered a wide range of important updates. Let’s dive in!
.png)
Casper 2.0 went live on the testnet on March 18 at 14:31 UTC. Casper Association President & CTO Michael Steuer stated that the response from validators was overwhelmingly positive, with 98.6% of the staked weight upgrading within 24 hours of release.
Some validators encountered peering delays due to an error in the known_addresses configuration, which caused connectivity problems between nodes. The issue was quickly identified, and a fix was deployed. Overall, the transition proceeded smoothly. The testnet is now operating with the full suite of Casper 2.0 features.
Michael noted that very few blockchain networks have successfully executed such a major version upgrade without serious disruptions.
“Yesterday's testnet upgrade was one of the final milestones of a path that started about two years ago, and this is a major version upgrade that represents one of the most substantial upgrades of a live blockchain network and history of our industry ever attempted in a single upgrade,” Michael stated.
He emphasized that the testnet phase is critical not just for assessing Casper 2.0’s technical performance but also for ensuring that validators, developers, and exchanges are operationally ready for the transition.
The team is closely monitoring validator participation consistency under Zug Consensus, exchange readiness to handle the upgrade without disruptions, and dApp and contract stability in the new execution model.
“We want every exchange, every dApp, every participant to be prepared before we flip the switch on mainnet,” said Michael.
The shift from Highway Consensus to Zug Consensus will improve validator performance and network efficiency. Under Highway, all validators had to work in lockstep, meaning if one performed poorly, it reduced rewards for everyone. Zug removes this dependency, so poor performance only impacts the individual validator.
With Zug, performance is assessed per validator, per block, ensuring that individual validators are rewarded based on their own contributions rather than the overall network’s activity.
The new performance metric is based on signatures and citations per block, ensuring that rewards are accurately distributed according to validator activity.
While some variance per era is expected, the system is designed to average out over time, meaning that short-term fluctuations should not be a concern.
Since the rewards are now based on direct contributions rather than relative performance within the network, validators must maintain consistent participation to ensure steady earnings.
A reminder to validators:
“Validators monitoring their performance on CSPR.live or EraGuardian may see discrepancies because these tools have not yet been updated to align with Zug’s tracking model. Expect updates soon to align them with Zug’s tracking model,” explained Michael.
Casper 2.0’s multi-engine execution model brings first-of-its-kind capabilities to Layer 1 blockchain architecture. This new model allows multiple execution environments to run natively on the Casper network, eliminating the need for Layer 2 solutions in many cases and enabling more complex smart contracts to operate seamlessly.
The update brings improved gas calculations, enhanced efficiency, and more predictable fees for developers.
Michael also stated that SDK updates are fully backward and forward-compatible, making the transition smoother for dApps and exchanges. The JavaScript, Go, and .NET SDKs have already been updated and tested against Casper 1.x and 2.0. Developers are strongly advised to upgrade their SDKs now:
“If you upgrade now, the transition to Casper 2.0 will be completely seamless. You won’t need to make any changes when mainnet activates,” said Michael.
A dedicated developer preview session covering execution engine performance benchmarks took place on February 25, and the next session is scheduled for March 27. Watch the recording of the meeting of February 25th on Casper’s YouTube channel.
The next meeting will take place on the 27th of March at 5:45 PM CET. You can submit your questions and topic requests via Telegram.
Node operators, dApp developers, and exchanges need to prepare for the mainnet upgrade. During the call, Michael provided the steps to ensure a smooth transition.
If You Run a Node:
Complete the preliminary setup steps and perform necessary maintenance.
Stay updated on upgrade instructions for mainnet by reviewing testnet upgrade documentation as a reference.
• Preliminary Setup Steps for Casper 2.0
• Staging Casper 2.0 Testnet Upgrade
If You Interact with RPC via a Public Node or Node-as-a-Service:
Ensure that your service provider is monitoring the upgrade and making necessary adjustments. Review and apply changes to the JSON-RPC interface to maintain compatibility.
If You Use an SDK to Interface with the Network:
Upgrade your SDK immediately for forward and backward compatibility. Review the official migration guides to ensure seamless integration.
Michael provided an overview of the latest updates across Casper’s core product suite, wallet integrations, and decentralized finance initiatives.
Casper’s core product suite, including CSPR.live, Casper Wallet, and CSPR.cloud, has been fully updated for Casper 2.0. Developers using these tools can now integrate Casper 2.0 features ahead of the mainnet transition, ensuring these applications remain fully functional post-upgrade.
The MetaMask Snap for Casper has also been fully updated for Casper 2.0 and is currently undergoing an audit. Once finalized, this update will provide seamless interaction with Casper through MetaMask, further expanding the network’s accessibility.
Other wallets are also preparing for Casper 2.0 compatibility. Ledger is finalizing its Casper 2.0 updates, with testing and auditing being conducted in collaboration with Zondax. The Tangem team is working on compatibility improvements, ensuring smooth integration once the mainnet upgrade is complete.
The RWY Protocol is actively deploying liquid staking contracts on Casper’s testnet, providing a new avenue for staking participation. Meanwhile, Wise Lending, a top liquidity provider on Uniswap V2, is integrating with Casper as its first non-EVM chain, broadening Casper’s DeFi capabilities. Router Protocol is also working on bridging Casper with 50+ blockchains, strengthening cross-chain liquidity and interoperability between different blockchain ecosystems.
Casper continues to increase its visibility by actively participating in major industry events. Here are the highlighted upcoming conferences in which Casper will participate:
Following the event calendar, Michael detailed the new marketing strategy. “We are launching a new marketing campaign to maximize awareness, developer engagement, and ecosystem expansion,” he said.
The multi-month marketing campaign will roll out in phases to ensure maximum awareness and ecosystem participation ahead of Casper 2.0’s full launch.
The campaign will be structured around four key pillars:
Driving Adoption: Highlighting the real-world use cases of Casper 2.0, from enterprise adoption to DeFi integrations and tokenization solutions.
Developer Engagement: Expanding developer resources, hosting workshops, and ensuring builders have what they need to build and deploy successfully on Casper.
User Education: Creating accessible content that explains Casper 2.0’s upgrades, the benefits of its architecture, and how users can interact with the network.
Ecosystem Amplification: Showcasing projects building on Casper, collaborating with key ecosystem players, and ensuring widespread visibility of new integrations.
Collaborations with key partners, including exchanges, will further expand Casper’s footprint in the broader blockchain industry.
On the documentation front, Michael said the need for improved documentation, particularly for validators, node operators, and developers integrating with Casper 2.0, is being addressed.
Michael confirmed that expanding documentation is a priority for the DevRel team. The planned improvements include clearer upgrade guides for node operators and validators, more detailed JSON-RPC documentation for developers, and expanded SDK migration resources to prevent integration issues.
Last but not least, the team is also working on refining the website structure to improve accessibility and ensure that key resources are easier to find.
Moving forward, casper.network and docs.casper.network will be the primary websites for all official information, consolidating developer tools, governance updates, and educational content. The restructuring aims to make it easier for both new and existing users to find relevant information efficiently.
As always, the call concluded with a Q&A session. Here are the highlights:
Q: When will there be an official stress and performance test for Casper 2.0?
The real stress test started when Casper 2.0 went live on testnet. Validators operate in different hardware environments with various configurations, which provides more realistic and unpredictable data than internal simulations.
We’ve been testing for months, from the earliest release candidates to DevNet onward. Our SRE team has been running large-scale performance tests, but the real test happens when validators with different setups start interacting with the network.
The public testnet is out of our control. We don’t control the servers. They’re not homogenous, and people just do what they do. That’s where we see edge cases we wouldn’t catch in a controlled testing environment.
Q: When will Casper 2.0 go live on mainnet?
There is no fixed date yet. If the community were happy with the current state today, we could go to mainnet immediately. However, we are listening to feedback and working with exchanges to ensure readiness.
Not every exchange is the same priority. Some have minimal trading activity, while others are essential to ensuring liquidity. Major exchanges need to be ready first, and are making good progress as we speak.
The release candidates we push to public testnet are meant to be production-ready. If we don’t get critical feedback, that means we can move forward. But we are dependent on factors like validator readiness, integration partners, and exchanges ensuring they are prepared.
Q: How does Casper 2.0’s Zug Consensus change validator performance tracking?
Under Highway, validator rewards were based on network-wide maximum achievable rewards. That meant if some validators underperformed, it affected everyone’s earnings. Zug makes rewards individualized, each validator’s rewards now depend solely on their own participation per block.
With Zug, you can very clearly see a validator’s performance at every block. If a validator is running poorly, they’re only bringing themselves down, not the entire network.
Previously, if one validator started performing poorly, it pulled down everyone. That wasn’t a bug; that was by design. Rewards needed to create an economic disincentive for poor performance. But now, each validator earns based on their own activity, block by block.
Validators monitoring their performance via CSPR.live or EraGuardian should note that these tools still need updates to align with the new model, so discrepancies may appear in the short term.
Q: What steps are being taken to improve decentralization?
There’s nothing preventing independent teams from writing their own node implementation. The protocol rules are open, and any team can create an alternative client.
It should be true today that if someone wanted to write their own node that followed the protocol but had their own implementation choices, they could. There’s no proprietary mechanism stopping that, it’s just that no one has done it yet.
However, we do recognize that some third-party tools and dashboards broke during the Casper 2.0 upgrade due to undocumented breaking changes. We need to improve documentation so validators can better track network health and performance.
Q: How does Casper 2.0 compare to Ethereum in handling a 51% attack?
A 33.4% stake would allow a cabal of attackers to stall the network, preventing transaction finalization but not altering past transactions.
A 66.7% super-majority stake would allow attackers to control network governance, meaning they could approve fraudulent transactions. If a party gains a controlling interest, they control the network. That’s just how proof-of-stake works. If they reach 66.7%, they can propose anything, vote to approve it, and that becomes the reality.
Could you fork the network? Yes. But you would need exchanges and the majority of the community to support the forked chain instead of the compromised one, and that’s not an easy process.
In testnet, we staged an emergency upgrade through social consensus to neutralize an attack scenario. That’s how we would respond in a real-world scenario if needed.
That’s it for this month’s Validator Connect & DeFi Working Group Call. Be sure to join the upcoming X Space for more information and updates from Casper leadership and ecosystem partners.
