I still remember the first time I watched a blockchain debate turn personal. It was not about code or fees. It was about who the network actually serves. That feeling came rushing back when Solana co-founder Anatoly Yakovenko dropped a short but pointed statement that put five major applications ahead of validators, developers, market makers, and even core engineers. In a space that often celebrates the builders behind the scenes, his ranking felt like a quiet reset of priorities.
Why Yakovenko Put Apps First
Yakovenko did not mince words. He named Phantom, Pump.fun, Fomo, Jupiter, and Kamino as the products that should guide how Solana optimizes its network. His logic was simple yet sharp. Products that hold substantial assets under management and drive real retail trading volume deserve the most attention. Everything else, in his view, comes second.
That stance landed at a moment when conversations about network design often circle around technical elegance or validator economics. Yakovenko flipped the script. He argued that the people moving real money and the platforms they trust should shape the roadmap more than the teams writing the code or the operators securing the chain.
The Core of His Argument
According to the co-founder, two metrics matter most. Assets under management and retail volume sit at the top of the priority list. He did not publish exact numbers for each app, and he did not rank the five against one another. Still, the message was clear. When a product holds significant capital or processes high levels of everyday trading activity, the network should bend to protect its reliability.
Products with a ton of aum and a ton of retail volume are the two most important groups to optimize for. Phantom/pump/fomo/jup/kamino >>> validators or devs or market makers or core engineers.
I find this perspective refreshing. Too often the conversation stays locked inside the technical community. Yakovenko reminded everyone that the chain exists to serve users who actually move value. In my experience, networks that forget that point eventually lose relevance.
The Ethereum Context That Sparked the Comment
The remarks did not appear in isolation. They came as a response to criticism aimed at Ethereum protocol designers. Some observers argued that many people shaping Ethereum’s future do not use the network themselves in meaningful ways. The implication was that designers should feel the pain of their own product when things go wrong.
Yakovenko quoted that criticism and then offered a measured counterpoint. He noted that the Ethereum Foundation has done a decent job optimizing for Aave. The reason is practical. If a major lending protocol cannot get transactions included during congestion or an outage, the entire product breaks. Reliability for high-stakes applications becomes non-negotiable.
That observation carries weight. It shows that even across competing ecosystems, the same principle applies. When an application holds large amounts of user capital, the base layer must treat its needs as primary rather than secondary.
Who Exactly Made the List
The five applications Yakovenko highlighted cover different corners of the Solana ecosystem. Phantom remains one of the most widely used wallets. Pump.fun has become synonymous with rapid token launches and retail speculation. Fomo, Jupiter, and Kamino each play distinct roles in trading, aggregation, and yield strategies. Together they represent both the speculative energy and the more structured financial activity that define current Solana usage.
What struck me is the absence of any formal partnership announcement. Yakovenko did not grant these teams special governance rights. He did not promise preferential treatment in protocol upgrades. He simply stated that their operational needs should rank higher than those of validators or core developers when hard choices arise.
In a follow-up comment he broadened the idea. The most important user, he said, is the plumber—whether institutional or retail. The metaphor lands well. Plumbers keep systems running. They are the ones who notice when the pipes leak. In blockchain terms, they are the applications and the end users who rely on consistent performance every single day.
What This Means for Validators and Developers
Placing apps above validators and developers does not mean those groups become irrelevant. It does mean their incentives and workflows may need to adapt. Validators still secure the network. Developers still build the tools. Yet the ultimate measure of success, according to this view, is whether the largest applications can operate smoothly under pressure.
I have watched enough network upgrades to know that trade-offs are inevitable. Faster finality, lower fees, or more predictable inclusion can benefit everyone, but the path to those improvements sometimes creates short-term friction for infrastructure operators. Yakovenko’s ranking suggests that friction should be accepted if it protects the products that hold the most user capital.
- Validators remain essential for consensus and security
- Core engineers still design the protocol upgrades
- Market makers provide liquidity that apps depend on
- Yet the ranking places user-facing products first when priorities conflict
Perhaps the most interesting aspect is how this stance could influence future upgrade decisions. When teams debate parameter changes or resource allocation, the question may shift from “What do the validators prefer?” to “What keeps the largest applications reliable?”
Lessons from Past Debates on Application Fees
This is not the first time Yakovenko has spoken about the relationship between applications and the base layer. In an earlier discussion involving a major brokerage’s infrastructure choices, he argued that a company could build on Solana, subsidize transaction costs, and still charge customers through its own interface. The point was that applications can capture value without needing to control the underlying chain.
That earlier exchange highlighted a broader tension. Some platforms prefer to keep a larger share of protocol revenue. Others accept paying for access to a high-performance network. Yakovenko’s recent comments reinforce the idea that the network’s primary job is to serve the applications that bring real usage, not to maximize every possible revenue stream for itself.
In my view, this approach aligns with long-term health. A chain that consistently delivers for its largest users tends to attract more builders and more capital. A chain that optimizes primarily for its own operators risks becoming less relevant to the people who actually move value.
How Network Upgrades Fit Into the Picture
Recent progress on Solana’s consensus improvements provides useful context. The shift toward faster finality targets has already begun moving through testing stages. Application teams that simply submit transactions and read balances face minimal migration work. Services that process blocks or track validator activity face more substantial changes.
That distinction matters. It shows that the network can evolve in ways that protect the simplest and most common application patterns while still demanding more from infrastructure providers. Yakovenko’s ranking of the five major apps sits comfortably alongside this philosophy. Optimize for the products that hold capital and process retail volume. Let the more specialized operators adapt.
Finality targets in the range of a few hundred milliseconds represent a meaningful leap from earlier designs. Yet the coverage around these upgrades has been careful to separate consensus finality from the moment a transaction first appears. That nuance is important for applications that need predictable behavior under load.
Validator Economics and the New Reality
Changes to validator fee structures add another layer. Plans to replace individual on-chain voting fees with a flat admission charge per epoch alter the cost structure for operators. Those who cannot cover the charge lose the ability to vote or produce blocks in the following epoch. Payment in advance becomes part of the operational rhythm.
From the perspective of the five highlighted applications, these changes are secondary. What matters is whether transactions land reliably and whether the network remains available during periods of high demand. If the new fee model supports greater stability, it serves the priority list even if it creates temporary pressure on some validators.
I have found that infrastructure operators often adapt faster than people expect once the direction is clear. The key is transparent communication and enough time to adjust. Solana’s staged approach through test networks has generally provided that runway.
What Retail Users Actually Experience
Retail volume sits at the heart of Yakovenko’s ranking. Everyday users interacting through wallets, launchpads, aggregators, and yield platforms generate the activity that justifies prioritizing those applications. When those users encounter failed transactions or unpredictable delays, trust erodes quickly.
Phantom’s widespread adoption means millions of users interact with Solana through a single interface. Pump.fun’s rapid token activity creates bursts of intense demand. Jupiter’s aggregation role places it at the center of many trading flows. Kamino’s strategies attract users seeking yield. Each of these platforms absorbs the consequences of network performance more directly than a validator or a core engineer does.
That is why the ranking feels pragmatic rather than ideological. It is not a dismissal of the people who keep the chain running. It is a recognition that the chain’s purpose is measured by the success of the products people actually use.
Institutional Versus Retail Perspectives
Yakovenko’s plumber metaphor covers both institutional and retail participants. Institutions managing large pools of capital care deeply about reliability and predictable inclusion. Retail users care about speed, low friction, and the ability to act when opportunities appear. Both groups suffer when the network prioritizes other concerns above application performance.
In practice the two groups often share the same applications. A retail trader and an institutional desk might both route through the same aggregator or rely on the same wallet infrastructure. Optimizing for those shared platforms therefore serves a broad spectrum of users at once.
I suspect this dual focus is intentional. By naming products that attract both crowds, Yakovenko avoided creating a false choice between sophisticated capital and everyday activity. The network can and should serve both.
Potential Criticisms of the Ranking
Not everyone will agree with placing specific applications above the broader ecosystem. Some will argue that validators deserve higher priority because without them the chain does not function. Others will note that core engineers create the improvements that benefit everyone. Market makers provide the liquidity that makes trading viable in the first place.
These points are valid. A healthy network needs strong participation across all layers. Yet Yakovenko’s ranking does not claim that other groups are unimportant. It claims that when trade-offs appear, the needs of high-AUM and high-volume applications should weigh more heavily.
That is a reasonable position. Resources are finite. Attention is limited. Choosing where to focus optimization efforts requires a clear hierarchy of importance. Placing the products that hold user capital at the top of that hierarchy protects the network’s reputation and long-term relevance.
How Other Ecosystems Handle Similar Questions
Every major blockchain faces versions of this debate. Some prioritize decentralization metrics above all else. Others focus on developer experience. A few emphasize institutional readiness. Solana’s current leadership appears to be leaning into application performance as the primary filter.
The comparison with Aave is instructive. When a lending protocol holds large amounts of capital, its ability to function during stress becomes a network-level concern. The same logic applies to the Solana applications named in the ranking. If any of them experience prolonged issues, the damage extends beyond a single product. User confidence in the entire ecosystem takes a hit.
Networks that internalize this lesson tend to allocate resources differently. They invest more in tooling that applications need. They test upgrades against real product workloads. They treat application teams as first-class stakeholders rather than afterthoughts.
Looking Ahead at Optimization Choices
Yakovenko’s comments contained no specific upgrade proposal, funding allocation, or change to validator participation rules. They were a statement of principle rather than a technical roadmap. Still, principles shape roadmaps over time.
Future decisions about fee markets, resource allocation, and upgrade sequencing may increasingly reflect the needs of the five named applications and others that meet similar criteria. Teams working on network improvements will likely ask how proposed changes affect the reliability and cost structure of those products.
That shift could prove healthy. It forces a continuous reality check. Does this change make the largest applications more reliable? Does it improve the experience for the retail volume flowing through them? If the answer is unclear, the change may need refinement.
The Human Side of Network Priorities
Behind every ranking sits a set of human judgments. Yakovenko has spent years watching Solana grow from an ambitious project into a major ecosystem. He has seen periods of intense congestion and periods of smoother operation. Those experiences shape how he evaluates trade-offs.
I have found that founders who stay close to real usage patterns often develop sharper instincts about what matters. Abstract metrics are useful, but they rarely capture the full picture. Watching users struggle with failed transactions or watching applications lose capital during outages leaves a lasting impression.
By publicly ranking the five applications above other groups, Yakovenko made those instincts visible. He invited the community to debate the hierarchy. That debate itself has value. It forces participants to articulate what they believe the network is for.
Balancing Short-Term Friction and Long-Term Gains
Any prioritization creates temporary winners and losers. Validators facing new fee structures may feel short-term pressure. Developers adjusting to new data access patterns may spend extra cycles on migration. Market makers recalibrating strategies may experience periods of uncertainty.
Those costs are real. Yet the long-term gain of a network that consistently serves its highest-volume applications can outweigh them. Capital and users tend to concentrate where reliability is highest. Applications that deliver smooth experiences attract more activity, which in turn strengthens the case for further optimization.
The cycle can become virtuous if managed carefully. Clear communication, staged rollouts, and genuine attention to operator concerns help keep the ecosystem cohesive even when priorities shift.
What Success Looks Like Under This Framework
If the ranking influences future work, success will look like fewer disruptions for the named applications and others that meet similar thresholds. Users interacting through those platforms should experience higher success rates for transactions. Capital should feel safer. Retail activity should flow with less friction.
At the same time, the broader ecosystem should remain healthy. Validators should still find the economics workable. Developers should still have clear paths for building. Market makers should still find sufficient opportunity. The ranking does not require sacrificing those groups. It simply places the largest applications first when conflicts arise.
Measuring that balance will take time. Networks evolve through many small decisions rather than single dramatic shifts. Watching how upgrade discussions unfold over the coming months will reveal whether the principle takes root.
A Broader Reflection on Blockchain Purpose
At its core, the discussion returns to a simple question. What is a blockchain for? Is it primarily a technical achievement, a set of economic incentives for operators, or a platform that enables valuable applications? Different communities answer that question differently.
Yakovenko’s ranking offers one clear answer. The network exists to serve the applications that hold substantial assets and process meaningful retail volume. Everything else supports that purpose. Validators secure the environment those applications need. Developers create the tools those applications rely on. Market makers provide the liquidity those applications require. Core engineers improve the foundation so the applications can grow.
That framing feels grounded. It keeps the focus on outcomes that users and capital can feel directly. In a space often distracted by abstract metrics, such grounding is valuable.
Final Thoughts on the Ranking
Anatoly Yakovenko’s decision to place five major applications ahead of validators, developers, market makers, and core engineers was more than a passing comment. It was a statement about what Solana should optimize for. Assets under management and retail volume sit at the center of that vision.
The apps he named—Phantom, Pump.fun, Fomo, Jupiter, and Kamino—represent both the speculative energy and the more structured activity that currently define the ecosystem. By elevating their needs, he signaled that reliability for those products matters more than comfort for any single supporting group.
Whether this ranking shapes concrete protocol decisions remains to be seen. Principles influence practice over time. What is already clear is that the conversation about network priorities has been sharpened. Participants now have a clearer hierarchy to debate.
In my experience, ecosystems that stay close to the products their users actually depend on tend to endure. Those that drift into self-referential optimization often struggle to retain relevance. Yakovenko’s ranking is an attempt to keep Solana firmly in the first category. That effort alone makes the statement worth careful attention.
The plumber metaphor may be the most lasting part of the message. Institutional or retail, the people who keep the system working day after day deserve the highest priority. Everything else follows from that recognition. As Solana continues to evolve, holding onto that simple idea could prove more important than any single technical upgrade.
The discussion is far from over. Network design always involves competing interests. Yet by stating his priorities so plainly, Yakovenko has given the community a clear reference point. Future debates can now return to a shared question: does this change serve the applications that hold the capital and move the volume? If the answer is yes, the path forward becomes easier to see.
