TraitForge — disclosed vulnerability reports and payouts

Every publicly disclosed and closed bug bounty report we hold for TraitForge, with our own summary of each finding and a link to the original disclosure.

Reports indexed
17
Total paid
$0
Critical
0
Largest payout
$0

This page collects the 17 closed, publicly disclosed TraitForge reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.

The findings concentrate in Logic error, Integer overflow / underflow, Reentrancy, Access control, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.

Use the vulnerability class links below to compare these findings against the same bug class in other protocols.

What reviewers look for

  • Logic error findings disclosed against TraitForge
  • Integer overflow / underflow findings disclosed against TraitForge
  • Reentrancy findings disclosed against TraitForge
  • Access control findings disclosed against TraitForge

Curated highlights

The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.

mediumLogic errorEVM-Solidity$0

TraitForge: NFTs mature too slowly under default settings.

TraitForge's NukeFund lets holders nuke their NFTs after a three-day maturity window to claim a share of an ETH fund, with each claim scaled by a nuke factor derived partly from the token's age. The age-driven growth is bounded by a configurable constant, defaultNukeFactorIncrease, that shipped so low that even a near-perfect entity gains only ~184 nuke-factor points in 30 days and needs about 4,000 days to fully mature. A Foundry PoC demonstrates the maturation timer is effectively broken, deferring intended fund payouts by well over a decade versus the documented ~30-day design. The sponsor confirmed the finding and recommended raising the constant to at least 33,750.

TraitForgecode4renaSep 13, 2024Open
mediumLogic errorEVM-Solidity$0

TraitForge: A dev will lose rewards if after claiming his rewards he mints an NFT

TraitForge's DevFund::claim() transfers a developer's pending Ether rewards before updating info.rewardDebt, breaking the checks-effects-interactions ordering. If the developer's receiving contract immediately spends the claimed funds to mint an NFT while the airdrop has not started, the minting fees are redirected into DevFund.receive(), which raises totalRewardDebt before claim() finishes. The developer's rewardDebt is then set to that inflated total, so they are recorded as having earned new reward fees they never received, locking them out of a portion of future rewards. The sponsor initially dismissed it and a fellow warden argued it is only QA/user error; no final adjudicated severity is captured in the source.

TraitForgecode4renaSep 13, 2024Open
highLogic errorEVM-Solidity$0

TraitForge: Number of entities in generation can surpass the 10k number

TraitForge's NFT contract tracks how many entities belong to each generation via generationMintCounts. When the generation advances, the incrementGeneration function resets genMintCount for the newly active generation to zero. Because forging can mint an entity into the next generation before that increment fires, those pre-forged entities are wiped from the count once the generation rolls over. The result is an understated per-generation entity ledger that lets the intended 10,000-entity cap per generation be exceeded. The TraitForge team confirmed the finding, with the proposed fix being to stop resetting genMintCount when the generation increments.

TraitForgecode4renaSep 13, 2024Open
highLogic errorEVM-Solidity$0

TraitForge: Incorrect percentage calculation in NukeFund and EntityForging when `taxCut` is changed from default value

TraitForge's NukeFund and EntityForging compute fee shares by integer-dividing an incoming amount by a raw taxCut integer that defaults to 10 (meant as 10%). Because the formula divides by the raw value rather than treating taxCut as a basis-point fraction, changing taxCut away from 10 silently alters the effective fee: setting it to 5 yields a 20% developer cut instead of 5%. This misallocates ETH between the developer address and the fund/forging treasury, distorting the fee economics and producing both unintended losses and gains. A forge test reproduced the discrepancy and the proposed fix moves taxCut to a basis-point scale with an upper-bound guard.

TraitForgecode4renaSep 13, 2024Open
mediumLogic errorEVM-Solidity$0

TraitForge: Each generation should have 1 "Golden God" NFT, but there could be 0

TraitForge stores a precomputed table of 10,010 entropies across 770 slots of 13 concatenated values, from which each generation mints up to 10,000 NFTs. When a generation ends, the owner-only initializeAlphaIndices() pseudo-randomly selects one slot and index to designate the generation's single "Golden God" NFT (entropy 999999). Because the selection can resolve to slot 769 at index positions that fall in the last 10 skipped entropies, the Golden God may be placed beyond the 10,000 mintable NFTs and can never be minted. This breaks the documented invariant that every generation contains exactly one Golden God, silently leaving some generations with zero.

TraitForgecode4renaSep 13, 2024Open
mediumInteger overflow/underflowEVM-Solidity$0

TraitForge: Imprecise token age calculation results in an incorrect nuke factor, causing users to claim the wrong amount

TraitForge's NukeFund.calculateAge() computes a token's age by integer-dividing the elapsed lifetime by seconds-per-day before multiplying by the performance factor and age multiplier. Because Solidity division truncates to whole days, tokens younger than a day compute a zero age and any older token silently forfeits its fractional-day remainder, understating the nuke factor and the claimable amount by roughly 11% in a shown three-day example. The PoC forge test reproduces the deviation and the report ships a fix that multiplies all numerator terms first and performs a single division by seconds-per-year to preserve sub-day precision. The flaw requires no attacker; it is a passive economic loss that reduces every holder's nuke claim.

TraitForgecode4renaSep 13, 2024Open

All reports in this group

Vulnerability classes disclosed here

Related protocol pages