INIT Capital — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for INIT Capital, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 13
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 13 closed, publicly disclosed INIT Capital 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, Reentrancy, Front-running / MEV, Oracle manipulation, 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 INIT Capital
- Reentrancy findings disclosed against INIT Capital
- Front-running / MEV findings disclosed against INIT Capital
- Oracle manipulation findings disclosed against INIT Capital
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
INIT Capital: `fillOrder` not properly cancel order when collateral of position is empty
INIT Capital's MarginTradingHook.fillOrder contains a memory-versus-storage write bug in its empty-position cancellation branch. When the collateral amount of the order's position is zero, the function intends to cancel the order, but it mutates the status field of a local memory copy of the Order struct rather than the storage-backed __orders entry. As a result, the storage status remains Active and the cancellation is never persisted, misleading users into believing their order was canceled. The judge rated this a Medium because order cancellation fails to work as intended, while the sponsor argued for QA given the absence of direct fund impact.
INIT Capital: `setPosMode` should not allow changing the mode when the new mode's `canRepay` status is disabled
The INIT Capital protocol contains a business logic vulnerability that allows users to avoid position liquidation by manipulating their account's mode. Specifically, the setPosMode function fails to verify whether a new mode allows for debt repayment, permitting users to switch to a mode where repayment is disabled. An attacker can exploit this by switching to an 'unrepayable' mode when their position health approaches the liquidation threshold, thereby blocking liquidators from closing the position and protecting the account from insolvency.
INIT Capital: If wLP is blacklisted, then user will not be able to withdraw it
INIT Capital's lending protocol lets users deposit wLP tokens as collateral, gated by a whitelist check at deposit time. The flaw is that the withdrawal path re-evaluates the same whitelist state, so once governance blacklists a wLP collateral token to phase it out, holders who still hold that collateral can no longer withdraw it—even though their position is healthy and passes the health check that would normally permit reducing collateral. The reporter notes the liquidation path is largely unaffected because blacklisting is expected to follow a collateral-factor step-down to zero, but the withdrawal freeze remains a genuine governance-triggered fund lock. The sponsor acknowledged the finding and committed to using unwhitelisting with care.
INIT Capital: `_handleRepay` of `MoneyMarketHook` does not consider the actual debt shares of the `posId` inside the position manager and could lead to a user's tokens getting stuck inside the hook
The MoneyMarketHook in the INIT Capital protocol fails to verify the actual debt balance of a position before transferring tokens from a user to perform a repayment. Because the transfer amount is derived from user-provided parameters rather than the current on-chain debt, the protocol is susceptible to a race condition. If a user's position is liquidated after they submit their repayment transaction but before it is confirmed, the Hook will still transfer the full amount of funds, leaving the excess tokens locked inside the Hook contract with no automated way to retrieve them.
INIT Capital: repay(), liquidate() and liquidateWLp() receive shares as argument, which may revert if from approval to tx settled blocks have passed
The INIT Capital protocol's repay and liquidate functions fail because they require fixed share inputs, which are susceptible to interest accumulation between transaction submission and execution. Because the protocol calculates interest based on the current timestamp, debt balances increase even in the brief interval between a user's allowance approval and the transaction's confirmation on-chain. Consequently, any transaction based on a previous debt estimate will revert when the contract's required transfer amount exceeds the user's pre-approved allowance.
INIT Capital: When the `returnNative` parameter is set to true in the `_params` provided to `MoneyMarketHook.execute`, it is not handled properly and could disrupt user expectations
The `MoneyMarketHook` contract in the INIT Capital protocol fails to properly handle the `returnNative` parameter during token withdrawals. When a user requests a native token withdrawal, the contract incorrectly routes the underlying tokens directly to the user's address rather than to the hook contract. This prevents the contract from unwrapping the tokens, causing the feature to fail and potentially disrupting integrations that rely specifically on receiving native ETH.
All reports in this group
- INIT Capital: wLp tokens could be stolenLogic error$0
- INIT Capital: Decimals of LendingPool don't take into account the offset introduced by VIRTUAL\_SHARESLogic error$0
- INIT Capital: `collateralizeWLp` can be bypassed even when collateralization is pausedReentrancy$0
- INIT Capital: Liquidations can be prevented by frontrunning and liquidating 1 debt (or more) due to wrong assumption in POS\_MANAGERFront-running / MEV$0
- INIT Capital: Malicious user can steal native tokens of MoneyMarketHook callerReentrancy$0
- INIT Capital: Lack of way to handle not fully repaid bad debt after liquidation after the lending pool share or WLP are fully seizedLogic error$0
- INIT Capital: API3 oracle timestamp can be set to future timestamp and block API3 Oracle usage to make code revert in underflowOracle manipulation$0