NoOne - Minting to Zero Address Causes Revert During Initial Supply Setup

[sherlock-admin4]

NoOne

medium

Minting to Zero Address Causes Revert During Initial Supply Setup

Summary

The mint function in the contract is designed to mint shares of a vault position and deposit corresponding token amounts to a specified receiver. However, the function attempts to mintMINIMUM_LIQUIDITY tokens to the zero address (address(0)) when the total supply is zero. This results in a revert due to the _mint function's check against minting to the zero address, causing the transaction to fail and preventing proper initialization.

Vulnerability Detail

if (supply == 0) {
    _mint(address(0), MINIMUM_LIQUIDITY);
    shares_ = shares_ - MINIMUM_LIQUIDITY;
}

function _mint(address account, uint256 value) internal {
    if (account == address(0)) {
        revert ERC20InvalidReceiver(address(0));
    }
    _update(address(0), account, value);
}

This design causes the mint function to fail when attempting to mint to the zero address, preventing proper initialization of the contract.

Impact

The impact of this vulnerability is significant as it prevents the contract from correctly initializing the minimum liquidity, which is essential for the proper functioning of the vault. This issue can halt the minting process, leading to a denial of service for users trying to interact with the contract.

Code Snippet

function mint

Tool used

Manual Review

Recommendation

To resolve this issue, the mint function should be modified to mint the initial MINIMUM_LIQUIDITY to the contract address itself (address(this)) instead of the zero address. This approach ensures that the tokens are accounted for and effectively locked within the contract, avoiding the revert and allowing proper initialization.

 if (supply == 0) {
        _mint(address(this), MINIMUM_LIQUIDITY); // Mint to the contract address
        shares_ = shares_ - MINIMUM_LIQUIDITY;
    }

[sherlock-admin3]

Escalate This is valid medium, due to the DoS of ArrakisMetaVaultPublic::mint() function , in the first call of the function

You've deleted an escalation for this issue.

[brakeless-wtp]

The watson references the _mint() method from OZ's ERC20 contract, but the protocol inherits Solady's ERC20 contract. It does not seem like the restriction mentioned in the report is enforced, unless it is implemented in the _before and _after hooks.

[Jelev123]

The watson references the _mint() method from OZ's ERC20 contract, but the protocol inherits Solady's ERC20 contract. It does not seem like the restriction mentioned in the report is enforced, unless it is implemented in the _before and _after hooks.

You are right that it use Solady ERC20, but in _beforeTokenTransfer function it says when to is zero, amount of from's tokens will be burned., from and to are never both zero. In this case both are zero

[0xjuaan]

it clearly does not revert, just run forge test --mt test_mint to run the test found in arrakis-modular/test/integration/ValantisIntegrationPublic.t.sol