LFG Retrospective & Feedback Round #2

Love the UX changes. I can see them both being very helpful for people going forward.

A feature I’ve seen a few people request is a visual countdown timer until the vote ends on the voting page.

Something that could be improved is ongoing official announcements/tweets that voting is live. One tweet went out at the start from the Jupiter X account then nothing until voting had closed. Even with a record turnout, there were still ~55M JUP (20%) that didn’t vote.

As for Discord, one suggestion is for a dedicated read-only Discord channel for the active measure. Reminder announcements could go out from there a couple times a day and they wouldn’t get lost in the shuffle of the main announcement channel. This could also be home to resources like the cheatsheet I posted for this last round.

When I originally posted the cheatsheet, I had to do so in multiple channels then ask for it to be pinned. Then when I needed to correct a piece of data, the original had already been spread around quite a bit. It was easy for me to update here on the forum but not Discord.

After the voting closes, the channel would be archived. Rinse and repeat for each new measure.

As for obscuring the vote tally, I don’t think it will make much of a difference. Since the info is on chain, someone somewhere will make a dashboard, the info will find its way into Discord and it will all have been for naught. But more than a few people want this so maybe do an informal poll in Discord in the JWG channel?

3 Likes

Disagree that people shouldn’t be able to change their vote.

Sometimes new info comes to light after someone has voted that causes them to change their mind. They should be able to re-cast their vote before voting closes.

5 Likes

2, were there things you wish could be improved ?
answer : YES! like making it possible for us Jup J4J catdets to vote to with some of our staked $JUP token when of if we don’t want to vote all, our $JUP voting power.

1 Like

I’ve gotta say that the lack of tokenomics requirement for all was a turnoff for me.

Secondly, I believe any airdrop should either 1. Be for all voters or 2. Not released prior to the end of the vote as it just incentives people to change their vote to rank #1,2 if one of those offers an airdrop only for those who vote for them.

I’d rather just see no additional airdrop at all for anyone to keep the voting process clean from bribes. That likely won’t be a popular statement, but it is what it is.

5 Likes

can we implementing One person, one vote for the lfg. Implementing a system where each eligible voter has an equal with the whales,but we can give the staked voting reward equal to the amount of the staked.its more democracy

5 Likes

Here are my thoughts on the first LFG vote I conducted. My thoughts to your questions below.

  1. Were there any aspects which you particularly liked?

Overall the process was easy to follow and implement. Quick and easy access to information on the projects was great.

  1. Were there things you wish could be improved?

More information on tokenomics for all future projects would be good, which should also include any information on staking, rewards, release rate, etc.

  1. What are the most common sentiments you’ve seen regarding potential LFG changes from other people? Do you agree with them?

As a first timer, I honestly saw good banter and discussions on these projects. Possibly a slightly extended time to allow for more banter and discussion prior to the vote.

1 Like
  1. To set up a minimum threshold to prevent unlimited sub -trumpets. From the first LFG voting wallet address of only 250,000, it has increased to 410,000 addresses for the second time, but the number of pledged JUP has only increased by 10 million .
  2. The cancellation time is a bit long for 30 days. It is recommended to 15-20 days. If you unlock all in advance, charge a certain handling fee.
  3. When the reward should be clear, whether it is airdrop or receive it by yourself.
  4. Increase the countdown.
  5. Clarify whether the voters have an additional airdrop from the project party
    I use Google Translation
3 Likes

I think everything you said nails the biggest problems within Jup staking. If those issues are addressed I believe it would bring in even more traffic.

1 Like

The public information on some projects is not enough for me to judge whether to vote for them.

1 Like

My two thoughts when voting this time was

  1. I didn’t see an exact time for the vote to conclude (only the date)
  2. It could nice for a organized notification system. Just some way (on any common app I guess) to opt into receive various notifications, such as initial announcements, when round/vote goes live, and 24 hrs left.
1 Like

2 Things i would mention:

  1. (Small) Maybe put a small subline under each project that describes this so people that blind vote may be pulled to a leading vote.

  2. Heard about from different ppl searching for the vote page. Jup LFG etc is very web3 native designed. New people need to dive deep, where, what etc. So maybe have a better just “Entrance page” - “Marketing Page” - “Native App with notifications” “knowledge Base Blog” (just some random ideas)

1 Like

A good number of others have already (quite rightly) stipulated that any (and all) potential LFG candidates should have their tokenomics published PRIOR to any consideration being given to their entry to the LFG.

Also, for candidates that have excellent merit (but little or no VC financial booster base) I would like to suggest a ‘wildcard entry’ for the LFG. This similar to Wimbledon system. Within Solana, wildcards can be given an opportunity for launch (those with great, clear tokenomics, identifiable strategic support and/or of advantage to the Solana ecosystem, active members in Discord (showing respect and engagement with Jupiter members, as well as their own Discord), excellent pedigree of project leaders and so on.

Thirdly, I realize that the LFG is evolving with each iteration. It is great that it is so popular (although not a surprise). The voting side though, I would prefer to see the ‘updates’ of who is winning obfuscated until after voting finishes. It did not impact myself (as I was of a strong opinion of who I wanted to vote for last time) but it may impact ‘weaker’ voters, who may believe they will get more airdrops (or whatever) if they then changed their votes. Everyone is different though, but I have to recognize this is a possibility in others. Great work, keep it up.

3 Likes

As a project that participated in the last round, we kept close eyes on community sentiment and have our own opinions regarding some improvements:

Clarity regarding JUP Voter airdrops would be great. Projects right now announce it manually on their channels, people have to make sure to not miss these announcements and there is no security that projects will really do the airdrops promised.

It would be safer to have an info box indicating the terms like voter airdrops in some of the official documents.
JUP could spin up some sort of escrow that will hold the Jupiter airdrop allocations and then distributes it later based on the project‘s terms.

I know it has been discussed before, but anonymizing the voting should be considered. Obviously the votes are onchain but keeping it from the UI could imo make the voting more fair as users potentially don’t ape for the winning party.

Maybe we could also have a discord channel that automatically fetches all JUP proposals from research forum? To make the discord more the central point of information and the proposals more visible.

2 Likes

I have the following feedback on the voting process:

  1. The projects that want to appear on the LFG launchpad should provide a minimum amount of information: (i) the tokenomics of the coin to be released via LFG launchpad, (ii) the reasoning behind the coin to be released via LFG launchpad, and (iii) team information. This (and potentially other information) should be a bare minimum to even be considered for the LFG launchpad. Minimum criteria not met = no launch and deferral to next period. How can someone vote on a project that refuses to recognize releasing a token and/or not providing any information on the token DESPITE applying for the LFG launchpad?

  2. We should resolve the issue of providing additional allocation to JUP voters. ZEUS set the precedent, which is great, but projects promising extra allocation (upon TGE) to JUP voters simply puts the voting system under pressure as people look at more coins instead of the underlying project. I have been thinking about a solution but it is not straightforward. I considered projects having to disclose that when they launch their LFG launchpad candidacy, any later allocation would lead to disqualification. However that could trigger voters to vote not for the product but for more tokens. Prohibiting projects to promise extra allocations is also counterintuitive, as this should be part of the reasoning on why to vote or not to vote on each project. We need to think about a way to resolve this situation, for example a tag on the project whether or not the allocation is more than ASR rewards?

  3. Jupiter should avoid announcing partnerships or any other activities with LFG launchpad candidates. This impacts voting as well, and not a little bit.

  4. A clear note should be on the top of the voting website mentioning that whoever you vote for does NOT impact your reward allocation. This could also be a pop up that people have to accept / understand before proceeding. It is essential that people understand this before they can actually issue their vote.

  5. Please hide how many votes each projects has (in percentage) during the vote. People are sheep and following the project that receives the most votes. The vote is basically done in the first hour as everyone votes on the ones winning then. There is a strategic advantage for projects to get their votes early to ensure them winning. An indication on whether or not the minimum threshold is met, is fine but hide the votes until the vote is finished.

  6. We need more transparency on when ASR rewards will drop. We know a general timeframe, but would be great for more information.

4 Likes

I really liked that it was obvious this time that my vote had gone through and who I had voted for.

Nice answer! Can’t agree more!

1 Like

Definitely also think that there should be a rule that any airdrops cannot be contingent on where someone put their vote, only for all people that voted. Otherwise we risk a system of open bribery. This is obviously already a risk anyway as people will be more inclined to want a project to win that provides better rewards.a simple solution would be a fixed airdrop provided by all participants, and to all voters. That way there would be no incentive for any project to win and people can vote based on other technicals, and how much they like the project.

Otherwise voting will end up being driven by greed alone.

4 Likes

How about this refinement: "Prior to being eligible for LFG voting, all Projects should be required to publicly disclose comprehensive tokenomics. Additionally, instead of the current top 2 pick vote, consider implementing a top 3 pick system for enhanced inclusivity and diversity of projects.

5 Likes

I think one thing that struck a chord with many is the fact they were surprised they did not get an airdrop from Sharky. They were expecting it, but did not get it, so were upset. I think the lesson learned from this is that we need to clearly set expectations from the beginning. Perhaps these details were buried in the docs and required research, to be honest, not sure. I think upfront info needs to be provided as part of a projects application such as

  1. How much of an airdrop does each voter personally get and how is that determined, for example, 5 airdrop tokens for every 250 JUP staked. If there is no airdrop voters should know that going in.
  2. How does the overall DOA benefit by launching the project? Does the DOA receive an allocation? Will stakers benefit from that allocation during rewards distribution later? Ultimately anyone who votes for a project wants to know how they will benefit at some point.
  3. Tokemonics should be clearly outlined as a part of any project submission. How much total supply, how much goes to seed investors, team, etc. Also, what;'s the vesting schedule? No one wants to get dumped on.
  4. We should be told if the team is dox’d or if they are anonymous
  5. If an audit of the project has been conducted that should be shared.
  6. Contract addresses should be provided so all projects can be scanned for risks.
  7. Community stats should be shared. Twitter, discord, etc.
  8. Can tokens be purchased at a discount by voters prior to launch if the project wins? If yes, what are the details?
  9. Summarized use case

The above should be basic items that are submitted by the project as part of their consideration process. The above should be summarized and provided to all. I know folks should DYOR and we want them to, but I have a feeling many don’t. In the end, we want to launch great projects. Everyone is always interested in projects launched by Binance Labs because they have great ROI’s, because they don’t launch junk. I’m not saying we are launching junk, just saying we don’t want to get a reputation of launching only projects that disappear in the bear market or never go anywhere. If we get that rep, then everyone will just dump their airdrops as soon as they get them. I would rather launch 4 good projects all year than 12 bad ones. 4 projects that 20X are better than 12 projects that die.

So in summary, each project application should include an executive level summary, 1-2 page doc that provides key information on the project, community, use case, team, tokenomics and benefits to the voters & DOA. This will help to ensure all voters can at least briefly educate themselves because not everyone will spend hours researching and I would rather have a semi-educated vote vs. a vote that was cast using a blindfold. The summaries can be posted, so no real additional work for the working group. Just as simple as telling the project up front this is part of the application process and the summary will be posted for all to see.

3 Likes

One other thought on voting. Currently, votes are based on amount staked. I get that and I’m ok with that, however, I think there should also be another approach.

Give everyone 2 votes. 1 Vote based on how much you have staked and 1 vote per person. Two completely different vote counts. So 1 vote count can show project ‘A’ won, perhaps because some large stakers voted a certain way, but project ‘B’ could win because the most individuals voted another way.

One approach gives more voting weight to those with more money staked and the other provides a level playing field for all. Currently we launch 2 projects based on the votes. You could have the first vote based on how much everyone has staked, then after that project wins, everyone votes again on the remaining projects but this vote is by individual, so 1 vote per person, period.

This approach gives the rich and poor equal say/opportunity. Because to be honest, a few large whales could possibly control a project to launch. If smaller fish feel they are never being heard, you may only be left with a pond full of whales, i.e. no community.

Also, for transparency, if a single wallet owns say 5% or more of the vote/amount staked, that should be disclosed and their vote should be disclosed. Just the wallet address, not any personal info. People would want to know if a single wallet is controlling a large portion of votes and if all top wallets voted a certain way or consistently vote the same way. Things can be manipulated and we need transparency and trust in the process.

2 Likes