On-chain security analysis — is it a scam or legit?
EthereumThe UNITY token contract implements an ERC-20 standard with a deflationary tax mechanism and anti-whale features.
Read the full analysisEach 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
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 6, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
_tTotal) is minted to the contract address (_balances[address(this)] = _tTotal;) in the constructor. This means the deployer (owner()) receives 0 tokens, making it impossible to add initial liquidity to Uniswap or distribute tokens to other addresses. The token is effectively unlaunchable and unusable as designed, as no one can acquire or transfer the tokens.C-01The entire token supply (_tTotal) is minted to the contract address (_balances[address(this)] = _tTotal;) in the constructor. This means the deployer (owner()) receives 0 tokens, making it impossible to add initial liquidity to Uniswap or distribute tokens to other addresses. The token is effectively unlaunchable and unusable as designed, as no one can acquire or transfer the tokens.
Modify the constructor to mint the total supply to the deployer's address (_balances[_msgSender()] = _tTotal;) or to a designated liquidity pool address, allowing for proper token distribution and initial liquidity provision.
Unresolved
Ownable pattern, granting the deployer (owner) extensive control over critical parameters such as tax rates (_initialBuyTax, _initialSellTax, _finalBuyTax, _finalSellTax), transaction limits (_maxTxAmount), wallet size limits (_maxWalletSize), and swap enablement (swapEnabled). While setter functions are not fully shown, the dynamic nature of these variables implies their existence. A malicious owner could exploit this by, for example, setting sell taxes to 100% after launch, effectively creating a honeypot.H-01The contract uses the Ownable pattern, granting the deployer (owner) extensive control over critical parameters such as tax rates (_initialBuyTax, _initialSellTax, _finalBuyTax, _finalSellTax), transaction limits (_maxTxAmount), wallet size limits (_maxWalletSize), and swap enablement (swapEnabled). While setter functions are not fully shown, the dynamic nature of these variables implies their existence. A malicious owner could exploit this by, for example, setting sell taxes to 100% after launch, effectively creating a honeypot.
Implement multi-signature governance for critical parameter changes or introduce time-locks for sensitive operations to provide a window for community review and prevent immediate malicious actions. Consider decentralizing control over time.
Unresolved
_maxTxAmount, _maxWalletSize, and a sellCount limit (maximum 3 sells per block). While intended to prevent bot manipulation and large whale dumps, these restrictions can significantly hinder legitimate trading activity, especially for larger investors or during periods of high market volatility, potentially leading to user frustration and reduced trading volume.M-01The contract implements _maxTxAmount, _maxWalletSize, and a sellCount limit (maximum 3 sells per block). While intended to prevent bot manipulation and large whale dumps, these restrictions can significantly hinder legitimate trading activity, especially for larger investors or during periods of high market volatility, potentially leading to user frustration and reduced trading volume.
Carefully review and adjust the values for _maxTxAmount, _maxWalletSize, and sellCount to strike a balance between preventing malicious activity and allowing legitimate trading. Consider dynamic adjustments based on market conditions or a more sophisticated bot detection mechanism.
Unresolved
emit Transfer(address(0), _msgSender(), _tTotal);. This event typically signifies the minting of tokens from the zero address to _msgSender() (the deployer). However, the actual balance update (_balances[address(this)] = _tTotal;) assigns the total supply to the contract itself, not the deployer. This discrepancy can confuse users, block explorers, and analytics tools that rely on events for accurate token distribution tracking.M-02The constructor includes emit Transfer(address(0), _msgSender(), _tTotal);. This event typically signifies the minting of tokens from the zero address to _msgSender() (the deployer). However, the actual balance update (_balances[address(this)] = _tTotal;) assigns the total supply to the contract itself, not the deployer. This discrepancy can confuse users, block explorers, and analytics tools that rely on events for accurate token distribution tracking.
Ensure that emitted events accurately reflect the state changes. If the intention is for the contract to hold the total supply, remove the misleading Transfer event. If the intention is for the deployer to receive the tokens, update the balance accordingly and ensure the event matches.
Unresolved
The contract lacks functions to pause trading in an emergency (e.g., exploit, severe market volatility) or to recover accidentally sent ERC-20 tokens or ETH that are not part of the tax mechanism. This could lead to irrecoverable loss of funds if tokens are sent to the contract address by mistake or if a critical vulnerability requires a temporary halt to operations.
Consider implementing an onlyOwner or multi-sig controlled pause() function for emergency situations. Additionally, add onlyOwner functions to withdraw accidentally sent ERC-20 tokens and ETH from the contract to prevent permanent loss.
Unresolved
_initialBuyTax, _initialSellTax). While the contract includes logic to reduce these taxes over time (_reduceBuyTaxAt, _reduceSellTaxAt), such high initial taxes can deter early adoption, reduce trading volume, and create a perception of an unfavorable trading environment for initial participants.I-01The initial buy and sell taxes are set at 18% (_initialBuyTax, _initialSellTax). While the contract includes logic to reduce these taxes over time (_reduceBuyTaxAt, _reduceSellTaxAt), such high initial taxes can deter early adoption, reduce trading volume, and create a perception of an unfavorable trading environment for initial participants.
Evaluate the impact of high initial taxes on user adoption and trading behavior. Consider starting with lower initial taxes or providing clearer communication on the tax reduction schedule to encourage participation.
Unresolved
The UNITY token contract implements an ERC-20 standard with a deflationary tax mechanism and anti-whale features. A critical design flaw prevents the deployer from accessing the token supply, rendering the token unlaunchable. The contract also exhibits high centralization risk, with the owner controlling critical parameters that could be exploited.
The contract utilizes SafeMath for arithmetic safety and implements standard ERC-20 functions. The lockTheSwap modifier helps prevent reentrancy during automated tax swaps (7.2 Code Security). However, a critical architectural flaw exists where the entire token supply is minted to the contract address, making it inaccessible to the deployer for initial liquidity provision or distribution (7.1 Architecture, 7.2 Code Security). Additionally, a misleading Transfer event in the constructor can cause confusion (7.2 Code Security).
The contract employs an Ownable pattern, granting the deployer significant control over key economic parameters such as tax rates, transaction limits, and wallet size limits (7.3 Access Control, 7.5 Governance). While these features aim to manage tokenomics, they introduce a high centralization risk, potentially allowing for malicious adjustments post-launch (7.4 Economic). The initial 18% buy/sell taxes are high, and anti-bot measures like the '3 sells per block' limit could hinder legitimate trading (7.4 Economic).
The contract is not designed with any upgradeability mechanisms (7.7 Upgrades). This means that once deployed, its logic cannot be modified or updated, which is a strength in terms of immutability but a weakness if critical bugs or necessary feature enhancements are identified post-deployment.
Address the critical design flaw by ensuring the token supply is correctly minted to the deployer or a designated liquidity pool address, enabling proper launch and distribution.
Implement robust access control for sensitive functions, potentially with multi-signature governance or time-locks for critical parameter changes, to mitigate centralization risks. Carefully review and balance anti-bot/anti-whale measures to avoid unduly impacting legitimate users and trading activity. Consider adding emergency pause functionality and mechanisms for recovering accidentally sent tokens to enhance operational resilience.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The Unity Software (UNITY) contract on Ethereum is 0xfd0bb211d479710dfa01d3d98751767f51edb2d9. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Unity Software is 8/100 (Low risk) as of Sep 6, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: 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.
Liquidity lock: Locked (as of Sep 6, 2026). Total DEX liquidity: $67.3K.
As of Sep 6, 2026, the 10 largest holders own 25.7% of the supply. The Holders section on this page shows who they are by holder type.
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
