Is RE a Scam? New Token Security Check

Critical Security Flags

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedUnknown

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Audit History

2 audits on record

Jul 2381

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: Prioritize verifying and publishing the source code for the implementation contract (`0x4d24b40e5b1103b3ce071192fce91ef39abc0273`). This is crucial for transparency and to enable a comprehensive security audit of the system's core logic and upgrade authorization mechanisms. Without this, the entire system remains unauditable and carries significant inherent risk. Implement robust access control, ideally with a multi-signature wallet and/or a timelock, for all critical administrative functions, especially contract upgrades. Ensure that the implementation's initializer function correctly handles any Ether forwarded during proxy deployment to prevent stuck funds.

Category Ratings

TechnicalMedium

6/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, th

GovernanceHigh

1/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 mechan

UpgradesHigh

1/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

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Upgrades (30d)0 · stable

LP Distribution

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

What Raised This Score

11 factors

Ownership status UNKNOWN (owner could not be resolved)
Proxy contract (upgradeable — admin can replace logic)
Top-10 concentration > 70% (97.5% total → 70.2% effective; 52.1% in EOAs, 45.4% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $10k ($3,429 across 6 pairs — easily drained)
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

Security Findings

4 total

1 High 1 Medium 1 Low 1 Info

H-01HighUnresolved

Unverified Implementation Contract Source Code

The implementation contract at address `0x4d24b40e5b1103b3ce071192fce91ef39abc0273`, 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.

Recommendation: Immediately verify and publish the source code for the implementation contract (`0x4d24b40e5b1103b3ce071192fce91ef39abc0273`) on Etherscan. Once verified, a full security audit of the implementation contract should be conducted to identify and mitigate any potential vulnerabilities.

M-01MediumUnresolved

Lack of Transparent Upgrade Authorization

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

Recommendation: After 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.

L-01LowUnresolved

Potential for Unintended Ether Reception in Proxy

The `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.

Recommendation: Ensure 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.

I-01InformationalResolved

Reliance on OpenZeppelin Libraries

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

Recommendation: Continue 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.

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.

Is RE a Scam? RE