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.
On-chain security analysis — is it a scam or legit?
Is SKI MASK DOG Safe?
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 →The SKI token contract is an ERC-20 implementation featuring dynamic taxes, anti-whale, and anti-bot mechanisms.
Read the full analysis- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking11.9%
- Walletsanonymous holders, free to sell4.9%
- Everyone elsethe rest of the supply83.2%
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- 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 pairs
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0xe507…25be0xb3ac…68a00x4985…2b2b0x5f79…8d49No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
CriticalHoneypot 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
HighImmutability 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
HighPotential 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
Mediumtx.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
tx.origin Usage for Transfer DelayIssue
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
MediumLack 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
InfoCentralized _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
_taxWalletIssue
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 4The 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).
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).
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).
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- 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