Introduction
The Indigo Labs is honored to present these recommendations to develop Indigo Protocol V2. This Temp Check and Proposal is presented as part of the services Labs has been hired to provide under the DAO-approved Services Schedule from last April. Our goal with this proposal is to present recommendations to the DAO to most efficiently foster the continued growth and enhancement of the Indigo Protocol.
It should be noted at the outset that, as with any development effort, we do not recommend including every possible feature or improvement in this V2, but try to strike a balance between the most important features and the best development schedule for the soonest possible implementation.
The Labs team has worked closely with the Protocol Working Group and the Technology Working Group in developing and refining these recommendations. PWG and TWG members are available to discuss and share their views on these proposals as well.
This Proposal is organized by reviewing three recommended new features first, and then listing six improvements to existing features.
We look forward to a free and open discussion of the recommended V2 features and improvements with the Indigo community.
New Features
To help the Protocol evolve and adapt, we propose several new features designed to address existing issues and enhance functionality. Below, we outline our recommendations by first articulating the problem we are looking to address and then outlining the solution we propose (and occasionally explaining why other possible solutions were considered but are not suggested):
Redemption Mechanism
Problem:
Following the several day period in April and May 2023 when the price of iUSD was below the target $1 USD price, it was clear that iUSD struggled to maintain its peg during significant market shifts and changes in demand for yields across various protocols. As different decentralized applications (dApps) may incentivize the use of particular digital assets like iUSD, the utility of iAssets may be threatened if theyâre unable to maintain their peg outside the Indigo environment, such as on AMM DEXs.
Depegs such as these hinder the utility of iAssets in other dApps, such as lending markets where iAssets can be used as collateral.
This proposal seeks to address this issue by implementing a redemption mechanism. Redemption is a feature which can enhance the resilience and stability of iAssets, collateralization ratio improves with redemption and a semi-hard peg helps to improve the range iAssets is traded between. It is widely used in popular Ethereum-based synthetic asset dApps, but its operation in a UTXO dApp involves some unique challenges.
Solution:
A redemption mechanism will minimize downward deviation of iAssets from its oracle price. There is no existing and tested redemption mechanism compatible with the UTXO model of the Cardano blockchain, however. Considering the common similarities in liquidation mechanisms, the Liquity redemption model on the Ethereum blockchain is the inspiration for this proposed solution.
All iAssets currently in circulation correspondingly represent equal debt in total CDP accounts. To introduce a redemption mechanism, it will need to access and use these existing CDP accounts. Despite certain technical challenges related to global state and the redemption against a pool of troves for Cardano, we propose an adaptation: The Redemption Margin Ratio (RMR).
Raising the RMR has a milder effect on positions compared to raising the MCR. For example, if a position is at 200%, raising the MCR to 200% would liquidate the position, resulting in a complete loss of net equity (50%). Conversely, increasing the RMR to 200% only exposes the position to potential net equity returns of 50%.
Letâs cover an example for iUSD:
Assumptions:
- ADA - 40 cents
- MCR - 120%
- iUSD RMR - 200%
We have a CDP with a CR of 130% (40000 ADA , 12307 iUSD (30767ADA equivalent)) at 40 cents. To redeem to the maximum 200% RMR, the following calculation takes place:
- Redeemable Assets = 21534 ADA (8613.6 iUSD)
Post-redemption, the CDP balance would be:
-
ADA: 18466
-
Debt: 3693.4 iUSD (9233 ADA)
-
New CR: 200%
The redeemer, on the other hand, would have to pay 8613.6 iUSD to unlock 21534 ADA.
The distribution of the unlocked ADA would be as follows:
- Redemption (97%): 20887.98 ADA
- DAO (1%): 215.34 ADA
- Indigo stakers (2%): 430.68 ADA
(Note: If the Indigo staker allocation changes, this distribution would adjust accordingly. For instance, reducing it to 1% would improve the peg by 1%.)
In addition, since the RMR is a protocol parameter per iAsset, the redemption mechanism can be turned off by simply changing the RMR to lower than the MCR as opposed to needing a protocol upgrade to effectively turn off RMR.
Furthermore, RMR limits redemption up to the decided RMR ratio, this allows the flexibility for users who do not wish to have their CDP subject to redemption by simply having a higher CR.
In summary, this proposal recommends the implementation of a Redemption Margin Ratio (RMR) to introduce a redemption mechanism in the Indigo Protocol. This also gives the flexibility to users where a user can decide whether their own CDP is redeemable by other participants through the management of their collateral ratio. We believe that this approach will better equip iAssets to maintain their peg value, especially during market volatility, enhancing the stability and reliability of the entire ecosystem.
Treasury Unlock
Problem:
Indigo Protocol v1 restricts the utilization of INDY tokens from the DAO Treasury, preventing the DAO from using the treasury to develop the Protocol as the Indigo Paper envisions. DAO Treasury access was not enabled at the start due to resource constraints and the need for the DAO to be in place and operational before addressing spending the DAO Treasury.
Solution:
We propose an upgrade that enables governance proposals to allocate funds from the DAO Treasury. The DAO Treasury was created to provide financial support for Protocol development and improvements by giving the Indigo DAO sufficient funding to contract with various ecosystem and industry service providers.
It is important to note that all funds that are âwithdrawnâ from the Indigo DAO Treasury will be sent (by smart contract) to the Indigo Foundation.The Foundation will then be the entity responsible for coordinating the payments based on the terms of the Proposal which authorized the distribution.
Fee Improvements
Problem:
The Protocol currently generates no revenue for the DAO Treasury. It would be more ideal if the Protocol generated sufficient revenue to sustain the current and future operations of the Foundation or fund other Protocol improvements.
Solution:
We propose implementing features in V2 which will give the DAO the ability to implement transaction fees or other sources of revenue in the future based on a vote of the DAO. The Indigo Labs teams will propose some of their ideas, such as CDP debt fees and fees being distributed to DAO treasury. We think the community has a lot of valuable feedback that they can provide.
Improvements
Indigo Labs also suggests bringing several other, smaller improvements to the Indigo Protocol V2, including:
Direct Oracle Integration
We suggest extending support for more Oracle datum standards, moving beyond the initial datum standard of V1 of the Indigo Protocol. This will help current and future iAssets more easily use decentralized oracle fees, such as those from Chainlink, Charli3 and OrcFax.
Better Proposal Submission and Moderation Process
We see an opportunity to enhance the process of submitting DAO proposals. We are seeking to include an exponential proposal deposit based on the number of active proposals. This feature was originally planned for development in V1 but was set aside to not further delay launch. The Indigo Labs team believes that this feature remains needed as it will prevent a bunch of meaningless proposals being submitted on chain, perhaps maliciously.
In addition, we suggest the inclusion of a minimum proposal quorum of 50,000 INDY to be required for a proposal to pass, adjustable by protocol parameters.
Improvement to Smart Contract Efficiency
We have pinpointed several areas where the efficiency of the smart contract specification can be enhanced, thereby minimizing any additional transaction overhead. In addition to small specification improvements, we propose a transition to Aiken, which promises better readability, reduced memory and CPU usage, and increased throughput. This shift is anticipated to be a game-changer, offering numerous benefits that are detailed in our recent article: Optimizing the Throughput of Cardano: The Evolution of Indigo Protocolâs Smart Contracts.
Liquidity State Transition
With the introduction of this proposal, Indigo Labs introduces a new mechanism that we are calling âLiquidity State Transition,â or LST for short. LST is meant to be implemented as a solution for the contention issue that can occur while interacting with Stability Pools.
What is Contention within the Indigo Protocol?
Currently, when two or more people are trying to request a change to their Stability Pool Account, they are all competing to update the Stability Pool global state - whoever manages to send their transaction before the other will have their transaction committed and the other transactions will be rejected. In Cardano, a UTxO that maintains a global state is difficult to transact with, because of UTxO contention. The diagram below shows the current structure of a transaction that consumes the Stability Poolâs UTxO.
As you can see above, multiple inputs are needed: the Stability Pool UTxO, Stability Pool Account UTxO, and the funds to pay the Tx Fees. Due to the user providing the information about the requested action and the funds for the Tx Fees needed to process the transaction, it becomes a contentious action to manage. This transaction is tackling two things: requesting a change to the Stability Pool Account UTxO and the execution of the request against the Stability Pool UTxO.
Our Solution
With LST, we separate this action into two transactions: a request transaction and an execution transaction. The below diagram demonstrates the architecture of LSTâs protocol:
Referencing the diagram, instead of processing the request and execution of the stability pool adjustment in the same transaction, we separate it into two transactions. This method greatly increases the assurance that the userâs intended action will be executed on the Cardano blockchain, rather than being impeded due to the submission of a contentious transaction.
Once the request is recorded on-chain, it can then be executed by the user who initially submitted the request against the Stability Pool.
Additionally, there are two ancillary benefits with LST:
- Executing requests can be transaction-chained against other executions; and
- The user never has to re-sign an execution with their wallet if a preceding transaction fails due to contention.
Since the execution doesnât require a wallet signature and has the potential to be transaction-chained, we increase our throughput by processing multiple executions against a Stability Pool in a single block. Below, the diagram illustrates how chained transactions can be included in the same block:
As shown in the above diagram, submitting requests and executing requests can both fit into a single block, which means that a request can be executed just as it is now, however, it simply occurs in two separate transactions.
The Liquidity State Transition (LST) feature represents a significant technical advancement in the Indigo Protocolâs capabilities. It addresses key issues such as transaction contention, introduces transaction chaining, and reduces reliance on wallet re-signature. These enhancements will lead to improved transaction efficiency and user experience. This development is one of the many parts of the progressive strategy to enhance the technical infrastructure and operational efficiency of the Indigo Protocol, one of the key objectives of V2.
Conclusion
If the Indigo Protocol v2 proposal garners swift approval, we are optimistically targeting a launch in Q1 2024. To keep the community informed and maintain transparency, we will provide regular progress updates on the development of the proposed solutions. Our current timeline sets the initiation of the audit phase for February 2024, followed by the submission of the upgrade proposal in March 2024. This upgrade proposal will detail the final launch parameters for all the newly introduced features. Importantly, any upgrades will be seamlessly executed through governance, ensuring a smooth transition and implementation. Due to the current implementation of Governance, users will not have to make any actions to upgrade their existing CDPs, Stability Pool Accounts, Staking Positions, or iAsset tokens to the V2 contracts.
We encourage the community to engage in discussions surrounding the proposed items and to contribute thoughtful input and suggestions. We will provide more explanation of some feature improvements and host a community call to discuss community feedback. We believe in the power of the Indigo DAO to ensure a promising future for the Indigo Protocol, and hope to earn everyoneâs support for this Temp Check and the eventual Proposal.
Changelog
Wed, Nov 15th, 2023
- Updated the Liquidity State Transition section with more detail.
- Removed âMitigate Bank Run Scenario Severityâ section in lieu of Liquidity State Transition.
- Added visual diagram to âRedemption Mechanismâ section to help readers understand the solution.
