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
33
Total paid
$0
Critical
0
Largest payout
$0

This page collects the 33 closed, publicly disclosed Gondi 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, Reentrancy, Integer overflow / underflow, Access control, Signature replay, 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
  • Integer overflow / underflow findings disclosed against Gondi
  • Access control findings disclosed against Gondi
  • Signature replay 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.

mediumLogic errorEVM-Solidity$0

Gondi: Bidders might lose funds due to possible racing condition between `settleWithBuyout` and `placeBid`

Gondi's AuctionWithBuyoutLoanLiquidator contains a boundary-condition flaw where the main lender's buyout path and the general bid path share an overlapping timestamp check around the buyout deadline. Because settleWithBuyout only reverts after the boundary (timeLimit < block.timestamp) while placeBid only reverts before it (timeLimit > block.timestamp), both operations are permitted at the exact boundary. If a bidder's placeBid is mined in the same block as a settleWithBuyout that runs after it, settlement still believes no bid exists, transfers the collateral NFT out, and deletes the auction record — stranding the bidder's funds. Gondi confirmed the issue and mitigated it by making the buyout boundary strict so the buyout can no longer execute once bidding is open at that timestamp.

Gondicode4renaJul 25, 2024Open
mediumLogic errorEVM-Solidity$0

Gondi: `confirmUnderwriter()` need to recalculate `getMinTimeBetweenWithdrawalQueues`

Gondi's Pool contract computes the minimum time between withdrawal-queue overwrites once at construction, derived from the active offer handler's maximum loan duration plus a buffer divided by the max queue count. When the owner confirms a new underwriter via confirmUnderwriter(), only the handler reference is swapped and this minimum is not recalculated. If the replacement handler exposes a larger getMaxDuration, pending withdrawal queues can be overwritten on a shorter timetable than the new loan term requires, so a repaying loan's corresponding queue may already be evicted and unmatchable. The sponsor confirmed and mitigated by making the value mutable and recomputing it (with a non-decreasing bound) on every underwriter confirmation.

Gondicode4renaJul 25, 2024Open
highLogic errorEVM-Solidity$0

Gondi: Incorrect accounting of `_pendingWithdrawal` in `queueClaiming` flow

Gondi's Pool.sol contains an accounting defect in the queue-related withdrawal distribution logic. When queueClaimAll() runs, a distribution loop assigns rather than accumulates the per-queue received loan funds into _pendingWithdrawal[secondIdx], so earlier queue indexes' contributions are overwritten by later ones. Because getTotalReceived[_idx] is zeroed before the loop, the lost intermediate values are unrecoverable, leaving pendingWithdrawal totals too low and effectively losing repaid funds for claimants tied to earlier queues. Gondi confirmed the issue and the fix (adding a missing '+') was verified in the follow-up mitigation contest by multiple independent reporters.

Gondicode4renaJul 25, 2024Open
mediumReentrancyEVM-Solidity$0

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.

Gondicode4renaJul 25, 2024Open
mediumLogic errorEVM-Solidity$0

Gondi: `loanLiquidation()` calculation of interest is not accurate

Gondi's loanLiquidation() route passed the entire liquidation recovery amount to FeeManager.processFees() as principal, even though any proceeds above the loan principal economically represent interest. Because processFees() charges the management fee on the principal value and the performance fee on interest, over-stating the principal produced an inaccurate fee split and mis-stated collected-fees accounting whenever an auction recovered more than the principal. The maintainers confirmed the bug and corrected the calculation to separate the over-principal surplus as interest before computing fees.

Gondicode4renaJul 25, 2024Open
highLogic errorEVM-Solidity$0

Gondi: Function `refinanceFromLoanExecutionData()` does not check `executionData.tokenId == loan.nftCollateralTokenId`

Gondi's refinanceFromLoanExecutionData() lets a borrower repay an existing NFT loan and immediately open a new one funded by outstanding lender offers, reusing the same escrowed NFT as collateral without moving it in and out of the protocol. The implementation forwards executionData.tokenId into the offer-processing and validator routines instead of the escrowed loan's loan.nftCollateralTokenId. Because the collateral NFT identity used in validation differs from the one actually held in escrow, a borrower can pass a token id accepted by a lender's offer while genuinely pledging a different, potentially restricted or lower-value NFT. This breaks the invariant that the collateral validated against the lender's signature is the NFT backing the new loan, enabling unauthorized collateral substitution.

Gondicode4renaJul 25, 2024Open

All reports in this group

Vulnerability classes disclosed here

Related protocol pages