AEP-95: One-Way AKT Sink to Solana

aep: 95 title: “One-Way AKT Sink to Solana” author: Artur Troian (@troian), Joseph Chalabi (@chalabi2) status: Draft type: Standard category: Core created: 2026-10-27 discussions-to: https://github.com/orgs/akash-network/discussions roadmap: major requires: 79

Summary

This AEP defines a one-way sink (bridge) for moving AKT from Akash to Solana, the first step in the Akash chain’s migration (see AEP-79 and its Chain Migration Program document set).

1. The user signs MsgSink on Akash with an amount and a Solana wallet address.
2. A new module, x/sink, locks the AKT and writes a fixed 77-byte transfer record into its store.
3. A relayer submits a proof of the record to the AKT program on Solana. An Akash light client on Solana verifies it against headers signed by Akash validators.
4. The AKT program mints the same amount of SPL AKT, once per record. If the recipient cannot hold AKT, it marks the record voided instead.
5. Reporters read the outcome on Solana and submit it to Akash. A confirmed mint closes the record. A confirmed void allows a refund after a challenge window.

The AKT mint is created on Solana with zero supply before the Akash upgrade. Transfers open after the upgrade and completion of the token and portal audits required by Akash governance proposal 346. Overclock Labs (OCL) then sends 1,000,000 AKT through the bridge to a Solana treasury vault to provide initial liquidity. Every AKT on Solana, including this seed deposit, is minted against a proven deposit and backed by AKT locked in x/sink.

During the launch phase, SPL AKT supports transfers and DEX liquidity only, with no staking or governance rights. Inflation and BME remain on Akash, and total supply follows Akash’s schedule.

Motivation

AKT launches on Solana before any protocol functions move there. The immediate goal is market access. Solana has the deepest DEX liquidity and widest wallet distribution for DePIN assets. AKT holders should be able to trade against SOL and USDC there without a wrapped-asset intermediary.

The bridge is deliberately one-way. SPL AKT is the canonical token on Solana, so no return path is needed. Omitting that path removes the largest class of bridge attacks. Locking AKT preserves Akash’s supply accounting and allows refunds through ordinary bank transfers.

This AEP covers the launch phase only. Staking, governance, BME and emissions on Solana belong to a later AEP.

Constraints and scope

The design must meet these requirements.

1. The AKT mint is created on Solana first. Users initiate transfers from Akash to Solana, with no return path. Transfers remain open for 2 years from token launch, as proposal 346 requires.
2. AKT moved to Solana is locked on Akash in a new module, x/sink. The marketplace escrow module is not reused.
3. The user signs one Akash transaction (Keplr or any Cosmos wallet) with an amount and a Solana address. The AKT is locked, the destination is checked on both chains, and the AKT is minted on Solana. If Solana cannot accept the transfer, the AKT goes back to the sender.
4. During the launch phase the Solana token has no protocol functions: no staking and no governance.
5. Solana mints nothing on its own. Every SPL AKT is minted against a proven x/sink record. Inflation and BME continue on Akash.
6. Initial liquidity comes from Akash: once transfers open, OCL sends 1,000,000 AKT through x/sink to the treasury vault.
7. No intermediary chains in the transfer path (no Cosmos Hub, Axelar or Wormhole Gateway routing).
8. Anyone can relay. The relayer, reporters and light client can each be replaced through configuration or governance.
9. Only liquid AKT can be deposited. Bonded and unbonding AKT must finish unbonding first. A separate upgrade will support moving staked AKT in one step, as proposal 346 describes.

Out of scope: emissions, staking or governance on Solana, the future of the Akash chain, and residual balances at any future shutdown.

Terminology

Trust model

What each side checks

To accept a header that skips heights, the light client requires signatures representing more than one third of the last trusted validator set’s voting power and more than two thirds of the new set’s voting power. Forging Akash state on Solana therefore requires more than one third of the stake trusted at the last update. That stake remains bonded and slashable during the trusting period. Two valid, conflicting headers freeze the client.

What each party could do if compromised

Specification

Overview

sequenceDiagram
    autonumber
    actor U as User (Cosmos wallet)
    participant S as x/sink (Akash)
    participant R as Relayer
    participant LC as Light client (Solana)
    participant M as AKT program (Solana)
    participant P as Reporters

    U->>S: MsgSink {dest, amount}
    S->>S: check, lock AKT, write transfer/{id}
    R->>LC: upload signed Akash headers
    R->>M: mint_transfer(record, proof_height) with ICS23 proof
    M->>LC: verify_membership(sink, transfer/{id}, record)
    alt recipient can hold AKT
        M->>M: mint to recipient ATA, status Minted
    else recipient cannot hold AKT
        M->>M: status Voided (InvalidRecipient), nothing minted
    end
    P->>M: read status at finalized commitment
    P->>S: MsgReportOutcome
    alt threshold reports Minted
        S->>S: Minted, AKT stays locked
    else threshold reports Voided
        S->>S: Voided, challenge window starts
        Note over S: any reporter or governance can veto
        S->>U: MsgFinalizeRefund pays the sender after the window
    end

A cap, pause or light-client error leaves no status on Solana, so the relayer retries later. A timeout alone never triggers a refund.

Akash: x/sink module

Store

{id} in transfer/ and void/ is the decimal ID with no leading zeros. IDs start at 1, increase by one and are never reused. The store name sink and these two keys are part of the proof format: changing them breaks every Solana proof. Parameters, totals and per-sender usage are stored under separate keys that Solana never reads.

Transfer record. 77 bytes, integers little-endian, no length prefixes.

Void order. 9 bytes: version 1, then the transfer ID as a little-endian u64.

Proofs. The proof path has two parts, the store name sink and the key. The proof is a protobuf ibc.core.commitment.v1.MerkleProof (IAVL proof, then multistore proof), fetched with the ABCI query /store/sink/key and prove=true. State committed at height H is proven against the app hash in header H+1.

Deposit: MsgSink

MsgSink { sender, dest_type, dest, amount } returns MsgSinkResponse { id }.

A deposit must meet all of these conditions. Otherwise, the transaction fails without locking funds.

• params.enabled is true.
• MsgSink is the only top-level message in the transaction, and sender is an ordinary signing account. Module accounts, authz MsgExec and other nested execution are rejected.
• dest_type is 1 (Solana public key).
• dest is canonical base58 of 32 bytes and not all zeros. It must be a valid Ed25519 point (a wallet address) unless it is in vault_allowlist.
• amount is positive, in uakt, at least min_transfer, and no greater than either solana_daily_mint_cap or max_transfer. Each sender is limited to max_daily_per_account deposits per UTC day and max_pending_per_account open transfers.
• If max_daily_amount_per_account is set, the sender’s total for the UTC day, including this deposit, stays within it.

On success, the module moves amount from the sender to the sink account, assigns the next ID, writes transfer/{id}, starts a pending settlement, adds the open-index entry and emits sink_deposit. The response includes the transfer ID.

The sink account is a blocked bank address. MsgSend, MsgMultiSend and contract sends to it fail, and it cannot be a distribution withdraw address. The memo is ignored. The user pays only the normal Akash transaction fee.

Settlement

Each transfer has a settlement status and a hold field.

Reporter votes. MsgReportOutcome { reporter, id, reporter_epoch, round, observation }. The observation contains the outcome (minted or voided), the finalized Solana slot and the 64-byte transaction signature.

• The reporter must be in params.reporters, and the vote must specify the current reporter epoch and the transfer’s current round. Duplicate votes have no effect.
• When reporter_threshold votes report a mint and there is no hold, the transfer becomes Minted (sink_mint_confirmed).
• When reporter_threshold votes report a void and there is no hold, the transfer becomes Voided and its challenge window ends challenge_period_seconds later (sink_void_confirmed).
• Mixed mint and void votes, or a vote against a confirmed outcome, set a conflict hold (sink_conflict).
• Changing the reporter set or the threshold increases reporter_epoch. Votes from older epochs do not count. On the next report, a nonterminal transfer returns to pending for a new vote.

Refund. MsgFinalizeRefund { executor, id }. Anyone can submit it. A refund is paid only when:

• refunds_enabled is true,
• the transfer is Voided with no hold,
• the void was confirmed in the current reporter epoch,
• the challenge window has ended,
• the amount fits within the remaining daily_refund_cap for the UTC day, and
• it is the oldest waiting refund, ordered by challenge end and then ID. MsgFinalizeRefund rejects all others.

It pays exactly the recorded amount to the recorded sender, marks the transfer Refunded and emits sink_refunded. The refund comes from that transfer’s locked AKT.

Veto. MsgVetoVoid { signer, id, reason }. A current reporter can veto during the challenge window. Governance can veto any time before payment. The transfer must be Voided. The veto sets a hold (sink_veto).

Governance.

• MsgRequestVoid { authority, id } writes void/{id} for a transfer that is not Minted or Refunded (sink_void_order). It moves no funds. A refund still requires proof of the void on Solana and confirmation by reporters.
• MsgResolveTransfer { authority, id, decision, observation, reason } resolves a hold or stalled vote. RESTART returns the transfer to pending. CONFIRM_MINT and CONFIRM_VOID require a matching observation. CONFIRM_VOID starts a new challenge window and leaves any refund subject to the refund switch and cap. A Minted or Refunded transfer cannot change. Every decision starts a new round and clears the votes and the hold (sink_resolved).
• MsgUpdateParams { authority, params } replaces the whole parameter set. It is the only way to turn deposits or refunds on, or to set the guardian.

Pause guardian. MsgGuardianPause { guardian, deposits, refunds }. The signer must be params.pause_guardian. It turns enabled, refunds_enabled or both off, never on (sink_guardian_pause).

Messages

All eight messages have Amino JSON names, such as sink/MsgSink and sink/MsgGuardianPause, so Ledger signing works through Keplr.

Parameters

See Decisions for proposed mainnet values.

Queries

Public statuses are transfer_pending, completed (mint confirmed) and void (void confirmed or refunded). A void order alone does not show as void.

Events

Totals and invariant

Totals tracks pending_amount, minted_amount, voided_amount, refunded_amount, pending_count, last_transfer_id, the day’s refunds and reporter_epoch. Each transfer’s amount belongs to exactly one total: pending, minted, voided or refunded. The module maintains this equality:

sink bank balance = pending_amount + minted_amount + voided_amount

refunded_amount is the cumulative amount paid out of the module. Only MsgFinalizeRefund can release locked AKT; there is no general withdrawal mechanism.

Upgrade and genesis

GenesisState { params, totals, transfers, accounts }.

The upgrade that adds the module must:

1. Add the store with StoreUpgrades{Added: ["sink"]}.
2. Before migrations, run PrepareInstall. The sink address is deterministic, so anyone can send coins to it before the upgrade. PrepareInstall converts any existing account at that address into the module account, preserves its account number, and moves its balance to the community pool (sink_preexisting_balance).
3. Run InitGenesis with default parameters and empty totals. No funds move.
4. Leave deposits and refunds disabled, with no reporters or guardian. Governance configures them after the upgrade.

Exported genesis keeps the records, settlements, counters and per-sender usage. Import checks the bank equality above.

Solana: light client

The bridge uses a dedicated deployment of the ICS07 Tendermint client and its access manager, built from cosmos/ibc-contracts at dc78ade828b766b218fb6bcb5417fdaf8e553021 with four patches:

• One client per deployment, at the ["client"] PDA. Each verified height has a consensus state at ["consensus_state", height] with its app hash and timestamp.
• Client settings: chain ID akashnet-2, trust level 1/3, trusting period at most 1,209,600 s (14 days, two thirds of the 21-day unbonding), unbonding 1,814,400 s, maximum clock drift measured before launch.
• The initial checkpoint is chosen in a ceremony: at least three people fetch a post-upgrade header, commit and validator set from at least three independent nodes and compare the block hash, app hash and validator hash.
• The client expires if no header is verified within the trusting period, and freezes on misbehaviour. A frozen or expired client cannot be recovered. The AKT program re-pins to a new deployment instead.
• The access manager’s RELAYER_ROLE controls header uploads, updates, misbehaviour and pruning. With open relaying, anyone can do all of these except pruning.
• A full commit from 100 validators fits in one Solana transaction’s compute limit. One from 129 does not. For sets with more than 100 signatures, the relayer submits only enough signatures for a quorum and marks the rest absent. This supports sets of at least 150 validators.

Solana: AKT program

Anchor 0.32.1, legacy SPL Token.

Accounts

The mint policy has per_transfer_max, daily_mint_cap and up to 16 vaults, with 0 < per_transfer_max <= daily_mint_cap.

Instructions

mint_transfer

1. It must be a top-level instruction, and only ComputeBudget instructions may come before it in the transaction. This keeps the TransferResolved event visible to reporters. Minting must be enabled.
2. It checks that the pinned light client uses the expected program and PDAs, matches the chain ID, and is not frozen. The latest consensus state must be within the trusting period, with a timestamp no later than the clock plus the allowed drift. proof_height must have a stored consensus state at or below the latest height, and the record’s height must be between 1 and proof_height.
3. It builds the path ["sink", "transfer/{id}"] and the 77-byte value from the record, and calls verify_membership on the pinned client with the uploaded proof.
4. It checks the recipient. A nonzero on-curve key owned by the System Program passes, whether or not the account exists. So does a key in vaults. Executables, token-program accounts, the zero key and the mint-authority PDA never pass, even if listed. A recipient whose existing AKT token account has been reassigned to another owner does not pass.
5. If the recipient fails, it writes Voided / InvalidRecipient. Nothing is minted and no token account is created.
6. If the recipient passes, it checks amount <= per_transfer_max and that the day’s total stays within daily_mint_cap, creates the recipient’s associated token account if needed, mints amount and writes Minted.
7. It emits TransferResolved { id, proof_height, outcome }.

If a cap, pause, light-client error or invalid proof causes the transaction to fail, nothing is written and the record can be retried.

void_transfer proves void/{id} equals [1, id] with the same light-client checks and writes Voided / Governance. It works while minting is paused and fails if the record already has a status.

Mint and void create the same TransferStatus account, so each record ID is resolved once: minted or voided, never both. A status cannot be closed or reset, including through re-pinning.

Daily cap. Days are fixed UTC days on the Solana clock, not a rolling 24 hours, so up to twice the cap can mint within 24 hours around midnight. Vault recipients are subject to the same caps. This is the per-epoch mint cap in proposal 346, with the UTC day as the epoch.

Events

A multisig calls the admin instructions through CPI, so monitors must read events by invocation frame. Anchor’s TypeScript EventParser skips events logged inside a CPI.

Errors

AKT errors are 7000 to 7024. ICS07 errors start at 6000 and appear on the same instruction when a membership check fails, so the two ranges never overlap.

Authorities

The upgrade authorities are retained because repin_light_client and verifier fixes require them.

Transfer caps

The following limits apply to transfer amounts and counts across both chains. Raise caps on Solana first; lower them on Akash first. See “Changing caps” under Launch sequence.

Token

The mint address is published on akash.network, the GitHub org, and to Jupiter, CoinGecko, CoinMarketCap, Solscan and SolanaFM before the seed deposit is minted. Assume impostor AKT mints already exist.

SPL Token or Token-2022

Solana has two token programs. SPL Token (“legacy”) has a fixed feature set (mint, transfer, burn, approve, freeze) and keeps name and logo in a separate Metaplex account. Every wallet, DEX, aggregator, custodian, exchange and indexer on Solana supports it.

Token-2022 is a separate program with optional extensions fixed at mint creation: transfer fees, transfer hooks, confidential transfers, a permanent delegate, non-transferable tokens, default-frozen accounts and embedded metadata. Each integrator must add support for it separately.

Legacy SPL Token supports broad trading access on Solana and provides every feature this design needs. The choice is permanent. RENDER also uses legacy SPL Token. Token-2022 accounts cannot receive AKT from the bridge.

Off-chain services

These services have no authority over funds. Each is configured with endpoints and keys, and each can be run by multiple operators.

Costs: users pay the Akash transaction fee. Relayers pay Solana fees and rent: about 0.0035 SOL per mint, including the recipient’s token account and the status account; refundable proof-buffer rent; and about 0.0015 SOL per verified header until it is pruned. min_transfer should be well above the relayer’s cost.

Failure handling

Stuck transfers. A transfer that cannot be minted, for example because its amount is above a lowered Solana cap, is resolved in this order:

1. Governance passes MsgRequestVoid { id }.
2. Anyone proves the void order with void_transfer. If the transfer was already minted, this fails and reporters confirm the mint instead.
3. Reporters confirm the void, the challenge window passes, and MsgFinalizeRefund pays the sender.

The order is enforced by the protocol. Akash refunds only after reporters observe a permanent Voided status on Solana, and after that status exists the record can never be minted.

Guarantees

• Each record ID is resolved at most once on Solana: one mint or one void.
• A mint is always exactly the recorded amount to the recorded recipient.
• Akash refunds only a transfer confirmed as voided, only to its original sender, only once, and only after the challenge window.
• Locked AKT leaves x/sink only through MsgFinalizeRefund.

Supply accounting

Locking does not change Akash total supply, which stays the single source of truth.

Solana supply + SPL AKT burned on Solana = amounts of all Minted statuses on Solana
AKT locked behind those Minted records = Solana supply + SPL AKT burned on Solana

Mint confirmations reach Akash a few minutes after minting. The monitor therefore compares Akash records directly with Solana statuses without waiting for minted_amount. Any mismatch or violation of the x/sink bank equality triggers an alert and an immediate pause of Solana minting through the pause guardian key, as proposal 346 requires. The monitor also pages the on-call team, which can pause deposits on Akash.

Before the first mint, Solana supply is zero. AKT burned on Solana stays locked on Akash. A public endpoint publishes these figures so CoinGecko, CoinMarketCap and exchanges report the same numbers.

Launch sequence

Solana (first)

1. Generate fresh keypairs for the three programs and publish the reproducible build hashes.
2. Deploy with a one-time ceremony key. In one transaction, initialize the access manager, allow the multisig as its CPI caller, grant it admin and renounce the ceremony key’s admin.
3. Run initialize. Check 6 decimals, no freeze authority, the PDA mint authority and zero supply.
4. Move all three upgrade authorities to the multisig and retire the ceremony key.
5. Through the multisig, set the token metadata and the pause guardian. Publish the mint address.

Akash (later)

6. Pass a software-upgrade proposal that specifies how to handle any balance already at the sink address. The upgrade adds x/sink and leaves deposits off. The upgrade takes no AKT from OCL; the seed follows as an ordinary deposit.
7. Conduct the checkpoint ceremony at a post-upgrade height. Through the multisig, in one transaction, initialize the ICS07 client and run configure_bridge("akashnet-2", policy) with a per-transfer maximum and daily cap of at least 1,000,000 AKT and the treasury vault in vaults. Start the relayer immediately because the trusting period begins at the checkpoint. Open relaying or grant relayer roles.
8. Reporters run in preview mode against their own nodes. After several days without issues and completion of the two independent token and portal audits required by proposal 346, pass a governance proposal to set the reporters, threshold, challenge period, vault list (including the treasury vault) and minimum transfer. It sets max_transfer, solana_daily_mint_cap and daily_refund_cap to at least 1,000,000 AKT and sets enabled to true. This opens transfers: the token launch in proposal 346.
9. Seed: OCL sends MsgSink for 1,000,000 AKT to the treasury vault. The multisig runs set_bridge_enabled(true) and the relayer mints it. The policy for other deposits while these higher caps apply remains open (see Decisions).
10. After the seed mints, lower the per-transfer and daily caps on both chains to their launch values, as in “Changing caps” below. Fund the counter-asset and seed the pools.
11. Run canary transfers: a normal transfer, an invalid recipient (void, then refund after the challenge window), and a transfer at the cap. Check supply after each. Then raise the daily cap in steps.

Changing caps. Raise the Solana caps first, then the Akash caps, keeping daily_refund_cap at least max_transfer. To reduce caps, lower them on Akash first. Wait until every transfer above the new Solana caps has minted or been refunded, then lower the Solana caps. x/sink refuses to lower daily_refund_cap below the largest open transfer, so every open transfer stays refundable.

Initial liquidity

AKT OCL sends the 1,000,000 AKT seed through the bridge to the treasury vault once transfers open. Pools are seeded after it is minted, which requires the upgrade, audits and governance vote to be complete.

Phase transition

The launch phase ends when a later AEP moves emissions to Solana.

• Akash: set inflation to zero and disable BME minting.
• Solana: emissions need a new mint path in the AKT program, added by a program upgrade through the multisig and time lock after Akash governance approves it. The proof-based mint stays for as long as deposits stay open.
• Before Akash stops running as a Cosmos chain, governance directs the multisig to transfer its authority to the successor or permanently disable minting if deposits end.

AKT remains locked. A later AEP will determine what happens to the locked AKT, the Akash chain and residual balances.

Rationale

A light client for minting. Akash validators authorize mints, so there is no separate operator set to select, pay and rotate. Forging a mint requires more than a third of the trusted Akash stake. The ICS07 client from cosmos/ibc-contracts runs on Solana and verifies standard ICS23 proofs of any Akash store, so x/sink needs no IBC upgrade.

Reporters for outcomes. No Solana light client exists for Cosmos, so Akash cannot verify Solana state. Reporters can authorize refunds but cannot mint. Refunds are subject to the challenge window, veto and daily refund cap.

Voids. Solana cannot send Akash a verifiable message. A void is a permanent Solana status in the same account used to record a mint. A transfer therefore cannot have both outcomes. Akash refunds only after reporters observe that status. Once it exists, no one can mint the record, so a refund can never race a late mint. There is no refund on a timeout.

Locking, not burning. Burning would require minting refunds on Akash and would change Akash total supply with every transfer. Locking keeps Akash supply as the single source of truth, makes a refund a bank transfer, and leaves the fate of the locked AKT to governance.

A dedicated module. The marketplace escrow handles leases. The bridge requires immutable proof records, a void-order key, reporter voting and a refund path, which do not belong in the marketplace module.

A dedicated deposit message. Accepting plain sends to the module would mean handling every way funds can reach its address: IBC transfers, distribution withdrawals, authz and contracts. MsgSink is checked before fees are charged. The sink address remains blocked like other module accounts, and the memo is ignored.

The seed goes through the bridge. Every SPL AKT, including OCL’s 1,000,000 AKT seed, is minted against a proven x/sink record, so all supply is backed by proven deposits and every mint is verified by the light client. This delays liquidity: pools can be seeded only after the upgrade, the light-client checkpoint and the seed mint.

A daily cap, with per-transfer and per-sender limits. The Solana per-transfer and daily caps bound what a forged header or a verifier bug could mint. max_transfer keeps every deposit within one day’s mint cap and one day’s refund cap. Per-sender limits slow floods of small deposits that cost the relayer rent. When set, the daily amount limit caps one sender’s share of the daily cap. Absolute amounts in base units are simple to check on both chains. Fixed UTC days allow up to twice the cap within 24 hours around midnight; the design accepts this trade-off. A transfer waits until a UTC day has room for its whole amount. The relayer submits waiting records in ID order, so after each rollover the oldest is tried first. Anyone minting other records first can still delay it, and governance can void and refund a transfer that keeps waiting.

Permissionless mint, void and relaying. The system does not depend on a particular operator. Anyone with a valid proof can resolve a record, and open relaying allows any signer to keep the light client current. Re-pinning lets the program move to a light client run by others.

Validation on Solana as well as on Akash. Akash checks the address format and requires a wallet key or listed vault. Only Solana can see whether the destination is a token account, a program or a reassigned ATA, so the AKT program voids those and the sender gets a refund instead of losing the tokens.

Legacy SPL over Token-2022. See the Token section under Specification.

Backward Compatibility

Existing modules, messages and state remain unchanged. x/sink is new and is installed in a chain upgrade that adds its store. Any existing account at the sink address is converted to the module account, and its balance goes to the community pool. Balances, delegations, vesting, IBC channels and marketplace escrow are untouched. No IBC upgrade is needed. Wallets need the Amino registration of MsgSink to sign with Ledger. Exchanges and data providers see a new non-circulating category (AKT locked in x/sink) and a new circulating venue (Solana).

Test Cases

Reproducible build hashes are published with the final release commit, not in this AEP.

Security Considerations

A compromised upgrade authority poses the greatest risk because it can mint without limit. A time-locked multisig holds that authority, monitors track its actions, and guardians can pause both chains without waiting for the time lock.

Two independent audits of the token and portal code must be completed before transfers open, as proposal 346 requires. Their reports must be published within 30 days.

Operational considerations

Wallets. MsgSink is a normal Cosmos transaction, so Keplr, Leap and Ledger-backed accounts can sign it. Ledger signing uses its Amino registration. The portal connects the Solana wallet and uses its address as the destination. Manual address entry shows a warning because Solana addresses have no checksum. AKT on Osmosis or other IBC chains must return to Akash first. No SOL is needed to send a transfer.

Exchanges. Exchanges can move AKT from their Akash hot wallets to their Solana deposit addresses. SPL AKT deposits and withdrawals at exchanges close the arbitrage loop between exchanges and Solana DEXes. Exchange coordination begins before launch.

Canonical address. Before the seed deposit is minted, publish the mint address on akash.network and GitHub, obtain Jupiter verification, update the contract address on the existing CoinGecko and CoinMarketCap AKT pages, and claim the Solscan and SolanaFM pages. There is one official portal domain, announced through official Akash channels.

Incentives. None at launch. LP incentives are reviewed at 90 days.

Operators. Run at least one relayer; anyone can run additional relayers. Each reporter operates independently, using its own hosts, Akash and Solana nodes, and key. Alerts go to the on-call operator.

Monitoring. Track light-client age and frozen state, pending-transfer age, and transfers resolved on Solana but still pending on Akash. Monitor every void during its challenge window, reconcile supply, and check the bank equality. Track all authority and configuration changes on both chains, guardian and re-pin actions, relayer and reporter fee balances, reporter vote age, and cap usage above 80%.

Runbooks.

Decisions

Decided

Open

References

• AEP-79: Akash on Shared Security and its Chain Migration Program document set
• Akash governance proposal 346: Migrate the Akash Protocol to Solana
• cosmos/ibc-contracts, ICS07 Tendermint light client and access manager for Solana
• ICS-23 commitment proofs
• Solana SPL Token and Token-2022 documentation, Metaplex Token Metadata, Squads multisig, Noble CCTP
• AKT on Solana: Implementation Status (companion document)

Copyright

All content is licensed under Apache 2.0.