I’ve got a 1GB Up/Down link on mine. I doubt bandwidth is the issue.
yeah 1GB is a lot.
thats very fast! congrats! there were just some checks that needed to be made before setting up the validator, but i doubt you will have any issues, but could you help me run some commands? refresh the gitbook and under the setting up validator there are 2 checks
It should look something like this
curl -s 127.0.0.1:26657/status | jq ‘.result.validator_info.pub_key’
cat .fxcore/config/priv_validator_key.json| jq .pub_key
Congrats! Nice seeing a public validator so fast.
1 Like
also have you created a node monitoring? it should be set up in a different server from your validator node
Will the Validator sub page have a extra column to show “Uptime”? Like the other explorers, so new / old holders can see which validator are up majority of the time.
Also to safeguard people’s funds since nobody likes to get slashed. It will also make sure the validators are ensuring the software/hardware is running smoothly with regular checks.
Since priority is the safety of community’s fund.
An example is Cosmos Explorer.
please delete it from here. dont show it. actually its fine but yea just make sure those pair of values are the same
Not yet … planning to do that in the coming days.
Monitoring and alerting.
Sentry Node architecture.
A dedicated website with my validator metrics.
Wanted to become the first public validator … so did everthing fast.
lol … yeah I just pasted because they are public keys. But yeah those are not fine too.
Have a different question.
Can I deligate 100k fx from a different address. I am thinking about this as an extra layer of security for my 100K.
haha good good. im proud of you!
yes you can. but it will be considered “self-delegated”. "self-delegated needs to be from that token holding address that you have bonded to your validator. it is a 1-1 mapping that cant be changed
Got it.
I dont see any company validator or institutional validator self deligating 100k … was that intentional?
If I dont self deligate … will my validator be jailed ?
Currently planning to deligate from a different address to get some voting power.
Quick question for you Richard. We are planning to setup backup nodes incase we get downtime on one of our nodes but to avoid double signing the same block I won’t be running the same PRIV key on the backup node.
I just wanted to clarify procedure with you and make sure this wouldn’t get my node jailed.
The idea is that if my main node drops my monitor node will also have a full node all synced and ready to go. If I just paste the PRIV key into the backup node. Will my backup node seamlessly take over or are there any risks involved other than making sure your main node doesn’t come back on while back up is running?
I just want to make sure we are never down for long enough to be slashed. This will be a good security measure to help protect ours and our delegators investment.
1 Like
@Richard
Not sure if this is bug but the validator description and site on the explorer is not showing the supplied values.
I did try editing the details one more time using edit-validator command.
I saw your create validator tx hash. The fields are correct. It’s an explorer issue. So not to worry about your validator. We’re currently fixing the issue now.
As for the 100fx as mentioned earlier, 100fx is the Min self-delegation. The reason why your validator showed 0 voting power on the explorer is because past a certain decimal place, it doesn’t show so that too is nothing to worry about too. Your validator voting power should be non-zero once you’ve fulfilled those requirements
1 Like
This is a great contingency plan! But just to avoid any kind of issues, here are some of my suggestions or notes:
- Always make sure you don’t have both instances with the same validator keys running at the same time. Make sure the other is completely shutdown before booting the other.
- You may refer to here for more best practices
- Do a dry run to cover all your corner cases on the testnet