[Ideation] SCP182 Implement Accountability KPIs for rFOX Staking Program

Proposal Discussion
1

Summary:
This proposal introduces accountability metrics for the rFOX staking program, providing clear KPIs tracking its success and offering the community tangible goals to rally around. These metrics will ensure the program’s performance is transparently evaluated, enthusiastically marketed, and built on a solid foundation. It allows for adjustment to meet KPIs or sunsetting if it fails to meet performance.

Abstract:
The ShapeShift DAO has already approved “SCP-166 an upgrade to FOX tokenomics” involving RUNE distribution and FOX token burns. This proposal seeks to build on that foundation by implementing a robust set of Key Performance Indicators (KPIs) to measure the success of the rFOX staking program. By setting clear goals, we aim to drive community engagement, ensure effective use of resources, and foster a culture of accountability within the DAO. Hopefully, if the program is a smashing success we have the numbers to qualify that now. If the program underperforms over a defined period, it will be sunset, preventing resource drain on unsuccessful performance. We already made a dashboard for some of these: [WIP] https://dune.com/shapeshift/rfox. This is an effort to be transparent and hold the program accountable.

Motivation:

  • Accountability: Establish clear metrics ensuring the rFOX staking program is held accountable for its performance. This proposal adds measurable goals and, as a benefit, significantly increases the marketability of rFOX participation.
  • Community Engagement: Provide the community with specific goals to support and rally around, enhancing user engagement and participation. By setting these goals, we aim to elevate our current/future community’s involvement, encouraging everyone to rise together towards common objectives.
  • Governance Responsibility: SCP 182 informs and empowers the DAO re: the success and viability of the rFOX program. By having a broad consensus and agreement about what constitutes success, the worksteams and the DAO are better equipped and informed in future possible trajectories of this and related programs.
  • Resource Efficiency: Ensure that the DAO’s resources are used effectively by evaluating and potentially sunsetting underperformance. If the program doesn’t not meet the established bar, we can redirect resources.

Specification:

  • KPIs Implementation: Introduce a comprehensive set of KPIs to track the success of the rFOX staking program.
  • Regular Reporting: Provide a live dashboard and/or regular updates on KPI performance to the community.
  • Success/Sunset Criteria: Define clear criteria for success/sunset of the program. More specifically, if two or more of the main KPIs are under-performant 3-6 months from August 2024, tokenomics/engineering/product will assemble a holistic report and make the decision to pivot, persevere, or end the program.

Main KPIs and Goals:

  1. Staking Participation Rate:
    • Definition: The percentage of total FOX tokens staked by users, calculated as rFOX deposits divided by the total FOX supply (liquid and in circulation).
    • Goal: Based on the first month; 5% MoM growth is a good benchmark. Failure is not achieving a 5% month-over-month growth for three consecutive months, indicating low user engagement and interest.
  2. Increase Trading Volume and FOX Burn:
    • Definition: The trading volume on ShapeShift increases, leading to increased FOX burns.
    • Goal: Within 3 months of August 2024, $24,000 per month is a success case and $75,000 of FOX burned per month is a smashing success. Failure is 3 consecutive months of sub $15,000 burnt (staying at our status quo).
  3. Number of Unique Stakers:
    • Definition: The total number of unique users participating in the staking program month-on-month.
    • Goal: < 50 unique stakers is a failure, ≥ 100 is a success, and 400 + is a smashing success per month. That means at 3 months we should see about 300 or so to consider it good. But, if there is 150 or less, that’s concerning.
  4. Staker Gini Coefficient:
    • Definition: The Gini coefficient of stakers in the pool above a certain threshold (100,000 FOX). The gini matters, but isn’t as important since it helps to describe the composition of users participating
    • Goal: For 38,843 FOX holders, aim for a target at about 0.6 – 0.3 for smashing success. This ensures a fairer distribution, and reflects more and more participation by a wider distribution of holders. A failure here is 0.7 and above for consecutive months, combined with no new stakers.
  5. Staker Retention Rate:
    • Definition: The percentage of users who continue staking their FOX tokens over multiple months.
    • Month on month Goal: 15%-25% retained stakers indicate success, and 30%-55% indicate smashing success. A staker retention rate of less than 15% for two quarters is a failure.
  6. Average Staking Duration:
    • Definition: The average length of time users keep ≥ 30,000 FOX tokens staked, 60,000 FOX tokens staked, 90,000 FOX tokens staked. Connecting FOX discounts, we’re tracking 10% , 20% , and 30% of the free fee threshold. Understand user commitment and the effectiveness of the staking incentives. If this isn’t sticky there is something likely very wrong.
    • Goal for 65% of the staking addresses: 2 months staked indicates success, 4 months indicates growth, and 8 months indicates smashing success. If the program is sticky it should reflect in both retention rate and duration of that retention.

Ancillary KPIs or nice to haves

  1. Percentage of Active Traders Depositing into rFOX:
    • Definition: The number of active traders who deposit rFOX divided by the total number of traders. We don’t want people parking their FOX and not trading. However, we have to consider UTXO’s as a wash, since linking them without a 0x account will be kind of moot. Out of all the stats this is the most fuzzy and most work-in-progress.
    • Goal: We want to be able to say something like “50% of stakers have done 1 trade in the last month.” Maintain a threshold of active trader participation over the last month if we can track it.
  2. Trading Volume & Number of Dolphin Holders of FOX and RUNE:
    • Definition: The trading volume of FOX and RUNE tokens on all exchanges and the number of holders goes up. (this is two different metrics)
    • Goal: 10%, 25%, and 45% increases in the number of holders for success —> growth. Less than 10% is failure. Volume looks like:
      • 1 million per day FOX volume indicates success.
      • > 10 million per day indicates smashing success.
      • Failure is current status quo of Below 500K trading volume. (what about RUNE?)
  3. Total RUNE Distributed:
    • Definition: The total amount of RUNE distributed to FOX stakers over a specific period.
    • Goal: Track to seek insights; simply tracking indicates success. We will market this heavily as it is the core benefit of the program.
  4. User Feedback and Satisfaction:
    • Definition: Feedback from users regarding their experience with the staking program.
    • Goal: Get actual feedback:
      • For interviews 0 indicates failure/status quo, 5 in-depth interviews (recorded and paid in FOX) indicate success, and 50 indicate growth.
      • Track and execute on Twitter feedback if we get any.
  5. Unique Visitors to Platform and rFOX Page:
    • Definition: The number of unique visitors to the ShapeShift platform and rFOX staking page.
    • Goal: Increase unique Monthly active visitors
      • Above 35K is success
      • Below 10k is a failure

Benefits:

  • Enhanced Accountability: Clear KPIs ensure the program is held accountable for its performance.
  • Increased Engagement: Tangible goals provide the community with a clear focus, driving engagement and participation.
  • Resource Optimization: Prevents resource drain on underperforming programs by setting criteria for success and/or sunsetting.
  • Governance Responsibility: Encourages responsible decision-making and ownership within the DAO.

Drawbacks:

  • Resource Allocation: Requires ongoing effort to monitor and report on KPIs.
  • Operational Burden: Increases workload for tracking and managing the program’s performance.
  • Potential Disruption: Sunsetting the program could disrupt current users if KPIs are not met.

Vote:

  • For: Formalizes the community’s support for implementing accountability metrics for the rFOX staking program.
  • For, with Changes: Supports the implementation with modifications to be specified.
  • Against: Opposes the implementation of accountability metrics for the rFOX staking program.
3 Likes
2

Looks great! Thanks for establishing these KPIs and goals.

3 Likes
3

Thanks @0xFBL for proposing this KPI initiative! It seems really well thought out and I think getting the community aligned on these KPI’s really helps give the community a good barometer for what may or may not be working about rFOX and FOX tokenomics in general as we begin to get the first few months of data.

In particular I love how this can give the DAO specific marketing talking points to help rally community support and help around, that could become really powerful and align incentives in imaginative and powerful ways.

A few thoughts as I read through this proposal:

Having some agreed on goals the community aligns on and can support meeting around rFOX seems great to me. The binary part of “either it meets the goals and succeeds or its shutdown” maybe contains the spectrum of possibilities a bit too much though? e.g. its very possible some of these goals succeed, some are missed, and some the DAO figures out were not the right goals to begin with for whatever reason. In such a case it may not be so clear that rFOX should be sunset, but it may be clear that particular alterations need to be made to rFOX to evolve and iterate on the program rather than shut it down or declare its success (and in practice that is probably a more likely outcome than a simple pass/fail evaluation). So, mainly just saying here I would suggest the proposal allows for more outcomes than continuing or sunsetting rFOX as the two binary possible outcomes, and ultimately however the goals are measured, evaluated, and reported on, I think its important that is used as fuel for community discussion around potential FOX tokenomics improvements (either building on rFOX or even replacing it with something else).

Love all of this :clap: I think its so smart to engage the community in ways that promote the whole community to work together on shared goals that benefit the entire ecosystem.

So, I have some concerns about this part of the specification.

(1). I am not sure it makes sense that any 2 KPIs not being hit would create some sort of automatic trigger that could potentially lead to an end to the program that isn’t voted on by governance digesting, discussing, and voting on the data to do so. For example, 5/6 of the KPIs could fail, but if trade and burn volume on ShapeShift increases significantly during the timeframe (and we see good evidence that rFOX is helping with that), it may not matter that the other 5 KPIs failed (maybe they just were not the right KPIs in that case and need adjusting). Or maybe the program just needs to be tuned based on that data and we can double down on the strengths that are working and edit out those parts that are not. So not sure setting some arbitrary trigger based on a number of the goals makes sense without also evaluating what those goals succeeding/failing might mean in context (and then making recommendations based on that which could include changes to rFOX, changes to the goals/targets, and sunsetting rFOX entirely).

(2) When it comes to how any decision for the future of rFOX is made from the KPIs, I personally think this should always resolve to governance and shouldn’t just be the decision of some assigned workstream(s) or committee, but I love the idea of the three mentioned workstreams issuing a report based on the KPIs along with their recommendations based on the data. I would suggest instead of some automatic trigger here that after some pre-determined amount of time (and makes sense being clear a report will be done in 6 months is good instead of a 3-6 more vague window) the three mentioned workstreams submit a report to the DAO that based on the KPI data may suggest wild success, possible changes/evolutions to rFOX or other aspects of FOX tokenomics, or a potential sunset of the program if the data suggests that no evolution makes sense from the perspective of the respective workstreams. From there the DAO could then vote on any governance proposal based on that report and likely have good/persuasive evidence to go on.

I think it remains vital that governance has the final say on any significant changes to rFOX or FOX tokenomics as well as any potential sunset of anything related to those aspects of tokenomics (and in fact I think tying rFOX more and more directly to governance and bucket params may be a great next iteration, but that is a discussion for another time). This is probably the only part of this current proposal that I couldn’t personally support in its current form if it stays this way for the final snapshot vote, but hopefully with some changes it would still achieve the same goal to accountably measure the success of rFOX and help the DAO adjust accordingly.

For the most part I really love all of the KPIs mentioned here, a few thoughts:

How will the circulating supply here be measured? Coingecko or another source?

Also seems like an average of any given three month period also captures the idea here better than if it reaches 5% or not in three consecutive months. An average would capture that something like +10%, -2%, +20% is clearly a success/trending the right direction where the current definition of how this metric is measured would consider that a failure.

Love this goal, and in many ways as mentioned above, if this alone was successful I would say rFOX as a whole might even be successful at that point (depending on the degree and context). Average over 3 or 6 months probably captures the trajectory of where things are going better, but isn’t a huge issue as this is currently defined as compared to 1.

Can we get a better idea of what this is intended to measure and what it means? I am not entirely clear based on the description of why these numbers would indicate a good or bad thing.

On the nice to have side, I really think it would be beneficial to also track what the effective staking APR has been in historic increments (7d/30d/3M etc). I think displaying at least the 7D on the interface would help attract more stakers and importantly help the DAO effectively evaluate and decide when buckets need to be tuned up or tuned down to help achieve the main KPIs.

Thanks again for getting this discussion going @0xFBL , look forward to hearing more thoughts from you and the rest of the community on this!

1 Like
4

Thank you, Jon, for your detailed feedback and thoughtful engagement with the KPI proposal. I appreciate the support for the initiative and your recognition of the value it brings in terms of accountability and community engagement.

For clarity’s sake: I will add to the final proposal that reporting will be at every product office hours and we already have a live Dune dashboard. Additionally, I will gauge engineering’s interest in adding performance reporting to the monthly IPFS posting thread or if it should be somewhere else.

Addressing some of the concerns and suggestions as topics:

Spectrum of Success and Flexibility

It’s absolutely the intention that this proposal allows for monitoring and executing on nuanced outcomes. Instead, it’s about learning from the data, iterating, and making informed adjustments. Those could be evolving and/or iterating on the program based on the KPI performance and user engagement. You’re absolutely right that evaluating the program on a spectrum rather than a binary pass/fail basis is paramount. This is why each KPI has success, smashing success, and failure criteria; they are a range. It’s important to recognize that some KPIs may succeed while others might not. I will incorporate this spectrum of possible outcomes, as your suggestions for flexibility and iterative adjustments are valuable. cheers.

Governance and Decision-Making

While the suggestion to have governance make the final decision based on the KPIs is well-intentioned, it’s crucial to acknowledge that governance has historically not taken responsibility for managing programs… It already has a solid foundation for initiative management. I’ll have to think about your suggestion critically for a workable outcome. Thanks for the input.

Growth and Success

Regarding hypotheticals about number of KPI’s === binary success or not, we covered that it is not binary. However, I believe it’s important highlighting that the program needs growth equaling success. Simply maintaining the status quo without demonstrating progress does not align with the goals of the DAO. The purpose of these KPIs is to ensure that the rFOX staking program is monitored and actively contributing to the growth + engagement of the community. Without measurable growth, it would be challenging to justify the continuation of the program, as I think we all can agree.

Specific KPI Feedback

Staking Participation Rate: I appreciate the suggestion to measure this both as an average over three months and month-on-month. This dual approach will indeed better capture the trend and provide a clearer picture of engagement. As for the circulating supply, we can specify that we will use a reliable source like CoinGecko to ensure consistency and transparency.

Increase Trading Volume and FOX Burn: Monitoring an average over three to six months is a great addition for capturing the overall trend and will be included in the revised proposal.

Staker Gini Coefficient: I understand the need for clarity here. The Gini coefficient is intended to measure the inequality in the distribution of staked tokens. A lower Gini coefficient indicates a more equitable distribution, which is desirable but by no means a critical thing. More stakers with a larger distribution of the pie almost certainly maps to new participants in the FOX ecosystem adn additionally would map to satisfaction as a user. I will provide another sentence explaining that metric in the final proposal to ensure everyone understands its significance.

Additional Metrics
Tracking the effective staking APR is a valuable addition but currently is in single-digit percentages, which is not great. Displaying this on the interface could possibly attract more stakers and provide useful insights for the DAO to fine-tune the program. I will add this to canny (possibly ancillary KPIs) since we have been tracking it anyway.

Thank you again for your constructive feedback. I look forward to incorporating these changes and continuing the discussion with the community.

2 Likes
5

I see the final proposal was posted up to snapshot today for voting, thanks again for pushing this forward @0xFBL! I really like where pretty much all of the KPIs landed and think this will serve as a great tool for the DAO going forward.

Unfortunately, I think the specifics around how any changes/sunset decisions get made though appears to have taken a step backward from the ideation post in terms of clarity of how this mechanism will actually work.

In the original ideation post it was mentioned that three specific workstreams (product/engineering/tokenomics) would issue a report after 3-6 months and then a decision would be made by those work streams regarding improvements, changes, or a potential rFOX sunset etc. I had suggested that in my opinion that any final decision should be up to governance ultimately based on the data from that report and that I don’t think big sweeping changes to FOX tokenomics, like sunsetting rFOX, should be made without clear governance ascent being part of the process.

Here is that original part of the ideation proposal:

And compare that to the language in the final snapshot that was posted today:

" * Success, Perseverance, & Sunset Criteria: Define clear criteria for the success of the program. The KPIs give the community the necessary input for the program’s growth. It should be obvious if the program is gaining traction, slowly succeeding, enabling participation, or underperforming. A strict number of KPI’s succeeding is too prescriptive, but bi-weekly reporting by product, weekly monitoring by the DFC, and the level of effort from engineering is sufficient to steer the program towards better outcomes."

I know there may be differing opinions here about what part(s) of that decision should or should not be up to governance or specific workstreams etc, but regardless I think this current proposal is not clear at all about that either way (and is unfortunately less clear than the ideation post was). Im not actually even sure based on the new language how this decision is supposed to be made at all if this proposal passes in its current form.

My personal opinion, as stated prior, is that this needs to be left up to governance as the final call for any major changes or sunset of rFOX as indicated by the data and report that comes from these KPIs (and personally I can’t support this proposal in its current form unless that aspect is left up to governance). However even if you disagree with that, it should be clear in the final snapshot proposal of who/how/what decides this (and the original ideation post was at least clear about this even if I didn’t personally support that methodology).

So, as a result, I think the current snapshot should be re-posted to be clear about this (e.g. is the final decision up to governance or some combination of workstreams leaders? Who/how/what decides this and the specification around that). If this part is not cleared up, I would have to urge others in the community to vote this current proposal down in its current form.

2 Likes
6

Thank you, @jonisjon , for your engagement with the proposal.

Clarity on Reporting and Decision-Making

I appreciate your concerns regarding the clarity of the decision-making process. To clarify, this revision incorporates your specific feedback about the robustness of reporting and removes a prescriptive number of KPIs for sunsetting. This gives the program much more of a chance to succeed, in my opinion. The proposal aims to provide robust monitoring and evaluation to ensure the rFOX program’s success, see below. Contributors are already excited about this type of visibility.

Reporting and Oversight

It should be abundantly clear that sunsetting is not the main objective. The revised proposal ensures continuous oversight and timely adjustments rather than hoping for good decision making at some pre-determined interval.

Clarifying reporting changes:

Bi-Weekly Reporting: The product workstream will provide updates every office hour, ensuring the community is regularly informed about the program’s progress. These will always be included in the presentations we produce each time.
Weekly Monitoring: The DFC will conduct weekly assessments to evaluate the program’s performance and make necessary adjustments. It will also iterate on incentives and ways to gain new participation.
Monthly report: There is a stretch goal for a monthly performance rollup when the IPFS hash is posted so the community can see the performance month on month holistically. A breakdown of KPI’s and any significant changes is reasonable and makes the necessary case for iterating, persevering, pivoting etc. We’ll do that, and as a result the community will have persuasive and clear evidence of performance.

Emphasis on Growth and Success:

The primary focus remains on fostering growth and engagement. The KPIs are designed to track the program’s success and drive improvements based on data and community feedback. The goal is to monitor the program holistically, ensuring it gains traction, slowly succeeds, and enables participation.

Governance and Community Involvement

Governance will not manage and cannot manage week-to-week decision-making. Asking for additional reports on top of continuous reporting to enable decisions is odd. Why would a workstream assemble another report on the rollup of its reporting? Especially if governance has already given the execution responsibilities (scp-166) and this proposal specifically enables better execution. The current proposal ensures that workstreams, which are directly involved in the program’s implementation, provide continuous oversight and timely adjustments. This approach balances efficiency with accountability and allows for quicker experimentation incentivizing the program’s success.

We’ll have to agree to disagree here and let the community decide.

1 Like
8

(sorry, i confused myself, dang tired)

I can see that this proposal is about reporting, setting up KPI’s i dont know why a proposal is needed to setup kpi’s.
couldnt we just set them up, and then proposals about actions on them?

like we did for the DFC levers about fee’s.
straight forward levers.

2 Likes
9

Your response doesn’t answer my question does it? What is the intention for the decision process as the proposal is written, as far as I can tell it is not clear anywhere in the proposal?

Whether or not that is the right decision making process for the ShapeShift DAO or not might be something reasonable people disagree on, but “what” the process is should be clear from the proposal no? It went from more clear in ideation to quite unclear in the final snapshot?

For sure, not saying there is any intention or objective to sunset rFOX until we get further data to evaluate the program, my point is more that if this proposal passing is intended to delegate any potential major modifications/changes to rFOX (including sunsetting) that should be clear from the proposal, and as it is currently written it is not.

If the intention is to allow certain workstreams to make potential modifications to the rFOX program, why not just be explicit about that as it was in the previous version of the proposal? I might not agree that is the right way to do this, but I also would at least know what the proposal is asking for.

This is great in regards to the data that will be provided to the community, but it doesn’t again answer the question of what process there will be for actually making decisions that affect rFOX?

Who is making the decisions based on that data? How and when are they doing it? What specific decision making power does this proposal intend to have governance delgate to whom and how/when can they use it?

So is the intention to not have governance ascent to decisions that may make some major change to rFOX like the buckets (which are specifically ascribed to governance in SCP-166)? If so, and this proposal intends to supersede that power by delegating that decision making to a particular workstream or workstreams, then the proposal should just clearly state that so governance can properly vote on whether it wants to delegate that power or not.

Right now the proposal does not specifically supersede SCP-166, and so in order to even make a change that would switch the decision making power from governance to specific workstreams, there would need to be language about superseding SCP-166 detailing what is superseded and what changes from the previous proposal as required by SCP-151. Otherwise if the intent is to re-delegate some of those powers it won’t even be effective in doing so.

No problem agreeing to disagree if we at least can be clear on where the disagreement is! As the proposal is currently written, it is not clear how/who/what is making any decisions and over what aspects of rFOX they can make decisions about (and your response above didn’t add clarity about what the intent is). If its meant to be the triad of product/engineering/tokenomics work stream leaders voting on potential changes, then that should be stated in the proposal (and it should stipulate which parts of SCP-166 are being superceded/delegated to those workstreams). If the final decision is meant to be recommended by the WSLs and then voted on by governance then that should be stated in the proposal. If some other method is intended for this then that should be stated too, as currently written its not clear that anyone (governance, or workstream leader, or anyone specifically at all) will have the power to make any changes based on how the proposal is currently written.

3 Likes
10

Thank you for your detailed feedback and for highlighting the areas that need further clarity. Let’s address these points directly and ensure the proposal is clear on the decision-making process and the roles involved.

Clarity on Decision-Making Process

The intention behind the proposal is to delegate the day-to-day management and necessary adjustments of the rFOX program to the workstreams, given their expertise and direct involvement. However, I understand the need for clarity on how major decisions, such as significant modifications or sunsetting, will be made.

Clarifying the Decision-Making Process

Reporting and Oversight provides a weekly, bi-weekly, and monthly narrative of performance:

  • Bi-Weekly Reporting: The product workstream will provide updates every office hour, ensuring the community is regularly informed about the program’s progress. These will always be included in the presentations we produce each time.
  • Weekly Monitoring: The DFC will conduct weekly assessments to evaluate the program’s performance and make necessary adjustments. It will also iterate on incentives, proposals, and ways to gain new participation.
  • Monthly Report: There is a stretch goal for a monthly performance rollup when the IPFS hash is posted so the community can see the performance month-on-month holistically ( as mentioned we’ll just do this, instead of stretching). A breakdown of KPIs and any significant changes will be provided making the necessary case for iterating, persevering, pivoting, etc. This ensures the community has persuasive and clear evidence of performance.

Decision-Making Process:

  • Day-to-Day Adjustments: Minor adjustments and iterative changes will be managed by the workstreams directly involved in the program’s implementation (product, engineering, and tokenomics). If they need a governance proposal such as changing the buckets, then there will be one with rationale, again, thanks to reporting.
  • Major Decisions: Significant changes will be based on the holistic reporting prepared by the workstreams after evaluating KPI performance within the structured cadence. These decisions will be made by the triad of workstream leaders (product, engineering, tokenomics), who are directly responsible for the program’s success. For clarity’s sake on sunsetting specifically– since this keeps taking the focus instead of growth– if the program underperforms continuously within a window of 6 months from August 1, 2024, it will be sunset, preventing resource drain on unsuccessful performance. If governance decides that this specificity needs to be included and votes against the proposal that’s fine. I also found an annoying typo so I welcome the opportunity to submit it again. :face_with_open_eyes_and_hand_over_mouth:

Clarification on SCP-166:

  • This proposal does not supersede SCP-166. It builds on it by providing a clear framework for continuous monitoring and iterative improvements, the pieces missing from SCP-166. Any decisions that would alter the core aspects of SCP-166, such as the buckets, will be managed by the workstreams in accordance with the existing governance framework, ensuring compliance with SCP-151. @ProfMcC is already working on those if memory serves.

By clearly outlining the roles and responsibilities, we ensure that the proposal is not only robust and flexible but also transparent in its execution and decision-making processes. This approach balances efficiency with accountability and allows for quicker experimentation, with the ultimate goal of incentivizing the program’s success.

Thank you again for your engagement and support. We look forward to working together to ensure the rFOX program thrives.

2 Likes
11

Thanks @0xFBL for this much clearer response and for the brief discussions on the governance call today.

It is at least now more clear to me that the intention of this proposal is for workstream leaders to have some level of decision making power over rFOX based on the data and evaluation that happens (similar to what was in ideation, but was removed). I just wish some of this was actually clear in the text of the final proposal so FOX token holders would know what they are voting on and what powers they are delegating to whom.

In regards to the process here that you are making clearer, a few questions/comments:

What falls in the buckets of “day-to-day” adjustments? Could you give some examples of things that would fall into this and what doesn’t and how something is decided to be a day-day adjustment? Can any individual WSL make these day-day adjustment unilaterally or is there some vote among the 3 WSL’s to effectuate a change?

Pretty much the same questions, what falls into the bucket of “major decisions”? Can you give some examples of this in terms of what changes this might entail and what it does not? Is the process a vote among the 3 WSLs or something else?

Again I am strong supporter of what I believe the spirit of this proposal is and I think the KPIs you have come to are awesome, I just want the text of the snapshot to be clear about what powers are being delegated to whom and in what way decisions would be made so governance knows what it is voting on and there isn’t debate later on due that lack of clarity.

Good to know the intention is not to supercede SCP-166 in whole or in part, but I think if the goal is to give the three mentioned WSLs any control/ability to make changes to the buckets of treasury/staking/burn it would be required to supersede SCP-166 since SCP-166 was explicit around the fact that particular power is controlled only by governance.

Maybe we are splitting hairs, but sunsetting rFOX at any point would mostly be equivalent to setting the treasury bucket to 100% and the others buckets to 0% and as currently written (without another superseding proposal) that is required to be a change that is made by governance.

Maybe the intention is to never alter the buckets without governance (still not entirely clear on that), in which case I agree nothing needs to be superseded, but if the intention is to give some specific decision making powers around altering of the buckets to the designated WSLs, that should be explicit in the snapshot text (who is being delegated to, what the decision making powers are, and how that decision process works among the 3 WSLs).

I want to re-iterate that I think we are on the same side and motivation here regarding the underlying spirit of this proposal, we may disagree about what specific decision making powers should be delegated and how and ultimately voters can decide on that, I just want what decision making powers are being delegated and how that is supposed to work to be clear in the proposal text.

Maybe we get another chance at that if the proposal does fail in its current form, or maybe this leads to a subsequent proposal to clarify if it passes! I just think any such subsequent proposal could be easily avoided by just being clear about this now in the final snapshot text.

2 Likes
12

I don’t think this is splitting hair and I agree with you on this, the buckets were a specific vote option in SCP-166 “Part 2”,, if they need to change to any value, currently the only way to do it is through governance as per SCP-166:

Effectively the specification of this governance proposal would setup 3 parameters […] governance can modify this with a subsequent proposal in the future to alter any of these, including setting any of them between 0-100%. [emphasis mine]

The Ideation language of SCP-182 (this proposal) specified that the involved Workstreams could “pivot, persevere, or end the program”. The “Final Vote” does not make such attribution anymore, so it should be clear to the proposers/Workstream Leaders involved that they won’t be able stop the program without an additional governance decision even if this passes.

If they want this power, they should ask for it explicitly in this proposal (like it was the case in Ideation, which I supported) or in a new proposal (e.g. when they want to stop the program).

The permissibility and ownership of such decisions should be explicit, especially because that program was decided by FOX Holders.

EDIT: I am voting For this Final Vote, as I presume it was done knowingly, but I hope everyone is clear on the implication of this change when potentially actions will need to be taken after sufficiently evaluating these great new KPIs. But hopefully we exceed all of these and it isn’t even a concern, long live to rFOX :smiley:

2 Likes
13

Just chiming in with my opinions here.

Amid the many posts above, one quote stood out for me and I felt it was important to highlight:

any final decision should be up to governance ultimately based on the data from that report and that I don’t think big sweeping changes to FOX tokenomics, like sunsetting rFOX, should be made without clear governance ascent being part of the process.

Now that governance has willed rFOX into existence, the workstream leaders are in charge of its operation. The way I understand the proposals, workstream leaders can tweak its operation but not sunset it. It’s my interpretation of the governance proposals that in order to turn rFOX off, a new governance proposal would be needed to be voted upon by the community.

I’m excited about this opportunity for the DAO and look forward to its implementation!

–MP

1 Like
14

Great work, @0xFBL on pushing forward with these clear KPIs for our rFOX staking program. It’s exactly what we need to keep everything transparent and continuously improving.

I can empathize with @jonisjon and @mperklin & agree that we need to be careful about how we proceed. I think a balanced approach could work best here. Let’s implement these KPIs, but also keep an open mind about potentially sunsetting the program if it doesn’t meet our goals. This isn’t about pulling the plug prematurely; it’s about having a clear and open discussion based on our performance metrics if and when it’s necessary.

This strategy lets us keep a tight check on performance while giving us the flexibility to adjust based on what we’re seeing on the ground. It keeps us accountable, is transparent, and builds consensus.

On another note, I want to touch on the discussion about the role of workstreams versus the guidelines set by our SCPs. It’s important that we keep these discussions focused and constructive. But, let me digress into the theoretical:

Workstreams need the agility to pivot and work alongside governance, effectively steering the DAO towards the best possible outcomes based on community input and the changing tides. Workstreams’ very existence is testament to the ad-hoc modification of governance to make up for its failures. While Workstreams can’t lose the forest for the trees (they are there at the behest and will and direction of the DAO), workstreams are also both mandated by the DAO and self-interestedly to act in ways that are to the betterment and survival of the DAO. This isn’t about bypassing protocols but enhancing our ability to respond dynamically to new information and community sentiments.

By setting clear metrics of success and defining timelines for review, we make sure everyone’s on the same page, enabling our workstreams to be proactive rather than reactive. This clarity will help keep contributors aligned and focused, as well as avoid redundancy and execution delays.

1 Like