The program around that state needs two instructions: a funding instruction that locks the tokens and a claim instruction that releases only what time has unlocked.

create_new_vest: validate the schedule before writing it: amounts above zero, start_timestamp before end_timestamp, and a recipient that matches the exported Cosmos data. Initialize the schedule PDA from stable seeds such as [b"vesting", recipient], store the bump, set claimed_amount to zero, and transfer the full allocation into a vault owned by the program's PDA authority in the same transaction, so a schedule can never exist unfunded.
claim_vest: require the claimant to sign and match schedule.recipient, read the current time from the Clock sysvar, and compute the vested amount with checked math: linear interpolation between the timestamps, plus whatever cliff rules you exported. Pay out vested - claimed_amount, update claimed_amount before transferring from the vault via the PDA signer, and reject claims where nothing new has vested.

You do not have to design this from scratch. The Solana developer bootcamp's token-vesting project is a buildable Anchor program with exactly this instruction shape (create the schedule accounts, then a Clock-driven claim with cliff handling), and Bonfida's token-vesting program is a Kudelski-audited implementation deployed on mainnet. If your exported schedules are standard cliff-plus-linear shapes, also consider loading them into an existing vesting product such as Jupiter Lock or Streamflow instead of operating a custom program.

NFT migration

CW721 metadata is closer to Solana's than it looks. A CW721 token points at off-chain JSON through token_uri (or stores the same fields on-chain in its metadata extension), and those fields follow the OpenSea-style standard. Metaplex JSON shares the core fields, so name, description, image, animation_url, external_url, and attributes usually carry over unchanged; a well-formed existing token_uri can often be reused as-is.

Map the differences deliberately: Metaplex JSON also expects a category and a properties.files array with a URI and MIME type per file; royalty configuration moves out of the JSON into onchain royalty settings such as the Metaplex Core Royalties Plugin; and CW721-only fields like background_color and youtube_url have no direct equivalent. Re-host any metadata or media you do not control on durable storage before the source chain halts.

Pick the Solana NFT or digital-asset standard before writing claim logic. For large collections, Bubblegum compressed NFTs keep mass minting affordable (on the order of 5 SOL all-in for a million assets), but wallets and marketplaces read them through DAS-API indexers rather than plain account fetches, so confirm your target tooling supports them first.
Preserve provenance and identifiers intentionally where external integrations depend on them.
Distribute with the same Merkle pattern as the token claimer: snapshot CW721 ownership as {contract, token_id, owner, solana_address} leaves, publish the root, and let each owner claim a mint of the corresponding Solana asset (for compressed assets, the claim instruction mints via CPI into Bubblegum).

DeFi positions

Liquidity positions: snapshot LP balances and the asset ratios you need to honor at migration time. Decide whether users receive migrated LP positions, underlying assets, or a fresh liquidity program entry on Solana.

Lending and borrowing: snapshot collateral, liabilities, and risk state. Resolve bad debt and policy exceptions before migration so you do not import insolvency into a new environment.

Delegation and rewards: define how staking, pending unbonding, and accrued rewards map into the Solana-side product.

What usually does not migrate 1:1

Validator operations: your app no longer owns a dedicated validator set after the move.
IBC channels and client state: these need a new cross-chain integration plan rather than a literal port.
Module internals: Cosmos module parameters and store layouts rarely map cleanly into Solana account layouts.
Indexer assumptions: dashboards and support tooling usually need a new read model built around Solana accounts and logs.

Solana constraints to plan around

Programs are stateless: durable migration data must live in accounts, not inside the executable.
Account allocation has cost: account sizing, rent, and resize strategy affect both migration design and user experience.
Transaction envelopes are bounded: large claims, proof payloads, or fan-out jobs may need to be chunked across multiple instructions or batches.
Compute per transaction is finite: expensive verification or multi-program flows need budgeting and profiling before production rollout.
Operational jobs must be restartable: large migrations should assume retries, partial completion, and resumable execution.
Read models often move off-chain: dashboards, audits, and support tools usually depend on indexed account data rather than on-chain query entrypoints.

Explore the map

How it works

Sign in with X

Pick your people

Find your mutuals