Before launching a testnet, make sure you have the following items sorted out
What are you trying to achieve with this testnet and how do you measure success? Are you testing for vulnerabilities? For UX? Enabling developers to try out your platform? Onboarding your validators? Make sure you have these explicitly listed. Without a set of goals you won’t be able to measure the outcome of your plans.
Based on these goals, you can define a set of actions, test cases, and incentives (if at all) for users and validators to perform during testnet. See this example from Evmos.
Make sure to plan our your testnets well in advance. Each testnet should have its clear purpose and focus.
Get something running and fix basic issues.
First batch of external feedback with selected parties.
Contributions based? Uptime?
Public testnet to make final tweaks.
Are you planning to incentivize the testnet, and if so, why? When poorly designed, Incentivized testnets can attract unwanted attention from inexperienced users that require a lot of support to onboard. Consider incentivizing not for just validating, but for finding bugs, breaking the protocol, but also marketing & education, etc. Anything that requires talent and contributes to the health and success of the network.
Depending on your jurisdiction, it might be necessary to established processes to perform KYC and AML for the incentivized testnet.
Read more about incentivized testnets in our chapter about Validator Bootstrapping.
Mainnet Validation Plan
Determine heuristics and checklist to determine suitable validators for the mainnet launch, especially if you’re considering doing a soft launch. For example:
- Distribution across multiple regions and providers
- Active participants in governance
- Spec requirements if you need high block speeds or you’re running oracles.
- Internal developer review
- Third-party review. The Builders Program can help you connect to our network of auditors, please just shoot us a message if you an intro!
- Bug bounties during testnet
Community & Validators
Define the relevant instructions on how to become a validator on testnet. The better your docs are, the less questions you’ll be getting from your users.
Make sure to have setup a Discord or some other form of live communication, as well as an mailing list to make sure everyone is up to date. It’s recommended to create a private channel for validators so that you can coordinate directly in case of critical events such as security incidents or chain halts. To verify validators, the Cosmos Hub asks them to send an email with Discord handles from their publicly listed domain. Other methods include sending a transaction with a custom memo, but this can be a rather cumbersome process.
Make sure to have a testnet marketing plan that’s aligned with the goals you stated at the beginning of this process. Especially if you’re incentivizing the testnet you have to make sure you know how to reach out to your exact target group. We can provide feedback on the general strategy if needed, and potentially audit and review promotional materials such as videos, guides, graphics and advertisements if you’re a Builders Program participant, as well as share the content in our validator network if you’re looking for more participation.
Create a faucet for testnet users and validators to obtain tokens. Ideally this is done without CLI and through some existing user interface (Discord / Telegram) or a custom web interface. Some examples:
- Cosmos Hub’s Discord Faucet - by Hypha Coop
- Tendermint’s Faucet - by Tendermint
- CosmWasm Testnet Faucet - by Confio
Disaster Recovery Process
In the case of a chain halt, you will need to coordinate the release of new binaries and potentially ask the validators to halt the chain manually. This is why setting up a private communication channel before launch is essential. It’s highly recommended that you define this process, clearly map out who’s responsible for what, and test it out at least once during testnet.
You can find detailed instructions on how to deal with a chain halt here [TBA].
Create Upgrade Process
Make sure to have an upgrade planning. A lot can go wrong in upgrades, especially if you have validators on board that are less experienced. Running an upgrade during testnet can be a highly informative experience and prepare you for mainnet upgrades. Most importantly make sure you have solid validator coordination, great docs, and learn what hiccups you have in testnet to improve your process iteratively all the way to mainnet.
If you’d like, before launch, we can help audit documentation for Builders Program participants and go through the steps suggested to run and interact with a node in order to enable users to participate in the network.
Ideally you have an initial version of a block explorer so that users can understand how the chain performs, follow transactions, and more. A few open source examples you can use:
- Big Dipper by Forbole
Tracking Testnet activity
Make sure you have a way to query your testnet to determine what addresses performed what (in case of an incentivized testnet) but also to understand overall performance. We recommend indexing your data or having a 3rd party do so.
Again, this depends what you’re trying to achieve with an incentivized testnet. What does it mean to test software, to test bugs. To get the data you’re looking for:
- Numia can help to index & get data. They can contribute a lot in helping you figure out which data is going to be relevant to your network. They provide valuable insights when it comes to user engagement, retention rate, etc. Please reach out to us and we’d be happy to connect you!
- If you’d like to try it yourself, you can use a Postgres indexer or ts-indexer for example. If you’re a Builders Program participant and have specific questions about best practices, please let us know through our previously established communication channels and we’d be happy to help guide you.