Putty — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Putty, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 19
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 19 closed, publicly disclosed Putty 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 Access control, Logic error, Reentrancy, Integer overflow / underflow, Front-running / MEV, 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
- Access control findings disclosed against Putty
- Logic error findings disclosed against Putty
- Reentrancy findings disclosed against Putty
- Integer overflow / underflow findings disclosed against Putty
- Front-running / MEV findings disclosed against Putty
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Putty: [Denial-of-Service] Contract Owner Could Block Users From Withdrawing Their Strike
PuttyV2's withdraw function deducts a platform fee from a user's escrowed strike and transfers that fee to the contract owner inline, before sending the remaining strike to the user. Because the user's transfer only executes if the owner fee transfer succeeds, the owner can permanently block all strike withdrawals by making that fee transfer revert — either by transferring ownership to the zero address (rejected by common ERC20s) or by adopting a malicious token whose transfer-to-owner reverts. The judge initially rated the issue high but downgraded it to medium because the triggering conditions are unlikely (fee must be nonzero or a malicious base asset adopted); the protocol confirmed it and fixed it by relocating the platform fee transfer to order-filling time, so any remaining owner griefing only causes a DoS rather than trapping user funds.
Putty: An attacker can create a short put option order on an NFT that does not support ERC721 (like cryptopunk), and the user can fulfill the order, but cannot exercise the option
The Putty protocol incorrectly assumes that all NFT assets used as underlying collateral in options contracts support the full ERC-721 standard. By using a safeTransferFrom implementation that requires the onERC721Received callback, the protocol unintentionally renders certain legacy NFTs, like CryptoPunks, unexercisable. Attackers can exploit this by offering options on these incompatible assets, collecting premiums from users who are then unable to exercise their options or receive the underlying asset.
Putty: `fillOrder()` and `exercise()` may lock Ether sent to the contract, forever
The Putty protocol's `fillOrder` and `exercise` functions are marked as payable to accommodate Ether-based transactions. However, these functions lack logic to validate that `msg.value` is only sent when required by the specific execution path. Users can accidentally send Ether to these functions when performing operations that use non-Ether code paths, leading to the funds being permanently trapped within the contract with no recovery mechanism.
Putty: `fee` can change without the consent of users
The Putty protocol was vulnerable to an economic logic error where active option orders were susceptible to arbitrary fee increases. The protocol calculated fees based on current global state during withdrawal, rather than pinning the fee rate at the time an order was filled. This allowed the protocol owner to adjust fees, forcing users to pay significantly higher costs than they had originally agreed to when creating or filling their orders.
Putty: Overlap Between `ERC721.transferFrom()` and `ERC20.transferFrom()` Allows `order.erc20Assets` or `order.baseAsset` To Be ERC721 Rather Than ERC20
Putty protocol is vulnerable to a token standard confusion issue where ERC721 tokens can be submitted in place of ERC20 assets. Because both standards share similar transferFrom function signatures, the protocol successfully pulls the NFT into its custody. However, due to the incompatibility between ERC20-based withdrawal logic and the ERC721 standard, these tokens become permanently locked within the contract, resulting in a total loss of funds for the depositor.
Putty: The contract serves as a flashloan pool without fee
PuttyV2's fillOrder and exercise functions lacked reentrancy protections, allowing a malicious user acting as both maker and taker to re-enter the contract from a malicious base-asset transfer callback. That re-entry exercises a short call to pull real ERC20/ERC721 balances out of PuttyV2, deploy them for profit on other venues, and repay before fillOrder completes. Because the protocol's 3% option fee is assessed in the base asset—an attacker-controlled custom token—the attack amounts to free, unrestricted use of all assets held by the contract. Sponsor and judge acknowledged the validity, agreeing flashloans are a feature but fee evasion is a bug, with no easy mitigation beyond nonReentrant guards at a gas cost.
All reports in this group
- Putty: Create a short call order with non empty floor makes the option impossible to exercise and withdrawLogic error$0
- Putty: Put options are free of any feesInteger overflow/underflow$0
- Putty: Zero strike call options will avoid paying system feeLogic error$0
- Putty: Options with a small strike price will round down to 0 and can prevent assets to be withdrawnInteger overflow/underflow$0
- Putty: Malicious Token Contracts May Lead To Locking OrdersLogic error$0
- Putty: Put option sellers can prevent exercise by specifying zero amounts, or non-existant tokensLogic error$0
- Putty: Zero strike call options can be systemically used to steal premium from the takerReentrancy$0
- Putty: Order duration can be set to 0 by Malicious makerLogic error$0
- Putty: Putty position tokens may be minted to non ERC721 receiversReentrancy$0
- Putty: `acceptCounterOffer()` May Result In Both Orders Being FilledFront-running / MEV$0
- Putty: Unbounded loops may cause `exercise()`s and `withdraw()`s to failLogic error$0
- Putty: Fee is being deducted when Put is expired and not when it is exercised.Logic error$0
- Putty: Order cancellation is prone to frontrunning and is dependent on a centralized databaseFront-running / MEV$0