`_createTriple` doesn't mint any shares to the atom avult, unlike `_createAtom`

[hats-bug-reporter[bot]]

Github username: @0x3b33 Twitter username: -- Submission hash (on-chain): 0xf0dfb593aefbd2fff34722841fcc3a152b1a8088390b67cfa1c6e7248bc301cf Severity: low

Description: Description\ A small discrepancy in the share minting process is found when comparing how _createAtom and _createTriple functions operate.

Inside _createAtom, we execute _depositOnVaultCreation twice:

1. Minting shares to the user and address(0)
2. Minting shares to our atom wallet.

        _depositOnVaultCreation(
            id,
            msg.sender, // receiver
            userDepositAfterprotocolFee
        );

        // Get atom wallet address for the corresponding atom
        address atomWallet = computeAtomWalletAddr(id);

        // Deposit atomWalletInitialDepositAmount amount of assets and mint the shares for the atom wallet
        _depositOnVaultCreation(
            id,
            atomWallet, // receiver
            atomConfig.atomWalletInitialDepositAmount
        );

However, this is not the case inside _createTriple, as we only mint triple shares to the user.

        _depositOnVaultCreation( 
            id,
            msg.sender, // receiver
            userDepositAfterprotocolFee - atomDepositFraction
        );

Whether intentional or not, this will change the ratio of minted and vault-owned shares.

Recommendation\ Execute a _depositOnVaultCreation for the triple vault and ensure the assets for this extra deposit are accounted for.

[mihailo-maksa]

The observation regarding the difference in share minting between the _createAtom and _createTriple functions has been reviewed. Here is our comprehensive explanation:

Intentional Design: The difference in the share minting process between _createAtom and _createTriple is by design. The _createAtom function includes an additional step to mint shares to the atom wallet, which is specific to atom creation.

Function-Specific Behavior: The _createTriple function focuses on minting shares to the user without involving the atom wallet. This design choice ensures that the share distribution aligns with the intended behavior for each function, maintaining consistency and clarity in their respective purposes.

System Balance: The current implementation ensures that the share minting process is balanced and appropriate for each function's role within the protocol. The differentiation in share allocation helps maintain the intended economic model and system dynamics.

Conclusion: The differing share minting processes for _createAtom and _createTriple are deliberate and align with the overall system design. This approach does not introduce any inconsistencies or vulnerabilities but rather supports the specific requirements of each function. Therefore, we consider this behavior to be functioning as intended and the issue is considered as invalid.