Add Athlete Performance Token (APT) Price Identifier

An UMIP number will be assigned by an editor. When opening a pull request to submit your UMIP, please use an abbreviated title in the filename. The file name should follow this format - “umip_add_priceidentifiername.md”. Please remove this and all italicized instructions before submitting your pr. All bolded fields should be filled in before submission.

Headers

UMIP
UMIP Title Add APT as a supported price identifier
Authors AthleteX DAO (athletexmarkets@gmail.com)
Status Draft
Created 9/8/2021
Discourse Link Add Athlete Performance Token (APT) Price Identifier

Summary

The DVM should support price requests for APT. APT reflects the price of an Athlete Performance Tokens (APT).

Motivation

Athlete Performance Tokens provide exposure to an athlete’s statistical performance.
This has a range of advantages, including player specific hedging, long term athlete
growth exposure, and less friction when adjusting positions (e.g. from Bitcoin and other
cryptocurrencies to LBJ).

APTs also unlock nascent markets in sports not currently available with traditional
sportsbooks. Some examples include, umpire tokens that track correct balls and strikes
percentage, and 1-game expiration tokens with high in-game volatility for live trading.

Athlete Performance Tokens are cryptocurrencies that track the statistical performance
of athletes. APTs are Long-Short Pairs collateralized by deposits in the Staking Contract.
Each athlete has a Long token reflecting positive performance and Short token
reflecting negative athlete performance. APTs can be bought and sold on the Trading
Block or redeemed for $AX at expiration. Redemption prices are an aggregate of
in-game performance statistics provided by SportsData.io.

Data Specifications

How should voters access the data necessary to calculate the value of this price identifier? What specific markets or data sources should be referenced?

If proposing multiple price identifiers, please add markets or other data sources for each.


  • Price identifier name: First Price ID Name
  • Base Currency: BASE - ETH - May not apply if this is not a typical Base/Quote price
  • Quote Currency: QUOTE - USD - May not apply if this is not a typical Base/Quote price
  • Markets & Pairs: Markets & Pairs - Example: Binance ETH/USDT, Coinbase Pro ETH/USD. This might not apply to all price identifiers
  • Example data providers: Provider to use - Cryptowatch, TraderMade, Quandl, the Graph
  • Cost to use: Explanation or link to provider pricing plan
  • Real-time data update frequency: Frequency - 60 seconds
  • Historical data update frequency: Frequency - 5 minutes

Price Feed Implementation

To allow for the creation of bots that can programmatically calculate prices off-chain to liquidate and dispute transactions, you must create a price feed following the UMA Protocol format (outlined below). This price feed is also necessary to calculate developer mining rewards.

If using existing price feeds from the UMA protocol repo, please list the price feeds used and write a price feed configuration following the examples here.

Ancillary Data Specifications

This is an optional section. If your price identifier is not intended to use ancillary data, you can remove this section entirely. You can read a full explanation of the expected ancillary data format here. An UMIP example of this section can be seen here.

Rationale

The section should describe why price identifier design decisions were made, as well as any alternative designs that were considered.

Implementation

Describe how UMA tokenholders should arrive at the price in the case of a DVM price request. Document each step a voter should take to query for and return a price at a specific timestamp, including rounding instructions. This should include an example calculation where you pick a specific timestamp and calculate the price at that timestamp.

Security Considerations

Some optional questions to consider: (Please remove before submission)

  • How could pricing data manipulation occur?
  • How could this price ID be exploited?
  • Do the instructions for determining the price provide people with enough certainty?
  • What are current or future concern possibilities with the way the price identifier is defined?
  • Are there any concerns around if the price identifier implementation is deterministic?