CocoCat

From my perspective, 2021 was when crypto switched from niche to mass attention. Since then, most people cared less about the upgrades and cared more about the results. They want Ethereum to be faster, cheaper, and more reliable. And whether people admit it or not, one of the clearest paths to make these things happen is the ZK tech. ZK is no longer “a research thing.” Vitalik has been clear that ZK is now part of core Ethereum engineering, but I also want to be clear on something else. ZK is bigger than Ethereum. It is becoming a general tool that can plug into any chain, any app, and even into normal internet workflows. -------- Last year, 2 things happened with ZK developments: 1. Proof systems got fast enough to work in actual products: I admit it is far from perfect, but teams can build faster with it without complications. There are example products shipping, like KAITO using ZK attestations, and infrastructure teams like Brevis and Succinct pushing the “proofs as a normal feature” direction. 2. Ethereum shipped PeerDAS in the Fusaka upgrade: In simple terms, this is a big move for scaling data without forcing every node to download everything. Even if you are not an Ethereum person, it matters because Ethereum is still where many ZK systems finalize and post their proofs, and cheaper, higher-capacity data changes what these systems can safely do. -------- My end goal for ZK is simple. I want the normal user to be able to verify a proof for a regular action at any time, without learning new words or trusting a middleman. So here are the ZK utilities I am watching closely: 1. Proving web facts without exposing your account: People want to use web2 data in web3, but they do not want to screenshot, dox themselves, or trust a random oracle. zkTLS and TLSNotary style systems, by @tlsnotary, exist for this. They let you prove a website said something, without revealing your private session data. In plain terms, you get a “receipt” that the site showed a fact, but you keep your personal details to yourself. 2. Proving you received an email, without showing the email: This is bigger than it sounds. zkEmail is built around the idea that you can prove an email property, like “this came from this domain” or “I received this,” without exposing the full content. This can power simple things like private access, where you can prove you qualify to enter without anyone seeing your email details, and safer account recovery, where you regain access without handing out private information. 3. Proving computation, without needing to trust the person doing it: This is the broader idea behind zkVMs and ZK coprocessors. One party does the heavy work, and everyone else checks the proof quickly. Here are 3 examples you can relate to: - Crosschain validation: You lock USDC on Ethereum and want the same USDC on Gnosis. Instead of trusting a bridge team to “confirm” your deposit, a ZK light client can prove to Gnosis that Ethereum finalized the transaction, then the bridge releases funds. Gnosis already uses this approach through Succinct’s integration for OmniBridge. - Rollup infrastructure: When you swap on a ZK rollup, the rollup batches many transactions, updates balances, and then posts a proof to L1 that the batch was executed correctly. You do not need everyone to rerun every swap because the proof is the receipt. - Proof-based automation: A project wants to reward users who actually did something in a campaign, like “used the app 10 times,” “provided liquidity for 30 days,” or “traded above a threshold.” A ZK coprocessor can compute that using historical onchain data, then send a proof so the contract pays automatically. Brevis is a strong example of this direction. 4. Verifiable AI outputs This year, I think AI agents will take a different form, more like a reward as a service. For that to work at scale, projects need a way to prove the agent did not fake the results. zkML can help by allowing the agent to submit a reward list plus a proof that the approved model and rules were used, so that the contract pays users, and the agent only gets paid if the proof verifies. -------- 📌 ZK for 2026 I am not trying to recap history. I am simply just looking at where this goes next. ZK is also one of the most important tools for privacy, and as long as people want privacy, they will keep coming back to zero knowledge. So my 3 angles for 2026 are simple: First, security becomes a moat. People think ZK is about speed, but once proofs expand to settlement, identity, and large value money flows, plus real access, the questions to be asked will be: can a fake proof slip through, or can a bug or upgrade mistake let someone move funds they do not own? That is why the focus is shifting from proving fast to proving safely, with deeper audits and clear fail-safes. Second, ZK will show up where users already are, including wallets, exchanges, onboarding flows, consumer apps, and everyday product features. Its goal will be to be the layer that makes things easier to verify. Third, liquidity will reward the boring winners. As proving gets cheaper, capital will flow toward the teams that make ZK easy to use in products, with low cost, stable performance, simple integrations, and tooling that developers can ship with. These products become the default infrastructures that everyone routes through, and even if nobody tweets about them daily, they will capture fees, volume, and long-term dependence. -------- Finally, my expectation is for ZK to become normal. By normal, I mean: - A developer can add proofs without hiring a cryptography team. - Users can do it without learning new words. - The security standard is clear enough for apps to rely on it. - Proofs help you reveal less, while still being trusted more. This year, I expect ZK to move from impressive to useful. And I will be sharing my next ZK piece soon, focused on the liquidity angle for ZK, the layers that capture value, and the areas people should pay attention to. Thank you for reading!

“Ethereum was not created to make finance efficient or apps convenient. It was created to set people free” This was an important - and controversial - line from the Trustless Manifesto ( trustlessness.eth.limo ), and it is worth revisiting it and better understanding what it means. “efficient” and “convenient” have the connotation of improving the average case, in situations where it’s already pretty good. Efficiency is about telling the world's best engineers to put their souls into reducing latency from 473 ms to 368ms, or increasing yields from 4.5% APY to 5.3% APY. Convenience is about people making one click instead of three, and reducing signup times from 1 min to 20 sec. These things can be good to do. But we must do them under the understanding that we will never be as good at this game as the Silicon Valley corporate players. And so the primary underlying game that Ethereum plays must be a different game. What is the game? Resilience. Resilience is the game where it’s not about 4.5% APY vs 5.3% APY - rather, it’s about minimizing the chance that you get -100% APY. Resilience is the game where if you become politically unpopular and get deplatformed, or if a the developers of your application go bankrupt or disappear, or if Cloudflare goes down, or if an internet cyberwar breaks out, your 2000ms latency continues to be 2000ms. Resilience is the game where anyone, anywhere in the world will be able to access the network and be a first-class participant. Resilience is sovereignty. Not sovereignty in the sense of lobbying to become a UN member state and shaking hands at Davos in two weeks, but sovereignty in the sense that people talk about "digital sovereignty" or "food sovereignty" - aggressively reducing your vulnerabilities to external dependencies that can be taken away from you on a whim. This is the sense in which the world computer can be sovereign, and in doing so make its users also sovereign. This baseline is what enables interdependence as equals, and not as vassals of corporate overlords thousands of kilometers away. This is the game that Ethereum is suited to win, and it delivers a type of value that, in our increasingly unstable world, a lot of people are going to need. The fundamental DNA of web2 consumer tech is not suited to resilience. The fundamental DNA of _finance_ often spends considerable effort on resilience, but it is a very partial form of resilience, good at solving for some types of risks but not others. Blockspace is abundant. Decentralized, permissionless and resilient blockspace is not. Ethereum must first and foremost be decentralized, permissionless and resilient block space - and then make that abundant.