
Loading...
Loading
Loading...
LoadingLoading audit report...

WalletGuard.ai, powered by Gestalt Labs
Forge fork-validation ran but no findings met the threshold for PoC inclusion. See the per-finding "Forge validated" badges in the report below for individual results.
The analyzed contract is a LiquidInfrastructureERC20, an ERC-20 token that manages distributions of revenue from associated NFTs to approved token holders. The analysis identified 0 critical, 8 high, 7 medium, 6 low, and 3 informational findings across 24 total submissions. The most dangerous pattern is the combination of an unbounded holders array with DoS-enabling logic errors in holder management, distribution locking, and a permanently-stuck LockedForDistribution state triggered by any reverting ERC20 transfer, which can render the contract completely inoperable. The contract in its current form carries substantial operational risk and should not be considered safe for production deployment without significant remediation of its distribution, holder management, and state machine logic.
If any ERC20 token used for revenue distribution has a transfer that reverts (rather than returning false), the entire distribution process halts permanently. No transfers, mints, or burns of the infrastructure token are possible until the distribution finishes, and it never will. A single poorly-behaved token or a token that blacklists a recipient can brick the entire contract indefinitely.
Every time tokens are burned, the address zero is added to the list of holders who receive revenue distributions. Over time this list fills with invalid entries. When a distribution runs, the contract will attempt to send tokens to address zero, which can cause the entire distribution to fail, permanently locking the contract and blocking all token operations.
The contract scans every holder in a list every time a token transfer or burn occurs. If thousands of small accounts are created (which anyone can do by transferring tiny amounts), every future transfer becomes too expensive to process and will fail. At sufficient scale, the token becomes completely frozen: no one can transfer, mint, or burn.
1 centralization point identified
Near-duplicate of Finding 8. The permissionless nature of this function is a design property buyers should understand; it does not directly cause fund loss but enables state manipulation and event spoofing.
withdrawFromManagedNFTs()Finding 2 (address(0) pushed to holders on every burn) causes the holders array to grow with invalid entries. Finding 3 (missing break in removal loop) means duplicates are never properly cleaned up. Finding 4 (unbounded iteration) compounds the gas cost as the array grows. When distribution eventually runs against this corrupted array, Finding 16 (reverting ERC20 transfer permanently blocks distribution) triggers if any token reverts on transfer to address(0), permanently setting LockedForDistribution to true. At this point, all mints, burns, and transfers are frozen with no recovery path.
Finding 10 (distribute() is publicly callable) allows any address to initiate a distribution and set LockedForDistribution to true whenever the minimum period has elapsed. Finding 5 (mintAndDistribute bypass) shows that if distribute() is called with numDistributions=1 by an attacker just before the owner calls mintAndDistribute(), the partial distribution leaves LockedForDistribution active. The owner's subsequent mint() call inside mintAndDistribute() then reverts because _beforeTokenTransfer checks LockedForDistribution. An attacker can repeatedly front-run mint operations, preventing the owner from ever minting until a full distribution completes, which itself may be blocked by Finding 16.
Finding 8 (withdrawFromManagedNFTs has no access control) allows anyone to partially advance nextWithdrawal. Finding 6 (releaseManagedNFT always passes its require) means an NFT can be released without being removed from ManagedNFTs, shrinking the array. Finding 15 (nextWithdrawal not reset on array length change) means nextWithdrawal can exceed ManagedNFTs.length after a release, causing the reset condition to never trigger. The result is that future withdrawal cycles never emit WithdrawalFinished, the distribution cycle stalls waiting for withdrawals, and the protocol cannot function normally.
| Agent | Status | Findings | Severity | Confidence | Duration | Coverage |
|---|---|---|---|---|---|---|
| reentrancy | success | 7 | 4H | 88% | 1.3m | Cross-function reentrancy in distribute(), mint(), burn(), and compound functions, ERC-777 tokensReceived callback attack surface via distributableERC20s, CEI (Checks-Effects-Interactions) pattern compliance in distribute(), holders[] array management in _beforeTokenTransfer and _afterTokenTransfer, Distribution state machine correctness (LockedForDistribution, nextDistributionRecipient), Withdrawal logic in withdrawFromManagedNFTs and LiquidInfrastructureNFT._withdrawBalancesTo, Access control on sensitive functions (onlyOwner, onlyOwnerOrApproved), releaseManagedNFT correctness and NFT transfer before state update, Integer precision loss in _beginDistribution entitlement calculation, ReentrancyGuard placement and coverage across all external-call functions, DoS via unbounded array iteration in _afterTokenTransfer, Read-only reentrancy on view functions (getThresholds, totalSupply), ERC-1155 callback patterns - not present in this contract, Flash loan callback patterns - not present in this contract |
| access control | success | 9 | 2M | 88% | 1.5m | Access control on all public/external functions, Holder array management in _beforeTokenTransfer and _afterTokenTransfer, Distribution logic including entitlement calculation and distribution loop, Withdrawal logic and state management, Reentrancy protection (nonReentrant usage), Signature/authentication patterns (none present), Upgrade safety (no proxy pattern), Integer overflow/underflow (Solidity 0.8.12 with built-in checks), Precision loss in division, DoS via unbounded loops, Test contract security boundaries, releaseManagedNFT correctness, Two-step ownership transfer (Ownable without two-step) |
| economic | success | 10 | 2M1L | 85% | 1.7m | Flash loan attack vectors - no price feeds or balance-based pricing found, not applicable, Oracle manipulation - no price oracles used in this contract, Governance attacks - no governance token voting mechanism present, MEV/sandwich exposure - no swaps or liquidations present, Reentrancy - nonReentrant guards checked on mint and releaseManagedNFT, distribute lacks guard but state is updated before external calls, Holder array management - linear search, unbounded growth, duplicate entries, address(0) insertion, Distribution entitlement math - integer division, precision loss, failed transfer handling, Distribution lifecycle - locking mechanism, begin/end distribution, partial distribution, NFT management - addManagedNFT, releaseManagedNFT correctness, Withdrawal cycle - nextWithdrawal counter, access control, index management, Access control - owner-only functions, permissionless functions, ERC20 compliance - _beforeTokenTransfer, _afterTokenTransfer hooks, Test contracts (TestERC20A/B/C, TestERC721A) - unrestricted mint in TestERC20A noted but test-only |
| logic validation | success | 10 | 2H3M1L | 85% | 1.7m | Input validation on all public/external functions, holders array management in _beforeTokenTransfer and _afterTokenTransfer, Distribution state machine (LockedForDistribution, nextDistributionRecipient), Withdrawal state machine (nextWithdrawal, ManagedNFTs modification during withdrawal), Arithmetic precision in entitlement calculation (division before multiplication), Integer overflow/underflow in unchecked blocks (none found), ERC20 transfer failure handling in distribute(), Access control on administrative functions, Reentrancy protection coverage across mint, burn, distribute, withdraw, releaseManagedNFT logic correctness, address(0) handling in token transfer hooks, Gas DoS vectors in loops, OwnableApprovableERC721 modifier correctness, LiquidInfrastructureNFT withdrawal access control, Test contract files (informational only, no production vulnerabilities) |
| code quality | success | 11 | 1L | 89% | 1.5m | ERC-20 conformance (transfer, transferFrom, approve, events), ERC-721 conformance (LiquidInfrastructureNFT functions and events), ERC-165 supportsInterface, Reentrancy vectors in distribute, mint, withdraw functions, Access control on owner-only and holder-management functions, Distribution logic: entitlement calculation, precision loss, holder list management, Holder array integrity (add/remove on transfer/mint/burn), Integer overflow/underflow (Solidity 0.8.12 built-in protections), Gas optimization: external vs internal calls, loop patterns, Withdrawal logic from ManagedNFTs, Dead code: require(true, ...) in releaseManagedNFT, Test contracts for production safety risks, OwnableApprovableERC721 access control modifiers, Proxy/upgrade patterns - none present |
| compiler bugs | success | 7 | 1H | 90% | 1.0m | Reentrancy patterns in distribute(), mint(), releaseManagedNFT(), Access control on all public/external functions, Holders array management in _beforeTokenTransfer and _afterTokenTransfer, Distribution entitlement calculation and integer division precision, Withdrawal flow ordering relative to distribution, LockedForDistribution state machine transitions, releaseManagedNFT correctness check, Compiler version (0.8.12) - no known compiler bugs applicable, ERC20/ERC721 standard compliance, Integer overflow/underflow (Solidity 0.8.x built-in protection), Dust/remainder accumulation in distribution, DoS via unbounded loops |
| assembly safety | success | 9 | 1H2L | 85% | 1.7m | Full codepoint scan for non-ASCII characters in all identifiers, strings, and comments — none found, Absence of assembly{} blocks confirmed across all files, holders array growth and shrinkage logic in _beforeTokenTransfer and _afterTokenTransfer, Distribution logic in distribute(), _beginDistribution(), _endDistribution(), releaseManagedNFT dead require(true) check, mintAndDistribute and burnAndDistribute reentrancy and griefing paths, Integer division truncation in entitlement calculation, withdrawFromManagedNFTs state machine and interaction with array modifications, setDistributableERC20s mid-distribution mutation, Access control on all public/external functions, TestERC20A unrestricted mint(), OwnableApprovableERC721 modifier logic, LiquidInfrastructureNFT withdrawal access control, ERC20 standard compliance and _beforeTokenTransfer/_afterTokenTransfer hooks, ReentrancyGuard application on mint() and releaseManagedNFT(), Keyword and identifier homoglyph scan — no suspicious characters found |
| l2 specific | success | 10 | 1H1M1L | 89% | 1.5m | Reentrancy vulnerabilities in distribute(), mint(), releaseManagedNFT(), Access control on all public/external functions, Holders array management in _beforeTokenTransfer and _afterTokenTransfer, Distribution logic in _beginDistribution, distribute, _endDistribution, Integer overflow/underflow and precision loss in entitlement calculation, NFT withdrawal logic and state consistency in withdrawFromManagedNFTs, ERC20 transfer failure handling in distribute(), Lock state (LockedForDistribution) consistency across all code paths, MintAndDistribute, burnAndDistribute, burnFromAndDistribute convenience functions, TestERC20A/B/C deployment risk on mainnet, OwnableApprovableERC721 modifier correctness, LiquidInfrastructureNFT withdrawBalances and threshold management, L2-specific concerns (block.number timing, chain ID) |
This automated audit has inherent limitations. The following areas are not covered.
This report is an automated point-in-time assessment and does not guarantee protection against all possible attacks. It does not cover off-chain components, economic modeling, or business logic correctness unless explicitly noted. Changes to the contract after the audit commit are not reviewed. This is not financial or legal advice. WalletGuard, powered by Gestalt Labs, provides this analysis as-is with no warranty of completeness.
[](https://walletguard.ai/audit/6a49b9d8-ffd6-460c-b8b3-a2b34fc88cd3)
<a href="https://walletguard.ai/audit/6a49b9d8-ffd6-460c-b8b3-a2b34fc88cd3"> <img src="https://walletguard.ai/api/badge/6a49b9d8-ffd6-460c-b8b3-a2b34fc88cd3" alt="WalletGuard Audit Badge" /> </a>