Thank you making this, you genius 
. I agree, very useful for future references and transparency. Maybe we can number them instead of bullet points, it will be easier to cross ref them in comments.
- Team should vote, considering they plan to spread the delegations across validators, hence raising the commissions.
a) if when this is achieved (spread is achieved), team Validators should vote.
b) they can optionally vote now, since we need things launched on fx, and the number of proposals are limited.
c) Once matured and the eco is thriving, point a & b should be made mandatory for them imo. As suggested on your post, if Public Validator should vote or get slashed.
-
Project addresses can vote when all Public/Team Validators reach a certain percentage of equally distributed delegators… This is an assumption, if this is actually what the intentions of the team is, then yes they can vote. By then all 50 Validators can be close to each other and have the desired equal delegators.
-
How to motivate public delegators to migrate voluntarily to public validators ?
a) Maybe by having more medium reports and in all possible translated languages
b) team giveaways, for redelegators
c) official team reports of public validators of datas (not sure what criterias here atm)
d) delegators security concerns answered,
and anticipated concerns clarified.
e) perhaps a fx telegram group questionnaire, and identifying these concerns, and having them answered.
f) knowledge based clarity; public validators overseeing (monitoring) each others node and especially the overall fx core network. Whereby a FX team member is over seeing and ensuring all Public Validators.
g) maybe an info graphic/ or a one pager here with the above points can help…
f) youtuber videos can maybe help here… More tweets, shills from individuals of course.
g) and the obvious in-wallet voting. That could change all the datas here with these brainstorming.
-
**What are all the FxCore project addresses ?
**
a) since the question is raised here, maybe transparency here couldn’t hurt to know, and in case for future reference point, or enquiries.
-
Which quorum should be targeted to allow public proposals to reach quorum, especially considering ?
a) without the team’s vote 30%
b) with the teams vote, as it stands now (with the uneven huge delegators, just abstain for now imo.
c) once even delegators across all 50 Validators, then maybe participate in voting.
- Should we setup proposals categories ?
a) what categories are there? Which type? Let’s assess Dapps (Defi, staking, gamefi, finance, etc vs EGF amount requested.
b) keeping it simple to on-board devs should be a priority imo.
c) actually I think you got it right there by suggesting a percentage of the overall requested… Need more thoughts here. However it can get complicated if the proposer wanted it for various reasons, such as DAOverse (which made sense in their case, the anomaly I speak off & in various ways).
d) maybe a floor height… but we should not restrict potential projects imo. Leaving it open and assess as it appears (the proposals).
e) categories cannot determine nor foresee the amount required and what’s ahead to be proprosed, or needed by startup project.
- Should we lower the minimum deposit for proposals ?
a) yes, absolutely. On-boarding projects is paramount, make it accessible and easy as possible, with minimal cost.
b) we don’t want flooders as well. So a little deposit is suffice eg 1k USD equivalence (or another number) in fx.
c) or simply use fxUSD. Surely FX Variable would need it. (I have not tested it, got bust here lol so not sure if its on FX Variable today).
- Should we set the minimum deposit for proposals to a fixed value depending on the category ?
a) no, as it restricts devs.
- Should we implement a slashing for validators which do not vote within the voting period ?
a) yes we should. Because it cost only 1fx, lol.
b) all public validators are dedicated individuals heavily invested and true supporters, it’s inexcusable not to vote.
c) I don’t see any concern for this tbh, since it runs for days (the proposals)
d) on second thoughts or can change rapidly actually with the EVM… But I think Public Validators can have a consensus to vote and encouraged to, of course we will be discussing each projects pros and cons, and from entire communities as well.
- Should the team delegate their tokens to public validators ? on which criteria ?
a) yes they should, and can
b) some public validators need support
c) our user base is still small.
d) validators cost covered
e) Team’s investment in public validators also means, they are investing in the longevity in fx supporters (over the many years, trust build both ways)
f) time spent setting up the initial validator node, this will reset if public validators don’t see much benefits vs simple delegating fx.
g) growing with the project in every aspect is good to know the team has also supported public Validators. We also need equal redistributions.
CC @DavidK @zaccheah @Peko @Richard
Not sure, but was thinking, should we shill FX Variable when it’s more closer to release… Still in Aplha and still have long way to go… Might be more impactful closer to date.
, especially since we’re still a very small community on the forum.