Atom fractions deposited as part of the triple deposit can't be redeemed proportionally

[hats-bug-reporter[bot]]

Github username: -- Twitter username: iamandreiski Submission hash (on-chain): 0x82bad5d9b0c22fa63ada58b815530f110d3b6eee5db8c0d6a191f0ccf998f4a7 Severity: medium

Description: Description

When depositing to a Triple vault (or creating one for that matter) a certain fraction of a user's deposit is going to every individual Atom vault which constitutes the Triple one. When the deposit is made via the _depositAtomFraction, the shares are also added/increased as part of the tripleAtomShares mapping, which is used to enable atom shares earned from triple deposits to be redeemed proportionally as per documentation/natspec. The problem is that there's no mechanism to prevent users to redeemed accumulated atom fraction shares from an individual atom vault without redeeming proportionally. Even if they decide to "redeem" proportionally the fractions from each individual atom, tripleAtomShares mapping is never decreased.

Attack Scenario

When a user creates a Triple vault or deposits to an already existing one, part of the Triple cost is the atomDepositFraction which is divded by three and each "third" is deposited to the individual Atom vault constituting one third of the Triple. This is done via the _depositAtomFraction function invoked both in _createTriple and depositTriple function as well:

  function _depositAtomFraction(uint256 id, address receiver, uint256 amount) internal {
        // load atom IDs
        uint256[3] memory atomsIds;
        (atomsIds[0], atomsIds[1], atomsIds[2]) = getTripleAtoms(id);

        // floor div, so perAtom is slightly less than 1/3 of total input amount
        uint256 perAtom = amount / 3;

        // distribute proportional shares to each atom
        for (uint256 i = 0; i < 3; i++) {
            // deposit assets into each atom vault and mint shares for the receiver
            uint256 shares = _deposit(receiver, atomsIds[i], perAtom);

            // update the mapping which tracks atom shares
            tripleAtomShares[id][atomsIds[i]][receiver] += shares;
        }
    }

As we can see from the code block above, each individual atom fraction is deposited to the related atom vault via the _deposit function, and the shares minted to the receiver. Besides that, the mapping which tracks atom shares or tripleAtomShares is also updated with the amount of shares attributed as fraction to the particular atom vault.

/// @notice Atom Shares Tracking
    /// used to enable atom shares earned from triple deposits to be redeemed proportionally
    /// to the triple shares that earned them upon redemption/withdraw
    /// Triple ID -> Atom ID -> Account Address -> Atom Share Balance
    mapping(uint256 tripleId => mapping(uint256 atomId => mapping(address account => uint256 balance))) public
        tripleAtomShares;

The problem is that users can redeem shares disproportionally and "redeem" accumulated atom fractions from each individual atom vault, as there's no mechanism in _redeem that redeems the atom fracitons proportionally when redeeming from triple vault, or performs checks in any way. If users redeem their whole underlying balances from the individual Atom vaults, the tripleAtomShares mapping will also never be reduced, and will show the total accumulated fraction shares across all deposits made to Triple vaults.

Attachments

1. Proof of Concept (PoC) File

2. Revised Code File (Optional)

[mihailo-maksa]

The reported issue regarding the inability to redeem atom fractions proportionally when deposited as part of a triple deposit has been reviewed. Here is our detailed perspective:

Intended Functionality: The current design of the system does not include a mechanism for proportionate redemption of underlying atom shares during the redeemTriple process. This is an intentional choice to simplify the redemption logic and ensure efficient processing of transactions.

Proportional Redemption: While the issue highlights the lack of proportional redemption checks, it is important to note that our system is designed to allow flexibility in how users manage their atom shares. Users can redeem their accumulated atom shares independently, providing them with more control over their assets.

System Integrity: The system ensures that the tripleAtomShares mapping accurately tracks the shares attributed to each atom vault. This mapping is updated correctly during deposits, and users can redeem their shares as needed. The current implementation does not pose any risk to the overall integrity of the system.

User Control: The ability to redeem atom shares independently from the triple vaults offers users more control and flexibility in managing their assets. This approach aligns with our philosophy of providing a user-centric experience.

Conclusion: The absence of proportional redemption for atom fractions in the redeemTriple function is a deliberate design choice. It simplifies the redemption process and offers users more control over their assets. Therefore, we consider this issue to be invalid.

Status: This issue is invalid.