Canto Application Specific Dollars and Bonding Curves for 1155s - pontifex's results

Lines of code

https://github.com/code-423n4/2023-11-canto/blob/335930cd53cf9a137504a57f1215be52c6d67cb3/asD/src/asD.sol#L73-L76

Vulnerability details

Impact

The asD.withdrawCarry function will always throw an error for all normal totalSupply() values due to inappropriate scale factor. So the creator can withdraw the accrued interest only after all users will burn their asD tokens.

Proof of Concept

The scale factor at the line L#76 of the asD contract may be used with cTokens with 8 decimals but not with the cNOTE which token has 18 decimals. The exchangeRateCurrent() for the cNOTE is scaled by 1 * 10**(18 - 18 + Underlying Token Decimals), i.e. 1e18. So the current scale factor is too big.

        uint256 maximumWithdrawable = (CTokenInterface(cNote).balanceOf(address(this)) * exchangeRate) /
            1e28 -
            totalSupply();

This way the underlying amount will be always underestimated and there will be the underflow error here.

Tools Used

Manual review

Recommended Mitigation Steps

Consider using 1e18 scale factor instead of 1e28.

Assessed type

Decimal

Lines of code

https://github.com/code-423n4/2023-11-canto/blob/335930cd53cf9a137504a57f1215be52c6d67cb3/1155tech-contracts/src/bonding_curve/LinearBondingCurve.sol#L21

Vulnerability details

Impact

The shares price increases/decreases too fast especially for the first 20 shares and the sandwich attack can be really profitable. This way users may lose sufficient value of their investments when buying and selling the shares.

Proof of Concept

I will consider the option in which users buy one share at a time as a priority strategy for users, but the attack can be carried out equally when users buy several shares in one transaction or in a batch of transactions.

The difference between price + fee for buying share #n and rewardsSinceLastClaim + price - fee for selling share #n+1 let perform the sandwich attack. The most profitable is frontrun the first buyer. The attacker can receive approx. 0.77 * priceIncrease but the user losses approx. a half of investments. Then the attacker can repeat this attack with next users. Some of these users can decide to sell shares some - to keep. So there can be multiple attacks. The max tokenCount when the attack is possible for any attackers is 20 shares. In case an attacker is controlled by the share creator (the role can be untrusted) the max tokenCount is 100. In both cases the amount of shares does not reflect the amount of attacks because of different users behavior. The table shows the attackers profit for different tokenCount values when the LinearBondingCurve contract is used as a bondingCurve.

Tools Used

Manual review

Recommended Mitigation Steps

Consider using the curve where the next token can't be sold with sufficient profit. For example the price of the first share can be equal 100 * priceIncrease. This makes frontrunning unprofitable even for the shares creators.

Assessed type

MEV

Lines of code

https://github.com/code-423n4/2023-11-canto/blob/335930cd53cf9a137504a57f1215be52c6d67cb3/asD/src/asD.sol#L52-L55

Vulnerability details

Impact

Due to the rounding losses an excess amount of cNOTE tokens may be burnt. This can cause different problems including that some amount of asD tokens can not be burnt, the owner of asD loses a part of the accrued interest and even the draining of the contract assets.

Proof of Concept

The asD.mint does not take into account the rounding losses at the cNOTE contract and mints exactly the _amount of asD. It is not a problem when a user deposits n tokens and then withdraws n tokens. But if the user deposits several times n tokens and then withdraws the whole value (k * n) the rounding error will be in k times less and the asD contract will burn an excess amount of cNOTE. There is a POC with a real exchange rate for the NOTE/cNOTE pair here. The test passes when the user mints 5e18 at once but not when the user deposits 5 times 1e18 NOTE and then withdraws the whole amount.

Running 3 tests for src/test/asDR.t.sol:asDR
[PASS] testBurn() (gas: 267387)
Logs:
  cNOTE 4979798570281804344

[PASS] testMint() (gas: 217598)
Logs:
  cNOTE 4979798570281804344

[FAIL. Reason: revert: ERC20: burn amount exceeds balance] testMintThenBurn() (gas: 565204)
Logs:
  cNOTE 4979798570281804340

Tools Used

Manual review

Recommended Mitigation Steps

Consider checking the actual minted amount of cNOTE to mint the appropriate amount of asD. It is obvious that the amount of asD can be slightly less than deposited NOTE but it will guarantee that all asD tokens can be redeemed.

Assessed type

Other