Quantum Audit Logo
Launch App

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

Is Main Street USD Safe?

MSUSDEthereum
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
SummaryAI Copilot

This audit covers an ERC1967Proxy contract, which is a standard UUPS proxy implementation from OpenZeppelin.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • 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 = 91.2%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
Exact factors
  • Ownership NOT renounced — Multisig (3-of-4)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (98.5% total → 40.0% effective; 1.0% in EOAs, 97.4% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 91.2% (independent LP — depth risk, pool = 93% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 93% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 2 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
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
97.4%Contracts1.5%
97.4%Contracts
ContractsWalletsEveryone elseBubble area = share of supply
98.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking97.4%
  • Walletsanonymous holders, free to sell1.0%
  • Everyone elsethe rest of the supply1.5%
Effective concentrationwhat the score reads40.0%
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$220.9K across 4 pairs
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$205.2KShare of depth92.9%
Top-1 Unlocked Holder91.2%
Top-3 Unlocked100.0%
Unlocked LP held by
0xff0e…94a80x3377…882d0x7aba…01420xc7ec…d7da0xcf93…867e

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

Security Findings

1 Critical2 High3 Info
Critical

Unverified Implementation Contract

The proxy contract at 0x4ba0…7c00 delegates calls to an implementation contract at 0x9627…da46. However, the source code for this implementation contract is not verified on the blockchain. This prevents any security analysis of the actual business logic, access control, economic model, and upgrade authorization, making the entire system's security posture unknown and highly vulnerable to undiscovered issues.C-01

Issue

The proxy contract at delegates calls to an implementation contract at . However, the source code for this implementation contract is not verified on the blockchain. This prevents any security analysis of the actual business logic, access control, economic model, and upgrade authorization, making the entire system's security posture unknown and highly vulnerable to undiscovered issues.

Fix

Immediately verify the source code of the implementation contract () on the blockchain. Once verified, a full security audit of the implementation contract must be performed to identify and address any vulnerabilities.

Status

Unresolved

High

Undeterminable Access Control and Economic Logic

Due to the unverified nature of the implementation contract, it is impossible to assess the access control mechanisms (7.3 Access Control) governing critical functions, privileged roles, or the economic logic (7.4 Economic) of the protocol. This includes evaluating potential attack vectors like unauthorized fund transfers, manipulation of economic parameters, or reentrancy vulnerabilities within the core logic. The lack of visibility into these critical components poses a high risk to the integrity and security of the protocol.H-01

Issue

Due to the unverified nature of the implementation contract, it is impossible to assess the access control mechanisms (7.3 Access Control) governing critical functions, privileged roles, or the economic logic (7.4 Economic) of the protocol. This includes evaluating potential attack vectors like unauthorized fund transfers, manipulation of economic parameters, or reentrancy vulnerabilities within the core logic. The lack of visibility into these critical components poses a high risk to the integrity and security of the protocol.

Fix

Verify the implementation contract's source code and then conduct a thorough audit of its access control mechanisms, role-based permissions, and economic logic to ensure they are robust and secure against common attack patterns.

Status

Unresolved

High

Upgrade Mechanism Security Risk

While the proxy uses the UUPS pattern, which is generally secure, the actual authorization logic for upgrades resides within the unverified implementation contract. This means the conditions under which the contract can be upgraded, who has the authority to initiate upgrades, and any associated timelocks or governance procedures (7.7 Upgrades) cannot be verified. A compromised or malicious implementation could allow unauthorized upgrades, leading to a complete loss of control over the protocol or introduction of backdoors.H-02

Issue

While the proxy uses the UUPS pattern, which is generally secure, the actual authorization logic for upgrades resides within the unverified implementation contract. This means the conditions under which the contract can be upgraded, who has the authority to initiate upgrades, and any associated timelocks or governance procedures (7.7 Upgrades) cannot be verified. A compromised or malicious implementation could allow unauthorized upgrades, leading to a complete loss of control over the protocol or introduction of backdoors.

Fix

After verifying the implementation contract, meticulously audit the _authorizeUpgrade function and any related upgrade governance mechanisms within the implementation. Ensure that upgrade permissions are tightly controlled, ideally through a multi-signature wallet or a robust governance process with appropriate timelocks.

Status

Unresolved

Info

Use of Standard OpenZeppelin ERC1967Proxy

The contract utilizes the ERC1967Proxy from OpenZeppelin Contracts (v5.0.0). This is a well-audited and widely adopted standard for upgradeable proxies, providing a solid and secure foundation for the proxy layer.I-01

Issue

The contract utilizes the ERC1967Proxy from OpenZeppelin Contracts (v5.0.0). This is a well-audited and widely adopted standard for upgradeable proxies, providing a solid and secure foundation for the proxy layer.

Fix

Continue to rely on well-vetted libraries like OpenZeppelin for core infrastructure components.

Status

Resolved

Info

UUPS Proxy Pattern in Use

The contract implements the UUPS (Universal Upgradeable Proxy Standard) pattern, where the upgrade logic resides within the implementation contract itself, rather than a separate admin contract. This design choice offers flexibility and can simplify the upgrade process.I-02

Issue

The contract implements the UUPS (Universal Upgradeable Proxy Standard) pattern, where the upgrade logic resides within the implementation contract itself, rather than a separate admin contract. This design choice offers flexibility and can simplify the upgrade process.

Fix

Ensure that the upgrade logic within the implementation contract is robust, secure, and adheres to best practices for authorization and safety checks.

Status

Resolved

Info

Constructor Initialization with upgradeToAndCall

The proxy's constructor uses ERC1967Utils.upgradeToAndCall(implementation, _data) to initialize the implementation address and optionally call an initialization function on the implementation. This is a standard and secure way to deploy and initialize UUPS proxies.I-03

Issue

The proxy's constructor uses ERC1967Utils.upgradeToAndCall(implementation, _data) to initialize the implementation address and optionally call an initialization function on the implementation. This is a standard and secure way to deploy and initialize UUPS proxies.

Fix

Ensure that the initialization function in the implementation contract is properly secured against re-initialization attacks.

Status

Resolved

Analysis

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

This audit covers an ERC1967Proxy contract, which is a standard UUPS proxy implementation from OpenZeppelin. While the proxy contract itself is well-vetted, the critical finding is that its associated implementation contract (0x96271bea7a9c4b8edd6c3a05e548f05f157ada46) is unverified on-chain. This prevents any meaningful security assessment of the protocol's core logic, access control, economic model, and upgrade mechanisms, introducing severe risks.

Technical3/10High risk

The proxy contract (7.1 Architecture) utilizes the battle-tested OpenZeppelin ERC1967Proxy, which is a strong foundation for upgradeability. However, the primary technical risk stems from the unverified implementation contract (7.2 Code Security). Without access to the implementation's source code, a comprehensive audit of its logic, including reentrancy, integer overflows, or other common vulnerabilities, is impossible. This significantly elevates the technical risk, as the actual operational code remains opaque.

Governance1/10High risk

The governance and economic models (7.4 Economic, 7.5 Governance) of the protocol are entirely dependent on the logic within the implementation contract. Since the implementation contract is unverified, it is impossible to assess critical aspects such as tokenomics, fee structures, access control for privileged functions, or any potential oracle manipulation vectors (7.6 External). This lack of transparency means the economic stability and governance integrity of the system cannot be evaluated, posing a high risk.

Upgrades1/10High risk

The contract employs the UUPS proxy pattern (7.7 Upgrades), which is a secure and widely adopted upgrade mechanism. The ERC1967Proxy correctly delegates upgrade authorization to the implementation contract. However, the unverified status of the implementation contract means that the actual upgrade authorization logic (e.g., who can call _authorizeUpgrade or upgradeToAndCall) cannot be audited. This introduces a high risk, as a malicious or buggy implementation could lead to unauthorized upgrades or a frozen system, impacting future operations (7.8 Operations).

Final RecommendationWhat to do about this score

The most critical recommendation is to immediately verify the source code of the implementation contract () on the blockchain.

Without this, a full security audit cannot be performed, and the system's overall security posture remains unknown and highly risky. Once verified, a comprehensive audit of the implementation contract should be conducted to identify and mitigate any vulnerabilities related to its core logic, access control, economic model, and upgrade authorization mechanisms.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkEthereum
Token age1y
Contract0x4ba0…7c00
Deployer0xe0f9…5c56
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Main Street USD 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. Sep 4, 202674High
  2. Jul 23, 202672High

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

Frequently Asked Questions

Is Main Street USD a scam?

Based on available data, Main Street USD exhibits high-risk characteristics, especially its highly concentrated token distribution where 99.2% is held by the top 10 wallets, and unlocked liquidity. While the contract is verified and ownership renounced, these don't mitigate the direct market manipulation or rug pull potential from concentrated holders and unprotected liquidity. It requires careful consideration.

Is Main Street USD safe to buy?

Investing in Main Street USD carries significant risks. The extreme centralization, with 99.2% of tokens held by the top 10 addresses, makes it vulnerable to price manipulation. Additionally, liquidity is not locked, posing a risk of liquidity withdrawal (rug pull) that could leave investors unable to sell. These factors contribute to its high-risk score.

Has Main Street USD been audited?

The Main Street USD contract has been verified on Ethereum, meaning its code is publicly visible and matches the deployed bytecode. However, "contract verified" is not the same as a comprehensive security audit by an independent third party. An audit typically involves deeper code analysis for vulnerabilities beyond just transparency.

Would You Like a More Detailed Audit of Main Street USD?

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