Quantum Audit Logo
Launch App

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

Is Upstarty Safe?

UPYBNB Chain
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
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades6/10Checks passed4 of 5Findings1 High · 1 Medium · 2 Info4
SummaryAI Copilot

The Upstarty token contract implements a standard ERC20 token with burnable and pausable functionalities, largely based on OpenZeppelin's secure patterns.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • Top-10 concentration > 30%
  • LP top1 unlocked holder = 54.9%
  • LP top3 unlocked holders = 100.0%
  • LP claimed locked but only 0.0% actually locked
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact factors
  • Ownership NOT renounced — Multisig (2-of-3)
  • Top-10 concentration > 30% (92.2% total → 38.1% effective; 2.1% in EOAs, 90.0% in contracts — moderate)
  • LP top1 unlocked holder = 54.9% (exit-liquidity risk, pool = 91% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (exit-liquidity risk, pool = 91% of DEX liquidity)
  • LP claimed locked but only 0.0% actually locked
  • 1 High finding(s) from audit
  • 1 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 44 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
90.0%Contracts2.1%7.8%
90.0%Contracts7.8%
ContractsWalletsEveryone elseBubble area = share of supply
92.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking90.0%
  • Walletsanonymous holders, free to sell2.1%
  • Everyone elsethe rest of the supply7.8%
Effective concentrationwhat the score reads38.1%
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$159.6K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$145.4KShare of depth91.1%
Top-1 Unlocked Holder54.9%
Top-3 Unlocked100.0%
Unlocked LP held by
0xab50…f7b00x7ffc…85050x0ed9…9706

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

Security Findings

1 High1 Medium2 Info
High

Missing Access Control for Pausable Functions

The Pausable abstract contract defines _pause() and _unpause() as internal virtual functions without any inherent access control. While this design allows inheriting contracts to implement their own access control, it creates a high-risk vulnerability if the inheriting contract exposes these functions publicly (e.g., via a pause() or unpause() external function) without proper authorization checks. An attacker could then halt all token transfers, severely impacting the token's utility and user trust. This is a critical design consideration for any contract inheriting Pausable (7.3 Access Control).H-01

Issue

The Pausable abstract contract defines _pause() and _unpause() as internal virtual functions without any inherent access control. While this design allows inheriting contracts to implement their own access control, it creates a high-risk vulnerability if the inheriting contract exposes these functions publicly (e.g., via a pause() or unpause() external function) without proper authorization checks. An attacker could then halt all token transfers, severely impacting the token's utility and user trust. This is a critical design consideration for any contract inheriting Pausable (7.3 Access Control).

Fix

The inheriting contract (e.g., 'Upstarty') must implement robust access control for any public or external functions that call _pause() and _unpause(). It is highly recommended to use a battle-tested access control mechanism such as OpenZeppelin's Ownable or AccessControl to restrict these functions to authorized addresses only.

Status

Unresolved

Medium

Centralization Risk of Pausable Functionality

The Pausable contract allows for the complete halting of all token transfers and related operations. While this feature can be valuable for emergency situations (e.g., mitigating a severe vulnerability), it introduces a significant centralization risk. The entity or address that controls the _pause() and _unpause() functions holds considerable power over the token's functionality, potentially leading to censorship, manipulation, or single point of failure (7.4 Economic, 7.5 Governance).M-01

Issue

The Pausable contract allows for the complete halting of all token transfers and related operations. While this feature can be valuable for emergency situations (e.g., mitigating a severe vulnerability), it introduces a significant centralization risk. The entity or address that controls the _pause() and _unpause() functions holds considerable power over the token's functionality, potentially leading to censorship, manipulation, or single point of failure (7.4 Economic, 7.5 Governance).

Fix

Carefully consider the implications of centralized control over the Pausable functionality. If the project aims for decentralization, explore options such as multi-signature wallets for controlling the pause mechanism, or integrate it into a broader governance system where decisions are made by token holders or a decentralized autonomous organization (DAO). Clearly document the conditions under which pausing may occur and the process for unpausing.

Status

Unresolved

Info

Safe Use of Unchecked Arithmetic

The contract utilizes unchecked blocks for arithmetic operations within the _update function, specifically for _balances[from] = fromBalance - value;, _balances[to] += value;, and _totalSupply -= value;. In Solidity 0.8.x, arithmetic operations revert on overflow/underflow by default. The use of unchecked here is safe and gas-efficient because preceding logic (e.g., if (fromBalance < value)) ensures that underflow will not occur for subtractions, and additions are generally safe within uint256 limits for typical token values (7.2 Code Security).I-01

Issue

The contract utilizes unchecked blocks for arithmetic operations within the _update function, specifically for _balances[from] = fromBalance - value;, _balances[to] += value;, and _totalSupply -= value;. In Solidity 0.8.x, arithmetic operations revert on overflow/underflow by default. The use of unchecked here is safe and gas-efficient because preceding logic (e.g., if (fromBalance < value)) ensures that underflow will not occur for subtractions, and additions are generally safe within uint256 limits for typical token values (7.2 Code Security).

Fix

No action required. The use of unchecked blocks is appropriate and correctly implemented in this context, contributing to gas efficiency without compromising security.

Status

Resolved

Info

Abstract Contract Requires Inheritance

The provided code consists of several abstract contracts (Context, ERC20, Pausable, ERC20Burnable, ERC20Pausable). These contracts cannot be deployed directly and are intended to be inherited by a concrete contract (e.g., 'Upstarty'). The final deployed contract will combine the functionalities defined here with any additional logic implemented in the inheriting contract (7.1 Architecture).I-02

Issue

The provided code consists of several abstract contracts (Context, ERC20, Pausable, ERC20Burnable, ERC20Pausable). These contracts cannot be deployed directly and are intended to be inherited by a concrete contract (e.g., 'Upstarty'). The final deployed contract will combine the functionalities defined here with any additional logic implemented in the inheriting contract (7.1 Architecture).

Fix

No direct action is required for the abstract contracts themselves. However, it is crucial to ensure that the inheriting contract correctly implements all necessary functionalities, including proper constructor arguments, access control for critical functions (as noted in H-01), and any specific tokenomics or business logic.

Status

Resolved

Analysis

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

The Upstarty token contract implements a standard ERC20 token with burnable and pausable functionalities, largely based on OpenZeppelin's secure patterns. The code demonstrates good practices such as custom error handling and appropriate use of unchecked arithmetic. However, a significant concern is the lack of explicit access control for the critical _pause() and _unpause() functions within the Pausable abstract contract, which must be carefully addressed by the inheriting contract to prevent unauthorized control over token transfers. The centralized nature of the pausing mechanism also introduces a governance and economic risk.

Technical6/10Medium risk

The contract implements a standard ERC20 token with burnable and pausable features, largely following OpenZeppelin patterns. It utilizes custom error types for improved clarity and gas efficiency. Arithmetic operations are protected against overflow/underflow by Solidity 0.8.x's default checks, with unchecked blocks used appropriately where safety is guaranteed (e.g., after explicit balance checks in _update). A significant technical risk is the lack of explicit access control for the _pause() and _unpause() functions within the Pausable abstract contract, requiring careful implementation by inheriting contracts (7.3 Access Control).

Governance1/10High risk

The Pausable functionality provides an emergency stop mechanism, which can be beneficial for mitigating certain attack vectors or operational issues (7.8 Operations). However, this introduces a centralization risk, as the entity controlling the pause functionality holds significant power over token transfers (7.4 Economic). The economic model of the token itself is not defined in this abstract contract, but the ability to halt all transfers represents a considerable governance control point (7.5 Governance).

Upgrades6/10Medium risk

The provided code does not include any proxy or upgradeability patterns (7.7 Upgrades). It is a standard, non-upgradeable contract implementation. Therefore, there are no inherent upgrade safety risks within this specific codebase. Any future desire for upgradeability would require a complete re-architecture using a proxy pattern, which would introduce its own set of upgrade-related considerations and risks.

Final RecommendationWhat to do about this score

It is crucial to implement robust access control for the _pause() and _unpause() functions in the inheriting contract to prevent unauthorized pausing or unpausing of token transfers.

Consider using a well-tested access control mechanism like OpenZeppelin's Ownable or AccessControl for these critical functions. Additionally, carefully evaluate the implications of the centralized Pausable control on the token's economic and governance model, and consider decentralizing this control through a multi-signature wallet or a governance mechanism if appropriate for the project's risk profile.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age1y
Contract0xb849…3466
Deployer0x5e0a…1c9c
Badge for your website
Upstarty 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 11, 202666High

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

Frequently Asked Questions

What is the UPY contract address?

The Upstarty (UPY) contract on BNB Chain is 0xb849c4d843769d42812fb600b1bcc8a6ba843466. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Upstarty a scam?

Quantum Audit's risk score for Upstarty is 66/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is UPY liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $159.6K.

Who holds UPY?

As of Sep 4, 2026, the 10 largest holders own 92.2% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
XPULSBNB Chain66HighHana TokenHANA · BNB Chain66HighOrizonORI · BNB Chain66High牛来NIULAI · BNB Chain66HighRandyBNB Chain66HighShopinX TokenSPX · BNB Chain66High

Would You Like a More Detailed Audit of Upstarty?

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