Quantum Audit Logo

Is Landwolf Safe?

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

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

Landwolf WOLF
0x6746…7e69
Ethereum Not verifiedLast checked 1d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive 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). 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.

1 Medium1 Low2 Informational
Volume 24h
$62.7K
Liquidity
$701.8K
Price
$0.000006668
Token Age
2y
Top 10 Holders
28.5%

Security Findings

1 Med1 Low2 Info
Medium

Complex Assembly in Math Library Functions

M-01The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved
Low

Unchecked Arithmetic for Nonce Increment

L-01The `_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.
IssueThe `_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.
FixExplicitly 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.
StatusUnresolved
Info

Extensive Use of Inline Assembly

I-01The `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.
IssueThe `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.
FixMaintain 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.
StatusUnresolved
Info

`ShortStrings` Fallback Mechanism Requires Careful Management

I-02The `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.
IssueThe `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.
FixEnsure 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.
StatusUnresolved

Category Ratings

TechnicalLow10/10

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

GovernanceLow10/10

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.

UpgradesLow10/10

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.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

28.5% in top 10
21.8% in wallets6.7% in contracts
Effective Concentration24.5%

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

$706.6K across 3 pairs
Uniswap v2WETHanalysed$701.8K99.3%Uniswap v3WETH$2.9K0.4%Curve twoUSDC$1.9K0.3%

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

LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

4 addresses
Deployer
0xfdb3…4b97
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.

What Raised This Score

3 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

Related Audits

6 more on the record
AsteroidLow RiskAmerica Pac (PAC)Low RiskJerry The Turtle By Matt Furie (JYAI)Low RiskNon-Playable Coin (NPC)Low RiskYee Token (YEE)Low RiskPikachuLow Risk

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