SCP-166 ThorFOX, a FOX tokenomics upgrade proposal

Proposal Discussion
43

lol, good point, I originally shared the RFC post for this proposal back in November before lending had launched and haven’t updated this, will do so.

I think here might be some chance of a modified FOXyv2 contract working, but ultimately that is a product/engineering workstream decision as outlined in the proposal. Not a bad sign that someone sees the proposal and already wants to stake, but I hear you on the confusion, i’ll cleanup that language so it’s not FOXy specific in the reference.

I do think it makes sense for the DAO to move towards a staking solution for discounts and other benefits for a variety of reasons, but I also don’t think it’s critical for that to be part of this particular tokenomics upgrade and I think its fine if people get discount benefits for unstaked FOX still for sometime as long as those staking also get the same discounts (so may still require some update in that logic so we account for staked FOX as well).

For simplicity sake, i’ll remove that requirement from this proposal and the community can follow up when its time to make any additional changes on the staking front.

Good suggestions and feedback @0xfbl, thank you!

1 Like
44

Thanks for posting an update. I have a couple of requests and feedback before this goes to Snapshot.

To vote “for” this, I would like to see:

Some sort of spec and resourcing allocation to engineering, product, and marketing resourcing as this is not planning the current roadmaps from either team. I think it is the burden of the proposer of new priorities to present this to the teams–even just a loose spec is better than nothing. Passing something without a comprehensive breakdown and understanding of the costs and resources required to build would be premature and I strongly encourage any FOX holder to question the resourcing required to build this.

I would like to request that we cut the name “THORfox” for this name of this SCP and roll with “SCP-166, a FOX tokenomics upgrade proposal.” I understand that this is meant to signify a deeper integration/alignment with THORChain, but I strongly want to move away from this name as soon as possible. I am sure the THORChain folks would greatly appreciate that as well, as they have expressed frustration multiple times towards other interfaces that use the name “THOR” with unrelated tokens/tokenomics as it confuses users.

I would have liked to have seen more of an effort to chat with the Hedgey team for alternatives to burning. This is something I have brought up a number of times on community calls, and I feel like this was not evaluated or considered. We have a strong and strategic partnership with Hedgey that can also drive more awareness and users to shapeshift by us using them more. It would be a miss IMO if we didn’t leverage them.

I would request that there be an option “d” for #7 where is is 5% rune to staking yield, 5% buyback, and 0% burn (or something like that that is nominal–even breaking apart the buyback and burn is valuable IMO). Having the ability to tune each of those knobs aside from the current options presented would be great.

Lastly, I would like to see more users actively asking for this feature on app.shapeshift.com on the canny board or socials. I think we should be building what users want, and from what I can tell via user feedback (slightly different than token feedback IMO), more people want better swap routes and features (like BTC<>ARB swaps via Maya Protocol) than this.

I think that this kind of tokenomics upgrade is premature given the state of our product relative to the industry (we are just now catching up with competitors). I think we need to keep building the product forward and out. This proposal, as it stands, detracts from that vision (or rather has a lack of definition on the resourcing required and impact it can bring to ShapeShift).

If the above changes could be made or further considered and defined, I would be more likely to vote “for” this.

1 Like
45

So there was a spec already done by the current engineering workstream leader which was posted in the RFC and was linked to earlier in this ideation thread, here is that link again: [RFC] ThorFOX, a FOX tokenomics upgrade proposal - #9 by 0xean

No problem, I will get rid of the THORFox name from the title and body of the final proposal draft when it goes up tomorrow. It was mostly just a fun way to talk about the proposal itself, was never meant to persist beyond that and has no fundamental necessity to stay in the text.

Im not sure really why this needs to be talked about with them beforehand to be honest. Its perfectly fine for the DAO to choose to use hedgey for the “locked treasury” option (that is going to be included based on GK’s request) if the community wishes and this can be determined before any implementation is done if that is the way voters want to go. I think including that locked treasury option for the starting params covers this and if any alterations are needed (such as whether to use hedgey or sablier or some other mechanism) before it goes live the community can follow up on those.

I don’t think such a 4th option adds much when we already have a 10/10/80 option to cover the “low” end of starting params. If you and others would prefer your suggestion (5/5/90) to replace the 10/10/80 option I would be happy to swap that out, but I don’t think we need both a 10/10/80 and 5/5/90 option for starting params (especially considering the community may wish to change these params before things go live anyway). I also don’t want to include more than one “treasury lock” option as opposed to the burn and I think the option added by GK covers that.

I don’t know that many users know to “ask” for tokenomics upgrades (and despite that I have seen such requests in the community before and recently) and I think it is important this proposal moves forward even if this isn’t a top feature request given the strong community sentiment we saw voting “for” during the ideation phase. I hear what you are saying, but this is a case where I think these is some disagreement among the community about the relative importance of this and thus governance is the best way to gauge that community sentiment.

I get that is your opinion on this and a number of other contributors share the sentiment its “too early” for this tokenomic upgrade proposal. However a large portion of FOX voters seem to disagree with that and think now is indeed the right time for this proposal (and talking to a number of those community members they seem to believe it significantly helps the vision instead of detracting from it), i’ve already covered this particular argument earlier in the ideation thread (notably here [Ideation] SCP-166 ThorFOX, a FOX tokenomics upgrade proposal - #25 by jonisjon but also multiple times elsewhere) but suffice to say that I think this question and community disagreement around this is best answered by governance voting and those that think its premature for this tokenomics upgrade should indeed vote this proposal down.

46

i got Hedgey (or sablier stream) on t he table! :slight_smile: i picked 10/10/80 and we can change that.
we could push it out further i suppose. and go 10rune, 10 buyback and x hedgy and 80 treasury.
so that the buckets can be adjusted more?
10 rune (adjustable)
10 Buyback (adjustable)
0-10 of the buyback to be Locked(adjustable)
80% treasury. (balance remaining)
to show it easier? if it works out, we start adjusting numbers to see if it works better etc.

maybe make sure in the snapshot, it specifys that the numbers are adjustable by TMDC (is it that or other method) whatever. easy being the key.

1 Like
47

Well specifically these numbers are not adjustable by the TMDC (without an additional proposal to delegate that to them, which I personally think shouldn’t happen), they are only adjustable by governance. So they can be adjusted after the fact (even before any implementation of this launches) but they will need to be adjusted via a subsequent governance proposal.

48

gm!

Here is the latest version of the draft that will go live later today for voting based on the last few days of comments:

SCP-166 a FOX tokenomics upgrade proposal

Summary

The goal of this proposal is to enact an upgrade to FOX tokenomics that more closely aligns the DAO with the THORChain ecosystem of which it is a vibrant part.

As part of its operations the DAO treasury receives and holds RUNE. This proposal would upgrade FOX tokenomics by paying a portion of the RUNE the DAO receives on a regular basis as “real yield” to FOX stakers in RUNE, as well as using a portion of that RUNE to buy and burn FOX.

Abstract

The ShapeShift DAO has been building through the bear market, consistently improving the interface/product offering as well as adding a number of THORChain related features in particular (such as streaming swaps, Metamask Snaps, and soon lending). Most of the focus during that time has been on improving the product and attempting to acquire users (as it should be), however the tokenomics of the DAO have not gotten nearly as much attention. This started to change slightly with SCP-153 when the community approved using FOX as a way to get discounted fees when trading. This proposal suggests, on the back of SCP-153, that the DAO should further embrace its alignment with the THORChain community by upgrading FOX tokenomics to enshrine that alignment with RUNE and the THORChain ecosystem at large.

Motivation

ShapeShift was and is one of the earliest THORChain supporters, well before others in the ecosystem recognized its value and even before the DAO launched, ShapeShift integrated THORChain for crosschain swaps. ShapeShift has consistently supported THORChain features as they are made available and most of ShapeShift DAO’s trading volume comes from users utilizing THORChain. The main motivation here is to encourage the ShapeShift community to further embrace and strategically focus on the THORChain ecosystem as its best opportunity. One of the best ways to do that is through an upgrade to FOX tokenomics that further aligns the ShapeShift DAO and THORChain communities together.

Specification

If passed, this proposal would dictate the following:

  1. X% of all new RUNE accumulated by the DAO treasury (from whatever source, whether donation, fees, or any other revenue stream) is paid out to FOX stakers as real yield every week (pro-rata across those who are staking). The definition of ”New” here means any revenue source that adds additional RUNE to the DAO’s treasury that wasn’t previously in the treasury prior to this proposal passing.
  2. X% of all new RUNE accumulated by the DAO treasury (again from whatever source, whether donation, fees, or any other revenue stream) is used to buy FOX from the open market which is then burned by being sent to 0x0000000000000000000000000000000000000000
  3. The remaining X% of RUNE would continue to be held and used by the DAO treasury as governance sees fit.
  4. In order to effectuate this new change, it will become required that in order to get FOX staking benefits (such RUNE yield and whatever else the DAO deems a “staking benefit” in the future), a user must stake their FOX in a staking contract (this staking contract will be chosen and implemented by Product and Engineering workstreams) as well as sign a message or transaction to assign the RUNE address where their yield will be paid. It should become standard that “unstaking” FOX takes a minimum of 28 days henceforth (though the receipt asset could still be liquid and transferable). To be clear this proposal passing would setup a simple single sided FOX staking mechanism for this purpose, it does not allow the DAO to use the staked FOX for other purposes, though future governance proposals may alter or evolve this to do so.
  5. New software will need to be prioritized and built by the Product and Engineering workstreams in order to allow a user to sign a message or transaction and assign a RUNE address where their yield will be paid. The user will also need the ability to update/edit this address at future dates by signing a new transaction.
  6. The DAO multisig will effectuate these RUNE and FOX transactions on a weekly basis based on the RUNE revenue numbers from the prior week.
  7. If this proposal passes, indicating the community has passed the overall tokenomics upgrade model, it will trigger an additional and immediate 7 day long snapshot vote where the community can vote on 1 of 3 options for the starting parameters (which will set the X%’s above). Those three options will be (a) 25% of RUNE to staking yield, 25% used for buyback and burn, 50% held by the treasury, (b) 25% of RUNE to staking yield, 25% used for buyback and then treasury locked, 50% held by the treasury, and (c ) 10% of RUNE to staking yield, 10% for buyback and burn, 80% held by the treasury.

If this starts to see increasing success and scale (in terms of overall RUNE volume, users staking, and number of transactions needing to be made by the multi-sig on a weekly basis) then it will make sense for engineering to create a bot for use by the multi-sig to make these transactions automated and more efficient (e.g. a hot wallet which the mutli-sig fills up every week that does the transactions automatically). This is not necessary to get it going, but would become a necessary upgrade once any sort of scale increase is needed. Ultimately this proposal leaves this implementation detail and timing up to the discretion of the product and engineering workstreams unless superceded by a subsequent governance proposal.

Effectively the specification of this governance proposal would setup 3 parameters that governance could affect going forward: (1) % of RUNE accumulated that powers FOX staking yield, (2) % of RUNE accumulated used to buyback FOX from the market which is then burned (or treasury locked if (b) is the winning option) and, (3) % of RUNE accumulated that is held by the treasury. While this proposal passing would set the initial starting parameters for all three of these (via the contingent subsequent snapshot vote), governance can modify this with a subsequent proposal in the future to alter any of these, including setting any of them between 0-100%.

Benefits

The major benefit to this proposal is upgrading FOX tokenomics in a sustainable way that more closely aligns the ShapeShift DAO with the THORChain ecosystem. With this alignment, the better RUNE and THORChain does, the better the ShapeShift DAO does as well. This creates ongoing yield opportunity for FOX stakers to earn RUNE (something which does not exist in many fashions outside of running a RUNE node or LPing on THORChain) and it starts to consistently burn FOX on a regular basis, all in a sustainable manner.

Another potential benefit to this proposal is that it could establish the foundation for a further upgrade to veTokenomics in regards to governance and for voting on how and where revenue the DAO earns is used on a more active basis. That is better served for a future proposal due to further complexity, but this proposal passing would setup such a natural evolution for subsequent tokenomic upgrades being successful.

Drawbacks

The major drawbacks of this proposal are the time and priority of the product and engineering workstreams in order to make these changes and operate the system on an ongoing basis.

It also could create some additional ongoing burden and workload for the Operations workstream who would have to field and respond to user questions and issues around this tokenomics upgrade and its effects.

There are opportunity costs to aligning with the THORChain ecosystem further, such as not aligning further with other ecosystems the DAO may wish to pursue or other engineering and product features which do not get prioritized as a result.

Finally the obvious drawback of aligning the DAO further with the THORChain ecosystem could have negative effects for FOX whenever RUNE is in a downtrend (such as in a bear market).

Vote

Voting “For” this proposal would enact the tokenomics changes for FOX as stipulated in the specification of this proposal. The initial parameters will be set via a contingent secondary vote if this proposal passes as described in (7) of the specification section. A “for” vote also serves to prioritize the product and engineering work streams to enact this proposal as quickly as reasonably possible.

Voting “Against” this proposal would enact no changes.

49

Snapshot is up!

2 Likes
50

https://snapshot.org/#/shapeshiftdao.eth/proposal/0x631b7c5520580c30770194105d1497d63d4629c62dd71b4365aa785e83c4caa6
Settings are up! make your choice!

1 Like
51

As we get closer to launch we have aggregated some documentation together

While we mostly tried to stay as close to the original vision there are some minor changes from the proposal. Most notably, each epoch will be 1 calendar month long.

The reasoning behind this is two fold:

  1. This is a very manual process for the time being and the multisig signers will need to dedicate significant time and dilligence to the execution
  2. We want the community to verify and agree with the accounting prior to the distribution actually being executed. After the end of an epcoh (month end), there is a 2 week window for the community to question any of the accounting prior to the distributions being made.

Launching soon…

4 Likes