Quantum Audit Logo

Is Unipeg Safe?

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

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

Unipeg UPEG
0x44b2…5505
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 Critical1 High1 Medium1 Low1 Informational
Volume 24h
$83.2K
Liquidity
$1.59M
Price
$221.3400
Token Age
3mo
Top 10 Holders
19.7%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Critical Reentrancy/Logic Flaw in Upeg-ERC20 Sync

C-01The `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…
IssueThe `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…
FixRefactor 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…
StatusUnresolved
High

Economic Decoupling of ERC20 and Upeg Balances

H-01The 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…
IssueThe 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…
FixRe-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…
StatusUnresolved
Medium

Centralization Risk with Owner and Hook Control

M-01The 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.
IssueThe 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.
FixWhile `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.
StatusUnresolved
Low

Precision Loss in Upeg Count Calculations

L-01The 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.
IssueThe 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.
FixThis 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.
StatusUnresolved
Info

Undisclosed Dependency on `Upeg.sol` Implementation

I-01The `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`.
IssueThe `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`.
FixConduct 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.
StatusUnresolved

Category Ratings

TechnicalLow7/10

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.

GovernanceMedium5/10

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.

UpgradesLow8/10

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.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

19.7% in top 10
4.0% in wallets15.6% in contracts
Effective Concentration10.3%

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

$1.82M across 8 pairs
Uniswap v4ETHanalysed$1.59M87.7%Uniswap v4ETH$140.1K7.7%Uniswap v4ETH$69.2K3.8%Uniswap v4USDT$7.5K0.4%Uniswap v3WETH$4.3K0.2%Uniswap v4ETH$1.9K0.1%
Show 2 more pairsShow less
Uniswap v4ETH$4590.0%Uniswap v2WETH$370.0%

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 Holder84.2%
Top-3 Unlocked100.0%

Key Addresses

5 addresses
Deployer
0x02ed…6e83
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.

What Raised This Score

7 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

Related Audits

6 more on the record
Shiba Inu (SHIB)Medium RiskGrand Theft Auto VI (GTAVI)Medium RiskMog Coin (MOG)Medium RiskWrapped TAO (WTAO)Medium RiskTelcoin (TEL)Medium RiskStockereum.fun (STOCKER)Medium Risk

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