[Ideation] SCP-153 - Parametric Survival - A Pragmatic Fee Model

Summary

This proposal directly supersedes SCP-128 entirely.

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

FOX holders receive discounted, up to free trades, based on a parameter.

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 introduces a three-fold change to our DAO’s fee structure.

First, we eliminate fees for small trades.

Second, we dramatically reduce fees for high-volume trades, targeting large traders while maintaining some value capture.

Lastly, we propose linearly-discounted trades for FOX token holders, with 1,000,000 FOX giving a 100% discount, or free trades. This encourages longer-term holding of our native token, while simultaneously offering direct utility and value to our community.

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, or discounted trades for FOX holders based on holdings
  • 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.

Success and failure criteria

If over the 3 month trial period, 1 month trailing trade volume dips below 50% of the last 3 months average trade volume we will consider this a failure and revert back to no fees.

Outsized trade volume that was incentivized by Optimism token rewards shall be excluded from historical data, and the underlying trade volume considered.

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

  • no_fee_threshold_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 finds governance underrated as a use case.

Solution: This proposal gives the token utility by linearly discounting trade fees to zero for 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

  • fox_max_discount_threshold

  • Denominated in FOX
  • Holding 0 FOX will not apply any fee discount
  • Holding this value of FOX or more will discount fees by 100%
  • A linear discount is applied between, e.g. 250,000 FOX will apply a 25% discount to the fees that are otherwise calculated based on trade size.
  • Set to an initial value of 1,000,000 FOX,or $20,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.
  • We propose a second, accompanying parameter

    fox_discount_delay_hours

  • Initially set to 168 (7 days)
  • A user must hold the amount of FOX using the snapshot strategy for this period before the discount is applied
  • This parameter is intended to assuage concerns of users obtaining FOX, executing trades, then disposing of it shortly afterwards.
  • In the future, via a future proposal, this could be modified to ramp up to the FOX discount over a holding period
  • Currently, it is a simple delay

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

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.

See the Python implementation below, which is easily understood.

First, we can calculate the fee according to the sigmoid curve. A second dimension to the fee calculation is the FOX held which creates the FOX discount percentage. This discount percentage is applied to the sigmoid curve to get the final fee to be charged.

Key Parameters

  • FOX Max Discount Threshold (FOX)
  • Holding this amount of FOX gives a 100% fee discount
  • Holding a fraction of this FOX gives the same fraction of 100% as a discount.
  • 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: 10 basis points
  • Long tail value capture on large trades.
  • 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.

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

An interactive Google Colaboratory notebook is available here to be forked https://colab.research.google.com/drive/1DloLZDsy4-atEzFOlMixzdPlprFyjHik

Python implementation

parameters governance votes on

fox_max_discount_threshold = 1_000_000 # Maximum FOX held for 100% discount

no_fee_threshold_usd = 1_000 # USD

max_fee_bps = 29 # bps - what fees start at

min_fee_bps = 10 # bps - what fees go down to, if you don’t hold any FOX

midpoint_usd = 150_000 # USD - the “knee” of the fee curve

steepness = 40_000 # unitless - the steepness of the fee curve

implementation of the proposal you are voting on

def calculate_fee_bps(trade_amount_usd, fox_held, no_fee_threshold_usd, max_fee_bps, min_fee_bps, midpoint_usd, steepness):

# fee free amount

if trade_amount_usd <= no_fee_threshold_usd:

    return 0

# decreasing fee based on trade amount

sigmoid_fee = min_fee_bps + (max_fee_bps - min_fee_bps) / (1 + np.exp(1 / steepness * (trade_amount_usd - midpoint_usd)))

# apply the discount based on FOX held

fox_discount = fox_held / fox_max_discount_threshold

fee_bps = sigmoid_fee * (1 - fox_discount)

return max(fee_bps, 0)

Visualization

A visualization is provided for illustrative and grokking purposes. The parameters and function above shall be the canonical reference and implementation, and form the core of this proposal.

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 no_fee_threshold_usd”
  • “Free trades for FOX holders at ShapeShift”
  • “We support our community - hold fox_max_discount_threshold and get free trades at ShapeShift”
  • “Bigger trades are cheaper at ShapeShift”
  • “We welcome whales - only calculate_fee_bps(...) basis points for your $trade_amount_usd 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.

Tomorrow 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:

@willy I’m not sure if Fox rewards is a proper binary for a counter proposal here. If this proposal does not pass, Opt out donations (As currently outlined in SCP-128) will continue in the platform and app.

FOX rewards is a product feature that should go through the same process all other product features go through. We as a DAO have found ourselves getting into difficult situations with almost every product feature that has been presented and passed as a proposal (See Osmosis bounty, Yat)

I think a no vote is sufficient if you are not in favor of this proposal. A counter proposal that pits this proposal against FOX rewards goes against the established norms of the Product Workstream built around the Feature addition process. It also puts the DAO in another area of building a (this time, incomplete and still un-scoped) feature based on a governance Proposal instead of the Proposals that pass pertaining to Product’s roadmap.

gm @Tyler2, you’re correct that FOX Rewards itself would not be a valid counter proposal. I assure you that the full counter proposal will be more than just a signal from the community to prioritize FOX Rewards and will be mutually exclusive to SCP-153.

I also hear your concern around prioritizing a single feature via governance rather than leaving that decision up to the Product Workstream. To be clear, I am not proposing for authority on prioritizing the roadmap be taken away from the Product Workstream. The decision of whether or not to prioritize FOX Rewards (or any other feature) would still be up to them. However, if the counter proposal passes, it will show a clear signal from the community that before enabling fees, they want to first experiment with no fees + FOX Rewards, something that has been included on the tentative roadmap since the DAOnnouncement, but that I’ve always recommended should not be prioritized until the interface is seeing early signs of product market fit and organic growth on its own (certainly not before we hit parity less than 1 year ago). I actually don’t think we’re quite there yet, albeit getting closer every week (or at least most weeks :D). If my counter proposal passes, it will actually give authority to enable fees as described in the pragmatic fee model once no fees + FOX rewards is experimented with first (or a superseding proposal is passed).

Will share more details in the counter proposal once it’s ready, but hope that helps clear things up at a high level

@willy

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.

Why the sudden push for something that was originally proposed in March 2021? Why wasn’t the testing of FOX rewards pursued over the past 2.5 years?

It’s perplexing to see a new idea being told to take the backseat when the transition team that pledged to prioritize it as an inaugural partnership failed to take action for 2.5 years.

I’ve always recommended should not be prioritized until the interface is seeing early signs of product market fit and organic growth on its own

Could you clarify the authority under which you postponed the implementation of FOX rewards for 2.5 years? Was there a specific governance proposal that granted this authority to determine when the DAO achieves PMF? Additionally, what metrics are being utilized to gauge PMF?

I actually don’t think we’re quite there yet

I’m curious about the simultaneous push for FOX rewards while expressing a belief that the DAO isn’t yet prepared for such a rewards system due to the perceived need for ShapeShift to establish PMF beforehand. This apparent contradiction prompts me to seek a clearer understanding of the alignment between your statements and actions.

@Tyler2

I think a no vote is sufficient if you are not in favor of this proposal. A counter proposal that pits this proposal against FOX rewards goes against the established norms of the Product Workstream built around the Feature addition process.

Adds unnecessary complications to an already complicated process. Agreed.

It also puts the DAO in another area of building a (this time, incomplete and still un-scoped) feature based on a governance Proposal instead of the Proposals that pass pertaining to Product’s roadmap.

I’m still uncertain about who will be responsible for developing and integrating the new FOX rewards system into ShapeShift. Given that the Engineering team has expressed hesitance about collaborating with the Mercle team, is it anticipated that there will be significant extra expenses associated with outsourcing this task to another group of developers? Moreover, how can the community have confidence in onboarding a new team that will necessitate access to sensitive information?

The deeper I delve into the two available options – a fee system or a reward system – the more I find myself leaning towards the fee system. It’s evident that this fee structure has seen contributions from numerous participants and generally enjoys preference. @0xdef1cafe has done the work to get the concept in front of many stakeholders. When it comes to experimentation, it seems more prudent to explore something that already has substantial community input.

On the other hand, the FOX rewards system is being developed by an external team, with whom the DAO has previously had a less than satisfactory experience. This has resulted in considerable discord among DAO contributors during various calls. Furthermore, the development of this system appears rushed and seems primarily geared towards preventing the DAO from conducting fee experiments at any cost.

Introducing this rewards system isn’t just about bypassing fees; it also carries the potential for another round of discord within the DAO. This comes at a critical juncture for the DAO, impacting not only its contributors but also the stakeholders of ShapeShift.

It’s akin to opting for the unfamiliar devil in testing rewards, simply because the vocal minority is apprehensive about the known devil that could generate revenue for us.

As a side note, has there been any effort to investigate the implications of these fees on our Monthly Active Users (MAUs) and Daily Active Users (DAUs)? Has anyone conducted a thorough analysis on the volume of trades executed by ShapeShift, both below and above the minimum fee threshold? Furthermore, has there been a study on how we can intensify marketing efforts to cater to the larger traders on the platform to increase fee revenues?

thanks for the Q’s @probablyngmi

“Why the sudden push for something that was originally proposed in March 2021? Why wasn’t the testing of FOX rewards pursued over the past 2.5 years?”

The sudden push for this comes from FOX Rewards being suddenly deprioritized in the past few weeks along with a push to enable fees.

Here’s my perspective on why it’s taken this long:

Although FOX rewards was included in the DAO Announcement in July 2021 as part of the tentative roadmap, the first steps that the product and engineering workstreams aligned on was open-sourcing all of ShapeShift’s code and removing the centralized backend. This took until October 2022 (plus a couple months of polish and bug fixing), and then we still had a year and a half of innovation to catch up on. At the DAO WOW in December and the subsequent product strategy discussions, we agreed on plan/roadmap that we felt would make the product valuable without the rewards, and then would finally prioritize FOX Rewards towards the end of 2 phase 6 month strategy. During this period, ShapeShift received a 300k OP grant from Optimism for user incentives. We hadn’t completed all of the planned functionality from phase 1 or phase 2, and the decision was made to launch the OP rewards campaign at the beginning of June (alongside NFT support and Foxatars) with a self-imposed goal of launching FOX Rewards on July 1st with Thrivecoin to help maximize retention of participants in the Optimism mission. Unfortunately we realized around mid-June that Thrivecoin may not be the optimal partner for FOX reward, and soon after started working with Mercle to develop a proof of concept that was designed specifically for FOX Rewards and incorporated many of the learnings from the Optimism mission.

“Could you clarify the authority under which you postponed the implementation of FOX rewards for 2.5 years? Was there a specific governance proposal that granted this authority to determine when the DAO achieves PMF? Additionally, what metrics are being utilized to gauge PMF?”

I’ve never postponed the implementation of FOX rewards nor claimed to have this authority. I’ve just recommended that before prioritizing FOX Rewards, the product and engineering workstream first focus on building a product that is valuable without FOX rewards. This is just my opinion; I have no authority over the product or engineering workstream. I do think we’re getting close though.

“I’m curious about the simultaneous push for FOX rewards while expressing a belief that the DAO isn’t yet prepared for such a rewards system due to the perceived need for ShapeShift to establish PMF beforehand. This apparent contradiction prompts me to seek a clearer understanding of the alignment between your statements and actions.”

I wouldn’t be pushing for FOX rewards to happen right now if there wasn’t a proposal to enable fees. Also, my counter proposal will not mandate that FOX Rewards needs to happen immediately. It will simply give a signal that the community would prefer to experiment with no fees & FOX Rewards (something that has potential to make ShapeShift objectively the best way to use protocols from a financial perspective and attract the volume and users that the DAO needs) prior to enabling fees (something I think will not help with this, and could seriously hinder one of the DAO’s greatest opportunities).

“If my counter proposal passes, it will actually give authority to enable fees as described in the pragmatic fee model once no fees + FOX rewards is experimented with first (or a superseding proposal is passed).” - self quote

After thinking about it more, I think it will be best to not mandate in the counter proposal that the pragmatic fee model will be automatically approved if for any reason the FOX rewards experiment is a success. just going to make the counter proposal a signal from the community that they want to experiment with no fees + FOX rewards first. If the counter prop passes, the pragmatic fee model could be proposed at any point afterwards.

So one important suggestion on this proposal @0xdef1cafe : if the plan is to not use some staked version of FOX to calculate the discount and to instead use Snapshot voting power to calculate, I think it is important that a delay is instated to prevent obvious gaming of that type of system (related to the concern raised in the incubation post),

The time of the delay is debatable and could be a variable, but someone should not be able to acquire FOX and immediately get benefits at the “current” snapshot block. Instead, it will make much more sense (and be far harder to game) for a number of reasons if there is something like a 1 week delay (e.g. use snapshot to look at a block one week ago instead of the “current” block at time of a trade). This also rewards FOX holders for holding over longer periods of time. This could also work with a 1 day delay I suppose, personally I think something like a few days to a few weeks makes more sense though to start with.

This also creates some nice messaging around how to get the benefit (e.g. buy FOX and hold it for at least one week).

LMK if I am missing something in this regard or if it would be easy enough to implement this snapshot delay to help fight against potential exploits and further reward FOX holders.

+1 jon i think this would be another parameter for governance to toggle: fox_max_discount_growth_time and you’d set like 3 weeks to start. so the longer you hold the larger your discount gets until max.

+2 jonisjon.

Thanks for the input @jonisjon @0xFBL and @Dutch - I agree this is necessary to be added.

@0xFBL while I like fox_max_discount_growth_time, I think this should be incorporated in a future revision, as this model is already significantly more complicated than what was initially posted to ideation, and adding a discount that grows with time is another dimension. A simple delay instead of time growth discount is easier to implement and understand, especially when communicating this to FOX holders (which I have plans for how to do visually in the UI using the same surface as shown in the interactive models above).

When I send this to vote, I’ll include something to the following, more fleshed out of course

fox_discount_delay_hours with a value of 168 initially (7 days) for the FOX holding discount parameters to be applied.

Oh we out here with future params for sure. I don’t want to suggest going live with that complexity as a requirement . Maybe a fast follow proposal or suggestions for TMDC would suffice

With this current proposal and the counter proposal (SCP-154) not being able to fit in the character limit of a single vote on snapshot, I have pinned this proposal in its current form to IPFS to maintain an immutable record.

The CID is QmVsox8WdUhpWK35Pm3LvmSGGwtzSMFwwWojWJ7K8Dat7s (which you can use with your preferred gateway IE https://ipfs.io/ipfs/QmVsox8WdUhpWK35Pm3LvmSGGwtzSMFwwWojWJ7K8Dat7s)

The same will be done on SCP-154, so that the snapshot vote can reference both of these proposals and we will maintain a record of their exact text.

With this current proposal and the counter proposal (SCP-154) not being able to fit in the character limit of a single vote on snapshot, I have pinned this proposal in its current form to IPFS to maintain an immutable record.

The CID is QmVsox8WdUhpWK35Pm3LvmSGGwtzSMFwwWojWJ7K8Dat7s (which you can use with your preferred gateway IE https://ipfs.io/ipfs/QmVsox8WdUhpWK35Pm3LvmSGGwtzSMFwwWojWJ7K8Dat7s)

The same will be done on SCP-154, so that the snapshot vote can reference both of these proposals and we will maintain a record of their exact text.

“This parameter is intended to assuage concerns of users obtaining FOX, executing trades, then disposing of it shortly afterwards.”

I think it’s good to have the fox_max_discount_growth_time parameter be adjustable by governance in case it’s needed, but not sure it’s necessary to start with any delay. If a user really wants to avoid the fees, they can just go to another interface, which is easier than getting a friend to delegate their FOX to you and much cheaper/less risky than buying the FOX, executing the trade, and disposing of it shortly afterwards.

This is also why I think the incremental utility that this adds to holding 1M+ FOX is equivalent to the effort saved by using another interface, which is not a tradeoff I think we should be encouraging users to consider. On the other hand, SCP-154 adds uncapped utility to holding FOX by offering an incentive that is not easily accessible elsewhere.

curious to hear your thoughts on this @0xdef1cafe @jonisjon @Dutch @0xFBL

I’m not sure “they could go elsewhere” is a good argument to let folks easily exploit FOX benefits (if they are enabled). Not when we can easily stop that just by having a delay.

I also envision that this delay could be a foundational building block for other types of FOX benefits so I think it is still better than having no delay (and things like @0xFBL mentioned like a linear discount based on holding time in the future etc could become part of that).

Clearly if the community thinks no fees + fox rewards is the better option than they should vote for that, if they think the better option is fees then I think a delay is an easy to implement and an important part of it. At the very least having the param and making it adjustable is the important part, if the DAO wants to start with a small or no delay and adjust from there that is fine, but I think the important part is the ability to adjust that as I think it could play other vital roles in future FOX tokenomic upgrades.

Agree with this line of thinking @jonisjon. i do think it’s a good param to have in case this does get exploited, but also think the risk is low enough that it makes sense to start without it and then increase as needed. if it does get exploited, we may find that 1 day is more than enough to prevent gaming.

I see both sides.

One of the arguments against fees is that it adds friction - I don’t agree with this from a UX perspective, I think people expect them and it’s a split second deliberation of “yep, not price gouging, execute trade”

I do think buying FOX adds some friction, but it’s a one off thing, at the same time, it’s balanced by the utility this proposal gives FOX, by offsetting fees.

Adding a delay however, I do think adds significant friction. “I have to buy FOX, and hold it for a week, eh can I use something else?” Maybe something like 12 hours is a better initial delay? We could also ask the TMDC to experiment it being 0 delay, and see if it’s abused, and quickly adjust.

The time weighted discount application solves this though, as I can see a user going “I’ll buy FOX, do my trade I wanted now, and the delay will pass quickly enough and I’ll have free trades in future”. It’s mainly difficult to communicate this visually in an image, as the added time dimension makes the charts 4 dimensional (time, trade size, fox holding inputs, fee output), but we can easily communicate this (in the UI to users) with an interactive chart with sliders for time/trade size/fox holding (the chart surface output becomes 3 dimensional again).

Ultimately, these are all guesses, and the best thing we can do is get a model in place, measure, and iterate in a data driven way.