Quantum Audit Logo

Is usocks a Scam?

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

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

usocks USOCKS
0x2e43…f7d2
Ethereum Not verifiedLast checked 3d ago 1 audit on record New Launch · 20h old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

1 Critical2 High2 Medium1 Low1 Informational
! 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.
Volume 24h
$380.4100
Liquidity
$113.3K
Price
$0.0000006817
Token Age
20h
Top 10 Holders
81.6%

Security Findings

1 Crit2 High2 Med1 Low1 Info
Critical

Critical: Redirected Buyback Vulnerability

C-01The `_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.
IssueThe `_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.
FixRework 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.
StatusUnresolved
High

High: Unexpected Token Burning on Sell

H-01The `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.
IssueThe `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.
FixClarify 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.
StatusUnresolved
High

High: Reentrancy in ETH Deposit/Distribution

H-02The `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…
IssueThe `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…
FixApply 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.
StatusUnresolved
Medium

Medium: Immutability of Critical Dependencies

M-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Medium

Medium: Complexity of Reward Distribution Logic

M-02The 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.
IssueThe 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.
FixConduct 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.
StatusUnresolved
Low

Low: Precision Loss in Reward Calculations

L-01The 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.
IssueThe 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.
FixDocument 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.
StatusUnresolved
Info

Informational: Lack of Emergency Pause/Withdrawal

I-01The 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.
IssueThe 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.
FixImplement 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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh1/10

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

UpgradesMedium4/10

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

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

81.6% in top 10
17.7% in wallets63.9% in contracts
Effective Concentration43.2%

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

$113.3K

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

Key Addresses

4 addresses
Deployer
0x9b8c…31b9
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.

What Raised This Score

10 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

Related Audits

6 more on the record
Caldera (ERA)Critical RiskPunkStrategy (PNKSTR)Critical RiskBluzelle Token (BLZ)Critical RiskAllora (ALLO)Critical RiskCOTICritical Riskdmt-natCritical Risk

Would You Like a More Detailed Audit of usocks?

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

Get Detailed Audit