From Cornell Lab to Crypto Protocol: Dr. Leo Fan on Building Cysic’s ZK Engine

With zero-knowledge proofs rapidly reshaping the frontier of blockchain and privacy, the journey from academic theory to real-world protocol is fraught with challenges. This article dives into the story of Dr. Leo Fan — a scholar who moved from the halls of a leading lab at Cornell to co-building the ZK (zero-knowledge) engine at Cysic. Along the way, we unpack how rigorous research merges with engineering ambition, and what it takes to turn complex cryptographic ideas into a live protocol.

As we explore Dr. Fan’s transition, technical insights, and vision for the future, readers will gain a nuanced view of how ZK engines are created — and why they matter for the next wave of decentralized systems.

Q1. You made a big shift from academia (Cornell → Rutgers) into founding Cysic. What was the moment or problem that convinced you to leave research/teaching and build a company around ZK hardware and infrastructure?

• During my time in academia and in industry research roles, it became clear that zero-knowledge systems suffered from a fundamental bottleneck: they were mathematically elegant, but far too slow and inefficient for real-world adoption. At Algorand, I saw firsthand that ZK systems lacked the hardware and infrastructure to scale beyond prototypes. That gap, rather than any single moment, convinced me to leave Rutgers and build Cysic in 2022 as a dedicated effort to make verifiable computation practical.

Q2. How did your academic research and early industry roles (Algorand, IBM/Bell Labs, etc.) shape the technical vision for Cysic, especially the decision to combine custom hardware (ASIC/CUDA) with a decentralized prover network?

• My academic work at Cornell, under Professor Elaine Shi, the renowned computer scientist and cryptographer, provided me with a solid foundation in cryptography and verifiable computation. Industry roles at Algorand and IBM/Bell Labs exposed me to the practical constraints: most ZK systems were compute-bound, and general-purpose hardware was not built for the workloads that proofs require. That combination—rigorous theory plus real-world bottlenecks—shaped Cysic’s decision to pair custom hardware (ASIC/CUDA acceleration) with a decentralised prover network. It was the only way to make proofs reliably fast, affordable, and scalable.

Q3. Cysic describes itself as “silicon to protocol.” Can you walk us through the stack, from hardware design to proof generation to settlement, and which layers you’ve prioritized while scaling?

“Silicon to protocol” means we optimise every layer of the proving lifecycle:

1. Hardware layer: custom-designed accelerators for ZK workloads, optimised for speed and cost.
   
2. Prover layer: decentralised networks of GPUs and ASICs running our ComputeFi model.
   
3. Protocol layer: settlement, verification, and integration with proof markets and L2 ecosystems.
   

In the early stages, we prioritised the hardware and prover layers because they are the foundation for scalability. ComputeFi—our mechanism for putting hardware on-chain—became a breakthrough moment, enabling verifiable, decentralised compute at scale.

Q4. Designing accelerator hardware for ZK proofs is unusually hard. What were the biggest engineering surprises or trade-offs you encountered when trying to optimize for throughput, latency, cost, and generality across proof systems?

• Optimising for throughput, latency, cost and generality simultaneously is inherently difficult. Our biggest breakthrough was ComputeFi, which allowed us to map hardware resources directly on-chain. That design choice resolved many of the trade-offs between flexibility and performance and formed the basis of our long-term vision for decentralised, verifiable compute.

Q5. Cysic is positioning itself as a ZK DePIN of sorts (computing resource marketplace). How do you think decentralizing ZK compute changes the economics and UX of ZK rollups and L2s?

• Today’s DePIN market relies heavily on hardware from large GPU manufacturers like Nvidia. In fact, Nvidia GPUs run about 80% of the DePIN infrastructure we see today. This leads to a monopolisation where the market is heavily influenced by Nvidia’s prices, decisions, and upgradability. Smaller developers are also negatively impacted by today’s high GPU costs because they can’t afford the economies of scale enjoyed by more well-funded developers.
• Decentralising computing power is the solution, as users no longer have to buy and own expensive hardware; instead, they can have access to on-demand high-performance computing power. This allows smaller developers with less funding to avoid buying and maintaining expensive physical hardware and only purchase access whenever they need it for operations like benchmarking or testing.

Q6. Product-market fit often forces pivots. How has Cysic’s product roadmap and go-to-market changed from the earliest prototype to your current testnet phases, and what user/partner feedback drove those changes?

• Our roadmap follows a deliberate, sequential expansion. The proof market is our foundational layer. From there, we are extending into the broader compute market through AI verification, inference, and ZK machine learning. The evolution has been driven by partner and customer feedback requesting a unified infrastructure for both AI and ZK workloads. As a result, we now provide servers and services that support this wider class of compute tasks.

Q7. Community and operator economics are critical for DePINs. How have you designed incentives, tooling, and onboarding so that a diversity of hardware providers (from hobbyist GPUs to ASICs) can participate sustainably?

• Mechanisms to ensure long-term sustainability include slashing: if provers or validators cannot respond in time, their $CYS tokens will be seized and distributed to others. This ensures validators are on top of tasks, which prevents long delays.
• For miners, we apply a maintenance fee on BTC that is burned over time. These mechanisms ensure liveness, discourage poor performance, and reward long-term, reliable participation across the hardware spectrum.

Q8. Can you share lessons from scaling the Cysic ecosystem, partnerships, integrations, developer tooling, or incubator/validator relationships that materially accelerated adoption?

• The most important lesson is adaptability. The crypto landscape changes constantly, and rigid roadmaps rarely survive contact with market reality. While community building and strong ecosystem partnerships have been essential, adaptability has been the deciding factor—being able to refine tooling, integrations, and partnerships quickly has allowed us to meet developers and networks where their needs emerge.

Q9. On the governance and token side (if you can speak to it): what governance model and economic levers do you see as essential to balance decentralization, security, and long-term protocol funding?

• The core economic levers we rely on are slashing, dynamic rewards for provers and validators, and fee burn mechanisms tied to maintenance costs. These align incentives across the network, ensuring that security and liveness are preserved while creating a sustainable long-term funding cycle for the protocol.

Q10. Security and trust are core to ZK infrastructure. How do you approach risk management, e.g., hardware bugs, malicious provers, or supply-chain attacks, and what layers of defense do you prioritize?

• Our approach focuses on layered defence: hardware-level validation, prover-level correctness guarantees through slashing, and protocol-level checks for liveness and behaviour. By combining decentralised prover redundancy with economic penalties for misbehaviour, we reduce single-point-of-failure risks and ensure that malicious activity is either prevented or economically disincentivised.

Q11. Looking back at your transition from professor to CEO, what soft skills or unexpected management challenges have been hardest to learn, and what advice would you give other academics thinking of founding a deep-tech startup?

• Being a professor and being a startup founder are two completely different roles.
  As a professor, I had to be precise, conservative in my claims, and overprepared; every piece of work had to be polished before it could be published.
• In a startup, it’s almost the opposite. I had to learn to focus on the macro vision and operate from a high-level perspective. Instead of waiting for perfect results, I had to show progress step-by-step and be confident about every improvement. This mindset directly contradicts academic training, where you’re expected to avoid making pre-emptive claims until everything is proven.
• My main advice to academics considering a deep-tech startup is not to focus solely on the technology. 99% of startups cannot win on tech alone. You need PR, marketing, partnerships, and a community. As a founder, you must manage all of these and stay focused on the bigger picture.

Q12. Five years from now, what does success look like for Cysic, technically, for the ecosystem, and for the broader ZK landscape? And what are the major technical or market risks you’re watching now?

• Success means becoming the go-to solution for scalable, cost-effective hardware acceleration for the entire ZK and verifiable compute ecosystem. Our long-term goal is to serve as the infrastructure backbone for innovation across both AI and crypto. The major risks today are market volatility and the rapid pace of technological change, which reinforces the need to remain adaptive while building towards that broader vision.