xComb Farming and Allocation Points Policies

lkngtn · June 4, 2021, 8:49pm

Really excited to have xComb and the farms launched and in the wild. The initial pairs were chosen by the Tulip swarm in order to get things rolling, however, the intention is for the allocation of farming rewards to be adjusted over time in order to curate the liquidity that’s available on the platform and attract volume to the exchange.

Currently the ability to adjust pairs and allocation points is held by a multisig of Tulip members. This is a privilege that can be revoked or adjusted via 1Hive decision votes if desired. By giving discretion over this function to the Tulip swarm we hope to be able to be more agile and strategic with pairs and allocations and is also in line with 1hive’s general governance philosophy of reducing the frequency and need for discrete decision votes where possible.

So how will the Tulip swarm manage allocation points and pairs? Thats something we are are still working on and would like to use this thread to propose, discuss, and gather input on policy choices.

Allocation Points System

The farms work on an allocation points system, which means that each block rewards are distributed proportionally to farmers based on the allocation points that have been assigned to each deposit token. Say we have two deposit tokens that have been registered (say ABC and XYZ), if both ABC and XYZ each have 1 allocation point, each would receive 50% of the rewards per block. If instead ABC had 9 allocation points, and XYZ had 1, ABC would get 90% of the rewards and XYZ only 10%.

The current allocation points distribution can be found on the wiki, which we will keep updated, but at the time of writing the distribution looks like this:

There are currently 45 allocation points assigned, so the xDai-xComb pair at 20 points is getting ~45% of the rewards, and 4x the amount of reward as the next highest pair. This pair is really important for the farms to work which is why it is weighted so highly, people who are providing liquidity on that pair are helping to establish and stabilize the market for the reward token.

As we add additional pairs and adjust allocation points, we need to think about the relative impact on the existing pairs. Adding an additional point will decrease the relative share of all other pairs, and in an extreme case adding a lot of points could effectively dilute the rewards of all other pairs two nearly zero.

The allocation points system at its core is quite flexible, but because of that there is a pretty large space for considering policies for managing these points.

Allocation Points Policy Considerations

Personally I think the following considerations are really important when considering potential policy for adjusting allocation points.

Predictability is important, if the allocation points are constantly changing it liquidity providers will be discouraged from participating and will almost certainly avoid locking their liquidity for extended periods of time… Imagine you are farming and you lock your deposit for 4 months to get a 2x multiplier, and the next day the points get adjusted decreasing the relative proportion of rewards on the pair you are locked into significantly? In order to avoid this we need adopt policies that make changes in allocation points predictable and stable enough for LPs to comfortably participate in the farms.

Curation is important, because the fundamental goal of the farms is to attract liquidity in pairs that users want to actively trade on. Liquidity for liquidity’s sake doesn’t necessarily translate into volume, and without volume we don’t get fees, and without fees we aren’t supporting a positive value feedback loop. We can approach curation in different ways, and I think think this will likely be the where the bulk of discussion on this topic happens.

A Policy Example

In order to kick of discussion and gather input, its helpful to describe a potential policy that the tulip multisig could use to manage allocation points. A policy doesn’t need to be written in code and can depend on subjectivity and discretion, but it should be specific enough so that its clear how pairs would be added/removed and how allocation points would be likely to change over time.

For example, this seems like a relatively simple policy we could document and adopt:

First we would break the total allocation into categories, each category would have a fixed number of allocation points to distribute to pairs, and may have a different policy for how to manage redistribution of those points over time.

30 points for Keystone pair - the main pair for the reward token (eg xDai-xComb) having a section specifically for this pair so that it would always get at least 30% of rewards.

30 points for Strategic pairs - long term strategic selections (eg the existing pairs other than xComb-xDai would fall under this category), allocation points in this category would discretionary, but the rate of redistribution would be limited to 5 points per month, so the rate of change would be quite gradual.

30 points for Performance pairs - pairs picked based primarily on volume metrics encouraging communities to funnel trading activity to honeyswap in order to compete for additional LP incentives for their tokens.

10 points Discovery pairs- tokens could apply to be incentivized as part of the discovery allocation and be evaluated based on their merits, rewards would last for limited time (eg 4-6 months) and be limited to a specific number of active pairs at a time each token would only be eligible for discovery once so that discovery pairs remain fresh.

Blazingthirdeye · June 5, 2021, 5:59am

Thanks, this helped me better understand the issues at ‘stake’. I had read about the allocation points but I didn’t grasp how they played out in reality. It doesn’t need to be overly complex as your example plan shows. I like the restriction on rates-of-change for the strategic pairs. This idea is important so we can lock in those 120 days. In this example there is no mention of the quantity of pairs in each category. Since the allocation points must be distributed among all the pairs within a category there would be a drastic difference if only 2 pairs split the points versus if 12 pairs had to split up the points. So it is worth considering how many pairs will be permitted within a given category.

I believe Tulip Swarm is best suited to manage this. However, it might be worth allowing guest ‘consultants’ to share their thoughts with the Swarm via a structured path like a suggestion box or a short voice call. If there is someone in this community who cares enough to make their opinion heard then they probably have valuable input and I want to hear it. Or rather, I want Tulip to hear it.

jasselnorm · June 5, 2021, 11:47am

Maybe the policy itself could provide the predictability that points will be increased for xComb if it suffers too much (how much?) of a loss in liquidity. Keystone guarantees “at least 30% of rewards” so it implies there might be conditions where over 30% is desired, but how are these conditions to be defined? Making this a written policy in the future rather than a purely subjective and discretionary reaction could provide more confidence in xComb and Honeyswap farming.

Agreed, but I think it will make sense to progressively add guarantees with Celeste. There may still need to be discretion in a phase 2 of the decisionmaking process if there are too many submitted and accepted pair parameters; otherwise, the curation with Celeste would need to be quite strict. A final curated list can be reliant in part on compliance with a certain discretionary governance process.

It occurs to me that the Strategic pairs are the ones with the most discretion, while Keystone is set in stone, Performance is “based primarily on volume metrics” and Discovery is based on “merits”. Therefore, the latter ones are great candidates to be curated with Celeste and sufficiently determined criteria.

In what circumstances does the Tulip Swarm intend to consider certain pairs to be “Strategic” apart from the other categories (Performance and Discovery) with actual or expected high volumes?

For future decentralization, does the Tulip Swarm have any “Governor” infrastructure in mind that could make this adjustment an optimistic action per the state of the curated allocation (such action and curation being subject to denial by Celeste)?

In the long term, hopefully Celeste can be used. In the meanwhile, I (and certainly others) would appreciate such openness, so please let us know here when it’s decided.

Bau · June 5, 2021, 5:00pm

I think allocation points are good method for distributing rewards across the different pairs. I’m not sure if this could be done, but it would be neat to have a maximum and minimum defined for the pair categories to guarantee some level of predictability in the changes in allocation points, and also make rewards dynamic.

So for instance if there was a performance pair where the volume traded on honey for that token fell below a certain threshold (whether graduated or not) the rewards for that performance pair could be adjusted to the minimum for all performance pairs and be reallocated to other performance pairs that presumably saw an uptick in volume.

It would also be really neat to see LPs them selves having discretionary decision making power over these different pairs, such that they are able to vote on allocations of rewards to different pairs based on the policies put in place, and maybe these people governing policy can also be rewarded for their efforts.

I’d advocate for as simple of a design as you can go for, with as much of the parameters written in code to guarantee some level of predictability and stability in the rewards across the system. I was also thinking depending on the relative performance of rewards across each category, you could possibly readjust allocations between strategy, performance, & discovery to incentivize the pairs that are the most performant in their own category. There will likely need to be limitations to the amount of pairs in a given category as well, which is something I am not knowledgeable or don’t feel very confident speaking to.

Thanks for your patience in me getting back here!

Eth_Man · June 5, 2021, 6:23pm

So lets try to be clearer about the mechanics here.

The number of points allowed is allowed to be what? 0 to what?
The number of pairs allowed is what? 0 to what?

Is 0 even allowed?

Let’s move on to the next question.

What is the total reward curve? Is it changeable at all?

I understand how to normalize the points against the drip. That part is easy.

Lets move on to your considerations:

While I can understand this - lets point out one important fact. A single person could extract liquidity or ADD it during the time of the lock - so your predictability of return from a user perspective by locking tokens is basically impossible. Just because the returns are set with so many points gives almost zero predictability to a user as to what return they will get because of this one fact.

So lets set ‘predictability’ aside because users won’t get it based on this system.

Move on to the next point.

I am not sure i like the term curation - and prefer ‘management’. Because this is exactly the goal one is trying to achieve. Management of rewards against volume. Yet the farming rewards only provide rewards for people to deposit LP, not as a reward for trading. This is really the hitch here. We have already seen that LP doesn’t make volume, but we know the reverse is true volume eventually will bring LP (because fees will generate returns that will bring volume and this usually creates a strong positive feedback loop).

I have asked repeatedly for a decent set of analytics regarding Honeyswap LP and trading so that we could apply data analytics to changes in farming incentives. How exactly are we going to measure that trading changes in a pair in response to farming incentives. In tracking my own LP performance I have learned that tracking the incremental and then the moving average of return rates over different time frames can tell me more about the trading volume relative to LP volume. What I don’t have is decent trading sizes in bin histograms to look at (in time windows so I can compare to the moving averages of interest) if volume changes are related to lot sizes changing, or whether there are just more of the same sized lots. This is an important metric because there is this claim that slippage reduces trading, but based on my experience this is mostly true on networks where the total cost of doing a transaction (network access fee) is high relative to the trading size (basically network fees force the users into higher slippage trades). If you have low network fees you can do multiple trades over time to manage slippage.

I have seen ZERO new data regarding this issue that leads me to believe artificial enhancements in LP actually improved trading lot sizes. In fact the only data I had from the HNY-xDAI pair from September-November showed in the previous farming episode that trading lot sizes decreased as LP farming came on line (indicating insiders did larger buys to get in before farming - and then everyone farming was trading out or around during farming). LP didn’t help trading size - but it brought in some volume in the smaller lots that only stayed while farming was attractive.

So if we are going to end up talking about curation, or management lets get our data analytics together on this so we can finally be on top of the data on this subject since I think without data we are all just speculating.

There are two things I like with current farming setup.

A new token dripping out provides the reward backbone. This will increase LP artificially until rewards normalize then it will stop. If the COMB price drops it can create a negative reinforcement loop where LP removes and then sells, causing the price to drop further causing LP to leave and sell leaving the locked liquidity holding losses.
The ability to shift rewards.

What I don’t like.

The overall rewards drip in current incarnation can’t increase or decrease. I believe this is bad because management requires not just ‘redistributing’ rewards but having the ability to increase or decrease them across all assets. Put simply the drip of xCOMB being predictable means it is no longer manageable. You can slosh COMB rewards into new pairs but you can’t stop them. Ignoring COMB price elasticity in this farming model is inherently bad from a tokenomic standpoint.

I don’t know smart contracts that well but I did have an idea regarding this. Is it possible to put into the farming drip contract the ability to ‘split’ the reward drip (as a % from 0-100) so that say I set the split to 90% then 90% of the scheduled drip goes to rewards as normal but 10% goes into a ‘recycle’ contract? So they aren’t burned but just collected for governance to decide what to do with them (burn, do another airdrop whatever). The point here is that this kind of adjustment allows rewards to go down - but not up. I like that from both a predictability and management point of view because from my own point I would use the data analytics to manage this split/points farming drip so user returns are more predictable potentially. Realize the goal here is to both provide reasonably stable rewards but the key focus is to manage rewards so trading fees increase providing the long term health and sustainability to the system as a whole.
Lack of data analytics to drive management and curation. If we are going to go down this road with farming rewards lets get some working analytics going. I see this as a huge void. I am tired of guessing these things and want to see some real analytics driving decision making.
I think if we can do (1) we might be able to solve another problem with how to manage drips of multiple tokens via the same contract. If there is one thing to solve in this farming approach it is a way for communities to pool their liquidity rewards so that for users there is a single stop where to get all of their rewards. Having this unifed means calculating total farming returns will be easier and consistent. It can make the farming pages the key single point of farming access for users (a big plus because we then would be able to use some or the real estate there as advertising space. Note if these farming analytics are done well they would also include the daily LP fees in the COMB APY calculations.

My point here is if you ignore the base fees in the APY in rewards you basically are missing the biggest piece of data regarding whether a LP needs more incentives or not. I mean if wETH-xDAI is paying 400%/yr from fees - do we really need to another 300%/yr on top of that (maybe we do - maybe we don’t). The point here is that LP fees as a percentage of the total return are probably one of the key metrics to look at when deciding whether to incentivize a particular pair.

Now to policy.

Personally in my own report elsewhere it is my goal to adjust returns to manage daily returns to something like .1 to 1% (36-360%/yr not compounded). In fact in my own LP tracking I tend to look more at the daily returns because some of these automatically compound, other ones need to be done manually. I generally feel the markets are going to go after returns >1%/day quite strongly and this makes these kinds of returns unsustainable where as .1%/day 36% seems to be reasonably sustainable. I want to put these returns in perspective because it is hugely important to someone locking xCOMB-xDAI expecting like 3-4%/day for 120days when at the end of this due to price decay they could lose 50%-80% of their investment (something we really want to avoid). This was true of the previous HNY farms btw (even without locking), people hoping that their IL would be compensated for by the high HNY farming return that found when HNY drops by 80% a .5%/day return just doesn’t make up for it.

Ask me how I know?. Because I got hammered in at least one of the pairs before I got smart and got out before the HNY price dropped the remaining 70%. I have seen this scenario repeated multiple times in different farming situations (elsewhere) and it is why LP comes quickly and leaves quickly. The first ones to the doors usually getting the best returns moving on to the next farming gig.

Too many people tend to think of this farming from a single side. Either as an exchange or new project trying to garner attention and liquidity for trading somewhere, OR as a user trying to invest or get return by investing. Rarely does anyone look at this as a complete picture balancing the needs of the community against the needs of the investors. Too often either the community is using the investors, or the investors are using the community depending on the situation being set up.

1Hive community has always focused development on being long term sustainable. This is why we tend to move slower and don’t flash in the pan as much. This has pluses and minuses. My concern is that we are being forced to give up on core principles to do things quickly and are failing on both counts. Not doing things fast enough, and also not giving enough time when we decide to do something to come up with:

Project requirements that must be met
Reasonable timelines
Funding to satisfy (1) and (2)
The big one - the ability to version. I mean we came out with farming v1, and now have farming v2, we should already be looking at farming v3 as well as farming analytics v1.

The lack of analytics here is a huge gap that needs to be filled here.

I think we have enough tools to manage policy but what I want to see in these endeavors is some idea that we will have to transition a vN to a vN+1 say in the near future. The way these spaces are moving is that we are constantly adding new features and this creates both a PR, documentation stress (no documentation is ever complete because the features are constant moving targets that also don’t have core requirements clearly laid out - or are a documentation after thought) as well as developer stress because devs are constantly moving forward and never really looking back except to deal with operational problems (ugg).

I want us to learn how to be faster up front, and a bit slower on the back end because of this. Everyone else is doing this rapid development blazing ahead and just leaving a trail of mess behind them. This inherently leaves users some number of steps behind, documentation filled with gaping voids, and everyone else struggling to keep up and a general lack of consistency in anything much less sustainability.

I get tired of having to try to correct issues after the fact that could have easily been forseen in onset if even one requirements document had been put forward before the coding work started. I have learned that smart contracts and particularly the users using them DON’T get edited after the fact (typically you don’t want that btw) which means you better get what you want right in the design phase because if you don’t you are going to have to do it all over again - or worse people just call things good enough and move on. I don’t expect perfect systems. In my experience there is no such thing as a perfect system. But there are systems and software that met requirements and/or planned for the inevitable upgrade paths (on inception) vs. projects that had people with ideas, did development, and found that the system was never complete because they were constantly adding and changing things. I have seen massive projects and companies fail because they ignored this one key point in project management. The fact that a project needs an inception point, and a completion point and then transitions into the field as an operations maintenance project. Clean points of inception and completion are required if one is going to create documentation, manage development requirements, and meet project performance goals and more importantly time lines.

Lets look at what we need here as well as what we have so we can finalize v2 farming into a operational management mode and start looking at a v3.

Analytics
Documenting v2 features and bugs as they are now.
Documenting a wish list for v3 features that leads into a v3 requirements document.
Setting up the v2 operational team requirements doc, and performance measures for v2 now both on xDAI, Polygon, etc.

I think it would be prudent to also document and distinguish whether there are differences between different chain implementations. Farming v2 on xDAI may be different than Polygon or Arbitrum. Or maybe we go with a v3 for Arbitrum. idk what I do know is that the above is a requirement to manage these things as well as provide consistent documentation. This is going to be even more important as we move development, and operations and various infra cross chain with each build a potential operational legacy support project

Rohekbenitez · June 5, 2021, 7:44pm

excellent, information thanks @lkngtn , in particular I only have a question if in the future other pairs are added to the yield farming, would that affect the current score?

Under what arguments or decision would they add new pairs, many acquaintances have asked me and I do not know what to answer them about it.

thanks and blessings to all the members of this great community 1hive

wikisum · June 6, 2021, 4:16am

Sound great , I love HNY, Xcomb

project_uwb · June 6, 2021, 6:16am

Luke… thanks so much for that long and detailed thread on how the allocation points system and farming rewards unfolded. I have to admit I am pretty new to the mechanics that run farms and intrigued at how a cohort of people would manage the rewards distribution to ensure best for 1Hive/ Honeyswap and xCOMB.

100% on this, even as a newbie, I think one thing that I want to be sure about is a level of predictability. I agree if rewards are changed at random, I almost feel helpless as I have already committed to 120 day locks on a couple of LPs assuming that change in APY would not be like drastic i.e from 0.5% per day to 0.05!! That is totally on me for aping into these without understanding how the levers behind all this works … lmao … but will use this as a learning exercise.
I think if this level of change is to be done, it would be good to at least give LPs an option to be able to unstake with a docking fee.

I really like your methodical approach on allocation of points and the various categories that you have defined. It would be really nice as a community member and a farmer if Tulip could elaborate on these categories and how some of these pairs were considered and what would drive change to these pairs.

Could I suggest a community call, where something like this could be bought up so that the community and anyone else interested could join and at least get an insight into the decision making? @CurlyBracketEffect unsure if this was already covered off in your earlier podcast, but I think this could be a topic on its own.

I am also using these farms as an educational play so that I understand how this type of farming incentive drives liquidity, pool 2 economics and all the other economic activity it stirs up. @D0SH I know you had a podcast planned on focussing on educating users with facts, would you consider one of the topics? A deep dive into LP farming, Pool 2s, adjusting strategy and how successful farmers use farms?

I am gonna keep a close eye on this topic, but somehow fee that a much better medium for discussion would be like a community call. Would be nice to hear what others think here!

GreenHornet · June 6, 2021, 8:54am

First and foremost, Congrats to tulip swarm!!! you guys are real superstars. im not going to touch too much on the finer points of the mechanics, i feel like there is going to be a through discussion on that @Eth_Man lol

going to comment on a few of these points though

predictability of return is not the goal, your right, that is not possible. but what predictable is the relative proportion of the reward per block. That is a reasonable thing to guarantee

defo dont want to get into unnecessary semantics, but this one is important. Curation is the process of selecting a universe of pairs and letting the market decide is what works. This is a bit art as well as science but i also agree management is also needed as well. I also agree with your broader point of the need for more analytics to drive the decision making process.

This is the most sensible and prudent thing to do in the short to medium term. As with most DAOs, consensus around governance decisions happen offline in discord, the onchain votes are usually to ratify what has already been decided. These forums are open if you really want to know whats happening and influence the outcome. That being said, due to the nature of the medium, its easy to miss when and where the relevant conversations are happening. This is not usually a big deal but the decisions being made will have significant financial implications for LP providers.

100% echo this, but more broadly i feel like any changes, not limited to point allocation should be changeable via Celeste. The most encouraging thing WRT feeling secure as a LP, is that the expectations cannot be changed suddenly

project_uwb · June 6, 2021, 10:03pm

@Eth_Man , I read this post of yours twice and I wish there was a ‘Clap’ button for a reaction instead of a heart. I would have given it like a ‘100’ claps! Mate your analysis of the farming so far and the rewards distribution I think are really clear and guided by simple ‘back to basics’ logic. As I pointed out in my first comment on this post, I am pretty new to economics of yield farming, but If I read your post unbiased removing my emotions as an smol time investor in the pools and my own personal interests, it absolutely makes sense and is quiet educational! I was actually hoping to find out the decision on how the current rewards distribution was finalised but if data analytics was not part of that decision making I can see your point of frustration.

I am not sure if everyone will get through reading your post in full, so posting a TLDR here. I would really appreciate it if you could let me know if I captured the essence of it and if I got something wrong, this is for my understanding as well. Thanks again!

Predictability cannot be guaranteed on returns by current method of xCOMB drip, as large LPs will decide what the returns are likely to be. I.e if a whale exits and xCOMB drip is the same, returns could be higher and if a large whale enter the pool, returns could diminish. So we cannot really control predictability.
Current method of rewarding LPs only may be flawed, as we need to reward volume which will in turn generate fee (I guess also leading to burning of xCOMB), the fee as returns will encourage LPs to join pools and will form a positive feedback loop.
Currently we do not have data analytics to support our decision of rewards distribution to the selected pools. So we could be speculating. Need data analytics to drive rewards distribution.
Need ability to be able to tune (increase or decrease) xCOMB rewards rate as a whole, which is currently not possible and a flaw in the design. Currently xCOMB total rewards is at a set rate and only tuning of xCOMB reward rate per pool is possible using the points based system.
Need to consider base APY (which is fee from being an LP provider) when determining the xCOMB reward drip to the pool. If this is not considered we may be rewarding pools that are already lucrative because of the base APY.
1Hive have always been focussed on sustainable development which has always lead to better outcomes but we have been forced to speed up with the farms deployment which has lead us away from our core values. We need to evolve to be able to think fast and ahead of the game, use data analytics to make informed decisions and start planning for future revisions of farming with clear requirements and learning lessons from the current v2 farms.

lkngtn · June 7, 2021, 1:59am

1M total supply, decaying linearly over 2 year, by the end of the 2 years the rate will be 25% of that at the start.

It cannot be changed given the current contracts, but the contracts could be upgraded, which would require a 1hive decision vote to withdraw any remaining xComb from the reward pool and unlock all deposits and then redeploying a new contract for people to use.

The points can be any number it’s a method for proportional allocation, 0 would be an edge case where rewards would effectively be disabled.

We cannot offer predictability of rewards, we can offer a rewards program that has predictable rules which I think is important. The issue isn’t that rewards may decrease after you have locked tokens as a result of more people participating or the price, market volatility is inherently part of the game. What we want to avoid is creating a game where the rules are changing frequently and erratically, which is something that we can certainly achieve.

One nice thing about decentralized applications is that all the data is available for analysis, so there is nothing preventing people from mining data and performing analysis–I would love to see us improve in this regard and would support proposals to do so if and when someone steps up and makes a solid proposal.

Without strong data suggesting a relationship between liquidity and volume, we do have some evidence that since we stopped our first farming initiative we saw both volume, liquidity, and mindshare for honeyswap on xDai wane. We also regularly get feedback from people who try and trade on xDai that the liquidity is insufficient for their trading and end up looking elsewhere. And we have seen farming programs repeatedly used to help bootstrap successful exchanges (Sushi, Pancakeswap, and Quickswap to name a few).

I can see the rationale for wanting to manage the emission rate, but I think it is a mistake to allow management of emissions as opposed to just direction of emissions (as we have now).

I do like your suggestion that we could allow modulating the rate but not allowing it to exceed the current maximum rate, as I think that eliminates the risk of unexpected or erratic increases in the emission rate. However, I don’t see how this capability would lead to a situation where rewards are “potentially more predictable”, and don’t necessarily see the the advantage in adding more governance surface (how much should we “recycle” at any given time and what to do with recycled tokens).

Im not sure how this relates to 1, unless you are suggesting that if we need to and want to rewrite and audit the farming contracts to accommodate 1 we can potentially also include in the scope of that supporting drips of multiple tokens through the same farming contract.

From a practical perspective is there any meaningful difference between having all the farming information available to users in a single table, but having the farming rewards and contracts be separate? I know people like the idea of getting two or more tokens for a single deposit, but it seems from an economic perspective having two separate farms that you can choose between would be nearly equivalent, and from a technical perspective more scalable/flexible.

We ended up having to cut this feature from the MVP release of the dapp frontend, but we definitely want to be able to show the “total rewards” as opposed to just the farming rewards.

How would you account for fluctuations in price of xComb and value of underlying deposits? How frequently would adjustments be made? and would the target be a max rate? Essentially saying that we think any reward in excess of this amount is wasteful, and will cap it by reducing the reward flow when it exceeds this amount?

I think this could be developed into an interesting potential policy in terms of setting allocation points. Or worked into a potential farming v3, where there is some sort of a rewards buffer that caps the reward rate, but accumulates the surplus as a buffer that gets used to increase the rewards to bring it to a target rate.

I referred to this pair as the keystone pair because it is essentially what is capitalizing the farming rewards, it’s significantly different from the other pairs both in terms of why its so important to incentivize it and how risk profile of the LP itself. Most of the other pairs being incentivized, will have relatively little correlation with the the exchange, even Honey and Agave which are more correlated have value propositions that are much broader than the success or failure of Honeyswap on xDai. But the xDai-xComb pair more than any other pair is essentially making a bet on the the success of Honeyswap on xDai, and the outsized rewards in xComb make a lot of sense in terms of rewarding that risk (imo).

I think the crux of this anecdote is that you felt that HNY (at the time) and now xComb may be overvalued, and therefore may decay in price over time. You may or may not be right, I’m not trying to argue for or against any specific valuation… but in principal if you are taking on any sort of risk by entering into a position (either holding a token, locking a farming deposit) its imperative to come up with some sort of valuation model and act according that model.

If your model says that xComb is overvalued then it makes sense to sell it as you get it and if it ends up going down in price to the point where you think it is undervalued you might start holding or even buying directly instead.

You tend to see really high initial rewards because rewards are distributed among the entire pool and the pool starts at 0, this is true even if rewards are paid in a stable value asset. In cases where reward are paid in a speculative asset, LPs are inherently participating in price discovery of that asset by choosing whether to hold or sell.

LPs are also participating in a market where they are exchanging the risk of holding (and potentially locking) a specific LP position for the rewards (fees, farming) that are offered. The market will fluctuate, both in terms of the value of rewards, as well as the value of deposits, and its important that everyone who participates understands that rewards are not “free money” but a reward for taking on risk to provide utility to the exchange.

As you pointed out we can’t really provide predictability in terms of rewards, nor can we provide predictability in terms of market movements of the underlying deposit assets.
I don’t think we need to try and mitigate the risk of providing liquidity that risk is a fundamental part of the game LPs are deciding to play… we just need to ensure that our policy for how we change the “rules” of the game are predictable, otherwise it is not a fun game to play.

I think this section and what follows probably deserves its own post or several… certainly lots of stuff mentioned are things that could be improved and I think we should of course work on improving them.

However I also think that its important to recognize that we are doing a ton of stuff in pretty radically different and experimental ways, and have managed to accomplish a ton in a very short period of time–I really don’t think we are at risk of compromising core values, we set out to create a more sustainable farming model and I think the introduction of network specific tokens does a really good job of making farming incentives a closed loop, sustainable system. I’m really proud of what the community has managed to build so far and look forward to seeing what we collectively do next.

lkngtn · June 8, 2021, 9:40pm

Based on the conversation over the last several days, its clear that this is an important topic with lots of possible improvements and changes to both the farms and the tooling we have to manage them.

However in the short term the Tulip swarm need to adopt a policy in order to effectively manage allocation points. I’d really like to be able to reach rough consensus by the end of the week, as I think its realy important for us to have some sort of policy in place sooner rather than later.

So I want to try and refocus the discussion on policy choices we could adopt today, as opposed discussions about possible features/mechanisms for future iterations (eg farming v2) and/or improved tooling that would need to be developed before it could be used. Perhaps a separate thread could be opened for that discussion.

Keeping in mind that adopting a policy now, doesn’t mean we cant change it in the future, we would just need to provide a fair amount of time (likely 4 months since that is the maximum lock time) before making further changes.

This makes sense, some of these sub-policies may need more specification in order provide enough information to support LP confidence in locking indivdiual pairs.

I strongly agree, I think its useful to have a decisive owner, I think that its also critical that this role is accountable to (and can be removed by) the community.

My thinking with the language of at least 30 percent of the rewards was that if some of the policies like the “discovery” pair didn’t use all their points, the proportion for other pairs would be higher when thinking of percentages.

There may be cases where we want more than 30% or less than 30% for the keystone pair. I don’t have a particularly strong case for a specific number, and would love to see a data-driven approach to coming up with a target, but unfortunately don’t have one in this case so the relative weight of the keystone pair relative to the other categories is simply based on a perception of the relative strategic importance of the categories.

I really like the idea of partially (or entirely) phasing out the role of the tulip multisig and using Celeste + a Comb token based curation mechanism of some sort. However, its not something we could adopt right away, so will save my thoughts on it for another thread

This is one I have the least conviction on and probably needs quite a bit more specification, but it seemed likely that there would be value in having a bucket of allocation points that could be used with a bit more discretion/flexibility.

Additionally, having this discrentionary pool would help ease the transition from the starting pairs to this new policy, in the sense that existing pairs that were chosen for initialization would fall into this bucket even if they might not be a fit for discovery, or their current weights don’t end up linig up with performance.

I think the performance policy in particular is a good fit for this sort of mechanism, its not clearly specified yet. But rolling with your suggestion with regard to min/max point system something like the following could work well:

At the beginning of each trimester (4 months corresponds to the max lock period) the top 10 pairs based on the liquidity:volume ratio and a minimum of 100k liquidity will be added as performance pairs with 1 allocation point. Each 4 weeks during the season, the remaining 20 allocation points would be re-distributed among these pairs with the top pair getting 5 points, the second getting 4, third 3, and fourth to seventh place getting 2 points each.

This would be an interesting game as LPs could lock on the pairs they think will perform best at the beginning of each trimester, know that they will have a minimum of points during that period, but potentially if they pick the best performing pairs they will get significantly more. As a result it will also encourage everyone (LPs, and projects/communities) to promote trading on the exchange in order compete for allocation points and increased incentives for their preferred tokens.

I think it might also be interesting to try and get a snapshot strategy which looks at accounts by trading volume, LPs, xComb balances, and Honey balances and use that as a way to survey different stakeholders. I’m honestly not sure how interested these groups would be in regularly participating in votes, but it seems like a something that could work well in terms of adjusting the more discretionary “strategic” pool, or helping to curate which pairs are selected for “discovery”.

I also think that using xComb in some sort of more direct on-chain curation mechanism could be interesting, but as mentioned earlier in the comment, I think this would require significant R&D so probably not as relevant to this current discussion.

Yes it would, thats why this policy discussion is so important!

I think we need to work on education a bit and perhaps provide stronger warnings in the frontend especially with regard to locking tokens. Rewards are not “free money”, they are a reward for providing utility to the exchange (and in doing so taking on risk), locking your position means you are taking on greater risk and that’s why you get the bonus multiplier. We can adopt a policy that makes how we adjust allocation points predictable, but we cannot make the underlying market movements of either the deposited assets or the reward asset predictable (I wish!) and so it will always be possible that participating in the farms on net may end up being better or worse than some alternative position (eg holding all stable coins over the same period).

Offering an unlock option with a penalty is something the current contracts don’t support, and there are trade-offs to including it… probably something to discuss in the context of other potential v2 iterations/improvements in another thread.

lkngtn · June 8, 2021, 9:43pm

Also here is an update to the example policy I proposed in the original post that attempts to clarify and improve the policies based on the feedback and suggestions in this thread…

Maximum Number of Allocation Points
This policy limits the total number of allocation points at any one time to 100.

30 points for the Keystone pair - the main stable pair for the reward token (eg xDai-xComb) helps to capitalize the reward program and therefore has been given its own pool of allocation points. Given the policy limit of 100 allocation points, this means that policy would ensure that the pair would receive a minimum of 30% of the rewards.

30 points for Performance pairs - Performance pairs would compete for point allocations on the basis of their respective liquidity and volume. The competion would be broken up into 4 month periods or seasons, At the start of each season, eligible pairs would be ranked based on their volume:liquidity ratio over the previous season and the top ten would be each granted 1 point for the season. Each month during the season, the remaining 20 allocation points would be re-distributed among these pairs with the top pair getting 5 points, the second getting 4, third 3, and fourth to seventh place getting 2 points each for that month.

Pair eligibility and competiton rules would be evaluated each season based on input from the community, and would be a necessary filter to prevent abuse of a purely metric driven allocation policy.

Up to 10 points Discovery pairs- This program would aim to showcase interesting tokens which are new or relatively illiquid. By boosting undiscovered tokens we can establish honeyswap as the main place to trade these tokens, and encourage these communities to cross-promote honeyswap and send traders to us.

Token projects could apply to be incentivized as part of the discovery program and be evaluated based on their merits, If accepted, they would be granted 1 allocation point which would last for 4 months.

The discovery points pool would be able to support up to 10 discovery pairs being active simaltaneously, but would not necessarilly always be fully utilized.

Up to 30 points for Discretionary pairs - A pool of pairs which can be allocated based on discretionary judgement rather than a more rigid policy. Rather than set expectations for how these points will be allocated or changed, we could set the expectation for specific allocations when they are added. This would provide some limited flexibility and experimentation in the allocation process which could help inform longer term iteration and improvements of the farming mechanism.

The discretionary points pool would suport a maximum of 30 active points at a time, but would not necessarilly always be fully utilized.

Rohekbenitez · June 8, 2021, 9:46pm

@lkngtn I think it is evident for the question of locking tokens in farming, it would take some kind of tutorial warning users of said blocking or explaining! sorry my bad english!

ceresbzns · June 9, 2021, 12:03am

I agree - we should consider adding more language to the front end so users are super clear on what’s going to happen when they hit Lock

ceresbzns · June 9, 2021, 12:04am

I support this proposed allocation policy.

project_uwb · June 9, 2021, 12:38am

Luke thanks for doing a clean write up at the end after having replied to the various discussions points in the thread above. This to me looks like a really good way forward. The only question I have is the 2nd category “30 Points for Performance Pairs”. As Eth_man had previously highlighted in his earlier post, is this proposal supporting the use of data analytics to drive the allocation in this category?

I also really like the idea of curation using Celeste as this will allow for community oversight over the points allocation as we have to take progressive steps away from having one team or group of individuals being able to change these levers even though that may be the best possible outcome currently.

I also completely understand your point about educating users (especially new) on the economics of farms and the risks if we want to stand out from the other crowd and would support any initiatives where we focus on the education.

I think overall we are moving toward a better defined set of requirements within the current limitation of the Farms design and would support this latest proposal if we ensure that data metrics drive the performance pairs. I would in fact ask to increase the point for this from ‘30’ to may be ‘40’ as this will be category that will bring the volume and thus the fee and increase the burn rate for xCOMB eventually.

cryptoclip · June 9, 2021, 12:53am

Agree with this - the main thing to make clear is that the APY shown on the screen when locking tokens is the current rate ONLY, and is not guaranteed for the duration of the lock period. The APY will change as people join or leave the pools, and APY’s typically decrease as more people join pools, rather than increase