Gondi — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Gondi, 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 Gondi 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, 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 Gondi
- Reentrancy findings disclosed against Gondi
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Gondi: Collected fees are never transferred out of Pool contract
In Gondi's Pool contract, loan repayment or liquidation computes a management/performance fee via FeeManager.processFees() and accrues it to the getCollectedFees state variable, but no code path ever transfers these accrued fees out of the Pool. Because processFees() is a view function that only calculates and never moves funds, the accumulated fees remain permanently trapped in the contract. This constitutes a value leak that only becomes material over time as lending volume accumulates fees. The finding was confirmed by the sponsor, downgraded by the judge from high to medium as a 'leak of value', and remediated by adding a collectFees() method that was mitigation-confirmed.
Gondi: Borrower signature could be reused in `emitLoan()`
Gondi's emitLoan() lets a borrower authorize a new NFT-collateralized loan via an off-chain signature (LoanExecutionData). Because the signature is never invalidated or nonce-bound, it can be replayed after the loan is repaid: anyone can call emitLoan() with the old signature to force the borrower into a fresh loan, drawing from any lender offer that still has capacity and has not expired. A single signature can be reused multiple times, limited only by offer capacity. The high-level impact is an authorization/replay flaw forcing unwanted loans on borrowers who set long expirations. The sponsor confirmed and the judge downgraded it to Medium because the borrower controls the expiration, and the project mitigated by instructing borrowers to use short expirations.
Gondi: Function `settleWithBuyout()` does not call `LoanManager.loanLiquidation()` during a buyout
Gondi's Pool is an ERC4626 vault whose lenders participate in loans through MultiSourceLoan. When a loan terminates because the borrower repays or the loan is liquidated, MultiSourceLoan invokes Pool.loanRepayment() or Pool.loanLiquidation(), which update the Pool's queue accounting and outstanding values. However, in settleWithBuyout(), the main lender repays all other lenders directly out of their own funds without triggering the pool-hook path, so if one of those repaid lenders is the Gondi Pool, the Pool never receives the loanLiquidation() callback and its internal accounting stays stale. Because depositors' share value and queue state depend on that accounting, skipping the callback mis-states the Pool's outstanding exposure and yield, distorting the vault economics. The sponsor confirmed the issue and shipped a fix that adds the loanLiquidation() call in the buyout path.