FunctionX DAO governance

Hi everyone !

This is the new thread to discuss mid-term governance improvements and transparency considering issues to get public proposals to reach the 40% quorum.
Some of them were discussed in the DAOverse creation proposal thread.
Others were discussed during the January 2022 AMA

One objective of this thread would be to discuss open issues:

  1. Should team validators vote ?
  2. Should team’s project addresses vote ?
  3. How to motivate public delegators to migrate voluntarily to public validators ?
  4. What are all the FxCore project addresses ? (beside personal addresses) → Product&Marketing, Engineering, PUNDIX conversion, … funds, EGF funds
  5. Which quorum should be targeted to allow public proposals to reach quorum, especially considering ? (especially if we were to consider the team validators/addresses would not vote)
  6. Should we setup proposals categories ?
  7. Should we lower the minimum deposit for proposals ?
  8. Should we set the minimum deposit for proposals to a percentage of the amount requested ?
  9. Should we set the minimum deposit for proposals to a fixed value depending on the category ?
  10. Should we implement a slashing for validators which do not vote within the voting period ?
  11. Should the team delegate their tokens to public validators ? on which criteria ?

I’ll keep this first post opened to add future new questions from the community.

Thanks to all, once again !

3 Likes

(Reserved for FX project addresses)

Currently-bonded (delegated thru FxCore) FX : 301.6M $FX (as of 01/22/2022)
Below supposed team FxCore addresses : 199.9M $FX (66.3% of total delegated tokens)

image for :warning:Don’t hesitate to warn me if any correction is required.image for :warning:

  • fx1lzjus804ufar37qulrwk5xva6f9h3p8wz47hs3 : 30M $FX - Votes for proposals 1/3/4/5/6/7/8
    → Engineering, product development and marketing address
    → ERC20 address : 0x2A34bdD763864D1b5F49D8A3EDFC37eE274a90dc
    → ERC20 address : 0xD3E327C4867b0934d3204aa9050321339718D80F
  • fx1g7d9ftp6xns5gfsk56j9khpzg2fz7g39nz8pny : 25.8M $FX - Never voted
    → Engineering, product development and marketing address
    → ERC20 address : 0x2A34bdD763864D1b5F49D8A3EDFC37eE274a90dc
    → ERC20 address : 0xD3E327C4867b0934d3204aa9050321339718D80F
  • fx1pgmjd400qfkh6t2hu7gnme47wdj6adwwa2wkam : 21.2M $FX - Votes for proposals 1/2/3/4/5/6/7
    → Ecosystem Genesis Fund
    → ERC20 address : 0xC070058769457328FF9D7B0D62b7089e8eF57a7E
  • fx15xtp30u054ndnf833jrq4kz4wpvn95zsh9399f : 17.8M $FX - Votes for proposals 1/3/4/5/6/7
    → PUNDIX conversion: not converted to FunctionX and stored in cold wallet
    → ERC20 address : 0x2589E6Ad2D2F73d2f8005810c27704491C9ae25E
  • fx1ftzv705fvyrfmqvnpjhjr0xh56c5jg980q0gul : 17.8M $FX - Votes for proposals 1/3/4/5/6/7
    → PUNDIX extra-bonus task
    → ERC20 address : 0x976738e0433689a08D5Cfe7F3BE9e7c6d5bADc40
  • fx1j59we8wnp72sna8fjdchpkf0s62m0q9va5yv03 : 13.7M $FX - Never voted
    → Ecosystem Genesis Fund
    → ERC20 address : 0xC070058769457328FF9D7B0D62b7089e8eF57a7E
  • fx19ukzjkag6n4lqgejfu33046qc036rw76thgsqv : 12M $FX - Votes for proposals 1/3/4/5/6/7
    → Ecosystem Genesis Fund
    → ERC20 address : 0xC070058769457328FF9D7B0D62b7089e8eF57a7E
  • fx1mtsq7ta90r3xj35q5sq3tcudelkyhzlh8dufzp : 10M $FX - Votes for proposals 1/3/4/5/6/7
    → Ecosystem Genesis Fund
    → ERC20 address : 0xC070058769457328FF9D7B0D62b7089e8eF57a7E
  • fx1wv2el7g92raz5jcv4fhsjvdcxl3hyqdd59repg : 9.9M $FX - Votes ???
    → Ecosystem Genesis Fund
    → ERC20 address : 0xC070058769457328FF9D7B0D62b7089e8eF57a7E
  • fx1wwvxyfr6u2jpp2zmcqjs3ett9npl90per52uve : 7.3M $FX - Votes ???
    → PUNDIX conversion: not converted to FunctionX and stored in cold wallet
    → ERC20 address : 0x2589E6Ad2D2F73d2f8005810c27704491C9ae25E
  • fx12shesxtysrm4k82aa2mptl3ltws00akp8qlczv : 5.6M $FX - Votes ???
    → PUNDIX conversion: not converted to FunctionX and stored in cold wallet
    → ERC20 address : 0x2589E6Ad2D2F73d2f8005810c27704491C9ae25E
  • fx13mjuh378z8yd4038eqlt5ef0z3wm8rp6xv2pxv : 4.5M $FX - Votes ???
    → PUNDIX conversion: not converted to FunctionX and stored in cold wallet
    → ERC20 address : 0x516E1115737ce7Dba553157A098e33fB954370fc
  • fx17uw98zmyv7q9cf4s9z3lumms6ctxtguyan44s9 : 4.0M $FX - Votes ???
    → PUNDIX conversion: not converted to FunctionX and stored in cold wallet
    → ERC20 address : 0x2589E6Ad2D2F73d2f8005810c27704491C9ae25E
  • fx1uunshfpqhrek0af5u5q54qrfu5g33sc5ce05kx : 4.0M $FX - Votes ???
    → PUNDIX conversion: not converted to FunctionX and stored in cold wallet
    → ERC20 address : 0x516E1115737ce7Dba553157A098e33fB954370fc
  • fx1aymjyggdcme9vlhqg45hmx4fsr97vnm0kquray : 3.8M $FX - Votes ???
    → PUNDIX extra-bonus task
    → ERC20 address : 0x976738e0433689a08D5Cfe7F3BE9e7c6d5bADc40
  • fx1qlaawfv2k2f283fxhyh5rwtwlusuzke4r07wt5 : 2.0M $FX - Votes ???
    → PUNDIX conversion: not converted to FunctionX and stored in cold wallet
    → ERC20 address : 0x2589E6Ad2D2F73d2f8005810c27704491C9ae25E
  • fx16xnahksm0646kxu56zsspwq93ydapjwq2uzkuh : 2.0M $ FX - Votes ???
    → PUNDIX conversion: not converted to FunctionX and stored in cold wallet
    → ERC20 address : 0x516E1115737ce7Dba553157A098e33fB954370fc
  • fx1je0uncutnc8wpg5s2uth97t5sfkw83h4dnz2ar : 1.8M $FX - Votes ???
    → PUNDIX conversion: not converted to FunctionX and stored in cold wallet
    → ERC20 address : 0x516E1115737ce7Dba553157A098e33fB954370fc
  • fx16p2uyfvepc28hqkjv8vz5nku4rqme2gzjj6trd : 1.7M $FX - Votes ???
    → Staking (matured)
    → ERC20 address : 0xDEDE2674E56D558288BdAa25cE3699fe42697c4e
  • fx1r30q2gq740pjr7fsrtwvk6sjyu47g8urytl6a2: 1.7M $FX - Votes ???
    → Staking (matured)
    → ERC20 address : 0xDEDE2674E56D558288BdAa25cE3699fe42697c4e
  • fx1u8503d8hnmy806slfy9e48e7qs5335qm6nqzkc : 1.7M $FX - Votes ???
    → PUNDIX conversion: not converted to FunctionX and stored in cold wallet
    → ERC20 address : 0x2589E6Ad2D2F73d2f8005810c27704491C9ae25E
  • fx17hkmdwrfq5f23903308pjrut7g99ue45vqmgux : 1.6M $FX - Votes ???
    → PUNDIX conversion: not converted to FunctionX and stored in cold wallet
    → ERC20 address : 0x516E1115737ce7Dba553157A098e33fB954370fc
  • fx1murmchz2hc909kgj3acac5z2qdsgzjrz0js30t : 1.5M $FX - Votes ???
  • fx194x0wudyg85jexjeheanau6cgcrl2nnshhh943 : 1.5M $FX - Votes ???
  • fx1h3nshfzumcztacd2tthefq6mhddwcm4tr4nrsg : 1.5M $FX - Votes ???/8
    → For those 3 : not sure - but certainly personal whales addresses
1 Like

(Reserved for future wrap-up of discussions)

Team Validator should vote, we need dapp work on fxcore first

Thank you making this, you genius :blush:. 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.

  1. 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.

  1. 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.

  2. 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.

  1. **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.

  2. 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.

  1. 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.

  1. 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).

  1. Should we set the minimum deposit for proposals to a fixed value depending on the category ?

a) no, as it restricts devs.

  1. 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.

  1. 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.

3 Likes

Where you have a need for yes / no responses i recommend use a poll to speed up the ability to respond, asking a reply on a lot of questions requiring input will be tiresome for most and won’t engage.
even better if you can set all into a click through engagement with options to select, always with extra options like; Other - not interested - Need more options - need more info ; selection options, time to move faster we need faster response options.

My tentative position (not the company and not set on stone)

  • Lower Quorum to 30%. Why not lower? Because company’s validator has been decreasing and will continue to decrease further hence it is conceivable already that public validator will control more than 30% of voting power soon.

  • Lower deposit fees to 3000fx. Low enough to encourage people to propose, high enough to prevent flooding. Alternatively if our engineers can figure out, it could be a % of the requested funds. So if you are asking for [AN AMOUNT]fx you should, on top of 3000fx, add another % of [AN AMOUNT] to it.

  • company validator do not vote. I am still not keen on company validator on voting as a one because inside the foundation we all have our preference and opinions (it would be a bad thing if everyone in the foundation think the same). So while, say, I support particular proposal , others in the foundation might be against, which is perfectly normal. Hence I will encourage the company’s delegator address to vote as these are managed individually, but not company validator.

There are many more things we can improve, more importantly is to make quick iterative improvement as our biggest competitor is time.

The team has been consistently reallocating our tokens to public validators, this is the right thing to do. Do know that we obviously try to be as fair as possible, but public validators are not all managed the same - some have better setups. We will be as fair as we can.

Shout out to @Mdmdmd83 and @Superbit123, your opinions are valuable.

4 Likes

Thank you for the clarity.

What is your opinion on having company votes as abstain for the pure sake of transparency. Remaining neutral is absolutely important but should be clearly portrayed as a abstain vote.

3 Likes

I actually hate polls because they’re already a bias by themselves :wink:, especially since we’re still a very small community on the forum.
The idea is to collect answers on one or more questions, or to gather other questions.
I will try to sum up answers on the go…
There’s no bad opinion anyway : I can’t pretend to have the whole picture, or to have thought everything thru 360°.
That’s why I think everyone should participate to the debates.

2 Likes

There again, I think the team should participate in the vote.
Though, since the team detains many tokens for now, voting abstain from all their validators would increase quorum, but also increase the proportion of non-yes responses, thus preventing to reach the 50% threshold.
@zaccheah indicated that they are delegating teams tokens to public validators, thus increasing public validators voting power. This might be a viable option (beside increasing public validators’ commission fees, and allowing them to improve nodes’ security).
While doing so, the team allows public validators which voted yes to automatically increase the quorum %age of the proposal, and the validator vote has more weight.
Still, even if it’s a temporary solution, which can be withdrawn anytime and 100% controlled by the team, it’s still a good way forward for the months to come.
I expect we’ll have more tokens in the wild in the future, and it will increase decentralization.

For me, priority would be to allow voting directly from the app, as soon as the next version of f(x)wallet app is out.
Another top priority would be to simplify the act of buying $FX, by having it on BSC and Pancakeswap, thus avoiding very expensive ETH fees thru Uniswap or centralised exchanges. Plenty of small buyers were lost with high ETH fees when transferring from XWallet.
Another priority would be to reach the community outside of f(x) with FXDM, airdrops on FxCore (for example using non-converted PUNDIX-to-FX).

5 Likes

Hi again ! @zaccheah @DavidK

I think I can express most of public validators and delegators disappointment wrt. what just happened for Proposal #8.
The only way for this proposal to get thru 40% quorum was to have only the 5 biggest team addresses to vote, whatever the vote was.
Here, the complete absence of vote from the team (except the few delegations to some public delegators) is totally disorienting me : the team currently holds almost 65-70% of the delegated tokens !
How can we expect any public proposal to reach 40% quorum if the team doesn’t vote ?

You’re looking for people ready to eat, drink and sleep their FX project, and yet, you didn’t even take 1 minute to consider the current issue.
93% of FX delegators/voters did vote YES (70M FX tokens, so, much more than half of the public delegated tokens !!): doesn’t that seem like we deserve some explanation ?

Solution 1 : the team is forbidden to delegate its tokens and to be rewarded with APY : this would lower the quorum by a significant level. But that would also significantly increase the APY.
Solution 2 : the team HAS to always vote : at least using EGF address and unconverted PUNDIX tokens address.
…other solutions : to be considered.

Thanks in advance.

6 Likes

Totally agree with you!
I would vote for option 1.
But the community has the right to get specific information, to know where we are going.
Transparency, clarity is important!
Now the situation is that there is a fund, there is voting. But everything is clear to everyone before the vote that everything depends on the FX team.

As I mentioned in the Daoverse thread there needs to be a immediate response from the team on this. The discussions about what is the proper path forward need to be in the clear light of day from within the team and not in private. If the goal really is decentralization this discussion Must happen in the open and with the clear input from the current (and now dwindling supporters)

2 Likes

Sorry to break it, but the team already dumped that plan. And instead want to use the liquidity on its own swap.
I dont get why they keep throwing away any plans that would increase the chances to reach more people. Its almost as if something will break the second it gets in contact with large parties

Hi these are all valid concerns, and as requested we will have an All-Hands meeting in a few hrs. Let’s address everything together.

4 Likes

I totally agree that the company should always stay neutral and not vote for any proposal.

Priority should always be company and reputation first.

My reasoning for this is because, no matter how much a company or person does their due diligence, we will never know 100% for sure that the proposer of any project is 100% legit.

There could be possibilities where well known syndicates or con-man who can build a nice story to request for a sizable fund may just run off after getting the fund.

To safeguard this, no matter how small the chance, I think the company should just stay neutral from the long-term POV or until the chain reach a certain maturity.

Solution to the quorum:
Let the quorum count non-company tokens only.

Example:
Total staked: 100,000
Company holds 40,000

The contract will only count 60,000 and that will be the full 100%. So if only 30,000 votes, that will already be 50% quorum.

Let the the contract auto calculate or insert the company’s address so it will exclude their tokens from the quorum calculation.

You guys already have seen how people on Twitter go crazy and talk shit, we wouldn’t want the trash talk to happen or have a chance to increase even more.


I urged all those to think from the company’s perspective. It is important to stay neutral in case of any bad projects.

Irresponsible investors will instantly turn their heads to the company if a project that was voted by the company becomes an actual garbage. To avoid this situation no matter how slim the chance is, stay neutral.

It would also be good to stay neutral since within the company, there will definitely be different opinions also and may cause internal conflict.

Think far and from a business point of view.

3 Likes

It would be nice if the proposers had to set milestones on the proposal page. The funds requested seems to be quite high. So, for high value proposals, one exceeding 100k, ensuring milestone is achieved before a certain amount of fund is released can help the community audit the work of the proposer.

For instance, someone starting a new defi dapp who asked for 250k should create at least 10 milestone and funds should be released gradually rather than immediately. Its easy to say that 100k will be used for marketing but the milestones can ensure that a targeted level of awareness is reached or users acquired. This can ensure that if the proposer is successful, they get the fund in time. However, if things are not woking out well, the funds are safe and can be used in other projects.

With regards to failure of DAOVerse proposal, I believe the above steps could help but the company could also set up INCUBATOR FUNDS from the EGF similar to Binance Labs to support startups. Do not change the quorum, maybe the maths behind it. The company still needs to keep control of the ecosystem at this stage.

Other suggestions to mitigate these situations:
-Voting on proposals should be possible from the wallet.
-The quorum should be calculated of those delegating and not all tokens
-The Company should always stay neutral but also note that, at this point, it was almost impossible for DAOVerse proposal to pass without their support. So, some form of reimbursement for them would be nice.
-Maybe set the quorom(temporarily) to 30% for those willing to get funds through milestones rather than all in one go.

3 Likes

I agree. I hope the team can consider setting a rule that the funds will be distributed in milestone phases.

Because if the developer doesn’t have any reputation or certification that can back up his claim, the fund may not get put to its intended use and may get wasted.

After all, those who actually have businesses in real life will know that most start ups fail and only a handful succeed.

4 Likes