[SCP-TBD] Parametric Survival - A Pragmatic Fee Model

SCP-TBD - Parametric Survival - A Pragmatic Fee Model

Prelude

A copy of this proposal is available for easier reading on Google Docs due to Metaforo formatting issues. Metaforo will remain the source of truth for governance incubation purposes.

https://docs.google.com/document/d/1Ek3LaOIwTZQTAnFIcZfnNxsZU7vKl-rRvgXUVe7YJi0/edit

The accompanying model is provided here for reference

https://docs.google.com/spreadsheets/d/11e3Kys4wlMew-OGNoUX3IYb3wUOMxMPLxgJqYsJB-Jc/edit#gid=0

Summary

This proposal directly supersedes SCP-128.

This proposal outlines a parametric fee model to be implemented on all trades routes.

FOX holders over a given parameter qualify for free trades.

Small trades under a given parameter qualify for free trades.

A parametric curve determines discounted fees as a function of size.

Parameters will initially be determined by governance via this proposal.

They will be maintained by TMDC in the interim and implemented by product and engineering.

Ultimately be maintained via governance and enacted via SnapShot, with the results attached as data to the proposal and stored on chain. This is consistent with mature DAO best practices, inspired by lending protocols like Aave, or AMM’s like Curve.

Abstract

This proposal aims to dovetail our current interests into one: supporting low volume low amount transactions, charging best in industry rates on nominal transactions, and giving a large boost to FOX holders.

Providing value to all while leaving no one in the cold, making ShapeShift objectively the best place as the bottom line is supported across the board.

Motivation

ShapeShift is not profitable. We are burning ~$200k in stablecoin runway each month, more if subsidized infrastructure via the Fox Foundation is included. We need to promptly course correct from our current default-dead business model and it should be in governance’s hands to determine that future

ShapeShift tried a “many revenue streams” approach. These are often characterized as great or diverse. Unfortunately, they all have either become defunct, have failed to deliver, or take so long to convert that the DAO can’t meet its obligations. Or worse, they deliver tokens that are held back from conversion into our main liability assets. While it makes logical sense to have diverse revenue, without proper ownership they don’t convert in any meaningful timeline.

Monetizing trade volume via fees is the de facto standard way for similar organizations or competitions within the ecosystem to generate revenue.

omgitsjustfees-alwayshasbeen.jpg

There exists ambiguity in governance and the community around recently implemented fees via monetization experiments with good arguments on both sides of an old debate.

Several proposals exist to indirectly address the debate around fees with varied approaches and subtexts.

  • This proposal seeks an amenable, unambiguous and clear compromise on multiple positions in a concrete way, meeting the following criteria:

    Free trades for small amounts under a specified parameter

  • Free trades for FOX holders over a specified parameter

Fees that decrease as a function of trade size, starting at a maximum parameter, decaying to a minimum parameter, with curve parameters.

A data-driven, unambiguous, governance-approved, and parametric fee model with clear invalidation criteria plus tunability is necessary to ensure robust trade driven revenue, and hence sustainability and survival for the DAO.

Specification

The model and its parameters shall apply to all current and future trade routes or features that include a buy and sell asset(s).

It is useful to consider the parameters and their interactions in parts.

Free trades for small traders

Problem: Small traders are fickle, transient, create an outsized support burden, yet are often vocal supporters of a good product. Although they are difficult to serve, they can become one of our strongest assets for the community.

Small traders are also difficult to monetize, for example

  • a 25bps fee on a $1,000 trade equates to $2.50 in DAO revenue.

  • This would require ~80,000 transactions of $1000 per month to generate $200k in revenue.

Large numbers of small users is difficult for support, operations and moderation; we reached a peak of ~50,000 MAU with ~$300,000 of OP token incentives

Solution - let small trades be free, up to a specified parameter. We propose the following parameter

  • MAXIMUM_FREE_TRADE_SIZE_USD

  • Denominated in USD at market price of sell asset
  • Price oracles are not of concern; downside risk is limited to a lost fee.

Set to $1000 initially.

A small trader given a good experience can become a loyal supporter. We let the krill go free.

Free trades for FOX holders

Problem: Currently the FOX token has no economic utility outside governance participation, sadly the space still find governance underrated as a use case.

Solution: This proposal gives the token utility by discounting trade fees to zero for substantial FOX holders. This is a necessary but insufficient step towards a FOX rewards program, which is yet to be specified.

The parameter should be designed with the consideration of the LTV of the user in terms of revenue foregone if fees were mandatory, assuming demand is purely inelastic. This is not precisely true, but a good linearization determines a starting point.

A reasonable economic burden to the buyer, but still creating a monetary incentive to buy, hold, and participate.

  • For the purpose of analysis, let’s consider the current market, and the persona “rational actor”

    a FOX price of $0.02, with

  • A user executing a $10,000 trade,

30bps fees

Said trade brings the DAO $30 in revenue. The persona of a user executing $10,000 in current market conditions is one of a regularly active participant. Assume they execute one transaction per month for 12 months, paying $360 in fees - their lifetime value, or LTV.

The following extreme examples would not fit their use case:

  • 100 FOX, or $2. A rational actor would buy $2 worth of FOX to offset a $30 fee on a single trade. Clearly, this is easily exploitable and harmful to DAO revenue.

1,000,000 FOX, or $20,000. A rational actor is unlikely to allocate $20,000 of capital to offset $360 of trades in a year.

There exists a balance we must strike to capture value between easily foregone revenue and an unattractive proposition to users.

As such, we propose the following parameter

  • MINIMUM_FOX_HOLDING_FREE_TRADE_SIZE

  • Denominated in FOX
  • Set to an initial value of 100,000 FOX,or $2,000 given the price used above.

Determined via the same mechanism as governance, i.e. SnapShot algorithm. This captures the market participants including liquidity providers, farmers, multiple chains etc.

Bear in mind, the cost of acquiring the minimum FOX required is not an expense to the user, rather a capital allocation. They are not $2,000 worse off - they have allocated capital to a liquid asset that can later be disposed of, and market participants may speculate on price and are exposed to volatility in both directions.

This could also be denominated in a USD value, with a utility appropriate to market conditions, say $2,000, and computed using a suitable price oracle such as Chainlink, however this adds additional lift and can be considered in a future proposal.

A future, or detail-focused technical suggestion to this proposal could specify additional parameters, such that the discount is not a binary option of the fee curve vs zero over the parametric threshold, but rather a function of FOX holdings and/or time. @woodenfurniture has good thoughts on a potential mechanism.

We support the FOX holding community.

Fee discount curve

Businesses operating at scale can afford to operate on lower margins, referred to as volume discounts.

Fees charged to a user should be proportional to the utility of the service that is provided to them.

Consider a flat 25 bps fee on various trade sizes

  • A user executing a $1000 trade doesn’t need a $2.50 fee to worry about.

  • A user executing a $10,000 trade on a slick and reliable UI will gladly pay $25 for the service of doing so. We’ve heard this direct feedback from users actually doing these trades “don’t clutter my UI with options, just make the execution good. I’ll gladly pay since I already do everywhere else.”

A user executing a $1,000,000 trade on the same UI will likely find a $2,500 fee steep, and are savvy enough to seek optimal trade routes elsewhere.

We propose a sigmoid curve-based decaying fee structure. This model allows for flexibility and value capture across various trade sizes.

The model is defined as follows

If you napped during math lectures like me and forget what a sigmoid curve is, the output of this function looks like the following.

Key Parameters

  • No-Fee Threshold (USD)
  • Transactions below this threshold incur zero fees.
  • Initial value: $1,000
  • Max Fee (bps)
  • The highest possible fee rate, applying immediately after surpassing the No-Fee Threshold.
  • Initial value: 29 basis points
  • Psychologically lower than 30bps, easy sell.
  • Min Fee (bps)
  • The fee asymptotically approaches this value as trade size goes to infinity.
  • Initial value: 4 basis points
  • Long tail value capture on large trades. $400 of fees on a $1mm trade is equivalent to ~8 cups of coffee for a $100k income earner, both representing 0.04% of the size.
  • Curve Midpoint (USD)
  • This parameter sets the inflection point of the sigmoid curve.
  • Initial value: $150,000
  • This “moves” the curve left and right.
  • Curve Steepness Factor (k)
  • Controls the "sharpness" of the sigmoid curve.
  • A higher value leads to a more gradual transition; a lower value leads to a sharper transition.
  • Initial value: 40,000
  • This value is unitless and arbitrary, but it feels right.

Model Features

  • Utilizes a sigmoid function to define the fee curve.
  • Allows for easy adjustments via key parameters.
  • Designed to capture maximum value in the range where the majority of trades occur.

Benefits

  • Accommodates both small and large traders.
  • Enables optimal value capture on the most frequent trade sizes.
  • Key parameters are under DAO governance, allowing future adjustments
  • Gives FOX holders another utility

Model implementation

A spreadsheet is available here to be forked

https://docs.google.com/spreadsheets/d/11e3Kys4wlMew-OGNoUX3IYb3wUOMxMPLxgJqYsJB-Jc/edit#gid=0

Raw LaTeX

Use https://www.quicklatex.com/ to render

\text{Fee (bps)} =

\begin{cases}

0 & \text{if } \text{Trade Size} \leq \text{No-Fee Threshold (USD)} \

\text{Min Fee (bps)} + \frac{\text{Max Fee (bps)} - \text{Min Fee (bps)}}{1 + \exp\left(\frac{1}{\text{Curve Steepness Factor}} \times (\text{Trade Size} - \text{Curve Midpoint (USD)})\right)} & \text{otherwise}

\end{cases}

Pseudocode implementation

The implementation is simple as follows and is a small engineering lift.

CONST NO_FEE_THRESHOLD_USD = 1000

CONST MAX_FEE_BPS = 29

CONST MIN_FEE_BPS = 4

CONST CURVE_MIDPOINT_USD = 150000

CONST STEEPNESS_DENOMINATOR = 40000

FUNCTION calculateFee(tradeSize)

IF tradeSize <= NO_FEE_THRESHOLD_USD THEN

RETURN 0

ELSE

steepnessFactor = 1 / STEEPNESS_DENOMINATOR

RETURN MIN_FEE_BPS + (MAX_FEE_BPS - MIN_FEE_BPS) / (1 + EXP(steepnessFactor * (tradeSize - CURVE_MIDPOINT_USD)))

END IF

END FUNCTION

Benefits

This proposal is quantitative and focuses the discussion on the mechanics and parameters of the model, rather than assertions and hope.

It is easily understood, marketable and catchy, with a consistent message, and details that can be expanded upon by referencing dynamic parameters, for example

  • “Small trades are free at ShapeShift!”

  • “We support small traders, we don’t charge fees under MAXIMUM_DOLLARS_FREE_TRADE_SIZE”
  • “Free trades for FOX holders at ShapeShift”
  • “We support our community - hold MINIMUM_FOX_HOLDING_FREE_TRADE_SIZE and get free trades at ShapeShift”
  • “Bigger trades are cheaper at ShapeShift”

“We welcome whales - only getFeeBpsByTradeSize({ sellAssetFiatAmount, curveParameters }) basis points for your $sellAssetFiatAmount trade at ShapeShift”, or “$400 fees on a million dollar trade? $FOX yeah”

Allows for data-driven feedback and experimentation with the parameters of the model to maximize revenue generation.

Creates a value accrual mechanism for the ShapeShift token outside governance participation.

Directly addresses multiple outstanding proposals trying to indirectly address this core issue in underhanded ways.

Users can choose to opt-out of fees by buying FOX, creating buy pressure.

Creates a liquid revenue stream across a variety of trade routes that can be promptly converted into stablecoins at the TMDC’s discretion to extend our runway and ensure survival.

Drawbacks

This may impact grant funding at optimism but TBD on other grant partnerships…

This may mean we are not classed as a free public good, worth noting we are still majority open source.

The delegation of responsibility to the TMDC is acceptable but not maximal decentralization. Ensuring a balance of rapidly responding to price volatility and market feedback, vs. the cumbersome nature of a governance vote enacting simple parameter changes will be difficult to explicitly define, refine, and iterate on.

The system may be open to abuse in unforeseen ways, leading to market volatility.

This is the best proposal for fees that I’ve seen, so kudos for that. Also, I appreciate you for going through governance to get community approval for fees rather than making this important decision on your own. Nonetheless, I still think it’s just a fancier, less bad version of fees, and I truly believe that we can and should do better. Otherwise, somebody else will (they could even just fork us), and if free market dynamics prevail, which they always do eventually, they will win.

I’d like to remind everyone that until volumes improve substantially, fees are simply not enough to make a significant impact on runway. We need an order of magnitude of more volume, and fees will only make it more difficult to attract that volume.

When this enters Ideation I will publish a counter proposal to not give up and start charging fees like every one of our competitors, and to instead test FOX rewards as originally outlined in ShapeShift’s decentralization announcement first. The counter proposal will include a proof of concept app built by Mercle.xyz where you can executed revenue-generating transactions and instantly claim real FOX tokens.

Until then, here’s a link to my thoughts on why fees are not a winning strategy, and how no fees + FOX rewards can lead to more revenues, unstoppable network effects, and a better future: https://x.com/willyogo/status/1656025695842123792

Last thing I’ll say for now:

IF the FOX rewards experiment fails, I will support the fee experiment proposal as outlined here. It’s too soon to give up now though. Again, fees are not a solution to our current problems, but they could make them worse and destroy our best opportunity.

Thanks to all who are thinking about this deeply :pray:

“The counter proposal will include a proof of concept app built by Mercle.xyz where you can executed revenue-generating transactions and instantly claim real FOX tokens.”

@willy Who at the DAO would be working on this? Product and Engineering have a very clear set of priorities (approved by governance) that they’re executing on. By definition, working on some rewards experiment would pull away resources from work that’s already happening. And similarly, who would pay for it?

Is this the same mercle team that botched foxatars, and my team voluntarily spent their weekends fixing their code, to ship a feature that no one believed in, and had no commercial viability, or success and failure criteria, but tons of mad vibes? The same team we said we’ll never work with again?

No thanks.

Not saying either way for me on this one. TMDC - by their definition, this would fall outside of that. (they decide what to do with whats IN treasury.) maybe another committee for settings. (or ask them about adding this to their list, /vote by them? or DAO to add to their purview) Item 2. seems low. so if Holding fox, makes 0 fee’s. item 3 doesnt count at all? maybe raise to 1m. (at current) setting (oracle) seems good. but with oracle, some buffer has to be in, as those users would get EXACTLY $2k and suddenly fall off and complain about that they had it, but at trade time it didnt work etc.

(in the pseudo code, i dont see the foxhold parameter) - if 3, then no 2? or just isolated example? (or i missed it lol)

Def interesting. Thanks!

Thanks for this proposal @0xdef1cafe and the people who helped you !

This is a much better compromise on monetization than simply mandatory fees. As stated, with it our app would not meet the definition of a non-excludable service (because as provider we can prevent people from using it if they do not pay beyond the free usage limit), and thus it would not be a Public Good anymore. By the strict definition our current funding partners apply to filter projects, it would disqualify us for future grants/funding (it’s also unclrear on the effect this would have on current active grants/funding programs we have not finished yet).

For context, a practical example, we would not be able to attempt to receive a RetroPGF grant from Optimism as planned, their last round (Round 2) distributed about USD 210,000 in spendable OP tokens to the top 10% projects (each), with a total funding of 10m OP. The next round (Round 3) plans to distribute 30m OP, so three times what was distributed in the previous round (maybe to more projects and/or larger grants). We are nowhere close to get trading volume that would match this kind of funding unfortunately, even with mandatory fees on everything (to take the extreme other scenario). So it’s important to weigh this in when we vote on this, especially if we are talking about immediate “Survival”.

Lastly, if this passes we should all regret that, as a DAO, we have failed to execute on three governance decisions that included FOX Rewards (SCP-121, SCP-128 and SCP-145) as a trading/deposit volume driver. We have only delivered on the opt-out donation part of SCP-128.

To answer a question from @seven7hwave there were Workstreams designated to own the feature/changes in SCP-128. It wasn’t executed completely, and pointing fingers won’t help, so I’m more interested in maybe still delivering what FOX Holders have asked. A working proof of concept for FOX Rewards exists, thanks to Mercle. If it doesn’t imply a huge lift or investment from the DAO to test it, why would we renounce doing it now? And what alternatives are suggested to drive users to our app?

As willy, I’m willing to compromise on this and vote for parametric fees (over just tests of mandatory fees) once we’ll have delivered what FOX Holders asked. Obviously, if they have changed their mind now and a proposal establishes it clearly (as this one would, thanks for the clarity on this @0xdef1cafe), let’s do it.

In all the potential scenarios (opt-out donations, mandatory fee tests, parametric fees), without a volume driver, we’re not testing much in my opinion. We can set all the percentage metrics we want, if we base it on low volume, it’s not representative of a success or a failure.

EDIT: Last thought (I’ve also shared during the Incubation proposal for mandatory fee tests), adding fees became a less and less viable solution since we’ve started providing a large part of the infrastructure necessary to run our app as an API (with a free tier). In this context any competitor who would want to drag us to a race to the bottom of fees can clone our app repository and deploy it without fees (vampire attack). If I’m not mistaken it’s already happening now… it makes me think we need to find ways to be sustainable without such fees (parametric or mandatory).

Sorry @firebomb I’m not following here.

SCP-128 didn’t mandate that specific Workstreams do anything with FOX Rewards, but rather only mentioned that one of the benefits of the proposal (at the time it was passed) would be as follows: “Buy time to experiment with no fees + FOX rewards, which could help the DAO in achieving strong and defensible product market fit.”

Since then the DAO has indeed had six month to experiment with no fees and FOX Rewards. Its experiment with Thrivecoin (which was at the time the most promising route to FOX Rewards) turned out to be a failure which almost cost the DAO hundreds of thousands of dollars, and in the meantime there have been growing concerns amongst many community members about the sustainability and desirability of pursuing FOX Rewards prior to the DAO being profitable.

I’m not seeing any mention of Fox Rewards in SCP-121.

It’s indeed listed as one of the many “interface bets” in SCP-145. I don’t advocate “renouncing” FOX Rewards, but ultimately defer to Product on whether this should be prioritized or deprioritized. And currently, for a number of reasons, FOX Rewards are being deprioritized due to the blockers that Product is perceiving. This follows ample time to experiment with adding them. I think it’s unambiguous and not a matter of controversy that WS Leaders have the ability to prioritize projects as they see fit.

“A working proof of concept for FOX Rewards exists, thanks to Mercle. If it doesn’t imply a huge lift or investment from the DAO to test it, why would we renounce doing it now? And what alternatives are suggested to drive users to our app?”

Hence my question to willy. What’s the lift or investment with this mercle experiment? And even if it’s possible, as we discussed yesterday there are many deep concerns held by community members, active contributors, and WS Leaders about doing FOX Rewards prior to the DAO being profitable. Also bear in mind the concerns defi has with Mercle (based on our recent experience with them) as outlined earlier in this thread.

In terms of driving more volume and transactions (referring to these and not users, since users is not a northstar metric defined by SCP-145), the compelling messaging and token incentives created by this very proposal could be helpful. "Bigger trades are cheaper at ShapeShift” is a compelling narrative, especially when combined with the added incentive of holding FOX to enjoy those benefits. Driving volume, not users, is the important task at hand IMO. Meanwhile, the employment of FOX incentives adds a potential value-accrual mechanism to the token.

But let’s throw the above argument out the window and say these fees won’t directly drive volume. Fine. Other ways to drive more volume would be targeted marketing campaigns on twitter (along the lines of what pastaghost was suggesting recently), a continuation of the current early momentum the DAO has seen with the RUNE ecosystem, leveraging the potential overlap between API users and the “whale” market segment (some likely API customers are also large-volume traders), and the upcoming rollout of Portals (which will notably improve the UI). To name a few. None of these are at odds with having fees.

Yeah excellent point on the TMDC, @Giantkin. It might make more sense for there to be a separate committee for what’s proposed above (similar to the old Olympus committee), although I’m sure the various TMDC members could provide invaluable input/advice around this.

At first glance (and without having time yet to give this a proper thorough reading), I really like the way this proposal combines a well-articulated and quantifiable fee-generation mechanism with an incentivization mechanism that provides added utility to FOX.

Exactly, and doesnt exclude a Tmdc member from being on this subcommittee , that might meet once a month? (or less, or with async checks, then setup meets… etc)

well said @Fireb0mb1.

@0xdef1cafe

  1. can you clarify these points?

    Which features are you proposing applying this fee model to?

  2. If fees had been enabled on those features this past month, and we aggressively assume the same volume amounts, how much additional revenue would the DAO have generated?

I think these are very important points to understand so the community can effectively weigh the cost-benefit of enabling fees now. @Fireb0mb1 did a great job of spelling out several of the costs of this. If the goal here is to to make smart business decisions that bring in more revenue than they cost, it seems like not adding fees is the correct decision.

@seven7hwave

re: What’s the lift or investment with this mercle experiment?

I’ll have a clear spec ready by the end of Friday this week. Tbh the lift required for ShapeShift’s engineering workstream is almost nothing. I could make the PR to activate the FOX Rewards card on https://app.shapeshift.com/#/demo/missions

  1. and link it to Mercle’s UI, where users can see the available tasks, a history of their completions, their total claimable rewards, and claim. That said, I do think it would be worth making the following changes to our UI:

    For any activity with FOX rewards attached (ie. buying/selling, trading, or depositing to an Idle vault), display the estimated amount of FOX that the user will earn.

  2. Show users the total amount of FOX they’ve earned on the FOX missions page, and let them claim directly from our UI
  3. This one is debatable and could be fast follow, but was already spec’d and mocked up as a stretch goal for FOX missions: considering we have these awesome Foxatars that any user can mint for free, and Foxatars are a necessary/integral part of how Mercle has built FOX rewards (very strategically designed btw), enable users to mint Foxatars natively and use that as an opportunity to teach about FOX rewards.

Out of all of the experiments that ShapeShift could run, this seems like a very reasonable lift considering the opportunity if this works.

While the community has delegated authority to product to prioritize the roadmap, the community also has the ability to revoke or overrule that authority. They are the boss after all. If the community votes for fees, I will be disappointed but will respect it. Until then, I feel compelled to explain why I strongly believe this is not the best strategy as well as outline what I believe is a better and more viable alternative so the community can make an informed decision.

@0xdef1cafe I really don’t understand where your vehement frustrations with Mercle come from. How did they botch the Foxatar launch? While it’s true that @0xApotheosis worked overtime to get Foxatars ready to launch in time for NFTBrasil and found a code in their yet-to-be-launched codebase, there have been countless bugs shipped to production in ShapeShift’s codebase. In fact, the majority of the time spent getting Foxatars ready for launch was fixing low level bugs with how ShapeShift’s wallet and keepkey signed messages, bugs that would have been much harder to identify if we hadn’t worked with Mercle. From my perspective, Mercle has been a world-class team to work with at every step of the way, and the way they’ve architected FOX Rewards is brilliant. If the entire engineering workstream refuses to work with them or their products (have only heard you say this), especially for an experiment for which they’ve already built the proof of concept, I think that’s incredibly poor judgement.

SCP-128 didn’t mandate that specific Workstreams do anything with FOX Rewards, but rather only mentioned that one of the benefits of the proposal (at the time it was passed would be as follows: “Buy time to experiment with no fees + FOX rewards, which could help the DAO in achieving strong and defensible product market fit.”

I understand this as a clear mandate to add opt-out donation and experiment with “FOX rewards”. The mandate for the first part is clearly attributed to Product and Engineering earlier in the text, which Workstream do you suppose should have implemented FOX rewards in the app if not these too? We can agree that it could have been more clear maybe… but considering that some work has been done at least by Product to do it, I think it was clear to them.

Since then the DAO has indeed had six month to experiment with no fees and FOX Rewards.

How many FOX were distributed as rewards to users over this period?

We have experimented with opt-out donations, without much volume and without the feature that was supposed to drive more volume to the app. I didn’t day they we didn’t have time, I say we didn’t deliver what was decided in that proposal in that time. Whatever the reason are, it’s a failure. If there wouldn’t be any mention of FOX Rewards anywhere in proposals, no documents/spec about it, I’d agree with you, but clearly some of the work has been started, has involved these Workstream (and the proposer) and we decided to deprioritize it and not finish it, in contradiction of what was asked in the proposal. Voters can judge us on this.

Its experiment with Thrivecoin (which was at the time the most promising route to FOX Rewards) turned out to be a failure

ThriveCoin is a rewards program that apparently fit in what Product/Engineering decided to prioritize, but it is not “FOX” rewards, it is a one-time OP reward from a grant obtained by Marketing. FOX Rewards has always been described and spec’d out as a way to rewards users for their habitual transactions in the app with FOX. Since we’ve actually met the OP grant goals planned for 6 months in only 3 months and it does place us in a great position for a RetroPGF grant potentially in the hundreds of thousands of USD, I wouldn’t call it a “failure”. We can agree that certain aspects of it were failures and important lessons.

which almost cost the DAO hundreds of thousands of dollars, and in the meantime there have been growing concerns amongst many community members about the sustainability and desirability of pursuing FOX Rewards prior to the DAO being profitabl

At no point has the DAO risked to be liable for “thousands of dollars”. ThriveCoin’s Terms of Service have always been clear about this, if we needed to cut rewards, even for legitimate participants, we could have. It would have been bad in terms of image, but there was no financial liability for the DAO. We found enough people who abused the program to not have to do this, thanks to both Gitcoin and ThriveCoin.

I’m not seeing any mention of Fox Rewards in SCP-121.

They are mentioned in the linked Roadmap of that proposal (and yes the argument that it isn’t part of the proposal text is a valid one, you can ignore this proposal relative to this point if you prefer, the point was that it has been talked and worked on for a long time). The spec was deemed executed by willy as an owner in the roadmap board, so at least there was some progress but no deliverable unfortunately (in the sense something that can actually deliver “FOX” rewards in the app).

Also bear in mind the concerns defi has with Mercle (based on our recent experience with them) as outlined earlier in this thread.

I do, I’ve worked with Mercle directly too and it’s not my experience of their service. They are very reactive and fixed multiple issues quickly when we’ve reported them, they have been reactive to our demands for FOXatar missions. The experience 0xdefi shared as far as I know happened when they first started working with us and it seems to have had a lasting effect on him, but since then Mercle has delivered more features and now a proof of concept for actual FOX Rewards, at no fee yet. I do think they deserve to be given a chance, especially since the same feature seems to be very hard to develop in-house unfortunately.

It’s indeed listed as one of the many “interface bets” in SCP-145. I don’t advocate “renouncing” FOX Rewards, but ultimately defer to Product on whether this should be prioritized or deprioritized. And currently, for a number of reasons, FOX Rewards are being deprioritized due to the blockers that Product is perceiving. This follows ample time to experiment with adding them. I think it’s unambiguous and not a matter of controversy that WS Leaders have the ability to prioritize projects as they see fit.

Many of the blockers were addressed by willy in the Tokenomics call you’ve hosted yesterday, primarily, the feature feasibility does not depend on our revenue or the value of FOX, it allocates a share (tweakble) of the revenues generated by a transaction as reward in FOX(y) for users that simply use our app to transact (no obligated assets, no obligated network, etc… as long as it generate revenue for us… and the reward is not happening just once).

I do not imply Product does not have the authority to to deprioritize this, I’m saying it goes against something that was explicitly asked to be delivered by FOX Holders. If it continues to be delayed I expect FOX Holders to notice and question why it has been, and vote accordingly (including for renewal of the Workstreams involved).

But let’s throw the above argument out the window and say these fees won’t directly drive volume. Fine. Other ways to drive more volume would be targeted marketing campaigns on twitter (along the lines of what pastaghost was suggesting recently), a continuation of the current early momentum the DAO has seen with the RUNE ecosystem, leveraging the potential overlap between API users and the “whale” market segment (some likely API customers are also large-volume traders), and the upcoming rollout of Portals (which will notably improve the UI). To name a few. None of these are at odds with having fees.

Thanks for sharing these ideas. I’m doubtful Marketing, unfortunately on low budget/resources, can carry this task alone as brilliant as they are, so hopefully it will work out in conjunction of other efforts. I’d like to focus on the one that is a feature “in the app”, Portals, I agree that it’s not at odds with fees, neither is it at odds with opt-out donations, so until a different explicit governance decision happens I am hoping that it will include opt-out donations. While I agree that better features can drive users, in contrast with actual monetary incentives from the past statistics we have, it’s a small driver. For comparison even a one-time Reward program like “Explore Optimism” (with all the failures you can attribute to it) make a new great feature like ThorChain Streaming Swaps look like a small bump in Mixpanel stats (if at all visible), so I’m still not convinced that we can rely only on this to have meaningful volume to look at… that’s why my interest is still in FOX Rewards, as soon as possible. Here’s the Weekly Active Transactor chart relative to this (Explore Optimism ended on Aug 1st, we’ve enabled ThorChain Streaming Swaps last week):

I do think FOX Rewards will have a more diluted effect than one-time bigger rewards like this OP program had, but they should put us at a constant advantage for all revenue generating transactions compared to any competitor.

“When this enters Ideation I will publish a counter proposal to not give up and start charging fees like every one of our competitors, and to instead test FOX rewards as originally outlined in ShapeShift’s decentralization announcement first. The counter proposal will include a proof of concept app built by Mercle.xyz where you can executed revenue-generating transactions and instantly claim real FOX tokens.”

Cross-posting my comment from the AMA that I was surprised was a demo of FOX rewards with Mercle on 8/30:

“It feels a little uncomfortable and weird that Engineering has stated they won’t work with Mercle going forward but we’re blazing through here with them now.

There was also a continued check in with Leadership and you @willyfox about making sure you weren’t promising that the DAO would do FOX rewards with anyone yet as we hadn’t scoped it completely and we weren’t happy with the current services that we were engaged with for other reward campaigns.

I’m not sure what was promised to the Mercle team about FOX rewards, but it feels a little disingenuous as FOX rewards is such a hot topic and the details of the service and its potential profit/benefit to the DAO are currently under question under governance right now.”

Was there anything promised to Mercle for doing all of the work they have done on your vision of FOX rewards thus far? There was never any acknowledgement that Mercle would be the team the DAO would partner with for future features, and quite the opposite, many requests from Product and leadership for a better understanding of potential service providers. To find us where we are with Mercle now seems perfect for Willy’s vision of FOX rewards, but also feels like an individual working against the direct communications and requests from Governance approved WS leaders and the DAO.

There was a clear communication from Product (the Workstream that will own and launch any reward program) about the work that needed to be done on the blockers that exist in the scope of FOX rewards. It seems rogue and in spite of the request from Product to present a demo before the blockers have been resolved enough for a kickoff or forward progress towards a feature release.

The questions were answered in the linner talk. ( looks like you left, its in the recordings, when they get posted)

be a few before they are up! :slight_smile:

Sorry… I am new here and I have been following the discussion about this proposal. I know, that my opinion doesn`t count a lot, as most of you here have been working on ShapeShift intensively over the last years and I have just been using it from time to time. Even I have been invested and following Thorchain, right from the start, when it was on the binance chain, I have been using Thorswap most of the time. But the pre-announcenment about Metamask and also this vote made me curious.

So I hope you don`t mind, if I add my five foxes to this discussion:

I do understand where willy is coming from and I get the idea behind it. However I do not share the fear, that it will make it more difficult for ShapeShift to grow in userbase and volume, when fees are added.

In contrary, I believe, that this can be very beneficial for the platform and community to make growing easier.

If fees are collected, they can be used for a sustainable treasury which helps further developments .

If, as a fox token holder, you can trade for free, of course the token receives more value. Which leads to more fox holder, which leads to more users.

A share of the fees can be used to be paid out to the community members or fox token holders (stakers).

There are many ways, of how fees can actually lead to growth.

At the end: it is not the cheapest product which wins the race, it`s the best….

Your def welcome! glad you shared your view!

  • Thanks for the proposal. It's good that such things are discussed so actively. I also really like the idea of giving fox more utility and was considering voting yes but I am wondering about these points:

    how can this work in a multichain environment, how can one prove his fox holding on ethereum while trading on other chains, e.g. bitcoin or cosmos?

  • how would this change impact onchain/gas fees?
  • @koryu thanks for the good questions - I’d quote you in a reply but this forum is turbo broken.

    I’m also glad to see active discussion about this, and would like to see more of these on topic questions.

    Proving holdings on other chains - we can have the holding eth wallet sign a message with addresses they want to trade from. They could also sign a message with the xpub of the account on another chain from which we can then derive all future addresses, this fixes the problem for the UTXO chains (read - BTC/BCH/DOGE/LTC).

    For THORChain txs it doesn’t impact anything, the memo exists regardless.

    For other routes it depends, and can make gas fees slightly higher. We can be smart about this, e.g. not applying fees if the gas impact to the user is higher than the fee for example. It gets very implementation-detaily, but they’re valid concerns and good questions, but probably too detailed/outside the scope of this immediate proposal.

    Really good points Tyler.

    If feels super premature to be engaging a team for a demo of an implementation of a feature that has yet to be specced, and would be managed and prioritized by @0xFBL on the product roadmap.

    I’ll reiterate my technical concerns again - Mercle really dropped the ball with simple foxatar stuff. The engineering team was thoroughly unimpressed. Rewards, when it’s defined, it’s going to be more complicated and risky, and open to abuse, as missions was.

    Let’s focus on building a good product people want and are asking for (trading), generate revenue like everyone else does (fees).

    Let’s not be fooled twice by a team building something that isn’t even defined yet, to give away money we don’t have.

    • Giantkin

      Another committee might be a good idea. I’m open to robust ideas that are easily implemented. Ultimately it should be done on chain like Aave/Curve. In the interim it’s a financial concern, and TMDC is the closest we have. The problem is “we need to be able to tweak params without weeks of governance debate”. I’m open to what the solution is. TMDC is just a proposed solution, and this in incubation.

    • Re price oracle - hence why I said it's a potential future step. Maybe I should remove that for clarity? Measure it purely in FOX. If the price moves wildly and the dollar amount no longer seems appropriate, we respond by tweaking the params, it's a nice problem to have. Hence the necessity for quick adjustments above.
    • Pseudo code is only for the curve. The pseudo (english) code that comes before it is "if you have more fox than the threshold the fee is zero". I addressed how we answer that with signing messages in another reply.