The project has the risk of getting a Vampire Attack due to the fixed fee rate

[code423n4]

Lines of code

https://github.com/code-423n4/2022-12-caviar/blob/main/src/Caviar.sol#L12

Vulnerability details

Traders pay a 30bps (0.3%) fee each time they buy or sell. This fee accrues to the liquidity providers and acts as an incentive for people to deposit liquidity.

However, the competition in NFT projects is high, especially with the Vampire Attack method, the platforms take the share of the other.
The fee rate, which is the most important point of the platform for the user, is fixed, there is a risk that a similar project in the future will only increase the fee rate and take the liquidity here.

What is a Vampire Attack in Crypto?
https://medium.com/@buraktahtacioglu/looksrare-vampire-attack-on-opensea-blockchain-roadmap-29bd51753a64
https://omerkeman.medium.com/what-is-a-vampire-attack-in-crypto-fdfc5e1fc5fc

Although the examples above are Vampire Attack, they do not fully comply with our findings here, because while this is done with airdrop, it is thought that this will be done with the fee rate in our case.

Proof of Concept

1- Caviar platform works with a fixed 0.3% commission rate
2- With the hype of NFTs, competition increases and platforms increase and a competing project charges 0.1% on each trade to get a share of existing users of Caviar instead of finding new users, and many NFT AMM users, including Caviar, offer an airdrop opportunity.
3- Users with a large number of trading movements receive a share and due to the fixed fee rate, the Caviar platform cannot react to it

Recommended Mitigation Steps

Instead of a fixed fee rate, this problem can be solved in two ways;
1- Function is added so that the rate of Fee can be updated by an authorized owner
2- Core Contract can be made upgradable (A different architecture is required for this)
3- The commission rate should be fixed with a certain upper rate so that users will not have a trust problem.

Uniswap v3 solved this problem as follows;

 /// @inheritdoc IUniswapV3PoolOwnerActions
    function setFeeProtocol(uint8 feeProtocol0, uint8 feeProtocol1) external override lock onlyFactoryOwner {
        require(
            (feeProtocol0 == 0 || (feeProtocol0 >= 4 && feeProtocol0 <= 10)) &&
                (feeProtocol1 == 0 || (feeProtocol1 >= 4 && feeProtocol1 <= 10))
        );
        uint8 feeProtocolOld = slot0.feeProtocol;
        slot0.feeProtocol = feeProtocol0 + (feeProtocol1 << 4);
        emit SetFeeProtocol(feeProtocolOld % 16, feeProtocolOld >> 4, feeProtocol0, feeProtocol1);
    }

NFTX solved this issue as follows;

https://github.com/NFTX-project/nftx-protocol-v2/blob/master/contracts/solidity/NFTXVaultFactoryUpgradeable.sol#L77-L97

 function setFactoryFees(
        uint256 mintFee, 
        uint256 randomRedeemFee, 
        uint256 targetRedeemFee,
        uint256 randomSwapFee, 
        uint256 targetSwapFee
    ) public onlyOwner virtual override {
        require(mintFee <= 0.5 ether, "Cannot > 0.5 ether");
        require(randomRedeemFee <= 0.5 ether, "Cannot > 0.5 ether");
        require(targetRedeemFee <= 0.5 ether, "Cannot > 0.5 ether");
        require(randomSwapFee <= 0.5 ether, "Cannot > 0.5 ether");
        require(targetSwapFee <= 0.5 ether, "Cannot > 0.5 ether");

        factoryMintFee = uint64(mintFee);
        factoryRandomRedeemFee = uint64(randomRedeemFee);
        factoryTargetRedeemFee = uint64(targetRedeemFee);
        factoryRandomSwapFee = uint64(randomSwapFee);
        factoryTargetSwapFee = uint64(targetSwapFee);

        emit UpdateFactoryFees(mintFee, randomRedeemFee, targetRedeemFee, randomSwapFee, targetSwapFee);
    }

[Shungy]

This reads more like informational. That would mean this submission's severity is overinflated.

[outdoteth]

Vampire attack design is out of scope

[c4-sponsor]

outdoteth marked the issue as sponsor disputed

[berndartmueller]

Downgrading to QA (NC) as this represents a recommendation to reconsider the design of the fee mechanism of the protocol.

[c4-judge]

Duplicate of #203