Verifiability is the most important edge of crypto.
Bitcoin and Ethereum gave us verifiable money and finance. The next step related to verifiability is different from the 2 previous steps.
The thing with Bitcoin and Ethereum innovations is that both of these types of verifiability exist within the crypto environment, more precisely, on-chain environment.
After people truly explored the power of on-chain verifiability, there was a time when people tried to build everything on-chain. Games, messengers, utilities, music, news, every type of classic application was put (or almost put) on-chain.
During that mania, few people said: "Why does it have to be on the blockchain?".
A lot of people from TradFi and IT sectors started building the same stuff they were building in their industries, but on the blockchain. Most of them didn’t work out, more accurately, almost none of them worked out.
That question became a meme. The main answer to this question was: "it doesn’t have to be on the blockchain". I believe both the question and the answer were wrong.
1. First reason: people didn’t understand the core value proposition of crypto.
The core idea was just to put something on-chain, not thinking about the benefits that on-chain deployment brings.
Therefore, the core value proposition at that time is that something on-chain is already better than something not on-chain, solely because it’s built on decentralized infrastructure.
• The core advantage is clear — the application is using decentralized architecture.
• The core disadvantages are also clear — expensive and slow computations compared to centralized architecture.
So that’s it, right? No.
The main value that apps gain from being on the blockchain is not decentralized infrastructure itself, but verifiability that this decentralized infrastructure brings. Building the whole application logic on-chain is painful and irrational, because of multiple reasons:
• You’re limited to specific software that only works within a certain VM (virtual machine)
• You’re limited to specific hardware for your application needs
• You’re limited to the consensus protocol of the blockchain
• You’re limited to interactions with the outside world and getting external data
Yes, smart contracts can get external data via oracles, but they have their own trust issues and this data is public. Blockchains operate on the premise of transparency, so getting external public data is not hard, but getting private data is way more difficult (don’t forget about trust assumptions).
Following this logic, it may seem that we should stick to only what the on-chain industry offers and build within these limits, right?
Of course not!
The biggest advantage that crypto has is verifiability: every user can independently verify the correctness, integrity, authenticity of every action. Most importantly, they can be sure they’re not cheated on & prevent themselves from cheating on other users.
However, as I said before, not everything can be put on-chain, because it’s either slow, expensive, or simply impossible.
You cannot just put expressive and complex instructions (code) on-chain. Copy and paste doesn’t work in that case.
That’s why previous solutions didn’t work: they tried putting the whole infrastructure on-chain, which naturally limits the functionality of the application, because web3 dev tools are way narrower than web2 tooling (at least for now).
2. If we can’t build the whole infra on-chain, can we build at least a part of it?
Do all applications need verifiability? No, but most of them.
Let’s take a platform where you’re currently reading this writing — Twitter. As noted by @shilpi_jc, Twitter needs verifiability for:
• ad revenue calculations (because creators want to be sure they’re paid fairly)
• real user views (to make sure views are not botted)
• trending topics (because it has massive power over public discourse)
• etc.
"Why are we discussing Twitter? nobody is going to put Twitter on a blockchain".
Yes, nobody is going to do that, because it’s impossible:
• you can’t call APIs
• you can’t run bot detection algorithms
• you can't do anything complex
What you can do is to write a simple function that calculates payouts based only on view count which can be easily botted.
If we consider complex systems such as AI, @_jasonwei wrote about Verifier’s Law: “The ease of training AI to solve a task is proportional to how verifiable the task is.”
If something is easy enough to solve (like transfers), it can be verifiable on-chain. Training complex AI models takes a lot of resources, therefore the verification of this model will take a lot of resources as well which current blockchain infra is just not ready to allocate.
• We can’t put complex app logic on-chain, but maybe we can put at least the core part of this logic to update state and facilitate value transfers?
• You can’t run bot detection algorithms to calculate the real number of views, but can we at least have payouts for these views on-chain?
We can, we can also store and update the final state on-chain, it’s not that computationally expensive.
So, we decided that we can keep consensus-related logic on-chain, but what about more complex computations?
To give you an idea of how far we’re from putting everything on-chain, @0xbodu noticed that:
• It would take 1000s of MegaETH chains to replicate Uber's global functionality.
• And it would take 100s of MegaETH chains to do the same just for NYC.
3. Can we keep basic logic on-chain & make complex logic verifiable?
We definitely want to keep basic logic on-chain, but what about other more complex logic?
The first natural thought is using something like AWS and its microservices. Yes, we can, but it lacks verifiability which is crucial for a lot of both consumer and infra applications.
What should we do?
We have to find a way to make this complex logic verifiable. We already have lots of verifiability for digital assets & smart contracts, but now we want to apply this to more complex infrastructure.
4. EigenCloud?
@eigenlayer recently rebranded to EigenCloud to increase a focus on verifiability. Even though EigenLayer was mostly known as the restaking protocol on Ethereum, this perception is not exactly correct.
Restaking subconsciously means verifiability, if something can be slashed — it can be verified. Restaking is part of why verifiability is possible, but adding slashing to the infrastructure doesn’t automatically make it verifiable.
All applications consist of multiple components. The core learning behind the EigenCloud product is that not every component of the application has to be verifiable, and if they need verification, there are different levels of that.
There are 3 different levels of verifiability in most of the applications:
• Simple logic (transfers): on-chain verifiability
• Complex logic (API, algorithms, AI/ML): off-chain verifiability
• Routine logic: no verifiability
EigenCloud focuses on off-chain verifiability where complex systems and components of complex systems must be verified.
There have been countless articles about EigenCloud architecture, off-chain verifiability and how it works and I don’t wanna repeat them.
What I want to do is give 3 examples of how important verifiability of complex systems is and how even non-crypto systems can benefit from EigenCloud.
I’ll take 3 different cases: gaming, robotics (inspired by @jinglingcookies), and future cyberpunk relationship between agent and human.
5. Verifiability in gaming & how to make the game more fair.
I spent 7 years of my life (more precisely 12,000 hours) playing Team Fortress 2 (TF2) which is a multiplayer shooter game. I’ve seen enough and I know how every mechanic of the game works.
However, there were things that made me deeply upset. I didn’t realize why until I started learning more about verifiability and applying it to my previous experience.
• We had the problem of hacker bots flooding the servers and 13 out of 24 players were bots.
• Bots were kicking real players by voting, because they’re a majority.
• They destroyed servers and made the game literally unplayable for a certain period of time.
Yes, anti-cheat systems exist, but those anti-cheat systems weren’t able to identify that these were bots and hackers, they kept playing the game unfairly.
If anti-cheat systems verified that the player is a bot, hacker, or using cheats, they wouldn’t be able to play. If anti-cheat systems falsely accused real players of cheating — those systems would be slashed.
Another interesting feature of TF2 is random crits.
Random crits happen randomly when the player shoots the weapon and it gives 3x more damage than they’d usually get from a normal hit.
• Problem: there are some weapons in the game that constantly give more random crits than other weapons.
• When the base random crit chance is 2%, some weapons gave 20% chance and used unfair advantage over other players.
If the logic responsible for random crits would be realized in EigenCloud, it would be verifiable and the weapon would eventually be nerfed.
Obviously, TF2 doesn’t need verification for everything, but some components really need this.
The logic for storing and trading items within the game can be stored on-chain and be fully verifiable, because this logic is pretty trivial. I’d play another couple of years if they fixed those problems (maybe).
6. Verifiability in the robotics industry & why it's way more important than you think.
The robotics industry is developing pretty rapidly and there are lots of problems as well, especially related to secure interoperability between 2 robots.
• Imagine you have a robodog that patrols your house.
• Robodog detects something weird and suspicious.
• Robodog alerts your humanoid robot at home about what it saw.
The process of informing is the data transfer, that data has to be secure and verifiable, otherwise it could literally risk your life.
In that case, both robots can even operate as mini-blockchains storing a shared state of memory, where every piece of information is verifiable.
For the verification process (EigenVerify) data has to be stored somewhere (EigenDA), to make sure it’s available for verification for every period of time within a timeframe.
• When we deal with robots, we have to be sure that each robot is verifiable.
• If we deal with multiple robots, we have to make sure the messaging (interoperability) between these robots is also verifiable.
Misalignment and unfair behavior could have far worse consequences than bots in computer games.
7. Verifiability in future zero-employee companies run by AI agents.
@shayonsengupta wrote an amazing article at the beginning of 2025 about the Human-Agent Relationship. According to the article, in the future there will be companies with zero employees where there are single or multiple agents operating.
It will be funded by humans and agents will allocate capital for actions it can't do or be intelligent enough to think about what it needs to grow the company.
The assumption is that agents can do the same in the future and will be so intelligent that any human input will ruin the outcome and trend towards zero.
(The same happened before with chess bots where minimal human impact makes the system perform worse than it would without human touch)
If there's really the world we will be living in, we really need verifiability of each action that the agent will do.
Especially in this connection between agents and humans. Agents will give tasks to the humans and reward them after completion.
• how to verify that the task was indeed completed?
• how to verify if an agent rewarded the human?
• how to verify if an agent rewarded the right human?
• how to verify if an agent rewarded the right amount of money to the right human?
There are infinite questions and only one answer:
Everything has been verified to make sure the system is not malicious and harmful.
Crypto rails are the best fit in this case as payments can be facilitated on-chain, while more complex infrastructure of agents and human-agent coordination can be off-chain.
8. Usage of verifiability outside the crypto industry.
Infrastructure will trend towards being globally applied to the wider crypto ecosystem and then to outside of crypto.
• For example: EigenCloud is not limited to Ethereum, this infra can be used for other L1s like Solana or other L2s with or outside Ethereum.
• Same with EigenDA, it’s not just middleware between L2 and L1, it can be applied to any components where computation inputs and outputs must remain accessible for verification.
Crypto verifiability can even be used in sports judging events.
• In sports like figure skating or gymnastics, judges subjectively score performances on artistry and technique, often leading to varied scores.
• Outlier scores may invite scrutiny or bias accusations.
• Judges might align with the majority to avoid criticism.
An AI model could standardize evaluations using predefined metrics (e.g. motion tracking), with penalties only for operators who manipulate the model’s inputs or outputs.
Each action of this AI model must be verifiable, otherwise it can also be biased towards certain outcomes and it just doesn’t make any sense.
There are 3 levels of verification:
• Blockchain (on-chain): handles payments, non-custody, and simple logic
• EigenCloud (off-chain): handles complex systems that really need verifiability
• Traditional Cloud: handles content storage, user interfaces, etc.
While most apps genuinely require verifiability, they don't have to be entirely verifiable. This is because some aspects simply don't need verification, and there's no need to include it merely for the sake of verifiability.
The core idea behind EigenCloud and the broader edge of crypto is to provide verifiability where it's truly needed, not for everything that exists.
Crypto has enabled significant progress in zero-knowledge proofs — a concept that existed previously but received less attention. The same will happen with verifiability, in fact, it's already happening.
Show original