Delving into the Security Implications of Fee Structure in a CDP protocol

Contact: billh

Introduction

In the rapidly evolving world of DeFi, ensuring protocol stability and security is essential. During a recent security review of a CDP project, I observed how specific vulnerabilities could arise under certain configurations. While the current parameter settings in this project are robust, understanding these potential risks is crucial for maintaining the protocol’s integrity.

This article aims to explore the critical role that one-time borrowing fees and redemption fees play in this context. By examining specific exploit scenarios that could arise without these fees, I will demonstrate how a proper fee structure is essential to preventing destabilizing attacks, thus ensuring the long-term security and viability of the protocol.

Overview of the Protocol’s CDP Mechanism

Drawing inspiration from one of the original protocols, Liquity, and its derivatives, many CDP (Collateralized Debt Position) models generate decentralized stablecoins through over-collateralization. These models often incorporate a complex yet sophisticated set of mechanisms designed to maintain the peg to the U.S. dollar while ensuring the protocol’s security under various conditions, effectively minimizing the risk of bad debt. These protocols distinguish themselves through key customizations, including tailored economic incentives that align more closely with the protocol’s specific objectives.

Key Concepts of the Protocol

1. Borrowing

• Users can leverage their collateral holdings to borrow the protocol’s stablecoin.
• Collateral is deposited into a Trove — a vault that holds the collateral and tracks the associated debt.

2. Collateral Ratio (CR)

• The Collateral Ratio is the ratio of collateral to the stablecoin debt within a Trove.
• The protocol enforces a minimum collateral ratio (MCR) of 110%, meaning that for every $1,000 of stablecoin borrowed, at least $1,100 worth of collateral must be held.

3. Redemption

• To maintain the stablecoin’s peg to the U.S. dollar, users can redeem the stablecoin for its underlying collateral at a rate of 1 stablecoin to $1 worth of collateral.
• During redemption, the system selects Troves with the lowest Collateral Ratio (CR) to fulfill the redemption, meaning that users with the riskiest positions are the first to be redeemed against.

4. Liquidation

• If a Trove’s CR falls below the MCR, the Trove is subject to liquidation.
• During liquidation, the stablecoin in the Stability Pool is used to repay the debt, and the corresponding collateral is redistributed to the Stability Pool, benefiting the stakers.

5. Recovery Mode

• Recovery Mode is activated when the Total Collateral Ratio (TCR) of the entire system falls below 150%.
• During this mode, only Troves with CRs above the TCR can be created, and liquidations are prioritized to restore the system’s overall health.
• In Recovery Mode, Troves with CRs below the TCR can be liquidated, even if their CR is above the minimum collateral ratio (MCR). This is done to restore the system’s overall health.
• Borrow and repay operations that would bring the system into Recovery Mode are prohibited.

Understanding One-Time Redemption Fee and Borrowing Fee

Redemption Fee

The redemption fee is a charge applied when a user redeems the protocol’s stablecoin for its underlying collateral. This fee is designed to stabilize the value of the stablecoin by making the redemption process costlier when redemptions are frequent, thus preventing excessive redemptions that could destabilize the protocol.

The redemption fee is calculated based on the protocol’s baseRate, a dynamically adjusting parameter that reflects the recent activity within the system. Specifically, the baseRate increases with each redemption, making subsequent redemptions more expensive.

This increase is proportional to the fraction of the total stablecoin supply that is redeemed. Over time, if no redemptions occur, the baseRate gradually decays back to zero, with a half-life of approximately 12 hours.

The redemption fee is calculated using the formula:

For example, if the baseRate is 1% and a user redeems 100 stablecoins when the price of the collateral is $50,000, the redemption fee would be:

Thus, the user would receive slightly less collateral after accounting for the redemption fee. This mechanism ensures that redemptions remain economically sensible while protecting the protocol from destabilizing arbitrage activities.

Borrowing Fee

The borrowing fee is another one-time fee that is charged when a user borrows stablecoins against their collateral. This fee is similarly based on the baseRate, but it applies at the time the stablecoins are drawn from the user’s Trove (a vault contract holding the user’s collateral and debt).

The borrowing fee is calculated as follows:

For example, if a user wishes to borrow 4,000 stablecoins and the baseRate is set at 0.5%, the fee would be:

This fee is added to the user’s debt, meaning their total debt would be the amount borrowed plus the fee (e.g., 4,000 stablecoins + 20 stablecoins = 4,020 stablecoins).

These fees also act as soft pegs, indirectly influencing the stablecoin’s market price by making it less attractive to borrow or redeem under certain conditions, thereby helping to keep the stablecoin closely pegged to $1.

Now, let’s explore what could happen if these crucial fees were removed or set to zero.

Exploit Scenarios Without One-Time Redemption Fee

Zero Slippage Swap DEX

Without a one-time redemption fee, the protocol could inadvertently transform into a zero-slippage swap DEX. In such a scenario, large stablecoin holders could exploit the redemption mechanism to swap stablecoins for collateral without incurring significant costs, effectively performing large-scale arbitrage trades. This could lead to several negative outcomes, as in this zero-slippage environment, large-scale redemptions would not only drain the protocol’s liquidity but also force borrowers to sell their collateral at the current market price. Although their debt would be reduced accordingly, this forced liquidation could increase operational costs for users, particularly if the stablecoin is trading below $1.

Additionally, there is a risk of oracle front-running: if a user notices that a transaction is about to update the collateral price oracle to reflect a higher price, they could quickly redeem a large amount of stablecoin before the price update. Once the collateral price is updated and rises, the user could then sell the redeemed collateral at a profit, completing an arbitrage cycle. This practice not only exploits the protocol but also leaves borrowers at a disadvantage, as they might be forced to sell their collateral at less favorable prices.

Exploit Scenarios Without One-Time Borrowing Fee

Redemption Fee Manipulation

One of the most straightforward exploit scenarios involves manipulating the redemption fee to reduce costs. In protocols where there is no one-time borrowing fee, users can borrow large amounts of stablecoin, artificially inflating the protocol’s total debt. Once the debt is inflated, they can redeem their stablecoins at a lower fee, as the redemption fee is calculated based on the ratio of the redemption size to the total debt.

This manipulation undermines the protocol’s intended fee structure, leading to reduced revenue for the protocol and potentially destabilizing the system. For example, attackers can use flash loans to borrow large amounts of collateral, which they then use to mint a substantial amount of stablecoins, thereby increasing the system’s total debt. They then perform a redemption operation, benefiting from the reduced fee due to the inflated debt, and finally repay the flash loan, leaving the protocol with less revenue than expected and can lead to further instability for those users who might not have anticipated being targeted for redemption.

Forcing System Recovery Mode via Oracle Update Transaction Sandwich

Another critical vulnerability arises from the ability to force the protocol into Recovery Mode in a single block, thereby enabling the liquidation of positions with previously healthy collateral ratios. This exploit relies on leveraging flash loans and timing the attack around an oracle price update.

The attack unfolds as follows:

1. Flashloan and Borrow:

The attacker first uses a flash loan to borrow a large amount of collateral, which is then deposited as collateral in the protocol. Using this collateral, the attacker borrows stablecoins at the Minimum Collateral Ratio (MCR). The attacker can take this action to drive the Total Collateral Ratio (TCR) down to 150%, the threshold for triggering Recovery Mode.

2. Oracle Price Update:

The attacker waits for an oracle update that reflects a drop in the collateral price. As the new lower price is updated in the system, the value of the collateral drops, causing the TCR to fall below 150%.

3. Triggering Recovery Mode and Liquidation:

With the TCR now below 150%, the protocol automatically enters Recovery Mode. In this state, the protocol allows the liquidation of Troves with Collateral Ratios (CR) below the new TCR. The attacker can then proceed to liquidate other users’ Troves that now have a CR below the TCR, causing losses to them and profiting from the liquidation rewards.

Forcing System Recovery Mode via Crafted Redemption

Building on the previous attack scenario, this advanced exploit allows an attacker to force the protocol into Recovery Mode through a carefully crafted redemption process. Unlike the earlier attack, which may temporarily return the system to normal mode after liquidation, this method ensures the system remains in Recovery Mode, allowing the attacker to repeatedly exploit the vulnerability.

The core issue, which arises when the system supports multiple types of collateral, each managed by different Trove Managers, lies in the potential for the system-wide Total Collateral Ratio (TCR) to decrease following a redemption, even as individual Trove Managers’ health improves. This counterintuitive outcome is a result of the complex interplay between global and local collateral ratios.

For instance, consider a scenario where the system’s TCR is at 150%.

If a user redeems against a Trove with a 160% collateral ratio, causing that Trove to close, the resulting calculation

would push the TCR below 150%, triggering Recovery Mode.

The attack unfolds as follows:

1. Setup of Initial Position:

The attacker opens a minimal position with a collateral ratio slightly above 150% in a carefully selected Trove. This setup is crucial for ensuring that the redemption in the next step effectively drives the TCR below the critical threshold.

2. Manipulation of TCR:

The attacker uses a flash loan to open another position with a collateral ratio at the Minimum Collateral Ratio (MCR) of 110% in any Trove Manager, bringing the system’s Total Collateral Ratio (TCR) down to exactly 150%. This step primes the system for Recovery Mode.

3. Crafted Redemption:

The attacker then redeems the position opened in the first step. Because this position has a CR slightly above 150%, redeeming it causes the TCR to dip below 150%, thereby triggering Recovery Mode. The redemption not only impacts the specific Trove being redeemed but also causes a systemic effect that pushes the TCR into Recovery Mode.

4. Liquidation of Vulnerable Positions:

With the system now in Recovery Mode, the attacker can liquidate any position with a collateral ratio below 150%. These liquidations might restore the TCR to above 150%.

5. Repeat the Process:

The attacker can repeat the steps as necessary, maintaining the system in a state of Recovery Mode to continuously exploit Troves with collateral ratios below 150%.

The Role of One-Time Redemption Fees and Borrowing Fees in Mitigating These Attacks

Economic Impact of Fees on Attack Vectors

One-time redemption fees and borrowing fees play a crucial role in mitigating the risks associated with the attack vectors described above. By introducing a cost to borrowing and redeeming, these fees make it economically unfeasible for attackers to execute large-scale profitable manipulations in most cases.

For example, in the scenario of redemption fee manipulation, a one-time borrowing fee would increase the cost of inflating the system’s debt, making it unprofitable for the attacker to exploit the redemption fee. Similarly, in scenarios where the attacker seeks to trigger Recovery Mode, the borrowing fee would act as a deterrent by raising the cost of taking on large amounts of debt in order to manipulate the TCR.

Final Thoughts on Securing DeFi Protocols

As DeFi evolves, protocols will face increasingly sophisticated attacks. To stay ahead, it’s crucial to understand how different features interact and potentially create vulnerabilities. Effective security requires a deep understanding of how different system components interact, as well as careful attention to the settings and parameters that govern these interactions. By proactively anticipating the ways in which features can combine to create vulnerabilities, designers can build protocols that are not only secure but also resilient and adaptable to future challenges.