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

Is Programmable a Scam?

Ethereum

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 recordNew Launch · 6d old

Chart

38/ 100

Medium RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical8/10 Governance1/10 Upgrades6/10 Checks passed3 of 5 Findings1 High · 1 Low · 1 Info3

SummaryAI Copilot

The UERC20 contract is an ERC-20 token designed for factory-based deployment.

Read the full analysis

What raised the score

Ownership status UNKNOWN
Top-10 concentration > 20%
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 99.5%
LP top3 unlocked holders = 100.0%
Token age < 7 days
1 High finding(s) from audit
1 Low finding(s) from audit

Exact 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

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.

Security Checklist

as of audit · Sep 43 of 5 checks passed

Contract verifiedVerified

OwnershipUnknown

MintNo mint

Liquidity lockNot locked

UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

50.5%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking39.8%
Walletsanonymous holders, free to sell10.7%
Everyone elsethe rest of the supply49.5%

Effective concentrationwhat the score reads26.6%

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$147.4K across 30 pairs

Show 4 more pairs

The 20 remaining pairs hold $1.9K between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$48.4KShare of depth32.8%

Top-1 Unlocked Holder99.5%

Top-3 Unlocked100.0%

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.

Security Findings

1 High1 Low1 Info

High

Critical Dependency on `msg.sender` for Initialization

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

Issue

Fix

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

Status

Unresolved

Low

Lack of Internal Parameter Validation in Constructor

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

Issue

Fix

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

Status

Unresolved

Info

`tokenURI()` Function for Fungible Token

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

Issue

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

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.

Technical8/10Low risk

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.

Governance1/10High risk

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.

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

It is crucial to ensure that the factory contract responsible for deploying UERC20 tokens rigorously validates all parameters before token creation and strictly controls the deployment process.

Consider adding defensive checks within the UERC20 constructor for critical parameters to enhance robustness. Thoroughly document the intended use of the tokenURI() function for this fungible token to prevent misunderstandings.

Contract & Record

1 audit on record

TypeToken

NetworkEthereum

Token age6d

Contract0x7987…24ee

Deployer0x2bb3…249e

Badge for your website

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

Sep 4, 202638Medium
Aug 3, 202632Low

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

Frequently Asked Questions

What is the V4 contract address?

The Programmable (V4) contract on Ethereum is 0x7987f03462200b3d8a072e02c89a8a41dcb124ee. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.