Early-stage security check — honeypot & rug-pull analysis
EthereumThis audit focused on the ERC1967Proxy contract, which utilizes the UUPS upgradeable proxy pattern.
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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xb5a6…b002No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
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.H-01The 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.
Immediately 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.
Unresolved
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.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.
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.
Unresolved
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.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.
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.
Unresolved
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.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.
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.
Resolved
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.
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).
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).
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).
Prioritize verifying and publishing the source code for the implementation contract ().
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.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
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.
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.
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.
This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.
Get Detailed Audit Is this your token? Publish your own audit on this page
