Changing formula for MNGO rewards in Liquidity Mining

In that case, I’m in favor of reducing max_depth to 100 as a quick fix.

After changing to (100, ^2) it’s still pretty bad. How about (100, ^8) which can be done in the next program upgrade?

I see people quoting massive size pretty deep in the book and getting almost no fills but collecting a lot of MNGO.

My only fear with (100, ^8) this is that there wont be enough liquidity deeper in the book in the case of stop losses or mass liquidations. We will definitely see more participation closer to the top of the book which will help the user experience. There should still be some incentive for sticking out further back as well but without hurting those that are risking higher up.

In my eyes the big players with large stacks sort of sap the rewards from the front but they still deserve some reward for this right? Give these liquidity providers the option to do this without hurting those near the top. I suggest possibly 2 functions that distribute mango one with an emission period of 1500 mango/hr and one with 500 mango/hr. The first function will be as you describe (100, ^8) to encourage people to provide liquidity at the front of the book. The second function can be (200, ^4) and just be very rewarding to big stacks without really affecting those that want to provide liquidity near the top.

In addition to this I noticed that sometimes in times of high market volatility some bids are pulled which can lead to some very bad results. I believe this is what happened with BTC perp went down to 35k. Sometime in the near future we should incorporate some sort of volatility parameter into the reward system.

Well how do CEXes get liquidity deeper in the book? The market maker programs I’ve seen usually only give rebates and incentives to quote near top of book and leave the deeper liquidity up to the market to provide.

One reason why ppl provide liquidity further out is to catch “wicks” from liquidation mechanisms. But because of how Mango does liquidations, where it is off-book, this is not providing that incentive.

TBH i think the bigger problem is flow not being there. I know it’s chicken/egg, but if more ppl go to Mango and use it to trade perps then liquidity will fill out, esp with incentives within 100bp. Are we just hoping that word of mouth makes this happen? Should we be talking marketing instead?

Alternatively, I remember someone on Discord suggesting (sorry can’t remember who to give credit, but was not my original idea) – to have “bands” where you offer say 2,000 MNGO within 100bp, but then 500 MNGO from 100-200 bp and then 100 MNGO at 200-300bp (with similar curves within each to keep the incentive closer to bbo)

1 Like

A trading competition was suggested in another thread Incentivising trading on PERP markets - #7 by plopps

Which is not without some dev work and there may be easier forms of marketing (some kind of referral mechanism to turn users into shills?)

I think its important to remember that market makers do in fact an overhead cost of transaction fees and have a 400ms delay when putting up orders so its not as easy as a CEX. Not really sure how many people will market make with almost 0 reward and not enough volume to actually get hit.

Going off what austerity said bands or a multitude of functions is probably the best way to get around the lack of liquidity up close while still rewarding some liquidity in the back. It is a great idea but you would have to tweak them to overlap or else there will be “deadzones” which actually give less rewards than being a little bit further back.

Adding on to this the 2000 mango/hr is enough it just has to get distributed in the correct way.

I’m just thinking more about incentivising liquidity closer to the book, and it occurs to me that we should just incentivise maker volume.

What if you cut mango rewards back down to 1000/hr, but gave ~5bps worth of mango out to makers. It keeps fee structure at 0bps/5bps, so it doesn’t look like a shady 0-take exch, but really incentivises people not only to provide liquidity that never gets hit, but to compete to be the maker.

It could effectively cut the SOL spread in half… (if it’s currently averaging ~20bps, and makers are willing to move each side in by 5bps).


I like this idea, -5bps/5bps so DAO revenue is 0 for now

1 Like

Having a maker rebate would incentivize thick, tight books. I would look to make it a permanent feature though.

I’m going around in circles here, but I’d like to propose another solution that I hashed out in discord:

What if we split the rewards into two 1000 MNGO buckets,

  1. 100 bps depth - just like it is now, this incentivises deep books.
  2. 0 bps depth - Only rewards those who place orders at or improving the inside. It will encourage tight markets as improving the inside will offer serious rewards.

We can avoid having to hash out a number for a maker rebate, but also incentivise and reward those making the closest, tightest market. I would put a minimum size to earn on #2, having someone set a new bid with 0.01 sol shouldn’t get all the points. Potentially, we consider the first $1k as within 0bps. Open to ideas here.

Wow this actually a very good idea and I think it has potential. This really could have a good effect and probably wont fall victim to wash trading. Reading more on the algorithm used to award mango the calculation is only done once making the function O(1). I think a few improvements can be made to make this function even better and more rewarding overall when considering how the function currently works.

Any of these conditions can trigger a reward from the second bucket:

  1. 0 bps start - This will give mango rewards to those who place their orders at the top of the book or match the top offer. Order must be canceled within 20 bps or get filled to receive points from this secondary bucket.
  2. Depth <= 20 bps start + Maker - This reward will only be considered for this bucket if the order actually becomes the maker in the future. Otherwise this reward will get the normal distribution of points from the normal bucket. (Unsure how the formula could work with partial fills)

Extra limitations and restrictions to these orders to avoid abuse:

  1. Unix time limit for rewards are capped at 10-15 minutes to avoid farming points when you don’t get filled for a long time. Important to note that this bucket is a fast moving incentive and not supposed to be farmed for hours on 1 order.
  2. Order must start with a size more than $250-$1000 depending on what we see fit.

I like the idea, but it seems a bit complex. There’s a lot of value in having something simple and easy to understand while still achieving our goals. Do you think it provides sufficient improvement over @iwillnotsaveyou’s idea?

Really hard to say without trying it out honestly. I do think it will benefit the book over what we currently have so in my opinion the only issue I have is if it can be abused or not. I do think the restrictions on the side are crucial such as a max time limit for this bucket of rewards to avoid farming for hours or days.

Edit: In general I think the first step is to try changing the way the function is done to (50, ^4) or whatever you had in mind and seeing the effect it has then adding this if that still does not work.

Rewards release schedule for RBG model - Three token rewards with power to the half PI rewards on a scale of 1461 days (4 years) from daily 0.01% to 314% compounded (end of year 4) here distributed in the chunks of division of 7 R, 77 G, 777 B

import numpy as np
import matplotlib.pyplot as plt
plt.rcParams["figure.figsize"] = (10,10)

max_days = np.pi * 465
total_number_of_tokens = 21000000000 #21 Billion
total_number_of_rewards = 0.43 #43% for rewards
total_hft_rewards = total_number_of_tokens*total_number_of_rewards

def power_half_of_PI_reward(vesting_days, power_risk_curve=np.pi/2,
                       min_profit=0.0101, max_profit=np.pi * 100,  # (0.01% - 314%)
                       min_days=1, max_days=np.pi * 465):
    y = [min_profit, max_profit]  # two given datapoints to which the exponential function with power pw should fit
    x = [min_days, max_days]
    pw = power_risk_curve
    A = np.exp(np.log(y[0] / y[1]) / pw)
    a = (x[0] - x[1] * A) / (A - 1)
    b = y[0] / (x[0] + a) ** pw

    return round(((vesting_days + a) ** power_risk_curve) * b, 7)

def power_half_of_PI_reward2(vesting_days, power_risk_curve=np.pi/2,
                       min_profit=0.0101, max_profit=np.pi * 100,  # (0.01% - 314%)
                       min_days=1, max_days=np.pi * 465):
    y = [min_profit, max_profit]  # two given datapoints to which the exponential function with power pw should fit
    x = [min_days, max_days]
    pw = power_risk_curve
    A = np.exp(np.log(y[0] / y[1]) / pw)
    a = (x[0] - x[1] * A) / (A - 1)
    b = y[0] / (x[0] + a) ** pw

    return round(((vesting_days + a) ** power_risk_curve) * b, 7)

number_of_days = np.pi * 465
days = np.arange(0, number_of_days, 1)
curve = np.array([power_half_of_PI_reward2(day) for day in days])
infl = np.array([power_half_of_PI_reward2(day) for day in days])

i = 1
rewards_budget = total_hft_rewards
rewards_budget_1 = total_hft_rewards
rewards_budget_2 = total_hft_rewards
rewards_budget_3 = total_hft_rewards
avg_rewards_per_days = total_hft_rewards/number_of_days

reward_plot = []
budget_inflation_1 = []
budget_inflation_2 = []
budget_inflation_3 = []

for c in curve:
    reward_emission_1 = rewards_budget_1 * i / (number_of_days-i)/7
    reward_emission_2 = rewards_budget_2 * i / (number_of_days-i)/77
    reward_emission_3 = rewards_budget_3 * i / (number_of_days-i)/777

    rewards_budget_1 = rewards_budget_1 - reward_emission_1
    rewards_budget_2 = rewards_budget_2 - reward_emission_2
    rewards_budget_3 = rewards_budget_3 - reward_emission_3


    print("Day " +str(i) + " Reward: " + str(c)  + " Governance Token issued: " + str(round(i/max_days*100,4)))
    print("reward budget " + str(round(rewards_budget,4)))
    print("reward emission " + str(round(reward_emission,4)))
    i = i + 1

plt.annotate("1 day - daily inflation " + str(budget_inflation[1])+ " CHFT " +str(round(1/max_days*100,4)) +" Voting power Available", (1, budget_inflation[1]))
plt.annotate("**** 3.9 year -  daily inflation " + str(budget_inflation[1390])+ " CHFT " +str(round(1390/max_days*100,4))+" Voting power Available", (1, budget_inflation[1390]))

fig, ax1 = plt.subplots()

color = 'tab:red'
ax1.set_xlabel('Vested days - maximum 4 years = 1461 days')
ax1.set_ylabel('release schedule rewards')
ax1.plot(days, budget_inflation_1, color=color)
ax1.plot(days, budget_inflation_2, color='tab:green')
ax1.plot(days, budget_inflation_3, color='tab:blue')

ax1.tick_params(axis='y', labelcolor=color)

ax2 = ax1.twinx()  # instantiate a second axes that shares the same x-axis

color = 'tab:purple'
ax2.set_ylabel('Purp (purple) - locked voting power to half PI based on RGB pool vesting', color=color)  # we already handled the x-label with ax1
ax2.plot(days, curve, color='tab:purple')
ax2.tick_params(axis='y', labelcolor=color)

fig.tight_layout()  # otherwise the right y-label is slightly clipped

#plt.plot(days, curve)
fig, ax_left = plt.subplots()
ax_right = ax_left.twinx()

plt.xlabel('Vested days - maximum 4 years = 1461 days')
ax_right.label('Daily reward emissions')
plt.title('daily distribution schedule for total supply of 9 Billion R1/G1/B1 for liquidity mining \n collateral rewards (lending) for 43% of R1 token (ratio 35% vesting rewards / 8% buy G1 token) \n  orderbook liquidity rewards for 43% of G1 token (ratio 35% vesting rewards / 8% buy B1 token  \n vested power rewards for 43% of B1 token (ratio 35% vesting rewards / 8% buy R1 token) ')

plt.plot(days, budget_inflation_1, 'r')
plt.plot(days, budget_inflation_2, 'g')
plt.plot(days, budget_inflation_3, 'b')
#plt.plot(days, reward_plot, 'b')
#plt.plot(days, c, 'g') # plotting t, c separately

How much does FTX, Binance, etc. spend on market making?

Obviously they have more users so at a certain point the market can make itself to a certain extent, but presumably they still have some deals in place.

We tried (50, ^4) and it wasn’t good enough because most of the risk was being taken by those at the top of the book, but vast majority (90%) of MNGO rewards were going to quoters quoting wide with very large size. We also are now trying (0, ^1) but it’s not going to work well unless there are competent full time market makers focusing on building systems for it. The rate param is moving around wildly and Mango blocks are taking much longer/shorter than the targeted 1 hour.

I’m working on building Top Size LM which essentially rewards the top N contracts quoted on the book. It’s a little bit hairy to make these changes while contract is already deployed. But I think it’s possible and I think it can be done in a week. But until then, we need to decide on what to do about liquidity mining.

Proposal 1

Reduce LM rewards to 0; Change fees to -4/5bps to reward MMs. And turn on LM again once Top Size is implemented

Proposal 2

Keep LM rewarsd but change it to something more reasonable like (20, ^4) or (20, ^8) until Top Size is implemented.

We also need to decide on some key design factors of Top Size, but maybe those technical decisions are better had in discord. We discuss them in the #governance channel.

Please advise on the liquidity mining!

New forum user, so pardon me if I point something that has already been discussed. It seems like full-time market makers would need a programmatic interface. Does such a thing exist?

I know the Citadel team was working on a Mango .Net interface. Perhaps some of the rewards would be better directed towards creating such tools.

1 Like

Yes, we’re waiting on locked Mangos in the DAO to be able to reward people appropriately.

Perfect. Citadel seems useful for an individual, but I’d expect that if we want full-time market makers, we should put out a MNGO bounty for something like Ichibot. This is likely a separate topic, though.

1 Like