├── .gitignore ├── Implementations ├── 2pi-kpi.md ├── OneTree-KPI.md ├── across-kpi.md ├── aggregation-methods.md ├── bankless-legal-guild.md ├── baskprice-1221.md ├── bdiflip-1221.md ├── boba-wagmi-tvl.md ├── boba-wagmi-v1.md ├── bprotocol-tvl.md ├── defillama-tvl.md ├── dfx-tvl.md ├── gro-tvl.md ├── jarvis-lp.md ├── metric-operations.md ├── oolongswap-volume.md ├── paraswap-volume.md ├── piedao-dough.md ├── pooltogether-tvl.md ├── pooltogether-tvl2.md ├── post-processing-functions.md ├── qi-dao-mai-debt.md ├── smart-alpha.md ├── stakedao-tvl.md ├── suINT-KPI-1stepoch.md ├── suTVL-KPI.md ├── subgraph-query.md ├── tetu-lp-tvl.md ├── thorswap-volume.md ├── uniswap-volume-kpi.md ├── volatility-dao-batch-one.md ├── volatility-dao-batch-two.md ├── xio-market-cap-rank.md └── yel-lp.md ├── LICENSE ├── README.md ├── UMIPs ├── images │ ├── across-architecture.png │ ├── tradingview-ux.png │ ├── umip-177_a.png │ ├── umip-177_b.png │ └── umip-177_c.png ├── umip-1.md ├── umip-10.md ├── umip-100.md ├── umip-101.md ├── umip-102.md ├── umip-103.md ├── umip-104.md ├── umip-105.md ├── umip-106.md ├── umip-107.md ├── umip-108.md ├── umip-109.md ├── umip-11.md ├── umip-110.md ├── umip-111.md ├── umip-112.md ├── umip-113.md ├── umip-114.md ├── umip-115.md ├── umip-116.md ├── umip-117.md ├── umip-118.md ├── umip-119.md ├── umip-12.md ├── umip-120.md ├── umip-121.md ├── umip-122.md ├── umip-123.md ├── umip-124.md ├── umip-125.md ├── umip-126.md ├── umip-127.md ├── umip-128.md ├── umip-129.md ├── umip-13.md ├── umip-130.md ├── umip-131.md ├── umip-132.md ├── umip-133.md ├── umip-134.md ├── umip-135.md ├── umip-136.md ├── umip-137.md ├── umip-138.md ├── umip-139.md ├── umip-14.md ├── umip-140.md ├── umip-141.md ├── umip-142.md ├── umip-143.md ├── umip-144.md ├── umip-145.md ├── umip-146.md ├── umip-147.md ├── umip-148.md ├── umip-149.md ├── umip-15.md ├── umip-150.md ├── umip-151.md ├── umip-152.md ├── umip-153.md ├── umip-154.md ├── umip-155.md ├── umip-156.md ├── umip-157.md ├── umip-158.md ├── umip-159.md ├── umip-16.md ├── umip-160.md ├── umip-161.md ├── umip-162.md ├── umip-163.md ├── umip-164.md ├── umip-165.md ├── umip-166.md ├── umip-167.md ├── umip-168.md ├── umip-169.md ├── umip-17.md ├── umip-170.md ├── umip-171.md ├── umip-172.md ├── umip-173.md ├── umip-174.md ├── umip-175.md ├── umip-176.md ├── umip-177.md ├── umip-178.md ├── umip-179.md ├── umip-18.md ├── umip-180.md ├── umip-181.md ├── umip-182.md ├── umip-183.md ├── umip-184.md ├── umip-185.md ├── umip-186.md ├── umip-187.md ├── umip-19.md ├── umip-2.md ├── umip-20.md ├── umip-21.md ├── umip-22.md ├── umip-23.md ├── umip-24.md ├── umip-25.md ├── umip-26.md ├── umip-27.md ├── umip-28.md ├── umip-29.md ├── umip-3.md ├── umip-30.md ├── umip-31.md ├── umip-32.md ├── umip-33.md ├── umip-34.md ├── umip-35.md ├── umip-36.md ├── umip-37.md ├── umip-38.md ├── umip-39.md ├── umip-4.md ├── umip-40.md ├── umip-41.md ├── umip-42.md ├── umip-43.md ├── umip-44.md ├── umip-45.md ├── umip-46.md ├── umip-47.md ├── umip-48.md ├── umip-49.md ├── umip-5.md ├── umip-50.md ├── umip-51.md ├── umip-52.md ├── umip-53.md ├── umip-54.md ├── umip-55.md ├── umip-56.md ├── umip-57.md ├── umip-58.md ├── umip-59.md ├── umip-6.md ├── umip-60.md ├── umip-61.md ├── umip-62.md ├── umip-63.md ├── umip-64.md ├── umip-65.md ├── umip-66.md ├── umip-67.md ├── umip-68.md ├── umip-69.md ├── umip-7.md ├── umip-70.md ├── umip-71.md ├── umip-72.md ├── umip-73.md ├── umip-74.md ├── umip-75.md ├── umip-76.md ├── umip-77.md ├── umip-78.md ├── umip-79.md ├── umip-8.md ├── umip-80.md ├── umip-81.md ├── umip-82.md ├── umip-83.md ├── umip-84.md ├── umip-85.md ├── umip-86.md ├── umip-87.md ├── umip-88.md ├── umip-89.md ├── umip-9.md ├── umip-90.md ├── umip-91.md ├── umip-92.md ├── umip-93.md ├── umip-94.md ├── umip-95.md ├── umip-96.md ├── umip-97.md ├── umip-98.md └── umip-99.md ├── UPPs ├── upp-1.md ├── upp-10.md ├── upp-11.md ├── upp-12.md ├── upp-13.md ├── upp-14.md ├── upp-15.md ├── upp-2.md ├── upp-3.md ├── upp-4.md ├── upp-5.md ├── upp-6.md ├── upp-7.md ├── upp-8.md └── upp-9.md ├── collateral-currency-template.md ├── price-identifier-template.md └── umip-template.md /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store -------------------------------------------------------------------------------- /Implementations/OneTree-KPI.md: -------------------------------------------------------------------------------- 1 | # Title 2 | Plant One Tree Per Tweet KPI 3 | 4 | # Summary 5 | This KPI Option is designed to pay off based on the number of retweets that a single, specific tweet gets on Twitter before an expiry date. 6 | 7 | # Ancillary Data Specifications 8 | Metric: Total number of Retweets the original One Tree Tweet can attain before expiry, Endpoint: "https://discord.com/channels/909933079181799524/953369451573690428", Method: "https://github.com/UMAprotocol/UMIPs/blob/master/Implementations/OneTree-KPI.md", Key: Total retweets, Rounding: 2 decimals, Interval: Daily resolving to data supplied directly following the request timestamp, Fallback: If fewer than three screenshots are provided within the first three hours following the request timestamp anyone can post a screenshot of the tweet, Aggregation: Median of the first three screenshots provided by pre-designated SuperUMAns posted after the request timestamp, Unresolved: 10000, Tweet: "https://twitter.com/UMAprotocol/status/1503828527099088904" 9 | 10 | # Rationale 11 | This design is not intended to avoid “gaming” in any sense. Rather, it is just to demonstrate the effectiveness of KPI options, as well as to create a game whereby people are excited to participate for good. This design should not be used for something highly sensitive or critical, as it relies on a social measure on a gameable social network. It is possible to “buy RTs” for quite cheap through different sources online, so an interested party could trick this measure pretty easily. 12 | 13 | # Implementation 14 | 1. Proposers/voters should check the tweet provided as Ancillary data at the expirationTimestamp for the number of RTs the tweet has. 15 | 2. There is some ambiguity about how to do this, because a tweet could receive more RTs after expiry. An increase in the value is not the problem, but rather, a lack of clarity for voters on what is the correct value. 16 | 3. For this reason, the authors would suggest that the source used as a reference for the calculation is the median of the first three screenshots provided by pre-designated SuperUMAns posted after the request timestamp in the [onetree-screencapture](https://discord.com/channels/909933079181799524/953369451573690428) channel of the SuperUMAn discord, but could be changed to use another data source in the future. The specific SuperUMAns taking the expiry screenshots will be @inalittlewhile#4712, @deadcoin#0901, @PVmilihache#8517, @Heruvim78#6876, and @PennyPanda#4443. 17 | 4. Round to 2 decimal places (third decimal place digit >= 5 rounds up and < 5 rounds down). 18 | 19 | # Intended Application 20 | This is intended to be used as a way to incentivize RTs. In its first iteration, this is for a charitable benefit. One could design it merely for marketing purposes, and even make the recipient be one of the RTers - Which while distributing the tokens to them would not be trustless, the value of the tokens themselves would be based on the number of RTs. 21 | 22 | This calculation is intended to be used with a KPI option that has FPL bounds of 0 and 10,000, and a collateralPerPair of 1. As an example, 5000 retweets would result in a KPI option value of 0.5 USDC. 3,000 retweets would result in a KPI Option value of 0.3 USDC by the same equation. 23 | -------------------------------------------------------------------------------- /Implementations/across-kpi.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | Across Community Growth KPI 4 | 5 | 6 | ## Summary 7 | Across Protocol is a new project that uses UMA's Optimistic Oracle for L2 to L1 token bridging. It would like to bootstrap its community by incentivizing UMA community contributors (superUMAns) to join and grow the Across community. This implementation doc details how the Across community size could be measured, which will be used to create a KPI option based upon community size. 8 | 9 | 10 | ## Ancillary Data Specifications 11 | Metric:Total number of members in the Across community on the day before expiry, 12 | Endpoint:"https://statbot.net/dashboard/887426921892315137/overview", 13 | Method:"https://github.com/UMAprotocol/UMIPs/blob/master/Implementations/across-kpi.md", 14 | Key:Total Members, 15 | Rounding:0, 16 | Interval:Daily with the day before the day that the expiry timestamp falls on being used 17 | 18 | ## Rationale 19 | 20 | The intended recipients of these kpi options are limited to those that have already demonstrated to be trustworthy participants when building this community. Because of this, we believe it is unlikely that this metric will be manipulated by bad actors. Additionally, there will be active measures by community moderators to maintain an environment that will contribute to the long-term success of the protocol. 21 | 22 | The intention of this KPI option as an incentivization tool is to get people into the community during the early stages of our launch. Ultimately, the use case for this KPI option is to experiment with community bootstrapping. 23 | 24 | The day before is used because Discord does not have an easy way to query for members at a specific timestamp. The day of would not be fitting, as the value could change depending on when proposers/voters refer to the stats dashboard. The value at the end of the day before (midnight UTC) will remain static and should be used. As an example, a request for this price identifier that falls on November 2nd would use the membership count on November 2nd at 00:00 UTC. 25 | 26 | ## Implementation 27 | 28 | 1. Using the discord server statbot dashboard, proposers/voters should refer to the `Total member count` table and use the `Total Member` value from the end of the preceeding day or the beginning of the day that the price request falls in. 29 | 2. The `Total Member` value should be returned as is with no rounding or transformation. 30 | 31 | 32 | ## Intended Use Case 33 | 34 | This calculation is intended to be used with a KPI option that has FPL bounds of 0 and 1000, and a collateralPerPair of 1. As an example, 500 members would result in a KPI option value of 0.5 UMA. -------------------------------------------------------------------------------- /Implementations/aggregation-methods.md: -------------------------------------------------------------------------------- 1 | These instructions are expected to be used with the `General_KPI` price identifier in conjunction with a dedicated `Method` document that requires aggregation of time series data. The instructions in the referenced `Method` document should have passed an array of measured KPI metrics along with Unix timestamps for these data points. 2 | 3 | Below sections provide instructions where each of section names corresponds to the supported values for the `AggregationMethod` parameter values passed in the ancillary data. 4 | 5 | ## `TWAP` 6 | 7 | Evaluated KPI metrics series should be sorted by their timestamps and each KPI metric element (except the last one) should be weighted by the time distance in seconds to the next evaluated KPI element in order to return time weighted average as the aggregated KPI metric. 8 | 9 | ## `MAX` 10 | 11 | The highest value KPI metric element from the evaluated time series should be returned as aggregated KPI metric. 12 | 13 | ## `MIN` 14 | 15 | The lowest value KPI metric element from the evaluated time series should be returned as aggregated KPI metric. 16 | -------------------------------------------------------------------------------- /Implementations/baskprice-1221.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | baskPRICE-1221 Calculation 4 | 5 | ## Summary 6 | 7 | BASK is BasketDAO governance token. This calculation is intended to track the BASK token price quoted in USD. The recommended method to query pricing data is to use CoinGecko API service, but this document will detail the calculation method so that it could be reproduced if CoinGecko was either not available or returning incorrect results. 8 | 9 | ## Intended Ancillary Data 10 | 11 | Metric:BASK price quoted in USD, 12 | Endpoint:"https://api.coingecko.com/api/v3/coins/ethereum/contract/0x44564d0bd94343f72e3c8a0d22308b7fa71db0bb/market_chart/range?vs_currency=usd&from=1638288000&to=1640966400", 13 | Method:"https://github.com/UMAprotocol/UMIPs/blob/master/Implementations/baskprice-1221.md", 14 | Key:prices[i][1] where prices[i][0] are the timestamps within the requested period in milliseconds, 15 | Interval:hourly, 16 | Aggregation:Peak value of minimum rolling 24-hour BASK price starting from 1638288000 timestamp, 17 | Rounding:2 18 | 19 | ## Implementation 20 | 21 | 1. Fetch BASK token (contract address `0x44564d0bd94343f72e3c8a0d22308b7fa71db0bb` on Ethereum mainnet) USD price time series from the provided CoinGecko API endpoint for the 1 month period ending at request timestamp. 22 | 2. For each available BASK price data-point (Step 1) take the minimum value of any price that falls within last 24 hours before the respective timestamp. 23 | 3. Find the peak value of minimum rolling 24 hour BASK prices from Step 2 during the 1 month period before the request timestamp. 24 | 4. Round the peak value from Step 3 to 2 decimals before returning it as resolved price request. 25 | 26 | Even though this implementation is based on CoinGecko pricing data, voters should verify that results agree with broad market consensus. In case CoinGecko data is not available or is considered corrupt, voters should independently calculate historical BASK prices following BASKUSD price identifier implementation from [UMIP-110](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-110.md). 27 | -------------------------------------------------------------------------------- /Implementations/bdiflip-1221.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | bdiFLIP-1221 Calculation 4 | 5 | ## Summary 6 | 7 | BasketDAO DeFi Index (BDI) token provides diversified exposure to DeFi blue chips, and it is aimed at the long term passive investor as a safe set-and-forget investment. This calculation is intended to track the market capitalization of BDI relative to DeFiPulse Index (DPI) that is a market capitalization-weighted index which consists of the 10 most popular Ethereum-based DeFi tokens. 8 | 9 | The recommended method to query market capitalization data is to use CoinGecko API service, but this document will detail the relative market capitalization calculation so that it could be reproduced if CoinGecko was either not available or returning incorrect results. 10 | 11 | ## Intended Ancillary Data 12 | 13 | Metric:Market capitalization of BDI minus DPI market capitalization, 14 | Endpoint:"https://api.coingecko.com/api/v3/coins/ethereum/contract/0x0309c98b1bffa350bcb3f9fb9780970ca32a5060/market_chart/range?vs_currency=usd&from=1638288000&to=1640966400 for BDI and https://api.coingecko.com/api/v3/coins/ethereum/contract/0x1494ca1f11d487c2bbe4543e90080aeba4ba3c2b/market_chart/range?vs_currency=usd&from=1638288000&to=1640966400 for DPI", 15 | Method:"https://github.com/UMAprotocol/UMIPs/blob/master/Implementations/bdiflip-1221.md", 16 | Key:market_caps[i][1] where market_caps[i][0] are the timestamps within the requested period in milliseconds, 17 | Interval:hourly, 18 | Aggregation:Peak value of minimum rolling 24-hour difference (BDI-DPI) starting from 1638288000 timestamp, 19 | Rounding:0 20 | 21 | ## Implementation 22 | 23 | 1. Fetch BDI token (contract address `0x0309c98b1bffa350bcb3f9fb9780970ca32a5060` on Ethereum mainnet) market capitalization time series from the provided CoinGecko API endpoint for the 1 month period ending at request timestamp. 24 | 2. Fetch DPI token (contract address `0x1494ca1f11d487c2bbe4543e90080aeba4ba3c2b` on Ethereum mainnet) market capitalization time series from the provided CoinGecko API endpoint for the 1 month period ending at request timestamp. 25 | 3. For each returned response timestamp from BDI request find the latest available DPI timestamp data-point and calculate the difference by subtracting DPI market capitalization (Step 2) from BDI market capitalization (Step 1). 26 | 4. For each available BDI data-point take the minimum value of any BDI-DPI market capitalization difference (Step 3) that falls within last 24 hours before the respective timestamp. 27 | 5. Find the peak value of minimum 24 hour BDI-DPI market capitalization differences from Step 4 during the 1 month period before the request timestamp. 28 | 6. In case the peak value from Step 5 is positive (i.e. BDI has sustained dominance of its market capitalization relative to DPI during any continuous 24 hour period of last month) voters should resolve the value of 1 to the price request. If this condition is not achieved voters should resolve the price request to 0. 29 | 30 | Even though this implementation is based on CoinGecko pricing data, voters should verify that results agree with broad market consensus. In case CoinGecko data is not available or is considered corrupt, voters should independently calculate BDI and DPI market capitalization for each hourly period during the last month from the price request. Market capitalization should be calculated by multiplying token price with respective historical tokens outstanding. Note that access to archive node would be required to make `totalSupply()` requests on historical state. Token pricing should be calculated as median from 3 (if available) most liquid markets for BDI and DPI. 31 | -------------------------------------------------------------------------------- /Implementations/gro-tvl.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | Gro Protocol TVL Calculation 4 | 5 | ## Summary 6 | 7 | Gro protocol is a stablecoin yield aggregator that tranches risk and yield. The first two products built on it are the PWRD stablecoin with deposit protection and yield, and Vault with leveraged stablecoin yields. The goal of the KPI options program is to motivate users growing TVL locked in the protocol. 8 | 9 | This document will detail the calculation method for average Gro Protocol TVL over the requested time period. 10 | 11 | ## Intended Ancillary Data 12 | 13 | ``` 14 | Metric:Gro Protocol TVL measured in USD, 15 | Method:"https://github.com/UMAprotocol/UMIPs/blob/master/Implementations/gro-tvl.md", 16 | Interval:daily, 17 | Aggregation:Average end of day (midnight UTC) TVL over previous 7 days before the request timestamp, 18 | Rounding:0 19 | ``` 20 | 21 | ## Implementation 22 | 23 | Total Gro Protocol TVL is determined by calculating the USD value of assets locked in Gro products fetching on-chain information from following contracts deployed on Ethereum (please confirm the canonical list of contract addresses at [Gro Docs](https://docs.gro.xyz/gro-docs/developer-apis/contracts)): 24 | 25 | * PWRD Stablecoin: 0xF0a93d4994B3d98Fb5e3A2F90dBc2d69073Cb86b 26 | * Gro Vault (GVT): 0x3ADb04E127b9C0a5D36094125669d4603AC52a0c 27 | 28 | In case Gro protocol is expanded with new contracts and this document is not up to date the voters should refer to the canonical list of addresses at [Gro Docs](https://docs.gro.xyz/gro-docs/developer-apis/contracts). 29 | 30 | 1. Identify all midnight UTC timestamps and their corresponding latest available block numbers during the period provided in the `Aggregation` parameter from the ancillary data. 31 | 2. Call the `totalAssets` method on each of Gro product token contracts listed above at each block number identified in the Step 1. The results should be scaled down by 18 decimals and it represents USD value locked in each of Gro products. 32 | 3. For each identified block number sum USD values locked in all Gro products obtained from the Step 2. 33 | 4. Calculate arithmetic mean of USD TVL values from Step 3 to get the average TVL over the requested time period. 34 | 5. Round the average USD TVL from Step 4 to 0 decimals before returning it as resolved price request. 35 | 36 | ## Intended Application 37 | 38 | It is intended to deploy the documented KPI options on Ethereum mainnet using [LSP contract](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/financial-templates/long-short-pair/LongShortPair.sol) with `General_KPI` price identifier approved in [UMIP-117](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-117.md). The contract would use [Linear LSP FPL](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/financial-templates/common/financial-product-libraries/long-short-pair-libraries/LinearLongShortPairFinancialProductLibrary.sol). 39 | -------------------------------------------------------------------------------- /Implementations/oolongswap-volume.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | Oolongswap Monthly Volume KPI Option Calculation 4 | 5 | ## Summary 6 | 7 | Oolong is an AMM built on the Boba L2 Network. Oolong was an early adopter of WAGMI KPI options mining. The Boba network wishes to continue Oolong performance incentivization by offering Oolong a binary option that targets an increase in monthly trading volume. 8 | 9 | ## Intended Ancillary Data 10 | 11 | ``` 12 | Metric:Oolong monthly volume, 13 | Method:"https://github.com/UMAprotocol/UMIPs/blob/master/Implementations/oolongswap-volume.md", 14 | Aggregation:Increase in cumulative volume for the provided time range, 15 | StartTimestamp:1648771200, 16 | EndTimestamp:1651363200, 17 | ThresholdVolume:25000000, 18 | Rounding:0 19 | ``` 20 | 21 | ## Implementation 22 | 23 | Oolongswap wishes to track the total increase in cumulative lifetime volume over a period of time. Since this calculation is somewhat complicated, it is recommended to use Oolong's subgraph to calculate this. 24 | 25 | This [cumulative volume query](https://api.thegraph.com/subgraphs/name/oolongswap/oolongswap-mainnet/graphql?operationName=users&query=query%20users%20%7B%0A%20%20uniswapFactories(first%3A%201000%2C%20block%3A%20%7Bnumber%3A%20413042%7D)%20%7B%0A%20%20%20%20id%0A%20%20%20%20totalVolumeUSD%0A%20%20%7D%0A%7D%0A) will be used. 26 | 27 | The query that should be used is: 28 | 29 | ``` 30 | query users { 31 | uniswapFactories(first: 1000, block: {number: 413042}) { 32 | id 33 | totalVolumeUSD 34 | } 35 | } 36 | ``` 37 | 38 | 1. Find the block numbers that correspond to the blocks either at or before and closest to the `StartTimestamp` and `EndTimestamp` unix timestamps that are specified in ancillary data. 39 | 2. For both block numbers, replace the `block.number` value and run the cumulative volume query listed above. Record each returned `totalVolumeUSD` value. 40 | 3. Find the difference between the `totalVolumeUSD` value at the block number used for `EndTimestamp` and the value at the block number used for `StartTimestamp`. Round the difference to 0 decimal places (e.g. 25.123 -> 25). 41 | 42 | ## Post processing 43 | 44 | Since this options should provide minimum guaranteed payout of 1 BOBA per KPI option token and currently the audited financial product libraries do not allow setting minimum payout floor above zero, voters should perform post-processing on the calculated volume and return either 1 or 2: 45 | 46 | 1. If the volume returned is equal to or above the ThresholdVolume value, return 2. 47 | 2. If the volume returned is less than the ThresholdVolume value, return 1. 48 | 49 | ***Note:** All values in this implementation doc should be treated as "unscaled". When returned on-chain, they should be scaled to 18 decimals like all other UMA price identifiers.* 50 | 51 | ## Intended Application 52 | 53 | It is intended to deploy the documented KPI options on the Boba network using [LSP contract](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/financial-templates/long-short-pair/LongShortPair.sol) with `General_KPI` price identifier approved in [UMIP-117](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-117.md). The contract would use [Linear LSP FPL](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/financial-templates/common/financial-product-libraries/long-short-pair-libraries/LinearLongShortPairFinancialProductLibrary.sol) with the `lowerBound` set to 0 and `upperBound` set to 2. 54 | 55 | `collateralPerPair` parameter for the LSP contract would be set to 2 so that the maximum payout per KPI option would reach 2 BOBA if the Oolongswap cumulative volume increase exceeds `ThresholdVolume`. 56 | -------------------------------------------------------------------------------- /Implementations/piedao-dough.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | Staked DOUGH Calculation 4 | 5 | ## Summary 6 | 7 | PieDAO aims at launching KPI options to promote the new staking program to be released as of beginning October 2021. The KPI options will track the amount of DOUGH v2 staked at price request timestamp (contract expiration) through a query to the subgraph provided, and convert it to a corresponding share from maximum KPI options payout. 8 | 9 | ## Intended Ancillary Data 10 | 11 | ``` 12 | Metric:Total DOUGH v2 staked, 13 | Endpoint:"https://api.thegraph.com/subgraphs/name/pie-dao/vedough", 14 | Method:"https://github.com/UMAprotocol/UMIPs/blob/master/Implementations/piedao-dough.md", 15 | Key:data.globalStats[0].totalDoughStaked, 16 | Interval:request the last updated event at or before request timestamp, 17 | Rounding:1 18 | ``` 19 | 20 | ## Implementation 21 | 22 | 1. Construct subgraph query by making sure that `timestamp_lte` parameter corresponds to the price request timestamp, e.g.: 23 | ``` 24 | { 25 | globalStats(first: 1, orderBy: timestamp, orderDirection: desc, where: {timestamp_lte: 1648677600}) { 26 | totalDoughStaked 27 | veTokenTotalSupply 28 | timestamp 29 | } 30 | } 31 | ``` 32 | 2. Perform `POST` request on the `Endpoint` (passed as a parameter from ancillary data) with request body from Step 1. As an illustration, `curl` request would look like: 33 | ``` 34 | curl -X POST \ 35 | -d '{"query": "{globalStats(first: 1, orderBy: timestamp, orderDirection: desc, where: {timestamp_lte: 1648677600}) {totalDoughStaked, veTokenTotalSupply, timestamp}}"}' \ 36 | 'https://api.thegraph.com/subgraphs/name/pie-dao/vedough' 37 | ``` 38 | 3. Take a note on the raw staked DOUGH v2 from the returned subgraph response value corresponding to `Key` parameter from ancillary data. 39 | 40 | ## Fallback implementation 41 | 42 | In case of technical issues with subgraph raw metric should be resolved by querying on-chain value of DOUGH v2 token held by the staking contract: 43 | 1. Identify the latest block at or before the price request timestamp. 44 | 2. Call the `balanceOfAt` method on DOUGH v2 token contract `0xad32A8e6220741182940c5aBF610bDE99E737b2D` by passing the address of the staking contract `0x6Bd0D8c8aD8D3F1f97810d5Cc57E9296db73DC45` as the first parameter and identified block number from Step 1 as the second parameter. 45 | 3. Take a note on the raw staked DOUGH v2 from the returned on-chain request. 46 | 47 | ## Post processing 48 | 49 | Depending on the value of queried raw staked DOUGH v2 (this is before scaling down token decimals) proposers/voters should transform it to discrete share from maximum KPI options payout according to the table below: 50 | 51 | | Raw DOUGH v2 staked range | Human readable token amounts | Resolved price | 52 | |---------------------------------------------------------|---------------------------------------|----------------| 53 | | 0 - 7499999999999999999999999 | less than 7.5M | 0 | 54 | | 7500000000000000000000000 - 9999999999999999999999999 | less than 10M and equal or above 7.5M | 0.2 | 55 | | 10000000000000000000000000 - 14999999999999999999999999 | less than 15M and equal or above 10M | 0.4 | 56 | | 15000000000000000000000000 - | equal or above 15M | 1 | 57 | 58 | ## Intended Application 59 | 60 | It is intended to deploy the documented KPI options using [LSP contract](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/financial-templates/long-short-pair/LongShortPair.sol) with `General_KPI` price identifier approved in [UMIP-117](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-117.md). The contract would use [Linear LSP FPL](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/financial-templates/common/financial-product-libraries/long-short-pair-libraries/LinearLongShortPairFinancialProductLibrary.sol) with the `lowerBound` set to 0 and `upperBound` set to 1. 61 | 62 | `collateralPerPair` parameter for the LSP contract would be set to 0.5 so that with the intended 10M option token distribution maximum absolute payout to the recipients would be 5M DOUGH v2 (when reaching 15M staked DOUGH v2). 63 | -------------------------------------------------------------------------------- /Implementations/post-processing-functions.md: -------------------------------------------------------------------------------- 1 | These instructions are expected to be used with the `General_KPI` price identifier in conjunction with a dedicated `Method` document that requires off-chain post-processing of the resolved KPI metric. 2 | 3 | Below sections provide post-processing instructions where each of section names corresponds to the supported values for the `PostProcessingMethod` parameter values passed in the ancillary data. `PostProcessingParameters` passed in the ancillary data should be a JSON object with key-value pairs representing named function parameters as detailed below. 4 | 5 | ## `STEPWISE` 6 | 7 | ### Function parameters 8 | 9 | - `milestones`: dynamic array containing 2 element arrays where the first element represents KPI metric milestone and the second element represents its price value. 10 | 11 | ### Implementation 12 | 13 | 1. KPI metric milestone values should be unique numerical values across all `milestones` array elements. Though if they were repeated due to user misconfiguration only the last `milestones` element with the same KPI metric should be used ignoring all preceding elements with duplicate KPI metric. 14 | 2. Sort `milestones` elements in descending order by their KPI metric milestone values. 15 | 3. Iterate over the sorted `milestones` elements and compare their KPI milestone value with the resolved KPI metric. If the resolved KPI metric is larger or equal to the evaluated KPI milestone then stop processing and return the corresponding price value. In case resolved KPI metric is below all KPI milestones resolve the price as set in `Unresolved` parameter form ancillary data or`0` if `Unresolved` was not provided. 16 | 17 | ### Example 18 | 19 | ``` 20 | PostProcessingParameters:{"milestones":[[0,1],[10000,2],[20000,5]]},Unresolved:0.1 21 | ``` 22 | 23 | As an illustration the above configuration from ancillary data would resolve price as follows: 24 | 25 | - If KPI metric is negative `0.1` price should be resolved (based on `Unresolved` parameter); 26 | - If KPI metric is at least `0` but lower than `10000` resolve price to `1`; 27 | - If KPI metric is at least `10000` but lower than `20000` resolve price to `2`; 28 | - If KPI metric is `20000` or higher resolve price to `5`. 29 | -------------------------------------------------------------------------------- /Implementations/thorswap-volume.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | Thorswap Volume KPI Option Calculation 4 | 5 | ## Summary 6 | 7 | Thorswap is a multi-chain DEX aggregator built on THORChain's cross-chain liquidity protocol. The Thorswap network wishes to incentivize increased volume to the network by offering the Thorswap community a binary option that targets an increase in trading volume. 8 | 9 | ## Intended Ancillary Data 10 | 11 | ``` 12 | Metric:Thorswap monthly trade volume measured in USD, 13 | Method:"https://github.com/UMAprotocol/UMIPs/blob/master/Implementations/thorswap-volume.md", 14 | Endpoint:"https://node-api.flipsidecrypto.com/api/v2/queries/8ace953e-a38e-405e-b78a-4640c22c651b/data/latest", 15 | MONTH: "" 16 | Key:data[i].TS_SWAP_VOLUME where data[i].MONTH is equal to the MONTH parameter, 17 | Rounding:0 18 | ``` 19 | ***Note 1:** `MONTH` will be updated in actual deployment using the following format: YYYY-MM-DD 00:00:00.000. The first day of the month corresponds to the total monthly value. An example for June 2022 is 2022-06-01 00:00:00.000* 20 | 21 | ***Note 2:** To avoid early results, Proposers and Voters should wait until the `MONTH` value of the following month used in the ancillary data is able to be queried before reporting results. For example, June 2022 values should not be proposed until 2022-07-01 00:00:00.000 is available* 22 | 23 | ## Implementation 24 | 25 | Thorswap wishes to track the total volume traded on the platform for a specific month. Since this calculation is somewhat complicated, it is recommended to use flipsidecrypto's platform to calculate this. 26 | 27 | * [volume per month query](https://node-api.flipsidecrypto.com/api/v2/queries/8ace953e-a38e-405e-b78a-4640c22c651b/data/latest) 28 | 29 | Support for the query can be found [here](https://app.flipsidecrypto.com/velocity/queries/8ace953e-a38e-405e-b78a-4640c22c651b). Please note, the below may be updated to reflect changes and Proposers/Voters should compare the query at the time of expiration to confirm the most updated query: 30 | 31 | ``` 32 | with base as (select a.block_timestamp, 33 | a.tx_id, 34 | max(to_amount_usd) as swap_volume 35 | from flipside_prod_db.thorchain.swaps a 36 | join flipside_prod_db.thorchain.swap_events b 37 | on a.tx_id = b.tx_id 38 | where right(split_part(memo, ':', 4),3) = '111' 39 | group by 1,2) 40 | 41 | select date_trunc('month', block_timestamp) as month, 42 | sum(swap_volume) as ts_swap_volume, 43 | sum(ts_swap_volume) over (order by month) as cumulative_ts_swap_volume 44 | from base 45 | group by 1 46 | ``` 47 | 48 | 1. Use the `volume per month` query above to retrieve the Thorswap monthly trade values. It should contain a list of { MONTH, TS_SWAP_VOLUME, CUMULATIVE_TS_SWAP_VOLUME } values. 49 | 2. For the values returned from step 1, locate the `MONTH` key value that corresponds with the parameter specified in the ancillary data. Choose the `TS_SWAP_VOLUME` value returned in the same array. Round the returned value to 0 decimal places (e.g. 72166475.9878698 -> 72166475). 50 | 51 | ## Intended Application 52 | 53 | It is intended to deploy the documented KPI options on Ethereum network using [LSP contract](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/financial-templates/long-short-pair/LongShortPair.sol) with `General_KPI` price identifier approved in [UMIP-117](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-117.md). The contract would use [Binary LSP FPL](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/financial-templates/common/financial-product-libraries/long-short-pair-libraries/BinaryOptionLongShortPairFinancialProductLibrary.sol) with the `strikePrice` set to 60 million. 54 | 55 | The expected payout should be 1 THOR per one option if the USD 60 million TVL threshold is reached and 0 THOR in case if it is below this target. `collateralPerPair` parameter for the LSP contract would be set to 1 so that the maximum payout per KPI option would be: 56 | 57 | * If the rounded Thorswap Volume is equal to or above USD 60 million, the request should be resolved as 1. 100% of the collateral amount would go to the long token and 0% to the short token. 58 | * If the rounded Thorswap Volume is below USD 60 million, the request should be resolved as 0. 0% of the collateral amount would go to the long token and 100% to the short token. -------------------------------------------------------------------------------- /Implementations/volatility-dao-batch-one.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | Volatilty DAO Batch One KPI 4 | 5 | ## Summary 6 | 7 | The Volatility DAO wishes to use KPI options to incentivize the community to complete future DAO projects. This implementation doc is intended to be used with the General_KPI price identifier, and its return value will be determined by UMA proposer/voterss assessment of the Volatility DAO's completion of its objectives. These objectives and corresponding payouts are detailed in the *Implementation* section. 8 | 9 | ## Intended Ancillary Data 10 | 11 | ``` 12 | Metric:Completion of various Volatility DAO governance projects, 13 | Method:"https://github.com/UMAprotocol/UMIPs/blob/master/Implementations/volatility-dao-batch-one.md", 14 | Rounding:0 15 | ``` 16 | 17 | ## Implementation 18 | 19 | Potential prices to return will be discrete values between 0 and 100 and should be informed by the completion of the goals listed in this document. Each goal has a percentage value associated with it, with completion of all goals corresponding to a 100 percent return value (or purely 100 for UMA voters). At the time of voting, voters should add up all values for each goal that has been met by the Volatility DAO. 20 | 21 | Goal 1: A total value of 40 will be assigned based on the broader goal of if the DAO organizes and implements KPI Option Batch Two & the rollover mechanism. You can read more about rollover KPI Options at this link (https://forum.volatility.com/t/modifying-kpi-options-with-rollovers/67). The 40 "points" will be broken up into these smaller objectives. 22 | - 20 for the Batch Two KPIs and lifespan are defined, submitted as a proposal, and passed them in community governance. 23 | - 10 for proposing to allocate DAO VOL tokens to fund the Batch Two Options, submitting as a proposal, and passing in community governance. Minting the KPI Options Batch Two with UMA must also occur for this objective to be complete. 24 | - 10 implementation of rollover mechanism between Batch 1 and Batch 2. 25 | 26 | Goal 2: A value of 30 will be added to the total if the POAPathon is created and launched. POAPathon is a POAP design competition that rewards designers that create the best POAP(s) across many DEFI projects. You can learn more about POAPathon in the [Discord](https://discord.gg/Xp58p6Csdx). 27 | 28 | Goal 3: A value of 30 will be added to the total depending on some completion objectives regarding sponsored prizes within the POAPathon. A sponsored prize is a bounty or reward submitted by a team, DAO, or individual as part of the POAPathon. In order for a sponsored prize to qualify it needs to be valued at >= 100 DAI on the date/time the POAPathon officially starts. If a prize is not offered in DAI, Nomics.com or Coingecko can be used to determine the spot price of the exchange rate. Number of sponsored prizes and amounts can be verified at the site where the POAPathon is hosted (e.g. Gitcoin). Since that site is not yet live you can join the [Discord](https://discord.gg/Xp58p6Csdx) where you will be notified when that site is live. Voters should add the following values depending on the number of sponsored prizes there are. 29 | - 10 - 1-20 prizes 30 | - 20 - 21-45 prizes 31 | - 30 - 46+ prizes -------------------------------------------------------------------------------- /Implementations/volatility-dao-batch-two.md: -------------------------------------------------------------------------------- 1 | ## Title 2 | 3 | Volatility DAO Batch Two KPI 4 | 5 | ## Summary 6 | 7 | The Volatility DAO wishes to use KPI options to incentivize the community to complete future DAO projects. This implementation doc is intended to be used with the General_KPI price identifier, and its return value will be determined by UMA proposer/voters assessment of the Volatility DAO's completion of its objectives. These objectives and corresponding payouts are detailed in the *Implementation* section. 8 | 9 | ## Intended Ancillary Data 10 | 11 | ``` 12 | Metric:Completion of various Volatility DAO governance projects, 13 | Method:"https://github.com/UMAprotocol/UMIPs/blob/master/Implementations/volatility-dao-batch-two.md", 14 | Rounding:0 15 | ``` 16 | 17 | ## Implementation 18 | 19 | Potential prices to return will be discrete values between 0 and 100 and should be informed by the completion of the goals listed in this document. Each goal has a percentage value associated with it, with completion of all goals corresponding to a 100 percent return value (or purely 100 for UMA voters). At the time of voting, voters should add up all values for each goal that have been met by the Volatility DAO as on the price request timestamp. 20 | 21 | 1. A value of 10 should be added to the total if a PIP to create and elect a Methodology Committee (a group that vets and creates PIPs for indices) has been passed. 22 | 2. A value of 5 should be added to the total if a PIP to implement a tip bot and the parameters for earning tips or additional VOLuntier2 tokens has been passed. 23 | 3. A value of 10 should be added to the total if Volatility DAO Twitter followers (https://twitter.com/VolatilityDao) were higher than 1000. This amount should be exceeded also on the price request timestamp. 24 | 4. A value of 10 should be added to the total if Volatility DAO Active Discord users (https://discord.gg/v75wdVeT) were higher than 500. This amount should be exceeded also on the price request timestamp. 25 | 5. A value of 5 should be added to the total if a PIP to elect DAO members to help run the DAO Github as well as create and manage a GitBook has been passed. 26 | 6. Maximum value of 30 should be added to the total depending on the number of products built on top of DAOracle indices. Each product built contributes 10 points. 27 | 7. A value of 15 should be added to the total if a new partnership within the Defi space has been identified and created by Volatility DAO. 28 | 8. Maximum value of 15 should be added to the total depending on the number of PIPs passed. This also may include PIPs passed as counted for reaching other goals stated above. 29 | - 5 points for 1-5 PIPs 30 | - 10 points for 6-10 PIPs 31 | - 15 points for 11-15 PIPs 32 | 33 | Additional information for UMA DVM participants: 34 | - Approved PIPs can be observed in the Volatility DAO [Github Repo](https://github.com/Volatility-DAO/PIPS/tree/main/Approved) in the “Approved” directory. 35 | - Within the Volatility DAO Discord is a channel called [#vol-kpi-metrics](https://discord.com/channels/807306992389062668/931235120269119488). This channel will be used to post and keep track of the above metric. Users will be able to verify products built on top of the DAOracle here and new partnerships that are created within the DeFi space. 36 | 37 | ## Intended Application 38 | 39 | It is intended to deploy the documented KPI options on Ethereum network using [LSP contract](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/financial-templates/long-short-pair/LongShortPair.sol) with `General_KPI` price identifier approved in [UMIP-117](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-117.md). The contract would use [Linear LSP FPL](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/financial-templates/common/financial-product-libraries/long-short-pair-libraries/LinearLongShortPairFinancialProductLibrary.sol) with the `lowerBound` set to 0 and `upperBound` set to 100. 40 | 41 | `collateralPerPair` parameter for the LSP contract would be set to 100 so that the maximum payout per KPI option would reach 100 VOL if all the goals listed above are reached by the request timestamp. 42 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # UMIPs 2 | 3 | This is a repository for UMA Improvement Proposals (UMIPs). 4 | UMIPs are used to propose and approve new financial contract templates, new price identifiers, and make other changes to governance of the UMA DVM (data verification mechanism). 5 | 6 | To contribute to this repo, first review [UMIP-1](UMIPs/umip-1.md). Then, clone the repository and add your UMIP to it. There is a template UMIP [here](umip-template.md). Then, submit a Pull Request to UMA's UMIPs repository. 7 | -------------------------------------------------------------------------------- /UMIPs/images/across-architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/UMAprotocol/UMIPs/05c8e788be8b7187b9fddf64c37f7c5b69739b42/UMIPs/images/across-architecture.png -------------------------------------------------------------------------------- /UMIPs/images/tradingview-ux.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/UMAprotocol/UMIPs/05c8e788be8b7187b9fddf64c37f7c5b69739b42/UMIPs/images/tradingview-ux.png -------------------------------------------------------------------------------- /UMIPs/images/umip-177_a.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/UMAprotocol/UMIPs/05c8e788be8b7187b9fddf64c37f7c5b69739b42/UMIPs/images/umip-177_a.png -------------------------------------------------------------------------------- /UMIPs/images/umip-177_b.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/UMAprotocol/UMIPs/05c8e788be8b7187b9fddf64c37f7c5b69739b42/UMIPs/images/umip-177_b.png -------------------------------------------------------------------------------- /UMIPs/images/umip-177_c.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/UMAprotocol/UMIPs/05c8e788be8b7187b9fddf64c37f7c5b69739b42/UMIPs/images/umip-177_c.png -------------------------------------------------------------------------------- /UMIPs/umip-1.md: -------------------------------------------------------------------------------- 1 | # UMIPs 2 | 3 | UMIPs (“UMA Improvement Proposals”) are the design documents used to propose changes to the UMA ecosystem. 4 | They provide information to the UMA community that describes a new feature for the UMA protocol, or its ecosystem. 5 | The UMIP should provide a concise technical specification of the feature and a rationale for the feature. 6 | They are modeled after [EIPs](https://eips.ethereum.org/) and [ZEIPs](https://blog.0xproject.com/0x-protocol-governance-voting-walkthrough-and-faq-3becfd57a370). 7 | See here for an [EIP template](https://github.com/ethereum/EIPs/blob/master/eip-template.md) and [ZEIP template](https://github.com/0xProject/ZEIPs/blob/master/ISSUE_TEMPLATE.md). 8 | 9 | We intend UMIPs to be the primary mechanism for proposing new features, collecting community technical input on an issue, and for documenting the design decisions that have gone into the UMA protocol. 10 | UMIPs are a convenient way to track the progress of an implementation. 11 | 12 | # What is the lifecycle of a UMIP? 13 | 14 | A successful UMIP will move along the following stages: Draft ⟶ Last Call ⟶ Final ⟶ Approved. 15 | Unsuccessful states are also possible: Abandoned and Rejected. 16 | 17 | ## Draft 18 | A UMIP that is open for consideration and is undergoing rapid iteration and changes. 19 | In order to proceed to “Last Call,” the implementation must be complete. 20 | Every UMIP author is responsible for facilitating conversations and building community consensus for the proposal. 21 | 22 | ## Last Call 23 | A UMIP that is done with its initial iteration and ready for review by a wide audience. 24 | If upon review, there is a material change or substantial unaddressed complaints, the UMIP will revert to "Draft". 25 | If the UMIP requires code changes, the core devs must review the UMIP. 26 | A successful UMIP will be in "Last Call" status for a reasonable period of time for comments and be merged (if necessary) before moving to a tokenholder vote. 27 | 28 | ## Final 29 | An UMIP that successfully passes the "Last Call" will move to the "Final" state and be put to UMA tokenholder vote. 30 | 31 | ## Approved 32 | If tokenholders approve the proposal, the live protocol will be updated to reflect it. 33 | At this time, any code changes (if relevant) should be merged into the core protocol repository so that the core protocol repository always reflects the live code that is running. 34 | The UMIP is then considered to be in the "Approved" state. 35 | 36 | ## Abandoned 37 | If at any point during the UMIP Finalization Process, a UMIP is abandoned, it will be labeled as such. 38 | Grounds for abandonment include a lack of interest by the original author(s), or it may not be a preferred option anymore. 39 | 40 | ## Rejected 41 | If tokenholders do not approve a proposal, or the UMIP is fundamentally broken or rejected by the core team, it will not be implemented. 42 | -------------------------------------------------------------------------------- /UMIPs/umip-10.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-10 | | 3 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 4 | | UMIP Title | Add WETH as a collateral currency | 5 | | Authors | Matt Rice (matt@umaproject.org), Clayton Roche (clayton@umaproject.org) | 6 | | Status | Approved | 7 | | Created | July 16, 2020 | 8 | 9 | ## Summary (2-5 sentences) 10 | This UMIP will add WETH as an approved collateral currency. This will involve adding it to the whitelist and adding a flat final fee to charge per-request. The proposed final fee is 0.1 WETH per request. 11 | 12 | ## Motivation 13 | ETH is the most liquid currency on Ethereum. Many users on Ethereum like to borrow against their ETH to get leverage on their ETH. At the time of writing, over 1.9mm ETH are locked in MakerDAO in this fashion. To allow synthetic tokens created with the EMP to take advantage of this liquidity and desire for leverage, WETH (ETH wrapped in an ERC20) seems like an important and safe addition to Dai as the second approved collateral currency. 14 | 15 | WETH as collateral is expected to have a variety of deployments. The timing for adding it now, and the immediate application, is for use with USDETH, which will enable the creation of yUSD, a yielding dollar token. This price identifier is described in UMIP 6. 16 | 17 | ## Technical Specification 18 | To accomplish this upgrade, two changes need to be made: 19 | - The WETH address, [0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2), needs to be added to the collateral currency whitelist introduced in UMIP-8. 20 | - A final fee of 0.1 needs to be added for the WETH in the Store contract. 21 | 22 | ## Rationale 23 | 24 | The rationale behind this change is giving deployers more useful collateral currency options. WETH needs to be used instead of ETH due to it being an ERC20, whereas native ETH is not. 25 | 26 | 0.1 was chosen because 0.1 WETH is about twice as large as the current DAI final fee (10 DAI). This accounts for the fact that WETH is a much more volatile asset. Voters cannot change the final fees immediately when the price changes on collateral assets, so this additional cushioning helps protect the system from DoS attacks in times of volatility. 27 | 28 | ## Implementation 29 | 30 | This change has no implementation other than the two aforementioned governor transactions that will be proposed. 31 | 32 | ## Security considerations 33 | Since WETH is a persistently valuable ERC20 token, including it as a collateral currency should impose no additional risk to the protocol. 34 | 35 | The only security implication is for contract deployers and users who are considering using EMP contracts with WETH as the collateral currency. They should recognize that, relative to most fiat currencies, WETH is much more volatile than Dai. This volatility should be taken into account when parameterizing or using these EMP contracts. 36 | 37 | For added assurance, WETH is not listed on the [buggy ERC20 contracts list](https://github.com/sec-bit/awesome-buggy-erc20-tokens/blob/master/bad_tokens.all.csv). 38 | -------------------------------------------------------------------------------- /UMIPs/umip-105.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-105 | | 3 | | ------------------- | ------------------------------------------------------------- | 4 | | UMIP Title | Add BASK as a supported collateral type | 5 | | Authors | Shawn C. Hagenah (Hagz48)shawnhagenah99@yahoo.com | 6 | | Status | Approved | 7 | | Created | 6/2/2021 | 8 | | Discourse Link | https://discourse.umaproject.org/t/add-dfx-as-approved-collateral-currency/1144 | 9 | 10 | 11 | ## Summary (2-5 sentences) 12 | The BASK token is the Governance token for the Basket DAO Protocol. Adding BASK as a price collateral currency for the creation of synthetic tokens is the purpose of this collateral UMIP. 13 | 14 | ## Motivation 15 | Adding BASK as a collateral currency would give Basket DAO community members the ability to create synthetic tokens for the creation of KPI options. The creation of these tokens using the UMA protocol, will not only allow for growth in the Basket DAO community but would also raise the current TVL of the UMA protocol thus benefitting both communities. Basket DAO has also expressed interest in other UMA protocol products as well. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be made: 20 | - The [BASK address](https://etherscan.io/address/0x44564d0bd94343f72e3c8a0d22308b7fa71db0bb) needs to be added to the collateral currency whitelist introduced in UMIP-8. 21 | - A final fee of 4 BASK in the proposed collateral currency needs to be added for BASK in the Store contract. 22 | 23 | ## Rationale 24 | Adding BASK as a collateral type would give the Basket DAO community the ability to create the KPI options that it has expressed it would like to mint. These options will not only help in the growth to the Basket DAO community, but the adding BASK as a collateral currency would also increase the UMA protocols TVL, thus benefitting both communities. The Basket DAO community has also expressed interest in creating Call options in the future. Thus adding the Basket DAO governance token BASK as a collateral type will benefit UMA both now, and into the future. Basket DAO while fairly new shows good liquidity and its value keeps on par with other similar coins. 25 | 26 | ## Implementation 27 | 28 | This change has no implementations other than the afore mentioned governor transactions 29 | 30 | ## Security considerations 31 | BASK is the governance token of the Basket DAO protocol. Its implementation as a collateral currency should pose no security threats other than normal market volatility. That being said $UMA holders should evaluate the ongoing cost and benefit of supporting this asset as collateral if liquidity concerns are identified. UMA holders should take note of the collaterals nature as liquidity if the collateral changes or if added robustness(Eg. via TWAPs are necessary to prevent market manipulation. -------------------------------------------------------------------------------- /UMIPs/umip-11.md: -------------------------------------------------------------------------------- 1 | # Headers 2 | 3 | | UMIP-11 | | 4 | | ---------- | ----------------------------------- | 5 | | UMIP Title | Add renBTC as a collateral currency | 6 | | Authors | Adrian Li (adrian@umaproject.org) | 7 | | Status | Approved | 8 | | Created | August 26, 2020 | 9 | 10 | ## Summary 11 | 12 | This UMIP will add renBTC as an approved collateral currency. This will involve adding it to the whitelist and adding a flat final fee to charge per-request. The proposed final fee is 0.018 renBTC per request. 13 | 14 | ## Motivation 15 | 16 | BTC is the world’s largest and most popular cryptocurrency by market capitalization as well as traded volume. Many holders of BTC like to borrow against their BTC to get leverage on their BTC. At the time of writing, over 7,000 WBTC are locked in MakerDAO in this fashion. 17 | 18 | To allow synthetic tokens created with the EMP to take advantage of this liquidity and desire for leverage, an ERC20-compliant representation of BTC is required. renBTC is an ERC20 token backed 1:1 with BTC using the decentralized Ren Protocol. 19 | 20 | renBTC as collateral is expected to have a variety of deployments. The timing for adding it now, and the immediate application, is for use with USDBTC, which will enable the creation of yUSD, a yielding dollar token. This price identifier is described in [UMIP-7](./umip-7.md). 21 | 22 | ## Technical Specification 23 | 24 | To accomplish this upgrade, three changes need to be made: 25 | 26 | - The renBTC address, 0xeb4c2781e4eba804ce9a9803c67d0893436bb27d, needs to be added to the collateral currency whitelist introduced in UMIP-8. 27 | - A final fee of 0.018 needs to be added for renBTC in the Store contract. 28 | - The precision for the USDBTC price identifier needs to be amended to 8 decimals instead of the usual 18 in order to comply with renBTC’s 8 decimals of precision. 29 | 30 | ## Rationale 31 | 32 | The rationale behind this change is giving deployers more useful collateral currency options. renBTC needs to be used instead of BTC due to it being an ERC20 representing BTC on the Ethereum blockchain, whereas native BTC does not exist on the Ethereum blockchain. 33 | 34 | renBTC was chosen in particular due to the fact that renBTC is the most popular (and largest) truly decentralized BTC-representing coin on the Ethereum blockchain. It is not being chosen at the exclusion of other possible BTC-representing coins, but it is a natural first choice for this purpose. 35 | 36 | While wBTC currently has larger market dominance than renBTC, it is worth noting that renBTC has already gained significant traction in the DeFi space. There exists a large amount of renBTC liquidity on Curve Finance ($98m), Balancer ($5m), and Uniswap ($150k). 37 | 38 | Large projects like Compound and Maker already have wBTC as a collateral type, so using renBTC within the UMA ecosystem can serve to differentiate the UMA community in terms of promoting a more decentralized version of BTC on the Ethereum blockchain. 39 | 40 | ## Implementation 41 | 42 | This change has no implementation other than adding the collateral type to the whitelist. 43 | 44 | ## Security considerations 45 | 46 | renBTC is minted with real BTC via RenVM, a trustless and decentralized virtual machine run by a network of nodes known as Darknodes. A user first sends BTC to a dedicated Bitcoin address generated by a dapp and verified by RenVM. The BTC is held in custody by RenVM's decentralized network of Darknodes. renBTC is backed 1:1 with BTC. 47 | 48 | Since renBTC is minted trustlessly as a token backed via the Ren Protocol, including it as a collateral currency should impose minimal risk to the protocol. 49 | 50 | The only security implication is for contract deployers and users who are considering using EMP contracts with renBTCC as the collateral currency. They should recognize that, relative to most fiat currencies, renBTC is much more volatile than Dai. This volatility should be taken into account when parameterizing or using these EMP contracts. 51 | -------------------------------------------------------------------------------- /UMIPs/umip-115.md: -------------------------------------------------------------------------------- 1 | UMIP-115 2 | 3 | - **UMIP title:** Add **BPRO** as collateral currency 4 | - **Author** yaron@bprotocol.org 5 | - **Status: Approved** 6 | - **Created:** 7.7.2021 7 | - **Discourse Link:** https://discourse.umaproject.org/t/add-bpro-as-approved-collateral/1236 8 | 9 | ## Summary 10 | 11 | This UMIP proposes adding **BPRO** for use as collateral in UMA contracts. 12 | 13 | ## Motivation 14 | 15 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be made: 20 | 21 | - The **BPRO** address **[0xbbbbbbb5aa847a2003fbc6b5c16df0bd1e725f61](https://etherscan.io/token/0xbbbbbbb5aa847a2003fbc6b5c16df0bd1e725f61)** needs to be added to the collateral currency whitelist introduced in UMIP-8. 22 | - A final fee of **200 BPRO** needs to be added for **BPRO** in the Store contract. 23 | 24 | 25 | ## Rationale 26 | 27 | This store fee was chosen as it is approximately equivalent to $400 in line with other collateral currencies as determined by **[coingecko price display](https://www.coingecko.com/en/coins/b-protocol)** 28 | 29 | ## Implementation 30 | 31 | 32 | This change has no implementations other than the aforementioned governor transactions 33 | 34 | ## Security considerations 35 | 36 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 37 | 38 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 39 | 40 | -------------------------------------------------------------------------------- /UMIPs/umip-120.md: -------------------------------------------------------------------------------- 1 | **UMIP 120** 2 | 3 | - **UMIP title:** Add Polygon renBTC and RBN as collateral currencies. 4 | - **Author** Chandler De Kock (chandler@umaproject.org) 5 | - **Status: Approved** 6 | - **Created:** 21 July 7 | 8 | ## Summary (2-5 sentences) 9 | 10 | This UMIP proposes adding **Polygon renBTC** , **RBN** for use as collateral in UMA contracts. 11 | 12 | ## Technical Specification 13 | 14 | To accomplish this upgrade, the following changes need to be made: 15 | 16 | - The **renBTC** address [Polygon token address](https://polygonscan.com/token/0xdbf31df14b66535af65aac99c32e9ea844e14501) 0xdbf31df14b66535af65aac99c32e9ea844e14501 needs to be added to the collateral currency whitelist introduced in UMIP-8. 17 | - A final fee of **0.012 renBTC** 18 | 19 | - The **RBN** address [Ethereum token address](https://etherscan.io/token/0x6123B0049F904d730dB3C36a31167D9d4121fA6B) 0x6123B0049F904d730dB3C36a31167D9d4121fA6B needs to be added to the collateral currency whitelist introduced in UMIP-8. 20 | - A final fee of **10 000 RBN** 21 | 22 | *Note*: a precisely accurate final fee cannot be obtained currently for RBN, since RBN is not yet actively traded. Instead a somewhat arbitrary amount of 10,000 tokens was chosen. 23 | 24 | RBN has a max total supply of 1b RBN. RBN is a protocol that has gained a large amount of traction, so an estimated starting market cap of $50m seems reasonable. This would give RBN a starting price of $0.05, putting the final fee at $500 - or right around the $400 target value. 25 | 26 | This should however be updated in a UPP at a later date if needed. 27 | 28 | 29 | ## Security considerations 30 | 31 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 32 | 33 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 34 | 35 | 36 | -------------------------------------------------------------------------------- /UMIPs/umip-124.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | 3 | **UMIP-124** 4 | 5 | - **UMIP title:** Add BANK as collateral currency 6 | - **Author** chandler@umaproject.org 7 | - **Status:** Approved 8 | - **Created:** 11 August 2021 9 | - **Discourse Link:** https://discourse.umaproject.org/t/add-bank-as-collateral/1285 10 | 11 | ## Summary (2-5 sentences) 12 | 13 | This UMIP proposes adding **BANK** for use as collateral in UMA contracts. 14 | 15 | ## Motivation 16 | 17 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 18 | 19 | ## Technical Specification 20 | 21 | To accomplish this upgrade, the following changes need to be made: 22 | 23 | - The Bankless DAO (BANK) **[token address](https://etherscan.io/address/0x2d94aa3e47d9d5024503ca8491fce9a2fb4da198) 0x2d94aa3e47d9d5024503ca8491fce9a2fb4da198** needs to be added to the collateral currency whitelist introduced in UMIP-8. 24 | - A final fee of **5500 BANK** needs to be added for **token** in the Store contract. 25 | 26 | ## Implementation 27 | 28 | 29 | This change has no implementations other than the aforementioned governor transactions 30 | 31 | ## Security considerations 32 | 33 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 34 | 35 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 36 | 37 | 38 | -------------------------------------------------------------------------------- /UMIPs/umip-125.md: -------------------------------------------------------------------------------- 1 | **UMIP-125** 2 | 3 | - **UMIP title:** Add MATIC, INST and JRT as collateral currency 4 | - **Author:** Chandler De Kock (chandler@umaproject.org) 5 | - **Status:** Approved 6 | - **Created:** 12 August 2021 7 | - **Discourse Link:** https://discourse.umaproject.org/t/add-matic-inst-and-jrt-as-collateral/1305 8 | 9 | ## Summary (2-5 sentences) 10 | 11 | This UMIP proposes adding **MATIC**, **INST** and **JRT** for use as collateral in UMA contracts. 12 | 13 | ## Motivation 14 | 15 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be made: 20 | 21 | 22 | ### Matic token (note that the token on Polygon is Wrapped Matic) 23 | - The MATIC [Ethereum token address](https://etherscan.io/address/0x7D1AfA7B718fb893dB30A3aBc0Cfc608AaCfeBB0): 0x7D1AfA7B718fb893dB30A3aBc0Cfc608AaCfeBB0 24 | - The WMATIC [Polygon token address](https://polygonscan.com/token/0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270): 0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270 25 | - A final fee of **380 MATIC** needs to be added for Store in the contract. 26 | 27 | ### InstaDapp token 28 | - The INST [Ethereum token address](https://etherscan.io/address/0x6f40d4a6237c257fff2db00fa0510deeecd303eb): 0x6f40d4a6237c257fff2db00fa0510deeecd303eb 29 | - The INST [Polygon token address](https://polygonscan.com/address/0xf50D05A1402d0adAfA880D36050736f9f6ee7dee): 0xf50D05A1402d0adAfA880D36050736f9f6ee7dee 30 | - A final fee of **45 INST** needs to be added for Store in the contract. 31 | 32 | ### Jarvis reward token 33 | - The JRT [Ethereum token address](https://etherscan.io/address/0x8a9c67fee641579deba04928c4bc45f66e26343a): 0x8a9c67fee641579deba04928c4bc45f66e26343a 34 | - A final fee of **4000 JRT** needs to be added for Store in the contract. 35 | 36 | ## Rationale 37 | 38 | This store fee was chosen as it is approximately equivalent to $400 in line with other collateral currencies as determined by looking at the price on CoinGecko, Coinmarketcap and Cryptowatch. 39 | 40 | ## Implementation 41 | 42 | This change has no implementations other than the aforementioned governor transactions 43 | 44 | ## Security considerations 45 | 46 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 47 | 48 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 49 | 50 | 51 | -------------------------------------------------------------------------------- /UMIPs/umip-126.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | UMIP-126 3 | 4 | - UMIP title: Add YEL as collateral currency 5 | - Author: Chandler (chandler@umaproject.org) 6 | - Status: Approved 7 | - Created: 24 August 2021 8 | 9 | ## Summary (2-5 sentences) 10 | 11 | This UMIP proposes adding the YEL token for use as collateral in UMA contracts. 12 | 13 | ## Motivation 14 | 15 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be made: 20 | 21 | 22 | The token address needs to be added to the collateral currency whitelist introduced in UMIP-8. 23 | - The **YEL token Ethereum [address](https://etherscan.io/token/0x7815bda662050d84718b988735218cffd32f75ea)**: 0x7815bda662050d84718b988735218cffd32f75ea 24 | - The **YEL token Polygon [address](https://polygonscan.com/token/0xd3b71117e6c1558c1553305b44988cd944e97300):** 0xd3b71117e6c1558c1553305b44988cd944e97300 25 | - A final fee of **33 000 YEL tokens** needs to be added in the Store contract. 26 | 27 | 28 | ## Rationale 29 | 30 | This store fee was chosen as it is approximately equivalent to $400 in line with other collateral currencies as determined by using the average market price of the token over the past 30 days on CoinGecko. 31 | 32 | ## Implementation 33 | 34 | This change has no implementations other than the governor mentioned above transactions. 35 | 36 | ## Security considerations 37 | 38 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. This token has a significantly small value with the substantial risk of the price going to zero. While trading activity shows stable prices, the possibility of the token going to zero should be noted for any contract wishing to use YEL as collateral. 39 | 40 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 41 | 42 | 43 | -------------------------------------------------------------------------------- /UMIPs/umip-128.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | UMIP-128 3 | 4 | - UMIP title: Add DFX as a Polygon collateral currency 5 | - Author: Chandler (chandler@umaproject.org) 6 | - Status: Approved 7 | - Created: 10 September 2021 8 | 9 | ## Summary (2-5 sentences) 10 | 11 | This UMIP proposes adding **DFX** for use as collateral in UMA contracts for the Polygon Network. DFX has already been approved for use as collateral on Ethereum. 12 | 13 | ## Motivation 14 | 15 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be made: 20 | 21 | - The DFX [Polygon token](https://polygonscan.com/address/0xe7804d91dfcde7f776c90043e03eaa6df87e6395): 0xe7804d91dfcde7f776c90043e03eaa6df87e6395 needs to be added to the collateral currency whitelist introduced in UMIP-8. 22 | 23 | - A final fee of **800 DFX** needs to be added to the Store Contract. 24 | - The final fee for Ethereum mainnet DFX was previously set to 400. This will also be updated to 800 to match the polygon final fee. 25 | 26 | 27 | ## Rationale 28 | 29 | This store fee was chosen as it is approximately equivalent to $400 in line with other collateral currencies as determined by the latest prices on CoinMarketCap and CoinGecko. 30 | 31 | ## Implementation 32 | 33 | 34 | This change has no implementations other than the aforementioned governor transactions 35 | 36 | ## Security considerations 37 | 38 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 39 | 40 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 41 | 42 | 43 | -------------------------------------------------------------------------------- /UMIPs/umip-131.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | UMIP-131 3 | 4 | - UMIP title: Add miMATIC, VOL, BIFI, ICE, IRON and IF as supported collateral currencies 5 | - Author: Chandler (chandler@umaproject.org) 6 | - Status: Approved 7 | - Created: 13 September 2021 8 | 9 | 10 | ## Summary (2-5 sentences) 11 | 12 | This UMIP proposes adding **miMATIC**, **VOL**, **BIFI**, **ICE**, **IRON** and **IF** for use as collateral in UMA contracts. 13 | 14 | ## Motivation 15 | 16 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 17 | 18 | miMATIC also known as MAI is a soft pegged stablecoin that is backed by other assets in the Polygon network. 19 | 20 | ## Technical Specification 21 | 22 | To accomplish this upgrade, the following changes needs to be added to the collateral currency whitelist introduced in UMIP-8. 23 | 24 | ## Ethereum 25 | ### VOL token 26 | - The **VOL** Ethereum [token address](https://etherscan.io/token/0x5166e09628b696285e3a151e84fb977736a83575): 0x5166e09628b696285e3a151e84fb977736a83575 27 | - A final fee of **1200 VOL** needs to be added in the Store contract. 28 | 29 | ### IF (Impossible Finance) 30 | - The **IF** Ethereum [token address](https://etherscan.io/token/0xb0e1fc65c1a741b4662b813eb787d369b8614af1): 0xb0e1fc65c1a741b4662b813eb787d369b8614af1 31 | - A final fee of **250 IF** needs to be added in the Store contract. 32 | 33 | ## Polygon 34 | ### miMATIC token 35 | - The **miMATIC** Polygon [token address](https://polygonscan.com/token/0xa3fa99a148fa48d14ed51d610c367c61876997f1): 0xa3fa99a148fa48d14ed51d610c367c61876997f1 36 | - A final fee of **400 MAI** needs to be added in the Store contract. 37 | 38 | ### BIFI token 39 | - The **BIFI** Polygon [token address](https://polygonscan.com/token/0xfbdd194376de19a88118e84e279b977f165d01b8): 0xfbdd194376de19a88118e84e279b977f165d01b8 40 | - A final fee of **0.5 BIFI** needs to be added in the Store contract. 41 | 42 | ### ICE token (Iron Finance) 43 | - The **ICE** Polygon [token address](https://polygonscan.com/token/0x4A81f8796e0c6Ad4877A51C86693B0dE8093F2ef): 0x4A81f8796e0c6Ad4877A51C86693B0dE8093F2ef 44 | - A final fee of **23 000 ICE** needs to be added in the Store contract. 45 | 46 | ### IRON stablecoin 47 | - The **IRON** Polygon [token address](https://polygonscan.com/token/0xD86b5923F3AD7b585eD81B448170ae026c65ae9a): 0xD86b5923F3AD7b585eD81B448170ae026c65ae9a 48 | - A final fee of **400 IRON** needs to be added in the Store contract. 49 | 50 | ## Rationale 51 | 52 | This store fee was chosen as it is approximately equivalent to $400 in line with other collateral currencies as determined by assuming that the MIA and IRON tokens will hold its peg to $1 per token or by using CoinMarketCap and CoinGecko prices. 53 | 54 | ## Implementation 55 | 56 | 57 | This change has no implementations other than the aforementioned governor transactions 58 | 59 | ## Security considerations 60 | 61 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 62 | 63 | It is noted that the ICE token is a redeployment of the TITAN token from the Iron Finance team. 64 | 65 | IF also has very low liquidity on Ethereum mainnet, because its home-chain is BSC. Because of this, it should likely only be used for non-liquidatable contracts. 66 | 67 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 68 | 69 | 70 | -------------------------------------------------------------------------------- /UMIPs/umip-133.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | UMIP-133 3 | 4 | - UMIP title: Add PERP, GRO and POOL as collateral currency 5 | - Author: Chandler (chandler@umaproject.org) 6 | - Status: Approved 7 | - Created: 28 September 2021 8 | 9 | ## Summary (2-5 sentences) 10 | 11 | This UMIP proposes adding **PERP**, **POOL** and **GRO** for use as collateral in UMA contracts. 12 | 13 | ## Motivation 14 | 15 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following needs to be added to the collateral currency whitelist introduced in UMIP-8. 20 | 21 | ### PERP 22 | - The **PERP** Ethereum [token address](https://etherscan.io/token/0xbc396689893d065f41bc2c6ecbee5e0085233447): 0xbc396689893d065f41bc2c6ecbee5e0085233447 23 | - A final fee of **35 PERP tokens** needs to be added in the Store contract. 24 | 25 | ### GRO 26 | - The **GRO** Ethereum [token address](https://etherscan.io/address/0x3ec8798b81485a254928b70cda1cf0a2bb0b74d7): 0x3ec8798b81485a254928b70cda1cf0a2bb0b74d7 27 | - A final fee of **35 GRO tokens** needs to be added in the Store contract. 28 | 29 | ### POOL 30 | - The **POOL** Polygon [token address](https://polygonscan.com/address/0x25788a1a171ec66da6502f9975a15b609ff54cf6): 0x25788a1a171ec66da6502f9975a15b609ff54cf6 31 | - A final fee of **45 POOL tokens** needs to be added in the Store contract. 32 | ## Rationale 33 | 34 | This store fee was chosen as it is approximately equivalent to $400 in line with other collateral currencies as determined by using the average price observed on Coinmarketcap. 35 | 36 | ## Implementation 37 | 38 | 39 | This change has no implementations other than the aforementioned governor transactions 40 | 41 | ## Security considerations 42 | 43 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 44 | 45 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 46 | 47 | 48 | -------------------------------------------------------------------------------- /UMIPs/umip-134.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | UMIP-134 3 | 4 | - UMIP title: Add AQUA and IDIA as collateral currency 5 | - Author: Chandler (chandler@umaproject.org) 6 | - Status: Approved 7 | - Created: 12 October 2021 8 | 9 | ## Summary (2-5 sentences) 10 | 11 | This UMIP proposes adding **AQUA** and **IDIA** for use as collateral in UMA contracts. 12 | 13 | ## Motivation 14 | 15 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be added to the collateral currency whitelist introduced in UMIP-8. 20 | 21 | ### AQUA 22 | - The **AQUA** address [token address](https://etherscan.io/address/0xd34a24006b862f4e9936c506691539d6433ad297): 0xd34a24006b862f4e9936c506691539d6433ad297 23 | - A final fee of **700 000 AQUA** needs to be added for the Store contract. 24 | 25 | ### IDIA 26 | - The **IDIA** address [token address](https://etherscan.io/address/0x0b15ddf19d47e6a86a56148fb4afffc6929bcb89): 0x0b15ddf19d47e6a86a56148fb4afffc6929bcb89 27 | - A final fee of **450 IDIA** needs to be added for the Store contract. 28 | 29 | ## Rationale 30 | 31 | This store fee was chosen as it is approximately equivalent to $400 in line with other collateral currencies as determined by using the current coinmarketcap prices. 32 | 33 | 34 | ## Implementation 35 | 36 | 37 | This change has no implementations other than the aforementioned governor transactions 38 | 39 | ## Security considerations 40 | 41 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 42 | 43 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 44 | 45 | IDIA is currently primarily used on BSC and has minimal liquidity on Ethereum mainnet. Because of this, developers using mainnet IDIA should take care to create "safe" contracts with it. As an example, use of IDIA for a liquidatable and volatile synthetic would likely not be practical, as liquidators would not necessarily have immediate access to capital required for liquidations. Its intended use case is to be used with non-liquidatable UMA contracts. 46 | 47 | 48 | -------------------------------------------------------------------------------- /UMIPs/umip-135.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-135 | | 3 | |------------|---------------------------------| 4 | | UMIP Title | Add Skinny Optimistic Oracle | 5 | | Authors | Matt Rice (matt@umaproject.org) | 6 | | Status | Approved | 7 | | Created | October 18, 2021 | 8 | 9 | ## Summary (2-5 sentences) 10 | This UMIP will have the effect of introducing a new, slimmed down optimistic oracle contract that will allow optimistic settlement of prices with lower gas costs. This will reduce the cost for end-users of UMA's oracle infrastructure. 11 | 12 | ## Motivation 13 | Prior to addition of this Optimistic Oracle, it could cost millions of gas to complete an Optimistic Oracle request lifecycle. 14 | 15 | ## Technical Specification 16 | To accomplish this upgrade, a few actions will need to be taken: 17 | - A new `SkinnyOptimisticOracle` contract has been deployed at [0x4060dba72344da74edaeeae51a71a57f7e96b6b4](https://etherscan.io/address/0x4060dba72344da74edaeeae51a71a57f7e96b6b4). 18 | - A transaction will need to be proposed to add this new address to the `Finder` contract under the name `SkinnyOptimisticOracle`. This is how other contracts will find the optimistic oracle and reference it. 19 | - The `SkinnyOptimisticOracle` will need to be registered with the `Registry` so that it can make requests to the DVM. 20 | 21 | Note: this change will only add the skinny optimistic oracle. New financial contracts that utilize the optimistic oracle will need to be deployed for it to become useful. Until all steps above are performed, the deployed SkinnyOptimisticOracle _should not_ be used in production since it will not be able to raise disputes to the DVM. 22 | 23 | ## Implementation 24 | 25 | The `SkinnyOptimisticOracle` contract can be found [here](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/oracle/implementation/SkinnyOptimisticOracle.sol). It is in the process of being audited. If the audit requires changes, a follow-up proposal can remove this implementation and add the updated one with little-to-no risk to the DVM. 26 | 27 | The mainnet contract address: 28 | 29 | *SkinnyOptimisticOracle* - [0x4060dba72344da74edaeeae51a71a57f7e96b6b4](https://etherscan.io/address/0x4060dba72344da74edaeeae51a71a57f7e96b6b4) 30 | 31 | 32 | ## Security considerations 33 | 34 | The Optimistic Oracle only has the ability to send price requests to the DVM, so in the event of a serious bug, the biggest security implication would be that end-users would be able to send requests to the DVM without paying the final fee. 35 | -------------------------------------------------------------------------------- /UMIPs/umip-137.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-137 | | 3 | |------------|---------------------------------------------| 4 | | UMIP Title | Add QUARTZ and ibBTC as collateral currency | 5 | | Authors | Mhairi McAlpine (mhairi@umaproject.org) | 6 | | Status | Approved | 7 | | Created | November 2, 2021 | 8 | 9 | 10 | 11 | 12 | ## Summary (2-5 sentences) 13 | 14 | 15 | This UMIP proposes adding QUARTZ and ibBTC for use as collateral in UMA contracts. 16 | 17 | 18 | ## Motivation 19 | 20 | 21 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 22 | 23 | 24 | ## Technical Specification 25 | 26 | 27 | To accomplish this upgrade, the following changes need to be made: 28 | 29 | 30 | - The QUARTZ token address 0xba8a621b4a54e61c442f5ec623687e2a942225ef([https://etherscan.io/address/0xba8a621b4a54e61c442f5ec623687e2a942225ef](https://etherscan.io/address/0xba8a621b4a54e61c442f5ec623687e2a942225ef) needs to be added to the collateral currency whitelist introduced in UMIP-8. 31 | 32 | - A final fee of 60 QUARTZ needs to be added for QUARTZ in the Store contract. 33 | 34 | - The ibBTC token address 0xc4e15973e6ff2a35cc804c2cf9d2a1b817a8b40f ([https://etherscan.io/token/0xc4e15973e6ff2a35cc804c2cf9d2a1b817a8b40f](https://etherscan.io/token/0xc4e15973e6ff2a35cc804c2cf9d2a1b817a8b40f) needs to be added to the collateral currency whitelist introduced in UMIP-8. 35 | 36 | - A final fee of 0.0067 ibBTC needs to be added for ibBTC in the store contract 37 | 38 | 39 | ## Rationale 40 | 41 | 42 | This store fee for each token was chosen as it is approximately equivalent to $400 in line with other collateral currencies as determined by querying CoinGecko. 43 | 44 | 45 | ## Implementation 46 | 47 | 48 | This change has no implementations other than the aforementioned governor transactions 49 | 50 | 51 | ## Security considerations 52 | 53 | 54 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. These collateral type should be monitored to ensure that the proposed collateral continues to have value. 55 | 56 | It should be noted that there is limited liquidity for QUARTZ on the Ethereum mainnet, consequently the final fee was determined using the liquidity available on the BSC sidechain 57 | 58 | Contract deployers considering using these collateral in an UMA contract should refer to the guidelines on collateral type usage available here **https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition** to ensure appropriate use. 59 | 60 | 61 | -------------------------------------------------------------------------------- /UMIPs/umip-138.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-138 | | 3 | |------------|-------------------------------------| 4 | | UMIP Title | Upgrade Skinny Optimistic Oracle | 5 | | Authors | Nick Pai (nick@umaproject.org) | 6 | | Status | Approved | 7 | | Created | November 3, 2021 | 8 | 9 | ## Summary (2-5 sentences) 10 | This UMIP should be viewed exactly as UMIP-135 but with an updated contract address to account for security upgrades in the `SkinnyOptimisticOracle`. 11 | 12 | ## Motivation 13 | UMIP-135 registered a new `SkinnyOptimisticOracle` for use in the [Across](https://medium.com/across-protocol/announcing-across-protocol-the-fastest-cheapest-and-most-secure-l2-to-l1-bridge-b64c66700e59) closed beta. However, this contract was always going have to be upgraded eventually since it was deployed pre-audit. This UMIP upgrades the `SkinnyOptimisticOracle` to a contract that includes some important fixes found during an external audit with OpenZeppelin. 14 | 15 | ## Technical Specification 16 | To accomplish this upgrade, a few actions will need to be taken: 17 | - A new `SkinnyOptimisticOracle` contract has been deployed at [0xeE3Afe347D5C74317041E2618C49534dAf887c24](https://etherscan.io/address/0xeE3Afe347D5C74317041E2618C49534dAf887c24). 18 | - A transaction will need to be proposed to add this new address to the `Finder` contract under the name `SkinnyOptimisticOracle`. This is how other contracts will find the optimistic oracle and reference it. 19 | - The `SkinnyOptimisticOracle` will need to be registered with the `Registry` so that it can make requests to the DVM. 20 | 21 | Note: this change will only add the skinny optimistic oracle. New financial contracts that utilize the optimistic oracle will need to be deployed for it to become useful. Until all steps above are performed, the deployed SkinnyOptimisticOracle _should not_ be used in production since it will not be able to raise disputes to the DVM. 22 | 23 | ## Implementation 24 | 25 | The `SkinnyOptimisticOracle` contract can be found [here](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/oracle/implementation/SkinnyOptimisticOracle.sol). It has been audited and the audit report will be released soon. The changes to this contract from UMIP-135 are now described: 26 | - `proposePriceFor` call back was incorrectly made to `msg.sender` instead of `requester`, [PR](https://github.com/UMAprotocol/protocol/pull/3531). 27 | - `bond` amount in `requestAndProposePriceFor` should default to `finalFee` similar to `requestPrice`, [PR](https://github.com/UMAprotocol/protocol/pull/3534) 28 | - `requestAndProposePriceFor` should be reentrancy guarded, [PR](https://github.com/UMAprotocol/protocol/pull/3539) 29 | 30 | The mainnet contract address: 31 | 32 | *SkinnyOptimisticOracle* - [0xeE3Afe347D5C74317041E2618C49534dAf887c24](https://etherscan.io/address/0xeE3Afe347D5C74317041E2618C49534dAf887c24) 33 | 34 | 35 | ## Security considerations 36 | 37 | The Optimistic Oracle only has the ability to send price requests to the DVM, so in the event of a serious bug, the biggest security implication would be that end-users would be able to send requests to the DVM without paying the final fee. 38 | -------------------------------------------------------------------------------- /UMIPs/umip-142.md: -------------------------------------------------------------------------------- 1 | **UMIP-142** 2 | 3 | - **UMIP title:** Add **AthleteX** as collateral currency 4 | - **Author:** athletexmarkets@gmail.com 5 | - **Status: Approved** 6 | - **Created:** 12/31/2021 7 | - **Discourse Link:** https://discourse.umaproject.org/t/whitelist-ax-as-collateral/1250 8 | 9 | ## Summary (2-5 sentences) 10 | 11 | This UMIP proposes adding **AthleteX** for use as collateral in UMA contracts. 12 | 13 | ## Motivation 14 | 15 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be made: 20 | 21 | - The **AX** address **https://polygonscan.com/address/0x5617604BA0a30E0ff1d2163aB94E50d8b6D0B0Df** needs to be added to the collateral currency whitelist introduced in UMIP-8. 22 | - A final fee of **22000AX** needs to be added for **AthleteX** in the Store contract. 23 | 24 | 25 | ## Rationale 26 | 27 | This store fee was chosen as it is approximately equivalent to $1500 in line with other collateral currencies as determined by **https://www.coingecko.com/en/coins/athletex** 28 | 29 | ## Implementation 30 | 31 | 32 | This change has no implementations other than the aforementioned governor transactions 33 | 34 | ## Security considerations 35 | 36 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 37 | 38 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 39 | 40 | -------------------------------------------------------------------------------- /UMIPs/umip-145.md: -------------------------------------------------------------------------------- 1 | **UMIP 145** 2 | 3 | - **UMIP title:** Add BOBA, YAM and JRT as supported collateral currencies 4 | - **Author:** Reinis Martinsons (reinis@umaproject.org) 5 | - **Status:** Approved 6 | - **Created:** 13 January 2022 7 | - **Discourse Link:** https://discourse.umaproject.org/t/collateral-omnibus-9/1391 8 | 9 | ## Summary (2-5 sentences) 10 | 11 | This UMIP proposes adding **BOBA**, **YAM** and **JRT** for use as collateral in UMA contracts. 12 | 13 | ## Motivation 14 | 15 | The addition of these collateral currencies offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be made: 20 | 21 | ### BOBA 22 | 23 | - BOBA token address 0x42bBFa2e77757C645eeaAd1655E0911a7553Efbc on Ethereum (https://etherscan.io/address/0x42bbfa2e77757c645eeaad1655e0911a7553efbc) needs to be added to the collateral currency whitelist introduced in UMIP-8. 24 | - A final fee of 600 BOBA needs to be set in the Store contract for BOBA token address 0x42bBFa2e77757C645eeaAd1655E0911a7553Efbc on Ethereum. 25 | - A final fee of 600 BOBA also needs to be set in the Store contract for BOBA token address 0xa18bF3994C0Cc6E3b63ac420308E5383f53120D7 on Boba network (https://blockexplorer.boba.network/address/0xa18bF3994C0Cc6E3b63ac420308E5383f53120D7). Note that it has already been added to the collateral currency whitelist as part of deploying required UMA contract infrastructure on Boba network, but its initial final fee now is not consistent with $1500 value target. 26 | 27 | ### YAM 28 | 29 | - The YAM token address 0xb3b681dee0435ecc0a508e40b02b3c9068d618cd on [Polygon](https://polygonscan.com/token/0xb3b681dee0435ecc0a508e40b02b3c9068d618cd) needs to be added to the collateral currency whitelist introduced in UMIP-8. 30 | - A final fee of 4000 YAM needs to be set in the Store contract for the YAM token address on Polygon. Note that this is a different amount than what is set for the already whitelisted YAM token on Ethereum. 31 | - A final fee of 4000 needs to be set in the Store contract for the YAM token on Ethereum mainnet [0x0aacfbec6a24756c20d41914f2caba817c0d8521](https://etherscan.io/address/0x0aacfbec6a24756c20d41914f2caba817c0d8521). Note that this token is already whitelisted and thus this will only update the final fee. 32 | 33 | ### JRT 34 | 35 | - JRT token address 0x596eBE76e2DB4470966ea395B0d063aC6197A8C5 on Polygon (https://polygonscan.com/address/0x596ebe76e2db4470966ea395b0d063ac6197a8c5) needs to be added to the collateral currency whitelist introduced in UMIP-8. 36 | - A final fee of 22000 JRT needs to be set in the Store contract for JRT token address on Polygon. Note that this is the same amount as for already whitelisted JRT token on Ethereum. 37 | 38 | ## Rationale 39 | 40 | The store fees for BOBA and YAM were chosen as they is approximately equivalent to $1500 in line with other collateral currencies as determined by using the current CoinGecko prices. 41 | 42 | ## Implementation 43 | 44 | This change has no implementations other than the aforementioned governor transactions. 45 | 46 | ## Security considerations 47 | 48 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 49 | 50 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 51 | 52 | -------------------------------------------------------------------------------- /UMIPs/umip-148.md: -------------------------------------------------------------------------------- 1 | **UMIP-148** 2 | 3 | - **UMIP title:** DOM, CRE8R and COMFI as approved collateral currencies 4 | - **Author:** Reinis Martinsons (reinis@umaproject.org), Geoff (stadnykgeoff1@gmail.com) 5 | - **Status:** Approved 6 | - **Created:** 26 January 2022 7 | - **Discourse Link:** 8 | 9 | ## Summary (2-5 sentences) 10 | 11 | This UMIP proposes adding **DOM** for use as collateral in UMA contracts. 12 | 13 | ## Motivation 14 | 15 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be made: 20 | 21 | ### DOM (Domination Finance) 22 | 23 | - DOM token address 0xef5Fa9f3Dede72Ec306dfFf1A7eA0bB0A2F7046F on Ethereum (https://etherscan.io/address/0xef5Fa9f3Dede72Ec306dfFf1A7eA0bB0A2F7046F) needs to be added to the collateral currency whitelist introduced in UMIP-8. 24 | - DOM token address 0xc8aaeE7f1DEaC631259B8Bf2c65e71207cc53B0c on Polygon (https://polygonscan.com/address/0xc8aaeE7f1DEaC631259B8Bf2c65e71207cc53B0c) needs to be added to the collateral currency whitelist introduced in UMIP-8. 25 | - DOM token address 0xF56FbEc7823260D7510D63B63533153b58A01921 on Boba network (https://blockexplorer.boba.network/address/0xF56FbEc7823260D7510D63B63533153b58A01921) needs to be added to the collateral currency whitelist introduced in UMIP-8. 26 | - A final fee of 150000 DOM needs to be set in the Store contract for DOM token address on Ethereum, Polygon and Boba. 27 | 28 | ## CRE8R (CRE8R DAO) 29 | 30 | - The CRE8R address [0xaa61d5dec73971cd4a026ef2820bb87b4a4ed8d6](https://etherscan.io/token/0xaa61d5dec73971cd4a026ef2820bb87b4a4ed8d6) on Ethereum needs to be added to the collateral currency whitelist introduced in UMIP-8. 31 | - A final fee of 6000 CRE8R needs to be added in the Store contract. 32 | 33 | ## COMFI (CompliFi) 34 | 35 | - The COMFI address [0x752efadc0a7e05ad1bcccda22c141d01a75ef1e4](https://etherscan.io/token/0x752efadc0a7e05ad1bcccda22c141d01a75ef1e4) on Ethereum needs to be added to the collateral currency whitelist introduced in UMIP-8. 36 | - The COMFI address [0x72bba3aa59a1ccb1591d7cddb714d8e4d5597e96](https://polygonscan.com/token/0x72bba3aa59a1ccb1591d7cddb714d8e4d5597e96) on Polygon needs to be added to the collateral currency whitelist introduced in UMIP-8. 37 | - A final fee of 1200 COMFI needs to be set in the Store contract for COMFI token address on Ethereum and Polygon. 38 | 39 | ## Rationale 40 | 41 | Since there is no trading activity observed for DOM it was arbitrary assumed having $15 million market cap. Given the total supply of 1,500,000,000 DOM that would translate to $0.01 token price and 150000 DOM final fee targeting $1500 value. Final fee for DOM could be updated in the forthcoming UPP once the token is listed for trading. 42 | 43 | COMFI and CRE8R final fees were targeted at an approximate $1500 value at the time of proposal. 44 | 45 | ## Implementation 46 | 47 | This change has no implementations other than the aforementioned governor transactions. 48 | 49 | ## Security considerations 50 | 51 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 52 | 53 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 54 | 55 | As of time of authorship of this UMIP, DOM has no liquidity and trading activity and COMFI and CRE8R are both relatively illiquid. Because of this, developers using these currencies should take care to create "safe" contracts with it. As an example, use of DOM for a liquidatable and volatile synthetic would not be safe, as liquidators would not have access to capital required for liquidations. Its intended use case is to be used with non-liquidatable UMA contracts. 56 | -------------------------------------------------------------------------------- /UMIPs/umip-149.md: -------------------------------------------------------------------------------- 1 | | UMIP-149 | | 2 | | ------------------- | -------------------------------------------------- | 3 | | UMIP Title | Give Proposer DVM request permissions | 4 | | Authors | Matt Rice | 5 | | Status | Approved | 6 | | Created | 2022-01-27 | 7 | 8 | # Summary 9 | 10 | The Proposer contract should have permission to request and retrieve prices from the Voting contract (DVM). 11 | 12 | # Motivation 13 | 14 | The [Proposer contract](https://etherscan.io/address/0x226726Ac52e6e948D1B7eA9168F9Ff2E27DbcbB5) is already being used 15 | as the method to propose governance actions to the DVM. It requires a bond to do so. That bond is repaid if the 16 | proposal is successful. To determine whether the proposal is successful, it needs to read the result of the vote from 17 | the DVM. To do this, it needs to be approved by the 18 | [Registry contract](https://etherscan.io/address/0x3e532e6222afe9Bcf02DCB87216802c75D5113aE). 19 | 20 | This governance action will allow bonds to be repaid to successful proposers. 21 | 22 | # Data Specifications and Implementation 23 | 24 | Three transactions are required to approve the Proposer contract: 25 | 26 | 1. The Governor must give itself the contract creator permission (role 1 in the Registry contract). 27 | 2. The Governor must call registerContract on the Registry contract, passing 28 | `0x226726Ac52e6e948D1B7eA9168F9Ff2E27DbcbB5` as the `contractAddress` argument. 29 | 3. The Governor must remove its contract creator permission (role 1 in the Registry contract). 30 | 31 | # Security Considerations 32 | 33 | Approving registered contracts is low risk. The worst thing a malicious registered contract can do is spam the DVM with 34 | price requests without paying final fees. In this unlikely event, the voters could choose to selectively ignore all 35 | requests coming from that contract and they could be temporarily removed by any UI. Then the voters could choose to use 36 | governance to rectify the permissions. 37 | -------------------------------------------------------------------------------- /UMIPs/umip-150.md: -------------------------------------------------------------------------------- 1 | **UMIP-150** 2 | 3 | - **UMIP title:** Add UMA as collateral currency on Polygon 4 | - **Author:** Geoff (stadnykgeoff1@gmail.com) 5 | - **Status:** Approved 6 | - **Created:** 15 February 2022 7 | - **Discourse Link:** https://discourse.umaproject.org/t/create-add-uma-as-collateral-currency-to-polygon-md/1408 8 | 9 | ## Summary (2-5 sentences) 10 | 11 | This UMIP proposes adding UMA on Polygon for use as collateral in UMA contracts. 12 | 13 | ## Motivation 14 | 15 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be made: 20 | 21 | - The UMA address https://polygonscan.com/token/0x3066818837c5e6ed6601bd5a91b0762877a6b731 needs to be added to the collateral currency whitelist introduced in UMIP-8. 22 | - A final fee of 250 UMA needs to be added in the Store contract. 23 | - A final fee for the UMA Mainnet address https://etherscan.io/token/0x04Fa0d235C4abf4BcF4787aF4CF447DE572eF828 needs to be updated from 90 to 250. 24 | 25 | 26 | ## Rationale 27 | 28 | This store fee was chosen as it is approximately equivalent to $1500 in line with other collateral currencies as determined by CoinGecko 29 | 30 | ## Implementation 31 | 32 | 33 | This change has no implementations other than the aforementioned governor transactions 34 | 35 | ## Security considerations 36 | 37 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 38 | 39 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 40 | -------------------------------------------------------------------------------- /UMIPs/umip-153.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | - UMIP-153 3 | - UMIP title: Add Fiat DAO (FDT) as a collateral currency. 4 | - Author: Geoff (stadnykgeoff1@gmail.com) 5 | - Status: Approved 6 | - Created: 14 March 2022 7 | - Discourse Link: https://discourse.umaproject.org/t/umip-proposal-create-vsq-and-fdt-collateral-adds/1571 8 | 9 | ## Summary (2-5 sentences) 10 | 11 | This UMIP proposes adding FDT for use as collateral in UMA contracts. 12 | 13 | ## Motivation 14 | 15 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be made: 20 | 21 | - The **FDT** address on Ethereum **https://etherscan.io/token/0xed1480d12be41d92f36f5f7bdd88212e381a3677** needs to be added to the collateral currency whitelist introduced in UMIP-8. 22 | - A final fee of **9,000 FDT** needs to be added in the Store contract. 23 | 24 | ## Rationale 25 | 26 | This store fee was chosen as it is approximately equivalent to $1500 in line with other collateral currencies as determined by **[FDT](https://www.coingecko.com/en/coins/fiat-dao-token)** values from **CoinGecko** 27 | 28 | ## Implementation 29 | 30 | This change has no implementations other than the aforementioned governor transactions 31 | 32 | ## Security considerations 33 | 34 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 35 | 36 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 37 | -------------------------------------------------------------------------------- /UMIPs/umip-155.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | - UMIP-155 3 | - UMIP title: Add **VSQ** as collateral currency 4 | - Author: Geoff (stadnykgeoff1@gmail.com) 5 | - Status: Approved 6 | - Created: 24 March 2022 7 | - Discourse Link: https://discourse.umaproject.org/t/umip-proposal-create-add-vsq-as-collateral-on-polygon/1576 8 | 9 | ## Summary (2-5 sentences) 10 | 11 | This UMIP proposes adding **VSQ** for use as collateral in UMA contracts. 12 | 13 | ## Motivation 14 | 15 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be made: 20 | 21 | - The **VSQ** address on Polygon **https://polygonscan.com/token/0x29F1e986FCa02B7E54138c04C4F503DdDD250558** needs to be added to the collateral currency whitelist introduced in UMIP-8. 22 | - A final fee of **250** needs to be added for **VSQ** in the Store contract. 23 | 24 | 25 | ## Rationale 26 | 27 | This store fee was chosen as it is approximately equivalent to $1500 in line with other collateral currencies as determined by **[CoinGecko](https://www.coingecko.com/en/coins/vesq)** 28 | 29 | ## Implementation 30 | 31 | 32 | This change has no implementations other than the aforementioned governor transactions 33 | 34 | ## Security considerations 35 | 36 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 37 | 38 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 39 | -------------------------------------------------------------------------------- /UMIPs/umip-158.md: -------------------------------------------------------------------------------- 1 | **UMIP-158** 2 | 3 | - **UMIP title:** Add **PSP** (ParaSwap), **BEAN** (Beanstalk), and **TETU** as collateral currency 4 | - **Author:** Geoff (stadnykgeoff1@gmail.com) 5 | - **Status:** Approved 6 | - **Created:** 4 April 2022 7 | - **Discourse Link:** https://discourse.umaproject.org/t/umip-proposal-create-psp-bean-tetu-collateral-add/1642 8 | 9 | ## Summary (2-5 sentences) 10 | 11 | This UMIP proposes adding **PSP, BEAN, & TETU** for use as collateral in UMA contracts. 12 | 13 | ## Motivation 14 | 15 | The addition of these collateral currencies offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be made: 20 | 21 | ### PSP 22 | - The **PSP** address on Ethereum **https://etherscan.io/token/0xcafe001067cdef266afb7eb5a286dcfd277f3de5** needs to be added to the collateral currency whitelist introduced in UMIP-8. 23 | - A final fee of **15,000** needs to be added for **PSP** in the Store contract. 24 | - The **PSP** address on Polygon **https://polygonscan.com/token/0x42d61D766B85431666B39B89C43011f24451bFf6** needs to be added to the collateral currency whitelist introduced in UMIP-8. 25 | - A final fee of **15,000** needs to be added for **PSP** in the Store contract. 26 | 27 | ### BEAN 28 | - The **BEAN** address on Ethereum **https://etherscan.io/token/0xDC59ac4FeFa32293A95889Dc396682858d52e5Db** needs to be added to the collateral currency whitelist introduced in UMIP-8. 29 | - A final fee of **1,500** needs to be added for **BEAN** in the Store Contract. 30 | 31 | ### TETU 32 | - The **TETU** address on Polygon **https://polygonscan.com/token/0x255707B70BF90aa112006E1b07B9AeA6De021424** needs to be added to the collateral currency whitelist introduced in UMIP-8. 33 | - A final fee of **40,000** needs to be added for **TETU** in the Store Contract. 34 | 35 | ## Rationale 36 | 37 | The store fees were chosen as they are approximately equivalent to $1500 in line with other collateral currencies as determined by **[CoinGecko](https://www.coingecko.com/)** 38 | 39 | ## Implementation 40 | 41 | 42 | This change has no implementations other than the aforementioned governor transactions 43 | 44 | ## Security considerations 45 | 46 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 47 | 48 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 49 | -------------------------------------------------------------------------------- /UMIPs/umip-161.md: -------------------------------------------------------------------------------- 1 | **UMIP-161** 2 | 3 | - **UMIP title:** Add MAGIC as collateral currency 4 | - **Author:** Mr.Bahama 5 | - **Status:** Approved 6 | - **Created:** 26 May 2022 7 | 8 | ## Summary (2-5 sentences) 9 | 10 | This UMIP proposes adding MAGIC for use as collateral in UMA contracts. 11 | 12 | ## Motivation 13 | 14 | MAGIC token is economic infrastructure for various play-to-own games using TreasureDAO. Adding MAGIC to UMA contracts will enable the Treasure ecosystem to incorporate more flexible in-game assets with defi. 15 | 16 | ## Technical Specification 17 | 18 | To accomplish this upgrade, the following changes need to be made: 19 | 20 | 21 | - The following address on Arbitrum needs to be added to the collateral currency whitelist introduced in UMIP-8: 22 | 23 | - MAGIC token address 0x539bdE0d7Dbd336b79148AA742883198BBF60342 24 | 25 | - https://arbiscan.io/token/0x539bdE0d7Dbd336b79148AA742883198BBF60342 26 | 27 | - The token on ethereum mainnet also needs to be added to the collateral currency whitelist. 28 | 29 | - 0xB0c7a3Ba49C7a6EaBa6cD4a96C55a1391070Ac9A 30 | 31 | - https://etherscan.io/token/0xB0c7a3Ba49C7a6EaBa6cD4a96C55a1391070Ac9A 32 | 33 | - A final fee of 5500 MAGIC needs to be set in the Store contract for MAGIC token 34 | 35 | 36 | ## Rationale 37 | 38 | The MAGIC final fee were targeted at an approximate $1500 value at the time of proposal. 39 | 40 | ## Implementation 41 | 42 | This change has no implementations other than the aforementioned governor transactions. 43 | 44 | ## Security considerations 45 | 46 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 47 | 48 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 49 | 50 | -------------------------------------------------------------------------------- /UMIPs/umip-162.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-162 | | 3 | |------------|---------------------------------| 4 | | UMIP Title | Add OptimisticOracleV2 | 5 | | Authors | Pablo Maldonado (pablo@umaproject.org) | 6 | | Status | Approved | 7 | | Created | June 21, 2022 | 8 | 9 | ## Summary (2-5 sentences) 10 | This UMIP will result in the creation of a new optimistic oracle contract with enhanced control over pricing request callbacks, which will only be executed if the requester has declared its readiness to receive them. This modification also eliminates the use of try-catch structures, which were vulnerable to gas griefing. Additionally, the contract includes a new event-based price request, which is suitable for requests that depend on events without a fixed date, thereby evaluating pricing requests at the time of proposal. This will enable the implementation of a more robust and adaptable price requests. 11 | 12 | ## Motivation 13 | Prior to the addition of this Optimistic Oracle, callbacks were executed whenever they were present in the requester contract, without the ability to control when this occurred. Additionally, the use of try-catch posed a risk. Similarly, there was no price request type that could be adapted to the request requirements associated with unscheduled, spontaneous events. 14 | 15 | ## Technical Specification 16 | To accomplish this upgrade, a few actions will need to be taken: 17 | - A new `OptimisticOracleV2` contract has been deployed in the following networks: 18 | * Mainnet: [0xA0Ae6609447e57a42c51B50EAe921D701823FFAe](https://etherscan.io/address/0xA0Ae6609447e57a42c51B50EAe921D701823FFAe) 19 | * Polygon: [0xee3afe347d5c74317041e2618c49534daf887c24](https://polygonscan.com/address/0xee3afe347d5c74317041e2618c49534daf887c24) 20 | * Optimism: [0x255483434aba5a75dc60c1391bB162BCd9DE2882](https://optimistic.etherscan.io/address/0x255483434aba5a75dc60c1391bB162BCd9DE2882) 21 | * Arbitrum: [0x88Ad27C41AD06f01153E7Cd9b10cBEdF4616f4d5](https://arbiscan.io/address/0x88Ad27C41AD06f01153E7Cd9b10cBEdF4616f4d5) 22 | * Boba: [0xb2b5C1b17B19d92CC4fC1f026B2133259e3ccd41](https://blockexplorer.boba.network/address/0xb2b5C1b17B19d92CC4fC1f026B2133259e3ccd41/transactions) 23 | 24 | 25 | - Transactions will need to be proposed to add this new addresses to the `Finder` contract under the name `OptimisticOracleV2` in each network. This is how other contracts will find the optimistic oracle and reference it. 26 | - The `OptimisticOracleV2` will need to be registered with the `Registry` in each network so that it can make requests to the DVM. 27 | 28 | Note: this change will only add the optimistic oracle v2 to the networks mentioned above. New financial contracts that utilize the optimistic oracle v2 will need to be deployed for it to become useful. Until all steps above are performed, the deployed OptimisticOracleV2 _should not_ be used in production since it will not be able to raise disputes to the DVM. 29 | 30 | ## Implementation 31 | 32 | The `OptimisticOracleV2` contract can be found [here](https://github.com/UMAprotocol/protocol/tree/master/packages/core/contracts/oracle/implementation). It is in the process of being audited. If the audit requires changes, a follow-up proposal can remove this implementation and add the updated one with little-to-no risk to the DVM. 33 | 34 | ## Security considerations 35 | 36 | The Optimistic Oracle V2 only has the ability to send price requests to the DVM, so in the event of a serious bug, the biggest security implication would be that end-users would be able to send requests to the DVM without paying the final fee. -------------------------------------------------------------------------------- /UMIPs/umip-164.md: -------------------------------------------------------------------------------- 1 | **UMIP-164** 2 | 3 | - **UMIP title:** Add THOR as collateral currency 4 | - **Author:** abg4 5 | - **Status:** Approved 6 | - **Created:** 28 June 2022 7 | 8 | ## Summary (2-5 sentences) 9 | 10 | This UMIP proposes adding THOR for use as collateral in UMA contracts. 11 | 12 | ## Motivation 13 | 14 | The THOR token acts as a governance, utility, and proof of membership token. Adding THOR to UMA contracts will enable the Thorswap ecosystem to incorporate KPI Options to incentivize their community. 15 | 16 | ## Technical Specification 17 | 18 | To accomplish this upgrade, the following changes need to be made: 19 | 20 | 21 | - The following address on Ethereum needs to be added to the collateral currency whitelist introduced in UMIP-8: 22 | 23 | - THOR token address 0xa5f2211B9b8170F694421f2046281775E8468044 24 | 25 | - https://etherscan.io/address/0xa5f2211B9b8170F694421f2046281775E8468044 26 | 27 | - A final fee of 6500 THOR needs to be set in the Store contract for THOR token 28 | 29 | 30 | ## Rationale 31 | 32 | The THOR final fee were targeted at an approximate $1500 value at the time of proposal. 33 | 34 | ## Implementation 35 | 36 | This change has no implementations other than the aforementioned governor transactions. 37 | 38 | ## Security considerations 39 | 40 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 41 | 42 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. -------------------------------------------------------------------------------- /UMIPs/umip-167.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | 3 | | UMIP-167 | | 4 | | ------------------- | ---------------------------------------------------- | 5 | | UMIP Title | Add ACX as a supported collateral currency | 6 | | Authors | Matt Rice (matt@umaproject.org) | 7 | | Status | Approved | 8 | | Created | 2022-11-22 | 9 | | Discourse Link | https://github.com/UMAprotocol/UMIPs/pull/561 | 10 | 11 | ## Summary (2-5 sentences) 12 | 13 | This UMIP proposes adding ACX for use as collateral in UMA contracts. 14 | 15 | ## Motivation 16 | 17 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 18 | 19 | ## Technical Specification 20 | 21 | To accomplish this upgrade, the following changes need to be made: 22 | 23 | - The ACX address [0x44108f0223A3C3028F5Fe7AEC7f9bb2E66beF82F](https://etherscan.io/address/0x44108f0223A3C3028F5Fe7AEC7f9bb2E66beF82F) needs to be added to the collateral currency whitelist introduced in UMIP-8. 24 | - A final fee of 15000 needs to be added for ACX in the Store contract. 25 | 26 | 27 | ## Rationale 28 | 29 | This store fee was chosen as it is approximately equivalent to $1500 in line with other collateral currencies as determined by the expected price of ACX with a $100MM fully diluted valuation. Because there are 1 billion ACX tokens in existance, this FDV would imply a per-token value of $0.1, meaning 15000 ACX would be roughly equivalent to $1500. Once the token has DEX liquidity, this final fee can be updated if it deviates too much from the desired $1500 target. 30 | 31 | ## Implementation 32 | 33 | This change has no implementations other than the aforementioned governor transactions. 34 | 35 | ## Security considerations 36 | 37 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 38 | 39 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 40 | 41 | -------------------------------------------------------------------------------- /UMIPs/umip-171.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | 3 | | UMIP-171 | | 4 | | ---------- | -------------------------------------- | 5 | | UMIP Title | Add OptimisticAsserter | 6 | | Authors | Pablo Maldonado (pablo@umaproject.org) | 7 | | Status | Approved | 8 | | Created | January 25, 2023 | 9 | |Discourse Link|https://discourse.umaproject.org/t/add-optimistic-asserter/1905| 10 | 11 | ## Summary (2-5 sentences) 12 | 13 | This UMIP proposes the introduction of the `OptimisticAsserter` contract, which allows for the assertion of truths about the world using an optimistic escalation game. The contract utilizes the UMA Data Verification Mechanism (DVM) to arbitrate disputes, and allows for the use of Escalation Managers to define their own security properties and tradeoffs. 14 | 15 | ## Motivation 16 | 17 | The `OptimisticAsserter` is a new form of Optimisitic Oracle which existing mechanics have been streamlined in order to simplify the creation of world-truth assertions. To this end, the result of an assertion can only be true or false, and an assertion is resolved only after the liveness period has expired or, in the case of a dispute, after it has been settled in the Oracle. In addition, the `OptimisticAsserter` permits the use of Escalation Managers to provide better control and setting over the escalation game and, ultimately, to disconnect from the UMA DVM in order to arbitrate conflicts in the specified Oracle. This disconnection logic is left up to the integrating project and is disabled by default. 18 | 19 | ## Technical Specification 20 | 21 | To accomplish this upgrade, a few actions will need to be taken: 22 | 23 | - A new `OptimisticAsserter` contract has been deployed in the following networks: 24 | 25 | - Mainnet: [0xFEc7C6AA64fDD17f456028e0B411f5c3877ADa5e](https://etherscan.io/address/0xFEc7C6AA64fDD17f456028e0B411f5c3877ADa5e) 26 | - Polygon: [0x1a3cF7c0f99256431Fd6e8163FF8748A4aE50b6F](https://polygonscan.com/address/0x1a3cF7c0f99256431Fd6e8163FF8748A4aE50b6F) 27 | - Optimism: [0xCd5FE81278FEbf3a9323eFC9F68AEcCAeAE8BE2C](https://optimistic.etherscan.io/address/0xCd5FE81278FEbf3a9323eFC9F68AEcCAeAE8BE2C) 28 | - Arbitrum: [0x211AD7adEf4d4348408B43da49D99bA117ADD8D1](https://arbiscan.io/address/0x211AD7adEf4d4348408B43da49D99bA117ADD8D1) 29 | - Boba: [0x17d02b5CDb6fe2c681A447B119e9f6F5AB4E3018](https://bobascan.com/address/0x17d02b5CDb6fe2c681A447B119e9f6F5AB4E3018) 30 | 31 | - Transactions will need to be proposed to add this new addresses to the `Finder` contract under the name `OptimisticAsserter` in each network. This is how other contracts will find the Optimistic Asserter and reference it. 32 | - The `OptimisticAsserter` will need to be registered with the `Registry` in each network so that it can make requests to the DVM. 33 | 34 | Note: this change will only add the `OptimisticAsserter` to the networks mentioned above. New contracts that utilize the `OptimisticAsserter` will need to be deployed for it to become useful. Until all steps above are performed, the deployed `OptimisticAsserter` _should not_ be used in production since it will not be able to raise disputes to the DVM. 35 | 36 | This [script](https://github.com/UMAprotocol/protocol/blob/master/packages/scripts/src/upgrade-tests/register-new-contract/1_Propose.ts) will generate the mainnet transactions required to register the aforementioned contracts in their respective Registry and Finder, and will include them in the UMIP proposal. 37 | 38 | ## Implementation 39 | 40 | The `OptimisticAsserter` contract can be found [here](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/optimistic-asserter/implementation/OptimisticAsserter.sol). The contract has already been audited by OpenZeppelin and the audit report can be found [here](https://blog.openzeppelin.com/uma-optimistic-asserter-audit/). 41 | 42 | ## Security considerations 43 | 44 | The `OptimisticAsserter` only has the ability to send price requests to the DVM, so in the event of a serious bug, the biggest security implication would be that end-users would be able to send requests to the DVM without paying the final fee. 45 | -------------------------------------------------------------------------------- /UMIPs/umip-174.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | 3 | | UMIP-174 | | 4 | | ---------- | -------------------------------------------------------------------------------------- | 5 | | UMIP Title | Update UMA emission rate | 6 | | Authors | Reinis Martinsons (reinis@umaproject.org) | 7 | | Status | Approved | 8 | | Created | March 06, 2023 | 9 | | Discussion | [Discourse](https://discourse.uma.xyz/t/feat-update-uma-emission/1940) | 10 | 11 | ## Summary 12 | 13 | This UMIP proposes to set a new emission rate for the VotingV2 contract at 0.18 UMA per second. 14 | 15 | ## Motivation & Rationale 16 | 17 | When upgrading the DVM system following [UMIP-173](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-173.md), 18 | the emission rate was initially set to zero. This was done to ensure fair participation when staking UMA tokens at the 19 | VotingV2 contract so that everyone has sufficient time to familiarize themselves with the new system and to ensure that 20 | no one can make outsized returns by staking early. 21 | 22 | The new emission rate of 0.18 UMA per second aims to keep similar growth in total supply as the previous DVM system. 23 | Assuming 100 resolved requests annually (which is approximate to resolved requests in 2022) at current supply of 113M 24 | UMA, the previous system with 0.05% inflation rewards per request would imply 0.18 UMA minted per second. 25 | 26 | Depending on the total amount of UMA staked in the new VotingV2 contract the expected APR for stakers will be as follows: 27 | 28 | | Total UMA staked | Expected APR | 29 | | ---------------- | ------------ | 30 | | 20M | 28% | 31 | | 25M | 23% | 32 | | 30M | 19% | 33 | 34 | Though actual return for individual stakers who vote correctly can be even higher due to redistribution of slashing for 35 | incorrect and missed votes. 36 | 37 | ## Implementation & Technical Specification 38 | 39 | This UMIP proposes a governance transaction that sets the `emissionRate` parameter of the [VotingV2 contract](https://etherscan.io/address/0x004395edb43EFca9885CEdad51EC9fAf93Bd34ac) 40 | to 0.18 UMA scaled by 1e18. 41 | 42 | ## Security considerations 43 | 44 | The new emission rate of 0.18 UMA per second is expected to keep similar growth in total supply as the previous DVM system. 45 | The new emission rate is also expected to be sufficient to incentivize voters to participate in the system. -------------------------------------------------------------------------------- /UMIPs/umip-175.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | 3 | | UMIP-175 | | 4 | | ---------- | -------------------------------------------------------------------------------------- | 5 | | UMIP Title | Revoke minter role for deprecated contracts | 6 | | Authors | Reinis Martinsons (reinis@umaproject.org) | 7 | | Status | Draft | 8 | | Created | March 31, 2023 | 9 | | Discussion | [Discourse](https://discourse.uma.xyz/t/feat-revoke-deprecated-minters/1973) | 10 | 11 | ## Summary 12 | 13 | This UMIP proposes to revoke UMA token minter role for deprecated voting contracts. 14 | 15 | ## Motivation & Rationale 16 | 17 | During each of DVM upgrades the new voting contracts got granted minter role for the UMA voting token while the previous 18 | contracts privileges were not revoked. Even though the minter role is only used to claim rewards, it is still 19 | considered a good security practice to revoke the minter role for deprecated contracts in order to reduce potential 20 | attack surface. 21 | 22 | The only contracts that should retain the minter role are the current VotingV2 contract and the one that was used before 23 | the recent DVM upgrade so that any users with unclaimed rewards can still claim them. 24 | 25 | ## Implementation & Technical Specification 26 | 27 | This UMIP proposes a governance transaction that calls `removeMember(uint256 roleId, address memberToRemove)` method of 28 | the [UMA Voting Token contract](https://etherscan.io/address/0x04Fa0d235C4abf4BcF4787aF4CF447DE572eF828) 29 | with `roleId` set to `1` (`Roles.Minter`) and `memberToRemove` set to the following addresses in multiple transactions: 30 | - `0xFe3C4F1ec9f5df918D42Ef7Ed3fBA81CC0086c5F`: Initial Voting contract. 31 | - `0x9921810C710E7c3f7A7C6831e30929f19537a545`: Voting contract approved in [UMIP-3](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-3.md). 32 | - `0x1d847fB6e04437151736a53F09b6E49713A52aad`: Voting contract approved in [UMIP-15](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-15.md). 33 | 34 | 35 | ## Security considerations 36 | 37 | Removing the minter role for deprecated contracts reduces potential attack surface and is considered a good security 38 | practice. -------------------------------------------------------------------------------- /UMIPs/umip-18.md: -------------------------------------------------------------------------------- 1 | # Headers 2 | | UMIP-18 | | 3 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 4 | | UMIP Title | Add USDC and USDT as whitelisted collateral currencies | 5 | | Authors | Sean Brown (sean@umaproject.org) | 6 | | Status | Approved | 7 | | Created | October 26, 2020 | 8 | 9 | ## Summary (2-5 sentences) 10 | This UMIP will add USDC and USDT as approved collateral currencies. This will involve adding the currencies to the whitelist and adding a flat final fee to charge per-request. The proposed final fee is 400 USDC per request for USDC and 400 USDT per request for USDT. 11 | 12 | ## Motivation 13 | USDT and USDC are the world’s two largest stablecoins by market capitalization as well as traded volume. Both are widely used across the cryptocurrency space, especially on exchanges, where USDC and USDT based crypto-pairs account for a large share of trading volume. 14 | 15 | In comparison to DAI, which is already favored by many in the DeFi community because of its high level of decentralization, USDC and USDT are both fiat-backed stablecoins run by centralized organizations. With centralization comes risk, but the proven success of USDT and USDC, in terms of longevity and size, provide assurance about their ability to maintain value. 16 | 17 | USDC and USDT as collateral types are expected to have a variety of deployments. They will allow for the creation of USD based synthetic assets and will increase the general accessibilty of these assets, as the cryptocurrency market is accustomed to transacting in these currencies. 18 | 19 | ## Technical Specification 20 | To accomplish this upgrade, four changes need to be made: 21 | 22 | - The USDC address, 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48, needs to be added to the collateral currency whitelist introduced in UMIP-8. 23 | - A final fee of 400 needs to be added for USDC in the Store contract. 24 | - The USDT address, 0xdac17f958d2ee523a2206206994597c13d831ec7, needs to be added to the collateral currency whitelist introduced in UMIP-8. 25 | - A final fee of 400 needs to be added for USDT in the Store contract. 26 | 27 | ## Rationale 28 | The rationale behind this change is giving deployers more useful collateral currency options. USDC and USDT are necessary, in addition to the already approved DAI, because of the size of the stablecoin market-share that they own. 29 | 30 | 400 was chosen as the final fee for both USDC and USDT because this is practically equivalent to the final fee of already approved stablecoins. 31 | 32 | ## Implementation 33 | 34 | This change has no implementation other than proposing the four aforementioned governor transactions that will be proposed. 35 | 36 | ## Security considerations 37 | Since USDC and USDT are persistently valuable ERC20 tokens, including both as supported collateral currencies should impose no additional risk to the protocol. 38 | 39 | The main implication is for contract deployers and users who are considering using contracts with USDC or USDT as the collateral currency. They should recognize and accept the centralization risk of using USDC or USDT, as both are fiat-backed or cash-equivalent backed stablecoins run by centralized organizations. USDC is issued and backed by Coinbase and Circle Invest, while USDT is issued and backed by Tether Limited. 40 | 41 | USDT is a non-standard ERC20 as the USDT approve function does not comply with the ERC20 standard. This should not have any immediate security implications, as UMA Protocol contracts use OpenZeppelin's [SafeERC20 wrapper](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/SafeERC20.sol), but should be noted as it *could* have implementation consequences for some financial contracts. 42 | 43 | New price identifiers, that are intended to be used with these collateral currencies, will need to be specified to 6 decimals of precision in order to comply with USDC and USDT. -------------------------------------------------------------------------------- /UMIPs/umip-180.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | 3 | | UMIP-180 | | 4 | | ---------- | ----------------------------------------------------------- | 5 | | UMIP Title | Register Base Parent Messenger in OracleHub and GovernorHub | 6 | | Authors | Pablo Maldonado | 7 | | Status | Approved | 8 | | Created | 03/28/24 | 9 | 10 | ## Summary 11 | 12 | This UMIP proposes to register the [Base Parent Messenger](https://etherscan.io/address/0x721bA6f9A0a44657f008f3d68C6dBdDeDBDE831A) with both the [Oracle Hub](https://etherscan.io/address/0x8fE658AeB8d55fd1F3E157Ff8B316E232ffFF372) and [Governor Hub](https://etherscan.io/address/0x94520d90A4EBaA98e5A7B8D6809463f65198C104) to facilitate cross-chain communication and ensure the operational functionality of newly deployed Base contracts, including the Optimistic Oracle. Additionally, it aims to reduce the default gas limit for transactions on both Optimism and Base Parent Messengers from 5 million to 500,000, thus optimizing network efficiency by correcting previously excessive gas allocations. 13 | 14 | ## Motivation 15 | 16 | The registration of the Base Parent Messenger with the Oracle and Governor Hubs is critical for enabling cross-chain communications, essential for the operation of Optimistic Oracles and governance processes on Base EVM-compatible network. Moreover, the proposed reduction in the default gas limit addresses inefficiencies in bridging resource usage, aligning gas allocations with actual transaction complexity and network capabilities, leading to optimized operation and lower transaction costs. 17 | 18 | ## Technical Specification 19 | 20 | To achieve the goals outlined in this UMIP, the following technical steps will be undertaken: 21 | 22 | - Register the [Base Parent Messenger](https://etherscan.io/address/0x721bA6f9A0a44657f008f3d68C6dBdDeDBDE831A) with the [Oracle Hub](https://etherscan.io/address/0x8fE658AeB8d55fd1F3E157Ff8B316E232ffFF372) and [Governor Hub](https://etherscan.io/address/0x94520d90A4EBaA98e5A7B8D6809463f65198C104). This action enables the Base Parent Messenger to function as a message bridging component in the cross-chain communication infrastructure, facilitating message passing between Base and Mainnet networks. 23 | - Adjust the default gas limit settings for the [Optimism Parent Messenger](https://etherscan.io/address/0x6455D800D1Dbf9B1C3a63c67CcF22B9308728dC4) and [Base Parent Messenger](https://etherscan.io/address/0x721bA6f9A0a44657f008f3d68C6dBdDeDBDE831A) from 5 million to 500,000. This adjustment reflects a more accurate estimation of gas required for typical transactions. 24 | 25 | ## Rationale 26 | 27 | The registration of the Base Parent Messenger with the Oracle and Governor Hubs is a necessary step to ensure the operational functionality of the Optimistic Oracle and governance processes on Base EVM-compatible networks. By enabling cross-chain communication, the Base Parent Messenger can facilitate the transmission of messages between Base and Mainnet networks, supporting the seamless operation of the UMA protocol across multiple chains. 28 | 29 | ## Security Considerations 30 | 31 | The Base Parent Messenger is an instance of the [Optimism _ParentMessenger](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/cross-chain-oracle/chain-adapters/Optimism_ParentMessenger.sol), a contract that has been audited and functioning within UMA's cross-chain infrastructure for several years. The proposed registration of the Base Parent Messenger with the Oracle and Governor Hubs is a standard procedure that has been successfully implemented in previous UMIPs. The gas limit adjustment is a minor optimization that does not introduce new security risks. 32 | 33 | The contracts targeted for registration have undergone thorough auditing. The audit details are available [here](https://blog.openzeppelin.com/uma-audit-phase-6/). 34 | -------------------------------------------------------------------------------- /UMIPs/umip-182.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | 3 | | UMIP-182 | | 4 | | -------------- | -------------------------------------------------------------------------------------------- | 5 | | UMIP Title | Register Blast Parent Messenger in OracleHub and GovernorHub | 6 | | Authors | Reinis Martinsons (reinis@umaproject.org) | 7 | | Status | Approved | 8 | | Created | April 18, 2024 | 9 | | Discourse Link | [UMA's Discourse](https://discourse.uma.xyz/t/umip-182-register-blast-parent-messenger/2117) | 10 | 11 | ## Summary 12 | 13 | This UMIP proposes to register the [Blast Parent Messenger](https://etherscan.io/address/0xe3C52FB4c395165b13f8184644D60357e7D3b995) with both the [Oracle Hub](https://etherscan.io/address/0x8fE658AeB8d55fd1F3E157Ff8B316E232ffFF372) and [Governor Hub](https://etherscan.io/address/0x94520d90A4EBaA98e5A7B8D6809463f65198C104) to facilitate cross-chain communication and ensure the operational functionality of newly deployed Blast contracts, including the Optimistic Oracle. 14 | 15 | ## Motivation 16 | 17 | The registration of the Blast Parent Messenger with the Oracle and Governor Hubs is critical for enabling cross-chain communications, essential for the operation of Optimistic Oracles and governance processes on Blast EVM-compatible network. 18 | 19 | ## Technical Specification 20 | 21 | To achieve the goals outlined in this UMIP, the following technical steps will be undertaken: 22 | 23 | - Register the [Blast Parent Messenger](https://etherscan.io/address/0xe3C52FB4c395165b13f8184644D60357e7D3b995) with the [Oracle Hub](https://etherscan.io/address/0x8fE658AeB8d55fd1F3E157Ff8B316E232ffFF372). 24 | - Register the [Blast Parent Messenger](https://etherscan.io/address/0xe3C52FB4c395165b13f8184644D60357e7D3b995) with the [Governor Hub](https://etherscan.io/address/0x94520d90A4EBaA98e5A7B8D6809463f65198C104). 25 | 26 | These actions enable the Blast Parent Messenger to function as a message bridging component in the cross-chain communication infrastructure, facilitating message passing between Blast and Mainnet networks. 27 | 28 | ## Rationale 29 | 30 | The registration of the Blast Parent Messenger with the Oracle and Governor Hubs is a necessary step to ensure the operational functionality of the Optimistic Oracle and governance processes on Blast EVM-compatible network. By enabling cross-chain communication, the Blast Parent Messenger can facilitate the transmission of messages between Blast and Mainnet networks, supporting the seamless operation of the UMA protocol across multiple chains. 31 | 32 | ## Security Considerations 33 | 34 | The Blast Parent Messenger is an instance of the [Optimism_ParentMessenger](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/cross-chain-oracle/chain-adapters/Optimism_ParentMessenger.sol), a contract that has been audited and functioning within UMA's cross-chain infrastructure for several years. The proposed registration of the Blast Parent Messenger with the Oracle and Governor Hubs is a standard procedure that has been successfully implemented in previous UMIPs. 35 | 36 | The contracts targeted for registration have undergone thorough auditing. The audit details are available [here](https://blog.openzeppelin.com/uma-audit-phase-6/). 37 | -------------------------------------------------------------------------------- /UMIPs/umip-187.md: -------------------------------------------------------------------------------- 1 | | UMIP-187 | | 2 | | ---------- | ----------------------------------------------------------------------------------------------------------------------- | 3 | | UMIP Title | UMA Emissions Reduction #2 | 4 | | Authors | Dylan O’Reilly, Lee Poettcker, Chase Coleman | 5 | | Created | May 5, 2025 | 6 | | Snapshot | [Snapshot](https://snapshot.box/#/s:uma.eth/proposal/0xf7307fe889b65d99acdc9af34acbeeac0dedd5af41665c05c41e877e00333e48)| 7 | | Discussion | [Discourse](https://discourse.uma.xyz/t/uma-emissions-reduction-2/2185) | 8 | 9 | ## Data Report 10 | This is a data report on the effects of the initial UMA Emission Reduction which lowered staking rates from 26.3% APR to 22.6% APR and went into effect on March 11, 2025. For full context, please read the original UMA Emissions Reduction post in UMIP 184: 11 | https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-184.md 12 | 13 | The first emission reduction had no discernable impact on the amount of UMA staked as evidenced by the Voting Power chart at Discourse link above. 14 | 15 | The number of total voters (see chart at Discourse link above) initially spiked after the emission reduction and has been trending downward since. This recent downward trend is not seen in the voting power graph which suggests the voter decline is likely due to small voters leaving after the gas rebate change which required a minimum stake of 500 UMA to be eligible for gas rebates. This change took effect on February 1st, but the first rebate under the new requirements was not paid out until March 13th. So many small voters may not have been aware of the change until mid March. 16 | 17 | A better measure of the effect of the UMA Emission Reduction is to look at the number of addresses voting with over 500 UMA (see chart at Discourse link above). This removes the effect of the gas rebate minimum and only takes into account addresses that have enough stake to meaningfully contribute to UMA’s staking decentralization. Below is a chart of voters with over 500 UMA staked: 18 | 19 | Based on the above data we recommend continuing with the UMA emission plans as laid out in the original proposal. 20 | 21 | ## Voting 22 | A yes vote means that you would like to decrease the emissions rate from 0.155 UMA/s to 0.130 UMA/s. This would lower the staking rewards APR from the current 20% to an estimated 16.8%. 23 | 24 | A no vote means that you would like to keep the emissions rate at 0.155 UMA/s 25 | -------------------------------------------------------------------------------- /UMIPs/umip-25.md: -------------------------------------------------------------------------------- 1 | # Headers 2 | | UMIP-25 | | 3 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 4 | | UMIP Title | Add GASETH-FEB21 and GASETH-MAR21 as supported DVM price identifiers | 5 | | Authors | Feddas 6 | | Status | Approved | 7 | | Created | December 10th, 2020 | 8 | 9 | ## Summary (2-5 sentences) 10 | This UMIP will reference a synthetic token to be created with this price identifier. This token will be referred to as 'uGAS' and will represent the token that tracks this identifier with the most ETH volume on Uniswap unless a different contract is determined by voters to be more legitimate. 11 | 12 | The DVM should support requests for a price that resolves to either the median monthly Ethereum gas price or a 2-hour Time-Weighted Average Price (TWAP) on the highest volume Uniswap ETH/uGAS pool. The price resolution method to use will depend on the the timestamp the price request was made at. 13 | 14 | #### Identifier GASETH-FEB21: 15 | 16 | For a price request made at or after the Unix timestamp `1614556800` (March 1, 2021 00:00:00 UTC), the price will be resolved with the median monthly gas price calculation defined for GASETH-1M-1M in UMIP-20. 17 | 18 | For a price request made before `1614556800`, the price will be resolved to a 2-hour TWAP for the Uniswap price of the listed synthetic token in ETH. The synthetic token address will be listed in the Technical Specification section. 19 | 20 | #### Identifier GASETH-MAR21: 21 | 22 | For a price request made at or after the Unix timestamp `1617235200` (April 1, 2021 00:00:00 UTC), the price will be resolved with the median monthly gas price calculation defined for GASETH-1M-1M in UMIP-20. 23 | 24 | For a price request made before `1617235200`, the price will be resolved to a 2-hour TWAP for the Uniswap price of the listed synthetic token in ETH. The synthetic token address will be listed in the Technical Specification section. 25 | 26 | ## Motivation 27 | The motivation for these price identifiers is explained in [umip-22](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-22.md). 28 | 29 | ## Technical Specification 30 | Technical specifications are the same as in [umip-22](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-22.md) except: 31 | - Identifier name: GASETH-FEB21 and GASETH-MAR21 32 | - Scaling Decimals: 18 (1e18) 33 | 34 | ## Rationale 35 | Please reference the Rationale section in [umip-22](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-22.md) for a full walkthrough of the rationale behind calculating aggregatory gas prices. 36 | 37 | ## Implementation 38 | Implementation is the same as in [umip-22](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-22.md) except the time stamps are adjusted for each identifier according to: 39 | 40 | Identifier GASETH-FEB21: Unix timestamp `1614556800` (March 1, 2021 00:00:00 UTC) 41 | 42 | Identifier GASETH-MAR21: Unix timestamp `1617235200` (April 1, 2021 00:00:00 UTC) 43 | 44 | ## Security considerations 45 | Please reference the security considerations section in [umip-22](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-22.md) 46 | -------------------------------------------------------------------------------- /UMIPs/umip-27.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-27 | | 3 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 4 | | UMIP Title | Approve Patched EMP Financial Contract Template | 5 | | Authors | Matt Rice (matt@umaproject.org) | 6 | | Status | Approved | 7 | | Created | December 14, 2020 | 8 | 9 | ## Summary 10 | This UMIP will have the effect of introducing an updated ExpiringMultiParty contract template that matches the one introduced in UMIP-14, but with [this](https://github.com/UMAprotocol/protocol/pull/2203) bug fix. 11 | 12 | ## Motivation & Rationale 13 | 14 | This UMIP was motivated by a bug report that revealed that the liveness-reset feature introduced in UMIP-14 did not work as intended due to a reversed inequality. 15 | 16 | ## Technical Specification 17 | To accomplish this upgrade, a new financial contract template must be deployed. 18 | 19 | Deployment address: https://etherscan.io/address/0xB3De1e212B49e68f4a68b5993f31f63946FCA2a6. 20 | 21 | After deployment, this new `ExpiringMutltiPartyCreator` contract should be approved as a ContractCreator in the Registry. 22 | 23 | Note: the voters only vote for the approval -- the deployment has no effect on the protocol until added as a ContractCreator. 24 | 25 | ## Implementation 26 | 27 | Please see this [directory](https://github.com/UMAprotocol/protocol/tree/master/core/contracts/financial-templates/expiring-multiparty). The directory contains both the [implementation](https://github.com/UMAprotocol/protocol/blob/master/core/contracts/financial-templates/expiring-multiparty/ExpiringMultiParty.sol) of the `ExpiringMultiParty` template and the [deployer contract](https://github.com/UMAprotocol/protocol/blob/master/core/contracts/financial-templates/expiring-multiparty/ExpiringMultiPartyCreator.sol) that will be registered with the DVM to allow users to deploy their own `ExpiringMultiParty` contract. 28 | 29 | The only change included in this deployment is this PR: https://github.com/UMAprotocol/protocol/pull/2203. 30 | 31 | ## Security considerations 32 | 33 | This patch is in the process of being audited. 34 | -------------------------------------------------------------------------------- /UMIPs/umip-36.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-36 | | 3 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 4 | | UMIP Title | Add Dynamic Set Dollar as a collateral currency | 5 | | Authors | John (dsdravage@gmail.com), Sean (sean@opendao.io) | 6 | | Status | Approved | 7 | | Created | January 13, 2021 | 8 | 9 | ## Summary (2-5 sentences) 10 | This UMIP will add DSD to the supported collateral currencies into the global whitelist contract, allowing the usage of DSD as collateral currency. 11 | 12 | ​ 13 | ## Motivation 14 | Dynamic Set Dollar (DSD) is a fast growing algorithmic stablecoin. DSD has a current market capitalization of $128 million & $28.7 million in liquidity. The volume since inception (under two months) has exceeded $444 million at the time of this writing. 15 | 16 | The motivation of adding DSD as a supported collateral in the global whitelist contract is so that DSD holders can go long on DSD by minting a stablecoin backed by DSD as collateral, which will be built on UMA. 17 | 18 | DSD holders would supply tokens to the OpenDAO Platform as a collateral asset to mint DSDO via underlying UMA contracts and use the minted DSDO elsewhere. DSDO being a synthetic asset that traces the value of USD. Once users of the DSDO token want their locked DSD collateral back they would bring DSDO back to the OpenDAO platform, settle any fees/interest and reclaim DSD tokens. A DSDO/USDC pool will be created via uniswap & sushiswap for easy access into other markets using DSDO. 19 | 20 | ​ 21 | ​ 22 | ## Technical Specification 23 | To accomplish this upgrade, two changes need to be made: 24 | - The DSD address, [0xBD2F0Cd039E0BFcf88901C98c0bFAc5ab27566e3](https://etherscan.io/token/0xBD2F0Cd039E0BFcf88901C98c0bFAc5ab27566e3), needs to be added to the collateral currency whitelist introduced in UMIP-8. 25 | - A final fee of 600 DSD needs to be added for the DSD in the Store contract. 26 | 27 | _Note:-_ 28 | 29 | Dynamic Set Dollar is not a rebase token. The “expansion” only goes to users who have tokens bonded (staked) in the dao or to liquidity providers who have bonded the lp tokens to the app. The tokens are claimed through the website [dsd.finance](https://dsd.finance). The contractions are voluntary. Users burn their tokens for coupons that promise a premium when the price returns to peg. The coupons expire if not redeemed in 30 days. 30 | 31 | ​ 32 | ​ 33 | ## Rationale 34 | ​ 35 | The rationale behind this change is that it fits into a larger goal of getting adoption of UMA protocol by allowing DSD’s token (DSD) to be used as collateral, where DSD’s projects with partners (such as OpenDAO) can leverage the UMA protocol. 36 | 37 | 38 | ​ 39 | ​ 40 | ## Implementation 41 | ​ 42 | This change has no implementation other than adding the DSD token address to the collateral currency whitelist. 43 | 44 | ​ 45 | ## Security Considerations 46 | ​ 47 | Dynamic Set Dollar is designed to have cycles. During the "debt" cycle (twap<1.00) DSD may significantly lose value temporarily. As the cycles continue the amplitude of each debt cycle will minimize untill the peg of 1.00 is bootstrapped. 48 | The other cycle of DSD is the expansion cycle, users bonded (staked) to dsd.finance and the DAO contract will be minting tokens up to 2% of the total supply every epoch. This requires a price point of $1.50 as the supply grows the expansions overtime will also be much smaller and sustainable. 49 | 50 | -------------------------------------------------------------------------------- /UMIPs/umip-43.md: -------------------------------------------------------------------------------- 1 | # Headers 2 | | UMIP-43 | | 3 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 4 | | UMIP Title | Add Ocean as a collateral currency | 5 | | Authors | Logan (logan@opendao.io) | 6 | | Status | Approved | 7 | | Created | January 28, 2021 | 8 | | Created | January 28, 2021 | 9 | |Link to Discourse| https://discourse.umaproject.org/t/adding-ocean-as-collateral-umip/117 | 10 | 11 | ## Summary (2-5 sentences) 12 | This UMIP will add Ocean to the supported collateral currencies on the global whitelist contract, allowing the usage of Ocean as collateral currency. 13 | 14 | ## Motivation 15 | The motivation of adding Ocean as a supported collateral in the global whitelist contract is so that Ocean holders can go long on Ocean by minting a stablecoin backed by Ocean as collateral, which will be built on UMA. 16 | 17 | The Ocean token is used to stake on data, to govern Ocean community funding, and to buy & sell data. Ocean and the smart contracts for Ocean functionality are deployed to Ethereum mainnet, and to further networks over time. 18 | 19 | The supply of Ocean is capped at 1.41 billion tokens. 51% of this supply is disbursed according to a Bitcoin-like schedule over decades, to fund community projects curated by OceanDAO. At the time of writing, the Ocean token market cap is $243,700,423 with a 24-hour trading volume of $137,565,116. 20 | 21 | Ocean holders would supply tokens to the OpenDAO Platform as a collateral asset to mint OceanO via underlying UMA contracts and use the minted OceanO further on the OpenDAO platform or elsewhere, OceanO being a synthetic asset that traces the value of USD. Once users of the OceanO token want their locked Ocean collateral back, they would bring OceanO back to the OpenDAO platform, settle any fees/interest, and reclaim Ocean tokens. An OceanO/USDC pool will be created via uniswap for easy access into other markets using OceanO. 22 | 23 | ## Technical Specification 24 | To accomplish this upgrade, two changes need to be made: 25 | - The Ocean address, [0x967da4048cD07aB37855c090aAF366e4ce1b9F48](https://etherscan.io/token/0x967da4048cD07aB37855c090aAF366e4ce1b9F48), 26 | needs to be added to the collateral currency whitelist introduced in UMIP-8. 27 | - A final fee of 1000 Ocean needs to be added for the Ocean in the Store contract. 28 | 29 | ## Rationale 30 | ​ 31 | The rationale behind this change is that it fits into a larger goal of furthering adoption of the UMA protocol by allowing Ocean tokens to be used as collateral, where Ocean’s projects with partners (such as OpenDAO) can leverage the UMA protocol. 32 | 33 | ## Implementation 34 | ​ 35 | This change has no implementation other than the changes listed in the *Technical Specification* section. 36 | 37 | ## Security Considerations 38 | ​ 39 | In the current setting, there will need to be a significant event that erodes confidence in OceanDAO and the token for it to be a security or PR concern. We expect the distribution of Ocean to increase over time as Ocean Protocol expands its efforts, and then more price feeds can be incorporated. 40 | -------------------------------------------------------------------------------- /UMIPs/umip-48.md: -------------------------------------------------------------------------------- 1 | # Headers 2 | | UMIP-48 | | 3 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 4 | | UMIP Title | Add GASETH_JUN21 as a supported price identifier | 5 | | Authors | nonstopTheo (nonstoptheo@yam.finance) 6 | | Status | Approved | 7 | | Created | February 10th, 2021 | 8 | | Link to Discourse| https://discourse.umaproject.org/t/umip-48-add-gaseth-jun21-as-a-supported-price-identifier/217 9 | 10 | ## SUMMARY 11 | This UMIP will reference a synthetic token to be created with this price identifier. This token will be referred to as 'uGAS' and will represent the token that tracks this identifier with the most ETH volume on Uniswap unless a different contract is determined by voters to be more legitimate. 12 | 13 | This follows the exact same process as UMIP-22 but uses a different timestamp. 14 | 15 | The DVM should support requests for a price that resolves to either the median monthly Ethereum gas price or a 2-hour Time-Weighted Average Price (TWAP) on the highest volume Uniswap ETH/uGAS pool. The price resolution method to use will depend on the the timestamp the price request was made at. 16 | 17 | For a price request made at or after the Unix timestamp `1625097600` (July 1, 2021 00:00:00 UTC), the price will be resolved with the median monthly gas price calculation defined for GASETH-1M-1M in UMIP-20. 18 | 19 | For a price request made before `1625097600`, the price will be resolved to a 2-hour TWAP for the Uniswap price of the listed synthetic token in ETH. The synthetic token address will be listed in the Technical Specification section. 20 | 21 | 22 | ## MOTIVATION 23 | The motivation for these price identifiers is explained in [umip-22](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-22.md). 24 | 25 | 26 | # MARKETS & DATA SOURCES 27 | 28 | Please refer to [umip-22](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-22.md). 29 | 30 | 31 | # PRICE FEED IMPLEMENTATION 32 | 33 | To further explain the price feed implementation beyond what is stated in [umip-22]: The price feed being used is the Uniswap price feed and only the Uniswap TWAP calculation will need to be queried in real-time. The Uniswap price feed is referenced [here](https://github.com/UMAprotocol/protocol/blob/master/packages/financial-templates-lib/src/price-feed/UniswapPriceFeed.js). 34 | 35 | 36 | # TECHNICAL SPECIFICATIONS 37 | 38 | **1. Price Identifier Name** - GASETH_JUN21 39 | 40 | **2. Base Currency** - uGAS 41 | 42 | **3. Quote currency** - ETH 43 | 44 | **4. Intended Collateral Currency** - WETH 45 | 46 | **5. Scaling Decimals** - 18 (1e18) 47 | 48 | **6. Rounding** - Round to nearest 6 decimal places (seventh decimal place digit >= 5 rounds up and < 5 rounds down) 49 | 50 | # IMPLEMENTATION 51 | The identifier requires updated timestamps. 52 | 53 | For a price request made at or after the Unix timestamp `1625097600` (July 1, 2021 00:00:00 UTC), the price will be resolved with the median monthly gas price calculation defined for GASETH-1M-1M in UMIP-20. 54 | 55 | For a price request made before `1625097600`, the price will be resolved to a 2-hour TWAP for the Uniswap price of the listed synthetic token in ETH. The synthetic token address will be listed in the Technical Specification section. 56 | 57 | Updated rounding: 6 decimals 58 | 59 | # Security considerations 60 | 61 | Please reference the security considerations section in [umip-22](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-22.md) 62 | -------------------------------------------------------------------------------- /UMIPs/umip-52.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-52 | | 3 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 4 | | UMIP Title | Add Optimistic Oracle | 5 | | Authors | John Shutt (john@umaproject.org) | 6 | | Status | Approved | 7 | | Created | February 16, 2021 | 8 | 9 | ## Summary (2-5 sentences) 10 | This UMIP will have the effect of introducing a new optimistic oracle contract that will allow optimistic settlement of prices and funding rates without a vote from the DVM. This will reduce the number of votes required from the DVM and is a pre-requisite for use of the new Perpetual (UMIP-53) and EMP (UMIP-54) contracts. 11 | 12 | ## Motivation 13 | Prior to addition of the optimistic oracle, every expiring multi-party contract would require a vote from the DVM to establish a final settlement price. The optimistic oracle allows for optimistic settlement of expiring contracts with a liveness window for disputes, similar to how liquidations and withdrawals happen today. The optimistic oracle also allows for optimistic proposals of funding rates, allowing the implementation of a perpetual contract that does not expire. 14 | 15 | ## Technical Specification 16 | To accomplish this upgrade, a few actions will need to be taken: 17 | - A new `OptimisticOracle` contract will need to be deployed. Once deployed, the contract address will be added to this UMIP. 18 | - A transaction will need to be proposed to add this new address to the `Finder` contract under the name `“OptimisticOracle”`. This is how other contracts will find the optimistic oracle and reference it. 19 | - The `OptimisticOracle` will need to be registered with the `Registry` so that it can make requests to the DVM. 20 | 21 | Note: this change will only create the optimistic oracle. New financial contracts that utilize the optimistic oracle will need to be deployed for it to become useful. Until all steps above are performed, the deployed OptimisticOracle _should not_ be used in production since it will not be able to raise disputes to the DVM. 22 | 23 | ## DVM Upgrade 24 | 25 | - For the optimistic oracle to be compatible with the DVM, the DVM will need to be upgraded to handle ancillary data (UMIP-55). 26 | 27 | ## Rationale 28 | 29 | This new contract allows the optimistic settlement of prices, reducing the number of DVM votes required for expiring multi-party contracts. It also allows for funding rate proposals, a pre-requisite for perpetual multi-party contracts. 30 | 31 | ## Implementation 32 | 33 | The `OptimisticOracle` contract can be found [here](https://github.com/UMAprotocol/protocol/blob/master/packages/core/contracts/oracle/implementation/OptimisticOracle.sol). It has been audited and will require no changes. 34 | 35 | The mainnet contract address: 36 | 37 | *OptimisticOracle* - https://etherscan.io/address/0x287a1ba52e030459f163f48b2ae468a085003a07 38 | 39 | 40 | ## Security considerations 41 | Please see the individual PRs for details on how each affects the security of the UMA ecosystem. This repo has been audited by OpenZeppelin, and the final audit report can be reviewed [here](https://blog.openzeppelin.com/uma-audit-phase-4/) 42 | 43 | This contract introduces the idea of a DVM trial because Optimistic Oracle users don't need to be explicitly registered with the DVM. Users of the Optimistic Oracle are encouraged to pay fees to the store as approved contracts do. However, they are also able to use the Optimistic Oracle without doing so on a trial basis. Each contracts' requests are distinguished at the DVM-level so the voters _can_ choose to reject requests if contracts are abusing this trial. The voters are expected to develop a consensus off-chain about what acceptable trial usage, but user contracts should be aware that using the Optimistic Oracle without paying fees and following DVM rules will be subject them to the voters' trial terms. 44 | -------------------------------------------------------------------------------- /UMIPs/umip-60.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | - UMIP-60 3 | - UMIP title: Approve ANT as a collateral currency 4 | - Author Chandler De Kock (chandler@umaproject.org) and Joseph Charlesworth (joe@aragon.org) 5 | - Status: Approved 6 | - Created: March 2, 2021 7 | - Discourse Link: 8 | 9 | ## Summary (2-5 sentences) 10 | Aragon Association would like to propose adding ANT as a collateral type to UMA Protocol in order to be able create KPI options for the Aragon community. The first step in this process involves adding ANT as a collateral type. The second step will involve establishing a suitable KPI in conjunction with the Aragon community for use in the KPI option. 11 | 12 | ## Motivation 13 | Adding ANT as a collateral type is required in order to be able to create a KPI option, collateralised by ANT. We see these as a sophisticated method to grow the Aragon community in conjunction with mutually agreed KPIs with ANT holders. 14 | 15 | Aragon is one of the market leaders in decentralised governance technology software. Products includes Aragon client to build and manage DAOs, enterprise voting solutions for companies and governments and APIs to embed voting solutions into custom applications. Over 1,700 DAOs are powered by Aragon with over $650m of funds stored and over $1bn secured by Aragon smart contracts. As the native token of the Aragon network, ANT is used in governance votes for protocol upgrades and is staked by jurors in Aragon Court. Should the KPI options for the Aragon Network DAO be successful, we expect many other Aragon DAOs to follow suit with their own proposals for KPI options using UMA to grow their own communities. Besides the immediate KPI proposal, we're also keen on exploring the development of a synthetic index using UMA to track the global performance of all Aragon DAO tokens. 16 | 17 | ## Technical Specification 18 | To accomplish this upgrade, two changes need to be made: 19 | 20 | - The ANT address, 0xa117000000f279d81a1d3cc75430faa017fa5a2e, needs to be added to the collateral currency whitelist introduced in UMIP-8. 21 | - A final fee of 120 ANT needs to be added in the Store contract. This is approximately $600 at current ANT rates. 22 | 23 | ## Rationale 24 | Adding ANT as collateral to UMA protocol is a pre-requisite to being able to use ANT as collateral in a KPI options contract. 25 | 26 | ## Implementation 27 | This change has no implementation other than proposing the aforementioned governance transaction that will be proposed. 28 | 29 | ## Security considerations 30 | Adding ANT as a collateral does not present any major foreseeable risks to the protocol. 31 | 32 | The main implication is for contract deployers and users who are considering using contracts with ANT as the collateral currency. They should recognise and accept the volatility risk of using this asset, and ensure appropriate required collateralization ratios, as well as a network of liquidator and support bots to ensure solvency. 33 | -------------------------------------------------------------------------------- /UMIPs/umip-63.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-63 | | 3 | |------------|---| 4 | | UMIP Title | Add INDEX & DPI as collateral | 5 | | Authors | Gottlieb Freudenreich (gottlieb.freudenreich@gmail.com) 6 | | Status | Approved | 7 | | Created | 2020-03-08 | 8 | | Discourse Link | https://discourse.umaproject.org/t/add-index-and-dpi-as-collateral/326 9 | 10 | # Summary 11 | 12 | This UMIP will add INDEX and DPI to the supported collateral currencies on the global whitelist contract, allowing the usage of these 2 assets as collateral currencies. 13 | More information on INDEX and DPI can be found on the website: https://www.indexcoop.com/ 14 | 15 | # Proposed Collateral Currencies 16 | 17 | ## INDEX (Index Cooperative Token) 18 | ### Motivation 19 | 20 | INDEX is the governance token which presides over the Index Cooperative the curater of the DeFi Pulse Index. 21 | The Index Cooperative has $130 million TVL and could utilize its governance token and/or treasury funds as collateral within the UMA ecosystem. 22 | 23 | 24 | ### Technical Specification 25 | To accomplish this upgrade, two changes need to be made: 26 | 27 | * The INDEX address, [0x0954906da0bf32d5479e25f46056d22f08464cab][index], needs to be added to the collateral currency whitelist introduced in UMIP-8. 28 | * A final fee of 24 INDEX needs to be added for the INDEX in the Store contract. (~$414 at time of writing) 29 | 30 | [index]: https://etherscan.io/token/0x0954906da0Bf32d5479e25f46056d22f08464cab 31 | 32 | --- 33 | 34 | ## DPI (DeFi Pulse Index Token) 35 | ### Motivation 36 | 37 | The DeFi Pulse Index is a digital asset index designed to track the performance of token within the Decentralized Finance industry. The index is weighted based on the value of each token’s circulating supply. 38 | The DPI Set is rebalanced monthly to realign to its market cap weighted index. As the index provides a broad exposure to different DeFi tokens there is plenty of potential to utilize DPI as collateral within the UMA ecosystem. 39 | Tokens within the DPI have been approved as collateral by e.g. UMIP 56. 40 | 41 | ### Technical Specification 42 | 43 | To accomplish this upgrade, two changes need to be made: 44 | 45 | * The DPI address, [0x1494ca1f11d487c2bbe4543e90080aeba4ba3c2b][dpi], needs to be added to the collateral currency whitelist introduced in UMIP-8. 46 | * A final fee of 1 DPI needs to be added for the DPI in the Store contract. (~$466 at time of writing) 47 | 48 | [dpi]: https://etherscan.io/token/0x1494CA1F11D487c2bBe4543E90080AeBa4BA3C2b 49 | 50 | --- 51 | 52 | ## Rationale 53 | The rationale behind this change is giving deployers more useful collateral currency options. This is an advancement into a new types of collateral and would allow DPI and INDEX holders to create options and synthetic assets within the UMA ecosystem. 54 | 55 | 24 INDEX and 1 DPI have been chosen as a $400 USD equivalent for the final fee because it is equal to or above the mimimum of already approved collateral. 56 | 57 | ## Implementation 58 | 59 | This change has no implementation other than proposing the two aforementioned governance transactions that will be proposed. 60 | 61 | ### Security Considerations 62 | 63 | Since the underlying tokens are persistently valuable tokens, including the token should impose no additional risk to the protocol. 64 | 65 | If a single token inside the DPI experiences extrem volatility (e.g. goes to 0), the DPI value would drop by the value of that token within DPI. 66 | 67 | The main implication is for contract deployers and users who are considering using contracts with these assets as the collateral currency. They should recognize and accept the volatility risk of using this, and ensure appropriate required collateralization rations (140%+), as well as a network of liquidator and support bots to ensure solvency. 68 | 69 | The DPI Token was created by the DeFI Pulse Index team on top of the Set Protocol. There is the theoretical risk that the underlying smart contracts get exploited which leads to a rapid loss of value in the currency proposed here which would require fast response to ensure solvency for any financial products built using this as a collateral type. -------------------------------------------------------------------------------- /UMIPs/umip-66.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-66 | | 3 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 4 | | UMIP Title | Add USDBTC_18DEC, BCHNBTC_18DEC, ELASTIC_STABLESPREAD/USDC_18DEC, STABLESPREAD/USDC_18DEC, STABLESPREAD/BTC_18DEC and AMPLUSD_18DEC as supported price identifiers | 5 | | Authors | Sean Brown (@smb2796) | 6 | | Status | Approved | 7 | | Created | March 10, 2021 | 8 | | [Discourse Link](https://discourse.umaproject.org/t/propose-v2-pids-for-all-depreciated-pis/336) | | 9 | 10 | 11 | ## Summary (2-5 sentences) 12 | 13 | This UMIP proposes adding USDBTC_18DEC, BCHNBTC_18DEC, ELASTIC_STABLESPREAD/USDC_18DEC, STABLESPREAD/USDC_18DEC, STABLESPREAD/BTC_18DEC, AMPLUSD_18DEC as supported price identifiers. 14 | 15 | ## Motivation 16 | 17 | With the introduction of the new EMP template proposed in UMIP-52, all price identifiers are required to be scaled by 10^18 when submitted on-chain. This is in contrast to the function in old EMP contracts, where the price identifier needed to be scaled to match the scaling factor of the collateral currency that the identifier was being used with. This means that price identifiers that are being used in an old EMP contract that has a non-18 decimal collateral currency cannot be used with the new contracts. 18 | 19 | Because of this, many price identifiers have been deprecated. This UMIP simply reproposes those price identifiers with slightly altered price identifier names and a scaling specification of 18 decimals. Everything else about these identifiers remains the same. The intention is that these price identifiers only be used while the original price identifiers are still deprecated. If the original price identifiers are at any point able to be used again, those should once again become the canonical price ids. 20 | 21 | ## Technical Specifications 22 | 23 | Voters should refer to the rationale, technical specifications, implementations and security considerations in each corresponding UMIP. The only change to the implemenentations of these price identifiers are that these should all be scaled 10^18. Voters currently do not have to adjust results for any sort of scaling when voting through the UMA voter dapp, so the result that a voter would input for one of these price ids would be exactly the same as for the deprecated identifiers. 24 | 25 | The price identifier pairings are as follows. 26 | 27 | | New Identifier | Old Identifier | UMIP | 28 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| --------------| 29 | | USDBTC_18DEC | USDBTC | [UMIP-7](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-7.md) | 30 | | BCHNBTC_18DEC | BCHNBTC | [UMIP-23](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-23.md) | 31 | | ELASTIC_STABLESPREAD/USDC_18DEC | ELASTIC_STABLESPREAD/USDC | [UMIP-30](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-30.md) | 32 | | STABLESPREAD/USDC_18DEC | STABLESPREAD/USDC | [UMIP-31](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-31.md) | 33 | | STABLESPREAD/BTC_18DEC | STABLESPREAD/BTC | [UMIP-31](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-31.md) | 34 | | AMPLUSD_18DEC | AMPLUSD | [UMIP-33](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-33.md) | 35 | 36 | -------------------------------------------------------------------------------- /UMIPs/umip-67.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-67 | | 3 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 4 | | UMIP Title | Add SUSHI and xSUSHI as approved collateral currencies | 5 | | Authors | Sean Brown (@smb2796) | 6 | | Status | Approved | 7 | | Created | March 10, 2021 | 8 | | [Discourse Link](https://discourse.umaproject.org/t/add-sushi-and-xsushi-as-collateral-types/335) | | 9 | 10 | ## Summary (2-5 sentences) 11 | This UMIP will add Sushi and xSushi as approved collateral currencies. This will involve adding these to the whitelist and adding a flat final fee to charge per-request. The proposed final fee is 25 SUSHI and 22 xSUSHI per request. 12 | 13 | ## Motivation 14 | 15 | SUSHI and xSUSHI are both ERC-20 tokens used by the SushiSwap community. SUSHI is the governance token of SushiSwap and is also used for staking. When SUSHI holders stake SUSHI, they receive xSUSHI in return. Each xSUSHI is thus exchangeable for a certain amount of staked SUSHI tokens. 16 | 17 | Adding SUSHI and xSUSHI as collateral types will allow for a variety of contract deployments. These could be used with the SUSHI/xSUSHI price identifiers that are also being proposed, to create SUSHI/xSUSHI backed yield dollars, or SUSHI/xSUSHI covered calls. 18 | 19 | ## Technical Specification 20 | To accomplish this upgrade, two changes for each currency need to be made: 21 | 22 | ### SUSHI 23 | - The SUSHI address, [0x6B3595068778DD592e39A122f4f5a5cF09C90fE2](https://etherscan.io/address/0x6b3595068778dd592e39a122f4f5a5cf09c90fe2), needs to be added to the collateral currency whitelist introduced in UMIP-8. 24 | - A final fee of 25 needs to be added for SUSHI in the Store contract. 25 | 26 | ### xSUSHI 27 | - The xSUSHI address, [0x8798249c2E607446EfB7Ad49eC89dD1865Ff4272](https://etherscan.io/address/0x8798249c2E607446EfB7Ad49eC89dD1865Ff4272), needs to be added to the collateral currency whitelist introduced in UMIP-8. 28 | - A final fee of 22 needs to be added for xSUSHI in the Store contract. 29 | 30 | ## Rationale 31 | 32 | The rationale behind this change is giving deployers more useful collateral currency options. 33 | 34 | 25 was chosen as the final fee for SUSHI, because this is approximately ~$500 at current SUSHI prices whcih is approximately equivalent to other collateral currencies. A slightly lower xSUSHI final fee of 22 was chosen, because xSUSHI will always trade slightly higher than SUSHI and this results in the same approximate dollar value. 35 | 36 | ## Implementation 37 | 38 | This change has no implementation other than the two aforementioned governor transactions that will be proposed. 39 | 40 | ## Security considerations 41 | 42 | The only security implication is for contract deployers and users who are considering using EMP contracts with SUSHI or xSUSHI as collateral currencies. Contract deployers and users of SUSHI and xSUSHI should be aware that these are both volatile currencies and sponsors should take care to keep their positions over-collateralized when using these. 43 | 44 | Since xSUSHI primarily functions as a SUSHI LP token, it does not have many liquid markets available. Contract creators should be aware that it could be more difficult for liquidators to get xSUSHI when needed. 45 | -------------------------------------------------------------------------------- /UMIPs/umip-72.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-72 | | 3 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 4 | | UMIP Title | Add BAL as approved collateral currency | 5 | | Authors | Mhairi McAlpine (mhairi@umaproject.org | 6 | | Status | Approved | 7 | | Created | March 30, 2021 | 8 | | [Discourse Link](https://discourse.umaproject.org/t/add-bal-as-approved-collateral-currency/510) | | 9 | 10 | ## Summary (2-5 sentences) 11 | This UMIP will add BAL as an approved collateral currency. This will involve adding BAL to the whitelist and adding a flat final fee to charge per-request. The proposed final fee is 8 BAL per request. 12 | 13 | ## Motivation 14 | 15 | BAL is an ERC20 token which is used for governance by the Balancer Protocol. It can be used to vote on proposals and steer the direction of the protocol. 16 | 17 | Adding BAL as a collateral type will allow for a variety of contract deployments. These could be used with the BAL/USD price identifiers that are also being proposed, to create BAL backed yield dollars, or BAL covered calls. 18 | 19 | ## Technical Specification 20 | To accomplish this upgrade, two changes for each currency need to be made: 21 | 22 | - The BAL address, [0xba100000625a3754423978a60c9317c58a424e3d](https://etherscan.io/address/0xba100000625a3754423978a60c9317c58a424e3d), needs to be added to the collateral currency whitelist introduced in UMIP-8. 23 | - A final fee of 8 needs to be added for BAL in the Store contract. 24 | 25 | 26 | ## Rationale 27 | 28 | The rationale behind this change is giving deployers more useful collateral currency options. 29 | 30 | 8 was chosen as the final fee for BAL, because this is approximately ~$400 at current BAL prices whcih is approximately equivalent to other collateral currencies. 31 | 32 | ## Implementation 33 | 34 | This change has no implementation other than the two aforementioned governor transactions that will be proposed. 35 | 36 | ## Security considerations 37 | 38 | Adding BAL as a collateral does not present any major foreseeable risks to the protocol. 39 | 40 | The main implication is for contract deployers and users who are considering using contracts with BAL as the collateral currency. They should recognize and accept the volatility risk of using this asset, and ensure appropriate required collateralization ratios, as well as a network of liquidators and support bots to ensure solvency. 41 | 42 | -------------------------------------------------------------------------------- /UMIPs/umip-75.md: -------------------------------------------------------------------------------- 1 | # Headers 2 | 3 | | UMIP-75 | | 4 | | ---------- | ----------------------------------- | 5 | | UMIP Title | Add bDigg as a collateral currency | 6 | | Authors | Sean Brown (@smb2796) | 7 | | Status | Approved | 8 | | Created | April 7, 2021 | 9 | | [Discourse](https://discourse.umaproject.org/t/add-bdigg-as-a-collateral-currency/854) | 10 | 11 | ## Summary 12 | 13 | This UMIP will add bDigg, the BadgerDAO DIGG vault LP token, as an approved collateral currency. 14 | 15 | This will involve adding it to the whitelist and adding a flat final fee to charge per-request. The proposed final fee is 0.016 bDigg per request. 16 | 17 | View [here](https://badgerdao.medium.com/sett-vault-user-guide-9040b2f4b7a4) for an overview of Badger DAO's Setts Vaults 18 | 19 | ## Motivation 20 | 21 | BadgerDAO’s first product is Sett vault, an automated DeFi aggregator focused on tokenized BTC assets. Users that tokenized Bitcoin in our vaults receive a corresponding “b” denominated token in return that represents their vault position. Unfortunately these vault positions then become illiquid. 22 | 23 | Many of BadgerDAO's users would like to borrow against their BTC vault positions as collateral to mint Badger Dollars. At the time of writing, Badger’s Sett Vaults have brought in over 1b in TVL. To allow synthetic tokens created with the EMP to take advantage of this liquidity, bwBTC/ETH SLP and bBadger have already been added as whitelisted collateral types and bDigg is a logical next addition. See below for a description of bDigg. 24 | 25 | - **bBadger** 26 | - Digg tokens are staked in the Badger Sett Vault to mint bDigg token(s) 27 | - View [here](https://etherscan.io/address/0x7e7e112a68d8d2e221e11047a72ffc1065c38e1a) for the associated token address 28 | 29 | 30 | bDigg as collateral is expected to have a variety of deployments. The timing for adding it now, and the immediate application, is for use with a USD/bDiggwhich will enable the creation of another type of Badger Dollar, a yield dollar token. 31 | 32 | **Note** - 'b' tokens are implemented as upgradeable proxy contracts. All governance functions are currently controlled via a multisig by the core Badger Team. 33 | 34 | ## Technical Specification 35 | 36 | To accomplish this upgrade, the following changes need to be made: 37 | 38 | - The bDigg address, 0x7e7e112a68d8d2e221e11047a72ffc1065c38e1a, needs to be added to the collateral currency whitelist 39 | - A final fee of 0.016 needs to be added in the Store contract (~$400 at time of writing) 40 | 41 | ## Rationale 42 | 43 | With $20m in illiquid Digg assets locked in the Digg vault, the ability to use these as collateral to borrow Badger Dollars reopens the possibilities of participating in open finance. In combination with the bDigg/USD price identifier which is also being proposed, bDigg could be used to create call options on the bDigg token price. 44 | 45 | ## Implementation 46 | 47 | This change has no implementation other than the aforementioned governor transactions. 48 | 49 | ## Security considerations 50 | 51 | Digg is an elastic supply rebasing token that is intended to track the price of Bitcoin by adjusting the supply of Digg. Because of the rebasing mechanism, the price of Digg (and bDigg) can be prone to large amounts of volatility. The bDigg supply is not elastic in the same way as DIGG. 52 | 53 | To read more about this, view the Digg explainer [here](https://badger.finance/digg). Contract deployers and users should take care to adjust contract parameteriziation and usage to account for the potential volatility. 54 | -------------------------------------------------------------------------------- /UMIPs/umip-8.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-8 | | 3 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 4 | | UMIP Title | Add Global Collateral Currency Whitelist | 5 | | Authors | Matt Rice (matt@umaproject.org), Clayton Roche (clayton@umaproject.org) | 6 | | Status | Approved | 7 | | Created | July 16, 2020 | 8 | 9 | ## Summary (2-5 sentences) 10 | This UMIP will have the effect of introducing a new global whitelist contract that will allow new collateral currencies to be added without deploying any new contracts. Previously a new financial contract template would need to be deployed to use a new collateral currency. 11 | 12 | ## Motivation 13 | Up until now, to update the collateral currencies, one would need to deploy a new financial contract template since financial contract templates were expected to have a frozen and limited list of collateral currencies. To make the protocol more scalable, it seems sensible to make adding a collateral currency to all existing financial contract templates as easy as proposing a simple governance vote that would approve two Governor transactions: one to add it to the whitelist and another to add a flat final fee for that currency. 14 | 15 | ## Technical Specification 16 | To accomplish this upgrade, a few actions will need to be taken: 17 | - A new `AddressWhitelist` contract will need to be deployed. 18 | - The Governor contract should be this contract’s owner. 19 | - Note: because Dai is already used as a collateral currency, Dai will be included in this whitelist from the start without requiring a separate vote. 20 | - A transaction will need to be proposed to add this new `AddressWhitelist`’s address to the `Finder` contract under the name `“CollateralWhitelist”`. 21 | - This is how other contracts will find the collateral whitelist and reference it. 22 | 23 | Note: this change will only create the whitelist. New financial contract templates that *respect* this whitelist will need to be deployed for it to become useful. 24 | 25 | ## Rationale 26 | 27 | The rationale behind this change is that it fits into a larger goal of making it simpler for the community to make useful changes to the protocol. 28 | 29 | ## Implementation 30 | 31 | The `AddressWhitelist` contract can be found [here](https://github.com/UMAprotocol/protocol/blob/master/core/contracts/common/implementation/AddressWhitelist.sol). It has been audited and will require no changes. 32 | 33 | ## Security considerations 34 | Please see the individual PRs for details on how each affects the security of the UMA ecosystem. This repo has been audited by OpenZeppelin, and the final audit report will be made available [here](https://docs.umaproject.org/uma/index.html). 35 | 36 | This security consideration already existed, but it’s worth noting in this change. Any collateral currencies that are whitelisted but have a small or 0 final fee will open the UMA voting system to DoS attacks. DoS attacks will not break the smart contracts, but they could make voting impractical in the short term while the community discusses how to stop the attack and disregard (or discard) the troublesome requests. 37 | -------------------------------------------------------------------------------- /UMIPs/umip-80.md: -------------------------------------------------------------------------------- 1 | ## Headers 2 | | UMIP-80 | | 3 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 4 | | UMIP Title | Add SharedStake(SGT) as Collateral | 5 | | Authors | Warren Muffett (wmuffet@yahoo.com) and Chimera | 6 | | Status | Approved | 7 | | Created | April 9th, 2021 | 8 | | Discourse Link | https://discourse.umaproject.org/t/add-sgt-as-an-approved-collateral/813 | 9 | 10 | ## Summary (2-5 sentences) 11 | This UMIP will add SGT as an approved collateral currency. This will involve adding the governance token to the whitelist and adding a flat final fee to charge per-request. The proposed final fee is 30 SGT per request. 12 | 13 | The tokenomics of SGT are continuously evolving, with the DAO driving innovation. Reference https://docs.sharedstake.org/sgt/tokenomics to learn more about the tokenomics and distribution of SGT. 14 | 15 | 16 | ## Motivation 17 | SharedStake is an initial custodial staking service that allows anyone to stake their ETH without having to maintain or monitor validator nodes. Simply put, SharedStake removes friction associated with ETH 2 staking 18 | 19 | By adding SGT as collateral, Sharedstake will be able to create derivative contracts such as KPI options that will be proposed shortly after. This is an opportunity to incentive growth of the SharedStake platform alongside the usage of KPI options. 20 | 21 | ## Technical Specification 22 | To accomplish this upgrade, two changes need to be made: 23 | - The SGT address, [0x84810bcf08744d5862b8181f12d17bfd57d3b078](https://etherscan.io/token/0x84810bcf08744d5862b8181f12d17bfd57d3b078), needs to be added to the collateral currency whitelist introduced in UMIP-8. 24 | - A final fee of 30 SGT needs to be added in the store contract. 25 | 26 | ## Rationale 27 | 28 | Whitelisting SGT provides another useful collateral option for UMA users interest in Ethereum 2.0 staking options and is a prerequisite for creating KPI option contracts. 29 | 30 | 30 SGT was chosen for the fee because this sits around $500, which we have seen other collateral tokens use in the past. 31 | 32 | ## Implementation 33 | 34 | This change has no implementation other than the two aforementioned governor transactions that will be proposed. 35 | 36 | ## Security considerations 37 | There are a couple security implications for contract deployers and users who are considering using EMP contracts with SGT as collateral currency. Contract deployers and users of SGT should be aware that it is a volatile currency and sponsors should take care to keep their positions over-collateralized when using the Sharedstake Governance token. 38 | 39 | Both the distribution schedule and the underlying ETH custodial process could have an effect on SGT price. The custodial process allows for ETH holders to pool together their holdings to stake for ETH 2.0. The underlying ETH is withdrawable throughout the process by burning vETH2. -------------------------------------------------------------------------------- /UMIPs/umip-83.md: -------------------------------------------------------------------------------- 1 | # Headers 2 | 3 | | UMIP-83 | | 4 | |---------|-| 5 | | UMIP Title | Add CONSTANT as a price identifier | 6 | | Authors | Sean Brown (@smb2796) | 7 | | Status | Approved | 8 | | Created | 04/21/21 | 9 | | [Discourse](https://discourse.umaproject.org/t/add-constant-price-identifier/1018) | | 10 | 11 | # Summary 12 | 13 | The DVM should support price requests for a CONSTANT price identifier. CONSTANT will always return the value, that is specified in the ancillary data passed along with the price request, or default to a value of "1" if no ancillary data is used. 14 | 15 | # Motivation 16 | 17 | For some financial products, it is useful to have a price identifier that simply returns a constant number. As an example, UMA's KPI options always need to be worth 2 UMA before expiry. This can also be accomplished in other ways - like using a financial product library - but for some contract deployers it may be easier to not need to deploy a custom library and instead just set their price by using this price identifier. 18 | 19 | This constant identifier will also be the first price identifier to reference ancillary data. 20 | 21 | # Markets & Data Sources 22 | 23 | None. This price identifier is just a constant and does not refer to any market. 24 | 25 | # PRICE FEED IMPLEMENTATION 26 | 27 | This price identifier will use the [ExpressionPriceFeed](https://github.com/UMAprotocol/protocol/blob/master/packages/financial-templates-lib/src/price-feed/ExpressionPriceFeed.js). To use ancillary data with this price identifier, a feature will need to be added to the price feeds to allow for the decoding and use of ancillary data. Since this price identifier can be used without ancillary data, it should not be blocked by the lack of ancillary data functionality in the price feeds. 28 | 29 | # TECHNICAL SPECIFICATIONS 30 | 31 | - Price Identifier Name: CONSTANT 32 | - Base Currency: NA 33 | - Quote currency: NA 34 | - Rounding: No rounding is necessary. The value returned should always be exactly equal to the value passed in ancillary data, or equal to 1 if no ancillary data is used. 35 | 36 | 37 | When converted from bytes to UTF-8, the ancillary data should be a dictionary containing a `constant` key like so: 38 | ``` 39 | constant:2 40 | ``` 41 | 42 | The `constant` key should return the value that voters should resolve for this identifier. In this example, voters should vote 2. This value should not be scaled and should be returned exactly as is. 43 | 44 | When the simple example ancillary data dictionary "constant:2" is stored as bytes, the result would be: 0x636f6e7374616e743a32. 45 | 46 | # RATIONALE 47 | No rationale is needed. The motivation for this price identifier is explained in `motivation` and there is no plausible alternative for how to return a constant value. 48 | 49 | # IMPLEMENTATION 50 | 51 | 1. Query for the `ancillaryData` value from the price request. 52 | 2. Decode the ancillary data from bytes to UTF-8. 53 | 3. If no ancillary data is provided, or there is ancillary data but it cannot be converted to the format in `Technical Specifications`, return `1`. 54 | 4. If the ancillary data in UTF-8 contains a `constant` key, return the `constant` value. Voters should disregard any other key:value pairs included in the ancillary data. 55 | 56 | # SECURITY CONSIDERATIONS 57 | 58 | Adding this price identifier poses no risk to the UMA system. Since there should be no inconsistency in the result that should be returned, there is no risk of lack of determinism in this approach, as long as the price requester specifies their ancillary data correctly. -------------------------------------------------------------------------------- /UMIPs/umip-88.md: -------------------------------------------------------------------------------- 1 | ## HEADERS 2 | | UMIP-88 | | 3 | |------------|-------------| 4 | | UMIP Title | Add iFARM as a supported collateral currency | 5 | | Authors | EAsports and gruad | 6 | | Status | Approved| 7 | | Created | 4/17/2021| 8 | | Discourse Link: | https://discourse.umaproject.org/t/adding-ifarm-as-collateral/922 | 9 | 10 | # SUMMARY 11 | 12 | This UMIP will add iFARM as approved collateral currency. This will involve adding the iFARM token to the whitelist and adding flat final fees to charge per-request. More information on FARM and iFARM can be found [here](https://farm.chainwiki.dev/en/home). 13 | 14 | # MOTIVATION 15 | 16 | iFARM is the interest-bearing receipt of the cash flow token FARM from Harvest Finance. All FARM staked in the SP pool either directly or through iFARM receives the benefit of a portion of all profits across all Harvest vault strategies. The Harvest community is interested in utilizing their capital more efficiently and borrowing against their iFARM while their FARM is still earning and exploring additional use cases within the UMA ecosystem such as KPI options. 17 | 18 | # TECHNICAL SPECIFICATIONS 19 | 20 | To accomplish this, two changes need to be made: 21 | 22 | * The iFARM address, 0x1571eD0bed4D987fe2b498DdBaE7DFA19519F651, needs to be added to the collateral currency whitelist introduced in UMIP-8 23 | 24 | * A final fee of 2 iFARM need to be added for the iFARM in the Store contract (~229.00 at 6pm ET on 2021.04.26). See [also](https://www.coingecko.com/en/coins/ifarm). Note: iFARM increases in value over time relative to FARM due to the nature of the in wallet compounding. For more explanation see section "How does the FARM Pool work?" of Harvest [FAQ](https://harvest.finance/faq) 25 | 26 | # RATIONALE 27 | 28 | The rationale behind this change is to add additional collateral currency options and position potential future opportunities including allowing iFARM holders to create options or synthetic assets within the UMA ecosystem. 29 | 30 | 2 iFARM has been chosen as a $400 USD equivalent because it is the minimum required fee and it will tend to grow over time in terms of underlying FARM. 31 | 32 | # IMPLEMENTATION 33 | 34 | This proposal has no additional implementation other than the two governance transactions proposed under “Technical Specification” 35 | 36 | # Security considerations 37 | 38 | Since iFARM is a persistently valuable token, adding it as collateral should not impose any additional risk beyond the normal volatility risk associated with its FARM. Users should be aware of those risks before depositing collateral. 39 | -------------------------------------------------------------------------------- /UMIPs/umip-93.md: -------------------------------------------------------------------------------- 1 | | UMIP-93 | | 2 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 3 | | UMIP Title | Add yvUSDC as a whitelisted collateral currency | 4 | | Authors | Pascal Tallarida (pascal@jarvis.network) | 5 | | Status | Approved | 6 | | Created | 09/05/2021 7 | | Discourse link | https://discourse.umaproject.org/t/add-yvusdc-as-approved-collateral/1060 | 8 | 9 | ## Summary 10 | 11 | This UMIP will add yvUSDC, an interest-bearing stablecoin tokenizing USDC deposited in YEARN V2 Vaults, as approved collateral currency. This will involve adding the currency to the whitelist and adding a flat final fee to charge per-request. The proposed final fee is 400 yvUSDC per request. 12 | 13 | ## Motivation 14 | 15 | yvUSDC is an ERC20 token reprenseting one's USDC deposit within Yean's V2 USDC Vault. 16 | 17 | It is an interest-bearing stablecoin which grows in value automatically (the yvUSDC/USDC rate is constantly going up, following the yield generated by the vault). 18 | 19 | Adding yvUSDC as collateral will allow the creation of new synthetic assets backed by this stablecoin which only grows in value. For example, it will allow us, at Jarvis, to launch new liquidity pools based on yvUSDC (see [UMIP-34](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-34.md). 20 | 21 | 22 | 23 | ## Technical Specification 24 | 25 | To accomplish this upgrade, two changes need to be made: 26 | 27 | - The yvUSDC address, 0x5f18c75abdae578b483e5f43f12a39cf75b973a9, needs to be added to the collateral currency whitelist introduced in UMIP-8. 28 | - A final fee of 400 yvUSDC needs to be added for yvUSDC in the Store contract. 29 | 30 | ## Rationale 31 | 32 | The rationale behind this change is giving deployers more useful collateral currency options. 33 | 34 | 35 | 400 yvUSDC was chosen as the final fee for yvUSDC because this is the practical equivalent to the final fee of already 36 | approved stablecoins. 37 | 38 | 39 | ## Implementation 40 | 41 | This change has no implementation other than proposing the two aforementioned governor transactions that will be proposed. 42 | 43 | ## Security considerations 44 | yvUSDC bear the centralized risks of USDC and the technical risks of Yearn: yearn's vault are investing depositors' USDC into other protocols in order to generate yield, therefore, in addition to yearn's own smart contract, yvUSDC also bears the risk of the underlying protocols used for generating the yield. 45 | 46 | Although, Yearn's team has quite a conservative risk management and assessment matrix, so the risk is limited. 47 | 48 | Using yvUSDC as collateral for contract deployers and users should be done without considering 1 yvUSDC = 1 USD; yvUSDC is an interest-bearing stablecoin which constantly grows in value. Contract deployers would need to use the yvUSDC/USDC exchange rate. 49 | 50 | A potential added risk for liquidators is that the yvUSDC token can be obtained only by depositing USDC in Yearn V2 Vault system (currently there is not a secondary market for the token). In that case liquidators are exposed to a possible high gas costs, which might dissolve some of the profits from the liquidation itself. One way to mitigate this is to hold a reserve of yvUSDC, which allows generating yield while a liquidation opportunity arrises. 51 | -------------------------------------------------------------------------------- /UMIPs/umip-94.md: -------------------------------------------------------------------------------- 1 | | UMIP-94 | | 2 | |------------|------------------------------------------------------------------------------------------------------------------------------------------| 3 | | UMIP Title | Add UST as a whitelisted collateral currency | 4 | | Authors | Pascal Tallarida (pascal@jarvis.network) | 5 | | Status | Approved | 6 | | Created | 09/05/2021 7 | | Discourse link | https://discourse.umaproject.org/t/add-ust-as-approved-collateral/1059 | 8 | 9 | ## Summary 10 | 11 | This UMIP will add TerraUSD (UST) as approved collateral currencies. This will involve adding the currencies to the whitelist and adding a flat final fee to charge per-request. The proposed final fee is 400 UST per request. 12 | 13 | ## Motivation 14 | 15 | UST is a decentralized algorithmic stablecoin pegged to the US dollar, issued on the Terra blockchain and wrapped onto various Blockchain. 16 | 17 | UST has been launched in September 2020, following the success of TerraKRW (KRT), a stablecoin pegged to the Korean Won (KRW). Since launch, UST became the 5th largest stablecoin, right behdind DAI, with a $2 Bn market capitalisation. $360M of UST are currently circulating on the Ethereum Blockchain. 18 | 19 | Unlike other algorithmic stablecoin, UST has been incredibly stable. 20 | 21 | Terra USD(UST) uses an elastic supply to maintain its peg to the USD. As example when there is a high demand for UST and the stable coin is traded above 1 USD, the supply of UST will be increase by minting new UST, thus bringing back down the price to a dollar. Vice versa if there is a shortage in demand for UST, the protocol will buy back UST and will burn in, thus reducing the supply and pushing the price back up to be equal to 1 USD. Also arbitrage opportunities are an incentivization to keep the price at 1 USD. 22 | 23 | The above algorithmic approach is achieved by using LUNA token as collateral for UST. In order to mint a new supply of UST, the protocol will have to burn LUNA tokens. Vice versa if the supply of UST have to be reduced, the protocol will burn UST tokens and mint LUNA tokens. 24 | 25 | It is listed agasint USDT on Bittrex and Kucoin, and in the UST Curve meta-pool (UST+3pool). 26 | 27 | Adding UST as collateral will allow the creation of new synthetic assets backed by this stablecoin. For example, it will allow us, at Jarvis, to launch new liquidity pools based on UST (see [UMIP-34](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-34.md)). 28 | 29 | 30 | 31 | ## Technical Specification 32 | 33 | To accomplish this upgrade, two changes need to be made: 34 | 35 | - The UST address, 0xa47c8bf37f92abed4a126bda807a7b7498661acd, needs to be added to the collateral currency whitelist introduced in UMIP-8. 36 | - A final fee of 400 UST needs to be added for UST in the Store contract. 37 | 38 | ## Rationale 39 | 40 | The rationale behind this change is giving deployers more useful collateral currency options. 41 | 42 | 43 | 400 UST was chosen as the final fee for UST because this is the practical equivalent to the final fee of already 44 | approved stablecoins. 45 | 46 | 47 | 48 | ## Implementation 49 | 50 | This change has no implementation other than proposing the two aforementioned governor transactions that will be proposed. 51 | 52 | ## Security considerations 53 | Adding UST as a collateral does not present any major foreseeable risks to the protocol. 54 | 55 | Since UST is a decentralized and algorithmic stablecoin, it bears technical risks of losing its peg, but with a proven track record with KRT, and the level of integration of UST, the risk is limited. 56 | 57 | Using UST as collateral for contract deployers and users should account for the potential fluctuations away from the peg. 58 | -------------------------------------------------------------------------------- /UPPs/upp-1.md: -------------------------------------------------------------------------------- 1 | # UPPs 2 | 3 | UPPs (“UMA Parameter Proposals”) are a lighter-weight form of an UMIP meant for simple parameter changes, like fees, inflation rewards, voting reward expiries, etc. The difference between this and an UMIP is semantic and process-based. Both still need tokenholder approval to be implemented and both can still pose a risk to the DVM. 4 | 5 | They give information about what parameters will be changed and why, but aren't as detailed as their UMIP counterparts due since their changes are simpler. 6 | The UPP should explain what parameter will be changed, why, and if there are any potential hazards to making this change. 7 | Note: despite the shorter process and simpler changes, these proposals are still quite powerful and should be considered just as carefully. 8 | This is why they still must go through the same tokenholder vote that regular UMIPs do. 9 | 10 | # What is the lifecycle of a UPP? 11 | 12 | A successful UPP will move along the following stages: Draft ⟶ Final ⟶ Approved. 13 | 14 | ## Draft 15 | A UPP that is open for consideration and is undergoing changes. 16 | 17 | ## Final 18 | A UPP that is done with changing due to feedback and is ready to be proposed for a vote. 19 | 20 | ## Approved 21 | If tokenholders approve the proposal, the live protocol will be updated to reflect the parameter change. 22 | 23 | ## Abandoned 24 | If at any point during the UPP Finalization Process, a UPP is abandoned, it will be labeled as such. 25 | 26 | ## Rejected 27 | If tokenholders do not approve a proposal, it will be labeled Rejected. 28 | -------------------------------------------------------------------------------- /UPPs/upp-11.md: -------------------------------------------------------------------------------- 1 | ## Status 2 | 3 | Approved 4 | 5 | ## Summary 6 | 7 | This UPP proposes adding WETH for use as collateral in UMA contracts on Optimism. 8 | 9 | ## Rationale 10 | 11 | WETH is already approved as a collateral currency within UMA's system but has not been approved on Optimism. This UPP will correct that. 12 | 13 | ## Specifics 14 | 15 | To accomplish this upgrade, the following changes need to be made: 16 | 17 | - The Optimism **WETH** address **[0x4200000000000000000000000000000000000006](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006)** needs to be added to the collateral currency whitelist introduced in UMIP-8. 18 | - A final fee of **0.35** needs to be added for **WETH** in the Store contract on Optimism. 19 | -------------------------------------------------------------------------------- /UPPs/upp-12.md: -------------------------------------------------------------------------------- 1 | ## Status 2 | 3 | Last Call 4 | 5 | ## Summary 6 | 7 | This UPP proposes to update the final fee for WETH on Optimism. 8 | 9 | ## Rationale 10 | 11 | UPP-11 registered WETH on Optimism with a proposed final fee of `0.35` WETH. Mistakingly the final fee was actually set to 0.35 * 10^18 instead. This UPP is proposed to correct the Optimism WETH final fee. 12 | 13 | ## Specifics 14 | 15 | To accomplish this upgrade, the following changes need to be made: 16 | 17 | - The final fee for Optimism **WETH** **[0x4200000000000000000000000000000000000006](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006)** needs to be updated to **0.35** in the Store contract on Optimism. -------------------------------------------------------------------------------- /UPPs/upp-13.md: -------------------------------------------------------------------------------- 1 | ## Status 2 | 3 | Draft 4 | 5 | ## Summary 6 | 7 | This UPP proposes to update the final fees for various registered stablecoin collateral types in the UMA system. This has been restricted to stables that are actually used today or have a higher likelihood of usage. These include: DAI, USDC, USDT and FRAX. 8 | 9 | ## Rationale 10 | 11 | UMA's final fees are a spam prevention mechanism. The idea is that it needs to be relatively expensive to trigger a DVM vote, so that votes are not needlessly or malicously escalated to the DVM without a cost. The ballpark cost has always been a function of how much a voter could earn in $UMA inflation rewards by triggering needless votes. 12 | 13 | Final fees had previously been targeted at $1500. This was voted in at a time when the dollar value of $UMA was much higher. Now with a lower UMA price, the value that a voter could get from spamming the system is much lower - so final fees can be adjusted accordingly and should be, since lower final fees make for a much better integrating experience for users of the UMA oracle system. 14 | 15 | ## Specifics 16 | 17 | To accomplish this upgrade, all the following currencies should have their final fee be updated to 500 tokens each. 18 | 19 | **FRAX** 20 | - FRAX Mainnet: [0x853d955acef822db058eb8505911ed77f175b99e](https://etherscan.io/token/0x853d955acef822db058eb8505911ed77f175b99e) 21 | 22 | **DAI** 23 | - DAI Mainnet: [0x6b175474e89094c44da98b954eedeac495271d0f](https://etherscan.io/token/0x6b175474e89094c44da98b954eedeac495271d0f) 24 | - DAI Polygon: [0x8f3Cf7ad23Cd3CaDbD9735AFf958023239c6A063](https://polygonscan.com/address/0x8f3cf7ad23cd3cadbd9735aff958023239c6a063) 25 | - DAI Optimism:[0xDA10009cBd5D07dd0CeCc66161FC93D7c9000da1](https://optimistic.etherscan.io/address/0xda10009cbd5d07dd0cecc66161fc93d7c9000da1) 26 | - DAI Arbitrum:[0xDA10009cBd5D07dd0CeCc66161FC93D7c9000da1](https://arbiscan.io/address/0xda10009cbd5d07dd0cecc66161fc93d7c9000da1) 27 | - DAI Boba: [0xf74195Bb8a5cf652411867c5C2C5b8C2a402be35](https://bobascan.com/address/0xf74195Bb8a5cf652411867c5C2C5b8C2a402be35) 28 | 29 | **USDT** 30 | - USDT Mainnet: [0xdac17f958d2ee523a2206206994597c13d831ec7](https://etherscan.io/token/0xdac17f958d2ee523a2206206994597c13d831ec7) 31 | - USDT Polygon: [0xc2132d05d31c914a87c6611c10748aeb04b58e8f](https://polygonscan.com/address/0xc2132d05d31c914a87c6611c10748aeb04b58e8f) 32 | - USDT Optimism: [0x94b008aA00579c1307B0EF2c499aD98a8ce58e58](https://optimistic.etherscan.io/address/0x94b008aa00579c1307b0ef2c499ad98a8ce58e58) 33 | - USDT Arbitrum: [0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9](https://arbiscan.io/address/0xfd086bc7cd5c481dcc9c85ebe478a1c0b69fcbb9) 34 | - USDT Boba: [0x5DE1677344D3Cb0D7D465c10b72A8f60699C062d](https://bobascan.com/address/0x5DE1677344D3Cb0D7D465c10b72A8f60699C062d) 35 | 36 | **USDC** 37 | - USDC Mainnet: [0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48) 38 | - USDC Polygon: [0x2791bca1f2de4661ed88a30c99a7a9449aa84174](https://polygonscan.com/address/0x2791bca1f2de4661ed88a30c99a7a9449aa84174) 39 | - USDC Optimism: [0x7F5c764cBc14f9669B88837ca1490cCa17c31607](https://optimistic.etherscan.io/address/0x7f5c764cbc14f9669b88837ca1490cca17c31607) 40 | - USDC Arbitrum: [0xFF970A61A04b1cA14834A43f5dE4533eBDDB5CC8](https://arbiscan.io/address/0xff970a61a04b1ca14834a43f5de4533ebddb5cc8) 41 | - USDC Boba: [0x66a2A913e447d6b4BF33EFbec43aAeF87890FBbc](https://bobascan.com/token/0x66a2a913e447d6b4bf33efbec43aaef87890fbbc) -------------------------------------------------------------------------------- /UPPs/upp-14.md: -------------------------------------------------------------------------------- 1 | ## Status 2 | 3 | Draft 4 | 5 | ## Summary 6 | 7 | This UPP proposes to update the final fees for various registered stablecoin collateral types in the UMA system. This has been restricted to WETH and stables that are actually used today or have a higher likelihood of usage. These include: WETH, DAI, USDC and USDT. 8 | 9 | ## Rationale 10 | 11 | UMA's final fees serve as a mechanism to prevent spam within the system. The primary objective is to discourage unnecessary or malicious escalation to the DVM (Data Verification Mechanism) without any significant cost. Previously, the final fees were set at $500 when the DVM2.0 was not yet implemented. 12 | 13 | With the introduction of DVM 2.0, new anti-spam measures have been implemented, ensuring robust protection against spam and misuse. These improved mechanisms have made it possible to lower the final fees to $250, independent of any changes in the value of $UMA. 14 | 15 | The decision to reduce the final fees to $250 is driven by the effectiveness of the new anti-spam mechanisms within DVM 2.0. By reducing the fees, the integration experience for users of the UMA oracle system is greatly improved. It allows for more accessible and cost-effective utilization of the system, while still maintaining the necessary deterrent against spam and malicious behavior. 16 | 17 | ## Specifics 18 | 19 | In order to implement this upgrade, the final fees for all the mentioned currencies should be adjusted to an equivalent of $250 USD worth of tokens each. 20 | 21 | **WETH** 22 | - WETH Mainnet: [0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) 23 | - WETH Polygon: [0x7ceb23fd6bc0add59e62ac25578270cff1b9f619](https://polygonscan.com/token/0x7ceb23fd6bc0add59e62ac25578270cff1b9f619) 24 | - WETH Optimism: [0x4200000000000000000000000000000000000006](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006) 25 | - WETH Arbitrum: [0x82af49447d8a07e3bd95bd0d56f35241523fbab1](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1) 26 | 27 | **DAI** 28 | - DAI Mainnet: [0x6b175474e89094c44da98b954eedeac495271d0f](https://etherscan.io/token/0x6b175474e89094c44da98b954eedeac495271d0f) 29 | - DAI Polygon: [0x8f3Cf7ad23Cd3CaDbD9735AFf958023239c6A063](https://polygonscan.com/address/0x8f3cf7ad23cd3cadbd9735aff958023239c6a063) 30 | - DAI Optimism:[0xDA10009cBd5D07dd0CeCc66161FC93D7c9000da1](https://optimistic.etherscan.io/address/0xda10009cbd5d07dd0cecc66161fc93d7c9000da1) 31 | - DAI Arbitrum:[0xDA10009cBd5D07dd0CeCc66161FC93D7c9000da1](https://arbiscan.io/address/0xda10009cbd5d07dd0cecc66161fc93d7c9000da1) 32 | 33 | **USDT** 34 | - USDT Mainnet: [0xdac17f958d2ee523a2206206994597c13d831ec7](https://etherscan.io/token/0xdac17f958d2ee523a2206206994597c13d831ec7) 35 | - USDT Polygon: [0xc2132d05d31c914a87c6611c10748aeb04b58e8f](https://polygonscan.com/address/0xc2132d05d31c914a87c6611c10748aeb04b58e8f) 36 | - USDT Optimism: [0x94b008aA00579c1307B0EF2c499aD98a8ce58e58](https://optimistic.etherscan.io/address/0x94b008aa00579c1307b0ef2c499ad98a8ce58e58) 37 | - USDT Arbitrum: [0xFd086bC7CD5C481DCC9C85ebE478A1C0b69FCbb9](https://arbiscan.io/address/0xfd086bc7cd5c481dcc9c85ebe478a1c0b69fcbb9) 38 | 39 | **USDC** 40 | - USDC Mainnet: [0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48](https://etherscan.io/token/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48) 41 | - USDC Polygon: [0x2791bca1f2de4661ed88a30c99a7a9449aa84174](https://polygonscan.com/address/0x2791bca1f2de4661ed88a30c99a7a9449aa84174) 42 | - USDC Optimism: [0x7F5c764cBc14f9669B88837ca1490cCa17c31607](https://optimistic.etherscan.io/address/0x7f5c764cbc14f9669b88837ca1490cca17c31607) 43 | - USDC Arbitrum: [0xFF970A61A04b1cA14834A43f5dE4533eBDDB5CC8](https://arbiscan.io/address/0xff970a61a04b1ca14834a43f5de4533ebddb5cc8) -------------------------------------------------------------------------------- /UPPs/upp-15.md: -------------------------------------------------------------------------------- 1 | ## Status 2 | 3 | Draft 4 | 5 | ## Summary 6 | 7 | This UPP proposes adding native USDC for use as collateral in UMA contracts on Optimism, Polygon, and Arbitrum. 8 | 9 | ## Rationale 10 | 11 | Bridged USDC is currently approved as a collateral currency on Optimism, Arbitrum, and Polygon. Native USDC is already approved on Ethereum mainnet and Avalanche. 12 | 13 | This UPP is proposing to update Optimism, Polygon, and Arbitrum to include native USDC. 14 | 15 | ## Specifics 16 | 17 | To implement this upgrade, a final fee of **250** needs to be added for the following addresses in the Store contract on Optimism, Arbitrum, and Polygon: 18 | 19 | - USDC Optimism: [0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85](https://optimistic.etherscan.io/token/0x0b2C639c533813f4Aa9D7837CAf62653d097Ff85) 20 | - USDC Arbitrum [0xaf88d065e77c8cC2239327C5EDb3A432268e5831](https://arbiscan.io/address/0xaf88d065e77c8cC2239327C5EDb3A432268e5831) 21 | - USDC Polygon [0x3c499c542cef5e3811e1192ce70d8cc03d5c3359](https://polygonscan.com/address/0x3c499c542cef5e3811e1192ce70d8cc03d5c3359) 22 | 23 | 24 | -------------------------------------------------------------------------------- /UPPs/upp-2.md: -------------------------------------------------------------------------------- 1 | ## Status 2 | 3 | Approved 4 | 5 | ## Summary 6 | 7 | This UPP will increase the final fees for DAI, WETH, and renBTC to be around $400. This will increase the cost of initiating disputes for the DVM. 8 | 9 | ## Rationale 10 | 11 | It is extremely expensive, in terms of gas, for the DVM voters to vote on a price request. The DVM also pays out a relatively large number of rewards on each vote. 12 | To ensure that price requests remain rare, they need to be more expensive to discourage any sort of purposeful triggering. 13 | 14 | While this does make the capital requirements for liquidators and disputers higher, the increased size of the final fee lockup is unlikely to deter honest participants. 15 | 16 | ## Specifics 17 | 18 | The WETH final fee will be increased to 1 WETH. 19 | The DAI final fee will be increased to 400 DAI. 20 | The renBTC final fee will be changed to 0.035 renBTC. 21 | -------------------------------------------------------------------------------- /UPPs/upp-3.md: -------------------------------------------------------------------------------- 1 | ## Status 2 | 3 | Approved 4 | 5 | ## Summary 6 | 7 | This UPP will adjust the final fees for WETH, renBTC, WBTC, PERL, DSD and OCEAN to be around $400. 8 | 9 | ## Rationale 10 | 11 | UMA final fees have traditionally been targeted to a dollar value of $400 - see the rationale behind this in [upp-2](https://github.com/UMAprotocol/UMIPs/blob/master/UPPs/upp-2.md). Naturally, the dollar denominated price of collateral types will change over time, and it is the responsibility of UMA tokenholders to adjust these to a more reasonable level. 12 | 13 | This page will give you the current final fees of these collateral types. 14 | 15 | ## Specifics 16 | 17 | - The WETH final fee will be decreased to 0.2 WETH. 18 | - The renBTC final fee will be decreased to 0.0075 renBTC. 19 | - The WBTC final fee will be decreased to 0.0075 WBTC 20 | - The PERL final fee will be decreased to 2500 PERL. 21 | - The DSD final fee will be increased to 2500 DSD. 22 | - The OCEAN final fee will be decreased to 300 OCEAN. 23 | 24 | -------------------------------------------------------------------------------- /UPPs/upp-4.md: -------------------------------------------------------------------------------- 1 | ## Status 2 | 3 | Approved 4 | 5 | ## Summary 6 | 7 | This UPP will increase the final fees for RenBTC, PERL, bBADGER , OCEAN, YAM, wBTC, AAVE, LINK SNX, UMA, DPI, SUSHI, xSUSHI, XIO, BAL,bDIGG, RAI, COMP, ALCX, ALPHA, REN, CRV, RGT, NFTX, LON, MASK, BANK, SFI, VSP, DEXTF, ORN, PUNK-BASIC, iFARM, BNT, vBNT, BAND, SDT, KP3R, CHAIN, OPEN and DFX to be around $400. This will increase the cost of initiating disputes for the DVM. 8 | 9 | Additionally, this UPP will decrease the final fees for RenDOGE, and BASK to around $400, reducing the cost of initiating disputes for the DVM. 10 | 11 | ## Rationale 12 | 13 | It is extremely expensive, in terms of gas, for the DVM voters to vote on a price request. The DVM also pays out a relatively large number of rewards on each vote. To ensure that price requests remain rare, they need to be more expensive to discourage any sort of purposeful triggering. 14 | 15 | While this does make the capital requirements for liquidators and disputers higher, the increased size of the final fee lockup is unlikely to deter honest participants. 16 | 17 | It is also necessary to ensure that the cost of dispute is not so high that is it off-putting to raise valid disputes, risking invalid liquidations being left unchallenged. 18 | 19 | ## Specifics 20 | 21 | - The RenBTC final fee will be increased to 0.012 RenBTC 22 | - The PERL final fee will be increased to 6000 PERL. 23 | - The bBADGER final fee will be increased to 40 bBADGER 24 | 25 | - The RenDOGE final fee will be decreased to 1500 RenDOGE 26 | - The OCEAN final fee will be increased to 1000 OCEAN. 27 | - The YAM final fee will be increased to 500 YAM 28 | - The wBTC final fee will be increased to 0.012 wBTC 29 | - The AaVE final fee will be increased to 2 AAVE 30 | - The LINK final fee will be increased to 23 LINK 31 | - The SNX final fee will be increased to 65 SNX 32 | - The UMA final fee will be increased to 45 UMA 33 | - The DPI final fee will be increased to 1.75 DPI 34 | - The SUSHI final fee will be increased to 60 SUSHI 35 | - The xSUSHI final fee will be increased to 50 xSUSHI 36 | - The XIO final fee will be increased to 3000 XIO 37 | - The BAL final fee will be increased to 24 BAL 38 | - The bDIGG final fee will be increased to 0.09 bDIGG 39 | - The RAI final fee will be increased to 500 RAI 40 | - The COMP final fee will be increased to 1.3 COMP 41 | - The ALCX final fee will be increased to 1.35 ALCX 42 | - The ALPHA final fee will be increased to 900 ALPHA 43 | - The REN final fee will be increased to 1150 REN 44 | - The CRV final fee will be increased to 250 CRV 45 | - The RGT final fee will be increased to 85 RGT 46 | - The NFTX final fee will be increased to 7.5 NFTX 47 | - 48 | - The LON final fee will be increased to 130 LON 49 | - The MASK final fee will be increased to 115 MASK 50 | - The BANK final fee will be increased to 5.75 BANK 51 | - The SFI final fee will be increased to 1.3 SFI 52 | - The VSP final fee will be increased to 50 VSP 53 | - The DEXTF final fee will be increased to 2250 DEXTF 54 | - The ORN final fee will be increased to 75 ORN 55 | - The PUNK-BASIC final fee will be increased to 0.015 PUNK-BASIC 56 | - The iFARM final fee will be increased to 7.5 iFARM 57 | - The BNT final fee will be increased to 135 BNT 58 | - The vBNT final fee will be increased to 400 vBNT 59 | - The BAND final fee will be increased to 75 BAND 60 | - The SDT final fee will be increased to 450 SDT 61 | - The KP3R final fee will be increased to 5 KP3R 62 | - The CHAIN final fee will be increased to 5000 CHAIN 63 | 64 | - The OPEN final fee will be increased to 1000 OPEN 65 | - The DFX final fee will be increased to 900 DFX 66 | - The BASK final fee will be decreased to 1.75 BASK 67 | -------------------------------------------------------------------------------- /UPPs/upp-5.md: -------------------------------------------------------------------------------- 1 | ## Status 2 | 3 | Approved 4 | 5 | ## Summary 6 | 7 | This UPP will increase the final fees for DSD to be around $400. This will increase the cost of initiating disputes for the DVM. 8 | 9 | ## Rationale 10 | 11 | It is extremely expensive, in terms of gas, for the DVM voters to vote on a price request. The DVM also pays out a relatively large number of rewards on each vote. To ensure that price requests remain rare, they need to be more expensive to discourage any sort of purposeful triggering. 12 | 13 | While this does make the capital requirements for liquidators and disputers higher, the increased size of the final fee lockup is unlikely to deter honest participants. 14 | 15 | ## Specifics 16 | 17 | - The DSD final fee will be increased to 20000 DSD 18 | 19 | -------------------------------------------------------------------------------- /UPPs/upp-6.md: -------------------------------------------------------------------------------- 1 | ## Status 2 | 3 | Approved 4 | 5 | ## Summary 6 | 7 | This UPP will remove SGT from the collateral currency whitelist introduced in [UMIP-8](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-8.md). 8 | 9 | ## Rationale 10 | 11 | SGT was approved as a collateral currency in [UMIP-80](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-80.md), liquidity has since dropped massively which is a concern for $UMA token holders since collateral liquidity is an important factor in determining whether a collateral currency is approved or rejected. This makes SGT an unsuitable collateral currency. 12 | 13 | ## Specifics 14 | 15 | Remove SGT from collateral currency whitelist introduced in [UMIP-8](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-8.md) 16 | -------------------------------------------------------------------------------- /UPPs/upp-7.md: -------------------------------------------------------------------------------- 1 | ## Status 2 | 3 | Approved 4 | 5 | ## Summary 6 | 7 | This UPP will adjust the final fees for the Polygon versions of SUSHI, CRV, WBTC, USDC, SNX, WETH, COMP, DAI, BAL, UNI, USDT, AAVE and YFI. Currently these fees sit at 0 and need to be adjusted to match their corresponding mainnet fee amounts. 8 | 9 | ## Rationale 10 | 11 | Final fees of around $400 are needed for all collateral types to prevent DVM spam. 12 | 13 | ## Specifics 14 | 15 | - SUSHI: [0x0b3f868e0be5597d5db7feb59e1cadbb0fdda50a](https://polygonscan.com/address/0x0b3f868e0be5597d5db7feb59e1cadbb0fdda50a): 60 16 | - CRV: [0x172370d5cd63279efa6d502dab29171933a610af](https://polygonscan.com/address/0x172370d5cd63279efa6d502dab29171933a610af): 250 17 | - WBTC: [0x1bfd67037b42cf73acf2047067bd4f2c47d9bfd6](https://polygonscan.com/address/0x1bfd67037b42cf73acf2047067bd4f2c47d9bfd6): 0.012 18 | - USDC: [0x2791bca1f2de4661ed88a30c99a7a9449aa84174](https://polygonscan.com/address/0x2791bca1f2de4661ed88a30c99a7a9449aa84174): 400 19 | - SNX: [0x50b728d8d964fd00c2d0aad81718b71311fef68a](https://polygonscan.com/address/0x50b728d8d964fd00c2d0aad81718b71311fef68a): 65 20 | - WETH: [0x7ceb23fd6bc0add59e62ac25578270cff1b9f619](https://polygonscan.com/address/0x7ceb23fd6bc0add59e62ac25578270cff1b9f619): 0.2 21 | - COMP: [0x8505b9d2254a7ae468c0e9dd10ccea3a837aef5c](https://polygonscan.com/address/0x8505b9d2254a7ae468c0e9dd10ccea3a837aef5c): 1.3 22 | - DAI: [0x8f3cf7ad23cd3cadbd9735aff958023239c6a063](https://polygonscan.com/address/0x8f3cf7ad23cd3cadbd9735aff958023239c6a063): 400 23 | - BAL: [0x9a71012b13ca4d3d0cdc72a177df3ef03b0e76a3](https://polygonscan.com/address/0x9a71012b13ca4d3d0cdc72a177df3ef03b0e76a3): 24 24 | - UNI: [0xb33eaad8d922b1083446dc23f610c2567fb5180f](https://polygonscan.com/address/0xb33eaad8d922b1083446dc23f610c2567fb5180f): 20 25 | - USDT: [0xc2132d05d31c914a87c6611c10748aeb04b58e8f](https://polygonscan.com/address/0xc2132d05d31c914a87c6611c10748aeb04b58e8f): 400 26 | - AAVE: [0xd6df932a45c0f255f85145f286ea0b292b21c90b](https://polygonscan.com/address/0xd6df932a45c0f255f85145f286ea0b292b21c90b): 2 27 | - YFI: [0xda537104d6a5edd53c6fbba9a898708e465260b6](https://polygonscan.com/address/0xda537104d6a5edd53c6fbba9a898708e465260b6): 0.01 28 | -------------------------------------------------------------------------------- /collateral-currency-template.md: -------------------------------------------------------------------------------- 1 | **UMIP #** - tbd 2 | 3 | - **UMIP title:** Add **token** as collateral currency 4 | - **Author:** Name (email) 5 | - **Status:** Draft 6 | - **Created:** Date 7 | - **Discourse Link:** Insert link to discourse topic after it has been moved into draft UMIPs 8 | 9 | ## Summary (2-5 sentences) 10 | 11 | This UMIP proposes adding **token** for use as collateral in UMA contracts. 12 | 13 | ## Motivation 14 | 15 | The addition of this collateral currency offers additional functionality to the UMA protocol and increases the range of contracts that can be built. 16 | 17 | ## Technical Specification 18 | 19 | To accomplish this upgrade, the following changes need to be made: 20 | 21 | - The **token** address **token address (etherscan link)** needs to be added to the collateral currency whitelist introduced in UMIP-8. 22 | - A final fee of **amount token** needs to be added for **token** in the Store contract. 23 | 24 | 25 | ## Rationale 26 | 27 | This store fee was chosen as it is approximately equivalent to $1500 in line with other collateral currencies as determined by **insert how the value of $1500 was determined** 28 | 29 | ## Implementation 30 | 31 | 32 | This change has no implementations other than the aforementioned governor transactions 33 | 34 | ## Security considerations 35 | 36 | Adding a collateral currency introduces a level of risk into the UMA Ecosystem. This collateral type should be monitored to ensure that the proposed collateral continues to have value. 37 | 38 | Contract deployers considering using this collateral in an UMA contract should refer to the [guidelines on collateral type usage](https://docs.umaproject.org/uma-tokenholders/guidence-on-collateral-currency-addition) to ensure appropriate use. 39 | 40 | -------------------------------------------------------------------------------- /umip-template.md: -------------------------------------------------------------------------------- 1 | This is the suggested template for new UMIPs. 2 | 3 | Note that an UMIP number will be assigned by an editor. 4 | When opening a pull request to submit your UMIP, please use an abbreviated title in the filename, umip-draft_title_abbrev.md. 5 | 6 | The title should be 44 characters or less. 7 | 8 | ## Headers 9 | - UMIP <#> 10 | - UMIP title: 11 | - Author (name or username and email) 12 | - Status: <Draft, Last Call, Approved, Final, Abandoned, Rejected> 13 | - Created: <date created on> 14 | - Discourse Link: <Link> 15 | 16 | ## Summary (2-5 sentences) 17 | "If you can't explain it simply, you don't understand it well enough." 18 | Provide a simplified and layman-accessible explanation of the issue. 19 | 20 | ## Motivation 21 | The motivation is critical to change the UMA protocol. 22 | It should clearly explain why the existing protocol specification is inadequate with respect to the issue raised. 23 | 24 | ## Technical Specification 25 | The technical specification should describe the syntax and semantics of the proposed solution for the issue raised. 26 | If a suggestion is proposed, provide sufficient details so that an implementation would be possible (Proof of Concepts are acceptable). 27 | 28 | ## Rationale 29 | The rationale should flesh out the specification by describing what motivated the design and why particular design decisions were made, as well as any alternative designs that were considered. 30 | 31 | ## Implementation 32 | An implementation must be completed before any UMIP proceeds to “Last Call” status. 33 | 34 | ## Security considerations 35 | All UMIPs must include a discussion of the security implications/considerations relevant to the proposed change as well as proposed mitigations. 36 | A UMIP cannot proceed to “Final” status without a sufficient security review from the core team. 37 | --------------------------------------------------------------------------------