Quantum Audit Logo
Launch App

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

Is REAL WORLD APPAREL Safe?

JACKETBNB Chain
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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical10/10Governance7/10Upgrades9/10Checks passed4 of 5Findings3 Info3
SummaryAI Copilot

This audit covers the OpenZeppelin Address library, a foundational utility contract.

Read the full analysis
What raised the score
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 50.8%
  • LP top3 unlocked holders = 100.0%
  • Token age < 30 days
Exact factors
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 50.8% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 30 days (still settling)

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 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
8.5%Contracts5.7%Wallets85.8%Everyone else
8.5%5.7%85.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
14.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking8.5%
  • Walletsanonymous holders, free to sell5.7%
  • Everyone elsethe rest of the supply85.8%
Effective concentrationwhat the score reads9.1%
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$136.0K

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$136.0KShare of depth100.0%
Top-1 Unlocked Holder50.8%
Top-3 Unlocked100.0%
Unlocked LP held by
0x12a5…9eab0x8815…288b

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

Security Findings

3 Info
Info

Misinterpretation of isContract for Security Checks

The isContract function, while correctly implemented, has inherent limitations explicitly detailed in its NatSpec documentation. It returns false for contracts in construction, externally-owned accounts (EOAs), and addresses where contracts will be created or have been destroyed. Relying on isContract to prevent calls from contracts (e.g., to protect against flash loan attacks or enforce EOA-only access) is explicitly discouraged by OpenZeppelin, as it breaks composability and can be circumvented (7.2 Code Security).I-01

Issue

The isContract function, while correctly implemented, has inherent limitations explicitly detailed in its NatSpec documentation. It returns false for contracts in construction, externally-owned accounts (EOAs), and addresses where contracts will be created or have been destroyed. Relying on isContract to prevent calls from contracts (e.g., to protect against flash loan attacks or enforce EOA-only access) is explicitly discouraged by OpenZeppelin, as it breaks composability and can be circumvented (7.2 Code Security).

Fix

Developers should avoid using isContract as a primary security mechanism to restrict access or prevent specific types of attacks. Instead, implement robust access control using Ownable, AccessControl, or role-based systems, and design protocols to be resilient to contract interactions rather than trying to block them. For reentrancy protection, use ReentrancyGuard or the checks-effects-interactions pattern.

Status

Unresolved

Info

Reentrancy Risk with External Calls

The sendValue function and functionCallWithValue facilitate external calls that transfer Ether or execute arbitrary code on another contract. The library's documentation explicitly warns about the potential for reentrancy vulnerabilities when using sendValue. While the library itself does not introduce reentrancy, its usage in a calling contract without proper safeguards (e.g., ReentrancyGuard or the checks-effects-interactions pattern) can lead to critical reentrancy exploits (7.2 Code Security).I-02

Issue

The sendValue function and functionCallWithValue facilitate external calls that transfer Ether or execute arbitrary code on another contract. The library's documentation explicitly warns about the potential for reentrancy vulnerabilities when using sendValue. While the library itself does not introduce reentrancy, its usage in a calling contract without proper safeguards (e.g., ReentrancyGuard or the checks-effects-interactions pattern) can lead to critical reentrancy exploits (7.2 Code Security).

Fix

Any contract utilizing sendValue or functionCallWithValue must implement robust reentrancy protection. This typically involves ensuring state changes occur before external calls (checks-effects-interactions pattern) or using a reentrancy guard mechanism like OpenZeppelin's ReentrancyGuard contract. Thoroughly review all functions that perform external calls for reentrancy vulnerabilities.

Status

Unresolved

Info

Implications of Low-Level Call Usage

The Address library provides robust wrappers for low-level call, staticcall, and delegatecall functions. While these wrappers handle error propagation and basic checks, using low-level calls, even wrapped, introduces complexity and potential risks. Developers must fully understand the target contract's behavior, potential side effects, and gas implications of arbitrary calls. Misuse of delegatecall in particular can lead to severe vulnerabilities if the target contract is untrusted or malicious, as it executes code in the context of the calling contract (7.2 Code Security).I-03

Issue

The Address library provides robust wrappers for low-level call, staticcall, and delegatecall functions. While these wrappers handle error propagation and basic checks, using low-level calls, even wrapped, introduces complexity and potential risks. Developers must fully understand the target contract's behavior, potential side effects, and gas implications of arbitrary calls. Misuse of delegatecall in particular can lead to severe vulnerabilities if the target contract is untrusted or malicious, as it executes code in the context of the calling contract (7.2 Code Security).

Fix

When using functionCall, functionStaticCall, or functionDelegateCall, ensure that the target address is trusted and that the data payload is correctly constructed and validated. Exercise extreme caution with functionDelegateCall, as it grants the called contract full control over the calling contract's state. Prefer higher-level Solidity function calls when possible, and only use low-level calls when absolutely necessary and with thorough security analysis.

Status

Unresolved

Analysis

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

This audit covers the OpenZeppelin Address library, a foundational utility contract. The library provides robust and secure wrappers for low-level address interactions, including ETH transfers and arbitrary function calls. No direct vulnerabilities were identified within the library itself, which is a testament to its mature and well-audited design. The primary security considerations for this library relate to how it is integrated and utilized by other contracts, particularly concerning reentrancy and the interpretation of isContract for security-critical logic.

Technical10/10Low risk

The Address library demonstrates high technical quality, adhering to established Solidity best practices and OpenZeppelin's rigorous standards (7.2 Code Security). It provides secure wrappers for low-level calls (sendValue, functionCallWithValue), explicitly mitigating common pitfalls like insufficient gas for transfer and handling call failures. The library includes clear warnings within its NatSpec documentation regarding reentrancy risks and the limitations of isContract (7.1 Architecture). All external calls are properly checked for success, and revert reasons are bubbled up or custom messages are used, enhancing robustness.

Governance7/10Low risk

As a standalone utility library, the Address contract does not implement any direct governance mechanisms or economic models (7.5 Governance, 7.4 Economic). Its functionality is purely technical, providing building blocks for other contracts. Therefore, governance and economic risk levels are not applicable to this specific contract.

Upgrades9/10Low risk

The Address contract is a library, which means it is not directly upgradeable in the same manner as a typical contract (7.7 Upgrades). Once deployed, its code is immutable. Any updates would require deploying a new version of the library and updating all consuming contracts to reference the new address, or for proxy contracts to be re-pointed to new implementations that use an updated library.

Final RecommendationWhat to do about this score

While the OpenZeppelin Address library is inherently secure, consuming contracts must exercise caution when integrating its functionalities.

Developers should pay close attention to the explicit warnings provided in the library's documentation, particularly regarding reentrancy when using sendValue or functionCallWithValue, and the limitations of isContract for access control or security-critical checks. Always follow the checks-effects-interactions pattern when performing external calls.

Contract & Record

1 audit on record
TypeToken
NetworkBNB Chain
Token age10d
Contract0x57ae…ffff
Deployer0x3cc2…7505
Badge for your website
REAL WORLD APPAREL 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. Aug 14, 20261Low

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

Frequently Asked Questions

What is the JACKET contract address?

The REAL WORLD APPAREL (JACKET) contract on BNB Chain is 0x57aedac0ccaafdec0ec62fc4fbfd8252735affff. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is REAL WORLD APPAREL a scam?

Quantum Audit's risk score for REAL WORLD APPAREL is 1/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is JACKET liquidity locked?

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

Who holds JACKET?

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

Related Audits

6 more on the recordAll audits
富贵BNB Chain1LowpricelessBNB Chain1LowDORABNB Chain1LowWangChai旺柴 · BNB Chain1LowCZ's DogBROWNIE · BNB Chain1LowBellwether领头羊 · BNB Chain1Low

Would You Like a More Detailed Audit of REAL WORLD APPAREL?

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