Quantum Audit Logo
Launch App

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

Is PunkStrategy Safe?

PNKSTREthereum
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades4/10Checks passed5 of 7Findings1 Critical · 2 High · 2 Medium · 2 Low7
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.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Top-10 concentration > 20%
  • Liquidity not locked
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
17.1%Contracts22.9%Wallets59.9%Everyone else
17.1%Contracts22.9%Wallets59.9%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
40.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking17.1%
  • Walletsanonymous holders, free to sell22.9%
  • Everyone elsethe rest of the supply59.9%
Effective concentrationwhat the score reads29.8%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$2.46M across 8 pairs
Show 2 more pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$1.33MShare of depth54.1%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
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.

Security Findings

1 Critical2 High2 Medium2 Low
Critical

Centralized Control and Fund Drain Risk

The 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).C-01

Issue

The 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).

Fix

Implement 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.

Status

Unresolved

High

Reentrancy Pattern in buyPunkAndRelist (State Update After External Calls)

The 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…H-01

Issue

The 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…

Fix

Adhere 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.

Status

Unresolved

High

Uniswap V4 Hook Trust and Potential Exploits

The 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).H-02

Issue

The 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).

Fix

Thoroughly 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.

Status

Unresolved

Medium

Price Manipulation/Sandwich Attack Risk in _buyAndBurnTokens

The _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).M-01

Issue

The _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).

Fix

Implement 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.

Status

Unresolved

Medium

Lack of Slippage Control in _loadLiquidity Initialization

The _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).M-02

Issue

The _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).

Fix

Consider 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.

Status

Unresolved

Low

Fixed reward and priceMultiplier Parameters

The 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).L-01

Issue

The 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).

Fix

Consider 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.

Status

Unresolved

Low

loadingLiquidity State Variable Redundancy

The 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).L-02

Issue

The 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).

Fix

Remove 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical4/10Medium risk

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).

Governance1/10High risk

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).

Upgrades4/10Medium risk

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.

Final RecommendationWhat to do about this score

Prioritize addressing the critical centralization risk by implementing a multi-signature wallet for the owner role or removing the transferEther function if not strictly necessary for protocol operation.

Re-evaluate the sequence of state updates in buyPunkAndRelist to ensure all state changes occur before external calls, even with reentrancy guards in place. Implement robust slippage control for all Uniswap V4 swap operations to protect against MEV and ensure favorable trade execution. Carefully vet and secure the Uniswap V4 hook contract, considering its significant privileges and callback capabilities.

Contract & Record

1 audit on record
TypeStaking, Router, Token
NetworkEthereum
Token age12mo
Contract0xc506…3edf
Deployer0xa679…d81c
Badge for your website
PunkStrategy security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202692Critical
  2. Sep 2, 202693Critical

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the PNKSTR contract address?

The PunkStrategy (PNKSTR) contract on Ethereum is 0xc50673edb3a7b94e8cad8a7d4e0cd68864e33edf. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is PunkStrategy a scam?

Quantum Audit's risk score for PunkStrategy is 92/100 (Critical risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is PNKSTR liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $2.46M.

Who holds PNKSTR?

As of Sep 4, 2026, the 10 largest holders own 40.1% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
usocksEthereum91CriticalArcBlockABT · Ethereum91CriticalCalderaERA · Ethereum90CriticaltapEthereum94CriticalBluzelle TokenBLZ · Ethereum90CriticalAlloraALLO · Ethereum89Critical

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 Is this your token? Publish your own audit on this page