MerkleLL and MerkleLT creation is done through CREATE opcode which is vulnerable to reorgs, especially as the protocol aims to deploy on various EVM chains.
The protocol aims to deploy on EVM compatible chains, including optimistic rollups (Optimism/Arbitrum) are notorious of having reorgs issues. Other chains like ethereum, polygon etc also have reorgs happen at one point in the past or another.
The creation of the Merkles LL and LT relies on ordinary CREATE opcode which is vulnerable to these kinds of attacks. The issue would happen when users rely on the address derivation in advance or try to deploy the position clone with the same address on different EVM chains and try to fund the merkles, the sent funds to the new contract could potentially be withdrawn by another user which could lead to the theft of user funds.
A user deploys a new Merkle, and then sends funds to it. Another user sees that the network block reorg happens and calls create function. Thus, it creates the merkle with an address to which first user initially sent funds. Then the first user's transaction gets executed and the transferred funds are sent to the second user's controlled merkle.
If users rely on the address derivation in advance, any funds/tokens sent to it could potentially be withdrawn by anyone else leading to the theft of user funds.
Manual Review
Try the deployment using create2 with salt that includes real msg.sender.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.