Quantum Audit Logo

Is RE a Scam?

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

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

RE RE
0x5265…8143
Ethereum Not verifiedLast checked 3d ago 1 audit on record New Launch · 3d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

This audit focused on the `ERC1967Proxy` contract, which utilizes the UUPS upgradeable proxy pattern. A critical finding is the unverified source code for the implementation contract, preventing a full security assessment of the system's core logic. This significantly elevates the overall risk, as the actual behavior and security of the protocol's functionality cannot be confirmed. Further review of the implementation is essential.

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

Security Findings

1 High1 Med1 Low1 Info
High

Unverified Implementation Contract Source Code

H-01The implementation contract at address 0x4d24…0273, which contains the core logic for the `ERC1967Proxy`, does not have its source code verified on Etherscan or provided for audit. This prevents a thorough security analysis of the actual business logic, access control, economic mechanisms, and upgrade authorization. Without visibility into the implementation, critical vulnerabilities such as reentrancy, integer overflows, or logic flaws cannot be identified, rendering the entire system's security unknown.
IssueThe implementation contract at address , which contains the core logic for the `ERC1967Proxy`, does not have its source code verified on Etherscan or provided for audit. This prevents a thorough security analysis of the actual business logic, access control, economic mechanisms, and upgrade authorization. Without visibility into the implementation, critical vulnerabilities such as reentrancy, integer overflows, or logic flaws cannot be identified, rendering the entire system's security unknown.
FixImmediately verify and publish the source code for the implementation contract () on Etherscan. Once verified, a full security audit of the implementation contract should be conducted to identify and mitigate any potential vulnerabilities.
StatusUnresolved
Medium

Lack of Transparent Upgrade Authorization

M-01While the `ERC1967Proxy` implements the UUPS upgrade pattern, the authorization mechanism for performing upgrades (i.e., who can call `upgradeToAndCall` or `_authorizeUpgrade` in the implementation) is unknown due to the unverified implementation contract. This lack of transparency means it's impossible to assess if robust access control (e.g., multi-signature wallet, timelock) is in place to prevent unauthorized or malicious upgrades, which could lead to a complete compromise of the protocol.
IssueWhile the `ERC1967Proxy` implements the UUPS upgrade pattern, the authorization mechanism for performing upgrades (i.e., who can call `upgradeToAndCall` or `_authorizeUpgrade` in the implementation) is unknown due to the unverified implementation contract. This lack of transparency means it's impossible to assess if robust access control (e.g., multi-signature wallet, timelock) is in place to prevent unauthorized or malicious upgrades, which could lead to a complete compromise of the protocol.
FixAfter verifying the implementation contract's source code, ensure that the upgrade authorization logic is robust. Implement a multi-signature wallet and/or a timelock for controlling upgrades to the implementation contract. This adds a layer of security and decentralization, preventing a single point of compromise from enabling malicious upgrades.
StatusUnresolved
Low

Potential for Unintended Ether Reception in Proxy

L-01The `ERC1967Proxy` constructor is `payable` and delegates to `ERC1967Utils.upgradeToAndCall`. If `_data` is provided, `msg.value` is forwarded via `Address.functionDelegateCall`. If the implementation's initializer function is not designed to handle or consume this `msg.value`, any Ether sent during the proxy deployment (initialization) could become permanently locked in the proxy contract. While `ERC1967Utils` includes a check (`_checkNonPayable()`) to revert if `msg.value > 0` and `_data` is empty, this does not cover the case where `_data` is non-empty but the implementation's initializer does not consume the Ether.
IssueThe `ERC1967Proxy` constructor is `payable` and delegates to `ERC1967Utils.upgradeToAndCall`. If `_data` is provided, `msg.value` is forwarded via `Address.functionDelegateCall`. If the implementation's initializer function is not designed to handle or consume this `msg.value`, any Ether sent during the proxy deployment (initialization) could become permanently locked in the proxy contract. While `ERC1967Utils` includes a check (`_checkNonPayable()`) to revert if `msg.value > 0` and `_data` is empty, this does not cover the case where `_data` is non-empty but the implementation's initializer does not consume the Ether.
FixEnsure that the initializer function of the implementation contract is either `payable` and explicitly handles any forwarded `msg.value`, or that the deployment process strictly ensures `msg.value` is zero when `_data` is non-empty and the initializer is not designed to receive Ether.
StatusUnresolved
Info

Reliance on OpenZeppelin Libraries

I-01The contract heavily relies on OpenZeppelin's battle-tested `ERC1967Proxy`, `Proxy`, and `ERC1967Utils` libraries. These libraries are widely used and have undergone extensive audits and community review, significantly reducing the risk of vulnerabilities within the proxy's core delegation and storage management logic.
IssueThe contract heavily relies on OpenZeppelin's battle-tested `ERC1967Proxy`, `Proxy`, and `ERC1967Utils` libraries. These libraries are widely used and have undergone extensive audits and community review, significantly reducing the risk of vulnerabilities within the proxy's core delegation and storage management logic.
FixContinue to monitor OpenZeppelin's security advisories and updates for any potential issues in the utilized library versions. Ensure that any custom logic built upon these libraries adheres to similar high security standards.
StatusResolved

Category Ratings

TechnicalMedium6/10

The `ERC1967Proxy` contract leverages battle-tested OpenZeppelin libraries, providing a robust and secure proxy architecture (7.1 Architecture, 7.2 Code Security). The proxy correctly implements the ERC-1967 standard for storage slot management, mitigating common storage collision risks. However, the primary technical risk stems from the unverified implementation contract (), which prevents a thorough security analysis of the actual business logic and potential vulnerabilities like reentrancy or integer overflows (7.2 Code Security).

GovernanceHigh1/10

The proxy itself does not contain governance or economic logic; these aspects reside entirely within the unverified implementation contract (7.4 Economic, 7.5 Governance). Without visibility into the implementation's source, it is impossible to assess the robustness of its access control mechanisms, such as upgrade authorization or critical function permissions (7.3 Access Control). This introduces significant uncertainty regarding the system's economic and governance security and operational safety (7.8 Operations).

UpgradesHigh1/10

The contract utilizes the UUPS proxy pattern, which is a well-established and secure upgrade mechanism (7.7 Upgrades). The `ERC1967Utils` library correctly handles implementation slot updates and emits `Upgraded` events. However, the lack of verified source code for the implementation contract means the upgrade authorization logic (e.g., who can call `upgradeToAndCall` or `_authorizeUpgrade`) cannot be audited, posing a high risk for unauthorized upgrades or upgrade path vulnerabilities (7.7 Upgrades).

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

97.2% in top 10
51.8% in wallets45.4% in contracts
Effective Concentration69.9%

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

$13.1K across 4 pairs
Uniswap v3USDCanalysed$6.5K49.5%Pancakeswap v3WETH$3.6K27.4%Uniswap v3LINK$2.1K16.4%Uniswap v3PENDLE$8916.8%

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

Key Addresses

2 addresses
Deployer
0x6c15…7649
Unlocked LP Held By
0xb5a6…b002

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

What Raised This Score

11 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 50% (97.2% total → 69.9% effective; 51.8% in EOAs, 45.4% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($13,136 across 4 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 49% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 49% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 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

Frequently Asked Questions

Is RE a scam?

Based on the available data, labeling RE definitively as a "scam" is not possible, but it carries a high-risk score of 59/100. While contract ownership is renounced and no mint function exists, the extreme concentration of 98.3% of tokens in the top 10 wallets and unlocked liquidity are significant red flags often associated with projects that could lead to investor losses.

Is RE safe to buy?

RE is not considered safe to buy, evidenced by its high-risk score of 59/100. The primary concerns include the very high concentration of 98.3% of the supply among the top 10 holders, which poses a significant manipulation risk. Additionally, the liquidity is not locked, meaning it could be removed by providers, potentially leading to a sharp price collapse and leaving investors unable to sell.

Has RE been audited?

The RE contract is verified, meaning its deployed bytecode matches the publicly available source code. However, "contract verified" is not the same as undergoing a full security audit by an independent firm. Verification enhances transparency but does not guarantee the absence of vulnerabilities or protect against economic risks, especially given the project's high-risk score.

Related Audits

6 more on the record
ZamaHigh RiskUNICURVEHigh RiskChain (XCN)High RiskGram (prev. Toncoin) (GRAM)High RiskDIAToken (DIA)High RiskTERAFABHigh Risk

Would You Like a More Detailed Audit of RE?

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

Get Detailed Audit