The testnet is a small test Kuknos network, run by the Kuknos Development
Foundation (KDF), which is open to developers.

KDF runs 3 Kuknos Core validators on the testnet.

You can connect a node to the testnet by configuring kuknos-core to use this

There is also a Horizon instance that
can directly interact with the testnet.

What is the Kuknos testnet good for?

  • Creating test accounts (with funding thanks to Friendbot).
  • Developing applications and exploring tutorials on Kuknos without the
    potential to lose any valuable assets.
  • Testing existing applications against new releases or release candidates of
    Kuknos Core and Horizon.
  • Performing data analysis on a smaller, non-trivial data set compared to the public network.

What is the Kuknos testnet not good for?

  • Load and stress testing.
  • High availability test infrastructure – SDF makes no guarantees about the
    availability of the testnet.
  • Long term storage of data on the network – the network is ephemeral, and resets periodically.
  • A testing infrastructure that requires more control over the test environment,
    such as:

    • The ability to control the data reset frequency.
    • The need to secure private or sensitive data (before launching on the public network)

Keep in mind that you can always run your own test network for use cases that
don’t work well with SDF’s testnet.

Best Practices For Using Testnet

Surge Pricing on the Testnet

The testnet has a capacity limit of ۱۰۰ operations per ledger. When more than 100 operations are submitted to a given ledger, the network enters surge pricing mode, which uses market dynamics to decide which submissions are included. It works exactly the same way as surge pricing on the public network.

If you are having trouble submitting transactions to the testnet, you may need to offer a higher fee. You can also take the opportunity to develop a fee strategy, which may prove useful when you move your project into production.

Periodic Reset of Testnet Data

In order to preserve a good experience for developers, the SDF testnet is
periodically reset to the genesis (initial) ledger. Resets declutter the network, remove
spam, minimize the time required to catch up to the latest ledger, and help
maintain the system over time.

A reset clears all ledger entries (such as accounts, trustlines, offers,
etc), transactions, and historical data from both Kuknos Core and
Horizon, which is why developers should not rely on the persistence of any accounts or on the state of any balances when using testnet.

After a reset, you will need to take a few steps to re-join and re-synch to the testnet. Those steps are outlined here, along with line-by-line instructions for people using core + horizon ubuntu packages. If you need help with other packages, check Kuknos’s Stack Exchange for guidance.

SDF will try to make testnet resets as painless as possible, and will announce the exact date at least two weeks in advance on the Kuknos Dashboard, and via several of Kuknos’s online developer communities.

The testnet resets once per quarter (every three months). The 2020 dates:

  • ۱/۲۹/۲۰
  • ۴/۲۹/۲۰
  • ۷/۲۹/۲۰
  • ۱۰/۲۸/۲۰

The testnet will always restart on the announced reset date at 0900 UTC.

Test Data Automation

Since most applications rely on data being present to do anything useful, it is
highly recommended that you have testing infrastructure that can repopulate
testnet with useful data after a reset. Not only will this make testing more
reliable, but it will also help you scale out your testing infrastructure to
a private test network if you choose to do so.

For example, you may want to:

  • Generate issuers of assets for testing the development of a wallet.
  • Generate orders on the order book (both current and historical) for testing
    the development of a trading client.

As a maintainer of an application, you will want to think about creating a data
set that is representative enough to test your primary use cases, and allow for
robust testing even when testnet is not available.

A script can automate this entire process by creating an account with
, and submitting a set of
transactions that are predefined as a part of
your testing infrastructure.