Quantum Audit Logo

Is Re Protocol reUSD Safe?

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

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

Re Protocol reUSD REUSD
0x5086…0c72
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

This audit covers an ERC1967Proxy contract, which utilizes OpenZeppelin's battle-tested UUPS proxy pattern. While the proxy contract itself is robust, a critical vulnerability exists due to the unverified source code of its current implementation contract, 'ShareToken' (0xb5276c436f65913cd5332de745d04fedeb4a21d4). This lack of transparency prevents any security assessment of the actual business logic and upgrade mechanisms, posing a severe risk to the integrity and security of the entire system.

1 Critical1 High3 Informational
Volume 24h
$17.8K
Liquidity
$451.5K
Price
$1.0980
Token Age
10mo
Top 10 Holders
99.4%

Security Findings

1 Crit1 High3 Info
Critical

Unverified Implementation Contract

C-01The proxy contract (0x5086…0c72) delegates all its logic to an implementation contract identified as 'ShareToken' at address 0xb527…21d4. The source code for this implementation contract is not verified on the blockchain explorer. This means the actual code being executed by the proxy is unknown, making it impossible to assess its security, functionality, or potential malicious behavior. This poses an extreme risk as the contract could contain backdoors, vulnerabilities, or arbitrary logic.
IssueThe proxy contract () delegates all its logic to an implementation contract identified as 'ShareToken' at address . The source code for this implementation contract is not verified on the blockchain explorer. This means the actual code being executed by the proxy is unknown, making it impossible to assess its security, functionality, or potential malicious behavior. This poses an extreme risk as the contract could contain backdoors, vulnerabilities, or arbitrary logic.
FixImmediately verify the source code of the implementation contract () on the blockchain explorer. Once verified, a thorough security audit of the implementation's code must be conducted to ensure its safety and integrity.
StatusUnresolved
High

Centralized Upgradeability Control

H-01The contract uses the UUPS proxy pattern, where the upgrade logic and its associated access control reside within the implementation contract. While this is a standard pattern, it implies a centralized point of control for upgrades. If the private key of the address or the multisig controlling the upgrade function within the implementation contract is compromised, an attacker could deploy a malicious new implementation, leading to a complete loss of funds or control over the protocol. The specific details of this control cannot be assessed due to the unverified implementation.
IssueThe contract uses the UUPS proxy pattern, where the upgrade logic and its associated access control reside within the implementation contract. While this is a standard pattern, it implies a centralized point of control for upgrades. If the private key of the address or the multisig controlling the upgrade function within the implementation contract is compromised, an attacker could deploy a malicious new implementation, leading to a complete loss of funds or control over the protocol. The specific details of this control cannot be assessed due to the unverified implementation.
FixOnce the implementation contract is verified, ensure that the upgrade function is protected by a robust access control mechanism, ideally a well-configured multi-signature wallet (e.g., Gnosis Safe) with a sufficient threshold, or a time-locked governance mechanism. Implement strict operational security procedures for managing the upgrade key(s).
StatusUnresolved
Info

OpenZeppelin Library Usage

I-01The contract leverages OpenZeppelin's battle-tested and widely adopted proxy libraries (ERC1967Proxy, ERC1967Utils, IBeacon, Proxy, Address, StorageSlot). This is a strong security practice as these libraries are rigorously audited and maintained by the OpenZeppelin team, significantly reducing the risk of common proxy-related vulnerabilities.
IssueThe contract leverages OpenZeppelin's battle-tested and widely adopted proxy libraries (ERC1967Proxy, ERC1967Utils, IBeacon, Proxy, Address, StorageSlot). This is a strong security practice as these libraries are rigorously audited and maintained by the OpenZeppelin team, significantly reducing the risk of common proxy-related vulnerabilities.
FixContinue to use and monitor updates from OpenZeppelin for best practices and security patches.
StatusUnresolved
Info

EIP-1967 Compliance

I-02The proxy contract correctly implements the EIP-1967 standard for transparent proxy storage slots. This ensures that the implementation address, admin address (if used), and beacon address (if used) are stored in well-defined, non-colliding storage locations, preventing storage clashes with the logic contract.
IssueThe proxy contract correctly implements the EIP-1967 standard for transparent proxy storage slots. This ensures that the implementation address, admin address (if used), and beacon address (if used) are stored in well-defined, non-colliding storage locations, preventing storage clashes with the logic contract.
FixNo action required. This is a best practice.
StatusUnresolved
Info

Non-Payable Upgrade Check

I-03The `ERC1967Utils.upgradeToAndCall` function includes a check (`_checkNonPayable()`) that reverts if `msg.value > 0` when no `data` is provided for a setup call. This prevents accidental transfer of Ether to the proxy contract during an upgrade operation where the Ether would otherwise become stuck.
IssueThe `ERC1967Utils.upgradeToAndCall` function includes a check (`_checkNonPayable()`) that reverts if `msg.value > 0` when no `data` is provided for a setup call. This prevents accidental transfer of Ether to the proxy contract during an upgrade operation where the Ether would otherwise become stuck.
FixNo action required. This is a good security practice.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract utilizes battle-tested OpenZeppelin libraries for its proxy implementation, ensuring adherence to EIP-1967 standards and robust delegatecall mechanisms (7.1 Architecture, 7.2 Code Security). The `ERC1967Utils` library includes checks like `_checkNonPayable()` to prevent accidental loss of funds during upgrades (7.2 Code Security). The primary technical risk is that the linked implementation contract (`ShareToken` at ) is unverified, meaning its source code is unknown (7.1 Architecture, 7.2 Code Security). This makes it impossible to assess the security of the actual logic being executed by the proxy.

GovernanceHigh1/10

The proxy itself is a standard UUPS implementation, which delegates upgrade logic to the implementation contract, allowing for flexible governance models (7.5 Governance). The upgradeability mechanism, while standard, implies a centralized control point within the unverified implementation contract (7.3 Access Control, 7.5 Governance). If the administrator or multisig controlling the implementation's upgrade function is compromised, a malicious contract could be deployed, leading to potential economic loss or system manipulation (7.4 Economic). Without the implementation's source, the specific governance model and its security cannot be evaluated.

UpgradesHigh1/10

The contract correctly implements the UUPS proxy pattern using OpenZeppelin's `ERC1967Proxy` and `ERC1967Utils`, which is a well-established and secure standard for upgradeable contracts (7.7 Upgrades). This pattern allows for future enhancements and bug fixes without deploying new addresses. The critical concern is that the current implementation contract (`ShareToken`) is unverified, making it impossible to audit its upgrade logic or ensure it adheres to secure practices (7.7 Upgrades). This lack of transparency means the upgrade mechanism could be controlled by an insecure entity or contain vulnerabilities that allow unauthorized or malicious upgrades.

Security Checklist

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

Proxy Upgrade Controls

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

Holder Composition

99.4% in top 10
0.8% in wallets98.6% in contracts
Effective Concentration40.2%

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

$451.5K

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
0x1e01…8075

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

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (99.4% total → 40.2% effective; 0.8% in EOAs, 98.6% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 Critical finding(s) from audit
  • 1 High 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 Protocol reUSD a scam?

While the data does not definitively confirm Re Protocol reUSD as a scam, several red flags warrant caution. The contract is verified, and ownership is renounced, which are positive indicators. However, the extreme token centralization, with 98.7% held by the top 10 wallets, coupled with unlocked liquidity, presents significant risks often associated with potential malicious activities or market instability. Investors should exercise due diligence.

Is Re Protocol reUSD safe to buy?

Based on the provided data, Re Protocol reUSD carries a high-risk score of 51/100, suggesting it is not safe for risk-averse investors. Key concerns include the top 10 holders controlling nearly all supply (98.7%), posing a significant centralization risk and potential for market manipulation. Furthermore, the absence of locked liquidity means funds can be withdrawn, increasing volatility and potential for sudden market impact.

Has Re Protocol reUSD been audited?

The Re Protocol reUSD contract is verified, meaning its code is public and matches the deployed version on the blockchain, providing transparency. However, verification differs from a full security audit performed by third-party experts. The available data does not indicate whether such a comprehensive audit, which assesses code for vulnerabilities, has been completed for the REUSD contract.

Related Audits

6 more on the record
Global Dollar (USDG)Critical RiskBigShortBets (BIGSB)Critical RiskFrankencoin (ZCHF)Critical RiskRallyCritical RiskEden Token (EDEN)Critical RiskZK Coin (ZKC)Critical Risk

Would You Like a More Detailed Audit of Re Protocol reUSD?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit