Quantum Audit Logo

Is SKI MASK DOG Safe?

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

SKI MASK DOG SKI
0x768b…0149
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The SKI token contract is an ERC-20 implementation featuring dynamic taxes, anti-whale, and anti-bot mechanisms. The provided information indicates that ownership has been renounced, making the contract immutable. This immutability, combined with the default high tax rates and fixed operational parameters, introduces significant risks, including potential honeypot characteristics and a lack of adaptability. Users should exercise extreme caution.

1 Critical2 High2 Medium1 Informational
Volume 24h
$70.5K
Liquidity
$663.5K
Price
$0.003934
Token Age
2y
Top 10 Holders
16.8%

Security Findings

1 Crit2 High2 Med1 Info
Critical

Honeypot Risk due to High Fixed Taxes

C-01The contract's ownership has been renounced, making all `onlyOwner` functions inaccessible. This means the initial buy and sell taxes are permanently fixed at 20% (assuming `finaltax` was not set to `true` before renunciation). Such high, immutable taxes make it extremely difficult for users to profit, as a significant portion of their investment is lost on each transaction, creating a strong honeypot characteristic. This directly impacts the economic viability of the token (7.4 Economic).
IssueThe contract's ownership has been renounced, making all `onlyOwner` functions inaccessible. This means the initial buy and sell taxes are permanently fixed at 20% (assuming `finaltax` was not set to `true` before renunciation). Such high, immutable taxes make it extremely difficult for users to profit, as a significant portion of their investment is lost on each transaction, creating a strong honeypot characteristic. This directly impacts the economic viability of the token (7.4 Economic).
FixFor future projects, avoid renouncing ownership with such high, fixed tax rates. If immutability is desired, ensure tax rates are set to a sustainable level (e.g., 0-5%) before renunciation. For this deployed contract, users should be made aware of the permanent high tax rates.
StatusUnresolved
High

Immutability of Critical Operational Parameters

H-01With renounced ownership, critical operational parameters such as `_maxTxAmount`, `_maxWalletSize`, `_taxSwapThreshold`, `_maxTaxSwap`, `transferDelayEnabled`, and `_preventSwapBefore` are permanently fixed at their initial values. This removes any flexibility to adapt to changing market conditions, address unforeseen issues, or optimize tokenomics post-deployment. For example, if `_maxTxAmount` is too restrictive, it could hinder large legitimate trades (7.8 Operations, 7.5 Governance).
IssueWith renounced ownership, critical operational parameters such as `_maxTxAmount`, `_maxWalletSize`, `_taxSwapThreshold`, `_maxTaxSwap`, `transferDelayEnabled`, and `_preventSwapBefore` are permanently fixed at their initial values. This removes any flexibility to adapt to changing market conditions, address unforeseen issues, or optimize tokenomics post-deployment. For example, if `_maxTxAmount` is too restrictive, it could hinder large legitimate trades (7.8 Operations, 7.5 Governance).
FixBefore renouncing ownership, ensure all critical parameters are thoroughly tested and set to optimal, sustainable values. Consider if complete immutability is truly necessary for a token with complex dynamic features, or if a multi-sig or timelock governance could manage critical parameters.
StatusUnresolved
High

Potential for Untradable Token Post-Renunciation

H-02If the `openTrading()` function (which creates the Uniswap pair and adds initial liquidity) and `setSwapEnabled(true)` were not called by the owner *before* ownership was renounced, the token would be permanently untradable. Users would be able to buy tokens (if a pair was manually created elsewhere) but would be unable to sell them through the intended Uniswap integration, and collected taxes would not be swapped to ETH, making the token a hard honeypot (7.8 Operations, 7.4 Economic).
IssueIf the `openTrading()` function (which creates the Uniswap pair and adds initial liquidity) and `setSwapEnabled(true)` were not called by the owner *before* ownership was renounced, the token would be permanently untradable. Users would be able to buy tokens (if a pair was manually created elsewhere) but would be unable to sell them through the intended Uniswap integration, and collected taxes would not be swapped to ETH, making the token a hard honeypot (7.8 Operations, 7.4 Economic).
FixVerify the deployment sequence to confirm that `openTrading()` and `setSwapEnabled(true)` were successfully executed before ownership renunciation. For future deployments, ensure a robust checklist for pre-renunciation setup.
StatusUnresolved
Medium

`tx.origin` Usage for Transfer Delay

M-01The `_holderLastTransferTimestamp` mapping uses `tx.origin` to enforce a transfer delay (one purchase per block). While intended for anti-bot measures, relying on `tx.origin` can be problematic. If a user interacts with the contract through another contract that forwards `tx.origin`, it might lead to unexpected behavior or potential bypasses of the delay mechanism, as `tx.origin` always refers to the original external account (EOA) that initiated the transaction (7.2 Code Security).
IssueThe `_holderLastTransferTimestamp` mapping uses `tx.origin` to enforce a transfer delay (one purchase per block). While intended for anti-bot measures, relying on `tx.origin` can be problematic. If a user interacts with the contract through another contract that forwards `tx.origin`, it might lead to unexpected behavior or potential bypasses of the delay mechanism, as `tx.origin` always refers to the original external account (EOA) that initiated the transaction (7.2 Code Security).
FixConsider using `msg.sender` instead of `tx.origin` for tracking user-specific delays, as `msg.sender` reliably identifies the immediate caller, whether it's an EOA or a contract. This provides a more robust and secure approach to access control and user tracking.
StatusUnresolved
Medium

Lack of Emergency Stop/Pause Functionality

M-02With renounced ownership, there is no longer an owner or any other entity capable of pausing transfers or stopping trading in the event of a critical vulnerability, market exploit, or unforeseen operational issue. This lack of an emergency stop mechanism leaves the contract vulnerable to cascading failures without any recourse (7.8 Operations, 7.5 Governance).
IssueWith renounced ownership, there is no longer an owner or any other entity capable of pausing transfers or stopping trading in the event of a critical vulnerability, market exploit, or unforeseen operational issue. This lack of an emergency stop mechanism leaves the contract vulnerable to cascading failures without any recourse (7.8 Operations, 7.5 Governance).
FixFor future projects, if renouncing ownership, consider implementing a decentralized emergency pause mechanism (e.g., via a timelock or community governance) or carefully weigh the risks of complete immutability against the need for emergency intervention capabilities.
StatusUnresolved
Info

Centralized `_taxWallet`

I-01The `_taxWallet` is set to the deployer's address in the constructor and, due to renounced ownership, cannot be changed. All collected ETH from tax swaps is sent to this single, unchangeable address. This centralizes the control of collected funds to one entity without any multi-signature or timelock protection (7.4 Economic).
IssueThe `_taxWallet` is set to the deployer's address in the constructor and, due to renounced ownership, cannot be changed. All collected ETH from tax swaps is sent to this single, unchangeable address. This centralizes the control of collected funds to one entity without any multi-signature or timelock protection (7.4 Economic).
FixFor future projects, consider using a multi-signature wallet or a timelock contract for the `_taxWallet` to enhance security and decentralization of collected funds, even if ownership is renounced.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes `SafeMath` for arithmetic operations, mitigating common integer overflow/underflow vulnerabilities (7.2 Code Security). A `lockTheSwap` modifier is implemented to prevent reentrancy during token swaps (7.2 Code Security). However, the use of `tx.origin` for transfer delay tracking is a minor concern (7.2 Code Security). The contract's architecture is a standard ERC-20 with Uniswap V2 integration (7.1 Architecture), but the immutability due to renounced ownership introduces significant technical inflexibility (7.8 Operations).

GovernanceLow7/10

The primary economic risk stems from the renounced ownership, which fixes the initial buy/sell taxes at 20% (7.4 Economic). This high, immutable tax rate creates a significant honeypot risk, as users may be unable to sell profitably. Critical parameters like `_maxTxAmount`, `_maxWalletSize`, and `swapEnabled` are also fixed, removing any ability to adjust to market conditions or correct issues (7.5 Governance). The `_taxWallet` is a single, unchangeable address, concentrating collected funds (7.4 Economic).

UpgradesLow9/10

The contract is not designed with upgradeability in mind, as indicated by `is_proxy: false` (7.7 Upgrades). This means there are no upgrade-specific risks such as proxy misconfigurations or logic errors during upgrades. However, the lack of upgradeability also means that any discovered vulnerabilities or necessary parameter adjustments cannot be addressed post-deployment (7.7 Upgrades).

Security Checklist

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

Holder Composition

16.8% in top 10
4.9% in wallets11.9% in contracts
Effective Concentration9.7%

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

$677.4K across 11 pairs
Uniswap v2WETHanalysed$663.5K97.9%Uniswap v3WETH$6.7K1.0%AerodromeWETH$6.3K0.9%Uniswap v4BUZ$4690.1%Uniswap v4ETH$2620.0%Uniswap v3USDC$900.0%
Show 4 more pairsShow less
Uniswap v4USDC$450.0%PancakeswapUSDC$170.0%Uniswap v4VIRTUAL$100.0%SushiswapWETH$10.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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

5 addresses
Deployer
0x8087…55df
Unlocked LP Held By
0xe507…25be0xb3ac…68a00x4985…2b2b0x5f79…8d49

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

3 factors
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium 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
BasecatLow RiskClawBankLow RiskSPARKLow RiskRUSSELLLow RiskOpenVPP (OVPP)Low RiskBase Juice (BASEJUICE)Low Risk

Would You Like a More Detailed Audit of SKI MASK DOG?

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

Get Detailed Audit