hats-finance / Metrom-0xfdfc6d4ac5807d7460da20a3a1c0c84ef2b9c5a2

Smart contracts for the Metrom project.

hats-finance/Metrom-0xfdfc6d4ac5807d7460da20a3a1c0c84ef2b9c5a2 Issues

Potential Out-of-Gas in createCampaigns Function
Updated 3 months ago1
Malicious User Can Bypass the Fee by Leveraging Incorrect Precision Handling
Updated 3 months ago1
Anyone can Deposit Native Erc20 Token for Free and Steal Funds
Updated 10 days ago1
Irreversible Contract Ossification
Updated 3 months ago1
Lack of Ownership Retention Mechanism
Updated 3 months ago1
Lack of check for existing specificFee before overwrite
Updated 3 months ago4
Inconsistent indexing of event fields in IMetrom.sol interface
Updated 3 months ago1
Metrom.sol contract does not support updating campaigns as mentioned by natspec
Updated 3 months ago1
Missing support for meta-transactions prevents certain users from claiming their deserved rewards
Updated 3 months ago3
Incorrect check for campaign start time
Updated 3 months ago3
`_bundle.chainId` must be validated on campaign creation in `createCampaigns()`
Updated 3 months ago2
The emit in the `acceptCampaignOwnership` function omit key information.
Updated 3 months ago2
Metrom.sol contract misses out on potential yield on Blast
Updated 2 months ago6
`ossify` Function Should Check `ossified` Before Assignment
Updated 3 months ago1
`setSpecificFee` Checks Behavior is Different from Intended
Updated 3 months ago1
Hash Collision Vulnerability in _campaignId Function Leading to Potential Overwriting and Unauthorized Access
Updated 3 months ago1
Campaign running period is ignored
Updated 3 months ago1
Reward distribution can be called multiple times for the same campaign
Updated 3 months ago1
`Metrom` does not handle correctly rebasing, inflationary, deflationary tokens and tokens with fee on transfer
Updated 3 months ago3
Front-running the create campaign making users overpay on fees
Updated 3 months ago1
The recoverRewards may revert when it should not, resulting in losses of rewards not recovered
Updated 3 months ago1
Risk of Merkle Tree Collision may result in loss of funds
Updated 3 months ago2
Malicious campaign owner with multiple campaigns can steal funds from other campaigns by exploiting a specific edge case.
Updated 3 months ago1
Merkle implementation does not prevent replication of transactions across chains
Updated 3 months ago5
`abi.encodePacked()` should not be used with dynamic types when passing the result to a hash function such as `keccak256()`
Updated 3 months ago1
No way to recover the unclaimed rewards.
Updated 3 months ago1
There is no way to recover upgradability back after using ossify()
Updated 3 months ago1
add pause/unpause function in the metrom contract
Updated 3 months ago1
users who add liquidity twice in the campaign range time may not be able to claim the second fair reward
Updated 3 months ago2
shadowing-local 5 occurrences
Updated 3 months ago1
Last claimer will not be able to claim rewards due to stETH's 1-2 wei corner issue
Updated 3 months ago5
Protocol does not earn any fees if reward token used has low decimals
Updated 3 months ago16
Campaign owners can bypass protocol fees causing loss to the protocol
Updated 3 months ago5
Missing access control on initialize() function
Updated 3 months ago1
Due to lack of expiration of the merkle proofs users can claim after campaign has concluded
Updated 3 months ago6
Wrong emit parameters in `createCampaign`
Updated 3 months ago1
the function `claimFees` reverts when ther claim fee is zero and break the whole loop
Updated 3 months ago2
Missing check for equal length arrays when creating campaign
Updated 3 months ago1
Unrestricted Updates to Campaign Merkle Roots Pose Significant Risks in Reward Distribution Integrity
Updated 3 months ago1
Ineffective Reward Recovery Due to Incorrect Merkle Proof Verification in `recoverRewards` Function
Updated 3 months ago1
Upgradable contracts should have a __gap variable
Updated 3 months ago1
Off-by-one timestamp error
Updated 3 months ago1
Using > when declaring solidity version without specifying an upperbound can cause future vulnerabilities
Updated 3 months ago1
Sending tokens in a for loop
Updated 3 months ago1
Rewards should only be recoverable after the campain finishes
Updated 3 months ago1
malicious campaign owner can siphon rewards from users
Updated 3 months ago4
distributeRewards function allows duplicate campaigns to be submitted by the updater
Updated 3 months ago11
The emit in the `acceptOwnership` function omits key information.
Updated 3 months ago1
claiming twice of rewards
Updated 3 months ago1
User will not be able to claim rewards if he is blacklisted for the reward tokens
Updated 3 months ago2