Quantum Audit Logo
Launch App

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

Is SKI MASK DOG Safe?

SKIBase
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
SummaryAI Copilot

The SKI token contract is an ERC-20 implementation featuring dynamic taxes, anti-whale, and anti-bot mechanisms.

Read the full analysis
What raised the score
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 2 Medium finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 47 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
11.9%Contracts4.9%83.2%Everyone else
11.9%Contracts4.9%83.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
16.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking11.9%
  • Walletsanonymous holders, free to sell4.9%
  • Everyone elsethe rest of the supply83.2%
Effective concentrationwhat the score reads9.7%
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$677.4K across 11 pairs
LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$663.5KShare of depth97.9%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
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.

Security Findings

1 Critical2 High2 Medium1 Info
Critical

Honeypot Risk due to High Fixed Taxes

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

Issue

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

Fix

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

Status

Unresolved

High

Immutability of Critical Operational Parameters

With 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).H-01

Issue

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

Fix

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

Status

Unresolved

High

Potential for Untradable Token Post-Renunciation

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

Issue

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

Fix

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

Status

Unresolved

Medium

tx.origin Usage for Transfer Delay

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

Issue

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

Fix

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

Status

Unresolved

Medium

Lack of Emergency Stop/Pause Functionality

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

Issue

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

Fix

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

Status

Unresolved

Info

Centralized _taxWallet

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical6/10Medium risk

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

Governance7/10Low risk

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

Upgrades9/10Low risk

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

Final RecommendationWhat to do about this score

It is strongly recommended to thoroughly review the deployment state of the contract, specifically verifying if openTrading() and setSwapEnabled(true) were called *before* ownership was renounced.

Given the high, fixed tax rates, potential investors should exercise extreme caution and understand the implications of these immutable parameters. For future projects, consider a phased approach to renouncing ownership, ensuring all critical operational parameters are correctly configured and tested, and potentially implementing a lower, more sustainable tax structure.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkBase
Token age2y
Contract0x768b…0149
Deployer0x8087…55df
Badge for your website
SKI MASK DOG 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. Aug 30, 202613Low

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

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