Extended Engagement of Jupiter DAO on LFG

Jupiter DAO LFG Updates
1

One of the most frustrating aspects of the LFG launchpad is waiting for an order to go through. Even with the DCA or limit buy sometimes the order does not go through. If we look at other launching platforms like Solanium, they allow stakers to participate in a preorder through some allocation based on tokens staked.

The Proposal
Create a priority purchase queue with 10% of the launch tokens for voters with allocation based on vote power. The minimum vote power to participate is 200 to stop people from creating many wallets to spam the allocation. The preorder should be added as a limit order so as to not impact the price of the token and should be submitted before the launch. Unused allocation should rollover into the main pool if unused by the voters. The allocation should be tiered such as:

  • Tier 1:
    Requires: 5001+ vote power
    Allocation: 0.00125% of the tokens

  • Tier 2:
    Requires: 1001-5000 vote power
    Allocation: 0.00025% of the tokens

  • Tier 3:
    Requires: 200-1000 Vote power
    Allocation: 0.00005% of the tokens allocated

Potential Benefits

  • Increased DAO participation
  • Increased interest in the project
  • More advanced payment

Potential Drawbacks

  • Could be difficult to implement
  • May not be satisfactory for stakers with large positions
  • A static allocation could decrease the total tokens bought by people interested in the project.
  • May not benefit the voters enough for sustained interest in the idea

Please let me know any thoughts you have on the proposal!

  • I like this idea and we should do it
  • I like this idea but it needs work
  • I don’t like this idea
0 voters
25 Likes
2

The issue is this isn’t an effective measure to discourage sybil atacks, it does the opposite – encourages more of it because the opportunity and advantage is created to do so.

Regarding VP and allocation tiers in your example, anyone with over 6,000 JUP is incentivized to spread that over 6x wallets for a total of 0.00150% (6x 0.00025%), rather than capping their allocation to one lock at 0.00125%

The minimum threshold is the 200 VP. Splitting 5000 JUP over 25 wallets at 200 each would yield an allocation of 0.00125% – there is where these tiers only work as a zero-sum game for holders with less than 5000 JUP. As highlighted in first paragraph – those with over 5201+ JUP, have the opportunity to game the allocation for more, whilst this approach only restricts any advantage for those holding less than that.

I would instead suggest a simple linear allocation reserve according to locked JUP. Not Tiers with cut-offs otherwise it can be gamed.

E.g. Your weighted % of the total locked JUP = Your % allocation of the total available presale reserved tokens. Simple.

15 Likes
3

A presale doesn’t really work for the fairness of a launch in my opinion. Maybe whitelist a prioritized limit buy for DAO members. I’d say 200 minimum isn’t a bad idea. But no limits based on holdings. If we whitelist based on weighted $JUP beyond 200 only Wales truly benefit. Just my opinion.

12 Likes
4

Actually this is a good idea, but if realised should be taught very thoroughly.
One of the potential flaws I see is while it will incentivise the use and staking of JUP it will also incentivise more people to join in order to be able to purchase first and dump later - so instead of the bots there will be people working with more time and money (and lso with bots at some stage).

Having this in mind. Here is an idea how this could be implemented in a proper manner to really give advantage to investors who join the Launchpad and stake their JUP to invest at least in short term if not even long.

A smart contract can be created that will collect the limit “pre-orders” only by people that staked JUP. We can give him a code name “LFG Concierge” - because he will make the orders on our behalf.
Investors who want to participate in the “priority” purchase set their settings for their order:

  1. How much they will invest
  2. What is their price ceiling they would give for the token (based on several considerations that I will explain below).
  3. They send their SOL/USDC to the smart contract and activate their priority position.

The concierge will collect all preorders without “promissing” any exact result and without giving any allocation. The allocation will be calculated on a fair formula after the preorders are closed and before the launchpad starts.
Instead of using any tiers and allocations we use a fair split based on voting power.
We already have enough other constants that can help us allocate dynamically based both on the interest for the project and the voting power that joined the priority purchase.

  1. There should be a maximum allocation for priority purchase (let’s use the 10% proposed in the initial proposal).
  2. The variables of the pool should be known before the opening of the priority preorders. This way we know the minimum price, the maximum price, the bin sizes both price and quantity wise.

So based on all collected priority orders by the Concierge and considering the other variables, the concierge creates consolidated limit orders based on bin size - one order for each bin (when there is a full priority of the concierge insted of thousands of players, it can calculate very precisely the order sizes and price).
The concierge creates each of this orders one by one calculating the current participants and their order sizes that will go into this bin starting by the lowest.
Each participant is considered to join the bin-order proportionally on their voting power if they qualify to this bin based on their ceiling price and order size. After the calculations and allocations for Bin 1 is made the allocated quantities for each participant are deducted from their total order and the next iteration for the next bin-order starts with the same rules.

In order to protect the Launchpad to be joined by paperhands that will join the priority purchase just to dump few minutes after the actual sale start the Concierge will lock the tokens for couple of days (for example will distribute the priority purchased tokens in the same time that unlocks the liquidity to the project team).

Also, because the algorithm supposes that there may be unused USDC (or SOL) tokens they should be returned immediatelly after the allocations are calculated in order the investors to have them liquid to use them for the regular pool if they want to. This can be achieved if the “Concierge” stops taking orders some time before the launch of the actual presale, so it can make the actual calculations and free the tokens that will not be used in the purchase.

Here is a very simple example with few bins and participants.
*NOTE: Examples are with numbers that are easy to calculate manually just so showcase the idea of the algortihm. In the real life bins are much more granular.

We have a pool of 5 bins (which represent the 10% allocation not all the tokens in the launchpad, the rest does not matter to the Concierge).

Bin 1 2 3 4 5
Bin size (tokens) 1000 2000 3000 4000 5000
Bin price (USDC) 1 2 3 4 5

Then we have 5 participants in this presale:

User Voting Power Ceiling Price Deposit
User 1 1000 1 USDC 200 USDC
User 2 1000 5 USDC 500 USDC
User 3 2000 4 USDC 5 000 USDC
User 4 2000 2 USDC 1 000 USDC
User 5 4000 5 USDC 75 000 USDC

User 5 is greedy and wants them all. But lets see what happens, when the Concierge starts to make allocations.

…
ITERATION 1

Iteration 1 Bin 1
Total Allocation 1000
Token price $1.00
Total Participants 5
Total Voting Power 10000

…
ALLOCATIONS:

User Remaining budget Allocation % Max Allocation Size Requested QTY REQ>MAX? Filled QTY Budget Spent
User 1 $200.00 10.00% 100 200.00 TRUE 100 $100.00
User 2 $500.00 10.00% 100 500.00 TRUE 100 $100.00
User 3 $5,000.00 20.00% 200 5000.00 TRUE 200 $200.00
User 4 $1,000.00 20.00% 200 1000.00 TRUE 200 $200.00
User 5 $75,000.00 40.00% 400 75000.00 TRUE 400 $400.00

Lets Explain the variables:
Remaining Budget - This is the budget that is left after the previous Iteration. Since we are at the first one Remaining is the same as the initial budget.
Allocation % - This is the Maximum Allocation from the current BIN that the user will receive. The percent is equal to the ratio of the users Voting Power to the Total Voting Power of all competitors in this iteration.
Max Allocation Size is the maximum number of tokens that the user can be allocated for this iteration. MAS=A%*TA
Requested QTY - this is the quantity that each users would like to buy. Assuming that the user wants to have his whole budget filled at the lowest possible price the Requested QTY is simply his budget divided to the price of the current bin.
REQ>MAX? - A simple check if the Requested Quantity is more than the Max Allocation Size.
Filled QTY - IF REQ>MAX? = TRUE, then the filled QTY equals the Max Allocation size. Else it will equal the Requested Quantity and then we will need to re-iterate the same bin in order to distribute the remaining tokens in the bin. (Example to follow in next iterations).
Budget Spent - this should be obvius :slight_smile:

In this Iteration example all users qualify to get their maximum Allocation, since they have enough budget.

…
ITERATION 2

Here we already lose User 1. While he has a remaining budget of $100 his ceiling price is set to $1 so he will not qualify for allocations at all in this iteration.

Iteration 2: Bin 2
Total Allocation 2000
Token price $2.00
Total Participants 4
Total Voting Power 9000
User Remaining budget Allocation % Max Allocation Size Requested QTY REQ>MAX? Filled QTY Budget Spent
User 2 $400.00 11.11% 111.1111111 200.00 TRUE 111.1111111 $222.22
User 3 $4,800.00 22.22% 222.2222222 2400.00 TRUE 222.2222222 $444.44
User 4 $800.00 22.22% 222.2222222 400.00 TRUE 222.2222222 $444.44
User 5 $74,600.00 44.44% 444.4444444 37300.00 TRUE 444.4444444 $888.89

…
ITERATION 3

Iteration 3 Bin 3
Total Allocation 3000
Token price $3.00
Total Participants 4
Total Voting Power 9000
User Remaining budget Allocation % Max Allocation Size Requested QTY REQ>MAX? Filled QTY Budget Spent
User 2 $177.78 11.11% 333.3333333 59.26 FALSE 59.26 $177.78
User 3 $4,355.56 22.22% 666.6666667 1451.85 TRUE -
User 4 $355.56 22.22% 666.6666667 118.52 FALSE 118.52 $355.56
User 5 $73,711.11 44.44% 1333.333333 24570.37 TRUE -

In this Example User 2 and User 4 have REQ>MAX?=FALSE. What we do is we fill only their orders at their Requested Quantity and then Re-Iterate for the rest of the tokens with the other users, that have a greater budget.
*NOTE: We can also perform a regular allocation in this iteration to the other users and then reiterate again only for the remaining tokens. I think ti does not matter, but either way the result would be the same for the users.

…
ITERATION 4

Iteration 4 Bin 3
Remaining Allocation 2822.22
Token price $3.00
Total Participants 2
Total Voting Power 6000
User Remaining budget Allocation % Max Allocation Size Requested QTY REQ>MAX? Filled QTY Budget Spent
User 3 $4,355.56 33.33% 940.7407407 1451.85 TRUE 940.7407407 $2,822.22
User 5 $73,711.11 66.67% 1881.481481 24570.37 TRUE 1881.481481 $5,644.44

After the Re-Iteration the Bin Allocation is filled so we can move to the next Bin.
In the real life there will most probably be several reiterations for each bin, since there will be a lot of players with different budgets which will be filled at different levels and it is possible to have users that at first iteration of a particular bin have REQ>MAX=TRUE, but after several re-iterations of the same bin they fill their budgets. In this case I made it simple just to showcase the idea.

…
ITERATION 5+6

Here you will see that User 3 will fill his budget on Iteration 5, and since they are only 2 users left in this example I combined Iteration 5 and the Reiteration for Bin 4 in one table, where User 3 gets his Requested QTY and User 5 gets all the remaining tokens in the bin.

Iteration 5+6 Bin 4
Total Allocation 4000
Token price $4.00
Total Participants 2
Total Voting Power 6000
User Remaining budget Allocation % Max Allocation Size Requested QTY REQ>MAX? Filled QTY Budget Spent
User 3 $1,533.33 33.33% 1333.333333 383.33 FALSE 383.33 $383.33
User 5 $68,066.67 66.67% 2666.666667 22688.89 TRUE 3616.67 $3,616.67

…
ITERATION 7

Iteration 7 Bin 5
Total Allocation 5000
Token price $5.00
Total Participants 1
Total Voting Power 4000
User Remaining budget Allocation % Max Allocation Size Requested QTY REQ>MAX? Filled QTY Budget Spent
User 5 $64,450.00 100.00% 5000 21483.33 TRUE 5000 $25,000.00

At this iteration User 5 is alone so he takes the full bin allocation. And while he still has a remaining budget to spent the total allocation for the Concierge is finished so there will be no more iterations and allocations.

Lets see what happened with our users at the end of the priority purchase:

User Total Budget Ceiling Price D Total Allocation Budget Spent AVG Price Remaining Budget
User 1 $200.00 $1.00 100.00 $100.00 $1.00 $100.00
User 2 $500.00 $5.00 270.37 $500.00 $1.85
User 3 $5,000.00 $4.00 1746.30 $5,000.00 $2.86
User 4 $1,000.00 $2.00 540.74 $1,000.00 $1.85
User 5 $75,000.00 $5.00 11342.59 $46,400.00 $4.09 $28,600.00

In Summary I think this (or similar approach) will be very beneficial for the Jupiter Launchpad because of several things:

  1. It will prioritise Investors before Sinping bots which usually try to dump shortly after they buy.
  2. It will also prioritise investors before paper hand traders because the of the token lock for several days or a week
  3. It will incentivise people to stake JUP and give a huge priority to the Jupiter Community wile it will not be a barrier for project’s community to invest since JUP staking is open to everyone and if timing is made right it will give enough time to anyone who wants to participate in particular project to prepare for the Launch of this kind of sale as well.

It is important to note that most of the Launchpads on the market “Sell” to project the idea that they have a community of investors, while in the real life if projects want to raise enough funds they need to do their own marketing and the vast majority of funds comes from their own community. This fact makes very few launches really sucessfull in general, while Jupiter as the biggest platform on Solana with a set of “revolutionary” measures have the real opportunity to cultivate a substantial community of small and medium investors and can make a real change on the market.

From projects perspective - this mechanism is also very beneficiary, because it incentivises mainly investors, who are not bothered to have their tokens locked for severals days or one-two weeks at least and know that those investors are also committed to at least one project - Jupiter with staking their tokens.

Of course it will be naive to think that this mechanism will completely “delete” speculative trade from LFG Launchpad, but it will at least give “the best share of the pie” to actual investors and to some extent to speculative traders, who will “dump” their best priced tokens at a much later stage instead of the very first minutes.

13 Likes
5

Hey thank you for your feedback! The idea of the tiers was to have a linear increase based on tokens held. The whales would be able to get the same advantage in a non tiered linear system as well. If for instance we took a non tiered approach with the same ratio of JUP to allocation. We would get:

200 JUP = 0.00005% Allocation

6000JUP / 200 JUP = 30

6000 JUP = 0.00005% Allocation * 30

6000 JUP = 0.0015% Allocation

The hope with the tiered system was that it would give someone with less JUP an allocation of up to x5 the value of their JUP. But really it only promotes splitting wallets and would be incredibly unfavorable for anyone already locked in. How would you feel if it was linear but the allocation increased every 200 JUP with a minimum of 200? Like so:

a = Allocation
r = Rate
j = JUP owned

a = ⌊ r * ( j / 200 ) ⌋

2 Likes
6

Thank you for your feedback it’s much appreciated. So the idea would be, everyone with at least 200 JUP would get the same allocation or are you saying we should have a linear progression for JUP over 200?

5 Likes
7

Same unlimited possible allocation yeah. I think that’s the only fare way to give everyone a chance.
Priority fees are another challenge I would consider. How can we leverage that? Offer the DAO 2X built in priority fee? Perhaps 2x to the limit of the base max they set? What do you think :thinking:?

3 Likes
8

I don’t dislike the idea of allocating airdrops to truly invested members at all, however I’ve been spending time on the research pages trying to be a productive member of the community and would not benefit from 200 being the minimum. I never received the initial jup airdrop, but I bought and held jup since the day it was introduced. My limit for staking was a bit lower tho due to the circumstances. I would have loved to hold/stake more, but should that mean because I’m not my participation should not be acknowledged? Or is it a tough luck situation? I’m not mad at anyone personally just wanted to bring this to light if it’s being discussed

7 Likes
9

There isn’t a need to complicate with any tiers or minimums.

Can simply do this;

a*(b/c)

Where
a = Total Allocation of Launch Token
b = Your Staked JUP
c = Total Staked JUP

For example with 100m Locked JUP, 2000 Individual Stake, and 50000 Allocation total;

50,000 * (2000 / 100m) = 100

100 of 50,000 = 0.002%
Just as;
2000 of 1,000,000 = 0.002

This way everyone gets the same ratio of allocation regardless of how much they have or however many wallets they split between or not.

4 Likes
10

Im interested in this but im still trying to figure out the current settings? How does the voting power work? How are the allocations set up? Is there a holding period etc

3 Likes
11

This is a very fair criticism, a 200 JUP minimum might be too high. I think that worza’s idea of a flat linear allocation with no minimum is a good idea.

4 Likes
12

Hey currently 1 JUP = 1 Voting power. Rewards are distributed linearly from the rewards pool based on how much you exercise your voting power in votes. Rewards are distributed quarterly with the next drop being in June.

If you meant for my proposal. I would want the allocation to be based on voting power like the rewards but I’d want the tokens bought during priority sale to be accessible at launch.

3 Likes
13

I’ve read this through a couple of times and I have to say you have proposed an incredible idea. I really appreciate how thoughtful you were. Is there an example of this being done somewhere else? The bins increasing in price is really smart. One of the things I was worried about was how to impact price the least. I think if we were to implement something like this you would have to notify people of the bins they’re participating in though, or at least give a value average per token before paying.

What I like:

  • Bin pricing will decrease the effect on the price of the token

  • People can be greedy if they’d like to

  • Locking up the tokens won’t disrupt the launch

  • The participation in the presale will give the launcher’s an idea of how the launch will go.

Potential updates:

  • Notifying the user of the bins they’re going to be participating in
3 Likes
14

This is actually the way the LFG Launchapd works splitting the tokens in bins.

So what I actually did was to make something like “fair launch” system that acknowledges the bins system that already powers the LFG and adding quota based on the Voting power and adding a ceiling price so people can decide their ceiling to enter the auction. (I suppose that everyone will set their ceiling price the same as the maximum price for the priority sale but yet it is a nice feature to allow people to set their ceiling.

About the notification. This system cannot pre-calculate the allocation since they will change dynamically as users join. The only way to calculate the allocations is after the priority sale is over.

About the idea - I personally developed on top of your idea for a priority launch but I see it happening at the same time as the launch it self. For example - people can join the priority sale no more than 1 day prior to launch start and the actual allocation to happen in the last 15 to 60 min before the public sale starts.

2 Likes
15

I think the key here is minimizing the abuse that could happen from people holding multiple small 200 wallets, so that it doesn’t ruin it on the rest.

1 Like
16

Yeah I dont like the idea of limit based on holding. It creates a scenario of feeling worthless or that voting blocks would take over.

2 Likes
17

Why not set 10k jup as a minimum for the lowest tier?
We are community driven project or what?
I can agree with 50 jup as a min.
But 20 jup is better.
Why?
I remember 2021, and some project went broke just of bad approach, by setting high threshold.
I hope the team does not make such a mistake.
As well as changing limit due to market conditions.
Rules must be clear and in place at least 3m.
And change must rake place in 1m after DAO vote.

3 Likes
18

I think 10k jup would not allow a lot ppl to participate…

2 Likes
19

I agree, how could we potentially incentivize quality over quantity, and consolidated assets in one wallet over multiple?

Coding, apps, tutorials, automation, resi proxy bundles (for all you shoe bottlers out there) allow a lot of people to execute Sybil farming and get away with it.

Even ghost cc generators, recaptcha and other tools get people around some kyc and Sybil prevention.

How about gated access that can’t be auto solved, bypassed or removed as proof of ___blank.?

Play a quick game to gain access to staking/voting? Some sort of token/badge or nft system?

Thoughts?

DC—

2 Likes