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

Is usocks a Scam?

USOCKS

Ethereum

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 recordNew Launch · 20h old

Chart

91/ 100

Critical RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical4/10 Governance1/10 Upgrades4/10 Checks passed3 of 5 Findings1 Critical · 2 High · 2 Medium · 1 Low · 1 Info7

SummaryAI Copilot

The USocks contract implements an ERC20 token with integrated NFT reward mechanisms and fee distribution.

Read the full analysis

What raised the score

Ownership status UNKNOWN
Top-10 concentration > 30%
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 74.2%
LP top3 unlocked holders = 100.0%
Token age < 24h
1 Critical finding(s) from audit
2 High finding(s) from audit
2 Medium finding(s) from audit
1 Low finding(s) from audit

Exact factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (81.6% total → 43.2% effective; 17.7% in EOAs, 63.9% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 74.2% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
Token age < 24h (brand new — bot activity, unproven)
1 Critical finding(s) from audit
2 High finding(s) from audit
2 Medium 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

Early-stage analysis. This token has limited on-chain history (20h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 43 of 5 checks passed

Contract verifiedVerified

OwnershipUnknown

MintNo mint

Liquidity lockNot locked

UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

81.6%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking63.9%
Walletsanonymous holders, free to sell17.7%
Everyone elsethe rest of the supply18.4%

Effective concentrationwhat the score reads43.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$113.3K

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$113.3KShare of depth100.0%

Top-1 Unlocked Holder74.2%

Top-3 Unlocked100.0%

Unlocked LP held by

0x73e5…91ad0xf900…098c0xd8d5…d3ca

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

Security Findings

1 Critical2 High2 Medium1 Low1 Info

Critical

Critical: Redirected Buyback Vulnerability

The _tryRedirectedBuybackAfterTransfer function is called after every transfer and transferFrom. If buybackExecutor.buy fails in _payBuyback, the buybackRewardRemainder is added to redirectedBuybackTotal. This accumulated redirectedBuybackTotal is then transferred from the USocks contract's balance to the recipient of *any subsequent token transfer*. This means a user making a small transfer to themselves or a controlled address can claim a potentially large accumulated redirectedBuybackTotal, effectively draining funds intended for buybacks. This creates a severe incentive for users to monitor redirectedBuybackTotal and exploit it.C-01

Issue

Fix

Rework the buyback redirection logic. Instead of redirecting to the next transfer recipient, consider a dedicated claim function for accumulated buyback funds, or ensure redirectedBuybackTotal is handled in a way that prevents arbitrary claiming by any transfer recipient. The redirectedBuybackTotal should be cleared or distributed in a controlled, auditable manner.

Status

Unresolved

High

High: Unexpected Token Burning on Sell

The recordSell function, called by the market, invokes _burnExcess(seller). This internal function burns balanceOf(seller) - amount. This means that when a user sells a specific amount of tokens, any *additional* tokens they hold in their balance beyond that amount are also burned. This is a highly unusual and potentially destructive behavior, as users might not expect their entire balance (minus the sold amount) to be destroyed.H-01

Issue

Fix

Clarify this behavior in documentation and user interfaces, or, preferably, remove the _burnExcess mechanism entirely. If the intent is to enforce a specific balance post-sell, this should be explicitly communicated and potentially opt-in, rather than an automatic burn.

Status

Unresolved

High

High: Reentrancy in ETH Deposit/Distribution

The receive() and depositFees() functions are payable and call _depositFees. _depositFees distributes received ETH to holderDistributionRemainder, pendingOfficial, and pendingBuyback. It then makes external calls to _payHolderDistribution, _payOfficial, and _payBuyback. Critically, _payBuyback calls buybackExecutor.buy{value: amount}(address(this), address(this)). If buybackExecutor, settlement, or official are malicious or compromised contracts, they could re-enter USocks via receive() or depositFees() during these external calls. This could lead to repeated distribution of the same ETH or other state manipulation before the initial _depositFees call…H-02

Issue

Fix

Apply the nonReentrant modifier to depositFees() and ensure receive() is also protected (e.g., by making receive() call a nonReentrant internal function). Thoroughly review all external calls within the ETH distribution logic to ensure no reentrancy vectors exist.

Status

Unresolved

Medium

Medium: Immutability of Critical Dependencies

The market, settlement, official, buybackExecutor, and renderer addresses are set as immutable in the constructor. While this provides certainty, it also means that if any of these external contracts become compromised, deprecated, or require an upgrade, there is no mechanism to update them. This could lead to a permanent failure of core protocol functionalities (e.g., market operations, buybacks, NFT rendering) without the ability to recover or adapt.M-01

Issue

Fix

Consider implementing an upgradeable proxy pattern for the USocks contract itself, or at least for the critical external dependencies, allowing a trusted governance or multisig to update these addresses if necessary. This introduces centralization but provides resilience against external contract failures.

Status

Unresolved

Medium

Medium: Complexity of Reward Distribution Logic

The reward distribution system involving accRewardPerWeight, totalRewardWeight, nftRewardDebt, nftRewardRemainder, nftClaimable, and various internal functions (_settleNft, _updateAccRewardPerWeight, _claimNft) is highly complex. Such intricate logic increases the surface area for subtle bugs, rounding errors, or unintended economic incentives, which can be difficult to identify and verify.M-02

Issue

Fix

Conduct a thorough mathematical review and formal verification of the reward distribution logic to ensure its correctness and fairness under all possible scenarios. Provide comprehensive documentation and unit tests for each component of the reward system.

Status

Unresolved

Low

Low: Precision Loss in Reward Calculations

The reward calculation uses ACCURACY = 1e36 for scaling and division. While large, division operations like (delta + nftRewardRemainder[tokenId]) / ACCURACY inherently involve precision loss if the numerator is not perfectly divisible. Although nftRewardRemainder attempts to capture remainders, repeated calculations over time could lead to minor discrepancies or accumulation of unclaimable dust amounts, potentially impacting the long-term fairness or exactness of rewards.L-01

Issue

Fix

Document the expected precision behavior and potential for dust accumulation. Consider using a fixed-point math library if extreme precision is required, or explicitly state that minor precision losses are an acceptable trade-off for gas efficiency.

Status

Unresolved

Info

Informational: Lack of Emergency Pause/Withdrawal

The contract lacks a mechanism to pause critical operations in an emergency (e.g., a severe vulnerability discovered in a dependency or the USocks contract itself). Additionally, there are no explicit functions for an authorized entity to withdraw accidentally sent or stuck tokens/ETH, although the _depositFees function immediately distributes ETH.I-01

Issue

Fix

Implement a Pausable mechanism (e.g., from OpenZeppelin) for critical functions to allow for emergency halts. Consider adding an emergencyWithdraw function, callable by a trusted multisig, to recover tokens or ETH accidentally sent to the contract, although this should be carefully designed to not interfere with intended protocol operations.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

The USocks contract implements an ERC20 token with integrated NFT reward mechanisms and fee distribution. While utilizing OpenZeppelin libraries and reentrancy guards for some functions, the audit identified critical economic design flaws related to buyback redirection and token burning, alongside a high-severity reentrancy vulnerability in the ETH deposit and distribution logic. Several medium and low-severity issues pertain to the immutability of critical dependencies and the complexity of the reward system. Addressing these core issues is paramount for the security and integrity of the protocol.

Technical4/10Medium risk

The contract leverages OpenZeppelin's ERC20 and ReentrancyGuard, providing a solid foundation for token operations and preventing reentrancy in several key functions (7.2 Code Security). However, a critical reentrancy vulnerability was identified in the _depositFees function, which handles incoming ETH and makes external calls without reentrancy protection (7.2 Code Security). The reward distribution logic is highly complex, increasing the potential for subtle bugs and unintended behavior (7.1 Architecture).

Governance1/10High risk

The economic design contains critical flaws that could lead to significant fund loss or manipulation (7.4 Economic). Specifically, the _tryRedirectedBuybackAfterTransfer function allows any user to claim accumulated buyback funds by performing a simple token transfer, creating a severe drain risk. Additionally, the _burnExcess function unexpectedly burns a seller's entire token balance beyond the sold amount, leading to unintended loss of user funds (7.4 Economic). Critical external dependencies are immutable, limiting adaptability and posing long-term operational risks (7.6 External, 7.8 Operations).

Upgrades4/10Medium risk

The USocks contract is not designed to be upgradeable, as it does not implement a proxy pattern (7.7 Upgrades). This means its logic cannot be modified post-deployment. While this simplifies the contract's lifecycle, the immutability of critical external dependencies (e.g., buybackExecutor, renderer) means that if any of these components require updates or become compromised, the entire USocks system would need redeployment, impacting long-term operational flexibility (7.8 Operations).

Final RecommendationWhat to do about this score

It is critical to immediately address the identified economic vulnerabilities related to redirected buybacks and unexpected token burning.

These design flaws pose an existential threat to user funds and protocol integrity. A thorough review and redesign of the _tryRedirectedBuybackAfterTransfer and _burnExcess mechanisms are essential. Furthermore, the reentrancy vulnerability in the ETH deposit and distribution logic must be patched by applying reentrancy guards to prevent potential fund drains. Consider implementing a more flexible dependency management system or an upgradeable architecture for future resilience.

Contract & Record

1 audit on record

TypeStaking, Token

NetworkEthereum

Token age20h

Contract0x2e43…f7d2

Deployer0x9b8c…31b9

Badge for your website

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

Sep 4, 202691Critical
Aug 13, 202686Critical

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

Frequently Asked Questions

What is the USOCKS contract address?

The usocks contract on Ethereum is 0x2e43e18a19ae896c6f8657ca6285b9672f67f7d2. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.