From Airbnb Engineer to Blockchain Founder — Neel Somani’s Path to Building Eclipse

Most startup advice boils down to “move fast and ship something.” Neel Somani did the opposite. He spent his first year at Eclipse buried in research, testing assumptions, and figuring out which problems actually mattered before writing a line of production code. That approach helped him raise venture funding to build blockchain infrastructure that challenges how the industry thinks about performance and security tradeoffs.

In this interview, Neel talks about his path from software engineering at Airbnb and quantitative research at Citadel to founding Eclipse. He shares what he learned along the way about resisting popular narratives, building with a small technical team, and knowing when the smartest move is to stop building and start rethinking. If you’re a founder working on deep technology or trying to figure out when patience beats speed, there’s a lot here worth sitting with.

How much revenue and profit does the business generate?

~$65M venture-funded 

Tell us about yourself and your business.

I’m a founder with a background that spans quantitative finance, systems engineering, and research-oriented computer science. 

I studied computer science, mathematics, and business at UC Berkeley. Early in my career, I worked as a software engineer at Airbnb before moving into quantitative research at Citadel. That combination shaped how I think. I’m very economics-driven, but I also care deeply about systems, correctness, and long-term structure rather than short-term optimization.

I founded Eclipse to address a very specific problem in blockchain infrastructure: performance without sacrificing security. Ethereum was clearly becoming the dominant settlement layer, but its execution environment was never designed for high throughput. Eclipse was built as a Layer 2 that rethinks execution entirely by using the Solana Virtual Machine while still deriving security from Ethereum. The goal was to support applications that simply were not viable on existing L2s.

Today, while Eclipse remains an important part of my story as a founder, most of my focus is on research and writing around AI systems, mechanistic interpretability, formal methods, and economic structure in a world shaped by AI. I spend most of my time developing ideas, publishing essays, and working on technically deep projects involving math, machine learning, and incentives.

How does your business make money?

Eclipse was built as infrastructure, which means monetization was never the first thing to optimize. The long-term model revolved around capturing value at the execution layer, where real economic activity happens, rather than at settlement or other thin layers that do not generate meaningful revenue.

More broadly, I tend to be skeptical of forcing early revenue models onto deep technology. In many cases, the right move is to prove that a system can exist, scale, and matter before worrying about extracting value from it. That philosophy still shapes how I think about building today.

What was your inspiration for starting the business?

The motivation came from a simple observation. Most Ethereum scaling solutions were low-throughput by design, and they accepted that limitation as inevitable. At the same time, other blockchains were proving that high-performance execution was possible, but only by sacrificing security or composability.

I wanted to see whether that tradeoff was real or just a product of how the problem was framed. Eclipse started as an attempt to redraw the boundaries and ask whether you could have a single high-performance execution environment without fragmenting state or security.

How and when did you launch the business?

Eclipse came together gradually rather than through a single launch moment. The early phase was dominated by research, architecture decisions, and understanding which constraints actually mattered. A lot of the work was invisible from the outside.

By the time we were more public, the direction was already set. The focus was execution, performance, and borrowing security rather than reinventing it. Everything else followed from those choices.

How is the business funded? 

Eclipse was venture-backed and raised a significant amount of capital from institutional investors. The funding reflected belief in the long-term technical thesis rather than short-term metrics.

I have always viewed capital as a tool to buy time and focus. In deep infrastructure, speed is often less important than correctness, and funding allowed the team to work on hard problems without forcing premature compromises.

What was your first year in business like?

The first year was extremely research-heavy. Most of my time was spent thinking, writing, and pressure-testing assumptions rather than building polished products. There were long stretches where progress looked abstract because the work was conceptual.

I worked constantly, but not in a structured way. My days were driven by whatever problem felt most fundamental at the time. Some weeks that meant deep dives into execution models, other weeks into economics or security assumptions.

Revenue was not a meaningful milestone in that first year. The real goal was clarity. Understanding what was possible, what was impossible, and which tradeoffs were real versus imagined.

What strategies did you use to grow the business?

The primary strategy was intellectual honesty. Instead of marketing narratives, I focused on articulating clear arguments about why certain approaches would or would not work. 

That attracted the right kind of attention from people who cared about fundamentals.

I also leaned heavily on writing. Explaining ideas in public forces precision, and it acts as a filter. People who resonate with the arguments tend to be aligned collaborators or early adopters.

What was the biggest challenge you had to overcome?

The hardest part was resisting premature consensus. In crypto especially, narratives solidify quickly, and once they do, it becomes difficult to challenge underlying assumptions.

Many of the problems we were working on looked simple on the surface but had hidden constraints. Recognizing when a clean problem statement was masking real complexity was an ongoing challenge.

What have been the most significant keys to your business’s success?

Being economics-driven has been critical. I try to ground arguments in incentives, market structure, and long-term equilibria rather than technical novelty alone.

Another key has been independence of thought. High-level strategic decisions are not group exercises. They require isolation, reflection, and a willingness to be wrong before you’re right.

Tell us about your team.

Eclipse was built by a relatively small, highly technical team. The emphasis was on depth of understanding rather than headcount.

In my current work, collaboration looks different. I work with students, researchers, and independent contributors on specific projects, often in a loose and exploratory structure rather than a traditional company hierarchy.

What is the most important lesson you’ve learned growing the business?

Progress and understanding are not the same thing. You can make visible progress without actually understanding the problem you’re working on.

The real breakthroughs come from reframing the question correctly. Once the framing is right, solutions often look obvious in hindsight.

What advice do you have for other entrepreneurs?

Be very careful about what problem you think you’re solving. Clean problem statements are often misleading.

Also, do not confuse activity with insight. Time, capital, and scale do not automatically produce understanding. Sometimes the right move is to slow down and rethink the premise entirely.

What are your future plans for the business?

My focus going forward in my career is on research and writing around AI, formal methods, and system reliability. I am especially interested in how we move from probabilistic assurances to provable guarantees in increasingly autonomous systems.

Rather than building for scale immediately, I’m more interested in identifying the end state and working backward. That has been the common thread across everything I have built so far, and it continues to guide what I work on next.