Two Migrations in Akash’s Solana Proposal

A destination choice enters a vote

On October 26, 2026, Greg Osuri announced the Akash core team’s selection of Solana as the proposed home for the network. The plan would replace Akash’s sovereign Cosmos chain with marketplace programs on Solana. But the proposal submitted to voters separates two decisions that a headline about a chain migration can easily collapse: launching SPL AKT and moving the computing marketplace.^[1][2]

At 00:12 UTC on October 27, the official Akash REST response reported proposal 346 as PROPOSAL_STATUS_VOTING_PERIOD at block 29,244,551. Voting began on October 26 at 15:02:58 UTC, with an end time of November 2 at 15:02:58 UTC. This records an open vote, not approval. The proposal explicitly says it neither sets the marketplace cutover date nor moves the marketplace.^[2]

The token track concerns ownership records

The token design concerns which chain records a holder’s AKT. It proposes a one-way portal: AKT removed from circulation on akashnet-2 would be represented by the same number of base units as SPL AKT on Solana. The design’s central accounting condition is that newly represented tokens are backed by verified removals, rather than creating a second spendable copy of the same units. This is a proposed mechanism, not a verified live portal.^[2][3]

That change would not by itself move a tenant’s workload or replace a provider’s lease. The proposal leaves live leases, staking and governance on akashnet-2 unchanged before cutover. The old chain therefore still has a job while the token and marketplace tracks follow different readiness conditions.^[2][4]

The marketplace has work left to settle

A marketplace holds more than users’ token balances. The design distinguishes user accounts from funds held by protocol modules, including escrow that must be attributed as leases settle. It also marks parts of the wind-down accounting as still under review. Moving a token balance cannot, on its own, decide which provider has earned a payment or which tenant is owed a refund.^[3]

The later cutover would move new deployment activity to Solana after marketplace audits, migration rehearsals and a separate on-chain cutover proposal. The proposed plan then allows a 90-day wind-down for existing leases before the old chain halts. Those are conditions and stages in the plan; neither the publication of the plan nor the current vote demonstrates that the audits, cutover or wind-down have happened.^[2][4]

Three documents do not make one calendar

The dates need particular care. The October 26 announcement says token launch comes two weeks after approval, subject to two independent audits. The token and rollout documents, labeled v0.10, draft for review, October 20, instead define launch as seven days after the migration vote passes. The text actually submitted as proposal 346 says launch is expected two to three weeks after passage, once token and portal audits are complete. An expectation conditional on audits does not establish a calendar date.^[1][2][3][4]

Other draft figures differ from the current chain too. The draft uses a 14-day unbonding period and describes 20% quorum with a three-day vote. At the observed block, the official endpoints returned 1,814,400 seconds for unbonding, or 21 days, and governance parameters of 33.4% quorum and 604,800 seconds, or seven days. These are a dated comparison of sources and chain state, not instructions to unbond or a promise about future parameters.^[3][4][5][6]

The rollout draft also requires a token-readiness gate before submission, while the submitted proposal conditions launch on completed audits. Submission alone does not prove that this draft gate was met. The submitted proposal points to a pinned plan commit, and the conflicting token and rollout files at that commit are identical to those at the repository’s current main revision checked for this article. The discrepancy therefore cannot be dismissed as merely reading the wrong branch. The submitted text establishes what voters are being asked to approve; it does not reconcile every design detail or prove implementation readiness. We do not turn any of these relative durations into a migration deadline.^[2][3][4]

What would establish the next stage

The useful distinction is between authorization, readiness and execution. A vote result would establish the community’s decision on this proposal. Published audit and rehearsal evidence would address readiness. A later approved cutover schedule and evidence of its execution would establish the marketplace transition. A Solana token announcement alone cannot answer all three questions.^[2][4]