Is Upstarty (UPY) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med2 Info

High

Missing Access Control for Pausable Functions

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

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

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

StatusUnresolved

Medium

Centralization Risk of Pausable Functionality

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

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

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

StatusUnresolved

Info

Safe Use of Unchecked Arithmetic

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

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

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

StatusResolved

Info

Abstract Contract Requires Inheritance

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

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

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

StatusResolved

Category Ratings

TechnicalMedium6/10

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

GovernanceHigh1/10

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

UpgradesMedium6/10

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.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

92.2% in top 10

2.1% in wallets90.0% in contracts

Effective Concentration38.1%

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

$159.6K across 2 pairs

Pancakeswap v2USDTanalysed$145.4K Pancakeswap v2USDC$14.2K

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

Top-1 Unlocked Holder54.9%

Top-3 Unlocked100.0%

Key Addresses

4 addresses

Deployer

0x5e0a…1c9c

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.

What Raised This Score

7 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

Final Recommendation

AI Copilot

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

Read the verdictHide

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

TypeToken

Audit History

1 audit on record

Aug 1166

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

Is Upstarty Safe?