Quantum Audit Logo
Launch App

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

Is WINR Safe?

Arbitrum
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 record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance1/10Upgrades3/10Checks passed4 of 7Findings1 High · 1 Medium · 1 Info3
SummaryAI Copilot

The WINR token contract implements a standard ERC20 token with custom minting and burning functionalities.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.3%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 44 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
66.7%Contracts4.0%29.3%Everyone else
66.7%Contracts29.3%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
70.7%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking66.7%
  • Walletsanonymous holders, free to sell4.0%
  • Everyone elsethe rest of the supply29.3%
Effective concentrationwhat the score reads30.7%
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$122.0K across 4 pairs

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$108.2KShare of depth88.7%
Top-1 Unlocked Holder99.3%
Top-3 Unlocked100.0%
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.

Security Findings

1 High1 Medium1 Info
High

MAX_SUPPLY Underflow and Economic Manipulation in burn Function

The 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…H-01

Issue

The 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…

Fix

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

Status

Unresolved

Medium

Centralized Control by DEFAULT_ADMIN_ROLE

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Info

Lack of Pause Mechanism

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

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical7/10Low risk

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

Governance1/10High risk

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

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

Address the critical vulnerability in the burn function by removing the MAX_SUPPLY -= amount line.

MAX_SUPPLY should represent a fixed, absolute maximum and not be modifiable by user burns. If a dynamic maximum supply is desired, a separate, privileged function should be implemented for its adjustment. Consider implementing a pause mechanism to halt critical operations in emergencies. Ensure the DEFAULT_ADMIN_ROLE is managed securely, potentially through a multi-signature wallet or a time-locked governance contract.

Contract & Record

1 audit on record
TypeToken
NetworkArbitrum
Token age1y
Contract0xd77b…a46e
Deployer0xd7ec…0b26
Badge for your website
WINR security record badge

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
  1. Sep 2, 202660Medium

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

Frequently Asked Questions

What is the WINR contract address?

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

Is WINR a scam?

Quantum Audit's risk score for WINR is 60/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is WINR liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $122.0K.

Who holds WINR?

As of Sep 4, 2026, the 10 largest holders own 70.7% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
NolaArbitrum60MediumGains NetworkGNS · Arbitrum60MediumNOXCATNOX · Arbitrum58MediumMAGICArbitrum58Mediumether.fi governance tokenETHFI · Arbitrum58MediumUniswapUNI · Arbitrum62Medium

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 Is this your token? Publish your own audit on this page