Why Akash Is Leaving Cosmos: The Real Cost of Blockchain Sovereignty
Akash Network’s proposed migration to Solana raises a fundamental question for decentralized infrastructure: when does operating an independent blockchain become more expensive than the sovereignty it provides?
October 29, 2026 | IBSvalidator — Blockchain Infrastructure & Governance Analysis
Introduction: Can a Blockchain Outgrow Its Own Blockchain?
For years, launching an independent blockchain represented one of the strongest expressions of decentralization.
Your own validators. Your own consensus. Your own governance. Your own economic security.
Complete control over the infrastructure supporting your protocol.
But sovereignty comes with responsibilities.
Validators must be incentivized. Network upgrades require coordination. Consensus software needs maintenance. Security depends on an economic system capable of sustaining itself over time.
And eventually, a difficult question emerges:
What happens when maintaining the blockchain becomes more expensive than the benefits it provides to the application?
Akash Network is confronting that question.
On October 26, 2026, Akash opened governance Proposal #346, asking AKT stakers to approve a strategic migration from its sovereign Cosmos SDK blockchain to Solana.
The proposal represents a potential transformation of the network’s technical architecture, validator economics, interoperability model and long-term infrastructure strategy.
As of October 29, the proposal has attracted overwhelming initial support, with approximately 98% YES among decisive votes in the research snapshot.
However, voting remains open until November 2, 2026.
The migration has not yet been approved or executed.
Beyond the immediate governance decision, Akash’s proposed transition offers a valuable case study for the broader Cosmos and DePIN ecosystems.
Let’s examine what is changing, why Akash believes the move is necessary, and what decentralized infrastructure may learn from this decision.
1. Understanding Akash: A Decentralized Marketplace for Computing Power
Before discussing the migration, we need to understand what Akash actually does.
Akash Network operates a decentralized marketplace connecting people who need computing resources with independent infrastructure providers.
Imagine a marketplace for cloud computing.
Instead of purchasing computing capacity exclusively from a single cloud company, developers can request resources from multiple independent operators.
These resources include:
- CPU processing power.
- GPU acceleration for artificial intelligence.
- RAM and storage.
- Network connectivity.
- Infrastructure for containerized applications.
A developer describes the required resources through a Stack Definition Language (SDL) file.
Compatible providers can submit bids.
The developer selects an offer, creating a lease that defines the relationship between the tenant and the provider.
The application then runs on the provider’s infrastructure, generally orchestrated through Kubernetes.
Where does blockchain enter the picture?
This distinction is essential.
Akash does not execute AI models or cloud workloads on its blockchain.
The blockchain coordinates the marketplace.
It records deployments, bids, leases, provider information and economic settlement.
The actual computing happens off-chain, on physical servers operated by independent providers.
In other words:
The blockchain manages the marketplace. The providers deliver the computing power.
This separation is central to understanding why Akash is considering a different settlement infrastructure.
2. The Original Architecture: A Sovereign Cosmos Blockchain
Akash currently operates on akashnet-2, a sovereign blockchain built with the Cosmos SDK and CometBFT.
This architecture provides several important capabilities.
Independent consensus
Akash maintains its own validator set.
Validators participate in consensus, produce blocks and secure the network’s state.
AKT staking provides the economic foundation for this security model.
Protocol-level governance
AKT stakers participate in governance decisions.
They can influence protocol parameters, upgrades and strategic changes.
Native IBC interoperability
As a Cosmos-based blockchain, Akash can communicate with compatible networks through the Inter-Blockchain Communication protocol.
IBC uses light clients and cryptographic proofs to verify cross-chain state transitions.
Relayers transport the necessary messages and proofs between networks.
Application-specific control
A sovereign blockchain allows its developers to customize execution rules, network parameters and upgrade processes.
These capabilities are valuable.
But they also require maintaining an entire blockchain infrastructure.
And that is where Akash’s economic argument begins.
3. Why Akash Wants to Move to Solana
In its October 26 announcement, the Akash core team explained why it selected Solana as its preferred destination.
The central argument is relatively straightforward.
Akash believes its marketplace no longer requires enough specialized consensus functionality to justify operating an independent blockchain.
The team identifies several reasons.
3.1. Reducing operational complexity
According to Akash, its current architecture involves approximately 100 validators securing the network.
The development team must also maintain customized components associated with:
- Cosmos SDK.
- CometBFT.
- Gogoproto.
- Network upgrades.
- Validator coordination.
Maintaining a sovereign chain requires engineering resources that could otherwise support marketplace development.
Moving to Solana would transfer responsibility for base-layer consensus to an existing network.
Akash would still maintain its marketplace programs, provider software, indexers and supporting infrastructure.
But it would no longer operate its own consensus network.
3.2. Lower transaction costs at scale
Akash estimates that its marketplace currently generates approximately 15,000 blockchain transactions per day.
Based on its proposed Solana architecture, the team estimates network fees of approximately 0.075 SOL per day at that activity level.
These are Akash’s projections, not independently verified future operating costs.
They also exclude broader expenses associated with development, infrastructure services and migration.
Nevertheless, the economic objective is clear.
Akash wants its marketplace to scale without requiring proportional investment in maintaining a dedicated consensus layer.
3.3. Joining an established DePIN ecosystem
Solana already supports several prominent decentralized physical infrastructure projects.
Examples include Helium, Render, Hivemapper, Nosana and io.net.
Akash sees strategic value in operating within an ecosystem where decentralized infrastructure projects, developers and potential users are already present.
Helium’s previous migration from its own blockchain provides an especially relevant precedent.
However, successful migration by another protocol does not guarantee that Akash will experience identical results.
3.4. Accessing liquidity and applications
The team also expects that a native Solana version of AKT could benefit from access to existing wallets, exchanges, decentralized finance applications and stablecoin infrastructure.
This could improve accessibility for developers, providers and token holders.
But these benefits remain strategic expectations.
Individual integrations and actual liquidity improvements must be evaluated after implementation.
4. Proposal #346: What Is Actually Being Decided?
One of the most important details is that Proposal #346 does not immediately migrate Akash’s marketplace.
It represents the first major governance decision in a longer process.
Status as of October 29, 2026: Voting in progress.
The vote opened on October 26 and is scheduled to close on November 2 at 15:02 UTC.
Research snapshots from October 29 show approximately 98% support among decisive votes, with participation already exceeding the required quorum.
These figures are provisional.
Votes can still change before the deadline, and the final result must be confirmed on-chain.
What would approval authorize?
An approved proposal would establish Solana as the migration destination and authorize the next phase of the process.
That includes preparing a native Solana version of AKT and a migration mechanism, subject to security requirements.
It would not immediately:
- Shut down
akashnet-2. - Transfer existing marketplace leases.
- End current validator operations.
- Replace the current governance infrastructure.
- Establish a final marketplace cutover date.
These changes require additional development, testing and governance decisions.
A successful initial vote would authorize the direction of travel, not complete the journey.
5. How Would the Migration Work?
Akash’s proposed migration separates the token transition from the marketplace transition.
This is an important architectural and operational distinction.
Phase 1: AKT token migration
The plan provides for AKT to become a native Solana token.
Existing AKT would migrate at a 1:1 ratio.
The token would retain its ticker and six-decimal precision.
A dedicated migration portal would allow holders to move their assets from Cosmos to Solana.
The portal is designed to operate in one direction.
Once migrated, AKT would not have an official mechanism for returning to akashnet-2.
The proposed portal availability period is two years.
Crucially, token launch depends on independent security audits.
The exact launch date remains subject to those requirements and official confirmation.
Phase 2: Marketplace implementation
Moving the marketplace is substantially more complex than moving the token.
Akash must recreate its marketplace functionality using native Solana programs.
That includes mechanisms for deployments, bids, leases, payments and provider interactions.
The plan also requires additional security audits and infrastructure testing.
According to the published migration framework, preparation includes:
- A provider testnet lasting at least six weeks.
- Participation from at least 25 independent operators.
- A community migration rehearsal lasting at least 14 days.
- Resolution of critical security and operational issues.
Phase 3: A separate governance decision
Once the necessary technical conditions have been satisfied, another governance proposal must determine the marketplace cutover.
Until that decision is executed, the existing Cosmos-based marketplace remains operational.
Phase 4: Transition and shutdown
Following a successful cutover, the plan provides for a 90-day transition period.
Existing workloads would continue temporarily while tenants migrate their deployments.
After that period, the old blockchain would be scheduled to stop operating.
There is currently no confirmed marketplace cutover date.
The distinction matters for developers, infrastructure operators and AKT holders preparing for the transition.
6. What Happens to Akash Validators?
From an infrastructure perspective, this is one of the most consequential aspects of the proposal.
Today, Akash validators secure a dedicated proof-of-stake blockchain.
Their responsibilities include consensus participation, network availability, governance and operational security.
Their economic role is connected to AKT staking and the security of akashnet-2.
Under the proposed architecture, Akash would no longer maintain an independent validator set after the old chain is retired.
Instead, marketplace execution would depend on Solana’s existing consensus infrastructure.
Akash validators do not automatically become Solana validators
This is an important clarification.
Operating a validator on Akash and operating a validator on Solana are different activities, with different technical requirements and economic models.
The proposed migration does not automatically transfer validator status, delegations or revenue.
Akash has identified possible alternative roles for existing operators, including:
- Cloud infrastructure providers.
- RPC service operators.
- Auxiliary infrastructure services.
- Automated maintenance services associated with marketplace execution.
However, these are not equivalent to continuing the existing AKT consensus-validation business.
What about staking rewards?
Under the proposed plan, AKT staking continues to secure the existing blockchain during the transition.
The current chain’s inflation and associated staking rewards are expected to end at marketplace cutover.
The validator role itself continues during the wind-down and ends when the old chain halts.
Future economic mechanisms would need to be defined separately.
For delegators, this creates an important distinction between holding AKT and participating in consensus security.
After the proposed migration, AKT would no longer directly secure the blockchain executing the marketplace.
That responsibility would belong to Solana’s validator network, secured through SOL staking.
For validator operators, the transition therefore represents a structural change rather than a routine network upgrade.
7. What Happens to IBC and Cosmos Interoperability?
Akash’s current architecture benefits from native IBC connectivity.
This enables interoperability with compatible Cosmos networks through established light-client and relayer infrastructure.
Migrating the marketplace to Solana would change that model.
Once akashnet-2 is retired, its native IBC connections would no longer operate.
Implications for relayers
Relayers currently supporting routes involving Akash would eventually lose those specific routes.
This is not an IBC failure.
It is the consequence of removing one of the participating blockchains.
IBC depends on the consensus and state-verification mechanisms of the connected networks.
If Akash stops operating its CometBFT blockchain, the existing light-client relationships cannot simply continue unchanged.
Implications for AKT holders
AKT held on Osmosis or other IBC-connected networks would need to follow the official migration process.
Akash’s published plan indicates that such assets must first return to the original Akash chain before entering the migration portal.
Users should wait for verified official instructions.
A broader interoperability question
The transition highlights an important distinction between interoperability and ecosystem permanence.
IBC provides a framework for communication between compatible networks.
It does not require every application to maintain its own sovereign blockchain forever.
However, abandoning a Cosmos-based chain also means abandoning the native interoperability advantages attached to that architecture.
Future connections would require different technical solutions.
Those alternatives introduce their own security assumptions and dependencies.
8. Cosmos vs Solana: Two Different Infrastructure Models
It would be misleading to interpret Akash’s decision as evidence that Cosmos has failed.
Cosmos and Solana offer different approaches to blockchain infrastructure.
The appropriate architecture depends on the requirements of the application.
Neither model eliminates infrastructure trade-offs.
When does a sovereign appchain make sense?
A dedicated blockchain can be valuable when an application requires specialized execution or consensus functionality.
Examples include:
- Custom transaction ordering.
- Specialized block processing.
- Application-specific security requirements.
- Direct control over consensus upgrades.
- Dedicated economic security.
- Particular censorship-resistance or interoperability requirements.
Akash itself cites dYdX as an example of an application whose specialized architecture can justify a sovereign blockchain.
When does shared infrastructure make sense?
A shared blockchain can be attractive when an application primarily requires reliable execution, settlement and access to an established ecosystem.
In that situation, maintaining a separate validator network may introduce costs without delivering sufficient additional value.
Akash believes its marketplace falls into this category.
But that conclusion is specific to Akash’s requirements.
Other applications may rationally reach the opposite conclusion.
9. The Security Trade-Off: Sovereignty vs Shared Consensus
Moving to a shared blockchain does not eliminate security responsibilities.
It changes where those responsibilities reside.
Security today
Akash currently depends on its own validators and consensus mechanism to secure marketplace state.
Its validator set is responsible for maintaining the blockchain’s integrity and availability.
Security after the proposed migration
Under the new architecture, Solana validators would secure the underlying execution environment.
Akash would remain responsible for its application programs, economic mechanisms, access controls and supporting services.
The migration would also introduce additional security considerations.
Migration portal risks
A token migration portal is a sensitive component.
It must ensure that the quantity of AKT created on Solana corresponds to the quantity removed from circulation on Cosmos.
Akash’s proposed safeguards include independent audits, supply reconciliation, minting limits and automatic pauses when inconsistencies are detected.
These are planned protections, not guarantees that migration risk has disappeared.
Network dependencies
Akash would also become dependent on Solana’s availability and underlying network rules.
A major Solana disruption could affect marketplace operations.
Conversely, Akash would no longer need to maintain the security and availability of a separate consensus network.
Shared security reduces certain operational burdens while introducing different dependencies.
The relevant question is whether those dependencies are acceptable for the application’s requirements.
10. Governance: The Most Important Part of the Story?
There is another dimension worth examining.
Akash’s core team has selected Solana as its preferred technical destination.
But the team cannot simply declare the migration complete.
The proposal must pass through governance.
AKT stakers have the opportunity to approve or reject the strategic direction.
And the future marketplace cutover requires another decision.
For decentralized infrastructure, this distinction matters.
Governance is not limited to adjusting inflation parameters or distributing community funds.
It can determine the future architecture of an entire protocol.
In this case, token holders are being asked to consider whether the network should eventually retire the blockchain they currently secure.
That is a substantial responsibility.
It also demonstrates the importance of transparent proposals, technical documentation, clear transition plans and informed participation.
However, governance approval alone does not establish that the proposed architecture is technically or economically superior.
Its long-term success will depend on execution.
11. The DePIN Perspective: Is a Dedicated Blockchain Always Necessary?
Akash’s proposal raises a broader question for decentralized physical infrastructure networks.
DePIN projects coordinate real-world resources.
Those resources may include computing power, storage, wireless connectivity, sensors or other physical infrastructure.
Blockchain technology can provide mechanisms for settlement, incentives, coordination and verifiable economic activity.
But the physical service itself generally operates outside the blockchain.
This creates an architectural choice.
Should the protocol maintain its own consensus network?
Or should it use an existing blockchain and concentrate resources on coordinating its physical infrastructure?
The cost of independence
A sovereign blockchain provides flexibility and control.
But it also requires:
- Sustainable validator incentives.
- Consensus security.
- Software maintenance.
- Upgrade coordination.
- Operational monitoring.
- Long-term ecosystem support.
These costs can be justified when sovereignty provides meaningful application-level benefits.
They become harder to justify when the application uses relatively little of that flexibility.
The value of specialization
For Akash, the core product is its decentralized computing marketplace.
Its competitive position depends on attracting reliable providers, available GPU capacity and developers willing to deploy real workloads.
The proposed migration reflects the team’s belief that resources currently dedicated to blockchain maintenance could create greater value elsewhere.
That remains a strategic hypothesis until the migration is implemented and its results can be measured.
The same reasoning could apply to other DePIN networks.
However, some protocols may still benefit significantly from independent consensus and specialized economic security.
There is no universal answer.
12. What Should the Ecosystem Watch Next?
Several developments will determine whether Akash’s proposed transition succeeds.
The final governance result
Proposal #346 closes on November 2, 2026.
The final outcome must be confirmed before the migration can be described as approved.
Security audits
The token and migration portal must satisfy the required security conditions before launch.
Provider participation
Akash will need sufficient independent providers to support the marketplace through the transition.
Provider participation matters because decentralized cloud infrastructure ultimately depends on physical operators delivering usable resources.
Validator continuity
The existing blockchain must remain sufficiently secure and operational throughout the transition.
The proposed migration creates a delicate period during which operators must continue supporting infrastructure scheduled for retirement.
IBC coordination
Relayers, exchanges, wallets and connected applications will need clear migration instructions.
Economic sustainability
The most important long-term test will be whether the new architecture improves the marketplace’s economics without introducing unacceptable security, availability or governance compromises.
Lower blockchain transaction fees alone will not establish success.
The quality, cost and reliability of actual computing services will remain decisive.
Conclusion: When Is Blockchain Sovereignty Worth Its Cost?
Akash Network’s proposed migration is more than a change of blockchain.
It challenges an assumption that has shaped decentralized infrastructure for years:
That owning the underlying consensus layer is always the strongest expression of decentralization.
Sovereignty provides valuable capabilities.
It enables independent governance, specialized execution, dedicated economic security and direct control over infrastructure.
But these capabilities carry operational and economic costs.
Akash believes that, for its computing marketplace, shared infrastructure may offer a more sustainable balance.
That decision comes with significant trade-offs.
Dedicated validator economics would disappear. Native IBC connectivity would end. Security assumptions would change. New dependencies would emerge.
For Cosmos, the lesson is not that sovereign appchains have become obsolete.
For Solana, it is not that shared infrastructure automatically provides the best solution.
And for DePIN, the lesson extends beyond either ecosystem.
A decentralized protocol must understand which parts of its infrastructure genuinely require sovereignty and which can benefit from shared foundations.
The next chapter for Akash will test that distinction in practice.
For now, Proposal #346 remains a governance decision in progress.
And perhaps the most valuable question it raises is one every infrastructure project should eventually confront:
When does sovereignty create more value than it costs to maintain?
Frequently Asked Questions
Is Akash Network leaving Cosmos?
Akash has proposed migrating from its sovereign Cosmos SDK blockchain to Solana. As of October 29, 2026, Proposal #346 remains under governance voting. The migration has not yet been executed.
Has Proposal #346 already passed?
No final result is available as of the article’s publication date. Voting is scheduled to close on November 2, 2026, at 15:02 UTC. Preliminary results show strong support, but they are not final.
Will AKT disappear?
No. The proposed migration would move AKT to Solana at a 1:1 ratio while retaining its ticker and six-decimal precision. The transition remains subject to governance and security requirements.
Will Akash validators continue receiving staking rewards?
Under the proposed plan, current staking rewards would continue during the transition and end at the future marketplace cutover. The dedicated Akash validator role would end when the old blockchain shuts down. Future economic mechanisms remain to be defined.
Will Akash still use IBC?
The existing native IBC connections associated with akashnet-2 would eventually disappear if the chain is retired. Future interoperability would require alternative mechanisms.
Will existing Akash deployments stop working immediately?
No. The initial migration proposal does not immediately affect existing workloads. The plan provides for a separate marketplace cutover decision and a subsequent transition period.
Does moving to Solana make Akash more decentralized?
Not automatically. The proposed architecture changes the distribution of security responsibilities and operational dependencies. Its effects on decentralization must be evaluated across consensus, providers, governance and infrastructure.
Why not simply use Cosmos shared security?
Akash argues that shared security within Cosmos could reduce some staking-related costs but would not sufficiently address the maintenance and distribution challenges identified by the team. This is Akash’s strategic assessment, not a universal limitation of Cosmos-based infrastructure.
Sources and Further Reading
Primary sources
- Akash Network — Why We Selected Solana for Akash
Greg Osuri, October 26, 2026.
Official explanation of the proposed migration, technical motivations and trade-offs. - Akash Governance — Proposal #346
Voting period: October 26 — November 2, 2026.
Governance proposal and migration authorization. - Akash Chain Migration Program — AEP-79
Technical migration specifications, security requirements, rollout strategy and operational dependencies. - Akash Network Documentation
Architecture, providers, deployments, leases and marketplace mechanisms. - Cosmos SDK Documentation
Sovereign blockchain architecture, staking and governance. - IBC Documentation
Interoperability architecture, light clients and relayer responsibilities.
Editorial note: This analysis reflects information available on October 29, 2026. Governance results, technical specifications and migration timelines may change. All forward-looking elements should be interpreted as proposed or planned until officially confirmed.
Expand Your Horizon with IBS
Stay ahead of the latest innovations in the Cosmos ecosystem and follow the progress of exciting projects by joining us on Discord and following us on Twitter.
By joining us, you are investing in a future where every interaction counts, as we build this future together, block by block. With IBS, write your own chapter in the story of true and verifiable decentralization.
Don’t miss the opportunity to be part of this revolution. Join us today and help build a decentralized ecosystem for tomorrow!