Adversary can frontrun reference rate increases to dump low yield bonds on KUMASwap

[code423n4]

Lines of code

https://github.com/code-423n4/2023-02-kuma/blob/3f3d2269fcb3437a9f00ffdd67b5029487435b95/src/kuma-protocol/KUMASwap.sol#L115-L171

Vulnerability details

Impact

Reference rate increases can be frontrun to dump low yield bonds on KUMASwap

Proof of Concept

https://github.com/code-423n4/2023-02-kuma/blob/3f3d2269fcb3437a9f00ffdd67b5029487435b95/src/kuma-protocol/KUMASwap.sol#L134-L136

uint256 referenceRate = IMCAGRateFeed(KUMAAddressProvider.getRateFeed()).getRate(_riskCategory);

if (bond.coupon < referenceRate) {
    revert Errors.COUPON_TOO_LOW();
}

When a user is selling a bond to KUMASwap it compares the bond coupon to the current reference rate. If the coupon is too low then the sale will revert.

https://github.com/code-423n4/2023-02-kuma/blob/3f3d2269fcb3437a9f00ffdd67b5029487435b95/src/mcag-contracts/MCAGAggregator.sol#L52-L62

function transmit(int256 answer) external override onlyRole(Roles.MCAG_TRANSMITTER_ROLE) {
    if (answer > _maxAnswer) {
        revert Errors.TRANSMITTED_ANSWER_TOO_HIGH(answer, _maxAnswer);
    }

    ++_roundId;
    _updatedAt = block.timestamp;
    _answer = answer;

    emit AnswerTransmitted(msg.sender, _roundId, answer);
}

The referenceRate used by KUMASwap must be manually update via a transmit call. Since the oracle is updating the rate to match a publicly available rate, all parties will become aware of the rate change at the same time. This creates a race between the oracle data provider and those looking to maximize returns. Those users can frontrun the price update to dump low yield bonds onto KUMASwap.

Example: Imagine users are trading the US 10Y Treasury Note. The current coupon is 3.5% but the treasury has just increased it to 3.8%. A user owns a large number of bonds and sees the coupon is about to increase. This would mean that they otherwise cannot sell their bonds. They quickly frontrun the update and sell all their 3.5% notes allowing them to sell bonds they shouldn't otherwise be able to.

This harms the liquidity and yield of all other KIBToken holders.

Tools Used

Manual Review

Recommended Mitigation Steps

Bond buying and selling should be disabled for a set period of time before and after potential changes to coupon.

[GalloDaSballo]

This looks like a network property, that does create negative externalities

The fact that the MEV is prevent is valid, so I will not discard this finding (Low Severity at least)

[GalloDaSballo]

@0x00052 please do add an example of a risk-free attack if you can come up with one

[IAm0x52]

The profitability of an attack like this would depend on the liquidity availability of the KIBToken and the time discount the market is currently applying to the KIBToken yield. If the conditions were right (enough liquidity and low enough time discount) they would sell their KIBToken for a stablecoin then buy new bonds at the higher yield. Due to their sale, the effective time discount on the KIBTokens have now increased because after their sale the market value of the KIBToken will have decreased. It also increases the number of low yield bonds that need to be purchased before the underlying yield of the KIBToken can increase.

In the event that it is not profitable to sell their KIBToken (low liquidity or time discount is too high) their KIBToken yield will guaranteed be the same or better than the bonds they sold.

Though not explicitly mentioned in my submission this also works in reverse. They can frontrun a decreases in reference rate to guarantee a higher rate than the KIBToken would have yielded. If the reference rate is 3.5% and it is decreasing to 3% then they can use their KIBTokens to buy as many bonds as possible to guarantee a 3.5% yield when their KIBToken would have only yielded 3% after the reference rate decrease.

[GalloDaSballo]

Am thinking leak of value (Med) at this time, but this MEV opportunity definitely requires further thinking

[c4-sponsor]

m19 marked the issue as sponsor disputed

[m19]

We struggle to see a real example on how users are potentially grieved. In our view this is intended behavior and simply offers arbitrage opportunities for advanced users. We'd love to see a more specific example on how someone could get grieved by this.

[GalloDaSballo]

After some digging, the best I can understand is that users that want to sell on rate hikes can always do so:

https://github.com/code-423n4/2023-02-kuma/blob/22fd56b3f0df71714cb71f1ce2585f1c4dd21d64/src/kuma-protocol/KUMASwap.sol#L134-L136

        if (bond.coupon < referenceRate) {
            revert Errors.COUPON_TOO_LOW();
        }

Ultimately they will all be able to sell the coupons by front-running the oracle update.

The pricing seems to be inelastic, but also the bond bought is valued for it's coupon

I'm thinking this is QA in that advanced users will always be able to do it, I'll think about risks to the Sponsor, but at this time it seems like this is more of a quirk than a proper leak of value

[GalloDaSballo]

Given the information that I have, I believe the finding to be valid, but of Low Severity, I recommend the Warden to follow up with the Sponsor if they believe a higher impact vector emerges

[c4-judge]

GalloDaSballo changed the severity to QA (Quality Assurance)

[GalloDaSballo]

L

[c4-judge]

GalloDaSballo marked the issue as grade-b