predict.fun lending market — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for predict.fun lending market, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 2
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 2 closed, publicly disclosed predict.fun lending market 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, 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 predict.fun lending market
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
predict.fun lending market: A borrower can not repay to a USDC blacklisted lender
In PredictDotLoan's repay() flow the borrower settles an outstanding loan by transferring the loan token directly to the lender's wallet via safeTransferFrom. When the loan token is USDC and the lender's address has been blacklisted by USDC's registry, that transfer reverts, so the borrower can never repay and never recover their ERC1155 collateral. Because the auction fallback also requires transferring USDC to the same blacklisted lender, the lender is effectively guaranteed to call the matured loan and seize all collateral. The acknowledged fix is to switch to a push-pull model where the borrower deposits the debt into the contract and the lender claims their funds from it, removing the dependency on transferring to a blacklistable address.
predict.fun lending market: hashProposal uses wrong typeshash when hashing the encoded Proposal struct data
In predict.fun's loan market, the EIP712 type hash constructed inside hashProposal() declares questionId as uint256 even though the Proposal struct defines the field as bytes32. Because the encoded struct value is still the bytes32, the type hash no longer matches the schema, so the domain-separated digest used to validate signatures is computed from a mismatched representation. Three order-matching entry points — acceptLoanOfferAndFillOrder, _refinance and matchProposals — validate signatures against the incorrect digest, breaking signature verification and violating the protocol's stated strict EIP712 compatibility requirement. The protocol team confirmed the issue and merged a fix (PR #37) changing the type hash to bytes32 questionId.