@lancelai Hello, currently we’re not running a testnet node.
2 Likes
The testnet upgrade has been completed. Those who are interested can catch up now. We encourage to do so as it helps to better prepare for the mainnet.
Thank you
2 Likes
We are excited to announce that the latest testnet upgrade includes the new implementation of omnichain technology. This advancement allows for enhanced interoperability and scalability across different evm networks. We encourage all users to explore this new feature to better understand its capabilities and prepare for its integration into the mainnet.
3 Likes
Hello validators,
We’ve identified a bug in the FXCore testnet. To address this issue and ensure the stability and performance of our network, we are planning another upgrade expected to be around 4pm SGT today.
Countdown link | Function X StarScan
We apologize for any inconvenience and appreciate your understanding as we work to enhance the reliability of our systems. Please stay tuned for further updates.
Regards,
Lance
3 Likes
upgraded! also enabled rpc endpoints and monitoring. snapshot services will follow soon
1 Like
Dear Validators,
We are pleased to inform you that we plan to upgrade the FXCore testnet this afternoon. In preparation for the upgrade, we will temporarily suspend the cross-chain functionality with the ETH/Base testnet.
5 Likes
Just updated my full node.
Seems to run fine.
A bit more notice maybe ? 
(v7.3.0 was not available to download a few hours earlier)
haha yep, we’ve also upgraded. faced no issues at our end
Hi @lancelai
Any way we could expect some documentation for devs about this new feature ?
Regards
Sure, it will be published to our GitBook once it’s ready
Our account is not authorized to start a new thread, so I am posting it here.
Dear FX Community,
I am writing to express my concerns regarding the current state of the FX validator ecosystem. We have been an active validator since January 2024, diligently maintaining our server and ensuring its performance. Despite our consistent efforts and the additional services we provide, our validator has remained inactive for nearly eight months. This has resulted in significant operational losses, as we have not received any delegations or support from the team.
Recently, it has come to our attention that one individual is operating three validators within the active set. These nodes have faced constant uptime issues and were recently jailed for missing the 20,000 blocks signing window, resulting in a slashing of 0.1% of their tokens across all their nodes. In one look, one can tell that this was not the first time but has happened before in the recent past. Despite this, the cumulative FX staked on their validators remains substantial, at 18,070,135 FX even after the slashing, approximately $2.5 million.
Additionally, another person, who has been consistently jailed and unjailed while running two validators, is now jailed for some time with a final stake of 4,864,000 FX. This means that approximately $654,684 worth of delegators’ FX is at stake and is not being managed properly due to carelessness or lack of commitment. This situation is disheartening and discourages other validators who are committed to maintaining high standards and contributing positively to the network. Delegators suffer losses when a validator is jailed, and it is not healthy for the chain to have non-performing validators occupying significant portions of the active set, while other diligent validators are overlooked. Furthermore, allowing a single person to run multiple validators poses a security threat to the network, as it can bring the network to a halt.
I urge the community to consider implementing parameters that encourage delegation to well-performing validators and discourage support for those who consistently underperform. This would not only promote fairness but also enhance the overall health and security of the FX network.
Additionally, I would like to address the situation regarding my validator for PundiX, a sister chain of FX. Despite running the validator for over seven months, we have received practically no rewards in monetary terms and were running the chain in good faith. We have decided to take this difficult step and shut our validator node. It feels unfortunate to part ways with the chain, but given the lack of community support and acknowledgment for performing validators, I would like to extend my gratitude to BYTEX, FrenchXCore, and Claudio Barros for their support during this time.
Thank you for your attention to this matter. I look forward to a more robust and equitable validator ecosystem.
Sincerely,
Nodes Hub
FunctionX & PundiX Validator
5 Likes
maybe some delegator need to move to your validator to help you run node
1 Like
Hi Ivan,
Thank you for your response. While we appreciate any support from delegators, our primary concern is the overall health and security of the network. Our previous post aimed to highlight the risks associated with allowing a single individual to control multiple validators, which can lead to significant vulnerabilities.
Currently, we are managing four nodes for FX alone: a validator node, an RPC node, a snapshot node, and a Testnet node. We have also provided fresh snapshots on request to fellow validators on the PundiX chain and assist our peers with syncing issues. We validate on other networks chains and we understand that validators can face issues and may be jailed, which is a normal part of the process. However, it is crucial that we remain vigilant and responsive to such situations. Validators are compensated for their services and are expected to maintain high standards of operation.
We have observed a concerning level of complacency in managing validator nodes and enforcing penalties for mismanagement over here. It is imperative that both validators and the community take a more active and stringent approach to ensure the network remains robust and secure.
Hi @NodesHub !
I fully adhere to your observations.
- Lots of tokens (which can be sourced to the FX foundation) are still being staked over jailed nodes. That makes no sense.
- A penalty (slash) of only 0.1% for downtime is far too low. This parameter can be changed thru governance, but we’d need to make sure the team is fine with such a change and would support it. This is particularly true since we need to attract professional-grade public validators, and the number of validators is too low (50, especially considering many are still foundation-validators).
- Again, transparency over how validators are being “staked” by foundation tokens would be also a good key, based on history, on slashes, on support provided, etc.
Regards,
@FrenchXCore
2 Likes
Hi FrenchXCore,
Increasing the slashing parameter would primarily hurt delegators, not the validator. The main issue is that across three nodes, the validator’s own bonded tokens amount to only approximately 1,600 FX. As a result, the validator barely gets penalized while delegators face significant losses. In this instance, delegators were slashed by 82,101 FX, roughly $10,845, whereas the validator withdrew a substantial commission today.
To improve the situation, it would be beneficial if validators compensated their delegators. We need a balanced approach. If a validator is slashed, they should lose a portion of their delegation. They should then be required to prove their uptime and reliability over the next few months before the community considers increasing their delegation again.
1 Like
hi i fully agree with your concern
validator who have 2 or more node need to turn off their server
and let other to be validator too
Tbh, it’s a great idea to reduce the validator’s delegated funds if they get slashed as a penalty since validators are essentially acting as a “21-day bank”.
Although that would only work if majority of the funds is owned by a single entity then it would easily be coordinated and undelegated at once.
Coordinating a bunch of delegators to undelegate would be kinda hard unless we know personally who delegates to who but this is all not doxxed.
2 Likes
We (Alif) have raised the same issues many times before. We were among the first public validators and have operated since than with benchmark performance and low commissions. This takes resources and multiple servers in the background.
Even with that, we were knocked down from rank 31 to 37 because of baklava teams decision to include only top 30 by delegation amount. The top 30 include very irresponsible operators.
Point is, there has been no clear performance metrics for validators and it’s been talked about many times with no clear road map.
2 Likes
One suggestion was to show cumulative downtime since inception, but it hasn’t been implemented.
1 Like