Quantum Audit Logo

Is WINR Safe?

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

WINR WINR
0xd77b…a46e
Arbitrum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The WINR token contract implements a standard ERC20 token with custom minting and burning functionalities. It utilizes OpenZeppelin's AccessControl for role-based permissions. A significant vulnerability was identified in the `burn` function, where `MAX_SUPPLY` is reduced by the burned amount, leading to potential integer underflow and unintended tokenomics. Centralized control by the `DEFAULT_ADMIN_ROLE` also presents a medium risk.

1 High1 Medium1 Informational
Volume 24h
$14.5K
Liquidity
$108.2K
Price
$0.002863
Token Age
1y
Top 10 Holders
70.7%

Security Findings

1 High1 Med1 Info
High

`MAX_SUPPLY` Underflow and Economic Manipulation in `burn` Function

H-01The `burn` function allows any user to burn their tokens, and critically, it also decrements the `MAX_SUPPLY` variable by the burned amount (`MAX_SUPPLY -= amount`). This introduces two significant issues: 1. **Integer Underflow:** If the current `MAX_SUPPLY` is less than the `amount` a user attempts to burn, the subtraction `MAX_SUPPLY -= amount` will cause an integer underflow, leading to a transaction revert. This effectively creates a denial of service for users attempting to burn tokens under certain conditions. 2. **Economic Manipulation:** The `MAX_SUPPLY` variable is intended to represent the absolute maximum number of tokens that can ever exist. Allowing any user to reduce this c…
IssueThe `burn` function allows any user to burn their tokens, and critically, it also decrements the `MAX_SUPPLY` variable by the burned amount (`MAX_SUPPLY -= amount`). This introduces two significant issues: 1. **Integer Underflow:** If the current `MAX_SUPPLY` is less than the `amount` a user attempts to burn, the subtraction `MAX_SUPPLY -= amount` will cause an integer underflow, leading to a transaction revert. This effectively creates a denial of service for users attempting to burn tokens under certain conditions. 2. **Economic Manipulation:** The `MAX_SUPPLY` variable is intended to represent the absolute maximum number of tokens that can ever exist. Allowing any user to reduce this c…
FixRemove the line `MAX_SUPPLY -= amount` from the `burn` function. The `MAX_SUPPLY` should remain a fixed, global cap on the total supply and not be affected by individual token burns. If a mechanism to adjust the maximum supply is desired, it should be implemented as a separate, privileged function accessible only by a trusted role (e.g., `DEFAULT_ADMIN_ROLE`) and with careful consideration of its implications.
StatusUnresolved
Medium

Centralized Control by `DEFAULT_ADMIN_ROLE`

M-01The contract relies on OpenZeppelin's `AccessControl` for managing permissions. The `DEFAULT_ADMIN_ROLE` has the power to grant and revoke all other roles, including the `MINTER_ROLE`. This centralizes significant control over the token's minting capabilities and overall access management to a single address or a small group of addresses. A compromise of this admin key could lead to unauthorized minting or manipulation of roles.
IssueThe contract relies on OpenZeppelin's `AccessControl` for managing permissions. The `DEFAULT_ADMIN_ROLE` has the power to grant and revoke all other roles, including the `MINTER_ROLE`. This centralizes significant control over the token's minting capabilities and overall access management to a single address or a small group of addresses. A compromise of this admin key could lead to unauthorized minting or manipulation of roles.
FixImplement a robust security strategy for the `DEFAULT_ADMIN_ROLE`. This could involve using a multi-signature wallet (e.g., Gnosis Safe) to manage the admin key, or integrating with a decentralized governance system. Consider implementing a time-lock for critical administrative actions to provide a window for community review or emergency intervention.
StatusUnresolved
Info

Lack of Pause Mechanism

I-01The contract does not include a mechanism to pause token transfers or other critical operations in case of an emergency, such as a discovered vulnerability, a major exploit in an integrated protocol, or market instability. In such scenarios, the inability to halt operations could exacerbate losses or allow an attack to continue unchecked.
IssueThe contract does not include a mechanism to pause token transfers or other critical operations in case of an emergency, such as a discovered vulnerability, a major exploit in an integrated protocol, or market instability. In such scenarios, the inability to halt operations could exacerbate losses or allow an attack to continue unchecked.
FixConsider integrating a pause mechanism, such as OpenZeppelin's `Pausable` contract. This would allow a designated role (e.g., a `PAUSER_ROLE` managed by the admin or a governance contract) to temporarily halt token operations. This mechanism should be used judiciously and ideally be subject to governance control or a time-lock.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract is built on OpenZeppelin's robust ERC20 and AccessControl libraries, providing a solid foundation for token functionality and role-based access. The `mint` function correctly implements a check against `MAX_SUPPLY` to prevent over-minting (7.2 Code Security). However, the `burn` function directly decrements `MAX_SUPPLY` by the burned amount, which can lead to an integer underflow if `MAX_SUPPLY` is less than the burn amount, causing transaction reverts and a denial of service for burning (7.2 Code Security). This also fundamentally alters the intended token supply cap (7.1 Architecture).

GovernanceHigh1/10

The contract employs a role-based access control system, with a `MINTER_ROLE` for minting and a `DEFAULT_ADMIN_ROLE` managing all other roles (7.3 Access Control). This centralized control allows the admin to manage minting permissions. A critical economic flaw exists where the `MAX_SUPPLY` can be arbitrarily reduced by any user burning tokens, which deviates from typical fixed-supply tokenomics and could lead to an unintended reduction in the total potential supply (7.4 Economic).

UpgradesHigh3/10

The WINR contract is not designed with upgradeability in mind, as it does not implement any proxy patterns (7.7 Upgrades). This means that any future changes or bug fixes would require a new contract deployment and a migration of tokens, which can be a complex and costly process. For a non-upgradeable token, this is an expected design choice.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

70.7% in top 10
4.0% in wallets66.7% in contracts
Effective Concentration30.7%

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

$122.0K across 4 pairs
Camelot v3USDCanalysed$108.2K88.7%UniswapWETH$13.1K10.7%CamelotUSDC$6880.6%Camelot v3WETH$470.0%

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

Key Addresses

4 addresses
Deployer
0xd7ec…0b26
Unlocked LP Held By
0x6cd3…cf570xa0c8…1b100x7884…af81

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

What Raised This Score

8 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (70.7% total → 30.7% effective; 4.0% in EOAs, 66.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.3% (independent LP — depth risk, pool = 89% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 89% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium 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
NolaHigh RiskGains Network (GNS)High RiskNOXCAT (NOX)High RiskMAGICHigh RiskWrapped BTC (WBTC)High RiskEspresso (ESP)High Risk

Would You Like a More Detailed Audit of WINR?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit