Alice Liu: Welcome Ismael, really excited to have you here.
Ismael Hishon-Rezaizadeh: Thanks for having me, Alice. We’ve seen a lot of House of ZK over the last few months, and I’m glad we finally get to do this.
Alice: Likewise. And we’re meeting in person at Devcon, which always makes for a better conversation.
Ismael: Absolutely. The energy at in-person events is just different. Glad the timing worked out.
Alice: Let’s start with an introduction. How did you first get involved in Web3, and specifically, ZK?
Ismael: My background is in traditional finance - I was leading an engineering team at John Hancock, working on early decentralized insurance products during the first DeFi summer. The challenge we faced was keeping client information private while using on-chain insurance and reinsurance platforms, which led me to ZK.
Later, I spent some time as a venture investor, but I saw a massive opportunity in using novel cryptographic techniques to enable verifiable computation at scale. When we started Lagrange Labs, one of the first people I brought on was Babis Papamanthou, the chair of cryptography at Yale. His academic background in ZK complemented our more applied focus, which made for a great mix.
Alice: That’s interesting - you’ve seen the space from both the investor and the founder side. Has that perspective shaped how you approach building a startup?
Ismael: Definitely. As a venture investor, you think about the entire value chain of an industry and where the best opportunities exist. As a founder, you make a similar decision, but you only get one shot, so the level of specificity is much higher.
When I looked at crypto, I saw verifiable computation as the only way to scale on-chain execution meaningfully. It’s what enables applications to do things they otherwise couldn’t. There’s a story I like to tell - years ago, someone said to me that eventually, every application will be cross-chain. At the time, it was a bold prediction. Now, we see that every major DeFi protocol has a cross-chain strategy.
Today, I make a similar prediction: eventually, every application will be a ZK app - whether it’s using ZK to verify off-chain computation, handle data privacy, or power interoperability. It’s just a matter of time.
Alice: That makes sense. But we’re not there yet. What do you see as the biggest barriers to adoption?
Ismael: We’re starting to see adoption, but there are still major challenges. The biggest ones are cost, latency, and developer experience. Historically, ZK has been expensive to use, slow to compute, and difficult for developers to integrate.
At Lagrange, we’re working to solve that with two core products. The first is our ZK co-processor, which lets smart contracts request off-chain computations and get verifiable results asynchronously. The second is our decentralized proving network, which has been live for four months and is used by over 85 institutional operators.
Alice: Let’s talk about that proving network. What are the benefits of decentralizing proof generation?
Ismael: Crypto’s core value proposition is permissionless, unstoppable applications. But if we’re relying on a single centralized prover running on AWS, we’re not really building something unstoppable. We’re just moving the trust assumptions around.
Decentralizing proof generation ensures liveness. If one prover goes offline, another can step in. It’s also about aligning with crypto’s ethos—if we want to build a decentralized financial system, we can’t have a single point of failure in the proving process.
Alice: Lagrange’s proving network is built on EigenLayer. What led you to that decision?
Ismael: When you build a network, you have two major costs: operating costs and capital costs. In most proof-of-stake chains, the capital cost—the cost of staking tokens—is the dominant one. This is why so many Cosmos-based networks struggle with sustainability.
But with ZK, the operating cost—generating proofs—is actually the largest cost. Pairing high capital costs with high operating costs creates an unsustainable network.
EigenLayer offers the lowest capital cost in crypto by using restaked ETH, which is much more capital-efficient than launching a new proof-of-stake token. That’s why we built on it.
Alice: That makes a lot of sense. What are some of the issues you see with existing proving marketplaces?
Ismael: To be blunt, most proving marketplaces don’t have real users. Many are just inflating numbers for a fundraise. The fundamental problem is incentive misalignment.
For example, if you have a network where two provers are constantly bidding against each other, the utilization of each machine is only 50%. That means the cost per proof is twice as high as it should be. If you move to a round-robin model where work is assigned evenly, then there’s no incentive for provers to optimize their setup. Either way, you end up with an inefficient market.
That’s why we built our own auction mechanism, which we formally proved in a research paper we submitted to Financial Cryptography this year. It optimizes for fair pricing, collusion resistance, and computational efficiency.
Alice: I like that approach. It sounds like specialization is a big part of Lagrange’s network design?
Ismael: Exactly. Our network allows provers to specialize based on their hardware and proof type. That’s a key difference. Most existing proving networks try to force every proof request through a generic marketplace, which leads to inefficiencies. We let different types of proofs run in separate sub-networks with different economic structures.
Alice: Let’s switch gears to the co-processor side. What’s the core value proposition of a ZK co-processor?
Ismael: The key idea is that it allows you to separate execution from state. Rollups today separate both execution and state from Ethereum, which creates fragmentation. A co-processor, on the other hand, lets a contract run expensive computations off-chain while keeping state on-chain.
We designed ours around SQL because it’s a language developers already know. Instead of writing ZK circuits, they can just write SQL queries. Under the hood, we use a technique called ZK MapReduce, which lets us structure computations efficiently over blockchain data.
Alice: What are some applications you’re most excited about for co-processors?
Ismael: There’s a hidden need for verifiable computation in almost every DeFi app. A great example is Ethena. They have an on-chain credit card and need to compute cash-back rewards for users. Doing that entirely on-chain is infeasible, but with a co-processor, it becomes possible.
Another example is Azuki. They’re building immersive digital experiences for NFT collectors, and ZK allows them to create unique mechanics that wouldn’t be possible otherwise.
Alice: And how do you see the space evolving over the next few years?
Ismael: I believe every application will eventually use ZK—whether for data, bridging, execution, or privacy. For that to happen, we need cheaper proofs, better developer tooling, and decentralized proving infrastructure. That’s exactly what we’re building at Lagrange.
Alice: I love how everything ties back to that broader vision. Any final announcements or advice for the audience?
Ismael: I’d challenge builders to think about what they would create if on-chain computation had no limits. What would you build if you could trustlessly access off-chain data, do complex computation, and interact seamlessly across chains? That’s the future we’re moving towards.
And if you want to follow what we’re working on, keep an eye on Lagrange’s Twitter - we have some big announcements coming soon.
Alice: Great note to end on. Thanks so much for the conversation, Ismael. I really enjoyed this one.
Ismael: Likewise. Thanks for having me.
Stay up-to-date with @Ismael_H_R and @lagrangedev on X.
