Quantum Audit Logo
Launch App

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

Is Re Protocol reUSD Safe?

REUSDEthereum
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 High · 3 Info5
SummaryAI Copilot

This audit covers an ERC1967Proxy contract, which utilizes OpenZeppelin's battle-tested UUPS proxy pattern.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
98.6%Contracts
98.6%Contracts
ContractsWalletsEveryone elseBubble area = share of supply
99.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking98.6%
  • Walletsanonymous holders, free to sell0.8%
  • Everyone elsethe rest of the supply0.6%
Effective concentrationwhat the score reads40.2%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$451.5K

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$451.5KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x1e01…8075

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

Security Findings

1 Critical1 High3 Info
Critical

Unverified Implementation Contract

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

Issue

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

Fix

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

Status

Unresolved

High

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.H-01

Issue

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.

Fix

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

Status

Unresolved

Info

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.I-01

Issue

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.

Fix

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

Status

Unresolved

Info

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.I-02

Issue

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.

Fix

No action required. This is a best practice.

Status

Unresolved

Info

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.I-03

Issue

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.

Fix

No action required. This is a good security practice.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical4/10Medium risk

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.

Governance1/10High risk

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.

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

It is critically important to verify the source code of the implementation contract (ShareToken at ).

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.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkEthereum
Token age10mo
Contract0x5086…0c72
Deployer0x6c15…7649
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Re Protocol reUSD security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Jul 23, 202682High

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

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 recordAll audits
Global DollarUSDG · Ethereum81HighBigShortBetsBIGSB · Ethereum81HighFrankencoinZCHF · Ethereum81HighHeyAnonANON · Ethereum81HighKyber Network Crystal v2KNC · Ethereum81HighapyUSDEthereum83High

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 Is this your token? Publish your own audit on this page