Inverter Network — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Inverter Network, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 12
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 12 closed, publicly disclosed Inverter Network reports indexed on CoinBuggie. 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 Inverter Network
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Inverter Network: wrong `defaultCurrency` can be set in the `OptimisticOracleIntegrator` causing the `defaultBond` to be zero
Inverter Network's OptimisticOracleIntegrator allows an operator to set a default bond currency that is not whitelisted as UMA collateral. The `_setDefaultCurrencyAndBond` setter only rejects a zero address, while UMA's `getMinimumBond` derives the minimum bond from the currency's cached final fee — which is zero for any non-whitelisted token. This lets a misconfiguration configure a zero defaultBond, stripping the economic stake that backs oracle data assertions and weakening slashing/incentive guarantees.
Inverter Network: FM_Rebasing_v1` is vounerable to just in time liquidity
Inverter Network's FM_Rebasing_v1 rebasing funding manager lets depositors hold bit-denominated shares that accrue value when tokens flow into the vault, but it imposes no withdrawal lockup or time-weighting on freshly deposited capital. This lets an attacker who can observe a pending value-increasing transaction (e.g. a protocol profit transfer into the vault) front-run it with a large deposit to capture a big share of the pool, then immediately back-run it with a withdrawal. The numeric example shows Bob netting 500 tokens (~50% of the rewards intended for active depositors) risk-free, transforming routine reward distributions into a sandwichable MEV window.
Inverter Network: LM_PC_Staking_v1&LM_PC_KPIRewarder - User can brick both contracts if he is first staker
Both LM_PC_Staking_v1 and LM_PC_KPIRewarder_v1 let a user pass an arbitrary uint amount to stake, and credit that exact amount to internal accounting while transferring the token. For tokens such as cUSDCv3 whose transfer special-cases type(uint256).max to move the user's entire balance, a first depositor can stake the maximum value: the contract believes it holds type(uint256).max worth of stake while only receiving a dust balance. Any subsequent stake then overflows the cumulative accounting and reverts, permanently bricking both contracts. If reward tokens were already pre-funded, they become unrecoverable, and there is no mechanism to force-dequeue the malicious stake.
Inverter Network: Payment Processors treat calls to non-contracts as a successful transfer calls
Inverter Network's Payment Processor modules PP_Simple_v1 and PP_Streaming_v1 perform low-level calls to transfer tokens, and guard success with a check that passes when the call returns empty data. Because a low-level call to an address that is not a contract returns success with empty return data, a payment to a non-contract token address is reported as successful even though no actual transfer occurred. This lets the TokensReleased event fire and any listening client or downstream module be told a payment succeeded when it did not, which the reporter frames as enabling phishing-style misreporting and hidden assumptions in the modular architecture. The fix is to replace the raw calls with OpenZeppelin's SafeERC20.
Inverter Network: PP_Streaming_v1.sol#_findAddressInActiveStreams() - `activePaymentReceivers` can become so large that it's impossible to process more payments, effectively bricking the processor
Inverter Network's PP_Streaming_v1 payment processor maintains an `activePaymentReceivers` array per client that is scanned linearly in `_findAddressInActiveStreams()` every time a new payment is added. Because the array is unbounded and prune-able entries only clear once claimed, an attacker can exploit LM_PC_Staking_v1 (which lets anyone stake a tiny amount and claim via the processor) to inflate this array with thousands of bogus receivers. Once large enough, adding a payment exceeds the block gas limit, bricking claimRewards and, transitively, stake/unstake since they call `_distributeRewards`, freezing legitimate user funds. The DoS is persistent because prunable cleanup requires real users to have claimed and a payment-processor swap is itself blocked while unclaimed legitimate entries remain.
Inverter Network: Admin Can Bypass Important Checks and Timelock Mechanism
Inverter Network's privileged-module timelock flow has a parameter-consistency defect: the three execute-step functions accept an address argument that is never checked against the address recorded by the matching initiate-WithTimelock call. Because of this, an admin can initiate a change for one module address and later execute with a different address that never passed the intended checks including the privileged-module interface validation. A second variant lets the admin cancel an authorizer update in front of users while still executing with the original pending address later, sidestepping the 72-hour timelock notification window. Economically, this lets a privileged actor swap critical authorizer, funding-manager, or payment-processor modules without the governance safeguards visible to the community.
All reports in this group
- Inverter Network: Admin Can Bypass Checks for Privileged ModulesLogic error$0
- Inverter Network: LM_PC_Bounties_v1::contributorsNotChanged`check is not enough, could result in CLAIMANT adding additional contributors in the last minute Logic error$0
- Inverter Network: LM_PC_KPIRewarder_v1` if bond token has a blocklist and disputer set disputer address to a blocked address, result in DoSLogic error$0
- Inverter Network: LM_PC_Staking_v1` can be used for pyramid scheme, because it is using current stakers funds to reward othersLogic error$0
- Inverter Network: LM_PC_Staking_v1.sol - allocated rewards can never be fully distributed, leftovers cannot be rescuedLogic error$0
- Inverter Network: LM_PC_KPIRewarder_v1.sol#assertionResolvedCallback() - `LM_PC_KPIRewarder_v1` can be set as a callback address to another assertion in order to set `assertionPending = false`Logic error$0