My question is about transitioning from the test-network to the public network. I am curious about whether there is a standard procedure to follow, not only in terms of configuration, but also in terms of resetting databases and clearing out buckets, logs, etc.

Here is a more detailed description of my issue: I finally built Horizon and Stellar-core from source on Ubuntu 18.04 LTS, and successfully configured both for the test network. Since both instances were up and running on the test network yesterday, I decided to go to the next level and configure them for the public network today.

To switch to the public network, the stellar-core.cfg, or in other words the Stellar TOML file, has to be edited. One particularly important option is the NETWORK_PHRASE. The value for this option should be set to:

NETWORK_PHRASE="Public Global Stellar Network ; September 2015"

when connecting to the public network, and:

NETWORK_PHRASE="Test SDF Network ; September 2015"

when connecting to the test network. The same holds for the horizon.env file, which is Horizon's equivalent configuration file.

In addition to the above alterations to the stellar-core TOML file, specifying whether the stellar-core instance will be a validator, in addition to PEERS and QUORUM SET must be defined. In this case, these are unrelated to my issue, or at least so I suspect.

When I decided to start stellar core with a new configuration file specified for the public network with the following command:

$ stellar-core --conf public-config.cfg

My log provided the following:

GDMPG [default FATAL] Got an exception: NETWORK_PASSPHRASE "Public Global Stellar Network ; September 2015" does not match previous NETWORK_PASSPHRASE "Test SDF Network ; September 2015" [main.cpp:671]

I have tried to source the new configuration file and start without the --conf option, but at that point I am unable to connect to the Overlay.

What is the correct approach to solving this problem? Should I restart PostgreSQL, or is there an issue related to public-config.cfg? Are there some files generated from running the test-network instance that I have to delete? And if so, which files should I delete? I was skeptical towards these latter aspects since I tried deleting files manually before which made me have to re-build stellar-core from scratch again.

Many thanks for the help.


After re-configuring the stellar-core.cfg file, and creating a custom Quorum set, I keep experiencing problems with the Work and Overlay components, but I am no longer getting the above FATAL error.

It appears to be that my Stellar-core instance does not catch up / sync appropriately as it cannot retrieve get-remote-file history/01/1a/09/history-011a09ff.json.

Indeed, when I run Horizon, I am informed of:

WARN[0256] ingest: waiting for stellar-core sync pid=12899

Usually, this error would arise due to an erroneously specified History Archive. Yet, I have also run stellar-core --newhist ARCH and checked that the directories are in place.

Interestingly enough, the directories are made in rather counter-intuitive ways, but they still appear to be configured correctly according to the stellar-core INFO.

Given this exhaustive information, I am suspicious regarding whether the reason why I am unable to sync onto the Public network is because I have to be approved by other nodes. Is this correct?

EDIT 2 So, now I have updated the buckets directory by making a new directory called public-buckets, and re-initialized the database.

Also tried editing the KNOWN_PEERS section in config file. I understood the problem lies in the configuration after reviewing OverylayManagerImpl.cpp on: https://github.com/stellar/stellar-core/blob/master/src/overlay/OverlayManagerImpl.cpp

Will update once I get it working :) `

  • 2
    stellar-core --newdb should help. Commented Jun 8, 2018 at 19:58
  • Keep getting the same error unfortunately, even after running the --newdb command. Commented Jun 18, 2018 at 8:40

1 Answer 1


The recommended way to switch between networks is to not reuse directories and/or archives (unless you can guarantee that you can delete all data). This particular error ... does not match previous NETWORK_PASSPHRASE ... will be cleared after running newdb as that command drops all tables in the database.

As for your later question, there is no vetting process to join the network: anybody can watch the network, and once you have a node up and running you can ask other people to trust your validator but this is a different problem.

  • Thanks @MonsieurNicolas. Good to know approval is not required, because then it simply means that the issue lies in the configuration. As the first problem is overcome, I suspect that a major part of the problem comes from the way the history archives are specified. I will post an edit for this. Commented Jun 20, 2018 at 6:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.