What’s your background, and how did you get involved with Casper?
I co-founded Casper in 2018 after a career in early e-commerce, mobile tech, gaming, and the early days of Web3. I’m now the CTO and President of the Casper Association.

Why did you decide to build Casper instead of developing on existing blockchains?
We saw that existing platforms catered mostly to crypto-native users, not real-world institutions. Casper was created to meet the needs of regulated environments with long-term software maintenance, governance, and accessibility in mind.

What does Casper 2.0 introduce, and how is it different from Casper 1.0?
Casper 2.0 introduces the Zug Consensus protocol with deterministic finality, taking full advantage of upgradable smart contracts, built-in access control, and multi-VM support, all designed for real-world systems that need certainty, flexibility, and developer familiarity.

How does Casper ensure security with instant finality
Deterministic finality means transactions are final the moment they’re added to the chain, so, no need to wait for confirmations. From a security perspective, the idea that ten minutes or ten blocks later you might get a reorg that erases or alters blockchain history, that just doesn’t exist in Casper. 

Why is access control so important and why hasn’t Web3 adopted it widely?
Web2 uses permissioning as a default, but Web3 didn’t prioritize it. Casper enforces it at the protocol level to improve security, governance, and real-world alignment, avoiding common vulnerabilities in admin wallet logic.

Why does it matter that Casper uses mainstream programming languages?
Most developers don’t know Solidity, and companies won’t retrain teams to use it. Casper uses WebAssembly, Rust, and offers SDKs in JavaScript, Python, Go, etc., enabling millions of developers to build confidently on-chain.

How do you plan to attract traditional Web2 developers to build on Casper?
We believe the timing is right. There’s growing institutional interest and massive untapped potential. We’ll announce real-world partners soon, showing how traditional businesses can build on Casper without learning new tooling.

What are you doing to improve user accessibility?
Most people will never download MetaMask or handle seed phrases. Casper is focused on removing friction with tools like CSPR.click, allowing for seamless login and app usage with familiar social sign-ins.

Can developers cover gas fees for users?
Yes. Casper 2.0 includes a hold-and-release gas model (subject to governance vote), allowing apps to “sponsor” gas. Over time, the gas is refunded, turning it from an operating cost into a reusable capital asset.

What’s coming next after Casper 2.0?
Casper 2.1 is scheduled in the next 3 months, introducing a second VM with an even simpler Rust interface and self-describing smart contracts. These can auto-generate SDKs or UIs and support AI-based development.

‍

I’m the CTO and the President of the Board at the Casper Association, the nonprofit that supports and helps grow the Casper Network. I’ve been in this role since last year, but I was actually one of the original co-founders of the Casper project, going all the way back to 2018.

Just to give you a quick background, I’m originally from Amsterdam, the Netherlands. I started out in the early e-commerce industry in the mid-90s, what we’d now refer to as the Web1 era, and ran some of the earliest e-commerce companies in the country. By the late ’90s, I had moved into mobile tech, which at the time was all about premium SMS services, things like texting “ABC” to a short code to get your horoscope for 99 cents. We built out a pan-European premium SMS network and developed applications for big media players.

As networks and devices evolved, so did the apps. We brought Japan’s “i-mode” service which was a precursor to the mobile web, into Europe. By 2001, I joined THQ, one of the top three video game publishers globally at the time, as CTO for mobile. We launched the first downloadable mobile games, which essentially kicked off mobile gaming and the modern app economy.

After that, I moved into social gaming and relocated to Los Angeles, where I still live. Around 2012–2013, my work in gaming started overlapping with the early Web3 world. I was based in Santa Monica, known as Silicon Beach, where a lot of early blockchain projects were born. In fact, some, like Tether, were founded in our office’s meeting room. I became a technical advisor to many of these projects and their investors, all while serving as CTO of a social gaming company. When we sold that company in 2016, my part-time interest in Web3 became a full-time obsession.

Then in 2018, my partners and I co-founded the Casper project to bring an enterprise-grade proof-of-stake network to life. And that’s how I got here.

‍

What we saw, and perhaps we were a little early with it, is that the Web3 space was very insular. And I think up until relatively recently, that’s remained the case, where the solutions and technologies being developed were mainly there to serve the Web3 space itself. Like, how can we do the next shiny thing that the degens like? And it didn’t matter if we moved fast and broke things, like Mark Zuckerberg used to say, because there wasn’t anything real at stake.

We believed that this blockchain technology (distributed ledger technology) has massive potential for the real world and real-world applications, where you have to deal with existing companies, with governments, with regulations, with jurisdictions, with processes that have been around for decades. And they’re not going to move fast and break things.They’re not going to retrain thousands of software engineers from their traditional programming languages onto Solidity or something else obscure that a few thousand people in the world know. They’re not going to develop software without testing capabilities, without deployment pipelines, or without all those things.

So we believed that, in order for blockchain to start integrating with the real world, there had to be a blockchain solution that met the real world where it is. Which means caring about software development best practices, caring about accessibility for developers, and caring about the things businesses actually care about, like maintaining software for years or decades in some cases, and being able to upgrade it as regulations evolve. And being able to mirror restrictions and processes that you have in your real-world company. Like, being able to have access rights to your software.

If you have a financial software program, the CFO is allowed to do a lot more things than the accountant or the marketing person. Those things didn’t exist in blockchain platforms. And we believed that, in order for blockchain to become relevant outside of its own sandbox, those had to come into existence.

‍

 Maybe what’s helpful for your audience is just to point out that Casper 2.0 launched on mainnet just three days ago, on Tuesday. It’s been a major launch. We’re extremely happy with the momentum and the feedback we’re getting from the market. It’s been a major launch that was literally years in the making.

But I’d love to describe what Casper 2.0 is, so we don’t confuse everyone. Let’s focus on what’s out there now versus what was out there before, because that’s what we’re building on top of, if that’s okay.

Let me walk you through some of the things Casper 2.0 introduces.

First of all, we launched a new consensus protocol. Casper, as I mentioned earlier, is a proof-of-stake protocol. It’s built on the original Casper whitepaper that was developed in the Ethereum research group back in 2015. Our researchers took that over in 2018 and ultimately launched Casper 1.0 as a first iteration of a Casper-based proof-of-stake blockchain. That protocol was called Highway. Zug is the next version of that, actually, it’s really a full replacement.

One of the key properties of Zug is deterministic finality. If you’re familiar with other blockchains, and many users are, whether it’s Bitcoin, Ethereum, or other Layer-1s and Layer-2s, they use what’s called probabilistic finality. That means when a block is added to the chain, it’s not finalized immediately. The longer you wait, the more likely it is that it won’t get dropped or replaced. That’s why, when you send tokens to an exchange, it doesn’t become tradable immediately. It shows up as “waiting for X confirmations”,  like Ethereum usually waits for 64.

That might be acceptable for crypto-native use cases, but it’s really not ideal when certainty really matters. Zug, our new consensus protocol, has deterministic finality, which means that the moment a block is produced by the network, it’s instantly final and permanent. That’s important. For example, if you’re selling your home or doing a large real estate deal, you don’t want to wait for 64 confirmations to know whether it’s truly sold. Zug eliminates that uncertainty. It’s a big deal, not just for real estate but for financial transactions, regulated asset transfers, legal agreements, anywhere ambiguity creates risk.

Another thing Casper 2.0 introduces is built-in access control. This lets developers define roles and permissions directly within their smart contracts, at the protocol level. Instead of reinventing that logic or building workarounds, it’s handled natively.

In the real world, you have governance requirements. Someone in the C-suite has different rights than someone in marketing. Casper lets you embed those rules directly in smart contracts, and the network enforces them at the protocol level.

Another thing I mentioned is smart contract upgradability. Casper allows contracts to evolve without needing to redeploy them entirely or migrate user data. That’s critical in the real world, where business logic and regulations constantly change. Being able to update a contract transparently and securely, without disruption, is a huge advantage.

We also introduced a multi-VM architecture. This means different virtual machines can now run side by side on the same Layer-1 network. In other environments, different execution engines are typically implemented via sidechains, rollups, or Layer-2s. In Casper’s case, these are fully integrated VMs that can interact with each other, allowing applications with different needs to operate natively in the same environment, on the same Layer-1.

And finally,  something that’s always been a big focus for us, is developer accessibility. In the Web3 world, obscure languages like Solidity have become the norm. There are maybe 20,000 developers fluent in Solidity and similar languages. But the real world has tens of millions of engineers who know mainstream languages and tools. You’re not going to retrain those people or hire new Solidity devs. You want to use your existing engineering base.

Casper is built on WebAssembly. We support smart contract development in Rust, and WebAssembly can be compiled from any mainstream language. We’re targeting those tens of millions of software engineers, not the few thousand Web3 specialists. And we provide SDKs in JavaScript, Go, .NET, and other popular languages.

Casper 2.0 is a step toward making blockchain infrastructure viable for long-term, real-world systems that need secure, adaptable, and understandable development processes.

‍

It’s a couple of things. It’s about user convenience: things go faster, and you can be more confident sooner. But I think that’s not the main advantage. The main advantage is really outside of DeFi, in the real world, where this concept of probabilistic finality doesn’t exist.

When you sell an asset, it either belongs to the seller or the buyer. There’s no such thing as it being in limbo for a minute, ten minutes, or even an hour, like with Bitcoin, where nobody knows who owns the asset or whether the transaction will go through and end up being the buyer’s or revert back to the seller. That simply isn’t acceptable in real-world environments.

If you want to implement real-world use cases, you have to mirror how the real world operates, and that’s pretty atomic: at one point it belongs to the seller, and at the next point, to the buyer. This limbo situation just isn’t tolerated outside the Web3 sandbox.

Now, on the security question: The reason why confirmations are a thing in probabilistic consensus is because of the possibility of reorgs and rewrites. That’s something that doesn’t exist in Casper. As I mentioned, when a block is added to the chain in Casper, it cannot be reorged, rewritten, or superseded. It’s a serial process. Once it’s added, it never goes back.

That’s what makes it final. So from a security perspective, the idea that ten minutes or ten blocks later you might get a reorg that erases or alters blockchain history, that just doesn’t exist in Casper. That’s the key difference between deterministic and probabilistic consensus.

‍

That’s a good question, and honestly, you could ask that about a lot of things. As I mentioned earlier, the Web3 industry has been focused on a narrow set of use cases where certain features, like robust access control, weren’t seen as essential. Most smart contracts today do have some form of access logic, like assigning an admin wallet address to perform privileged actions. But these are all custom implementations and often a major source of vulnerabilities.

We’ve seen many exploits where the admin wallet could be overwritten due to a bug, or methods meant to be restricted weren’t properly protected. These patterns repeat across the ecosystem, and they place too much responsibility on individual smart contract developers.

Casper solves this at the protocol level. Developers can define access roles for each contract method (or “entry point”), and the network itself enforces those rules. If someone tries to call a method without being in the correct role group, the system throws an error automatically. This removes the burden from developers and avoids the usual security holes.

Casper also supports native smart contract upgradability and built-in multisignature (multisig) at the protocol level, you can combine all three features to mirror real-world governance flows.

For example, say you want to restrict contract upgrades to the executive team of a company. You define a “C-suite” role, require three out of five members to approve any upgrade using native multisig, and enforce all of it with Casper’s access control. No need for extra code or external governance logic,it’s all handled by the protocol. That gives you real, enforceable, on-chain control that maps directly to how actual companies operate.

‍

 That’s a fair point. We do tend to reinvent the wheel in Web3 sometimes for good reasons, like improving on legacy systems, but often unnecessarily. One example is the dominance of Solidity, which is used by a very small pool of developers, maybe 20,000 globally, and only a fraction of those are full-time or experienced.

Compare that to mainstream languages like Rust or JavaScript, which millions of developers already know. On Stack Overflow’s annual developer surveys, Rust consistently ranks in the top 5. Solidity barely registers.

At Casper, we want to break out of the Web3 sandbox and meet the real world where it already is. That’s why we support WebAssembly (WASM), which lets you compile from many mainstream languages. We also offer SDKs in JavaScript, Go, .NET, and more. The goal is to make blockchain development feel like modern software engineering, because that’s what the real world needs.

‍

There are a few things to consider. First, I think we’re right at the precipice of this transition. Blockchain has been around for about 15 years, and smart contracts for just over a decade, let’s say since Ethereum launched. But the first phase of the industry has largely been an internal sandbox. People building blockchain apps for blockchain users.

Now, that’s starting to change. Over the last year, especially with regulatory shifts in the U.S. and growing institutional interest, we’re seeing real momentum from outside the Web3 space. Companies are reconsidering what they can put on their balance sheets. There’s real interest now in blockchain and digital assets from the traditional world.

From an asset-size perspective, the entire blockchain industry is still tiny,around $3 trillion if you total all market caps. Compare that to real estate, which is well over $999 trillion. We’re just scratching the surface.

So now it’s about offering the right solutions at the right time. I think we have those solutions now. And we’re working on bringing them to the real world. We’ll be launching with partners very soon,real-world applications that will prove you can attract traditional companies and Web2 developers, and bring them into Web3. These are engineers who will integrate blockchain into real workflows, processes, and businesses.

‍

Yes, and I think that’s part of why blockchain is still where it is. If you look at the user experience today, it’s still difficult. I don’t know about your parents, but mine are never going to be able to use a dApp the way we do. Downloadable wallets, 24-word recovery phrases,the user interface is, frankly, abhorrent.

A lot is happening to make things more accessible, and that work needs to continue. If you go back to the early mobile days, people used to know what tech they were on: GSM, CDMA, 1G, 2G, etc. Over time, that complexity disappeared into the background. Today, no one knows what protocol their phone is on, and when you pay for groceries, you don’t think about what payment network it’s running on. That’s where blockchain needs to get to, past the protocol talk, past recovery phrases, and into product-market fit and usability.

At Casper, we’re strong believers in this. We do a lot on the product development side to improve the client libraries so developers can build dApps with seamless onboarding. We have a library called CSPR.click, which is a wrapper around all supported wallets. It also enables social logins, so users don’t have to deal with complex wallet setup. They can just click “Sign in with Google,” like they do everywhere else, and start using the app within seconds.

The average person doesn’t want to know what protocol they’re using. They just want to move money or use services that work. Banks have had 100+ years to make that seamless. Most people are fine using their banking apps to wire money,they don’t care about the backend.

Blockchain needs to meet that standard. Right now, it’s still driven by hype cycles and tech enthusiasts hopping from one shiny project to the next. But the long-term value will come from real utility, solving real-world problems. It’s not about who has 120 million TPS. It’s about who can attract users and fill blocks with actual meaningful transactions.

‍

Very good question. It’s a yes-ish, because it’s not really gas stations. But we have a couple of features in that area that are actually part of the 2.0 code base, although they haven’t been activated on mainnet yet. I’ll describe what they are.

We have a concept called essentially gasless transactions. They’re not technically gasless. The way it works: as a developer or user, instead of paying a gas fee that leaves your account as an expense, there is a hold that gets placed on the gas. You still need gas from a security perspective, to provide an economic guarantee for the execution of your transactions, but you don’t necessarily have to withdraw it from the user.

What we’re doing is putting a hold on the gas, and then after a set period of time, that hold gets released, so it comes back to the user. It’s effectively a free transaction with a temporary hold. This provides the necessary network security while making transactions essentially free.

The nice thing about this for a dApp is that instead of having to predict how much it will cost to run your application week-to-week or month-to-month, and tracking it as an expense (because gas fees that don’t come back are a direct expense), you’re locking up some capital temporarily, and it returns. So it moves from OPEX (operating expense) to a CAPEX (capital expense). You just need to calculate the maximum capital you need to run your app. It’s not a cost, just a capital requirement.

This feature is launching very soon, and we’re going to make it subject to a governance vote, because changing the economics of the protocol is something the community should have a voice in.

In addition, we have a concept called contract and accounts unification, or merge, which is similar to account abstraction. Contracts can act as accounts and accounts as contracts. This lets DApps pay for themselves directly, so the responsibility for gas shifts from the user to the DApp.

If you combine that with the gas hold feature, you essentially get free transactions. It doesn’t even cost the DApp anything over time. So yes, lots of interesting things are happening to make blockchain more user-friendly. If both of these go live, users won’t have to deal with gas at all, the DApp handles it entirely.

‍

Absolutely. Casper 2.0 went live, 72 hours ago or so. First of all, we are super happy with how seamless that went, because this has been a major, major upgrade that’s been, as I mentioned, two years in the making, and literally involved several hundreds of thousands of lines of code that were added or modified in the Casper protocol software stack.

The engineering team really did something massive that I’m super proud of and really impressed with, our team. At the same time, launching such a massive protocol upgrade on mainnet was a little stressful. I can tell you that I didn’t sleep very well the night leading up to it, because no matter how many times we’ve tested it, and obviously this upgrade has gone through various test networks, both internal and public testnets, as well as ad hoc networks that we spin up on an almost daily basis, launching something on mainnet, which is really a unique environment… you’re dealing with validator nodes that are spread all over the world, running on different types of hardware, in different types of data centers with different latencies and firewall configurations, etc… There’s a lot that can go wrong.

And thankfully, nothing did. It actually went as smoothly as we could imagine. This was the first time we’ve seen it operating out there on mainnet, in the real world. And obviously we’re very interested in the performance metrics we’re seeing, and we couldn’t be more encouraged. We’ve seen things like block finalization times between the old consensus protocol, Highway, and the new consensus protocol, Zug, improve by a factor of 100–150x, meaning there is massive, massive room for throughput and speed improvements on the new protocol.

Like I said, it’s been two years of development. We’re switching back to a sort of three-month release cycle, where every three months we want to release a minor upgrade. The next one is Casper 2.1, and that will add a new virtual machine, the second VM to run in parallel on our multi-VM architecture.

That new VM will offer an even more simplified Rust-based smart contract interface for developers. It introduces new capabilities like self-describing smart contracts, which can automatically generate things like SDKs and potentially even apps based on the contract metadata. This is something that could unlock very interesting potential, think about, for example, AI-based software development or applications that dynamically spawn new contracts.

We’re excited about that. And as you sort of hinted at earlier, we’re looking forward to making some announcements of projects coming on board in the next weeks that are making use of all this. So it’s really an exciting time for Casper.

‍