SCP-166 ThorFOX, a FOX tokenomics upgrade proposal

[jonisjon]

@hpayne_shapeshiftdem

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.

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

@hpayne_shapeshiftdem

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.

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.

@hpayne_shapeshiftdem

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.

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.

@hpayne_shapeshiftdem

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.

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.

@hpayne_shapeshiftdem

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 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.

@hpayne_shapeshiftdem

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).

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.