ShapeShift

Summary:

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

This 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 grown and diversified, deferred far less revenue, churned little to no users, and proves the business model works as expected. Shapeshift DAO should double down building momentum for the future.

This amendment enables the selective application of discount/fee structure logic to any monetizable area within the ShapeShift’s app(s) and extends the original scope with simpler fallbacks if needed. It also provides flexibility of choosing when and where to implement these measures. This approach ensures a consistent and sustainable revenue model, while also adapting 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 areas within ShapeShift’s app(s) . 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 improves 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 SCP-153’s list of parameters. We may not be able to use discounts on all features which could potentially confuse users across different offerings. Eventually these should be automated and derived from on-chain data

They are as follows:

• 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: A starting default parameter of $1,000,000 USD. This discount threshold remains flexible to accommodate various use cases within the app(s), whether it’s a trade, deposit, withdraw, or other future action that hasn’t been created yet.

These default are designed for a balanced and adaptable discount/fee structure. They offer flexibility, consistency, and a user-centric approach to discounts/fees management.

An ancillary benefit is simplifying the user experience and reducing implementation headaches.

Motivation:

This amendment aims to establish a flexible, adaptive, and sustainable 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. 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. This proposal seeks to make functionality and responsibilities more explicit/decentralized avoiding delays and ensuring the efficient operation of monetization efforts.

Extending the discount/fee structure to more app(s) features streamlines decision-making and quickly captures revenue opportunities.

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

Specification:

When feasible, extend SCP-153’s parameters or utilize the default monetization parameters on all surfaces of the ShapeShift app(s), including but 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(s) 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, recommendations, and ultimately voting they maintain a robust system of checks and balances. Fostering adaptability while ensuring user experience and DAO health.

• The TMDC shall utilize research, recommendations, and votes 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 the following monetizable action parameters:

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

• After a discussion and evaluation, TMDC shall finalize the following on a vote in the discord channel:

  • Feature.name
  • Parameters applied
  • Parameter name
  • Value

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

  • Revenue growth or decline
  • Unique addresses engaging onchain
  • Market share growth or decline
  • Changes in user balances over time
  • Traction, or conversly, any implementation negatively impacting KPIs.

Product/Marketing:

The Product/MKBD workstream actively collaborates with TMDC determining the practical implementation of fee parameters, user impact, research, and market timing. They work together on meeting market demand effectively and proposing parameter adjustments.

• Responsible for monitoring user engagement and feedback to parameter changes.
• Responsible for monitoring the adoption of new features, the churn rate, and the effects of implementing a fee, discount, promotion, or combination therein.
• Responsible for proposing any adjustments alongside TMDC.
• Pending team bandwidth, product or the TMDC shall post parameter change outcomes on the forum once a quarter.

Engineering:

Engineering works closely with TMDC and Product to translate the approved parameters into technical implementations.

• They ensure the seamless integration of discount/fee structures across different app(s) features and functionalities.
• They surface blockers early.

Benefits:

This amendment offers enhanced clarity and:

• Ensures consistency in the discount/fee structure across all monetizable areas of the Shapeshift product suite.
• 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.
• Utilizes cross-workstream accountability to put users first and listen to onchain data.

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 on chain data with dynamic adjustments 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. Against:  Formalizes the community is “against” the proposal.