Metrom — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Metrom, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 3
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 3 closed, publicly disclosed Metrom reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Metrom
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Metrom: Campaign owners can bypass protocol fees causing loss to the protocol
Metrom lets campaign owners set a custom fee tier per address; when a campaign is created, the protocol charges the creator's resolved fee at creation time. A campaign owner can dodge this charge by creating the campaign from a separate address whose resolved fee is zero (the code sets campaign owner to msg.sender), then transfer the campaign ownership to the original fee-paying owner. Because transferCampaignOwnership() and acceptCampaignOwnership() never re-check the incoming owner's fee tier or collect the difference, the intended fee is never collected, causing direct revenue loss to the protocol. The researcher proposes charging only the difference between the new and current owner's fees at acceptOwnership time to avoid both under- and over-charging.
Metrom: Gas griefing vulnerability in `createCampaigns` function
Metrom's createCampaigns function derives each campaign's storage key from a deterministic keccak256 hash of the bundle's parameters (chain, pool, time window, specification, reward tokens and amounts) and reverts with CampaignAlreadyExists if that ID is already present. Because the ID does not incorporate the caller, an attacker can front-run a victim's batched creation by submitting a bundle with identical variables first, which forces the victim's transaction to revert once it reaches the duplicate entry. The economic impact is limited to gas griefing: the victim's entire multi-campaign transaction is wasted and the campaigns cannot be created unless the attacker's coordinates diverge. The report proposes including msg.sender in the campaign ID so each sender's bundles are unique and cannot collide across senders.
Metrom: Fee-on-Transfer Tokens in `createCampaigns` Function cause revert in `_processRewardClaim`.
Metrom's createCampaigns function books the full requested reward amount into internal accounting before pulling tokens from the caller, which is unsafe for fee-on-transfer ERC-20s. Because such tokens deliver less than the nominal transfer amount (amount minus fee), the contract records reward.amount and reward.unclaimed that exceed its actual balance. When users later call _processRewardClaim, the withdrawal of the over-booked reward reverts, leaving the campaign's rewards permanently stuck. The report proposes measuring the token balance before and after the transfer and using the received delta for all subsequent calculations, eliminating the assumption that the nominal amount equals the received amount.