The Standard

Summary

The mint function deploys a vault contract using create1. However, some of the chains (Polygon, Optimism, Arbitrum) to which the SmartVaultManagerV5 may be deployed are suspicious of the reorg attack.

Vulnerability Details

A simple scenario to demonstrate the issue:

• Alice deploys a vault at 0x76jute98...., and then sends some collateral to it.

• Bob sees that the network block reorg happens and front-run alice vault deployment by deploying a vault at 0x76jute98....

• Alice transaction ended up deposited into Bob's vault.

Here -> https://polygonscan.com/blocks_forked, you may be convinced that the Polygon has in practice subject to reorgs. Even more, the reorg may be 1.5 minutes long. So, it is quite enough to create the quest and transfer funds to that address, especially when someone uses a script, and not doing it by hand.

Optimistic rollups (Optimism/Arbitrum) are also suspect to reorgs since if someone finds a fraud the blocks will be reverted, even though the user receives a confirmation and already created a quest.

Impact

Vault's are created from the SmartVaultManagerV5 via CREATE1, a malicious ward can frontrun mint() to deploy at the same address. If the deployed chain reorg, a different vault will also be deployed at the same address.

Tools Used

Manual review

Recommendations

Deploy the vault contract via create2 with salt that includes msg.sender and tokenId.