Quantum Audit Logo

Is Unity Software Safe?

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

Is this your token? Publish your own audit on this page →

Unity Software UNITY
0xfd0b…b2d9
Ethereum Not verifiedLast checked today 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

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.

1 Critical1 High2 Medium1 Low1 Informational
Volume 24h
$82.4K
Liquidity
$67.3K
Price
$0.0000000004
Token Age
1y
Top 10 Holders
25.7%

Security Findings

1 Crit1 High2 Med1 Low1 Info
Critical

Critical Design Flaw: Token Supply Inaccessible

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.
IssueThe 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.
FixModify 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.
StatusUnresolved
High

Centralized Control and Potential 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.
IssueThe 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.
FixImplement 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.
StatusUnresolved
Medium

Anti-Bot/Anti-Whale Measures May Hinder Legitimate Trading

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.
IssueThe 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.
FixCarefully 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.
StatusUnresolved
Medium

Misleading Transfer Event in Constructor

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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved
Low

Lack of Emergency Pause/Withdrawal Functionality

L-01The 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.
IssueThe 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.
FixConsider 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.
StatusUnresolved
Info

High Initial Transaction Taxes

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.
IssueThe 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.
FixEvaluate 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.
StatusUnresolved

Category Ratings

TechnicalLow7/10

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

GovernanceLow8/10

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

UpgradesLow9/10

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.

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

25.7% in top 10
14.4% in wallets11.2% in contracts
Effective Concentration18.9%

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

$67.3K

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

1 addresses
Deployer
0x502b…73a9

What Raised This Score

4 factors
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 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

Related Audits

6 more on the record
4CHANLow RiskMOO DENG (MOODENG)Low RiskHEXLow RiskWrapped liquid staked Ether 2.0 (WSTETH)Low RiskManyuLow RiskRektLow Risk

Would You Like a More Detailed Audit of Unity Software?

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

Get Detailed Audit