Baklava did deploy an incentive of 300k $FX (not $USDT) for Baklava vaults.
I don’t know if it’s on Stake vault or FxSwap vaults though (I think it’s only on the first one…) Link 1 Link 2
Thank you for your support and effort to build your platform on f(x)Core. I am very thankful for your commitment, especially when I saw that the FX tokens that you received from proposals #28 and #40 have been 100% allocated as liquidity on FXSwap (FX-BAVA pairing) and also as incentives (on top of the additional allocation of BAVA tokens from Baklava team).
In this message, I want to propose to the FX community to replace FX liquidity on the FX-BAVA pairing on FXSwap with FX tokens from EGF (which will be submitted by the team), and the current FX liquidity that belongs to the Baklava team can be utilized for the next development.
I think this will be beneficial for both teams in the long run. I hope the Baklava team can consider building vaults to bridge the supported chains with f(x)Core and bring that liquidity to f(x)Core (especially if it can utilize the f(x)Bridge).
I look forward to hearing the community’s thoughts.
I am proposing 300,000 FX tokens, basically the same amount as the Baklava team received on proposal #28, where they put all of them as liquidity on FXSwap.
Thank you for the consideration @indra & @FrenchXCore, it will be very useful for our future development on fx. our team will wait for more opinions from the other community members. we are proud to be part of fx and always try to deliver our best.
Considering there were some validator nodes that became inactive during the upgrade last week, I suggest you guys limit the auto delegation only to the top 30 or top 40 of the active list. From my point of view, most of the rank changes happened in the top 40 below, and this approach is to secure the user’s delegations from slashing. Kindly let me know if you have other solutions.
This approach is subject to change based on the results of the next upgrade.
This is the reason why I suggested this previously, back in September, again and again.
A competent team should be able to <visualize issues that have not happened and prevent them> from happening. - Reference Lido for whitelisting quality validators.
Whitelist validators with consistent uptimes; this is to ensure both the users of Function X and Baklava can have peace of mind.
It’s the protocol’s responsibility to ensure they integrate quality validators only.
Having bad validators reduces the protocol’s APR.
Having bad validators puts the user’s fund at risk of slashing.
It’s the foundation’s responsibility to ensure they delegate to quality validators only.
Having bad validators puts the foundation’s fund at risk of being slashed.
Both have a part to play.
Decentralization is a journey, but we should always stick to the principles of being of high quality and not forgo basic measures.
There are a lot of top validators top30-50 only get punished by 2-3 bad validators……50 isn’t not much and there are 20-25 company validators so monitoring 20 Public validations by quality would be nice……