Quantum Audit Logo

Is Sock a Scam?

Early-stage security check — honeypot & rug-pull analysis

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

Sock SOCK
0xb3a1…a5b9
BNB Chain
Not verifiedThis 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 10d ago 1 audit on record New Launch · 5d old
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The SockLaunchToken contract is an ERC20 token with ERC20Permit functionality. It features a dynamic `creator()` function that determines access control for updating metadata. The primary risk identified is the reliance on external contracts for this critical access control logic, which introduces a significant external dependency.

1 High1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (5d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$983.2K
Liquidity
$219.9K
Price
$0.002045
Token Age
5d
Top 10 Holders
22.2%

Security Findings

High

Critical External Dependency in Creator Logic

H-01The `creator()` function, which determines the privileged address for `setMetadataURI`, relies on external contracts (`ILaunchpadHook` and `ICreatorLookup`) to dynamically resolve the creator. If these external contracts are compromised, malicious, or misconfigured, an unauthorized entity could manipulate the `creator()` return value, thereby gaining control over the `setMetadataURI` function. This introduces a significant trust assumption and a potential single point of failure on systems not directly audited.
IssueThe `creator()` function, which determines the privileged address for `setMetadataURI`, relies on external contracts (`ILaunchpadHook` and `ICreatorLookup`) to dynamically resolve the creator. If these external contracts are compromised, malicious, or misconfigured, an unauthorized entity could manipulate the `creator()` return value, thereby gaining control over the `setMetadataURI` function. This introduces a significant trust assumption and a potential single point of failure on systems not directly audited.
FixThoroughly audit and secure the `ILaunchpadHook` and `ICreatorLookup` contracts. Implement robust access control and immutability for these external contracts if possible. Consider adding a mechanism to update the `launchpad` address by a trusted multi-signature wallet or DAO, or a timelock for changes to the `metadataURI` if the external dependencies are deemed high risk.
StatusUnresolved
Low

Unused Immutable Variable `drawer`

L-01The `drawer` address is set as an immutable variable in the constructor but is not utilized anywhere within the `SockLaunchToken` contract's current implementation. This may indicate incomplete functionality, a placeholder for future features, or a design oversight.
IssueThe `drawer` address is set as an immutable variable in the constructor but is not utilized anywhere within the `SockLaunchToken` contract's current implementation. This may indicate incomplete functionality, a placeholder for future features, or a design oversight.
FixIf the `drawer` variable is intended for future use, document its purpose clearly. If it is no longer needed, consider removing it to reduce contract complexity and bytecode size. If it is meant to be used, ensure the functionality is implemented as intended.
StatusUnresolved
Info

Centralized Control over Metadata

I-01The `creator()` address has the sole ability to update the `metadataURI` of the token. While this is a common pattern for token metadata management, it represents a centralized point of control for this specific aspect of the token.
IssueThe `creator()` address has the sole ability to update the `metadataURI` of the token. While this is a common pattern for token metadata management, it represents a centralized point of control for this specific aspect of the token.
FixAcknowledge the centralized control over metadata. If decentralization is a long-term goal, consider mechanisms for community governance or multi-signature control over metadata updates in future iterations. For now, ensure the `creator()` address is securely managed.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract implements standard ERC20 and ERC20Permit functionalities, leveraging battle-tested OpenZeppelin libraries for core token operations (7.2 Code Security). The `creator()` function includes robust `try/catch` error handling for external calls, gracefully falling back to `originalCreator`. However, a significant technical risk arises from the dynamic `creator()` logic, which relies on external `ILaunchpadHook` and `ICreatorLookup` contracts to determine the privileged address (7.6 External). This introduces a critical dependency on the security and integrity of these external systems, which are outside the scope of this audit.

GovernanceHigh1/10

The contract's economic model is straightforward, functioning as a standard ERC20 token with initial supply minted to the deployer (7.4 Economic). There are no complex DeFi primitives or staking mechanisms. Governance is minimal, limited to the `creator()` address controlling the `metadataURI` (7.5 Governance). The `drawer` address is immutable but currently unused, which could be a minor design oversight.

UpgradesMedium6/10

The SockLaunchToken contract is not designed as an upgradeable proxy (7.7 Upgrades). It is deployed as a standard, immutable contract, which eliminates upgrade-related risks such as proxy storage collisions or incorrect upgrade paths. This design choice simplifies the contract's lifecycle and reduces the attack surface associated with upgradeability.

Security Checklist

Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

9.1% in wallets13.2% in contracts
Effective Concentration14.3%

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 Holder97.2%
Top-3 Unlocked98.9%

Key Addresses

Deployer
0xf794…384f
Unlocked LP Held By
0xc14c…eead0x7480…1cb80xfd5d…05960xf92f…4a700xddec…cb520x3f3d…120d0x1eed…d9f40x9717…cbe10xb3dc…7ab20xe9a0…cd4c

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

What Raised This Score

  • Ownership status UNKNOWN (owner could not be resolved)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 97.2% (independent LP — depth risk, pool = 85% of DEX liquidity)
  • LP top3 unlocked holders = 98.9% (independent LP — depth risk, pool = 85% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 1 High finding(s) from audit
  • 1 Low 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

Related Audits

mubarakMedium RiskAlaya Governance Token (AGT)Medium RiskCheese Head (CHEESE)Medium RiskAsterMedium RiskTutorial (TUT)Medium RiskMYXMedium Risk

Would You Like a More Detailed Audit of Sock?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit