Disclaimer
The content of this summary, as well as the full audit report, should not be construed as financial advice; financial decisions should not be made based on conclusions derived from said documents. While several Indigo Protocol vulnerabilities were discovered during the audit and subsequently resolved, this does not mean that the Indigo Protocol is without risk or free of vulnerabilities. Users should, and are encouraged to, perform their own research and make their own risk assessments before using the Indigo Protocol.
Audit Summary
The Indigo Protocol has been developed with a goal of managing billions of dollars worth of assets. As a result, protocol security has been and remains the highest priority. In addition to following internal best practices and leveraging automated testing, to date two complete audits of the Indigo Protocol smart contracts have been conducted by independent expert audit teams. The first full-scale audit was completed by Tweag in November, 2021 (and can be found here).
The second audit by MLabs was structured in two phases. The first phase was a three week pre-audit phase which began in September 2022. This was followed by a full final audit of the on-chain code that was conducted from October through November 2022. This included every validator and minting script that have since been securely deployed to Cardano’s mainnet.
The MLabs full audit report is available here for everyone to read through for greater insight into Indigo’s security posture. Below we highlight several key findings.
In total, 17 vulnerabilities were discovered by the MLabs audit team during the full audit and assigned the following severity ratings:
- 3 were deemed critical;
- 4 were deemed medium;
- 6 were deemed low; and
- 4 had no severity level
All vulnerabilities of critical severity level and most of those with a rating of medium, low, or without any rating were fixed and re-audited prior to mainnet launch. This article describes the three vulnerabilities rated as critical, and elaborates on why some of the other vulnerabilities are acceptable to the Indigo team as “Not Fixed.”
Audit Findings
Vulnerability: 3.2.1. Incorrect validation of CDP liquidation transactions allows burning arbitrary amount of iAsset from the Stability Pool
Severity: Critical
Status in the report: Fixed
Description: The CDP validator script contained an incorrect validation of CDP liquidation transactions, which may have resulted in allowing a full liquidation to burn more iAssets from the Stability Pool than the actual debt owed in the CDP.
Justification: This vulnerability was addressed as soon as it was reported, then re-audited before mainnet launch, and is now considered fixed by the auditors.
Vulnerability: 3.2.2. Incorrect validation of poll shard merging allows stealing of poll tokens
Severity: Critical
Status in the report: Fixed
Description: The Poll validator script contained an incorrect validation of transactions merging poll shards. This vulnerability could have resulted in an attacker stealing ADA and poll tokens from poll shards. With the poll tokens, an attacker could have created malicious polls to pass DAO Governance.
Justification: This vulnerability was addressed as soon as it was reported, then re-audited before mainnet launch, and is now considered fixed by the auditors.
Vulnerability: 3.2.3. Incorrect validation of Proposal execution allows stealing of the Upgrade Token
Severity: Critical
Status in the report: Fixed
Description: The Governance validator script contained an incorrect validation of transactions executing a proposal. This vulnerability may have allowed an attacker to obtain an Upgrade Token by creating a transaction spending two Upgrade Tokens belonging to proposals of the same type (e.g. two Text Proposals). With an Upgrade Token, the attacker could have executed malicious proposals.
Justification: This vulnerability was addressed as soon as it was reported, then re-audited before mainnet launch, and is now considered fixed by the auditors.
Vulnerability: 3.2.4. Missing check in the CDP validator to ensure that inputs from other scripts are spent with the correct redeemer is unsafe
Severity: Low
Status in the report: Not Fixed
Summary: When a transaction to liquidate a CDP is built, one of its inputs is a Stability Pool UTxO, which should be spent with a specific Stability Pool redeemer. The CDP validator script does not explicitly check whether this is the case. This could potentially turn into a vulnerability if the Stability Pool validator were to be changed via a protocol upgrade.
Justification: This vulnerability may only be exploited if a future protocol upgrade is not properly audited. As per the Indigo DAO Constitution and Voting Procedures, all protocol upgrades will undergo audits for both the upgrade process as well as the code intended to be deployed. Accordingly, the Indigo team feels that this vulnerability has been accounted for.
Vulnerability: 3.2.6. Creation of duplicate iAssets results in invalid protocol state
Severity: Medium
Status in the report: Not Fixed
Summary: The protocol expects iAsset on-chain names to be unique but does not prevent iAssets with the same name to be whitelisted. This could be problematic if two iAssets with the same name were created, as this would result in having two Stability Pools for the same iAsset name.
Justification: Whitelisting of iAssets requires going through DAO Governance, therefore such a scenario can be caught during the temperature check and poll process and voted down if it were to reach the stage of an on-chain proposal. In addition, the Indigo Web App will not allow creation of a proposal for an iAsset that already exists, avoiding such a proposal to be created by mistake. If such a proposal was still created, this proposal will be flagged as malicious and in breach of the Indigo DAO Voting Procedures when it appears on the web app via on-chain querying, thus encouraging DAO Members to vote down proposals in violation.
Vulnerability: 3.2.9. Potential Governance Power Misuse
Severity: Low
Status in the report: Not Fixed
Summary: The Governance system is an essential aspect of the Indigo protocol and allows for many aspects of the protocol to be changed (e.g. MCR of existing iAssets, and updating logic of validators for various contracts such as the Stability Pool). Given these changes could affect the behavior of the protocol, such powers could be misused.
Justification: The Governance system has been designed to allow the DAO to become a steward of the protocol to achieve true decentralization. Protective governance features, such as Adaptive Quorum Biasing, were designed to safeguard the protocol from any misuse of power or malicious proposals. Additionally, Indigo’s token distribution schedule ensures a diverse distribution of INDY, further decentralizing from any concentrated control and preventing any single entity or group of entities from power misuse. The Indigo team feels that these structural measures sufficiently address this potential vulnerability.
Vulnerability: 3.2.11 Locked Ada values in multiple protocol UTxOs
Severity: Low
Status in the report: Not Fixed
Summary: A number of UTXOs associated with Version Registry, Poll Manager and Stability Pool validator scripts and containing ADA values could be indefinitely locked due to expiry mechanics implemented in the protocol.
Justification: This issue covers a few different endpoints: Version Registry, Poll Manager, and Stability Pool:
- Version Registry: ADA is locked in a UTxO to act as a read-only upgrade endpoint. Data stored at the Version Registry is used to process the upgrades for the protocol, so they must be stored for an indefinite period of time.
- Poll Manager — There is an edge case in which the Poll ADA could be locked indefinitely, which may occur if the poll owner does not retrieve their ADA before the expiration period. This is unlikely as a poll owner will have 7 days to withdraw the funds they’ve deposited if the proposal has been passed and is incentivized to do so or else face the loss of their ADA.
- Stability Pool — The Stability Pool validator has a UTxO called “EpochToScaleToSum” that acts as a read-only endpoint for the Stability Pool in certain edge cases where the Stability Pool is depleted or a large liquidation took place against it. When the epoch or scale of a Stability Pool is updated, the protocol sometimes utilizes a read-only UTxO that is then referenced for calculations of iAsset/ADA rewards.
UTxOs that may store ADA indefinitely are not user-funded UTxOs. Instead, these UTxOs are used by the protocol and typically paid for (often ~1.5 ADA) by bot owners or entities familiar enough with the protocol to handle those requests and who are willing to provide that value with their ADA for the benefit of all users of the protocol.
Vulnerability: 3.2.13. It is possible for the staking position datum to grow infinitely, resulting in the datum not fitting into the Tx
Severity: Low
Status in the report: Not Fixed
Summary: The staking position datum stores all the proposals that a user has voted on. This is stored in a specific data structure that is unbounded, meaning there could potentially be an unlimited amount of information stored. This unbounded property may result in the datum becoming too large to fit in a Cardano transaction. To cause this behavior of transactions becoming too large, a user would need to vote on many simultaneous proposals.
Justification: When a user stakes INDY within the protocol, a staking position is created containing some datum. Each time the user votes, the datum grows in size. If the datum grows too large, users will be unable to vote on more proposals until the datum is reset. If a user attempts to vote more times than the datum allows then they’ll experience a transaction error. To resolve this, users can unlock their INDY after proposal voting periods expire, thereby resetting the datum of their staking position. This allows the user to continue voting on new proposals as they’re presented on-chain. In the Indigo Web App, this issue will be addressed to limit active on-chain proposals to a maximum of 3 to help prevent users experiencing transaction errors.
Vulnerability: 3.2.15. Lack of tests for helper functions
Severity: None
Status in the report: Not Fixed
Summary: There were no unit tests for the helper functions used throughout the protocol. A lack of tests means the code behavior is not fully determined and cannot be relied upon. Although some of these functions are indirectly tested through transaction tests, some edge cases might be missed.
Justification: This potential code maintainability issue has been addressed with unit tests for helper functions created and used before mainnet launch. The helper functions were heavily tested via other integration tests throughout the protocol. More tests have been added after the audit concluded, which is why this issue is still flagged as “Not Fixed” in the report, though no longer a present issue.
Vulnerability: 3.2.17. Missing integration tests with the real Cardano environment risks unexpected issues during deployment
Severity: None
Status in the report: Not Fixed
Summary: Currently, Indigo’s test suite uses the Plutus Simple Model testing framework, which is like emulator traces and is used to estimate program resource usage and assert correctness. However, testing and running Plutus programs in a real Cardano network is essential as various issues can arise when dealing with not deterministic parts of the blockchain like contention, slot timing, or block validation.
Justification: The Indigo Protocol was deployed to testnet and heavily tested against a real Cardano network through many real-world use cases and edge cases. In addition, after finalizing the audit, additional tests leveraging Plutip were implemented. This confirmed that the on-chain and off-chain code both function as expected on any Cardano network. Furthermore, the Indigo Protocol was successfully deployed to Cardano mainnet on November 20th, 2022 without issues, therefore the deployment process is now complete and tested.
Website | Discord | Telegram | Twitter | Indigo Paper
