Workshop Followup - KPIs for Governance


#1

In the last workshop, I suggested we look for metrics to judge whether or not we needed to adjust governance parameters. At the time, no one had a suggestion for a parameter that needed to be changed. Regardless, we may choose this time to identify the underlying reasons to change a parameter and what will be measured to determine if the changes are necessary and/or are working as intended.

With that in mind, I propose the following draft of Goals and Metrics looking for your feedback. It would be ideal to come to some consensus on what we think the goal of each parameter is and how we want to keep track of it. We don’t necessarily have to agree on what the targets are for each metric at this stage, but those suggestions are certainly welcome as well.


MIN_DEPOSIT

  • Description: the number of tokens a candidate must lock as a deposit for their application, and for the duration of their listing thereafter.
  • Goal: Make challenges worth the effort (in time, gas and risk) such that all points are curated, being mindful to not discourages POI creation.
  • Metric: Cost of new points and challenges (theoretical gas spend based on recent gas prices).

APPLY_STAGE_LEN

  • Description: The duration, in blocks or epoch time, during which an application can be challenged. If this period passes with no challenge being issued, the candidate becomes a listee.
  • Goal: Highlight new points (and lock their deposit) such that there is time for the points to be curated and spam can be combatted.
  • Metric: Ratio of new points challenged during application stage vs after the application stage.

COMMIT_PERIOD_LEN

  • Description: The duration, in blocks or epoch time, during which token holders can commit votes for a particular challenge.
  • Goal: Give voters enough time to cast their votes and maximize the number of voters participating while resolving challenges in a reasonable time frame.
  • Metric: Ratio of challenges a reasonably active FOAM user (based on on-chain activity) could have voted on.

REVEAL_PERIOD_LEN

  • Description: The duration, in blocks or epoch time, during which token holders can reveal committed votes for a particular challenge.
  • Goal: Give voters enough time to reveal their votes while resolving challenges in a reasonable time frame.
  • Metric: Ratio of challenges that could have ended early due to having 100% of votes revealed.

DISPENSATION_PCT

  • Description: The percentage of the forfeited deposit in a challenge which is awarded to the winning party as a special dispensation compensating for their capital risk.
  • Goal: Give challengers incentive to stake a challenge deposit & voters incentive to participate.
  • Metric: Voter participation (based on tokens), Cost of challenges, Cost of votes

VOTE_QUORUM

  • Description: The percentage of tokens out of the total tokens revealed in favor of admitting/keeping a challenged candidate necessary for that candidate to get/keep listee status. The VOTE_QUORUM does not count non-voting tokens, and unrevealed tokens are considered non-voting.
  • Goal: Adjust the difficulty of challenges.
  • Metric: Challenge success rate.

5/9 Community Workshop II - TCR Parameter Adjustments & Registry / Voting Contract Upgrades
New Tags: Residential, Education, Transportation, Religion, Government – FOAM Map
#2

Application and post-application stage does not seem to have any practical difference at the moment, apart from blue vs green rendering on the map. Transaction costs and min deposit should already take care of spam prevention. So one less parameter and metric to discuss? Unless I am missing something about application stage mechanics.


#3

I’d like to steal this from https://github.com/ConsenSys/PLCRVoting:

Tactical goal : increase the number of tokens one owns by voting with the majority
Strategic goal : increase the value of those tokens one owns by making the system more valuable

from which we could define the guiding principle for this governance exercise as ensuring that strategic goal is not compromised by individual tactical goals.


#4

The practical difference is that “undo” operations for cartographers who add points are unavailable until this period is completed. During this period, the points are at risk of being challenged for typos and other fixable mistakes. It’s not new user friendly.


#5

Thanks to everyone who joined our second Community Workshop Call, where we discussed these five different TCR parameters that we, as a community, will have the ability to vote on and change once the governance module is live. It was a good discussion, with insightful points made by many different participants.

There’s multiple action items that came out of the call. Many are around gathering and analyzing metric data, or continuing the discussion. Anyone’s free to take responsibility for investigating these. Here they are, along with more general notes:

Discussion:

  • Proposals made to increase MIN_DEPOSIT to increase voter participation on POIs with minimum (50) staked

    • Gas spend is first factor for assessing this min_deposit, since this determines profitability of voting
      • People are generally overspending on Gas according to Caleb’s Calculations
    • How the min_deposit impacts number of voters on challenge is second thing to look at
  • Proposals made to lower to 10-1 points have also been made, to reduce challenging and better balance incentives between creating POIs and challenging

    • Lowering the min_deposit could lead to spam. Requiring stake is a spam prevention measure
  • Take into consideration people who have not completed Proof of Use yet before changing the smart contracts.

  • Action Item: Assess average gas costs as guideline for new min_deposit

  • Action Item: How do challenges play out across different stake deposits?

    • What is the distribution of stakes between points currently?

Discussion:

  • 60% of challenges are done after 7 weeks - mostly to POIs that have more in them than min_deposit

  • The remaining 40% are challenged almost immediately, within the first day or two, according to Caleb’s research presented in Community Workshop Call #1

    • Therefore, proposal to lower the apply_stage_len
  • Long-term proposal to even remove the parameter altogether

    • Calling out new POIs could just be a UI feature
    • It’s leftover from Adchain contracts, which FOAM’s were originally based on
  • Other long-term option is to keep the parameter but add in addition functionality at the smart contract level to provide some sort of defender’s advantage to verified POIs that have passed through apply_stage_len period

    • Ex. Challenger needs twice the POI stake in order to challenge the POI
  • How can it be friendlier for people who are newcomers/mistakenly placed POIs?

    • There have been some instances where people mistakenly clicked a spot on the map and sent transaction and then they had to wait the entire period to remove the POI, if it wasnt already challenged
    • Solution: Allowing users to remove points during the apply_stage_len?
  • Action Item: (longer-term) Think more about whether or not we even want to keep this parameter. Which long-term proposal do we like?

  • Action Item: (short-term) Discuss whether we should we decrease?

Discussion:

  • The current vote period is 5 days, there isn’t a reliable way to expand
  • Need to look more at the metric proposed

Discussion:

  • Problem with proposed metric is that there haven’t been many, if any, votes that have had 100% of the votes revealed

  • New metric?- Ratio of unrevealed to revealed votes at any given challenge

    • Issue here is that voters may choose not to reveal to save gas if they already know they are going to lose
      • debate as to whether this is a regular occurrence outside of the recent malicious challenger seeing 5 million FOAM whale votes and giving up
  • Action Item: Look at the median time that this happens and see if the challenge has a majority/100% vote already

  • New idea- If enough votes have been revealed already to reach the vote quorum, there is no need to continue the vote and reveal_period_len should end automatically, rather than only ending after a set amount of time

    • Seems like smart contract should just do this. The way it works now is just inefficient because it wastes time

Discussion:

  • Right now it is 60:40 for Challenger and Voter as incentive rewards

  • Look at Challenge Frequency?

  • What if we reduced the amount that challenger gets, and increase the amount that voters get?

    • Community has been upset with high incentive to challenge, and this would reduce that incentive
    • Community has also mentioned low incentives to vote (especially on low value POIs). Doing the above would at the same time increase voter rewards and thus voter participation
    • Is this “killing two birds with one stone”?
  • Action Item: Needs further discussion and investigation into the proposed metrics

Discussion:

  • % of tokens needed for having a challenge go through (% votes “True” of challenge)
  • Success rate is not an bad metric, but we also need to look at the total amount of points challenged
  • Action Item: look at success rate considering total amount of POIs challenged

Let’s keep the discussion going! Good ideas all around.


5/9 Community Workshop II - TCR Parameter Adjustments & Registry / Voting Contract Upgrades
#6

As a thought, 1-week voting period would ensure that there is a weekend for more casual voters to catch up with challenges. It’s a widely used fact that scheduling elections on a non-working day helps turnout.


#7

Looking forward to continuing the conversation on KPIs but have not had a chance to progress yet.

Regarding the application period, here is one recent example where a new cartographer challenges their own point in what appears to be an attempt to edit/remove the point after it was added. I assume because there are only “boost” and “challenge” options, they tried both. And it would have been faster to resolve by letting the application period expire, verifying it, then removing it. Confusing.


#8

I am also in agreement that the application period is confusing and potentially unnecessary, at least in its current form. As discussed, the only functional difference is the POI owner not being able to remove the point. Having this parameter results in extra work + gas spent to update the point to verified. (Right now, there’s hundreds, if not thousands, of blue points that are ready to be updated to green, but no one wants to spend the gas to do it.) This parameter also adds unnecessary complexity to an already somewhat difficult to understand map-game for new users. I also believe that simplicity is important in game-theoretic systems like this that need to be reasoned about.

For those that are unfamiliar with this topic, this is something that we discussed on the last Community Workshop Call.

Some arguments were made to add additional features in to make the application period slightly more useful, like giving a “defender’s advantage” to verified POIs, or removing the application period parameter altogether and just making new points a UI feature.