[Proposal] Sushiswap TRU/ETH LP Retroactive Airdrop

Proposals
1

Contributors: @MG-TT & @tylerw

What Happened:

On January 19th, 2021, a proposal was made to migrate the TRU/ETH liquidity provider incentives from Uniswap to Sushiswap, with the logic that the migration would engender community cross-promotion to reach new users, and also offer double rewards: SUSHI & TRU.

The proposal passed a Snapshot vote on February 2nd, 2021, with a reduction in the outgoing TRU rewards: Sushiswap LPs to receive 10,108 TRU per day (20% of Uniswap incentives).

With a “double rewards” feature to ship with Sushiswap V2, it was believed the combination of SUSHI & TRU rewards would drive pool returns to an attractive range, as high as +100% APY.

Sushiswap incentives were designed to launch at the conclusion of the Uniswap TRU/ETH farm, which ended March 22nd, 2021. Though some Uniswap LPs migrated their funds starting February 5th, after the vote was passed, the majority of LP activity occurred in March onwards.

Unfortunately, Sushiswap V2’s launch (and by extension, double rewards functionality) was delayed to accommodate audits and test deployments, so TRU rewards were never distributed to Sushiswap LPs.*

Sushiswap LPs did, however, receive SUSHI rewards via Onsen as well as trading fees.

Additional resources:

*TRU/ETH Onsen rewards also recently ran out, though this was explained to have been a V1 > V2 migration mistake and are being restored.

Goal of this Proposal:

This proposal seeks to distribute TRU intended to be used for Sushiswap LP rewards retroactively to LPs who participated in the Sushiswap pool between March 22nd and May 20th, 2021 - the end of Uniswap incentives, and the launch of TrueFi V3, respectively.

The intention is to appropriately compensate Sushiswap LPs commensurate with the expectations set by the TrueFi & Sushiswap teams during the original proposal.

Supporting Data

  • Sushiswap LPs did receive SUSHI rewards and fees
  • Sushiswap LPs did not earn TRU rewards (this is why we’re proposing this!)
  • 22% ROI for users in Sushi LP from snapshot on 2/5 to 5/20 launch
    • ROIs differ for users who entered and exited the pool at different dates, of course

Screen Shot 2021-05-28 at 4.54.13 PM
Screen Shot 2021-05-28 at 4.54.13 PM1874×1028 223 KB

The number of impacted LPs: 33

If farm had run at the expected rate of 10,108 TRU per day from 3/22/21 to 5/20/21, LPs would have received 172k TRU (or ~$60k USD at current $0.33 TRU price)

Discussion: Should Sushiswap LPs be compensated? At what rate?

The most generous argument: Considering the total amount of USD, at ~$60k, is relatively small, the most generous consideration is to distribute the reward to Sushiswap LPs in full, many who entered the pool in anticipation of TRU rewards. These community participants do a service for TrueFi and it can be argued they’re worth taking care of. The most generous idea is to grant LPs 100% of the allocated TRU from the date the snapshot was passed.

Conservative arguments: A high APY farm launching would have attracted more capital to the pool, diluting the LPs. It can be argued TrueFi should only allocate 75-50% of the allotted incentives to reflect this theoretical inflow.

Argument against disbursement proposal: In fact, most LPs made a decent return on the pool regardless of double rewards not being enacted: approximately 20% ROI.

Discussion:

Let’s start a discussion about (a) whether these LPs should be retroactively rewarded for their service to TRU liquidity and (b) to what extent (ie 100%, 75% or “most generous,” “starting at X date, not Y date”)

EDIT (June 1, 2021): After 4 days of discussion, the vote is now live below:

  • YES, distribute 100% of the estimated rewards (172k TRU) to the 33 affected Sushi LPs
  • NO, do NOT distribute 100% of the TRU rewards to the 33 affected LPs
0 voters
4 Likes
2

Thanks for the proposal. I personally feel it would be fair to retroactively pay them in full (i was not one of them). They indeed probably would have been diluted if the rewards had worked but i think it would be a nice gesture to ignore that to thank them for their patience and “service”.

4 Likes
3

I think it would be fair to retroactively pay them in full as well and would vote in favor if proposed.

2 Likes
4

I am one of the LPs so I’m biased, but the way this proposal turned out is fair. Choosing to reward us less than the full amount out of a concern over moral hazard seems pointlessly stingy. I don’t see how we could choose any specific <100% allocation without it being an inherently arbitrary delineation.

2 Likes
5

As stated in the Discord chat, I was affected by the promised rewards not being paid, so will personally benefit if this is passed, but I would vote the same even if I wasn’t. I believe passing this is the right thing to do. The migration and rewards were passed via the community vote. We then entered into the liquidly pool in good faith based on this. Therefore passing this makes good what should have happened automatically anyway.

I vote in favour of this proposal.

6

I’m the one who brought up moral hazard; I’m no longer too concerned with that. I also don’t think the “arbitrary delineation” argument is very strong - ultimately if I was convinced that 100% was too high and 0% was too low, then I’d much rather pick an arbitrary intermediate value than pretend that 100% and 0% were our only options. Nonetheless, (reiterating from discord) I believe 100% is reasonable because that’s what we voted to deliver. (I could also see a slightly smaller % to reflect theoretical inflow.)

7

Proposal for an amendment: Instead of ignoring the amount that would have gone to the company and been burned, actually burn that amount (from the same pool with which you’re planning to do the airdrops). I’ve voted against burns elsewhere, but if the goal here is to retroactively cause the reward system we voted for to happen, well the burn is part of what would have happened, and given the support I’ve seen for burns here, it might reasonably have been part of what people were voting for.

8

What about inflation? There is no buyer in the market, and continuing to increase the supply will lead to another decrease in the price of the coin

9

@123321 This is a fully general argument against all our TRU emissions. Note that the entire amount discussed in this proposal is less than what is emitted every 8 hours by the current farms, so if you’re worried about inflation, I think this proposal isn’t the place to look.

1 Like
10

Coins obtained from farming and airdrops are different things. Correct stacking positioning leads to an increase in demand and a decrease in supply. For 7 years in cryptocurrency, I have never seen a positive result from an airdrop. But you’re right, I’m worried about inflation and insane stacking percentages. We need to have a strong uptrend with a low% rate. Not a down trend with huge emissions. Just a personal opinion

11

The way I think of this proposal though is that it is the farming/staking rewards that were promised by vote, just delivered in a different method (“airdrop”). It’s like if we’ve agreed that I will pay you some money over PayPal and then I discover a bug with my PayPal account, then the only appropriate response is to find a different method to pay you; I can’t just say well the original method is broken so I guess I don’t owe you money anymore.

12

Of course, reputation is the most important thing, promises must be kept, I did not understand the essence of the issue.

13

Well my analogy is not exact of course; it’s possible to argue that the promise of rewards really was tied to the distribution method here :man_shrugging:

14

Folks, with the discussion largely considering 100% vs 0%, I’ve launched a poll representing a pure YES/NO vote as an edit to the original post:

15

Snapshot is now live for this proposal, please vote below:

https://snapshot.org/#/truefigov.eth/proposal/QmbxK5kdFYq7cMEhgWJoZQJt2ynWxbuKn26xaEtdCeFTGm

1 Like
16

TRU rewards were distributed retroactively to Sushiswap ETH/TRU LPs today.

A total of 171,924 TRU were distributed to the addresses listed here, excluding contract addresses and TrustToken treasury (0x62c).

1 Like