Retroactive reward

As suggested by Kenny to start a retroactive reward discussion, here’s me taking a stab at it.

Say v2 is launching in May 2021, I suggest we do five snapshots each a month from Jan 2021, the allocation for the snapshot per month should be 20% of governance reward. That 20% is given by ratio to the people that contributed.

This method is fair and easy to implement. A harder way is to take the average of every day or every second if the developers have time for it.



I liked what Curve did with their retrospective LP rewards.


  • Reward LPs proportionately at any given point in time. No “snapshots” per se but a continuous proportionate calculation if I recall.
  • Vest the rewarded tokens over X years. This should be debated as making 100% of tokens available straight away can be beneficial for price discovery, governance and so on.

I agree.
I think the snapshot should be earlier than January 2021. I think the liquidity provision should have started much earlier and is a contribution of the project.


Good thread to have, i think its pretty essential to reward LPs right up to the start of when the pools were announced, the easiest and “fair” way of doing it would be to allocate some amount of SEA per block per pool and have it split by the liquidity providers proportionally, this is the most common way of doing snapshot retroactive rewards and i think makes a lot of sense. It also rewards users more when the value of the pools is lower (ie. people have left for other good opportunities or the protocol is less well tested) and rewards them less when the pools are bigger (probably there are fewer good alternatives)

I think weighting the stable pool and the btc pool equally works really well as it roughly reflects the btc/stable yield ratio in other protocols with normal natural flow. Just as an example:

The stable pool currently has ~8m of deposits
BTC pool has ~12m

So here the returns of the stablecoin pool would be ~1.5x that of the btc pool right now. If you look at the other opportunities around this seems quite fair as btc returns are generally lower than stablecoin returns. (also worth noting that im saying this as someone who is currently mostly in the btc pool)

I think if we are doing any interesting reward distributions (such as rewarding users for staying in the protocol long term) then its better to do those forward facing to incentivize behavior going forward rather than retroactively benefitting those who happened to act in the correct way.


In terms of vesting vs no vesting, i think its very important that some reasonable portion of the circulating supply is available at the beginning so as to not have the curve problem of an extremely high initial price with constant dumping, its pretty bad for the morale of the project and causes people who might want to buy the token to have to hold off. I think the initial circulating supply of between 5-10% feels right, retroactive rewards could also include some vested portion and some unvested portion


Hey guys,

First of all great project and Team, I’ve been in the Telegram Discord and LP pools for months now and im a believer in the longterm success of this , here are my 2 cents:

I really want to emphasise that it is important to reward people $SEA for time*value spent in the pools, as Joe pointed out other Projects did that and it shouldn’t be to hard and by far the fairest.

It is far higher risk for someone to deposit into the BTC pool when it has like 2 BTC in it and just launched vs depositing after 2 months when there are 200 BTC.
Could even argue for rewarding earlier LPs slightly more but I think a flat distribution is perfectly fine as well

This also solves the issue that a lot of people probably left as soon as there were other profitable options for BTC (e.g. Badger) and if they were lucky and still in the pool on a random snapshot date that would kind of screw the distribution in a weird and unfair way.

I don’t have any problem with Vesting a decent amount of tokens since as I said im a huge believer in this, but I think it is important there is a high float at first and there is no steep Inflation


I agree with everyone saying to do something similar to what Curve did but with a portion of the the tokens (maybe 1/3) released immediately with the rest vested over a period of time, maybe 6 months or a year.

It’s worked well for other projects.

1 Like

Agree with the replies who would reward LPs based on time in pool and % of total pool, cant really understand why rewards would arbitrarily start at the beginning on the year.

A lot of newer projects are releasing tokens in batches which seems to be working pretty well as everyone knows when those tokens are being released, and the releases more or less get priced in which avoids panic selling. I think this could work well, and agree that some type of vesting is needed even for LPs. I believe LPs should receive some % up front along with whatever other supply is released.

It would help to know what type of vesting/release schedule the angel investors are on, and if there were to be a sale other than that seed round what that vesting would look like.


I would recommend tweaking the formula from (time)x(value) to (time)x(% pool share) as mentioned above. This rewards people who take the highest risk (early depositors in a small, untested pool) and also rewards people for their opportunity cost of sticking in the pool during times when other higher yield opportunities were present.

Also, just using time*value would potentially allow larger short term whale investors to dilute out longer term supporters by depositing exponentially larger amounts for a short period of time. For example, someone like say Alameda farming the pool with 8 or 9 figures few weeks before token launch and diluting out all the earlier users who have been LP’ing for several months. Using pool proportion could mitigate this somewhat as per block rewards would be capped at whatever 100% pool proportion equates to.

Regarding start time, I also agree with continuous “per block” rewards from the launch date of each pool like Curve. This seems the fairest way with no potential manipulation of snapshots. Regarding the v1 stable pool migration, you could have a 1 or 2 week grace period where the v1 stable pool and newer stable pool liquidity is added together for reward determination while people were migrating before turning off retroactive rewards for the older pool at a set date.


Agree dollar amount is much less important than % of pool.

The migrated pool being treated as one larger pool for a grace period (i’d argue the period should be longer than 1-2 weeks, and probably just until the initial pool was deprecated.) makes sense.

Regarding the initial distribution for $SEA, I think it is valuable to have a significant initial float to achieve some price equilibrium. Our theoretically ideal approach for this is a “double auction”, which is a type of auction for an asset where there is a distribution but not a price. Sellers submit how much they’d like to sell at what price, buyers submit how much they’d like to buy at what price, and the intersection of these two curves decides the price such that only the bids that were satisfied transact. If a buyer/sellers price isn’t satisfied, they just keep their tokens.

Although we thought that is ideal, doing the work to make that come to life is a daunting task. Fortunately, I did some networking and as I was talking about it with Gnosis, it turns out they could repurpose some of their newer developments to support this double auction use case as well.

I for one would be excited to get this involved in DeFi as a primitive for bootstrapping tokens, and it seems there is a possibility for us to collaborate with Gnosis to make it happen.

At a high level, this would look like everyone gets their tokens, but they are not transferrable until the auction ends. While the auction is proceeding, people could lock in their bids and asks, and afterwards they would be able to mint their transferrable $SEA tokens in accordance with the outcome of the auction. The auction could be held over as little as a couple days and as long as a couple weeks, allowing everyone a chance to gauge the market and specify their opinions about the price.

How does everyone feel about that approach?

I think a liquidity bootstrapping event in that fashion would be great. You could also look at how did with their launch. They used a Balancer LBP (Liquidity Bootstrapping pool) running over 48 hours. It’s a tad different from the idea you outlined I believe.

Building Liquidity into Token Distribution | by Mike McDonald | Balancer Protocol | Medium

Siren protocol also recently did a LBP. Seems to be an effective, equitable way to distribute early tokens, at least compared to the uniswap IDO approach. Also, seems this would be a lot easier to implement on the dev side.

Is it possible for LPs to seed the LBP? they would have to put in SEA tokens and some extra eth and would get back something based on the price, you could even have a 10% tax to create post LBP liquidity. This is unless the team wants to use a LBP to raise funds

You could have the pool start out 90% shell 10% eth and finish 5% shell 95% eth, the 5% shell is matched with 5% eth and a new pool is created while those that contributed the initial liquidity get back 90% eth

How would the LBP work for LPs?

It seems like there would have to be a tax for entering the pool after the weights have changed significantly, otherwise would the new entrants be taking advantage of the work done by the early LPs who were selling their $SEA for cheap?

One drawback for the LBP is that everyone in the pool agrees to the selling at the same prices. This works great when there is one party who is selling everything. But how does it work for a community of early LPs? Everyone wants to sell their $SEA at a high price, but the construction of the LBP would demand that a significant portion of it will be sold at a low price. So that makes me wonder what incentive an LP has to provide liquidity early?

With the double auction format, the price is emergent strictly from the bids and asks, so this dilemma is solved for by construction.

LP’s would contribute their SEA and small ETH to a contract (or multisig) which would start the LBP. They cant add to the LBP once its already started

Until completion of the LBP, SEA transfers would be disabled for any LP’s SEA that was not initially added to the LBP.

Upon completion, proceeds are distributed pro rata to those who contributed to the LBP and all transfers are reenabled.

I think you could also do this with a placeholder token that is non transferable and LPs can indicate how many of these tokens they would want to contribute to the LBP and those real SEA tokens are issued to the LBP contract on behalf of them, the rest of their tokens are minted after the LBP

1 Like

Good conversation – it’s hard to know how many are promoting their own self-interest vs good long term tokenomics.

The flip side of it is to pick a time when v2 is being launched and promote that liquidity mining will start on X day – do a fair launch for everyone.

It’s so hard also because we are in a bull market–all tokens are doing well. But if v2 is going to launch much later in the year, the token launch could be at the time when the market is at all time highs (thus seeing a massive correction of all crypto coming soon).

Tokenomics work very different during a bear market, regular times, and during a bull market. Development doesn’t stop but once a token and price is a thing, developers and team members will have to solve for a crazy community as well. People get crazy when their money is on the line.

I do like the idea of rewarding users as well – reward it 100%(?) of the gas they spent on the swap transaction.

1 Like

How about having two types retrospective rewards:

  1. Airdrops for wallets that have interacted with the Shell protocol in one way or another before a certain cut off date. This cut off date should be fairly early on - say early 2021, or the date that this thread was started - such that it is too late to game this airdrop. The airdrop should be a non-trivial amount to increase the token distribution. If airdrop holders choose to sell their airdropped tokens immediately, that allows for early price discovery and establishes a price floor. This may well achieve the intended effect of an LBP, without the complexities of organising an LBP (not to mention the unfounded suggestion that the team is doing a further cash grab by way of LBP).

  2. LP Rewards for early LPs. This has been discussed fairly extensively, and the consensus generally seems to be rewards proportionate to LP size and time. While this approach heavily favours big LPs, having a non-trivial airdrop will mitigate these concerns.

1 Like

What metric is the token solving for? If it’s going to release 90% of the supply, that looks very different than if 5% of the supply is released.

If the goal is to get it into as many wallets as possible to achieve “sufficient decentralization” distribution looks different.

If the goal is to incentivize liquidity, that looks different.
If the goal is to incentivize early supporters, that looks different.
If the goal is to incentivize total number of users, that looks different.
If the goal is to incentivize total number of active monthly(?) users, that looks different. (I took monthly because that’s the metric Coinbase used in it’s IPO)

And on top of all this----we are in a bull market so token price is very different than it would look like in another part of the cycle. Would all the defi tokens accrue any value at all if BTC was not above $20k and speculative cash wasn’t flowing into alts? As far as I know no defi token accrues actual protocol revenues. Most try to avoid that because it would be a security. There is zero fundamental value in any defi token.

You guys could make it quite simple:
Whenever v2 launches you start liquidity mining (nothing retroactive). You do it as a way to incentivize liquidity at the time you decide you want it.

Until a clear roadmap for the project is developed (and ultimately where actual paying users are going to come from (aka profits), the talk of a token could be premature.

Another idea: Liquidity mining reward is accrued but not paid for a year. There is no token, no price dumps, no price talk. Early liquidity could be incentivized with a positive factor and withdrawing liquidity prior to a year could be incentivized with a negative factor. Users also could accrue rewards. Then there could be a massive distribution when the product is mature and everyone is ready.

I disagree with arnel that starting liquidity mining at some set point in the future would constitute a “fair launch” to everyone.

Some of us has stuck around the protocol for a long time and provided liquidity through all the ups and downs of Version 1. Providing liquidity for V1 has been crucial in order for the devs to improve upon it for the next iteration. Stress-testing V1 with sufficient liquidity is ultimately what led to the development of V2.