Bandit - When `cScale` < `maxScale` Tranche Can Become Insolvent

[sherlock-admin2]

Bandit

medium

When cScale < maxScale Tranche Can Become Insolvent

Summary

The protocol cannot pay out all withdrawers or redeemers when cScale < maxScale

Vulnerability Detail

The Tranche calculates the asset to share conversion ratio based on the maxScale which is the highest value of the scale that has been recorded. However, if the current scale is lower than the maximum scale, then the total number of shares that could be redeemed would exceed the total shares in existence.

In Tranche#redeemWithYt():

[        if (_lscale != 0) {
            accruedInTarget += _computeAccruedInterestInTarget(_maxscale, _lscale, yBal);](https://github.com/sherlock-audit/2024-01-napier/blob/6313f34110b0d12677b389f0ecb3197038211e12/napier-v1/src/Tranche.sol#L261-L271)
        }

        // Transfer underlying from user to adapter and deposit it into adapter to get target token
        _underlying.safeTransferFrom(msg.sender, address(adapter), underlyingAmount);
        (, uint256 sharesMinted) = adapter.prefundedDeposit();

        uint256 sharesUsed = sharesMinted + accruedInTarget;
        uint256 fee = sharesUsed.mulDivUp(issuanceFeeBps, MAX_BPS);
        issued = (sharesUsed - fee).mulWadDown(_maxscale);

This can happen for liquid staking derivatives, where the scale could have decreased from the past due to a slashing event.

When this happens, if everybody withdraws, there wouldn't be enough assets to pay everybody out, and the protocol is insolvent.

Impact

Protocol cannot payout all redeemers when they withdraw when cScale < maxScale

Code Snippet

https://github.com/sherlock-audit/2024-01-napier/blob/6313f34110b0d12677b389f0ecb3197038211e12/napier-v1/src/Tranche.sol#L202-L225

Tool used

Manual Review

Recommendation

Use the cScale even when it is not the maximum it has ever been rather than the maxScale

[nevillehuang]

Escalate

This is a duplicate of #84

[sherlock-admin2]

Escalate

This is a duplicate of #84

You've created a valid escalation!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

[massun-onibakuchi]

I'm not sure what you found. Please provide a PoC

[xiaoming9090]

Escalate

This is a duplicate of #84

Disagree that this should be a duplicate of Issue 84. Issue 84 highlighted the root cause of the lack of slippage control in the issue function, which has team can remediate by implementing a slippage control. So, that report presents a clear and straightforward actionable solution.

I do not see how this issue has to do with the lack of slippage control in the issue function, as it was not mentioned anywhere in this report.

Lastly, the sponsor is not clear about this issue (https://github.com/sherlock-audit/2024-01-napier-judging/issues/104#issuecomment-1986790751), and has requested a POC from Watson.

[cvetanovv]

Disagree with the escalation. For me, this report is not a duplicate of #84.

[Czar102]

I don't see how is this a duplicate of #84.

@nevillehuang please provide an extensive comparison if you maintain your position in the escalation.

If a strong justification isn't provided within 24h, I'm planning to reject the escalation and leave the issue as is.

[nevillehuang]

@Czar102 Agree it is not a duplicate and lacks sufficient vulnerability description, miss-escalation on my part

[Czar102]

Result: Invalid Unique

[sherlock-admin3]

Escalations have been resolved successfully!

Escalation status:

• nevillehuang: rejected