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.