When launching a mainnet, the process is very similar to launching a testnet, although there are a few specific items to consider.
Hard Launch v.s. Soft Launch
A hard launch is a mainnet launch where everything is full speed from block 0. All validators are encouraged to join, all features are enabled and the launch is a highly public event with all eyes on the protocol.
This is how a lot of chains have launched. It can be a great tactic to get a lot of publicity in a small time window. However, some chains have also run into various issues during their mainnet launch which were not found during testnet. In case you run into a significant problem like a chain halt, the public sentiment can be harsh and impactful and it might take quite a bit of work to fix your reputation.
The Soft Launch
In a soft launch, chains go to mainnet a couple days or weeks prior to the big announcement. You generally just invite a select few validators to join that you have good communication channels with. This could also be a group of operators that were part of your incentivized testnet if you ran one, or perhaps the group that was part of your validator funding round.
Although the chain remains permissionless and other validators are free to join, having less eyes on the soft launch allows you to test your protocol in production without potentially disappointing your entire audience. In case you do run into any issues, you’re able to resolve them fairly quickly without much public attention and user assets at risk.
There are two things you should consider doing for a soft launch:
- Disable Inflation to make sure the group of validators don’t unfairly earn rewards before anyone else does
- Disable IBC token transfers to prevent liquidity pools from being created on DEXes
Disabling is done through the parameters of each module.
Enabling the above features on the public launch date can be done in several ways:
- Governance: you can simply publish a param change proposal to enable your features. Just keep in mind this will take a while. An easy workaround would be to enable 1 or 2-day proposals at genesis, as you often see on testnets. Make sure to update the gov params as well.
- Authz: you can have a multisig authorized to execute param changes on behalf of governance. At the public launch date you can have the governance module address revoke the authorization as well so that every future proposal needs to go through the community. We do not recommend this option due to the negative impact it might have on sufficient decentralization.
Node Availability
Please make sure you have enough public endpoints available so that:
- Node operators can sync using
state_sync
& fill their address book with the right seeds
- Your self-run explorer has nodes to index the chain until you’ve been integrated into public explorers
- Users can query chain data during the early stages of the network
Publish these endpoints online in your documentation and make sure your community team has template responses ready as there will be many operators and users requesting them on Discord and other channels.
Unless you have a front-end that requires access to chain data, you will likely not have to keep running these nodes in the long term. The assumption is that the community will continue this work moving forward.
If you are running a purely back-end service and you do not require nodes to run your dApp, you’re best advised to hire another team to run the nodes on your behalf for a limited time span instead of hiring a full-time devops person. You’ll likely find that some of the validators that have been part of your testnet are excited to provide this service for a fee.
Wallet Support
If your chain is a end-user facing dApp that’s dependent on using wallets, make sure you either have your own wallet, or that you’ve been integrated into the most popular ones like Keplr and Cosmostation. If your chain is dependent on staking, wallet integration is vital, unless you build out your own user interface.
In case you haven’t been able to get an integration, Keplr allows you to prompt users to add your network to their web extension through their
experimentalSuggestChain
feature. Documentation can be found here. Make sure you have a solid RPC endpoint available so users won’t run into issues.