Quantum Audit Logo
Launch App

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

Is Unipeg Safe?

UPEGEthereum
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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance5/10Upgrades8/10Checks passed4 of 5Findings1 Critical · 1 High · 1 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The Unipeg contract implements an ERC20 token with integrated NFT (Upeg) syncing logic.

Read the full analysis
What raised the score
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 84.2%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 84.2% (independent LP — depth risk, pool = 88% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 88% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 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

Security Checklist

as of audit · Sep 44 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
15.6%Contracts4.0%80.3%Everyone else
15.6%Contracts4.0%80.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
19.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking15.6%
  • Walletsanonymous holders, free to sell4.0%
  • Everyone elsethe rest of the supply80.3%
Effective concentrationwhat the score reads10.3%
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$1.82M across 8 pairs
Show 2 more pairs

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$1.59MShare of depth87.7%
Top-1 Unlocked Holder84.2%
Top-3 Unlocked100.0%
Unlocked LP held by
0xee67…3a670xf9fd…f90f0xc500…6aca0xe0dd…f3df

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

Security Findings

1 Critical1 High1 Medium1 Low1 Info
Critical

Critical Reentrancy/Logic Flaw in Upeg-ERC20 Sync

The Unipeg contract exhibits a critical circular dependency between ERC20 token transfers and Upeg NFT transfers. When an ERC20 transfer occurs, the _afterTokenTransfer hook calls _onTokenTransfer to synchronize Upegs. If _onTokenTransfer determines that Upegs need to be moved (e.g., in a user-to-user transfer), it calls _moveUpegs, which in turn calls _transferUpeg (from the inherited Upeg.sol contract). The _transferUpeg function, as an override, then triggers _afterUpegTransferred in Unipeg.sol. Crucially, _afterUpegTransferred then executes an internal ERC20 transfer via _transfer(from, to, UNIT_PER_UPEG). This creates a reentrant call to the ERC20 transfer mecha…C-01

Issue

The Unipeg contract exhibits a critical circular dependency between ERC20 token transfers and Upeg NFT transfers. When an ERC20 transfer occurs, the _afterTokenTransfer hook calls _onTokenTransfer to synchronize Upegs. If _onTokenTransfer determines that Upegs need to be moved (e.g., in a user-to-user transfer), it calls _moveUpegs, which in turn calls _transferUpeg (from the inherited Upeg.sol contract). The _transferUpeg function, as an override, then triggers _afterUpegTransferred in Unipeg.sol. Crucially, _afterUpegTransferred then executes an internal ERC20 transfer via _transfer(from, to, UNIT_PER_UPEG). This creates a reentrant call to the ERC20 transfer mecha…

Fix

Refactor the Upeg-ERC20 synchronization logic to break the circular dependency. The _afterUpegTransferred and _afterUpegsListTransferred functions should not trigger new ERC20 transfers if the Upeg transfer was initiated by an existing ERC20 transfer. Instead, these hooks should only handle the ERC20 side if the Upeg transfer was initiated independently (e.g., by a direct call to _transferUpeg not originating from _onTokenTransfer). Consider using a reentrancy guard or a flag to prevent…

Status

Unresolved

High

Economic Decoupling of ERC20 and Upeg Balances

The logic in _onTokenTransfer for calculating from_remove_cnount can lead to a permanent decoupling of ERC20 token balances and Upeg NFT counts. The calculation `from_remove_cnount = from_count > from_max_allowed ? from_count - from_max_allowed : 0; means that if an account's actual Upeg count (from_count) is already less than the expected Upeg count derived from its ERC20 balance (balanceOf(from) / UNIT_PER_UPEG`), no Upegs will be removed or burned when ERC20 tokens are transferred out. This allows users to reduce their ERC20 balance without affecting their Upeg count, effectively 'hiding' Upegs or creating a state where the total number of Upegs in circulation is significantly le…H-01

Issue

The logic in _onTokenTransfer for calculating from_remove_cnount can lead to a permanent decoupling of ERC20 token balances and Upeg NFT counts. The calculation `from_remove_cnount = from_count > from_max_allowed ? from_count - from_max_allowed : 0; means that if an account's actual Upeg count (from_count) is already less than the expected Upeg count derived from its ERC20 balance (balanceOf(from) / UNIT_PER_UPEG`), no Upegs will be removed or burned when ERC20 tokens are transferred out. This allows users to reduce their ERC20 balance without affecting their Upeg count, effectively 'hiding' Upegs or creating a state where the total number of Upegs in circulation is significantly le…

Fix

Re-evaluate the synchronization logic to ensure a consistent 1:1 relationship between UNIT_PER_UPEG tokens and one Upeg NFT. Implement a mechanism to actively reconcile discrepancies where OwnerUpegsCount is less than balanceOf / UNIT_PER_UPEG. This might involve burning excess Upegs when tokens are transferred out, or preventing token transfers if they would lead to an invalid Upeg state. The goal should be to prevent a scenario where users can hold ERC20 tokens without the corresponding…

Status

Unresolved

Medium

Centralization Risk with Owner and Hook Control

The contract's owner has significant control over critical system parameters. The owner can set the hook address via setHook(). This hook address is then the only entity authorized to call start(), which sets the crucial pool address and enables the token's core functionality (Upeg minting/burning). A compromised owner account or a malicious owner could set a malicious hook address, which could then set a malicious pool address, leading to potential manipulation of the Upeg minting/burning process, unauthorized token mints, or other forms of economic exploitation.M-01

Issue

The contract's owner has significant control over critical system parameters. The owner can set the hook address via setHook(). This hook address is then the only entity authorized to call start(), which sets the crucial pool address and enables the token's core functionality (Upeg minting/burning). A compromised owner account or a malicious owner could set a malicious hook address, which could then set a malicious pool address, leading to potential manipulation of the Upeg minting/burning process, unauthorized token mints, or other forms of economic exploitation.

Fix

While Ownable is a standard pattern, consider implementing a multi-signature wallet for the owner address to reduce the risk of a single point of failure. For highly critical functions like setHook, consider a time-locked or multi-step ownership transfer process to allow for community review or intervention. Clearly document the responsibilities and potential impact of the owner and hook roles.

Status

Unresolved

Low

Precision Loss in Upeg Count Calculations

The calculations for Upeg counts, such as amount / UNIT_PER_UPEG in _mintUpegs and balanceOf(addr) / UNIT_PER_UPEG for from_max_allowed and to_max_allowed, use integer division. This truncates any remainder, meaning that if an account holds, for example, 1.9 * UNIT_PER_UPEG tokens, it is only considered to own 1 Upeg. This results in a slight discrepancy where fractional Upeg equivalents are not accounted for, potentially leading to minor economic inefficiencies or user confusion regarding their exact Upeg entitlement based on their token balance.L-01

Issue

The calculations for Upeg counts, such as amount / UNIT_PER_UPEG in _mintUpegs and balanceOf(addr) / UNIT_PER_UPEG for from_max_allowed and to_max_allowed, use integer division. This truncates any remainder, meaning that if an account holds, for example, 1.9 * UNIT_PER_UPEG tokens, it is only considered to own 1 Upeg. This results in a slight discrepancy where fractional Upeg equivalents are not accounted for, potentially leading to minor economic inefficiencies or user confusion regarding their exact Upeg entitlement based on their token balance.

Fix

This is a design choice, but it should be clearly communicated to users. If a more precise representation is desired, consider alternative mechanisms for linking tokens and Upegs that can handle fractional amounts, or explicitly state that Upegs are only granted/counted in whole UNIT_PER_UPEG increments. Ensure that the implications of this precision loss are fully understood and accepted within the project's economic model.

Status

Unresolved

Info

Undisclosed Dependency on Upeg.sol Implementation

The Unipeg.sol contract heavily relies on the internal implementation details of the Upeg.sol contract, which was not provided for this audit. Functions like _mintUpeg, _burnUpeg, _transferUpeg, OwnerUpegsCount, and OwnerUpeg are critical for the core logic of Unipeg.sol. The security and correctness of the entire system are therefore directly dependent on the robustness, reentrancy-safety, and bug-free nature of the Upeg.sol contract. Any vulnerabilities or unexpected behaviors within Upeg.sol could directly compromise Unipeg.sol.I-01

Issue

The Unipeg.sol contract heavily relies on the internal implementation details of the Upeg.sol contract, which was not provided for this audit. Functions like _mintUpeg, _burnUpeg, _transferUpeg, OwnerUpegsCount, and OwnerUpeg are critical for the core logic of Unipeg.sol. The security and correctness of the entire system are therefore directly dependent on the robustness, reentrancy-safety, and bug-free nature of the Upeg.sol contract. Any vulnerabilities or unexpected behaviors within Upeg.sol could directly compromise Unipeg.sol.

Fix

Conduct a full audit of the Upeg.sol contract, paying close attention to its internal state management, transfer mechanisms, and any external interactions. Ensure that Upeg.sol adheres to best security practices, especially regarding reentrancy and access control, as its interactions with Unipeg.sol are highly sensitive. Provide the source code for Upeg.sol for a comprehensive security assessment.

Status

Unresolved

Analysis

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

The Unipeg contract implements an ERC20 token with integrated NFT (Upeg) syncing logic. The audit identified a critical reentrancy/logic flaw in the token-NFT synchronization mechanism, a high-severity economic issue leading to potential decoupling of token and NFT balances, and medium-severity centralization risks. While access controls are generally well-defined, the complex interaction between ERC20 and Upeg transfers introduces significant security challenges.

Technical7/10Low risk

The technical architecture (7.1) presents a complex dual-token system where ERC20 and NFT (Upeg) balances are intended to be synchronized. Code security (7.2) is significantly impacted by a critical reentrancy/logic flaw in the _afterTokenTransfer and _afterUpegTransferred hooks, creating a circular dependency that could lead to unexpected state or reentrancy. Access control (7.3) is generally robust, utilizing Solady's Ownable pattern, with critical functions like setHook and setImageParamsProvider restricted to the owner, and start restricted to the designated hook address.

Governance5/10Medium risk

The economic model (7.4) attempts to link ERC20 token holdings with Upeg NFT ownership, but a high-severity flaw in the syncing logic allows for a decoupling where actual Upeg counts can fall below expected token-derived counts, potentially impacting the token's value proposition. Governance (7.5) is centralized with a single owner controlling critical parameters like the hook address, which in turn controls the pool address, introducing a medium centralization risk. External dependencies (7.6) on the Upeg.sol contract are significant, and its internal implementation details are crucial for the overall security and correctness of the Unipeg system.

Upgrades8/10Low risk

The Unipeg contract is not designed with an upgrade mechanism (7.7), meaning its logic is immutable once deployed. This eliminates upgrade-related risks but requires thorough pre-deployment auditing. There are no explicit operational (7.8) concerns beyond standard owner responsibilities.

Final RecommendationWhat to do about this score

It is critical to address the reentrancy/logic flaw in the ERC20-Upeg synchronization to prevent potential exploits and ensure consistent state.

The economic model's decoupling issue also requires immediate attention to maintain the integrity of the token-NFT link. Consider implementing a more robust and explicit state machine for managing the synchronization, possibly with reentrancy guards or clearer separation of concerns between the ERC20 and Upeg transfer hooks. Thoroughly review the Upeg.sol contract's implementation, especially its transfer hooks, to ensure it does not exacerbate or introduce new vulnerabilities in conjunction with Unipeg.sol.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age3mo
Contract0x44b2…5505
Deployer0x02ed…6e83
Badge for your website
Unipeg 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. Sep 4, 202626Low
  2. Jul 31, 202624Low

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

Related Audits

6 more on the recordAll audits
Shiba InuSHIB · Ethereum26LowGrand Theft Auto VIGTAVI · Ethereum26LowMog CoinMOG · Ethereum26LowWrapped TAOWTAO · Ethereum26LowTelcoinTEL · Ethereum26LowStockereum.funSTOCKER · Ethereum26Low

Would You Like a More Detailed Audit of Unipeg?

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