First Flight #9: Soulmate

Summary

The protocol mints and approves during the deployment process amount of tokens for the airdropVault, stakingVault and aidropContract, stakingContract. But the protocol doesn't taka into account the case when the minted and approved tokens are used. In that case the protocol functionality will be broken and all of the contracts should deploy again.

Vulnerability Details

The deployment process for the Vault consists from the following steps:

• Initiate 2 Vault contracts, one for airdropVault and one for stakingVault.

• Use them in the LoveToken contract's constructor.

• Call the Vault::initVault function for each vault.

• The Vault::initVault function calls the LoveToken::initVault and initialized the allowance.

But the LoveToken::initVault and the Vault::initVault functions allow for a one-time minting event for each of the airdropVault and stakingVault. There is no functionality to mint additional tokens after this initial event.
The LoveToken::initVault function also approves a large amount of tokens to a managerContract. The managerContract can be the stakingContract or airdrpContract. Once these tokens are transferred or spent, there is no built-in mechanism to approve additional tokens.

The implementation of Vault::initVault and LoveToken::initVault:

Impact

In the LoveToken contract, the initVault function is responsible for minting to the airdropVault and stakingVault and approving to airdropContract and stakingContract a large amount of tokens (500 million) . If the tokens are transferred out or used, the contract does not have a built-in mechanism to mint additional tokens or approve more tokens for spending.

If the initial amount of tokens approved for the managerContract is depleted and there is a need to approve more tokens, the contract as it stands does not support this functionality because it does not have a function to mint additional tokens beyond the initial LoveToken::initVault call. Since the contract does not include any upgradeability features, you cannot modify its behavior once it is deployed.

Therefore, if you need to approve more tokens after the initial amount is gone, you would not be able to do so with the current contract. You would have to deploy a new contract with the desired functionality, which could include additional minting capabilities or a different approval mechanism.

However, deploying a new contract would mean that you would have a new token with a different contract address, which might not be desirable as it would not be the same token that users initially received. To avoid such a situation, it is important to carefully plan the tokenomics and functionality of the token contract before deployment, considering future needs for minting and approval of tokens. If you anticipate the need for more tokens in the future, you should design the contract with the necessary functions to mint and approve additional tokens in a secure and controlled manner for making such decisions.

Tools Used

Manual Review

Recommendations

Carefully consider the long-term tokenomics and operational needs before deploying the contract. If future minting or approvals are anticipated, include the necessary functions in the contract.