Upgrading the Skew Incentive model

Stemming from the many debates on the skew-incentive program, on Discord, I have decided to put forth a modified criteria for inclusion/distribution of the incentive model, in hopes of addressing some of the (very valid) concerns about the current implementation, as well as (hopefully) reducing the need for manual governance-interaction week to week.

I propose we implement and set the following system variables:

  1. MinAssetGlobalShare - Minimum threshold, as a % of the global debt pool, for asset to be included in the incentive round. Should be sUSD value, as a sum of BOTH long/short synths.
  2. MinAssetSkewPct - Minimum gap between long/short tokens. Calculation in ratio of base tokens, abs(iSynth-sSynth/(iSynth+sSynth))
  3. RewardAmount - Amount of SNX to distribute, divided proportionally to the sUSD-skew of each asset meeting the above requirements

If we set the variables as following:

MinAssetGlobalShare = .02
MinAssetSkewPct = .10
RewardAmount = 32000

The incentive pool for this period would be:

iBTC: 30103.78 SNX
sETH:  1896.22 SNX

Currently, BTC is ~36m sUSD off-skew, while ETH is only ~2m, and iETH is actually over-skew, so in fact sETH would be incentivised for this period, under this model (which I personally think is the correct outcome).

As assets become more in-line, they will lose their incentive, which may make the more transient farmers look elsewhere, but i think long term this creates a more stable skew-farming cohort, who are intending to be short these assets long-term, and would like the free money on top. It also can also react to large shifts more automatically and immediately than I feel governance is able to, at this time.

There are likely more wrinkles that need to be added to this, and I am confident that we have enough big-brains here to massage this into a more hardened system, but I believe it is a good direction to move towards.

I look forward to feedback!

3 Likes

I really like the spirit of this idea. However:

It also can also react to large shifts more automatically and immediately than I feel governance is able to, at this time.

This is both a blessing and a curse. We’d have to come up with some kind of smart dampening to prevent whales from gaming this.

E.g. we can’t let a whale take a huge, temporary, sTRX position, have the mechanism set up a lot of SNX to iTRX and then have the whale switch wholesale to iTRX.

Yes, and I believe this is actually a very plausible avenue for manipulation, but that we should be able to work a way around it.

Some ideas I had for this:

  • using the average of multiple snapshots at various points throughout the period (or even from previous periods, depending on how dampened we want)
  • lowering the period window, potentially to every 3-5 days (more frequent re-balancing shortens the window to benefit from a snapshot-related manipulation attack)
  • ‘whitelisting’ assets by governance vote, so that it wont randomly come out of nowhere on assets that otherwise have extremely low float (though, this can also be potentially managed by setting a high MinAssetGlobalShare from the variables above)
2 Likes