Summary
The purpose of this governance post is to address the community’s concerns with IIP-29, galvanize support for Intrinsic Productivity (IP) for DPI, and ensure quorum is reached when Decision Gate 2 (DG2) voting takes place.
@kiba outlined an actionable plan for the DeFi Pulse Index (DPI) to earn yield in IIP-29 Active DPI Intrinsic Productivity.
IIP-29 was advanced to Decision Gate 1 (DG1) and voting on Snapshot happened between May 3 and May 6. The community was overwhelmingly in support of the proposal with over 80% of voting INDEX voting FOR.
If implemented, IIP-29 would be the Coop’s first step towards implementing IP for DPI. It would immediately generate ~50 bps in passive yield for DPI holders from SUSHI and YFI, and create an iterative process for generating yield from the other assets in DPI. All yield generated from IP would be returned to DPI holders, making DPI more attractive to hold, and therefore fuel AUM and revenue growth for the Coop.
This governance post summarizes two possible approaches to implement IIP-29 for the community to comment and discuss (see Community Sentiment Polls below).
I put out a call for feedback to those who either voted AGAINST or who abstained from voting, and learned that many influential contributors and community members were AGAINST the proposal. I sought to understand and learn from their concerns.
There were 3 common arguments AGAINST the proposal:
-
Extrinsic Productivity (EP) integrations: IP for DPI may risk DPI being added as collateral to DeFi lending protocols like Maker, Aave, CREAM, etc.
-
Centralized Exchange (CEX) listings: IP for DPI may risk DPI being listed by CEXes like Coinbase or Binance, and even potentially risk delisting from KuCoin and BitMart.
-
Product Prioritization: IP should be implemented for SMI or MVI before DPI.
Importantly, none of these arguments are against IP for DPI in principle, but about how best to implement IP in practice and when to do it.
One approach to break the impasse is to implement IP for DPI as a separate product (iDPI). The following is intended to summarize the arguments in favor of a one product approach vs a two product approach for activating IP. In other words, should IP be activated for DPI or should it be implemented as a separate product?
One Product Approach: Arguments to activate IP for existing DPI product
-
Liquidity: Prevents facturing of liquidity across separate products.
-
Lower Internal Costs: Lower development, maintenance, and marketing costs for Coop stakeholders (Set, Pulse Inc, and Community) than for two products. The two product approach would require the Coop to repeat Extrinsic Productivity (EP) proposals for the iDPI product; the one product solution does not require duplication of work.
-
Speed: Faster to activate IP for DPI than to launch a new product, iDPI.
-
Avoids Cannibalization: If iDPI largely cannibalizes the DPI product, then launching two products would be a waste of Coop resources.
Two Product Approach: Arguments for separate product with IP (i.e. iDPI)
-
EP Integrations and CEX listings: Does not further complicate or risk EP integrations or CEX listings for DPI.
-
Lower External Costs: Activating IP for DPI may impose costs in terms of smart contract development, risk analysis, security/legal analysis, on EP integrators (Maker, Aave, etc.) and CEXes (KuCoin, Bitmart, etc.). Having two products lets EP integrators continue using DPI and allows them to integrate iDPI as collateral and / or CEXes list it after iDPI has proved product-market fit.
-
Unlock New Market: Potentially serves two different customer bases and increases revenue for the Coop.
Community Sentiment Polls
- Do you want the Coop to move forward with IP for DPI via a one product or two product approach?
- One Product: Introduce IP features to the existing DPI product
- Two Products: Launch a second product so we have DPI and iDPI
0 voters
-
If the Index Coop decides to run two products (DPI and iDPI) in parallel, we can choose one of the following options to implement:
a) Launch a new iDPI product and facilitate migration (deposit DPI in contract, then x Days later receive iDPI once product is launched)
b) Migrate all current DPI to iDPI unless holders actively opt out.
If the Index Coop decides to run two products in parallel, would you prefer?
- Option A: Existing contracts / tokens etc should remain DPI and iDPI use new contracts etc with migration.
- Option B: Existing contracts / tokens should be converted to iDPI unless holders opt-out.
0 voters
Edit for Clarification Purposes: The “vault model” described in the comments below would be a subset of the two product approach (options 1a and 2a.). The vault model is intentionally not included in the voted as it needs to be vetted among other technical implementation options from an engineering perspective.
Request for Comment:
-
Maker Risk and MOMC - @monet-supply: In your view, does the one product solution risk or push the prioritization of DPI being added as collateral by Maker (it’s currently #8 in Maker’s Collateral Framework)?
-
Index Coop, Business Development - @reganbozman: Do you agree activating IP for DPI (1 product solution) would further risk or jeopardize exchange listings? Do you view this as a legitimate reason to pursue the two product approach?
-
Pulse Inc - @scott_lew_is / @Jo_K : Does Pulse Inc have the resources to support the two product approach at the present time? Can Pulse Inc support maintaining both DPI and iDPI or would that require too much operational overhead?
-
Set Labs - @richard: You had suggested pursuing IP for SMI as a path forward to activate IP. Punia said in the Product Working Group meeting on May 17th that the possibility of implementing IP for SMI should not be considered as part of the analysis for IIP-29. Other than prioritization considerations, does Set Engineering have reasons to favor the one product or two product approach from a technical standpoint?
-
@oneski22 : Does the two product approach above mirror what you outlined in the IIP-29 governance post?
-
Additional Commenters: @trx314 , @DarkForestCapital , @verto0912