The Wildcat Protocol — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for The Wildcat Protocol, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 9
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 9 closed, publicly disclosed The Wildcat Protocol 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 Integer overflow / underflow, Logic error, Reentrancy, Front-running / MEV, Access control, 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
- Integer overflow / underflow findings disclosed against The Wildcat Protocol
- Logic error findings disclosed against The Wildcat Protocol
- Reentrancy findings disclosed against The Wildcat Protocol
- Front-running / MEV findings disclosed against The Wildcat Protocol
- Access control findings disclosed against The Wildcat Protocol
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
The Wildcat Protocol: User could withdraw more than supposed to, forcing last user withdraw to fail
In The Wildcat Protocol, withdrawal requests are batched and executed based on proportional interest scaling. When a market is closed, withdrawal requests within an active batch can be executed before all lenders have added their requests. A early withdrawer can execute at an outdated rate, while subsequent micro-withdrawals further alter precision and lower the batch rate, leaving insufficient unclaimed balance for remaining lenders. Consequently, the final user attempting to process their withdrawal experiences a transaction revert and permanent loss/locking of funds.
The Wildcat Protocol: `FixedTermLoanHooks` allow Borrower to update Annual Interest before end of the "Fixed Term Period"
In Wildcat Protocol's fixed-term loan hooks implementation, a missing check in `onSetAnnualInterestAndReserveRatioBips` allowed borrowers to reduce the market's annual percentage rate (APR) prior to the expiration of a fixed-term loan period. Because lenders in fixed-term markets are strictly restricted from initiating early withdrawals until the term ends, borrowers could lower interest rates (down to zero) without triggering or allowing lender ragequits. This resulted in lenders being locked into capital commitments under altered economic terms and losing out on expected interest yield.
The Wildcat Protocol: Users are incentivized to not withdraw immediately after the market is closed
In The Wildcat Protocol, withdrawal requests within the same withdrawal batch share a blended execution rate. When a market is closed while an unexpired withdrawal batch exists, new withdrawal requests are bundled into the old batch, causing the effective interest rate for new withdrawers to be dragged down by earlier requests. This creates an economic disincentive for users to withdraw immediately upon market closure, forcing them to either accept a diluted rate or lock their funds until the batch expires to claim their full earned APY.
The Wildcat Protocol: Inconsistency across multiple repaying functions causing lender to pay extra fees
In The Wildcat Protocol, market functions differ in whether they pull tokens before or after updating the market state. In standard repayment functions, assets are pulled prior to state calculation so that pending withdrawal batches and interest accrual account for the newly available funds. Conversely, functions like `closeMarket` calculate the updated market state before transferring funds, leading to higher accrued interest and fees charged to borrowers than if transfers occurred first.
The Wildcat Protocol: No lender is able to exit even after the market is closed
In Wildcat v2, fixed-term loan markets utilize hooks to restrict lender withdrawals until a designated maturity timestamp (`fixedTermEndTime`). While borrowers are permitted to close a market early, the `onCloseMarket` hook callback did not update or clear `fixedTermEndTime`. Consequently, even after a market was closed and marked inactive, lenders remained unable to queue or execute withdrawals until the original fixed-term timestamp had passed. This resulted in temporary locking of lender funds despite the loan market being officially shut down.
The Wildcat Protocol: Role providers cannot be EOAs as stated in the documentation
The Wildcat Protocol documentation states that externally owned accounts (EOAs) can be configured as role providers without needing to implement contract interface functions. However, the `AccessControlHooks` contract attempts to make a static call to `isPullProvider()` whenever a new role provider is registered via `addRoleProvider`. Because EOAs lack smart contract code, this external call fails and causes the registration transaction to revert, preventing non-deployer EOAs from being added as role providers.
All reports in this group
- The Wildcat Protocol: `AccessControlHooks` `onQueueWithdrawal()` does not check if market is hooked which could lead to unexpected errors such as temporary DoSFront-running / MEV$0
- The Wildcat Protocol: Role providers can bypass intended restrictions and lower expiry set by other providersAccess control$0
- The Wildcat Protocol: `FixedTermLoanHook` looks at `block.timestamp` instead of `expiry`Logic error$0