Last year in March 2024, I found a critical bug in the GammaSwap protocol on Immunefi, which allowed anyone to steal funds from some newly deployed GammaSwap pools. In this write-up, I will explain the bug in detail. Let's begin!

Note to users: This bug was fixed immediately after it was reported and no funds were lost. This bug only impacted some newly deployed GammaSwap pools and the bug has been fully mitigated and is no longer present.

What is GammaSwap?

GammaSwap is a perpetual options protocol that aims to solve the impermanent loss problem by allowing users to borrow liquidity from an AMM to profit from price movement.

GammaSwap aggregates liquidity, where one side are LPs who deposit their LP tokens into the GammaSwap pool, allowing users to borrow them in exchange for borrowing fees, compensating LPs better for their risk.

The other side are users who borrow LP tokens to open a position, burning the LP tokens and holding the reserve tokens in the contract. The IL that LPs experience will now become impermanent gain to the borrowers once the price moves.

GammaSwap works specifically with constant function market makers like Uniswap v2, SushiSwap, and a GammaSwap Uniswap v2 fork called DeltaSwap.

Borrowing

When someone borrows liquidity from the GammaSwap pool, the LP tokens get burned, turning the withdrawn liquidity into a loan and holding the reserve tokens of the withdrawn liquidity as collateral in the contract to pay back the loan on a future date.

The amount of LP tokens borrowed is measured in Liquidity Invariant Units of the AMM which is the geometric mean of the reserve tokens that we received from the AMM by burning the LP tokens.

Repayment

If the price in the AMM changes, the funds withdrawn from the AMM become more valuable relative to the liquidity borrowed from the AMM.

When the user repays the loan, the reserve tokens in the loan will first be rebalanced to match the current ratio of the reserves in the pool, and then the contract will send enough reserve tokens into the CFMM to mint the LP tokens to pay back the debt + interest. The reserve tokens that are left is the profit that the user receives from the impermanent gain.

Liquidations

When a user borrows a loan, the reserve tokens that get withdrawn are added to the collateral and will fully collateralize the borrowed amount. However, because the debt accrues interest, the user needs to over-collateralize his loan.

GammaSwap does not use an oracle and does not have liquidation prices. However, if the loan crosses a 99.5% LTV threshold, then it will get liquidated.

Liquidations work the same way as when you're repaying a loan. The reserve tokens first get rebalanced and sent to the CFMM to mint LP tokens to pay back the loan.

However, the biggest difference here is that if the contract does not receive enough LP tokens after the rebalance and mint, the bad debt will be written off and passed as a loss to LPs which could happen if the loan didnt get liquidated immediately and went underwater.

This is what we will focus our attention on

Finding the bad end state

Let's take a look at what would happen if the reserve tokens in the loan didn't match the ratio of the CFMM reserves after the rebalance when liquidating. Before we mint the LP tokens, we first need to find out how many reserve tokens we need to send to the CFMM for the mint.

This is done by calcTokensToRepay()

function calcTokensToRepay(uint128[] memory reserves, uint256 liquidity,    uint128[] memory maxAmounts) internal virtual override view
        returns(uint256[] memory amounts) {

        amounts = new uint256[](2);
        uint256 lastCFMMInvariant = calcInvariant(address(0), reserves);

        uint256 lastCFMMTotalSupply = s.lastCFMMTotalSupply;
        uint256 expectedLPTokens = liquidity * s.lastCFMMTotalSupply / lastCFMMInvariant;

        amounts[0] = expectedLPTokens * reserves[0] / lastCFMMTotalSupply + 1;
        amounts[1] = expectedLPTokens * reserves[1] / lastCFMMTotalSupply + 1;

        if(maxAmounts.length == 2) {
            amounts[0] = GSMath.min(amounts[0], maxAmounts[0]);
            amounts[1] = GSMath.min(amounts[1], maxAmounts[1]);
        }
    }

Here, we first convert the debt liquidity invariant to the amount of LP tokens expected and then calculate the exact amount of reserve tokens needed. If we don’t have enough reserve tokens to cover the exact amount, we will use the maxAmount, which is the entire balance of the loan.

As you know from Uniswap v2, if the proportions are different when minting then we will take the minimum

liquidity = Math.min(amount0.mul(_totalSupply) / _reserve0, amount1.mul(_totalSupply) / _reserve1);

So if the reserve tokens in the loan didnt match the ratio of the CFMM reserves after the rebalance, then one side wouldnt have enough tokens, taking the maxAmount which results in fewer LP tokens being minted and a bad debt write-off.

However, this would only be possible if the rebalance didnt happen and that cant happen, right? Right?

Achieving the bad end state

Let's take a look at how a rebalance may not happen

Whenever liquidating, we first calculate the deltas for the rebalance and then rebalance the collateral:

(_liqLoan, deltas) = getLiquidatableLoan(_loan, tokenId);

if(isDeltasValid(deltas)) {
    (tokensHeld,) = rebalanceCollateral(_loan, deltas, s.CFMM_RESERVES);
    updateIndex();
}

The deltas are calculated by this function:

deltas = _calcDeltasForMaxLP(_liqLoan.tokensHeld, s.CFMM_RESERVES);

_calcDeltasForMaxLP() uses the tokens held in the loan and the reserves in the CFMM to calculate the delta for the rebalance, taking into account the price impact of the swap.

If the deltas are 0, then isDeltasValid() returns false, and a rebalance does not happen. So if we find a way for _calcDeltasForMaxLP() to return 0, then the rebalance will not happen.

Without getting into the complex math of _calcDeltasForMaxLP(), after testing some values I have found that _calcDeltasForMaxLP() will return 0 if the current CFMM reserves are very tiny, close to the locked amount (1e3) at the zero address.

Now the next step is to find a way to withdraw all the reserves from the CFMM, leaving only the locked amount. This seems quite impossible, but it is actually possible because of DeltaSwap.

DeltaSwap is a fork of Uniswap V2 with zero spot trading fees which was launched specifically to work with GammaSwap pools, allowing users to borrow liquidity from it.

Deltaswap LP tokens don’t earn fees unless they are in the GammaSwap pool, so LPs have to deposit them into the Gammaswap pool if they want to earn fees.

After checking the deployed pools, i have found some pools where all of the DeltaSwap LP tokens except the locked amount were deposited in the Gammaswap pools. Meaning that all of the LP tokens could be borrowed, withdrawing the liquidity from the Deltaswap pool to leave only the tiny reserves so that the rebalance doesnt happen when liquidating.

Now that we have everything, lets take a look at the attack.

The attack

Here is a step-by-step breakdown of the attack:

1-Borrowing Liquidity

• We first borrow all available liquidity from the GammaSwap pool

• Lets say we will borrow 100e18 LP tokens, worth 100e18 of Token A and 100e18 of Token B.

• The CFMM reserves are now: 1000 of Token A and 1000 of Token B.

2-Manipulating the CFMM Reserves

• Because we know that the rebalance wont happen during the liquidation, we can manipulate the reserves heavily to one side by swapping to steal as much as possible

• After the swap, the new reserves become 1e6 of Token A and 1 of Token B.

3-Liquidation

• In the next block, the loan becomes liquidatable, but the rebalance won't happen because _calcDeltasForMaxLP() returns 0

• To mint 100e18 LP tokens, the required amount is 1e23 of Token A and 1e17 of Token B.

• Since we don’t have 1e23 of Token A, we will use the max available of Token A in the loan which is 100e18

4-Profiting from the attack

• When minting LP tokens, we will receive and repay: 100e18 * 1000 / 1e6 = 0.1e18

• The remaining 99.9e18 LP tokens are written off as bad debt and passed as a loss to LPs

• The attacker will then withdraw 99.9e18 of Token B from the loan and receive the other part from swapping in the pool which has 100e18 of Token A and 1e17 of Token B

As a side note, after 80% utilization the opening loan fees increase exponentially. However, this can be easily bypassed by depositing a large amount of LP tokens first, then borrowing everything except the amount that we deposited and in the same tx withdrawing what we deposited.

The impact of this vulnerability was severe, as it allowed anyone to steal most of the available funds that weren’t borrowed yet, resulting in big losses for LPs. Luckily, only a small part of the pools were affected.

At the time of the submission, there were 3 pools where all of the DeltaSwap LP tokens were in the GammaSwap pool except for the locked amount. These were newly deployed pools, other pools already had a third holder, which was a liquidator bot(made by Gammaswap that received LP tokens after liquidations. The LP tokens it held were sufficient for the rebalance to happen but if the liquidator bot burned the LP tokens, then the pools would have become vulnerable too.

The full PoC can be found here

The fix

To prevent the AMM from running out of liquidity and enable the attack a check was added to block withdrawals or borrowing that results in a utilization rate of 98% or higher.

Another very important check was added that ensures that the rebalance actually happened and the loan reserve tokens ratio is correct by reverting if the amount needed is bigger than the max amount in the loan when liquidating:

if(amounts[0] > maxAmounts[0]) {
    unchecked {
        if(amounts[0] - maxAmounts[0] > 1000) revert InsufficientTokenRepayment();
    }
}
if(amounts[1] > maxAmounts[1]) {
    unchecked {
        if(amounts[1] - maxAmounts[1] > 1000) revert InsufficientTokenRepayment();
    }
}

Additionally, small amounts of liquidity were deposited to the DeltaSwap pool to be kept outside of the GammaSwap pool.

Closing and Acknowledgment

I would like to thank the GammaSwap team for their swift response and for taking security seriously. No funds were lost and a fix was deployed very quickly. And thanks to Immunefi for making the bug bounty experience seamless!

Some interesting factors came together to make this attack possible which may have been quite hard to spot during the audit and this is why its always good to have a bug bounty program!

Arz