Temperature Check for DAO Approval: Proposal to Develop Indigo Protocol V2


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


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.


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:


  • 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


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.


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


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.


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.


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:

  1. Executing requests can be transaction-chained against other executions; and
  2. 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.


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.


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.

LFG!! :metal:



Hi, can you provide a real life example of how new redemption approach would incentivise users to push iUSD towards $1 peg? What you provided in the proposal is not clear. Thanks!

1 Like

When it’s below $1 (or $0.97 based on the fees) on a DEX you can arbitrage by redeeming it on Indigo.


like… how exactly? Buy iUSD with ADA and then go to Indigo and do what if I do not have CDP? Or if I have CDP but do not want to close it at the moment?

1 Like

It would be redeemed against other people’s CDPs which are below the RMR as described.

1 Like

You can purchase iUSD on dexes which is for example trading around 93cents and go to the protocol and redeem it for 97cents worth of ADA against risky CDP below the RMR. making a 4 cents profit.
Repeating this will push the dexes price towards 97 cents.

1 Like

Could you please share a real life example? How someone else can fiddle with my CDP?

1 Like

So you say, i buy iUSD at $0.95 with 100 ADA, then go to protocol, choose someone else’s CDP where collateral is below RMR and above liquidation level, repay/burn iUSD i bought to to get 105 ADA back… from collateral? From where? What happens with someone’s else CDP?

Regarding the switch to Aiken, would that not necessitate the Aiken compiler to be formally verified before the contracts could be released? It seems they’re on track for Q4 this year so far at least. If not, can the generated UPLC be audited itself?

1 Like

It will be from someone else CDP that is below RMR.
So the CDP that is being redeemed against will have a reduction in both ADA and Debt resulting in higher CR

Regarding the redeeming mechanism proposal, is it possible model how this would have affected the current CDPs since the depeg (in September 29)? I was thinking more how many CDPs would have been affected after the whale minted 1M iUSD and started dumping for ADA. How many CDPs would have been affected? Would it be possible to repeg with the current CDPs? It would be nice to have visual representation of the amount the whale sold and how the CDPs would have changed over each iUSD sell order.

Another question, why the RMR rate of 200% was chosen? (I am not criticizing if that’s too high or too low, I am just curious about rationale behind that choice).

1 Like

So far, after asking the same question several times which is ‘please give me a real life end-to-end example with numbers of how new redemption will work exactly to incentivise users to keep 1 iUSD pegged to $1 USD and what is the impact on those CDP owners whose CR will be above liquidation and below RMR’ I have not received a straight answer (I appreciate the replies though very much). It would be great if @CodyCodes has a chance to give such examples. Otherwise I am against this new redemption approach because 1) not clear how / from which funds users will be receiving collateralised assets for burning iUSD via someone else’s CDPs; 2) it seems like CDP owners with CR below RMR will lose control over their CDPs, or at least it seems so from the answers.

1 Like

This is a good question! I think that this would be relatively important that there be some trust in the underlying language used by the smart contracts. Your question has led me to ask the Aiken team their plans. It seems they have been playing with lean to see what can be done. It sounds like the expectation is that this may not occur by the end of the year but is coming.

As for your question about this being necessary. I’m not sure this is absolutely necessary. I am happy to be stand corrected, but I do not believe PlutusTx, Plutarch, or any other language in the ecosystem (including UPLC itself) have been formally verified.

To be frank, our team is more concerned about the stdlib being audited rather than the compiler itself. This is why we have spent a lot of time on positive and negative tests within our test suite. As we near launch we will have the aiken smart contracts audited just as we did in V1. In addition, we do have a bug bounty program and the smart contracts will be open sourced.


Hello Vlashe!

We saw your question and are working to respond in a long-form way with more details. However, I will try to respond with a quick example.

The redemption mechanism really just enables you to arbitrage between DEXs and CDPs on Indigo. Right now iUSD on MinSwap is trading at $0.92. A user who would want to help maintain the peg would purchase iUSD on the DEX (essentially raising the price), and then sell it back to CDPs on Indigo using the Redemption Mechanism.

When utilizing the redemption feature what you are doing is purchasing ADA for iAsset from CDPs who are not maintaining a collateral ratio above the RMR.

For example: The iUSD is reporting that the ADA/USD price is 0.2854 (or 3.503 USD/ADA). There is a CDP with 60,000 ADA collateral and 10,000 iUSD minted (their CR is 171%). The redeeming user would purchase (let’s say) 2,876 iUSD from MinSwap at 3.26 iUSD/ADA (totalling 9375.76 ADA). The redemption mechanism would allow the redeeming user to select that CDP, burn the 2,876 iUSD and get a 9,776 ADA returned to them. This would in addition increase the collateral ratio of that CDP to 200%.

It should also be noted that any CDP under the RMR can be selected, there is no “first come first serve” or any mechanism like that.

I hope this helps you understand until we can get more diagrams and better documentation ready for you guys to consume.

1 Like

Thanks! So 9,776 ADA in your example is returned from the collateral of a selected CDP? So for a CDP owner it essentially means her/his ADA collateral gets sold at the current USD/ADA rate? Randomly (i mean, their CDP may be chosen / may be not)? So for CDP owners new redemption mechanism is less capital effective (i.e. they will have to maintain RMR above 200%, more collateral will be required locked)?

1 Like

Currently around 300 CDPs is below 200% RMR for example.
This represent less than 800k redeemable partially due to the run up in ADA.
It would mean everyone will be bumped up to minimal 200% CR if similar event were to happen.

The peg will then be allowed to depeg beyond 0.97 due to the outsize event.

That is the fundamental design of the RMR that differs from unlimited redemption from other protocols.
A lower peg instinctively reduce the demand for leverage through capital inefficiencies.
Unlimited redemption will allow a whale to effectively takeover all CDPs

This mechanism introduce a semi hardpeg that is slightly more versatile.
Pegging without using fiat back stablecoin isn’t yet solved in the whole space, whether using stableswap or directy as collateral.

RMR isn’t seeking to peg at par. it only seeks to provide the flexility to manage such event.
Remember, there is also a soft peg component.


First and foremost i want to thank the team and technical committee for their hard work and clear presentation of the problems and proposed solutions. Indy is #1 most popular dapp on cardano so clearly it was built right.

I support the general direction of all of the proposals, except the RMR redemption mechanism. I think its important we take a step back and remember who we are here. We are a synthetic derivatives platform not a stablecoin protocol.
As such users should be very clearly advised of the risks of investing in derivatives as opposed to actual underlying asset.

Derivetives will always carry the risk of trading at a premium or a discount to the underlying assets they represent, particularly at times of significant changes to the overall market conditions. RMR or not, discounts and premiums will occur as sentiment changes quickly, which some view as a problem while others view as opportunity.

First - why 200% RMR? I see no justification to this number aside from a vague reference to some eth synthetic protocols usage of something similar. Would like to see justification for such a change include far more risk based analysis.

Second - I am strongly against any outside third party being able to redeem against somebody elses cdp. The person who holds the CDP is taking on all the risk here and this third party is able to profit risk free against somebody elses CDP by sniping cheap iUSD off the markets and redeeming it at the CDP owners expense. I find this completely unethical and i believe #1 it disincentivizes deposits to the stability pools which protect the protocol, and #2 disincentivizes creation of CDPs due to risk of losses as a result of opportunistic market scalpers f’in with your cdps.

#3. One of the primary drivers here seems to be the idea of meeting liqwids ultimatum that iUSD have a redemption feature before it can be considered eligible as collateral. Getting listed as collateral on liqwid will further incentivize leveraged shorting of iUSD and further snowball the downward depeg this proposal is trying to solve in the first place. This could completely backfire when people go hogwild shorting iUSD on liqwid, which is a distinct possibility particularly if its incentivized.

I think this proposal should be removed in its entirety for v2 and addressed separately later down the road and any potential solutions should be based on a thorough fact based risk assessment comparing existing parameters of the protocol to the proposed parameters of the protocol.

Thanks for considering my concerns. Love indigo and love the hard work and efforts of labs and the technical committee to enhance the very best #1 protocol on the entire cardano blockchain.


Hey @k-stack Thanks for the great feedback.

#1 - 200% was suggested based on redeemable relative to the amount that was sold at depeg in early October.
As of current 200% will result in roughly 500k redeemable.

#2 - The redemption itself is just a starting point. There is the reason why the redemption doesn’t happen in 1:1 basis.
The fees involve ensure there isn’t any such opportunity if peg is above the nett redemption rate.
Perhaps some of the redemption fee can be directly accrue to the CDP accounts rather than INDY takers.
I do understand with your overall point on this though.
Further more once the parameters around a hard peg is formed. Additional mechanisms can be introduced to oscillate the peg above a redemption rate.

#3 - Redemption isn’t exactly done for other protocols. But having iUSD being the largest supply while not being the collateral allow for looping with iUSD being the exit. This will happen as long as there is possibility of leveraged yield in other protocol.

1 Like

Im ok with implementing RMR as I understand the greater need for it. Personally I like the free market approach to iUSD but I get that’s not ideal for mass adoption and user confidence. I do wonder if by the time a redemption mechanism is ready for deployment it may be too little too late as we will have much more competition in the stables space.

As for choosing a direction for addressing liquidity state transition and mitigating a bank run scenario, I really want to hear from the Technical working Group on these different options. What would be the pros and cons of the different options. Could someone model some examples so we can have a better understanding of the options and their effects on the protocol?

Liquidity State Transition

Option 1: Bundled Requests
Would this favor whales who can justify paying the entire fee. During volatile times fractional orders may process quite quickly as many users are offering fractional orders, whereas during none volatile times users offering fractional orders could wait hours or days for their fractional order to process?

Option 2: Fixed Fee Requests
Who would be the “processors” and what sort of incentives will drive their actions.

Option 3: Fee Market
Would this favor whales while the shrimp are more often liquidated because they can’t afford the high fees?

Mitigate Bank Run Scenario Severity

Option 1: Periodic Withdrawals
So SP transaction requests would be allowed to accumulate for a once every 10 minutes transaction that processes all that accumulated all at once?

Option 2: Increased Withdrawal Fees
Would the fees collected be distributed as rewards to SP stakers or added to their staked position?

Option 3: Rate Limited Withdrawals
How long of a wait during volatile times? So transaction requests would not fail but rather just take say 10 minutes to fulfill?