Users can deposit and redeem to tripple vaults to farm shares

[hats-bug-reporter[bot]]

Github username: @0x3b33 Twitter username: -- Submission hash (on-chain): 0x2c0404f367cd11e2b000abaf9153bd3416edad291487e1896eb8f9a701a1b1f9 Severity: high

Description: Description\ During deposits with depositTriple, the function deposits to the triple vault while also making three other deposits for the smaller vaults. This mechanic mints the user x amount of triple shares and x / 3 shares for each smaller vault.

<depositTriple>
733.       uint256 shares = _deposit(receiver, id, userDepositAfterprotocolFee);

739.        _depositAtomFraction(id, receiver, atomDepositFraction);

<_depositAtomFraction>
849.        for (uint256 i = 0; i < 3; i++) {
850.            // deposit assets into each atom vault and mint shares for the receiver
851.            uint256 shares = _deposit(receiver, atomsIds[i], perAtom);
852.
853.            // update the mapping which tracks atom shares
854.            tripleAtomShares[id][atomsIds[i]][receiver] += shares;
855.       }

However, the same is not done in redeemTriple, where only the triple shares are burned while redeeming the full amount.

803.        (uint256 assets, uint256 protocolFee) = _redeem(id, msg.sender, shares);
804.
805.        // transfer eth to receiver factoring in fees/shares
806.        (bool success,) = payable(receiver).call{value: assets}("");
807.        if (!success) {
808.            revert Errors.MultiVault_TransferFailed();
809.        }

Attack Scenario

1. User1 mints 3000 triple shares for 1 ETH, where each mini vault mints an additional 1000 shares.
2. User1 then redeems the triple shares and gets his 1 ETH back, while still having the 1000 shares from each of the mini vaults.

User1 is in profit as he can now redeem the shares from these three mini vaults.

Recommendation Burn the shares for the three vaults inside the triple vault.

[0x3b33]

No need to read it it's invalid. Main vault is minted userDepositAfterprotocolFee - atomDepositFraction and mini vaults are minted atomDepositFraction / 3 each. All of the balances are correct.

For future reference is there a way wardens can close issues that are later found invalid ?

[mihailo-maksa]

The report is invalid. The current implementation works as intended, as confirmed by the documentation and the reporter themselves. When users deposit to the triple vault, shares are correctly minted and distributed to the corresponding atom vaults.

Specifically, when depositTriple is called, the function correctly handles the shares distribution by calling _deposit for the triple vault and _depositAtomFraction for the underlying atom vaults. Each vault receives the appropriate amount of shares based on the deposit, ensuring that the user's total shares are accurately reflected across the triple and atom vaults.

This design prevents any exploitation where users could farm shares. The protocol’s logic ensures that all deposits and redemptions are accounted for correctly, maintaining the integrity of the vaults and their shares. Therefore, no further changes are needed.