UMIP 112 - Add uDAO_KPI_UMA as a supported price identifier

Headers

| UMIP # Leave blank - an UMIP no will be assigned at proposal stage

| ------------------- | ------------------------------------------------------------- |
| UMIP Title | Add uINT_KPI_UMA as a supported price identifier|
| Authors | Brittany Madruga (brittany.madruga@gmail.com |
| Status | Draft |
| Created | 06/08/2021 |
| Discourse Link | Insert link to discourse topic after it has been moved into draft UMIPs_ |

Summary

The DVM should support requests for UMA protocol integrations.

Key Performance Indicator(KPI) options are synthetic tokens that redeem to protocol tokens with the redemption value determined by performance against that indicator. One example of a KPI metric is Integrations. Integrations serve to measure the activity of the protocol rather than assigning all of the value to the dollar amount generated by the protocol, as previously seen in UMA’s TVL KPI option.

This UMIP enables the DVM to support price requests based on the number of qualifying integrations that occur during a specified timeline.

A synthetic option is minted against a base collateral, in this case UMA, which expires at 23:59:59 (UTC) September 30th 2021.

Motivation

The primary motivation for the development of KPI options is to allow protocols to incentivize Defi users to assist them to reach the protocol’s identified targets by leveraging their community resources by sharing their value with their community members.

Using integrations as a key metric directly benefits the UMA protocol because it encourages the community to build relationships in the broader DeFi community with the intention of providing tools that may be useful to teams who are currently unaware of what UMA has to offer. This creates a win-win across the board because it allows us to showcase our products and our products can then help other protocols to complete their goals.

By establishing the terms of a qualifying integration, it allows for the community to reach out in a way that aligns with the current priorities of the UMA protocol- attracting attention to our strongest products and encouraging teams to test out a wide variety of use cases.

It is anticipated that this Price Identifier will be used to create KPI Options, however it is acknowledged that it may be used for a variety of purposes.

Data Specifications

Voters should assess the status of deployed contracts using (insert link to UMAverse dashboard?). For an integration to be displayed on the UMAverse dashboard, it must meet the following criteria:

Any contract that falls into one of the categories listed below that has been funded with at least $10,000 of value.

  • Call or Put options
  • KPI options
  • Range Bonds
  • Integration with Optimistic Oracle
  • Long/Short Pair (LSP) Contract

Note: a contract that has been launched and funded by UMA will not count. However, a contract launched by UMA but funded by an external party does count.

The applied timeframe for this UMIP will be between 1622505600 and 1633046399, meaning that all qualifying integrations launched during this timeframe should be counted.

DVM Discretion

The UMAverse dashboard should not be considered the only source of truth. The DVM has the ability and responsibility to challenge the validity of any integration that has been included or excluded from the UMAverse dashboard if the broader consensus is that it is within the spirit of this UMIP to do so.

This UMIP is meant to identify integrations with UMA that are good faith experiments and product launches, as a way to gauge DeFi community engagement with the protocol. Some qualitative indicators of a valid integration (as opposed to a manipulative one) are:

  • Governance proposals discussing and approving a particular product launch
  • A properly funded contract that remains in place for longer than 30 days
  • Discussion within the UMA discord surrounding interest and strategy for a product launch.

This list is by no means all-inclusinve, but rather a reference point for the DVM if any ambiguities or challenges should come up. Any and all questions surrounding the validity of an integration can be brought up in further detail in the voting channel on the UMA discord.

Technical Specifications

  • Price identifier name: uINT_KPI_UMA
  • **Base: Number of qualified integrations
  • There is no quote currency in this option, as design feature. The collateral redemption is tied to the number of qualified integrations by design
  • Intended Collateral Currency UMA.
  • Rounding: Round to 4 decimal places
  • If the value returned is greater than 1.2000, round down to 1.2000 to provide a ceiling price.

Rationale

Specifics of this design were chosen to establish a minimum payout that will definitely occur, with the maximum payout being within reach. One idea behind this is that if we make sure we can reach our KPI, then we can turn around and launch another before this one expires to keep that positive momentum going strong.

  • Variable scaling is set up to reward implementations that occur before launch (between June 1 and launch date), but to provide the highest incentive to go out and get new integrations at the start of launch date. It also decreases the rate of reward after the intended payout threshold to create a plateau rather than running into a hard stop at the ceiling.

  • The decision to stick to the listed product types was made in order to bring focus to the products we want to push the most at this time.

  • Setting it up to allow for all qualified launches to be counted throughout the period rather than just at the time of expiry helps to ensure that we are not missing out on any integrations that might expire before the KPI option does.

  • Choosing a starting timestamp of June 1 helps to reward the community for the integrations they have already started on and help keep momentum going while the current KPI expires.

  • In order to reward the extra work that goes into larger integrations, any qualifying integration valued over $1 million will be worth 2 integrations.

Implementation

Step 1: Assess all contracts launched in the timeframe listed above (not sure yet how to do that, open to feedback on alternative “price feeds” if any should be included beyond the UMAverse dashboard).

Step 2: Assign 1 point for qualifying integrations, and 0 points for non-qualifying integrations. If a qualifying integration is worth $1 million or more, assign 2 points.

Step 3: Add up the total number of points assigned to qualifying integrations. This total number of points will be used in the following step.

Step 4: Determine the value of 1 uINT token (in UMA) by increasing the value of the uINT token (starting at 0) incrementally according to the following amounts:

  • 0.0167 for the first 10 points.
  • 0.0583 for the next 15 points.
  • 0.0417 for the next 3 points.
  • 0.0167 for any points beyond that.

Step 5: return the appropriate value (in UMA) per uINT that corresponds to the total number of points tallied. If value returned is greater than 1.2000, return 1.2000.

Example: if a voter establishes a tally of 12 points, they would say that 1uINT = (5 x 0.0167) + (7 x 0.0583) = 0.4917 UMA.

Security Considerations

How could metric manipulation occur?

  • By establishing a minimum value for qualifying integrations, it ensures that the cost of manipulation is higher than the possible reward for doing so. Additionally, the DVM voters have the ability to determine if it appears that someone is acting maliciously and can disqualify any integrations that majority believe should not be included.

How could this price ID be exploited?

  • I’m not sure it can be, since it is based on the definition of the metric. Thoughts?

Do the instructions for determining the price provide people with enough certainty?

  • Yes.

Are there any current or future possible concerns with the way the price identifier is defined?

  • It could be determined that the scaling is not appropriate in the event of overwhelming failure of the option. This would happen if we achieved too few integrations or if we had an unexpected number of integrations from one particular team. The latter can be remedied by the voting power of the DVM, as discussed above.
  • Additionally, there is the potential for ambiguities to present that have not been considered at the time of writing. In this case it will be up to the DVM to determine the resolution of those ambiguities. We anticipate hitting the ceiling, so it is possible that any ambiguities that arise will be non-significant.
  • It is possible that over the course of the KPI option, UMA could determine there are other products they would like to prioritize that are not defined in this UMIP. In that case, another KPI option can be launched to include that product.

Are there any concerns around if the price identifier implementation is deterministic?

  • No?
1 Like

Hey guys, just wanted to get a draft up to spark some discussion and recruit help/input.

Specifically, I don’t know what the best way is to instruct voters to find the data points they need. I don’t think our dashboards tell us which team created a project or what kind of project it is, which is sort of the whole point in the integration concept.

Thoughts?

1 Like

The snapshot provided helps to illustrate the way I set up scaling. Let me know if this (or a piece of it) would be useful to include somewhere more permanently.

Call or Put Options

Integrate with the OO maybe?

I like the payout matrix in theory. And even though I helped inform it, I do want some kind of validation that we aren’t starting with crazy numbers. I’d hate to end in 3 months at 8 integrations, or end in 1 month with 30 integrations.

We will be giving these out to people who have already worked hard and demonstrated that they will continue to work hard. So we are allowed to err on the side of concentrating payouts even more in the center, which would promise that the payouts would be more reliably healthy.

Just a thought. I think one thing we need to know to validate this payout scale is how many integrations we think are already “in the bag” and also ones that have already qualified since the start of June, if any.

1 Like

This needs to be more precisely defined. 10k in TVL? Liquidity? Does any period of funding matter?

Long/Short Pair (LSP) Contract

@Britt remember we talked about creating a validating system for what UMA centrally decides is a valid integration, such as by adding to the UMAverse website.

How do you feel about adding a section kind of like this:


This UMIP is meant to identify integrations with UMA that are good faith experiments and product launches. In an effort to tally the “no-contest” integrations, the UMA team will list them on a website and identify them as such. However, there could be some “contested” integrations and it is up to the wider token holder voting system to determine if any contested integrations are in fact legitimate integrations.

A framework is provided for helping identify legitimate integrations. They could include things like

  • Governance proposals discussing and approving a particular product launch
  • An average amount in excess of $10k in TVL for longer than 30 days
  • [any others…?]
1 Like

With regard to the $10k, I would say yes in TVL but I don’t think that a specific period of funding would matter in this case. However, I’m open to suggestions if you believe otherwise.

1 Like

@Clayton I think that little section would fit nicely under the Data specifications spot where I left a place holder for the future UMAverse dashboard.

My only thoughts on the example framework you listed:

  • governance proposals are a good indicator NOW of things coming soon (useful for establishing our expected range), but I wouldn’t think we would want to include that as criteria after launch for an integration.
  • similarly, if we specify a time frame of 30 days then we will be cutting off qualification for anything that occurs in September. Is there a reason we would want to consider a time frame that I just can’t see at the moment?

I guess I meant those to be qualifying but not disqualifying criteria. More like ways we can use to determine if something is an ‘in good faith’ integration vs. a spammy one.

ah, I see! You mean to define here the discussion points voters should use in the face of uncertainty, or in the event they think one is legitimate but was not recognized on UMAverse. Correct?

1 Like

@Mhairi-UMA I don’t seem to have the permissions/ability to move this to the draft section, but I am going to go ahead and get it up on github for review if you’d be so kind as to help me move it over to drafts. Thanks!

Maybe a dumb question. But what are the exact lists of approved integrations we’re considering? Can you maybe clear this up with an example? Or is still too early of a stage to worry about this at the moment?