Quantum Audit Logo

Is Main Street USD Safe?

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

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

Main Street USD MSUSD
0x4ba0…7c00
Ethereum Not verifiedLast checked 3d ago 1 audit on record
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

1 Critical2 High3 Informational
Volume 24h
$1.1K
Liquidity
$205.2K
Price
$0.4092
Token Age
1y
Top 10 Holders
98.5%

Security Findings

Critical

Unverified Implementation Contract

C-01The 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.
IssueThe 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.
FixImmediately 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.
StatusUnresolved
High

Undeterminable Access Control and Economic Logic

H-01Due 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.
IssueDue 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.
FixVerify 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.
StatusUnresolved
High

Upgrade Mechanism Security Risk

H-02While 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.
IssueWhile 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.
FixAfter 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.
StatusUnresolved
Info

Use of Standard OpenZeppelin ERC1967Proxy

I-01The 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.
IssueThe 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.
FixContinue to rely on well-vetted libraries like OpenZeppelin for core infrastructure components.
StatusResolved
Info

UUPS Proxy Pattern in Use

I-02The 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.
IssueThe 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.
FixEnsure that the upgrade logic within the implementation contract is robust, secure, and adheres to best practices for authorization and safety checks.
StatusResolved
Info

Constructor Initialization with `upgradeToAndCall`

I-03The 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.
IssueThe 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.
FixEnsure that the initialization function in the implementation contract is properly secured against re-initialization attacks.
StatusResolved

Category Ratings

TechnicalHigh3/10

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.

GovernanceHigh1/10

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.

UpgradesHigh1/10

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

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

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

Holder Composition

1.0% in wallets97.4% in contracts
Effective Concentration40.0%

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

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 Holder91.2%
Top-3 Unlocked100.0%

Key Addresses

Deployer
0xe0f9…5c56
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.

What Raised This Score

  • 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

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.

Related Audits

Covalent X Token (CXT)Critical RiskUSDxCritical RiskNEXOCritical RiskCronos (CRO)Critical RiskEpic Chain (EPIC)Critical RisktrUSDCritical Risk

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