Is Re Protocol reUSD (REUSD) Safe? Smart Contract Security Analysis

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership RenouncedUnknown

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Audit History

2 audits on record

Jul 2382

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

Audit Summary

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.

Final Recommendation: It is critically important to verify the source code of the implementation contract (`ShareToken` at `0xb5276c436f65913cd5332de745d04fedeb4a21d4`). Without verification, the functionality and security of the entire system operating behind this proxy are unknown and cannot be trusted. Once verified, a comprehensive audit of the implementation contract's code, including its access control for upgrade functions, should be performed to ensure its integrity and security.

Category Ratings

TechnicalMedium

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

GovernanceHigh

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

UpgradesHigh

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

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

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% (98.2% total → 40.3% effective; 1.7% in EOAs, 96.4% 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, pool = 99% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
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

Security Findings

5 total

1 Critical 1 High 3 Info

C-01CriticalUnresolved

Unverified Implementation Contract

The proxy contract (0x5086bf358635b81d8c47c66d1c8b9e567db70c72) delegates all its logic to an implementation contract identified as 'ShareToken' at address 0xb5276c436f65913cd5332de745d04fedeb4a21d4. 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.

Recommendation: Immediately verify the source code of the implementation contract (0xb5276c436f65913cd5332de745d04fedeb4a21d4) on the blockchain explorer. Once verified, a thorough security audit of the implementation's code must be conducted to ensure its safety and integrity.

H-01HighUnresolved

Centralized Upgradeability Control

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

Recommendation: Once 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).

I-01InformationalUnresolved

OpenZeppelin Library Usage

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

Recommendation: Continue to use and monitor updates from OpenZeppelin for best practices and security patches.

I-02InformationalUnresolved

EIP-1967 Compliance

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

Recommendation: No action required. This is a best practice.

I-03InformationalUnresolved

Non-Payable Upgrade Check

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

Recommendation: No action required. This is a good security practice.

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.

Is Re Protocol reUSD Safe? REUSD