gno

gno copied to clipboard

Description

Upon creation of a Network Configs section within our docs, it is discovered that two networks (Staging + test3) both utilize the same chainID. Both networks operate independently of one another and are transactable/queryable, though they cannot both be added to Adena due to the conflicting chainIDs, which should be unique. See chainlist for examples.

Further, the Staging RPC address (http://staging.gno.land:36657) does not follow the other RPC conventions found to include the TLS protocol and rpc subdomain (eg, https://rpc.test3.gno.land/); we'll want to fix this so that all of the RPC addresses follow the same convention for consistency.

We have a draft PR removing the Staging RPC address from the Network Configs but if Staging is something we want to persist, then this PR should be changed and we should be removing test3 instead of Staging.

Additionally, since staging is being reset frequently, it is possible to set its chainID to say, staging.

@albttx can we work on setting the correct values for staging?

RPC address: rpc.staging.gno.land:443 Chain-ID: staging

I just check, i have access to the server, but it's not managed by me. (iirc: it's from @moul, a recognize tmux + emacs on the server)

Before doing anything, i would like to have confirmation from @moul that:

1. We decide to persist the staging (now that we have portal loop)
2. Plan to move it into my managed infrastructure, so i can monitor everything.