Camp security record

The `DisputeModule` contract uses a global `isUsedEvidenceHash` mapping to prevent duplicate evidence submission across all disputes. However, this design enables malicious actors to permanently block legitimate disputes by front-running evidence hashes. When a dispute is raised in `raiseDispute()`, the evidence hash is marked as used globally and permanently, even if the dispute is later cancelled via `cancelDispute()`. Since the Camp network relies on a private mempool, there's no potential for the classic frontrunning exploitation. However, IP Owners may still be able to foresee future evidence hashes that can be blocked by raising throwaway disputes with the same evidence hash, then cancelling before the cooldown period elapses to recover their bond while permanently burning the evidence hash.

Access to tokens can be bought via the `Marketplace` contract following a subscription model. The `hasAccess()` function is used by offchain components to evaluate if a user has access to some token. Currently, this depends on the state of the token and the state of the subscription. Therefore, users need subscriptions to their own tokens to have the expected access. A similar issue arises during the token minting process, where the royalty module ensures that the minter had subscriptions to all parent tokens in the past. Again, minters are required to have had subscriptions to their own tokens.

In the `bridgeOut` function, a whitelisted sender must send a value at least equal to `_totalNativeTokens`. However, if the value sent exceeds `_totalNativeTokens`, the excess remains locked in the `CampTimelockEscrow` contract. Similarly, in the `release` function, small "dust" amounts of native tokens can remain locked. This occurs because `_totalNativeTokens` is calculated as `fee.nativeFee + _dustAdjustedAmount`, which may differ slightly from the original deposit amount.

This contract mints wrapped tokens in a 1:1 ratio for native token deposits. The `totalSupply()` of this token contract is determined by querying `address(this).balance`. However, the balance of the contract can differ from the total sum of deposits if another contract forces a native token transfer using `selfdestruct`, which circumvents the otherwise correctly implemented `receive()` function. This opcode is deprecated, but currently still supported and can be used in this manner.

In the `notifyRewardAmount()` function, the reward rate calculation uses integer division (`rewardRate = reward / rewardsDuration`). When the reward amount is not evenly divisible by the rewards duration, the remainder is truncated and becomes permanently locked in the contract. This dust accumulates over time with each `notifyRewardAmount` call, permanently reducing the effective reward distribution.

This contract exposes an empty `receive()` function. This is necessary to allow for refunds from the LayerZero system. The refund address is set for each `send()` operation, but is currently always set to this contract. However, the contract does not offer any option to rescue these unaccounted tokens, causing them to be trapped in the contract.

The owner-only function `setRewardsDuration()` allows setting a new duration for reward periods. However, it lacks a check to prevent `_rewardsDuration` from being set to zero. If the owner calls this function with `_rewardsDuration = 0`, the rewardsDuration state variable becomes zero. The next time the owner attempts to start a new reward period by calling `notifyRewardAmount()`, the transaction will revert due to a division-by-zero error in the line `rewardRate = reward / rewardsDuration`. This bricks the reward distribution mechanism, making it impossible to add new rewards until the owner rectifies the situation by calling `setRewardsDuration()` again with a non-zero value. ```solidity function setRewardsDuration(uint256 _rewardsDuration) external onlyOwner { if (block.timestamp <= periodFinish) revert RewardsPeriodNotFinished(); rewardsDuration = _rewardsDuration; emit RewardsDurationUpdated(rewardsDuration); } ```

Running the `npm install` command to install the dependencies highlights 17 vulnerabilities (2 low, 14 high, 1 critical). This may introduce backdoors, known vulnerabilities or unexpected behavior into the system.