Akash Migrate: AKT on Solana

Akash Migrate moves AKT from Akash to Solana. You lock AKT on Akash, and the same amount of AKT is minted to a Solana wallet you choose.

Transfers are one way. AKT that arrives on Solana can’t be sent back to Akash through Akash Migrate.

The mainnet contracts are deployed. See mainnet addresses and releases for the token mint, bridge programs, multisig, source code and operator downloads. The CLI guide uses akt v1.1.1; the public portal URL will be announced separately.

There are two ways to send a transfer:

• The Akash Migrate portal: a web app. Connect Keplr, enter a Solana address and an amount, then confirm.
• The akt CLI: run akt tx sink deposit from the command line.

How a Transfer Works

1. You deposit AKT on Akash. The deposit names a Solana wallet address. The Akash sink module locks the AKT and writes a permanent record of the transfer: its ledger ID, sender, recipient and amount.
2. The record is proven on Solana. A relayer submits Akash block headers and a proof of the record to Solana. The AKT program on Solana checks the proof against its Akash light client. A relayer can delay a transfer, but it can’t change a record or create one.
3. Solana mints the AKT. The program mints exactly the recorded amount to the recorded address.
4. Reporters settle the transfer on Akash. Independent reporters check the result on Solana and vote on Akash. The transfer is settled once enough votes agree. Governance sets a decimal threshold. The required vote count is the reporter count multiplied by that threshold, rounded up, and must exceed two thirds of the reporters.

Most transfers finish within a few minutes. You don’t need to do anything after the deposit, and closing the portal doesn’t stop a transfer.

Each transfer has a ledger ID in the form owner/height/sequence: the Akash sender, creating block and position within that block. Keep the full ID to look up the transfer in the portal or on the command line.

If Solana cannot deliver to the address, it records a permanent void. The AKT then follows the refund process on Akash. See Refunds.

Statuses

Akash keeps the financial outcome separate from any dispute. The portal also verifies the finalized Solana outcome; see Statuses in the portal.

A veto or conflict hold requires review. Even a minted or refunded transfer can have an unresolved conflict; the hold does not erase what has already happened.

Limits

Akash governance sets the transfer limits and can change them.

The account cap may be zero to disable that limit. The other caps remain positive, and the aggregate cap still applies. There are no per-account deposit-count or open-transfer-count limits. Deposits that exceed an enabled sending cap fail; the amount stays in the sender’s wallet, though a submitted transaction can still incur a network fee.

Akash uses its existing epochs module to track quota periods. The selected day schedule has a configurable duration and start time in epochs genesis. Allowances reset when that schedule advances, rather than at midnight UTC. A refund does not restore the sender’s sending allowance.

Solana mints can happen as soon as a deposit proof is available. They do not wait for the Akash quota period to end. If Solana’s independent daily cap is exhausted, affected mints wait for its next UTC day.

The portal shows transfer bounds and epoch caps. akt query sink params shows configuration; akt query sink state shows the current epoch and global usage; akt query sink account <owner> shows the account’s lifetime and current-epoch sending amounts.

Fees

• You pay the Akash network fee for the deposit, in AKT.
• There is no transfer fee. Solana mints the full amount you deposit.
• You don’t need SOL to receive AKT. You need SOL only to move AKT on Solana afterwards.

Refunds

Solana voids a transfer when it can’t deliver to the address, for example because the address belongs to a program or a token account instead of a wallet. Akash governance can also order a void. The order must be proven on Solana; it does not authorize a refund by itself. The refund process has three steps:

1. Reporters confirm the void on Akash.
2. A challenge window of at least 72 hours starts. During the window, a reporter or Akash governance can stop the refund if the void doesn’t match Solana.
3. After the window, an eligible refund can be paid to the original sender. Reporters submit refunds automatically, and anyone can submit akt tx sink finalize-refund <owner/height/sequence>.

The refund returns the full deposited amount. The Akash network fee for the deposit isn’t returned.

The challenge window is a configurable duration measured from authorization. Crossing a quota boundary does not shorten it. Payment also needs current authorization, no hold, enabled refunds, queue priority and room under the epoch refund cap. A deadline passing does not prove payment. Refunded means the money has actually returned.

Safety

• Check the address. AKT is minted to exactly the address you enter, and a completed transfer can’t be reversed. Send to a Solana wallet address you control, not a token account.
• Your Solana wallet doesn’t sign. You sign one transaction: the deposit on Akash. Connecting a Solana wallet in the portal only reads its address.
• Deposits and refunds can be paused. A pause guardian chosen by governance can turn deposits, refunds or both off. Only governance can turn them back on. AKT from transfers you already made stays locked on Akash until it’s minted or refunded.
• Governance controls the settings. The limits, the reporter set, the vote threshold and the pause guardian are Akash governance parameters. Read settings with akt query sink params and the active policy with akt query sink reporters. These commands require the akt v1.1.1 commands.

Verify AKT on Solana

AKT on Solana is an SPL token with six decimals, like AKT on Akash, so one base unit equals one uakt. Its token name is Akash and its symbol is AKT.

Other tokens can copy the name and symbol. Check the mint address before you accept or buy AKT on Solana.

The canonical mint is 5d3fjPDdkYbtYcAMR9PC2TANaEyhzuyP8JxTEwqjVgBZ.

See the mainnet reference for all contract and multisig addresses, metadata, verification commands, Docker releases and source repositories. The native Sink module account holds locked AKT; only refunds release it back to senders.

FAQ

Can I move AKT from Solana back to Akash?

No. Akash Migrate only moves AKT from Akash to Solana.

Which Solana addresses can receive AKT?

A wallet address: the address your Solana wallet shows when you receive tokens. Phantom, Solflare, Backpack and hardware wallets all work, and so does a new address that has never been used.

Akash checks the address format and its configured recipient policy. Solana checks the actual account when resolving the transfer. A token account or other ineligible account can therefore pass the native address check and still be voided on Solana. Send to your wallet address, not its token account.

What if I sent AKT to the wrong wallet?

If the address is a valid wallet, the AKT is minted there and Akash Migrate can’t recover it. Only transfers that Solana can’t deliver are refunded.

What happens to my transfer during a pause?

A pause stops new deposits, refunds or both. AKT from transfers you already made stays locked on Akash until the transfer is minted or refunded.

How do I find a transfer?

In the portal, connect the Keplr account that sent it, or track it by ledger ID or Akash transaction hash. On the command line, run akt query sink transfer <owner/height/sequence>.

For Developers

Akash REST endpoints serve the sink queries:

Continue list queries with the returned pagination.next_key. Treat the key as opaque and keep the same filters, direction, and x-cosmos-block-height across a pass. A pruned height must fail the pass. Do not enumerate numeric IDs or treat an exhausted snapshot cursor as a permanent subscription to future transfers.

MsgSinkResponse carries the full typed ID. The typed EventTransferCreated event is supplementary; owner queries and ID lookups do not depend on a transaction event index. The transfer response exposes one explicit financial status and a separate hold, without a second public-status mapping.

A deposit must be the only message in its transaction and must be signed by the depositing account. Akash rejects deposits sent through authz, a smart contract or a transaction with other messages.

Related Resources

• Mainnet addresses and releases - Contracts, multisig, artifacts and source
• Use Akash Migrate - Send a transfer with Keplr
• Send AKT to Solana with akt - Command-line transfers and module commands
• Akash Migrate services - Run a relayer or reporter
• Queries & Transactions - Other akt chain commands