Quantum Audit Logo

Is Programmable a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

Programmable V4
0x7987…24ee
Ethereum Not verifiedLast checked 3d ago 1 audit on record New Launch · 6d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The UERC20 contract is an ERC-20 token designed for factory-based deployment. It leverages Solady's ERC20 implementation for efficiency and includes custom metadata functionality. The primary security concern identified is the critical dependency on `msg.sender` (expected to be a factory) for all initialization parameters, which could lead to a malformed token if deployed incorrectly or by a malicious entity. Additionally, the contract lacks internal validation for critical constructor parameters, relying solely on the factory. The contract is not upgradeable, which simplifies its security profile regarding upgrades.

1 High1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (6d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$9.0K
Liquidity
$48.4K
Price
$0.00009508
Token Age
6d
Top 10 Holders
50.5%

Security Findings

1 High1 Low1 Info
High

Critical Dependency on `msg.sender` for Initialization

H-01The `UERC20` constructor critically relies on `msg.sender` to be the `IUERC20Factory` and to correctly provide all initialization parameters via `getParameters()`. If the `UERC20` contract is deployed directly by an address other than the intended factory, or by a malicious contract mimicking the factory interface, the token could be initialized with arbitrary or incorrect properties (e.g., wrong name, symbol, decimals, or even minting to an unintended recipient). This design pattern places a high degree of trust in the caller during deployment (7.3 Access Control, 7.2 Code Security).
IssueThe `UERC20` constructor critically relies on `msg.sender` to be the `IUERC20Factory` and to correctly provide all initialization parameters via `getParameters()`. If the `UERC20` contract is deployed directly by an address other than the intended factory, or by a malicious contract mimicking the factory interface, the token could be initialized with arbitrary or incorrect properties (e.g., wrong name, symbol, decimals, or even minting to an unintended recipient). This design pattern places a high degree of trust in the caller during deployment (7.3 Access Control, 7.2 Code Security).
FixThe factory contract should be designed to ensure that `UERC20` tokens are only deployed through its `createToken` function, potentially using `create2` with a salt derived from the parameters to prevent front-running and ensure deterministic addresses. The factory must perform comprehensive validation of all parameters before passing them to the token constructor. Consider adding a mechanism (e.g., an `onlyFactory` modifier if direct deployment is to be prevented, though this is complex for co…
StatusUnresolved
Low

Lack of Internal Parameter Validation in Constructor

L-01The `UERC20` constructor directly uses parameters obtained from `IUERC20Factory(msg.sender).getParameters()` without performing any internal validation. For instance, it does not check if `params.totalSupply` is greater than zero or if `params.recipient` is not the zero address before calling `_mint`. While the `ITokenFactory` interface defines errors for these conditions, relying solely on the factory's validation introduces a single point of failure. If a factory were to provide invalid parameters, the `_mint` call might revert, or the token could be created in an unusable state (7.2 Code Security).
IssueThe `UERC20` constructor directly uses parameters obtained from `IUERC20Factory(msg.sender).getParameters()` without performing any internal validation. For instance, it does not check if `params.totalSupply` is greater than zero or if `params.recipient` is not the zero address before calling `_mint`. While the `ITokenFactory` interface defines errors for these conditions, relying solely on the factory's validation introduces a single point of failure. If a factory were to provide invalid parameters, the `_mint` call might revert, or the token could be created in an unusable state (7.2 Code Security).
FixImplement basic defensive validation checks within the `UERC20` constructor for critical parameters. For example, ensure `params.totalSupply > 0` and `params.recipient != address(0)` before proceeding with the `_mint` operation. This adds a layer of robustness, preventing the creation of malformed tokens even if the factory provides invalid inputs.
StatusUnresolved
Info

`tokenURI()` Function for Fungible Token

I-01The `UERC20` contract implements a `tokenURI()` function, which is typically associated with ERC-721 (NFT) tokens to provide a URI pointing to off-chain metadata. While technically permissible, its inclusion in a fungible ERC-20 token is unusual and not part of the standard ERC-20 specification. This might lead to confusion or unexpected behavior for systems and wallets that primarily interact with ERC-20 tokens and do not anticipate this extension (7.1 Architecture).
IssueThe `UERC20` contract implements a `tokenURI()` function, which is typically associated with ERC-721 (NFT) tokens to provide a URI pointing to off-chain metadata. While technically permissible, its inclusion in a fungible ERC-20 token is unusual and not part of the standard ERC-20 specification. This might lead to confusion or unexpected behavior for systems and wallets that primarily interact with ERC-20 tokens and do not anticipate this extension (7.1 Architecture).
FixClearly document the purpose and intended use of the `tokenURI()` function for this fungible token. Ensure that any off-chain systems or front-ends interacting with this token are aware of this non-standard extension and how to interpret the returned metadata. If not strictly necessary, consider removing it to maintain strict ERC-20 compliance.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good architectural practices by inheriting from Solady's optimized ERC20 implementation and OpenZeppelin interfaces (7.1 Architecture, 7.2 Code Security). Core token parameters are immutable, enhancing security against unauthorized modifications. However, a significant technical risk lies in the constructor's reliance on `msg.sender` for all initialization parameters without internal validation (7.3 Access Control, 7.2 Code Security). This design choice makes the token highly dependent on the security and correctness of the deploying factory, potentially leading to a malformed token if the factory is compromised or bypassed.

GovernanceHigh1/10

The UERC20 contract is a basic ERC-20 token and does not implement any complex governance mechanisms or economic models (7.5 Governance, 7.4 Economic). Its functionality is limited to standard token operations (minting, transfers, approvals). Therefore, the direct governance and economic risks associated with this specific contract are minimal, as it does not control significant funds or decision-making processes beyond its token supply.

UpgradesMedium6/10

The UERC20 contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). There are no proxy patterns (e.g., UUPS, Transparent) or other upgradeability mechanisms present. This design choice eliminates risks associated with upgradeability, such as proxy misconfigurations, logic contract vulnerabilities during upgrades, or unauthorized upgrade paths.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

50.5% in top 10
10.7% in wallets39.8% in contracts
Effective Concentration26.6%

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

$147.4K across 30 pairs
Uniswap v4USDCanalysed$48.4K32.8%Uniswap v4ETH$30.8K20.9%Uniswap v4USDC$30.4K20.6%Uniswap v4ETH$16.8K11.4%Uniswap v4ETH$8.0K5.4%Uniswap v4USDT$4.3K2.9%
Show 4 more pairsShow less
Uniswap v4USDT$4.1K2.8%Uniswap v4USDT$1.1K0.7%Uniswap v4USDC$9340.6%Uniswap v4USDT$6560.4%

The 20 remaining pairs hold $1.9K between them and are not listed.

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 Holder99.5%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0x2bb3…249e
Unlocked LP Held By
0xe68d…c5660x923a…52a40x1beb…c01a

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

8 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (50.5% total → 26.6% effective; 10.7% in EOAs, 39.8% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.5% (independent LP — depth risk, pool = 33% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 33% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 1 High 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
Octra (OCT)Medium RiskZigCoin (ZIG)Medium RiskChainlink (LINK)Medium RiskKiteMedium RiskRaveDAO (RAVE)Medium RiskLO0PMedium Risk

Would You Like a More Detailed Audit of Programmable?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit