Quantum Audit Logo
Launch App

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

Is Landwolf Safe?

WOLFEthereum
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 5, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical10/10Governance10/10Upgrades10/10Checks passed7 of 7Findings1 Medium · 1 Low · 2 Info4
SummaryAI Copilot

The audited codebase consists of several foundational utility libraries (Math, SignedMath, ShortStrings, StorageSlot) and an abstract contract (Nonces), along with an interface (IERC5267).

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (28.5% total → 24.5% effective; 21.8% in EOAs, 6.7% in contracts — mild)
  • 1 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

Security Checklist

as of audit · Sep 57 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 5, 2026
6.7%Contracts21.8%Wallets71.5%Everyone else
6.7%21.8%Wallets71.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
28.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking6.7%
  • Walletsanonymous holders, free to sell21.8%
  • Everyone elsethe rest of the supply71.5%
Effective concentrationwhat the score reads24.5%
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 5, 2026

Liquidity

as of audit · Sep 5$706.6K across 3 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$701.8KShare of depth99.3%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
Unlocked LP held by
0xb3ac…68a00x0000…8a900x1f2f…f387

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

Security Findings

1 Medium1 Low2 Info
Medium

Complex Assembly in Math Library Functions

The mulDiv and sqrt functions within the Math library utilize complex inline assembly and unchecked blocks for performance optimization. While these are often optimized implementations, they are inherently harder to audit, verify, and more prone to subtle errors than pure Solidity code. Any miscalculation or edge case not fully accounted for in the assembly could lead to incorrect results in critical arithmetic operations.M-01

Issue

The mulDiv and sqrt functions within the Math library utilize complex inline assembly and unchecked blocks for performance optimization. While these are often optimized implementations, they are inherently harder to audit, verify, and more prone to subtle errors than pure Solidity code. Any miscalculation or edge case not fully accounted for in the assembly could lead to incorrect results in critical arithmetic operations.

Fix

Ensure extensive unit testing, including fuzz testing, for all functions involving inline assembly, especially mulDiv and sqrt, to cover all possible input ranges and edge cases. Consider adding comprehensive comments to explain the assembly logic clearly. If possible, explore alternative pure Solidity implementations for critical sections to improve readability and auditability, even if it means a slight performance trade-off.

Status

Unresolved

Low

Unchecked Arithmetic for Nonce Increment

The _useNonce function in the Nonces abstract contract uses unchecked for the _nonces[owner]++ operation. While this is acceptable for nonces, as a uint256 wrapping around is not a security concern for this specific use case (it simply resets the nonce count after 2^256 increments), it deviates from the default checked arithmetic introduced in Solidity 0.8.x. This could be a point of confusion for auditors or developers unfamiliar with the specific design choice.L-01

Issue

The _useNonce function in the Nonces abstract contract uses unchecked for the _nonces[owner]++ operation. While this is acceptable for nonces, as a uint256 wrapping around is not a security concern for this specific use case (it simply resets the nonce count after 2^256 increments), it deviates from the default checked arithmetic introduced in Solidity 0.8.x. This could be a point of confusion for auditors or developers unfamiliar with the specific design choice.

Fix

Explicitly document the rationale behind using unchecked for nonce increments to clarify that overflow is an expected and non-critical behavior in this context. No code change is strictly required if the design intent is clear and understood.

Status

Unresolved

Info

Extensive Use of Inline Assembly

The StorageSlot, ShortStrings, and Math libraries make extensive use of inline assembly. While necessary for certain low-level optimizations, direct storage manipulation, or specific string encoding, it significantly increases the complexity of the codebase. Assembly code is less readable, harder to debug, and more prone to subtle errors compared to high-level Solidity, requiring specialized expertise for thorough verification.I-01

Issue

The StorageSlot, ShortStrings, and Math libraries make extensive use of inline assembly. While necessary for certain low-level optimizations, direct storage manipulation, or specific string encoding, it significantly increases the complexity of the codebase. Assembly code is less readable, harder to debug, and more prone to subtle errors compared to high-level Solidity, requiring specialized expertise for thorough verification.

Fix

Maintain comprehensive documentation and comments for all assembly blocks, explaining their purpose and logic. Ensure that developers working with these contracts have a strong understanding of EVM assembly. Rigorous testing is crucial to mitigate the increased risk associated with assembly code.

Status

Unresolved

Info

ShortStrings Fallback Mechanism Requires Careful Management

The ShortStrings library implements an efficient fallback mechanism for strings longer than 31 bytes by storing them in a separate string storage slot. While this is a clever design pattern to optimize gas costs for short strings, it requires the consuming contract to carefully manage the associated string storage variable. Incorrect management (e.g., not providing a dedicated storage slot or reusing a slot for different purposes) could lead to storage collisions or unexpected behavior.I-02

Issue

The ShortStrings library implements an efficient fallback mechanism for strings longer than 31 bytes by storing them in a separate string storage slot. While this is a clever design pattern to optimize gas costs for short strings, it requires the consuming contract to carefully manage the associated string storage variable. Incorrect management (e.g., not providing a dedicated storage slot or reusing a slot for different purposes) could lead to storage collisions or unexpected behavior.

Fix

Ensure that any contract utilizing ShortStrings.toShortStringWithFallback and toStringWithFallback allocates a dedicated and unique string storage variable for the fallback mechanism. Document this requirement clearly for developers integrating the library to prevent potential storage-related issues.

Status

Unresolved

Analysis

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

The audited codebase consists of several foundational utility libraries (Math, SignedMath, ShortStrings, StorageSlot) and an abstract contract (Nonces), along with an interface (IERC5267). These components are designed for efficient, low-level operations, including complex arithmetic, storage manipulation, and nonce management. The code demonstrates a strong understanding of Solidity's capabilities, including extensive use of inline assembly and unchecked blocks for performance optimization. While generally well-structured, the complexity introduced by inline assembly and specific unchecked operations warrants careful review.

Technical10/10Low risk

The codebase comprises well-structured utility libraries and an abstract contract, demonstrating robust design patterns for common operations like nonce management, string handling, and advanced mathematical calculations. Strengths include explicit overflow/underflow checks in Math.try* functions and efficient storage slot manipulation via StorageSlot (7.1 Architecture). However, the extensive use of inline assembly in Math.mulDiv, Math.sqrt, StorageSlot, and ShortStrings introduces significant complexity, increasing the potential for subtle bugs and making verification more challenging (7.2 Code Security). The Nonces contract uses unchecked for incrementing nonces, which is acceptable but deviates from default safety (7.2 Code Security).

Governance10/10Low risk

The provided contracts are foundational utility components and do not implement specific governance or economic mechanisms. Therefore, direct governance or economic risks are not applicable to this codebase (7.4 Economic, 7.5 Governance). Their security impact would be indirect, affecting any higher-level protocol that integrates them, rather than inherent to these contracts themselves.

Upgrades10/10Low risk

The contracts themselves are not designed for direct upgradeability. However, the StorageSlot library provides primitives for direct storage manipulation, which is a common pattern in upgradeable proxy implementations. If these libraries are intended to be used within an upgradeable system, careful consideration of storage slot consistency and potential collisions is paramount (7.7 Upgrades). No explicit upgrade mechanisms are present in the provided code.

Final RecommendationWhat to do about this score

Thoroughly review and test all functions utilizing inline assembly, especially Math.mulDiv and Math.sqrt, to ensure correctness across all edge cases and potential environments.

Implement comprehensive unit and integration tests for all utility functions, particularly those involving unchecked arithmetic or direct storage manipulation, to confirm their behavior under various conditions. If these libraries are integrated into an upgradeable system, ensure that the use of StorageSlot aligns with the proxy's storage layout to prevent storage collisions or data corruption.

Contract & Record

1 audit on record
TypeSolidity 0.8.25
NetworkEthereum
Token age2y
Contract0x6746…7e69
Deployer0xfdb3…4b97
Badge for your website
Landwolf 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 5, 20260Low

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

Frequently Asked Questions

What is the WOLF contract address?

The Landwolf (WOLF) contract on Ethereum is 0x67466be17df832165f8c80a5a120ccc652bd7e69. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Landwolf a scam?

Quantum Audit's risk score for Landwolf is 0/100 (Low risk) as of Sep 5, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: 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 WOLF liquidity locked?

Liquidity lock: Locked (as of Sep 5, 2026). Total DEX liquidity: $706.6K.

Who holds WOLF?

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

Related Audits

6 more on the recordAll audits
AsteroidEthereum0LowAmerica PacPAC · Ethereum0LowJerry The Turtle By Matt FurieJYAI · Ethereum0LowNon-Playable CoinNPC · Ethereum0LowYee TokenYEE · Ethereum0LowPikachuEthereum0Low

Would You Like a More Detailed Audit of Landwolf?

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