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.

On-chain security analysis — is it a scam or legit?
Is Main Street USD Safe?
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 →This audit covers an ERC1967Proxy contract, which is a standard UUPS proxy implementation from OpenZeppelin.
Read the full analysis- 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 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking97.4%
- Walletsanonymous holders, free to sell1.0%
- Everyone elsethe rest of the supply1.5%
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- Uniswap v3USDCAnalysed$205.2K92.9%
- Balancer v3USDC$12.9K5.8%
- Uniswap v4USDT$1.9K0.9%
- Uniswap v4USDC$9400.4%
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xff0e…94a80x3377…882d0x7aba…01420xc7ec…d7da0xcf93…867eNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
CriticalUnverified 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
HighUndeterminable 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
HighUpgrade 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
InfoUse 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
InfoUUPS 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
InfoConstructor 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
upgradeToAndCallIssue
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 4The 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.
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.
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).
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
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 202674High
- 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