Quantum Audit Logo

Is PunkStrategy Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

PunkStrategy PNKSTR
0xc506…3edf
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The PunkStrategy contract is designed to manage CryptoPunks on Uniswap V4, acting as an ERC20 token and a strategy for buying, re-listing, and burning its own tokens. The contract leverages established Solady libraries and interacts with well-known protocols like Uniswap V4 and CryptoPunks. However, the audit identified a critical centralization risk where the owner can drain all contract funds. High-severity issues include potential reentrancy patterns due to state updates after external calls and significant trust placed in the configurable Uniswap V4 hook address. Medium-severity concerns involve the lack of slippage protection in token swaps and liquidity provision, exposing the contract to MEV and unfavorable trade execution.

1 Critical2 High2 Medium2 Low
Volume 24h
$56.5K
Liquidity
$1.33M
Price
$0.007698
Token Age
12mo
Top 10 Holders
40.1%

Security Findings

1 Crit2 High2 Med2 Low
Critical

Centralized Control and Fund Drain Risk

C-01The `transferEther(address _to, uint256 _amount)` function, callable only by the contract owner, allows the owner to transfer any amount of ETH from the contract's balance to an arbitrary address. This capability presents a critical centralization risk, as a malicious or compromised owner could drain all funds held by the contract, including accumulated fees and liquidity, leading to a complete loss of user assets and protocol insolvency (7.3 Access Control, 7.4 Economic).
IssueThe `transferEther(address _to, uint256 _amount)` function, callable only by the contract owner, allows the owner to transfer any amount of ETH from the contract's balance to an arbitrary address. This capability presents a critical centralization risk, as a malicious or compromised owner could drain all funds held by the contract, including accumulated fees and liquidity, leading to a complete loss of user assets and protocol insolvency (7.3 Access Control, 7.4 Economic).
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the owner role to require multiple approvals for critical operations like `transferEther`. Alternatively, remove the `transferEther` function if direct owner-initiated ETH transfers are not an essential part of the protocol's intended operation. If necessary, restrict its use to specific, auditable scenarios with clear purpose.
StatusUnresolved
High

Reentrancy Pattern in `buyPunkAndRelist` (State Update After External Calls)

H-01The `buyPunkAndRelist` function performs multiple external calls to `punksContract.buyPunk`, `punksContract.offerPunkForSale`, and `SafeTransferLib.forceSafeTransferETH(msg.sender, reward)` before updating the critical state variable `currentFees` (`currentFees -= totalRequired;`). While the function is protected by `nonReentrant` and `SafeTransferLib` mitigates direct reentrancy from `msg.sender`, the pattern of updating state after multiple external calls is inherently risky. If any of the external calls were to have an unexpected reentrant behavior or if a subsequent call (e.g., to `hookAddress` in another function) could be triggered before `currentFees` is updated, it could lead to an…
IssueThe `buyPunkAndRelist` function performs multiple external calls to `punksContract.buyPunk`, `punksContract.offerPunkForSale`, and `SafeTransferLib.forceSafeTransferETH(msg.sender, reward)` before updating the critical state variable `currentFees` (`currentFees -= totalRequired;`). While the function is protected by `nonReentrant` and `SafeTransferLib` mitigates direct reentrancy from `msg.sender`, the pattern of updating state after multiple external calls is inherently risky. If any of the external calls were to have an unexpected reentrant behavior or if a subsequent call (e.g., to `hookAddress` in another function) could be triggered before `currentFees` is updated, it could lead to an…
FixAdhere to the Checks-Effects-Interactions pattern. Update all relevant state variables (`currentFees`) *before* making any external calls. This ensures that the contract's state is consistent even if an external call re-enters or reverts unexpectedly. For example, decrement `currentFees` immediately after the `if (currentFees < totalRequired)` check and before calling `punksContract.buyPunk`.
StatusUnresolved
High

Uniswap V4 Hook Trust and Potential Exploits

H-02The `hookAddress` is set by the owner in `loadLiquidity` and is integrated into the Uniswap V4 `PoolKey`. This means the `hookAddress` will receive callbacks from Uniswap V4 during various pool operations (e.g., swaps, liquidity changes). A malicious or buggy hook contract could exploit these callbacks to manipulate the pool state, cause reentrancy issues, or perform sandwich attacks/MEV. Additionally, the `hookAddress` can call `addFees()`, allowing it to deposit ETH into the contract. This introduces a significant trust assumption on the `hookAddress` and its implementation, posing a risk to the strategy's integrity and funds (7.6 External, 7.4 Economic).
IssueThe `hookAddress` is set by the owner in `loadLiquidity` and is integrated into the Uniswap V4 `PoolKey`. This means the `hookAddress` will receive callbacks from Uniswap V4 during various pool operations (e.g., swaps, liquidity changes). A malicious or buggy hook contract could exploit these callbacks to manipulate the pool state, cause reentrancy issues, or perform sandwich attacks/MEV. Additionally, the `hookAddress` can call `addFees()`, allowing it to deposit ETH into the contract. This introduces a significant trust assumption on the `hookAddress` and its implementation, posing a risk to the strategy's integrity and funds (7.6 External, 7.4 Economic).
FixThoroughly audit and secure the `hookAddress` contract. Implement strict access controls and validation within the hook contract to prevent malicious actions. Consider making the `hookAddress` immutable after initialization or subject to a robust governance process for changes. Ensure the hook contract's logic is minimal and only performs necessary operations to reduce the attack surface.
StatusUnresolved
Medium

Price Manipulation/Sandwich Attack Risk in `_buyAndBurnTokens`

M-01The `_buyAndBurnTokens` function executes a `swapExactTokensForTokens` on Uniswap V4 to swap ETH for PNKSTR tokens. The `amountOutMinimum` parameter for this swap is implicitly set to `0` (or not specified with a minimum), meaning there is no slippage protection. This vulnerability allows an attacker to front-run the transaction by artificially increasing the PNKSTR price, letting the contract buy at an inflated price, and then back-run to profit from the price difference. This 'sandwich attack' would result in the contract receiving fewer PNKSTR tokens for the same ETH amount, reducing the effectiveness of the token burn (7.2 Code Security, 7.4 Economic).
IssueThe `_buyAndBurnTokens` function executes a `swapExactTokensForTokens` on Uniswap V4 to swap ETH for PNKSTR tokens. The `amountOutMinimum` parameter for this swap is implicitly set to `0` (or not specified with a minimum), meaning there is no slippage protection. This vulnerability allows an attacker to front-run the transaction by artificially increasing the PNKSTR price, letting the contract buy at an inflated price, and then back-run to profit from the price difference. This 'sandwich attack' would result in the contract receiving fewer PNKSTR tokens for the same ETH amount, reducing the effectiveness of the token burn (7.2 Code Security, 7.4 Economic).
FixImplement a reasonable `amountOutMinimum` parameter for the `swapExactTokensForTokens` call in `_buyAndBurnTokens`. This minimum should be calculated based on the expected amount of PNKSTR tokens to be received, allowing for a small, acceptable slippage tolerance. This will protect the contract from significant losses due to price manipulation.
StatusUnresolved
Medium

Lack of Slippage Control in `_loadLiquidity` Initialization

M-02The `_loadLiquidity` function initializes a Uniswap V4 pool with fixed `liquidity` and `startingPrice`. While `amount0Max` and `amount1Max` are used, the `multicall` for `modifyLiquidities` does not include a transaction-level deadline. If the transaction to initialize liquidity is delayed or front-run, the actual price at execution might deviate significantly from the `startingPrice`, leading to an unfavorable liquidity provision ratio or potential loss of funds if the `amountMax` values are insufficient for the desired `liquidity` at the current market price (7.2 Code Security, 7.4 Economic).
IssueThe `_loadLiquidity` function initializes a Uniswap V4 pool with fixed `liquidity` and `startingPrice`. While `amount0Max` and `amount1Max` are used, the `multicall` for `modifyLiquidities` does not include a transaction-level deadline. If the transaction to initialize liquidity is delayed or front-run, the actual price at execution might deviate significantly from the `startingPrice`, leading to an unfavorable liquidity provision ratio or potential loss of funds if the `amountMax` values are insufficient for the desired `liquidity` at the current market price (7.2 Code Security, 7.4 Economic).
FixConsider adding a `deadline` parameter to the `posm.multicall` function itself, or ensure that the `block.timestamp + 60` deadline within `modifyLiquidities` is sufficient and that the `startingPrice` is carefully chosen to reflect current market conditions at the time of deployment. For production systems, dynamic price fetching and slippage control are crucial for liquidity provision.
StatusUnresolved
Low

Fixed `reward` and `priceMultiplier` Parameters

L-01The `reward` (0.01 ETH) and `priceMultiplier` (2000) parameters are fixed values set in the constructor and can only be updated by the owner. While owner control allows for adjustments, these fixed values might not remain optimal under varying market conditions. A static `reward` could become disproportionately high or low relative to gas costs or Punk values, and a fixed `priceMultiplier` might lead to Punks being listed at uncompetitive prices (too high to sell, or too low missing profit), impacting the strategy's efficiency and profitability over time (7.4 Economic).
IssueThe `reward` (0.01 ETH) and `priceMultiplier` (2000) parameters are fixed values set in the constructor and can only be updated by the owner. While owner control allows for adjustments, these fixed values might not remain optimal under varying market conditions. A static `reward` could become disproportionately high or low relative to gas costs or Punk values, and a fixed `priceMultiplier` might lead to Punks being listed at uncompetitive prices (too high to sell, or too low missing profit), impacting the strategy's efficiency and profitability over time (7.4 Economic).
FixConsider implementing a more dynamic mechanism for adjusting `reward` and `priceMultiplier`, perhaps based on market conditions, governance proposals, or a time-weighted average. If owner control is maintained, ensure a robust process for parameter updates, potentially involving a time-lock or multi-signature approval to prevent hasty or malicious changes.
StatusUnresolved
Low

`loadingLiquidity` State Variable Redundancy

L-02The `loadingLiquidity` boolean state variable is set to `true` at the beginning of the `_loadLiquidity` function and `false` at its conclusion. This variable is only used within this internal function and is not checked anywhere else in the contract to prevent re-entry or concurrent calls. Since `_loadLiquidity` is called only by `loadLiquidity` (which is `onlyOwner`), and `loadLiquidity` is not `nonReentrant`, this variable does not provide any additional security or reentrancy protection. Its current usage appears redundant (7.2 Code Security).
IssueThe `loadingLiquidity` boolean state variable is set to `true` at the beginning of the `_loadLiquidity` function and `false` at its conclusion. This variable is only used within this internal function and is not checked anywhere else in the contract to prevent re-entry or concurrent calls. Since `_loadLiquidity` is called only by `loadLiquidity` (which is `onlyOwner`), and `loadLiquidity` is not `nonReentrant`, this variable does not provide any additional security or reentrancy protection. Its current usage appears redundant (7.2 Code Security).
FixRemove the `loadingLiquidity` state variable as it does not serve a functional security purpose. If its intent was to prevent re-entry, the `nonReentrant` modifier should be applied to `loadLiquidity` if concurrent calls are a concern, though `onlyOwner` already limits this significantly. If it's for internal state tracking, consider if it's truly necessary or if local variables suffice.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract utilizes robust Solady libraries for secure operations (7.2 Code Security) and implements reentrancy guards for critical functions (7.2 Code Security). It interacts with established external protocols like Uniswap V4 and CryptoPunks (7.6 External). However, the `buyPunkAndRelist` function updates `currentFees` after multiple external calls, posing a reentrancy risk despite the `nonReentrant` guard (7.2 Code Security). The `_buyAndBurnTokens` function lacks slippage protection, making it vulnerable to sandwich attacks during Uniswap V4 swaps (7.2 Code Security). Furthermore, the Uniswap V4 hook address, configurable by the owner, introduces a significant trust assumption and potential for exploitation through callbacks (7.6 External).

GovernanceHigh1/10

The contract's economic model involves accumulating fees, buying CryptoPunks, re-listing them, and burning its own ERC20 tokens. The owner has extensive control over critical parameters and funds (7.3 Access Control, 7.4 Economic). Specifically, the owner can drain all ETH from the contract via `transferEther` (7.3 Access Control). The `hookAddress` also has the ability to add fees and receives Uniswap V4 callbacks, creating a high dependency on its integrity (7.4 Economic). The fixed `reward` and `priceMultiplier` parameters may not adapt well to market fluctuations, potentially impacting profitability or operational efficiency (7.4 Economic).

UpgradesMedium4/10

The PunkStrategy contract is not designed with an upgradeability pattern (7.7 Upgrades). It is deployed as a standard, non-upgradeable contract. This means that once deployed, its logic cannot be modified or updated without a complete redeployment and migration of assets, which would be a complex and costly process. This design choice eliminates upgrade-related risks but also removes the flexibility to fix bugs or introduce new features post-deployment.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

40.1% in top 10
22.9% in wallets17.1% in contracts
Effective Concentration29.8%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$2.46M across 8 pairs
Uniswap v4ETHanalysed$1.33M54.1%Uniswap v4ETH$630.0K25.7%Uniswap v4ETH$344.1K14.0%Uniswap v4USDC$117.5K4.8%Uniswap v3PROS$27.4K1.1%Uniswap v3WETH$7.8K0.3%
Show 2 more pairsShow less
Sushiswap v3PEPE$5720.0%Uniswap v4uPEG$4770.0%

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xa679…d81c
Unlocked LP Held By
0xc506…3edf

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

9 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 20% (40.1% total → 29.8% effective; 22.9% in EOAs, 17.1% in contracts — mild)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • LP top1 unlocked holder = 100.0% (exit-liquidity risk, pool = 54% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (exit-liquidity risk, pool = 54% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Related Audits

6 more on the record
usocksCritical RiskCaldera (ERA)Critical RisktapCritical RiskBluzelle Token (BLZ)Critical RiskAllora (ALLO)Critical RiskVision (VSN)Critical Risk

Would You Like a More Detailed Audit of PunkStrategy?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit