Solana Devnet to Mainnet: A Launch Handoff Checklist

A successful devnet rehearsal proves that a particular test worked under test conditions. It does not establish that a mainnet wallet is funded, that production configuration is correct, or that the same integrations accept the final token settings. Treat the transition as a reviewed release with explicit evidence.

The most useful handoff artifact is a compact launch manifest: the approved configuration, the people responsible, and the checks that permit the next step. It should be understandable to an operator who did not write the integration and to a reviewer who did not run the rehearsal.

Recreate the Plan, Not the Devnet State

Solana's cluster reference identifies devnet as a testing environment and mainnet as production. Devnet tokens are not production assets, and devnet may reset. Changing an RPC setting is not a transfer of a test mint into production.

Make separate records for test and production identifiers. Even if your tooling deliberately reuses a public address, verify initialization independently on each cluster. Never paste a devnet explorer link into the production announcement and assume readers will correct its network selector.

A rehearsal should produce a procedure and expected observations, not a bag of signed transactions waiting for launch day. The production execution needs its own funding, approvals, current transaction construction, and resulting receipts.

Freeze a Launch Manifest

Before requesting a mainnet signature, record these decisions:

• Network and selected token program.
• Token name, symbol, and approved metadata references.
• Decimals, human-readable initial supply, and exact raw supply.
• Fee-paying wallet and intended receiving wallet.
• Mint and freeze authority policy, including any planned removal.
• Required account funding, selected service options, and spending approval.
• Reviewer, operator, and person authorized to pause the launch.

For an integration, add the deployed application version, configuration revision, RPC provider, and expected result format. Keep credentials in the appropriate secret-management system, not inside the manifest. The manifest should identify configuration without becoming a copy of the environment file.

Use an explicit approval sentence such as: the reviewer approves this configuration for one production creation attempt. That is more precise than approved for launch, which can be misread as permission for repeated submissions or unrelated distribution work.

Turn the Rehearsal Into Acceptance Tests

Consider a fictional training application issuing 48000 tokens with two decimals. The raw initial quantity is 4800000. Its rehearsal should check that exact arithmetic, the destination wallet, the observed supply, and the intended authorities. It should also exercise rejection of a three-decimal input.

Run through one wallet rejection and one unresolved-submission scenario. Confirm that reopening the interface does not automatically create another mint. Save the expected support record for each case so the production operator knows what evidence to collect.

Then test the handoff itself: ask another team member to locate the mint, identify the receiving account, and explain which transaction created it. If they need private messages to reconstruct the receipt, improve the manifest before scheduling production. Operational clarity is part of the acceptance test.

Rebuild Production Transactions at Execution Time

Check the production network in the application, wallet, RPC configuration, and explorer. Confirm that the selected payer has enough SOL for the approved scope and a deliberate reserve. Do not rely on a devnet balance or a previously captured cost estimate.

The getLatestBlockhash documentation returns a recent blockhash and its last valid block height. For ordinary recent-blockhash transactions, obtain current validity context when constructing the production request. Preserve it with the attempt record instead of reusing a transaction from rehearsal.

Have the operator compare the final wallet review against the manifest. Unexpected recipients, authorities, or extra instructions are stop conditions. A difference should trigger investigation and renewed approval, not an assumption that production always looks a little different.

Verify Results Before Publishing

After the required confirmation level, inspect the resulting mint and recipient account. Solana's getTokenSupply reference provides supply and decimals for reconciliation. For the training example, compare the observed raw supply with 4800000 and the decimals with two; do not rely on a rounded display.

Treat any authority change as its own checkpoint. The authority documentation describes role changes and permanent removal. Confirm the actual current role state after the transaction rather than treating a selected checkbox as proof. Do not remove authority before resolving whether the approved issuance is complete.

The publication gate should require a verified mainnet mint, correct supply and recipient, expected authority state, and saved signatures. Keep the announcement draft unlinked until those checks pass. This prevents the public record from becoming the team's first source of truth.

Define Stop and Handoff Conditions

Pause on an unexplained configuration mismatch, insufficient evidence about an earlier attempt, an unexpected signer, or an unresolved transaction. A pause means stop new actions and reconcile state. It does not mean a successful on-chain creation can be undone like a website deployment.

The final handoff should include the approved manifest, production mint, receiving account, transaction signatures, verification time, known outstanding work, and a named owner for support. Keep distribution and external integration tasks visibly separate from completed creation.

For manual execution, use the TokenAnvil no-code app with this checklist beside the wallet review. For automation, verify current network and transaction capabilities in the developer portal before integrating them. The same release gates should apply regardless of who or what constructs the request.