BetaNet requires a reset of previously running nodes

In order to test some new features, we had to perform a network realignment. Unfortunately, this may cause an issue if you were running a node on BetaNet. Due to these changes, you will need to reset your node in order to re-join the network. We apologize for the inconvenience!

Thanks, was wondering what was up.

Does reset mean stop and restart? ./ doesn’t find a new version and the chain has been at block 3000000 for 70 hours according to algoexplorer. My restarted node is still at block 3000000 as well.

Hi @Stephen, we are waiting for official confirmation to reset AlgoExplorer.


@Stephen, you’ll need to stop the node, delete the data directory ( or at least the betanet-v1.0 sub-directory ), and start it again. It will catchup, and when done, it will be able to pass the 3M round.

I know that it is painful ( for all of us ), but unfortunately had to be done.

Thanks!. As of late last night a new clean node wasn’t pulling any blocks.

I created a from-scratch betanet instance using the directions (-c beta, …)

Changing dns config entry… and when all is said and done - and it’s fully synced. it’s still just a devnet instance. I haven’t really found any clear documentation on the different networks.

Diffing the genesisfiles directories shows basically no difference:

diff genesisfiles/devnet/genesis.json genesisfiles/betanet/genesis.json
    <   "network": "devnet",
      "network": "betanet",
    <   "timestamp": 1560210489
    < }
      "timestamp": 1564572341

The dev instructions at say to change the network to from… all this means is that in the end… I just ended up creating another copy of a devnet node. ?

I don’t recall seeing this dns change for betanet before. These instructions are from the link aojjaz posted. Is this correct? I think there are some inconsistencies in the instructions depending on the page you land on.

DNS Configuration for betanet¶
For the betanet network, when installing a new node or relay, make the following modification to the config.json file located in the node’s data directory. First, if there is not a config.json, make a copy of the config.json.example file.

cp config.json.example config.json
Then edit the config.json file and replace the line

“DNSBootstrapID”: “”,

“DNSBootstrapID”: “”,
This modification to the DNSBootstrapID is only required for the betanet network.

After fooling around with this more I guess I had forgotten about moving and editing the config.json file. After deleting the betanetdata directory and following the instructions I’m now syncing:

➜ node ./goal node status -d ~/node/betanetdata
Last committed block: 3602
Time since last block: 0.0s
Sync Time: 94.6s
Last consensus protocol:
Next consensus protocol:
Round for next consensus protocol: 3603
Next consensus protocol supported: true
Genesis ID: betanet-v1.0
Genesis hash: mFgazF+2uRS1tMiL9dsj01hJGySEmPN28B/TjjvpVW0=


I’m happy to hear that you’ve figured out the configuration issue.
( btw : that’s why I said “delete the betanet-v1.0 subdirectory”, as it would have retained the configuration file changes ).

regardless, there is a ticket for fixing this so that the config file would not need to be modified for the betanet, but it wasn’t handled yet.

Any idea on me setting up a from-scratch betanet install following the instructions and it just becoming a devnet setup?

Hi @tsachi, we stopped the node and deleted the subdirectory only “betanet-v1.0”. After the restart, we currently see:

user@betanet:~/node$ ./goal node status -d betanetdata/
Last committed block: 3000000
Time since last block: 443628.7s
Sync Time: 86.4s
Last consensus protocol:
Next consensus protocol:
Round for next consensus protocol: 3000001
Next consensus protocol supported: true
Genesis ID: betanet-v1.0
Genesis hash: 

Is this normal? How can we confirm that it is actually trying to catch up?


Could you please verify that you shut down the node before deleting the betanet-v1.0 subdirectory ?
Looking on the output you’ve posted, it looks as if your node has not been moving forward for 123 hours ( 443628 seconds ).

The network field in the genesis file is sufficient to render the two genesis files apart.
It’s true that the betanet and devnet shares some of the same genesis accounts, but that’s about where the similarity ends.
As long as you have the correct genesis.json file in the data directory, the corresponding network should be “joined”. If that’s not the case, please let me know.

Both my devnet and from-scratch (following the directions) setup for betanet show devnet as the genesis id when I run goal node status.

I think that it is not properly stopped as it shows:
user@betanet:~/node$ ./goal node stop -d betanetdata/
Cannot kill node: operation not permitted
user@betanet:~/node$ ./goal node start -d betanetdata/
Algorand node was already started!
Algorand node successfully started!

Should we uninstall and reinstall?

Could you try and figure out which use the algod process is run as ?
if it’s not the same as the logged on user, that could explain the “operation not permitted”.

maybe sudo ./goal node stop -d betanetdata/ would do the trick ?

It was root, so I used sudo ./goal node stop -d betanetdata and we managed to stop it! We started it again with sudo ./goal node start -d betanetdata and it is now counting from 0 (and increasing).

Thank you for the help!

Nope - I followed the directions to the letter multiple times and beta always just becomes devnet…
So, I extract the downloader to a dummy directory and run:

./ -i -c beta -p ~/node-beta -d ~/node-beta/data/ -n
Current Version = 0
Latest Version = 8589934605
New version found
Checking for files matching: 'channel/beta/node_beta_darwin-amd64_' in bucket algorand-releases
Update Downloaded to /var/folders/k8/xxxxx/T/tmp.TnvFiG7p/8589934605.tar.gz
Expanding update...
Validating update...
Starting the new update script to complete the installation...
... Resuming installation from the latest update script
Current Version = 0
Stopping node...
... node not running
Backing up current binary files...
Backing up current data files from /Users/xxx/node-beta/data...
Installing new binary files...
Installing new data files into /Users/xxx/node-beta/data...
Copying genesis files locally
Checking for new ledger in /Users/xxx/node-beta/data
Cannot read genesis file /Users/xxx/node-beta/data/genesis.json: open /Users/xxx/node-beta/data/genesis.json: no such file or directory
Updating genesis files for default network
New genesis ID, resetting wallets
New Ledger - restoring genesis accounts in /Users/xxx/node-beta/data
New Ledger - importing rootkeys for genesis accounts
Imported 0 keys
Applying migration fixups...
Deleting existing log files in /Users/xxx/node-beta/data
Install complete - restart node manually

switch to ~/node-beta

./goal -v
2.0.13.beta [rel/beta] (commit #5df2b13a)
go-algorand is licensed with AGPLv3.0
source code available at

Examining data/genesis.json… network in genesis.json is… devnet
data/ contains devnet-v1.0 subdirectory, not betanet.
Changing the dns entry in config.json to algodev, etc. and starting the node. Works fine, but in the end, it’s just a devnet instance.

Where can I find a description what the difference even is between devnet and betanet. They appear to be one and the same.

You need to specify -g betanet when running ./ For a detailed tutorial, see