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
- 14
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 14 closed, publicly disclosed Putty 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 Front-running / MEV, Logic error, Integer overflow / underflow, 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
- Front-running / MEV findings disclosed against Putty
- Logic error findings disclosed against Putty
- Integer overflow / underflow findings disclosed against Putty
- Reentrancy 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: Order cancellation is prone to frontrunning and is dependent on a centralized database
Putty's order cancellation mechanism suffered from critical dependencies on centralized infrastructure and exposure to frontrunning. Because cancellations required on-chain transactions with specific order data, users could not cancel without either interacting with a centralized database or risking MEV-based frontrunning. This design created a significant risk where a centralized server outage could prevent users from invalidating orders, leaving their funds vulnerable to exploitation by parties holding mirrored order data.
Putty: Order duration can be set to 0 by Malicious maker
Putty's option-order protocol failed to enforce a minimum order duration, letting a maker submit an order with a duration of zero. Such an order expires the instant it is filled, so a taker who fills it is immediately trapped in an expired state and can only withdraw while still paying fees derived from the strike price. This lets a malicious maker force takers into a financially pointless transaction, incurring losses. The maintainers confirmed the issue and fixed it by requiring a minimum order duration of 15 minutes at fill time.
Putty: Options with a small strike price will round down to 0 and can prevent assets to be withdrawn
The Putty protocol contains a vulnerability where certain ERC-20 tokens, which revert on zero-value transfers, can cause a Denial-of-Service during asset withdrawals. The issue occurs because the protocol's fee calculation uses integer division, which can round down to zero for small strike prices and low fee rates. When the contract attempts to transfer this zero-value fee to the protocol's treasury, the transaction reverts, permanently locking the user's assets within the vault.
Putty: Putty position tokens may be minted to non ERC721 receivers
The Putty protocol incorrectly uses an unsafe minting function when generating ERC721 position tokens for users and makers. This omission fails to verify that the receiving contract can properly handle ERC721 tokens, leading to a risk where positions are sent to non-ERC721-compliant receivers. Consequently, if a smart contract recipient lacks the necessary logic to interact with or transfer these tokens, the assets remain permanently trapped, unable to be exercised or withdrawn.
Putty: Zero strike call options can be systemically used to steal premium from the taker
The Putty protocol was vulnerable to a permanent denial-of-service (DOS) condition when users attempted to exercise zero-strike call options involving specific non-standard ERC20 tokens. If a token reverted on zero-value transfers, the protocol's unconditional transfer attempt made it impossible for takers to exercise their options, allowing malicious makers to collect premiums without risk. This vulnerability allowed makers to systematically exploit unsuspecting takers by creating orders that appeared valid but were functionally impossible to exercise.
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.
All reports in this group
- Putty: `fillOrder()` and `exercise()` may lock Ether sent to the contract, foreverLogic error$0
- Putty: Put options are free of any feesInteger overflow/underflow$0
- Putty: Overlap Between `ERC721.transferFrom()` and `ERC20.transferFrom()` Allows `order.erc20Assets` or `order.baseAsset` To Be ERC721 Rather Than ERC20Logic error$0
- Putty: Create a short call order with non empty floor makes the option impossible to exercise and withdrawLogic error$0
- Putty: `acceptCounterOffer()` May Result In Both Orders Being FilledFront-running / MEV$0
- 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 optionLogic error$0
- Putty: Put option sellers can prevent exercise by specifying zero amounts, or non-existant tokensLogic error$0
- Putty: Fee is being deducted when Put is expired and not when it is exercised.Logic error$0