@Richard what do you mean by “Reduce the tax and fee ratio of the community pool” ?
If you refer to this part of the document, before fees are distributed, there is a 40% tax applied and this will go to the community fund. this fund will be used for community upgrades/proposals…
And 1 question .
When validator is slashed or jailed or down, or whatever, my initial delegated coins are save right?
And i can, at any time, access my delegated coins?
That there are no rewards build up in that downtime is clear, thats my own calculated risk.
you may refer to this part of the document for more clarity @SCENE . But essentially your original stake will be subjected to slashing conditions, not your rewards. With regards to redelegation and unbonding, the same rules apply.
@cop4200 will take note of the insurance suggestion. there are many different ways that we could design this and very good thinking!
Hmm but according to yesterday’s AMA at 14:00min - if the validator gets jailed, the delegator won’t be able to redelegate although this is for double signing i think.
Also it’s good to note that the current ~30% APY isn’t coming from validator’s transactions (as there are not many transactions going on), but from FX yearly distribution pool. So even if the validator goes offline for 24h, you’re still going to get most from your daily APY (minus fees from transactions which didn’t happen). Jail for validator happens after ~27.7hours of being offline. So you’ve plenty of time to redelegate. However you won’t know if the validator is offline, as it’s going to show still Active on the Explorer for the first few hours (as there is no Uptime).
In general your funds are safe at the smart contract address, not at the validator’s place, so they can’t run away with it.
Question is, whether the slashing will happen after redelegation during vesting even after you redelegated or not. In my opinion, it won’t slash you, if you redelegate within the first ~27.7h when validator goes offline (before it gets jailed).
@Richard if team is implementing performance metrics tracking, then having a sort option for the list of active validators will be helpful (i.e ability to sort list by commission rate, uptime , insurance pool size etc)
Hmm but according to yesterday’s AMA at 14:00min - if the validator gets jailed, the delegator won’t be able to redelegate although this is for double signing i think.
@SCENE my bad. you can actually redelegate if the validator is in jail. i was thinking about something else with regards to unbonding not redelegating…if a validator is INACTIVE and NOT JAILED then you can unbond anytime without suffering the 21 day lock out period. more information can be found here: What are the different states a validator can be in
I think there’s no need to complicate. is just make only the validator can be slash. not delegators
actually delegators for that particular validator will also get slashed. if you vote in a lousy government, and that government makes really bad policies. the entire country suffers. government (validator) and citizens (delegators) included. You may refer to the updated What are the slashing conditions document and How will delegators choose their validators? Reason being delegators should do their due diligence and choose a validator with good uptime and behaves honestly, if not they too will suffer the consequences.
@Richard if team is implementing performance metrics tracking, then having a sort option for the list of active validators will be helpful (i.e ability to sort list by commission rate, uptime , insurance pool size etc)
@cop4200@FrenchXCore Actually you can also do your own checks on other validator’s uptime for now through the CLI, you may check the commands here: Checking block information and validators signatures you may run these commands and check the signatures. you may consider writing a script for it to check who has signed or hasn’t and you can deduce which validator has missed a block. And agreed to your suggestion. I have already added most of your suggestions into the product pipeline. Some others will require governance voting. I will keep you guys updated and maybe even consider creating more transparency with regards to pipeline and deliverable.
Hi everyone, was thinking of opening up a product pipeline board for f(x)core related upgrades/issues so it would be easy for everyone here to keep track of updates as well as being kept up to date with deliverables. Do you have any recommendations or suggestions for this? Especially with regards to what platform to use so that it is easily accessible to the public (does not require any login credentials)? Would like to hear your suggestions and feedback on this.
That would be an awesome idea. Like a living roadmap.
Maybe it can be added to the functionX website, since it’s kind of a roadmap. Than that’s a link that can be shared throughout the social media canals.
And I’m curious how expectations will be managed, because it’s obviously that people see work that will be done and stick the team to certain progress. Would be carefull to not get people burn the team down because they’re not spot on with closing story cards.
If it’s just to create a visibility of what has happened and what is going to happen than it wouldn’t be an issue, but if dates will be used it can be a trigger for FUD.
Just a point to note for validators here, we will be increasing the commission rate for all internal validators to 5%. This will hopefully result in some redistribution of funds.
But also lets help ourselves in giving delegators a vote of confidence by
Increasing your self-delegation amount for eg. like Alif who has 10,210FX self delegated @l4zyboi@cop4200
Being proactive in the community, helping others and showcasing their work like @ClaudioxBarros@kenorb and this clearly shows their capabilities in programming and running a validator node
Being transparent with their validator’s actions, notifying the public way in advance for any increase in commission rate like @FrenchXCore
These are just some initiatives taken by some of the validators. Let us think out of the box and strive to build a more cohesive, secure and decentralized community and network.
These are all good points.
I redelegated my fx to public validators from day one pure based on trust and “knowing” the validator(s) of my choice by name and community activity and testnet experience.
For some that maybe sound a little naive.
But so far so good .
Besides the transparant communication, which i find realy important, another thing is the hardware and security side of the validator nodes.
Don’t read much about that.
It maybe a little technical, and i don’t have to understand the technical aspect of a node completely, but it’s an important thing and gives trust to delegators.
Would like to read more about that.
Like f.e. @ClaudioxBarros does in validator description and website.
That, combined with uptime are for me important things.
(Low) commission rate is nice, but
Stability and security and insight in uptime are way more important to me.
Btw, rhe self-delegation amount seems low to me in most validator nodes.
Is that amount ment for some sort of security amount to show delegators your dedication to run a node?
hardware : currently, any minimal hardware can support a validator (I started with a simple Raspberry Pi 4 and Raid-1 SSDs). It doesn’t need much power, but it requires HD space (100 GB for now) and a min of 2 1.8GHz cores. What’s important, is database corruption due to potential electrical shutdowns and inter-net disconnections.
sentry nodes : setting up sentry nodes prevents from DDOS attacks (and other related-cyber attacks) by making your validator unaccessible from the internet but only from internet-connected sentry nodes. I doubt a DDOS attack would focus on a specific-node for more than 24-hours (19k blocks disconnection is required for the validator to be slashed by 0.1% and jailed). It would leave too much time to setup a twin-validator on another IP address, and hackers wouldn’t gain much (beside eventually stealing the self-bonded FX only). I don’t think this case really matters much for now, especially since the network is just starting.
self-bonding (current and minimum) : again self-bonding doesn’t offer any warranty to users, it just means the validator is ready to loose this part in case of slash (downtime=0.1% or double-sign=5%). Also, increasing the self-bonding is one thing, but setting its minimum to that amount means the validator intends to keep it at that level. That second part is also very important.
downtime : what the downtime really impacts is that validator might be eligible for a block but wouldn’t respond, so wouldn’t get the block’s commission fee. In fact, downtime impacts only the validator’s owner as long as there is always at least 1k contiguous blocks signed by a validator every 20k blocks.
So, from what I can check on the FxCore blockchain, all validators seem to act fair and properly. Some have some more missed blocks than others, but then again, it just impacts the validator’s owner at that level.
My conclusion is that we should do the best we can to share around us and monitor the network.
For your information, I set up a Telegram bot to monitor all validators : @frenchxcore1monitorbot
And I’m also finalizing the code of a much-more advanced SDK to be able to interact with FxCore nodes and produce automatic reports.
true. i know my “ecosystem” is very oversized, but thats how i do stuff, i always do the better and best i can. But the most important is the security. and that is not directly connected with the “size” of hardware .
I use to say, the time wast to do something wrong is the same time to do it well.
So is always better to do it for the worst scenario
Just wish to know more about programming like Mdmdmd83, Kenorb or alif or more free time
.
or more free time