Building Thru: An Ex-Firedancer Engineer's Vision for Reimagining Blockchain Architecture

The world of blockchain infrastructure is witnessing a fascinating moment of innovation as engineers who cut their teeth building the most performant systems begin charting their own courses. Liam Heeger, a former core engineer at Firedancer—Jump Trading's high-performance Solana client—has emerged from the shadows of one of crypto's most ambitious technical undertakings to build something entirely new. His company, Untoo Labs, is developing Thru, a layer-one blockchain that challenges fundamental assumptions about how decentralized networks should operate.

Top Projects

Lulo

Score: 7,586.13

Bonk

Score: 4,806.12

Sphere

Score: 2,544.42

Moonwalk

Score: 2,026.11

In a wide-ranging conversation on the Lightspeed podcast, Heeger outlined his vision for a blockchain without leaders, where anyone can propose blocks, validators compete on performance rather than capital accumulation, and the rigid constraints of fixed block times give way to the natural rhythms of market activity. The discussion touched on everything from the challenges of building Firedancer against Solana's moving target to whether Solana itself has become "too decentralized," offering rare insights into the thinking of engineers operating at the cutting edge of blockchain technology.

The Firedancer Experience: Building Against a Moving Target

Firedancer represents one of the most ambitious undertakings in blockchain infrastructure—building a completely new client for Solana from scratch in C, designed for maximum performance. Heeger's perspective on this effort reveals both the technical challenges and the organizational dynamics that shape such projects.

"It's really hard to build against someone else's specification," Heeger explained, capturing the essence of the Firedancer challenge. The team had to maintain a constant awareness of developments in other codebases while simultaneously pushing forward with their own implementation. Features like vote equivocation and Alpine Glow had been discussed in the community for over a year, meaning the Firedancer team often found themselves implementing solutions for problems that weren't yet fully specified.

The reality of building a second client for an evolving blockchain creates a peculiar engineering challenge. Teams must anticipate future changes while remaining compatible with current implementations. "You end up having to kind of try to get a little bit ahead on it without really having the full thing in front of you," Heeger noted. This dynamic creates both opportunities for innovation and constraints that can slow development.

Is Solana Too Decentralized? The Client Diversity Debate

One of the more provocative questions raised in the conversation was whether Solana has become "too decentralized"—a statement that would surely raise eyebrows among Ethereum advocates who have long criticized Solana's validator economics. Heeger offered a nuanced technical perspective that separates the soft benefits from the hard tradeoffs.

On the soft side, multiple client implementations create healthy competition that improves overall quality. "Because of Firedancer, Agave and the other smaller clients have significantly better testing than they would have had two years ago," Heeger observed. The competitive pressure drives improvements across the ecosystem that might not otherwise occur.

However, the technical reality of Solana's consensus mechanism creates genuine risks around client diversity. Unlike Ethereum, where disagreements between clients can be resolved while the chain continues operating, Solana's consensus algorithm faces potential halts when clients disagree about chain state. "If two clients disagree and there's like 40% stake on one client and 60% on the other, then if they disagree about what the state of the chain is because they have slightly different implementations, then the chain has to actually halt," Heeger explained.

This dynamic suggests that client diversity, while valuable for testing and competition, carries different implications on Solana than on other networks. Heeger characterized some of the discourse around client diversity as having "a bit of theater" to it, while maintaining that the testing improvements and competitive pressure remain genuinely valuable contributions.

Introducing Thru: A Leaderless Blockchain Architecture

The Thru virtual machine represents a departure from both Solana's architecture and the broader landscape of smart contract platforms. At its foundation, Thru utilizes RISC-V, an open-source instruction set architecture that has gained significant traction in the hardware world and now serves as the basis for Thru's computational model.

The choice of RISC-V reflects a strategic focus on developer accessibility rather than raw performance optimization. "The most important thing for us is that it is supported by a whole bunch of tools, compilers, programming languages—C, C++, Rust, some ancient ones like Fortran, Cobol, some newer ones like Zig and Nim and others," Heeger explained. While any team can optimize their VM for performance, expanding the developer pool presents a more fundamental challenge that RISC-V helps address.

Interestingly, Heeger noted that Ethereum has also explored RISC-V, though for different purposes. The Ethereum approach would help with ZK proving efficiency but wouldn't address performance concerns—a distinction that highlights how the same technology can serve vastly different architectural goals.

The Problem with Single-Leader Consensus

Heeger's critique of existing blockchain architectures centers on what he sees as a fundamental misalignment: the monopolistic control that leaders exert over block space. On Solana, a leader maintains monopoly control over block space for 1.6 seconds per slot. On Ethereum, that monopoly extends to 12 seconds. In either case, a single entity controls the supply of block space during their tenure.

"That's obviously not great," Heeger stated bluntly. The search for alternatives led the Untoo team to examine Multiple Concurrent Leaders (MCL), an approach that Solana has been exploring with advocacy from researchers like Max Resnick. However, Heeger found this solution insufficient: "You haven't really gotten rid of the monopoly problem. You've still just turned it into oligol[y]."

The deeper issue with MCL, in Heeger's view, is the impossibility of finding a fair ordering rule when multiple leaders produce blocks simultaneously. "That rule is not going to ever, I think, ever be fair," he concluded, though he acknowledged Resnick as "a really smart guy" with serious work on the problem.

This analysis led to what Heeger described as a "principle first decision": eliminate leaders entirely. Thru operates as a completely leaderless network where anyone with a small amount of tokens can become a block producer, while a separate validator set handles consensus.

How Block Production Works Without Leaders

The separation of block production from validation represents one of Thru's most distinctive architectural choices. Block producers can be essentially anyone—from professional block builders like Temporal to individual applications running their own sequencing operations.

Professional block producers would aggregate order flow and provide sophisticated block proposal services, maximizing their own revenue while potentially reducing costs for users. But the more interesting case involves applications becoming their own block producers. "An application would actually be a sequencer themselves," Heeger explained. "A dex coming in, they capture all of their flows and they can actually build blocks for their users and actually build the best possible blocks."

This architecture enables applications to eliminate sandwich attacks by controlling their own transaction ordering, capture value that would otherwise flow to external MEV extractors, and even subsidize user fees entirely. An application could pay the block producer fees on behalf of users, enabling genuinely zero-fee transactions from the user's perspective.

The mechanics involve block producers posting a price with their proposed block, essentially bidding for inclusion. Validators then vote on blocks based on a combination of the offered price and the computational resources required to execute the block. This creates a dynamic market for block space rather than the fixed allocation of current systems.

Validator Incentives: Aligning Profit with Performance

Heeger identified a fundamental problem with proof-of-stake systems: they incentivize capital accumulation rather than network performance. "If they're accumulating capital, they're not as focused on the performance of the network and the success of the network," he argued.

Thru's validator economics attempt to realign these incentives. When validators vote on blocks from producers, they earn a portion of the fees posted by the block producer. But crucially, validators can then convert their earnings into additional voting power on the network. This creates a direct relationship between profitable operation and influence over the network.

"If they're all competing, then they will all also be focused on performance, on the performance of the network, on serving users in the best way possible, and serving block producers also in the best way possible," Heeger explained. The mechanism creates competition not just for stake but for the ability to efficiently process blocks and capture fees.

Validators that fail to remain competitive—perhaps by not voting quickly enough on profitable blocks—will make less money and accumulate less voting power relative to their peers. This creates ongoing pressure to maintain performance rather than simply accumulate tokens and coast on staking returns.

Spam: A Fake Problem or Real Concern?

One of the more contrarian positions Heeger took concerned spam prevention. "Solana says that the token exists to prevent spam," he noted. "And I don't really, I don't believe that."

His argument rests on the observation that computers can trivially filter low-value transactions. The price check happens almost instantly—if a transaction doesn't offer sufficient fees, it gets rejected immediately. Services like Double Zero can perform this filtering before transactions even reach validators. "Spam is like a solved problem," Heeger argued. "Look at the transaction, if it's valuable, you take it, if it's not valuable, you don't."

But Solana clearly does experience spam in the form of high transaction failure rates, often attributed to bots attempting to improve their landing rates through repeated submissions. Heeger acknowledged this reality but reframed the issue: from the network's perspective, these transactions are still paying fees, making them "perfectly fine transactions" that simply don't accomplish anything useful.

The real problem, he suggested, drawing on insights from Ben at Temporal, is the unpredictability of transaction placement within blocks. "They're spamming because the jitter, where they get in the block, is not easy to determine," Heeger explained. Reducing this jitter—providing more predictability about transaction ordering—could eliminate much of the incentive for spam without requiring protocol-level changes to fee mechanisms.

Variable Block Times: Matching Supply to Demand

One of Thru's more novel features is the abandonment of fixed block times. While Solana operates on 400-millisecond slots and Ethereum uses 12-second blocks, Thru will have variable block production that responds to actual transaction demand.

The motivation comes from observing how traditional markets operate. "NASDAQ and New York Stock Exchange and all of these big exchanges—they don't move at a fixed time," Heeger noted. "Events come in bursts. There's a lot of activity in one moment and then kind of a bit of quiet quiescence."

This pattern characterizes virtually all economic activity. Payroll processing happens at specific times. Market events cluster around news releases and trading sessions. Bulk purchases happen in concentrated bursts rather than steady streams. "When Costco needs a bunch of corn, they're going to buy it in one burst," Heeger illustrated.

Fixed block times create a mismatch between supply and demand for block space. During quiet periods, blocks might be nearly empty. During bursts of activity, block space becomes scarce and contested. Thru's variable timing allows the network to "take in a bunch of blocks all at once and then kind of have a moment of quiet," better matching the natural rhythm of economic activity.

Block Producer Economics and Market Dynamics

The block producer role on Thru creates interesting market dynamics that don't exist in leader-based systems. Because anyone can produce blocks, there's genuine competition for block space that should drive efficiency improvements over time.

Block producers can set deadlines for their blocks, creating urgency around inclusion. A block producer might say, "I need either include this now or don't take it at all." Combined with pricing, this creates a push-pull dynamic between block producers seeking inclusion and validators evaluating their options.

At any given moment, validators face continuous decisions about which blocks to include. "Do I want to include this block or this block?" becomes an ongoing optimization problem rather than a passive acceptance of whatever the current leader produces.

Heeger drew on the analogy of hedge fund traders to describe how smaller block producers might find profitable niches. "That guy that went on vacation for five years, they still have some capital. They think they see a really good trade in the Mongolian team market. So they go set up shop, a small shop of three guys from high school in Mongolia." Small block producers could similarly identify market opportunities and attack them profitably, even competing against larger, more sophisticated operations.

Application-Level Block Production and Fee Structures

The ability for applications to serve as their own block producers creates possibilities for novel fee structures. An application like a hypothetical "Thru Swap" could collect trading fees in their own token while paying for block space in the network's native token.

This addresses a concern about value accrual that has plagued discussions of layer-two networks on Ethereum. When applications can capture all value in their own tokens without paying for base layer resources, value fails to flow to the underlying chain. But on Thru, even applications operating as block producers must pay for actual execution on the L1.

"They still have to actually pay for the block space. And it's not just data availability. This is actual execution," Heeger emphasized. The architecture avoids the "L2 conundrum" that has complicated Ethereum's value proposition while still enabling applications to optimize their own user economics.

The Most Slept-On Improvement: Read Layer and Observability

Asked about the lowest-hanging fruit for blockchain performance improvements, Heeger's answer surprised: the read layer and observability infrastructure.

"A lot of things that I push with our team is don't just do something without measuring, don't do optimization without having the data," Heeger explained. Fifteen years into the blockchain industry, the tools for understanding what's actually happening on-chain remain remarkably primitive.

"Explorers are still inscrutable to this day," he observed. Application developers often can't easily observe the market dynamics their applications participate in. High-performance read systems that can serve thousands of users pulling significant data simultaneously remain technically challenging.

This perspective aligns with best practices in traditional software engineering—optimization without measurement is guesswork. But the distributed, adversarial nature of blockchain environments makes instrumentation particularly difficult. Heeger praised Alessandro's work at ANSA on low-level profiling as an example of the measurement-first approach needed across the industry.

The 10x Performance Question

The conventional wisdom in crypto infrastructure holds that incremental improvements don't matter—you need 10x gains to justify new systems. Kyle Samani of Multicoin Capital has articulated this view prominently, and it clearly influenced Untoo's thinking.

When asked directly whether Thru would deliver 10x performance improvements over Solana, Heeger was careful in his response. "The most important thing for us right now is to align the incentives, get the protocol in a state where we can be that," he said.

The architectural changes—eliminating single-leader monopolies, enabling multiple concurrent block producers, removing fixed block times—represent fundamental shifts that could enable significant performance improvements. "Imagine if you didn't just have one block producer at a time," Heeger suggested. "Maybe you could get a lot more done."

At the same time, he acknowledged that launch-day performance will depend heavily on achieving meaningful usage. "What really matters is getting used on the chain, getting amazing applications on the chain." Infrastructure improvements from projects like Double Zero will also contribute to performance gains across the ecosystem.

Building an L1 in 2025: The Business Challenge

Launching a new layer-one blockchain has become substantially harder than it was during previous market cycles. The competitive landscape is more crowded, developers have established preferences, and ecosystems have formed around existing platforms. Heeger acknowledged this reality directly: "It's not as easy to just go build an L1."

Untoo's approach emphasizes being present with early partners. "Being in person as an ecosystem participant is really important because it means that we can work together and quickly iterate on the underlying things that you need," Heeger explained. When core products are being developed alongside the protocol, missing features in the VM or runtime can be addressed rapidly.

The team is bringing in entrepreneurs-in-residence with product experience and working with market experts to develop DeFi primitives specifically enabled by Thru's architecture. With only five people total covering engineering and business development, the team maintains an intense focus on shipping rather than perfecting.

Regulatory Clarity as Tailwind

Surprisingly for a conversation centered on technical architecture, regulatory developments featured prominently in Heeger's outlook. The GENIUS Act and clarity around crypto regulation have provided what Heeger described as a "clear path forward for success."

"I'm really bullish on a lot of the new regulation. I think it's the right direction for the industry," he said. Rather than making things easier, the regulatory developments provide clarity that helps founders "sleep easier at night about how we think about what we're doing and the value of it."

This represents a notable shift from the regulatory ambiguity that characterized previous years. For teams building fundamental infrastructure that will underpin financial applications, clear rules—even strict ones—are often preferable to uncertainty about what's permissible.

Token Plans an Launch Timeline

Thru will have a native token, though Heeger declined to provide details beyond confirming its existence. "Not much to say there just yet. I think it's a little early," he noted, while expressing confidence that regulatory clarity would provide a framework for thinking through token design.

On timeline, Heeger targeted July 2026 for a mainnet launch, while emphasizing continuous shipping rather than big-bang releases. The team has already launched a test network called "Breakthrough" that could function as an L2 sequencer today.

"We're going to continuously ship things," Heeger explained. "You're going to see more from us. We've got the SDKs going into private alpha soon." The approach reflects a philosophy that getting real products into the world quickly matters more than waiting for everything to be perfect.

The Approach to Developer Experience

Untoo's strategy acknowledges that developer acquisition is as important as technical performance. The RISC-V choice exemplifies this thinking—by supporting existing toolchains and programming languages, Thru avoids requiring developers to learn entirely new technologies.

"We can make the VM performant. Everybody can make their little VM performant," Heeger acknowledged. "But expanding the developer pool is incredibly hard." By meeting developers where they are—with familiar languages like C, C++, Rust, and emerging options like Zig—Thru aims to lower barriers to entry that have historically limited blockchain adoption.

The team plans to build "dumb" reference implementations of core infrastructure like wallets to demonstrate possibilities and guide external teams. Rather than trying to capture everything in-house, the approach focuses on enabling an ecosystem of businesses to emerge around the network.

Implications for Solana and the Broader Ecosystem

Thru's development raises interesting questions about Solana's evolution and the broader competitive landscape. Heeger's critique isn't that Solana performs poorly—it's that architectural constraints around single-leader consensus create fundamental limitations that incremental improvements can't address.

At the same time, many of the problems Heeger identifies are actively being worked on within the Solana ecosystem. Multiple concurrent leaders, improved scheduling, and better fee mechanisms are all under discussion or development. The question is whether these improvements can match the performance potential of architectures designed from scratch with different constraints.

Solana's established ecosystem, developer familiarity, and operational track record represent significant advantages that new chains must overcome. But the history of technology suggests that fundamental architectural improvements eventually win out over incremental optimization of legacy systems.

The Role of Infrastructure Providers

Heeger's acknowledgment of Double Zero's role in potential performance improvements highlights how infrastructure providers outside of core protocol development contribute to blockchain performance. Networking layers, geographic distribution, and hardware optimization all matter alongside protocol design.

This suggests a future where blockchain performance depends on ecosystems of specialized providers rather than monolithic protocol implementations. Block producers, validators, network providers, and read-layer specialists might each optimize their piece of the stack, with competition driving improvements across the board.

Measuring Success in Blockchain Development

The conversation surfaced an interesting tension around how to evaluate blockchain development. Traditional metrics like transactions per second or time to finality tell part of the story, but Heeger's emphasis on observability and measurement suggests richer evaluation criteria.

Understanding how transactions flow through the network, where bottlenecks emerge under load, and how different components interact under various conditions requires instrumentation that most blockchains lack. Building this observability infrastructure may be as important as optimizing the underlying systems being observed.

Looking Forward: The Evolution of Blockchain Architecture

Thru represents one data point in an ongoing evolution of blockchain architecture. The leaderless consensus model, separation of block production and validation, variable block times, and RISC-V VM all represent specific choices that will be tested against alternatives in the market.

Whether these choices prove superior to alternatives like Solana's integrated approach or Ethereum's proposer-builder separation remains to be seen. But the willingness of experienced engineers to challenge established assumptions suggests a healthy competitive dynamic that should benefit the broader ecosystem.

The blockchain industry has seen multiple waves of architectural innovation, from Bitcoin's proof-of-work to Ethereum's smart contracts to Solana's proof-of-history. Each generation challenged assumptions of its predecessors while introducing its own limitations. Thru's leaderless approach may represent the next evolutionary step—or it may reveal unforeseen challenges that validate current designs.

Conclusion: The Case for Architectural Experimentation

Liam Heeger's journey from Firedancer to Thru illustrates both the depth of knowledge accumulated in building high-performance blockchain systems and the frustrations that drive talented engineers to start fresh. The technical critiques he raises about single-leader consensus and fixed block times reflect genuine limitations that affect user experience and market efficiency.

Whether Thru's answers—leaderless consensus, separated block production, variable timing—prove superior to alternatives will depend on execution and market adoption. But the willingness to question fundamental assumptions and propose novel solutions keeps the blockchain industry moving forward.

For Solana and its ecosystem, Thru represents both competition and validation. Competition in the sense that talented engineers see opportunities to improve on Solana's approach. Validation in the sense that the problems being addressed are real and the standards for performance are being set by Solana's example.

The ultimate beneficiaries of this competition are users and developers who gain access to faster, more efficient blockchain infrastructure. Whether that infrastructure runs on Solana, Thru, or systems yet to be imagined, the push for better performance and aligned incentives drives the entire industry forward.

Facts + Figures

• Firedancer Development Challenge: Building a second client for Solana requires engineering against a "moving target" specification, with teams needing to anticipate future changes while maintaining current compatibility—features like vote equivocation and Alpine Glow were discussed in the community for over a year before full implementation

• Client Diversity Risk on Solana: Unlike Ethereum, Solana's consensus algorithm can force the chain to halt if clients with significant stake disagree about chain state—a 40/60 stake split between disagreeing clients would cause a halt rather than allowing the chain to continue

• Thru VM Architecture: Built on RISC-V, an open-source instruction set architecture that supports C, C++, Rust, Fortran, Cobol, Zig, Nim, and other programming languages through existing toolchains

• Leaderless Consensus: Thru eliminates block production monopolies entirely—on Solana, leaders control block space for 1.6 seconds; on Ethereum, for 12 seconds

• Block Producer Economics: Anyone with a small amount of tokens can become a block producer, and applications can serve as their own sequencers to capture order flow and eliminate sandwich attacks

• Variable Block Times: Unlike Solana's fixed 400ms slots or Ethereum's 12-second blocks, Thru will have variable block production that responds to actual transaction demand

• Zero-Fee Transaction Model: Applications serving as block producers can subsidize user fees entirely, paying block producer costs while collecting fees in their own tokens

• Validator Incentive Mechanism: Validators can convert earnings from block inclusion into additional voting power, creating direct alignment between profitable operation and network influence

• Team Size: Untoo Labs operates with approximately five total people covering engineering and business development

• Target Launch Date: July 2026 for mainnet, with continuous SDK releases and alpha programs leading up to launch

• Test Network Status: "Breakthrough" test network already operational, could function as an L2 sequencer in its current state

• Regulatory Outlook: Heeger expressed strong optimism about the GENIUS Act and broader regulatory clarity, describing it as providing a "clear path forward for success"

• Spam Prevention Philosophy: Heeger argues spam is a "solved problem" at the technical level—computers can trivially filter low-value transactions before they reach validators

• Root Cause of Transaction Failures: High jitter in transaction placement within blocks drives repeated submission attempts, not fundamental spam economics

• Most Underrated Improvement: Read layer and observability infrastructure, which Heeger described as "the frontier" for blockchain development fifteen years into the industry

• EIR Program: Untoo is bringing in entrepreneurs-in-residence with product experience and market expertise to develop DeFi primitives specifically enabled by Thru's architecture

Questions Answered

What is the relationship between Firedancer and Thru?

Thru's founder Liam Heeger was a core engineer at Firedancer, Jump Trading's high-performance Solana client, before departing to start Untoo Labs. His experience building Firedancer against Solana's evolving specification informed his views on blockchain architecture and ultimately led him to design a new system from scratch. The technical challenges of maintaining client compatibility while pursuing performance optimization at Firedancer highlighted architectural constraints that Heeger sought to address with Thru's leaderless design. Jump initially sued Heeger over non-compete violations, but the parties eventually settled and Untoo raised funding from Symmetric Capital.

Why does Thru use RISC-V instead of creating a custom virtual machine?

Thru uses RISC-V primarily to expand the potential developer pool rather than for raw performance gains. RISC-V is an open-source instruction set architecture supported by existing compilers and toolchains for C, C++, Rust, Fortran, Cobol, Zig, Nim, and other programming languages. While any team can optimize their VM for performance, lowering barriers for developers to build on a new platform is significantly harder. By supporting familiar tools and languages, Thru avoids requiring developers to learn entirely new technologies, potentially accelerating ecosystem growth compared to platforms with proprietary virtual machines.

How does block production work without leaders?

On Thru, block production is completely separated from validation, and anyone with a small amount of tokens can propose blocks. Block producers post a price with their proposed block, essentially bidding for inclusion by validators. This creates a market for block space rather than the monopolistic allocation in leader-based systems. Professional block builders can aggregate order flow, while applications can become their own block producers to capture value that would otherwise flow to MEV extractors. Validators evaluate blocks based on offered prices and computational requirements, continuously deciding which blocks to include.

Can applications really offer zero-fee transactions?

Yes, through the block producer mechanism. When an application serves as its own block producer, it can collect fees from users in its own token while paying for block space in the network's native token. This means applications could fully subsidize the blockchain fees for their users, creating genuinely zero-fee experiences from the user's perspective. Unlike the L2 value accrual problem on Ethereum, applications still must pay for actual execution on the L1, ensuring value flows to the network while enabling novel user-facing fee structures.

How does Thru address the spam problem that affects Solana?

Heeger argues that spam is technically a "solved problem"—computers can trivially filter low-value transactions by checking prices before processing. The real issue on Solana is high jitter in transaction placement within blocks, which forces bots to submit many transactions to improve their chances of landing in the right position. From the network's perspective, these transactions still pay fees, making them legitimate if unproductive. Thru's architecture, with its competitive block producer market and variable block times, should provide more predictability about transaction ordering, reducing the incentive for spray-and-pray transaction strategies.

Why doesn't Thru use fixed block times like Solana or Ethereum?

Thru abandons fixed block times because real economic activity happens in bursts rather than steady streams. Traditional markets like NASDAQ and the NYSE don't operate on fixed intervals—activity clusters around events, announcements, and specific times like payroll processing. Fixed block times create mismatches between supply and demand for block space, with blocks potentially empty during quiet periods and overwhelmed during high activity. Variable timing allows Thru to process many blocks during demand spikes and remain quiet during lulls, better matching the natural rhythm of economic activity.

What does Heeger think is the most important improvement for blockchain performance?

Surprisingly, Heeger identifies the read layer and observability infrastructure as the most underrated area for improvement. After fifteen years of blockchain development, tools for understanding what's actually happening on-chain remain remarkably primitive. Block explorers are "inscrutable," application developers struggle to observe market dynamics, and high-performance read systems that serve many users simultaneously remain technically challenging. Without proper measurement and observability, optimization becomes guesswork—a violation of fundamental software engineering principles that affects the entire industry.

When will Thru launch and what is the development approach?

Heeger targets July 2026 for mainnet launch but emphasizes continuous shipping over big-bang releases. The team already operates a test network called "Breakthrough" and is moving SDKs into private alpha. Rather than waiting for all components to be perfect, Untoo plans to announce developments like wallet releases and third-party integrations as they happen. This approach reflects a philosophy that getting real products into the world quickly and iterating based on actual usage matters more than extensive internal development before any public exposure.

How does Thru's validator economics differ from Solana's?

Thru attempts to align validator incentives with network performance rather than capital accumulation. Validators earn fees from block producers when they vote on blocks, and they can convert these earnings into additional voting power. This creates direct competition based on performance—validators that process blocks quickly and efficiently make more money and accumulate more influence, while less competitive validators fall behind. In contrast, traditional proof-of-stake systems reward capital accumulation, potentially disconnecting validators from active focus on network performance.