[Ideation] SCP-163 ShapeShift Dynamic Monetization Levers

[0xFBL]

Summary:

SCP 153 superseded SCP 128 leaving a gap in scope. This proposal formalizes the missing scope adding clarity for governance and workstreams.

The proposed amendment builds upon the principles outlined in SCP-153, which introduced a parametric fee model for trade routes. As of Jan 2024 the volume on Shapeshift has not only continued to grow but diversify, proving the business model works as expected. Shapeshift DAO should double down on this success.

This amendment enables the selective application of discount/fee structure logic to any monetizable area within the ShapeShift app, providing us with the flexibility to choose when and where to implement these measures. This approach ensures that we can maintain a consistent and sustainable revenue model, while also having the discretion to adapt to market conditions, user preferences, or promotional activities.

As a result, this proposal enables monetization levers, aligning FOX governance and workstreams around shared success. It extends the authority of managing discount/fee parameters across workstreams for checks and balances.

ShapeShift must stay competitive for long-term survival.

Abstract:

Tl;dr Make it optional for teams to enable or disable discounts/fees when reasonable.

This amendment expands SCP-153’s discount/fee structure to all monetizable ShapeShift app areas. It assigns parameter management to the Treasury Management and Diversification Committee (TMDC) and delegates implementation details, user impact, and market timing to the product and engineering workstreams.

Most importantly, this amendment broadens the scope of SCP-153, permitting the selective enabling of discounts/fees, rather than applying them universally across all features.

This amendment introduces default monetization parameters to the SCP-153 list of parameters. Eventually these should be automated and derived from on-chain data:

• no_fee_threshold_usd: This parameter, set at $1,000 USD, acts as the threshold below which no fees are applied, providing a user-friendly experience for smaller transactions.
• three_month_avg_bps: Starting at 10 BPS, this parameter serves as the default basis point (BPS) fee for events where other parameters may not be applicable, ensuring a consistent fee structure.
• monetizeable_action_size_discount_threshold_usd: With a starting default parameter of $1,000,000 USD for free. This discount threshold remains flexible to accommodate various use cases within the app, whether it’s a trade, deposit, withdraw, or other future action that hasn’t been created yet.

These default monetization parameters are designed to maintain a balanced and adaptable discount/fee structure. They offer flexibility while ensuring a consistent and user-centric approach to fee management.

An ancillary benefit to this amendment is that it simplifies the user experience and reduces implementation headaches.

Motivation:

This amendment aims to establish a flexible, adaptive discount/fee structure responsive to market dynamics. By clearly stating our intentions while avoiding excessive detail, we prevent the need for frequent new proposals, thereby avoiding missed opportunities and governance fatigue. This proposal seeks to make functionality and responsibilities more explicit/decentralized.

We recognize the importance of avoiding delays and ensuring the efficient operation of monetization efforts. This amendment seeks to strike a balance between sustainability and agility.

Extending the structure to more app features streamlines decision-making and quickly captures revenue opportunities.

It aligns our commitments, adapting to market changes while maintaining a diplomatic approach to community engagement and it reduces headaches arguing over specific wording of other proposals. Additionally, it makes implementations much clearer, reducing shipping complexity.

Crucial to this amendment is the built-in flexibility to deactivate unsuccessful monetization efforts or launch promotional campaigns incentivizing specific app functionality. This approach allows us to remain competitive, respond to user feedback, and make strategic decisions that best serve both the DAO and our users.

Specification:

When feasible, extend SCP-153’s parameters or utilize the default monetization parameters to all surfaces of the ShapeShift app, including but is not limited to, the following (with examples):

• Additional Trade Routes and Trade Features: This extension applies to trade routes and trade features that have not yet been launched, allowing them to benefit from the same discount/fee structure logic reducing engineering complexity.
  • E.g., Portals/zaps/shifts
• DeFi Functionality: DeFi functionalities such as Thorchain savers, any/all DeFi protocol pool deposit/withdraws including advanced liquidity functionality (regardless of origin chain or transaction complexity), staking/unstaking rehypothecation, smart contract wallet bundles, and minting will also be subject to the extended discount/fee structure scope.
  • E.g., Thorchain savers would ideally use the FOX discount parameters but, if too heavy, we would experiment for 6 weeks with the 10 BPS default, if users withdraw then it would turn off. TMDC and product would monitor the usage and capital flows.
• Future Monetizable Features: Any new features introduced in the app that have a relevant business case for monetization are eligible for SCP-153 discount/fee structure or monetizable action parameters.

The proposed discount/fee structure, as outlined in SCP-153 and expanded in this amendment creates a structured pipeline of responsibility:

• TMDC (Treasury Management and Diversification Committee): TMDC plays a pivotal role in researching and recommending parameter changes in collaboration with Product and Engineering workstreams. Through research, votes, and recommendations, they maintain a robust system of checks and balances. Fostering adaptability while ensuring user experience and DAO health.

• The TMDC shall utilize research, votes, and recommendations for managing the same Discount/Fee parameters as in 153 across any newly implemented feature:

  • 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 (edited)

• If the Discount/fee parameters are not applicable or too heavy, TMDC shall manage monetizable action parameters:

  • no_fee_threshold_usd = 1_000 # USD
  • three_month_avg_bps_ = 10 BPS # starting default parameter
  • monetizeable_action_size_discount_threshold = 1_000_000 # starting default parameter

• TMDC may propose adjusting, adding, or removing parameters as features deploy and gain more traction or negatively impact KPIs.

• As the primary body managing fee parameters, the TMDC should oversee the financial and strategic outcomes of the changes leading and building out monitoring for success metrics like:

  • Revenue growth
  • Unique addresses engaging onchain
  • Market share growth or decline
  • Changes in user balances over time

• Product: The Product workstream actively collaborates with TMDC to determine the practical implementation of fee parameters, user impact, and market timing. They work together on meeting market demand effectively.

  • Responsible for monitoring user engagement and feedback
  • Responsible for monitoring the adoption of new features, the churn rate, and the effects of implementing a fee, discount, promotion, or combination therein.

• Engineering: Engineering works closely with TMDC and Product to translate the approved parameters into technical implementations or surfacing blockers. They ensure the seamless integration of discount/fee structures across different app features and functionalities.

Benefits:

This amendment offers enhanced clarity alongside several benefits:

• Ensures consistency in the discount/fee structure across all monetizable areas of the app.
• Unblocks revenue potential by applying proven fee logic to new features with a backup of minimal revenue on by default.
• Less management since the parameter math is the same and the backups are simple.
• Allows for ongoing assessment and management of feature performance.
• Provides transparency and clarity in revenue generation methods.
• Utilizes cross-workstream accountability to put users first and listen to onchain data.

By extending the discount/fee structure logic to all areas of the app and granting the relevant authorities the ability to assess and remove non-performing features, the DAO can create a robust and sustainable financial model that supports its long-term objectives.

Drawbacks:

• There may be unknown technical implementation complexity.
• We may not be able to use discounts on all features which could potentially confuse users across different offerings.
• TMDC is sufficient but not complete decentralization. Market driven smart contract oracles preferred.

For: Formalizes the community is “for” the details in this amendment proposal. Including the optionality of setting monetization parameters, the management therein, and the additional scope.
For with amendments/changes: Acknowledges the proposals main points requesting some additions incorporated before final vote.
Against: Formalizes the community is “against” the proposal.

[Giantkin]

First thing that caught my eye:
If the Discount/fee parameters are not applicable or too heavy, TMDC shall manage monetizable action parameters:

no_fee_threshold_usd = 1_000 # USD
three_month_avgbps = 10 BPS # starting default parameter
monetizeable_action_size_discount_threshold = 1_000_000 # starting default parameter

So at this point, im like wtf. all that effort, discussion about free over x, and this removes the entire thing. lol.

but lower its explained the thinking, which makes me more ok with it.
“There may be unknown technical implementation complexity.
We may not be able to use discounts on all features which could potentially confuse users across different offerings.”

maybe add something along the lines of … We will attempt to put the Fox discount/fee parameters in. ( the above feels too …arbitrary wordage wise. (ie make an attempt))
otherwise seems ok (well, if your a fan of 153… heh)
– maybe the …arbitrary (ness) letting the decision ride on any one group?
Any other change that i didnt notice? (the above stuck in my brain heh)

[Fireb0mb1]

Thanks for writing this proposal! Definitely interesting and I’m not fundamentally opposed to it, but I have few questions and improvement suggestions.

@0xFBL

ShapeShift must stay competitive for long-term survival.

I agree, in that context, are our competitors applying additional fees on Liquidity Providing/Staking activities? The ones I’ve checked do not apply additional fees besides network fees.

While this proposal doesn’t say we will absolutely add fees for this, it seems to be one of the prime examples given and I’ve heard the suggestion in a TMDC call too earlier this week. So, I suppose this is the current use case that brought this proposal to life and I’m wondering how adding these fees would help us remain “competitive” if our competitors do not charge such fees?

Other than that, based on the vote results for SCP-153, I would say it makes sense to give a relatively wider power over the fee settings to Workstreams/Committees and notably the ability to remove fees where needed for promotional or competitive purposes.
In this spirit and to “decentralize” the decision even more (as members of the WS and the TMDC can have some overlap, as you know yourself ), wouldn’t it make sense to involve the Marketing Workstream in such decisions too, they are the ones who will have to actually promote and communicate such changes are certainly well placed to know when/if such changes/promotions will be well received by our users and potential users?

Lastly, two issues this proposal does not address explicitly and that I think should be added:

1. The potential for disagreements between the parties involved in the “decision” about the numbers and the features affected. How would these be solved, is there a required public vote involving all parties or just the TMDC? Who has the final say among all the parties involved? I think it would be wise to clearly define the process for such decisions.
2. Who will “own” the changes made and be responsible of reporting the effects of the changes? Will these changes always be tied to goals and metrics to determine their success? What happens if the goals aren’t met?

On a side note:

@0xFBL

The proposed amendment builds upon the principles outlined in SCP-153, which introduced a parametric fee model for trade routes. As of Jan 2024 the volume on Shapeshift has not only continued to grow but diversify, proving the business model works as expected.

I’m not sure how you’ve reached this conclusion regarding the business model changes introduced by SCP-153. We are barely 1 and a half months after the actual implementation of the model, we’re amidst an upward trending market (which almost always caused increase in volume for us), and we’ve also added cool new features which seem to be a main source of the increased volume if I read MixPanel correctly… attributing our recent better results to SCP-153 seems odd in this regard.
It surely contributed to securing some revenue on the newly acquired volume, but I’m not seeing any glaring example of how the strategy helped “grow but diversify” this volume. Do you have any?
What we need are more users and with more volume, I’m still doubtful that more fees are conductive to this. We still have competitors who have no fees and seem to thrive even more when it comes to user acquisition. Who’s to say we wouldn’t have had more success without SCP-153 with the same current market conditions. In all cases, my point is that it seems very early to make a conclusion like this.

[0xFBL]

@Giantkin

So at this point, im like wtf. all that effort, discussion about free over x, and this removes the entire thing. lol.

Hah, this made me laugh a bit too hard and i had the same thought! But it’s good to know it could be clearer upfront. put simply, It’s meant to add scope of parameters since the SCP153 ones are a bit heavy for anything that isn’t trading and the scope fo the app is still very very large.

@Giantkin

but lower its explained the thinking, which makes me more ok with it.

@Giantkin

We will attempt to put the Fox discount/fee parameters in. ( the above feels too …arbitrary wordage wise. (ie make an attempt))

Yeah this is kinda the point but it’s difficult to articulate without being wordy.

selective application of discount/fee structure logic to any monetizable area

is about as close as I could get for efficiency. Would welcome any other clarifying language.

[0xFBL]

Noice! Thanks for the insightful reply. Firebomb takes on progress are the best. What im hearing most is a call for some more clarity so i’ll try to be more articulate.

@Fireb0mb1

to involve the Marketing Workstream in such decisions too

good callout.I see marketing as an intimate part of the product lifecycle, after all, what’s the point of building if you can’t market? Ill add as co owner to the product responsibilities section.

@Fireb0mb1

it seems to be one of the prime examples given and I’ve heard the suggestion in a TMDC call too earlier this week

Could be! but also could not be. depends on the reasoning we have and to your point the research here could be clarified. We’re iterating through that specific features, and not at the point of making a decision. Also the market is pretty muddy for LPs, some charge and some don’t. It’s been months of work and im pretty sure the experience on Shapeshift is 2x better at minimum. I would advocate for something modest after poking around and @ProfMcCarthy would help evaluate/sanity check. @PTT has been leading the spec so it would be his data that helps everyone.

@Fireb0mb1

astly, two issues this proposal does not address explicitly and that I think should be added:

1. The potential for disagreements between the parties involved in the “decision” about the numbers and the features affected. How would these be solved, is there a required public vote involving all parties or just the TMDC? Who has the final say among all the parties involved? I think it would be wise to clearly define the process for such decisions.

More good callout is gud. For disagreements, I think we should strive to let TMDC votes be the ultimate decision with FOX governance as backup. Ideally, we can march towards using onchain data to inform the parameters in the future. Eventually no decision makers at all! That’s how all of them were designed.

@Fireb0mb1

1. Who will “own” the changes made and be responsible of reporting the effects of the changes? Will these changes always be tied to goals and metrics to determine their success? What happens if the goals aren’t met?

I think this is covered in the responsibilities section as all product specs have a failure, success, and growth case. But if you have thoughts on how to be more explicit that would be super helpful. At a broad stroke, flexibility is key but if goals aren’t met TMDC + other workstreams should notice and take action to revise.

@Fireb0mb1

I’m not sure how you’ve reached this conclusion regarding the business model changed introduced by SCP-153. We are barely 1 and a half months after the actual implementation of the model,

Hmm, not quite what the data is saying, I’m purely looking at swapper volume MOM not the best since we know private contributes a big chunk. Here are the paths that get to /trade as well. Other events tally at best 28% and the drill down isn’t as reliable as it could be.

I can’t see the correlation between new features like lending into trades (sadly-- we should track this a bit better and it’s part of our goals). Might i be missing some more inputs?

@Fireb0mb1

if I read MixPanel correctly… attributing our recent better results to SCP-153 seems odd in this regard.

As macho man randy savage would say “you may not like it but accept it”
In all seriousness though, it’s worth highlighting that i could have made this clearer. I agree that Volume increase is agnostic to the model being on, it’s not deferring revenue that is working as expected. I will make that clearer in the voting proposal summary.

@Fireb0mb1

It surely contributed to securing some revenue on the newly acquired volume, but I’m not seeing any glaring example of how the strategy helped “grow but diversify” this volume. Do you have any?

Again, and sorry if it’s pedantic, it’s more that fees on didn’t turn dramatically anyone away. Weekly active transactors are flat with ~1% decrease . So, not only did we gain we didn’t lose a ton of users either. That’s all.

@Fireb0mb1

We still have competitors who have no fees and seem to thrive even more when it comes to user acquisition.

i’d check that again. Trust just enabled a 70 BPS fee (!!!). They also didn’t see a drop in swaps. You can verify via flipside if you like. Lots of good queries on this board.

@Fireb0mb1

In all cases, my point is that it seems very early to make a conclusion like this.

Respect this position quite a bit, so i want to be clear that we should be vigilent and not get out over our skiis. so this vote is about moving towards more aligned process and capturing revenue. It also allows us, Thor willing, to run some dang promotions in the future. Which would be aces.

[Fireb0mb1]

Thanks for the answers!

@0xFBL

Also the market is pretty muddy for LPs, some charge and some don’t.

Which significant competitor charges additional fees on LP/Staking? Maybe I’m missing something or they don’t detail it in their breakdowns but I couldn’t find any among the usual suspects

e.g. ThorSwap doesn’t (but they do charge fees on swaps/streaming swaps). So we’d position ourselves at a disadvantage. But agreed, that would be part of the research conducted before taking such a decision and I assume it would be carefully weighted by all the parties involved.

@0xFBL

I think we should strive to let TMDC votes be the ultimate decision with FOX governance as backup.

I think it’s a good proposition, it aligns with SCP-153’s desire to delegate this task to the TMDC. It wouldn’t hurt to make that voting process clearer in this proposal though. Maybe for changes that do not trigger a governance vote (e.g. all parties involved in the decision are in agreement) we could still have a public announcement of the new parameters in the forum for example, in order to inform FOX holders that something has changed in regards to parameters they’ve originally voted on (and give them the opportunity to call for a governance vote with a proposal if desired).

@0xFBL

I think this is covered in the responsibilities section as all product specs have a failure, success, and growth case. But if you have thoughts on how to be more explicit that would be super helpful.

All good, it’s my bad, I missed it.

@0xFBL

it’s not deferring revenue that is working as expected. I will make that clearer in the voting proposal summary.

Fair enough, with this distinction, it is accurate. Thanks.

@0xFBL

i’d check that again. Trust just enabled a 70 BPS fee (!!!). They also didn’t see a drop in swaps. You can verify via flipside if you like. Lots of good queries on this board.

I didn’t know, sad news for their users then… good marketing opportunity for us to hammer on our much more advantageous rates now

It depends how brazen we want to be about it, but apparently (tested on Android) they do not display any breakdown of the fees and still have a “This fee is not paid to Trust Wallet” when you click on the info icon for the “Provider fee”. But clearly looking at the fee amount it is including 70bps fee There’s also no recent trace of them adding this on their public Github repo for the wallet and no other announcement…

In that context, with users not being informed that they pay fees to the wallet and likely believing it’s just ThorChain that cost this much it’s hard to claim the change has minimal impact on losing users in my opinion. In an ideal world users would notice the difference in fees and look into why it suddenly increased this much, but between high fee networks fluctuations and simple ignorance it’s pretty easy to “hide” fees like this to an existing user base unfortunately.

The Flipside link you’ve provided is great but it doesn’t seem to list the “new” ThorNAMEs Trust Wallet seems to use for these transactions with fees, there are no entries with “ti” and “td” which if you look at recent transactions are the ones in use now… There are entries with “te-ios”, “te”, “tr” on Flipside.

[0xFBL]

@Fireb0mb1

The Flipside link you’ve provided is great but it doesn’t seem to list the “new” ThorNAMEs Trust Wallet seems to use for these transactions with fees, there are no entries with “ti” and “td” which if you look at recent transactions are the ones in use now… There are entries with “te-ios”, “te”, “tr” on Flipside.

Exactly! That’s why we’ve been working on forking the details to more accurate picture of where things stand. It’s both art and science, plus there is never a “right” answer.

Anyways, a lot of this response, and mine, is quite ahead of the actual proposal should it pass. But! They are good insights/points for one of the discussion/evaluations of params on a specific feature. A good preview of how to approach these.

Circling onto the proposal details:

@Fireb0mb1

It wouldn’t hurt to make that voting process clearer in this proposal though. Maybe for changes that do not trigger a governance vote (e.g. all parties involved in the decision are in agreement) we could still have a public announcement of the new parameters in the forum for example, in order to inform FOX holders that something has changed in regards to parameters they’ve originally voted on (and give them the opportunity to call for a governance vote with a proposal if desired).

This … I reviewed a few times in the week, hence response delay. Announcing every change in the forum is starting to scope creep a bit. The point of this proposal is to make these things dynamic, precisely avoiding governance burnout for FOX holders, not creating more. The voting pattern in TMDC is already well documented and publicly available. I’ll let @profMcC_shapeshiftde mull on whether he wants to cross post outcomes, shouldn’t be too difficult to do a parameters changes once a quarter.

What seems simplest is moving the bullet list around a bit an then adding more explicit vote outcomes. My draft so far is:
"After a discussion and evaluation, TMDC shall finalize the following:
Feature.name
Parameters applied
Parameter name
Value
these votes can always be found in the [link here to discord].

• Pending team bandwith, product or the TMDC shall post parameter change outcomes to the forum once a quarter"