Loading...
LoadingLoading...
LoadingLoading audit report...
WalletGuard.ai, powered by Gestalt Labs
Findings selected for deep verification. Where possible we generated a Solidity proof-of-concept and executed it against a forked mainnet.
contracts/EntropyGenerator/EntropyGenerator.solFunction: writeEntropyBatch1Lines: 47-61contracts/EntropyGenerator/EntropyGenerator.solFunction: writeEntropyBatch1Lines: 47-51contracts/EntropyGenerator/EntropyGenerator.solFunction: initializeAlphaIndicesLines: 140-152contracts/Airdrop/Airdrop.solFunction: claimLines: 74-81contracts/DAOFund/DAOFund.solFunction: receiveLines: 16-26contracts/DAOFund/DAOFund.solFunction: receiveLines: 24-29The analyzed contract suite is a multi-component NFT protocol on Ethereum mainnet (TraitForge), encompassing NFT minting, entropy-based trait generation, forging mechanics, trading, airdrop distribution, and a DAO fund with token burn functionality. The analysis identified 3 critical, 8 high, 9 medium, 6 low, and 2 informational findings after deduplication and severity adjustment. The single most dangerous pattern is the use of entirely predictable, block-number-based pseudo-random entropy generation for NFT traits, combined with unrestricted public access to the entropy batch initialization functions, which allows any actor to manipulate the fundamental fairness properties of every token ever minted. The contract suite presents substantial security risk and should not be deployed to production without addressing the entropy manipulation surface, the tx.origin phishing vector in the airdrop, the broken mintWithBudget loop condition, and the generation-blocking access control failure in initializeAlphaIndices.
Anyone can call the functions that set the random traits for every NFT in the protocol. Because the 'random' values are computed from the block number (which is publicly known before the transaction is included), an attacker can choose exactly which block to call these functions in, pre-computing which traits each future token will have. This means an attacker can guarantee themselves tokens with the best possible stats while everyone else mints blind.
The airdrop contract steals tokens from whoever originally initiated a transaction rather than from the direct caller. A malicious contract can trick the protocol owner into clicking a link or signing something, and that malicious contract quietly calls the airdrop function in the background, draining all of the owner's airdrop tokens without their knowledge.
The batch minting function stops working permanently after the first 10,000 NFTs are minted. Because the code checks a running total against a per-generation limit, once that total exceeds 10,000 the function will silently refund every user's ETH without minting anything. Every user trying to batch-mint in generation 2 or later will lose their gas fees and receive nothing.
2 centralization points identified
Owner can reset alpha indices at any time, manipulating which slot receives the 999999 special value across generations. The onlyOwner restriction limits this to the privileged role but the capability exists without constraint.
initializeAlphaIndices()Owner can set taxCut to 0, which causes division-by-zero in all forging and trading transactions, bricking both contracts. The impact is severe but limited to privileged action by the owner address.
setTaxCut()An attacker first calls writeEntropyBatch1/2/3 (Finding: unprotected batch initialization) at a self-chosen block number, having pre-computed via keccak256(block.number, i) which slot indices produce high forgePotential, isForger status, or desirable nukeFactor values. The attacker then mints tokens immediately after initialization, obtaining only the favorable indices. Because initializeAlphaIndices is also manipulable by the same block-data weakness (Finding: weak on-chain randomness), the attacker can also control which slot receives the special 999999 alpha value. The result is complete, deterministic control over the trait distribution of the entire NFT collection.
When generation 1 fills (10,000 tokens), TraitForgeNft._incrementGeneration() is called, which calls entropyGenerator.initializeAlphaIndices(). Because initializeAlphaIndices requires onlyOwner and TraitForgeNft is not the owner of EntropyGenerator (Finding: initializeAlphaIndices can be called by anyone when contract is not paused), this call reverts. The revert propagates up, causing the generation increment to fail, which causes all subsequent minting to revert. Separately, even if the generation boundary is crossed, mintWithBudget uses a global token counter against a per-generation limit (Finding: mintWithBudget loop condition bug), so batch minting is broken regardless. Together these two issues guarantee a permanent denial of service on minting at the end of generation 1.
The entropy pool holds approximately 10,010 unique values (770 slots x 13 numbers). The protocol supports up to 100,000 tokens (10,000 per generation x 10 generations). Once entropy is exhausted, getNextEntropy wraps currentSlotIndex back to 0 (Finding: entropy reuse on wrap), reusing all trait values from the beginning. Combined with the off-by-one in getEntropy that reads entropySlots[770] (out-of-bounds, Finding: off-by-one in getEntropy), entropy reads near the boundary will revert, causing minting to brick before the wrap even occurs.
EntityForging.listForForging uses forgingCounts[tokenId] <= forgePotential (Finding: off-by-one in forge count). A forger with forgePotential=1 can list at count=0, forge (count becomes 1), be auto-delisted, then re-list because count=1 still satisfies 1<=1, and forge again (count becomes 2). The no-post-increment check in forgeWithListed (Finding: forgerTokenId listing not properly validated) confirms the limit is never re-verified after the increment. Together, a forger can forge an unbounded number of times beyond its design limit, inflating token supply and degrading game economy.
| Agent | Status | Findings | Severity | Confidence | Duration | Coverage |
|---|---|---|---|---|---|---|
| reentrancy | success | 11 | 4H1M1L | 75% | 1.9m | Classic reentrancy (external call before state update) in all contracts, Cross-function reentrancy via shared state mappings, CEI pattern compliance in claim(), nuke(), forgeWithListed(), buyNFT(), ERC-777/ERC-1155 callback patterns, tx.origin usage in Airdrop.startAirdrop(), Uniswap integration in DAOFund (slippage, sandwich attacks), ReentrancyGuard application and correctness, Entropy generation security and predictability, State machine logic in listing/forging/trading, ETH transfer patterns (push vs pull, DoS risks), Integer overflow/underflow in unchecked blocks, Access control on privileged functions, Cross-contract composability risks between NukeFund, Airdrop, TraitForgeNft, EntityForging, Read-only reentrancy risks in view functions |
| access control | success | 10 | 2H2M1L | 84% | 1.6m | Access control on all public/external functions across all contracts, tx.origin usage for authorization, Signature verification patterns, Reentrancy guards on state-changing functions, Initializer protection patterns, Upgradeable contract patterns, delegatecall usage, selfdestruct usage, ERC-721 transfer hooks and callback patterns, Entropy generation randomness and predictability, Fund accounting logic in NukeFund and DevFund, Forging mechanics and count limits, Listing lifecycle in EntityForging and EntityTrading, Airdrop token distribution logic, DAOFund swap slippage protection, Generation increment and price calculation logic, Ownership transfer patterns, Cross-contract interaction security |
| economic | success | 12 | 2H3M | 83% | 2.0m | Flash loan attack vectors on token balance dependencies, Oracle manipulation (no oracle price feeds found - protocol uses internal entropy), MEV and sandwich attack exposure on DAOFund swap, Reentrancy across all contracts (ReentrancyGuard present and used), tx.origin usage in Airdrop.startAirdrop, Integer precision loss in Airdrop.claim reward distribution, Entropy generation predictability and manipulation in EntropyGenerator, Listing state management in EntityForging (mapping cleanup), Forging count validation logic in EntityForging.forgeWithListed, DevFund reward accounting and potential underflow, NukeFund fund accounting and taxCut=0 edge case, TraitForgeNft.mintWithBudget generation boundary logic, Access control on entropy batch write functions, DAOFund slippage protection on Uniswap swap, Governance attack vectors (no governance contract found), Fee-on-transfer token compatibility in Airdrop, First-depositor inflation attacks, Chainlink/Pyth oracle integration (none found) |
| logic validation | success | 13 | 3H1M2L | 84% | 2.3m | Input validation on all function parameters across all contracts, Arithmetic safety including division operations and type downcasts, tx.origin vs msg.sender usage, Reentrancy patterns and CEI ordering, State machine transitions in Airdrop, EntityForging, Access control on privileged functions, Entropy generation randomness and predictability, ERC-4626 patterns (not applicable - ERC721), Uniswap swap parameters (slippage, deadline), Fund accounting in NukeFund and DevFund, Listing lifecycle in EntityForging and EntityTrading, mintWithBudget loop condition correctness, Token generation increment logic, ageMultiplier initialization, forgingCount validation bypass, Division by zero risks in taxCut usage, Array bounds in EntropyGenerator, Merkle proof whitelist bypasses |
| code quality | success | 18 | 1L | 83% | 2.8m | Reentrancy vulnerabilities across all contracts, Access control on sensitive functions, tx.origin usage, Integer overflow/underflow (Solidity 0.8 checked arithmetic), Unchecked downcasts, Oracle manipulation and weak randomness in EntropyGenerator, Slippage protection in DAOFund Uniswap swap, ERC-20 compliance (Trait token), ERC-721 compliance (TraitForgeNft), ERC-721Enumerable compliance, Fund accounting logic in NukeFund and DevFund, Forging mechanics and off-by-one errors, Listing/cancellation state management, Entropy recycling and boundary conditions, Merkle proof whitelist bypass, Generation increment logic, Price calculation correctness, ETH transfer failure handling, CEI pattern violations, Cross-contract interaction risks |
| compiler bugs | success | 8 | 1H1L | 83% | 1.4m | Reentrancy in all nonReentrant-guarded functions, Access control on all owner/admin functions, tx.origin usage in Airdrop.startAirdrop, Entropy generation randomness quality and manipulation surface, Forging count logic and forge potential limit enforcement, DevFund reward accounting and claim logic, NukeFund fund accounting vs actual balance, mintWithBudget loop termination condition, DAOFund swap slippage protection, Merkle proof whitelist bypass conditions, ERC721 transfer hooks and listing cancellation, Integer overflow/underflow in Solidity 0.8.20 (protected by default), Compiler bug patterns for pragma ^0.8.20 (no bugs apply to this version range) |
| assembly safety | success | 15 | 2H2M1L | 83% | 2.7m | Full source code scanned for non-ASCII characters — no non-ASCII characters found in identifiers, function names, or string literals, All assembly{} blocks — none present in any file; confirmed by full source scan, Reentrancy patterns across all contracts (Airdrop, DevFund, EntityForging, EntityTrading, NukeFund, TraitForgeNft), Access control on all public/external functions, Integer arithmetic and precision loss in reward calculations (DevFund, Airdrop, NukeFund), Entropy generation randomness quality (EntropyGenerator), Token listing/cancellation state machine (EntityForging, EntityTrading), tx.origin usage, Uniswap slippage protection (DAOFund), Mint price calculation and generation boundary behavior (TraitForgeNft), Forge potential enforcement at forge time vs list time (EntityForging), Entropy pool exhaustion and wrapping behavior, Fund accounting consistency (NukeFund), Approval check redundancy in nuke() |
| l2 specific | success | 16 | 1H2M | 83% | 2.3m | Airdrop contract: claim logic, startAirdrop tx.origin usage, access control, DevFund contract: reward distribution arithmetic, claim CEI pattern, receive() ETH handling, EntityForging contract: forging count limits, uint8 overflow, listing management, payment distribution, EntityTrading contract: buy/sell flow, listing state management, ETH transfer ordering, EntropyGenerator contract: randomness quality, batch initialization access control, slot index bounds, entropy cycling, NukeFund contract: fund accounting, receive() DoS vectors, nuke() ETH-before-burn ordering, TraitForgeNft contract: mint pricing, mintWithBudget loop condition, generation management, _beforeTokenTransfer, DAOFund contract: sandwich attack on swap, receive() logic, Cross-contract interactions: airdrop state consistency, forging/trading integration with NFT contract, Reentrancy vectors across all contracts, Access control on sensitive functions, Integer arithmetic precision and overflow |
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/cdf4860d-6440-4a26-b9cb-adca289c42a9)
<a href="https://walletguard.ai/audit/cdf4860d-6440-4a26-b9cb-adca289c42a9"> <img src="https://walletguard.ai/api/badge/cdf4860d-6440-4a26-b9cb-adca289c42a9" alt="WalletGuard Audit Badge" /> </a>
Secured by WalletGuard