Need4Audits Case Study with PashovAI and NemesisAI
AI-Powered Smart Contract Auditing in Practice: A Need4Audits Case Study with PashovAI and NemesisAI
Source Reports
Findings Summary (Normalized)
The severities below are normalized from the two report files so this audit page can render structured severity totals (Critical/High/Medium/Low) like the other audit pages.
Escrow Treasury Fee Accounting Drift Can Create Phantom Balances
Severity: High
payoutTreasuryFee can transfer treasury-share funds without decrementing the relevant internal accounting path, which can leave balances overstated and break later payout assumptions.
finalizeAndPay Status Gating Allows Unsafe Closure and Payment Paths
Severity: High
The status gate uses negative exclusions instead of a strict allowlist, allowing exploitable flows such as premature closure, second-opinion bypass, escalation denial, and potential repeated judge-fee payout conditions.
Duplicate Severity Inputs Can Inflate Required Deposits and Trap Capital
Severity: Medium
Duplicate severity entries in program configuration can inflate total required deposits while only one final severity value remains active, causing avoidable capital lock.
Invalidation Path Leaves Judge-Fee Distribution Incomplete
Severity: Medium
For second-opinion invalidation outcomes, the payment path can leave expected judge compensation unreachable, creating incentive and accounting inconsistencies.
Escalation Finalization Missing Fresh Judge Allowlist Validation
Severity: Low
Escalation finalization does not consistently re-check judge allowlist status at execution time, so a removed judge may still finalize an in-progress escalation in specific conditions.
Penalty Distribution Rounding Enables Micro-Deposit Griefing
Severity: Low
Very small penalty repayment amounts can round unevenly and skew share allocation, enabling low-cost griefing against intended distribution behavior.
Summary
Artificial intelligence is quickly becoming part of the modern smart contract security workflow. What started as experimental linting and pattern matching has evolved into a new class of AI smart contract audit tools that can reason about control flow, state transitions, accounting logic, and protocol invariants. For Web3 teams shipping faster than ever, that matters.
In decentralized systems, a single missed edge case can freeze bounty funds, misroute judge fees, or break dispute resolution. That is exactly why automated smart contract security is gaining traction among auditors, protocol teams, and bug bounty hunters. AI tools are not replacing deep manual review, but they are increasingly effective at surfacing risky logic paths early, accelerating triage, and helping reviewers focus on the most security-critical parts of a codebase.
To explore how useful these tools really are in a real audit workflow, I tested PashovAI and NemesisAI against the Need4Audits protocol, an onchain bug bounty payout system built around escrowed funds, judge-based decisions, and dispute resolution. The process was intentionally sequential: first run PashovAI, fix the vulnerabilities it identified, and then run NemesisAI on the patched contracts to see what additional issues could still be detected. That made the exercise especially useful as a case study in AI bug bounty analysis and smart contract vulnerability detection in a decentralized bug bounty environment.
What Need4Audits Actually Does
Need4Audits is not a simple “pay a bounty from a wallet” design. It is a more structured decentralized bug bounty protocol with multiple actors and contract layers. At a high level, the architecture looks like this:
- BountyProgramRegistry acts as the source of truth for bounty programs, including payout token, severity schedules, fees, penalties, and lifecycle state.
- EscrowVault holds the funds, splitting deposits into bounty pool, judge fee pool, and treasury fee.
- ReportManager handles the report state machine and stores judge assignments, statuses, timelocks, escalations, and final outcomes.
- JudgeRegistry maintains the judge allowlist.
- PayoutController coordinates approval, escalation, second opinion, penalties, and final payout execution.
That makes Need4Audits a strong target for AI analysis because it contains exactly the kinds of logic that LLM-based security tooling often struggles with and sometimes excels at: multi-contract coordination, stateful dispute flows, token accounting assumptions, and payout edge cases. In other words, it is a realistic environment for testing Web3 security tools under conditions that go beyond isolated Solidity bugs.
Why Decentralized Bug Bounty Protocols Are Security-Critical
Traditional bug bounties are largely operational. A platform receives a report, triages it, and pays out offchain. Need4Audits moves meaningful parts of that process onchain: fund custody, severity-linked payouts, judge compensation, dispute resolution, escalation logic, and refund paths.
That creates a stronger trust model, but it also introduces more protocol risk. If the smart contracts mishandle status transitions or token accounting, the bug bounty system itself can become unsafe. A protocol designed to reward valid vulnerabilities could end up trapping funds, bypassing dispute rights, or paying the wrong party.
This is where AI smart contract audit workflows become compelling. They can quickly scan for patterns that human reviewers also care deeply about:
- invalid state transitions
- broken payout assumptions
- escrow accounting drift
- insufficient validation around judge decisions
- unsupported token behaviors such as fee-on-transfer or rebasing
The Need4Audits case makes that concrete.
The AI Audit Workflow: PashovAI First, NemesisAI Second
The workflow was simple but deliberate.
Step 1: Run PashovAI on the Original Contracts
The first pass used PashovAI across the Need4Audits contracts. Its report surfaced a mix of accounting flaws, token handling issues, and payout-path vulnerabilities. Several findings were high-confidence and directly tied to protocol safety.
Among the most important findings were:
- treasury payout accounting that did not decrement internal balances correctly
- duplicate severity configuration inflating required deposits
- rounding-based penalty griefing via micro-deposits
- multiple lower-confidence but still meaningful issues around
finalizeAndPay, escalation handling, and rebasing-token behavior
One of the strongest examples was an escrow accounting flaw in payoutTreasuryFee. According to the PashovAI report, treasury transfers could leave internal bounty balances overstated, creating “phantom” accounting and eventual payout failures. In a protocol that depends on escrow integrity, that is a serious design-level issue, not a cosmetic bug.
Step 2: Fix the PashovAI Findings
After reviewing the first report, I patched the identified vulnerabilities before moving to the second tool. This is an important detail. The goal was not just to compare raw outputs; it was to simulate a practical audit loop where one AI system helps clean up the obvious or high-confidence issues, and another system is then used to probe the patched design for deeper residual flaws.
This matters because AI tools are most useful when treated as layered assistants rather than one-shot judges. The first pass can improve baseline security and reduce noise. The second pass can then focus on what remains: subtle state-machine gaps, incomplete fixes, or assumptions that were not addressed by the first tool.
Step 3: Run NemesisAI on the Patched Contracts
NemesisAI was then run on the updated contracts. Its output was especially interesting because it focused less on generic accounting drift and more on coupled state paths and exploit sequences. Instead of merely identifying isolated issues, it traced how report status mutation interacted with payment actions, refund reachability, and judge authorization.
That led to three verified findings:
- a high-severity
finalizeAndPaystatus-gating flaw with multiple exploitable sub-cases - a medium-severity judge-fee gap for invalidation outcomes
- a low-severity missing allowlist check in escalation finalization
In other words, after the first round of fixes, NemesisAI still found meaningful protocol-level weaknesses. That is exactly why multi-tool AI bug bounty analysis is valuable.
Key Vulnerabilities Found Across Both Tools
finalizeAndPay Logic Flaws
This was one of the most instructive areas.
PashovAI had already pointed to weaknesses around finalizeAndPay, including the risk that a primary judge could close escalated reports prematurely and the risk that unvalidated severity input in certain paths could manipulate judge-fee distribution.
NemesisAI went even deeper. It identified that finalizeAndPay used a negative exclusion model for status validation rather than a positive allowlist. That created multiple attack paths:
Unprocessed report closure
A primary judge could finalize a SUBMITTED report before any real review, causing it to move to CLOSED.
Second-opinion bypass
A primary judge could close a report in SECOND_OPINION_REQUESTED, collect a judge fee, and kill the company’s dispute path.
Escalation denial
A rejected report could be closed before the researcher had the chance to escalate.
Double-payment risk
A previously PAID report could still be finalized again under certain conditions, creating the possibility of double-paying judge fees.
This is a classic state machine flaw: the function did not strictly enumerate valid finalization states. Instead, it merely blocked a few invalid ones, leaving dangerous gaps. That is a perfect example of advanced smart contract vulnerability detection where the issue is not a simple arithmetic error but a flawed control-flow model.
Escrow Accounting Inconsistencies
PashovAI did especially well on accounting integrity.
It caught the duplicate severity issue in createProgram, where repeated severity entries could inflate required deposits while only one final value remained active. The result: excess funds trapped unless the company completes a separate refund flow. In an escrow-based protocol, trapped capital is a real operational and security problem, even if no attacker steals funds directly.
Escalation Flow Vulnerabilities
Both tools also exposed issues in the dispute-resolution design.
PashovAI highlighted that escalated reports could be mishandled by the primary judge and that judge fees could become permanently locked in certain rejection outcomes. NemesisAI then added a lower-severity but still important control issue: finalizeEscalation lacked a fresh isJudge allowlist check, meaning a previously assigned but later removed judge could still finalize an escalation already in progress.
For decentralized bug bounty protocols, these aren’t just implementation mistakes. They go to the heart of fairness. If escalation and second-opinion mechanics can be bypassed, the protocol’s dispute model loses credibility.
PashovAI vs. NemesisAI: What Each Tool Did Well
Both tools were useful, but they excelled in different ways.
Where PashovAI stood out
PashovAI was particularly effective at finding:
- accounting mismatches in escrow and treasury flows
- configuration and deposit-related edge cases
- several practical payout-path weaknesses
Its report felt strong on financial logic and protocol assumptions that could lead to undercollateralization, trapped funds, or broken balance accounting. That made it highly useful as a first-pass AI audit layer.
Where NemesisAI stood out
NemesisAI performed best on:
- state machine path analysis
- coupling between report status and payment rights
- exploit sequence construction
- verifying which issues were true positives versus false positives
Its finalizeAndPay analysis was the strongest example. Rather than simply saying the function looked risky, it mapped concrete sub-cases showing how different statuses could be abused. That is exactly the kind of depth that makes a second-pass tool valuable after initial fixes are already in place.
How NemesisAI performed after the PashovAI fixes
This was the most important takeaway from the whole experiment: even after applying fixes based on the first AI report, NemesisAI still uncovered high-severity issues.
That suggests two things:
First, AI tools are complementary. One tool may surface accounting flaws, while another may expose residual logic bugs in the patched state machine.
Second, the best use of AI in security may not be “pick one model.” It may be a layered workflow:
- run one tool for broad vulnerability surfacing
- patch obvious and high-confidence findings
- run a second tool to probe for remaining invariant violations and protocol-flow bugs
- have a human auditor perform final triage and adversarial reasoning
That is a strong operational model for modern Web3 security tools.
Why AI-Assisted Audits Are Becoming Essential
The rise of AI in smart contract security is not hype alone. It reflects real pressure in Web3 development:
- codebases are becoming more modular and stateful
- launch cycles are fast
- protocols often combine escrow, governance, dispute flows, and token mechanics
- manual reviewers need better ways to prioritize time
An AI smart contract audit helps teams get earlier signal. It can surface likely danger zones before formal review, support internal QA before contests, and help auditors test assumptions faster. In bug bounty environments, AI can also help researchers rapidly inspect protocol mechanics and identify suspicious flows worth deeper validation.
Need4Audits is a great example because the meaningful bugs were not flashy reentrancy clichés. They were protocol correctness bugs: payout sequencing, status reachability, refund dead ends, and accounting drift. Those are exactly the categories where AI is becoming increasingly useful.
The Limits of AI Auditing Tools
That said, AI tools are not substitutes for real auditors.
They still have hard limitations:
- they can mis-rank severity
- they can produce false positives
- they may miss cross-contract business logic assumptions
- they do not understand real-world intent unless the code expresses it clearly
- they cannot independently validate whether a finding is economically exploitable without careful human review
NemesisAI’s own report explicitly distinguished verified findings from eliminated false positives. That is a good reminder that human triage remains essential. A strong security process still needs manual reasoning, exploit validation, invariant thinking, and architectural judgment.
The best framing is not “AI versus humans.” It is “AI plus humans.” AI accelerates discovery. Humans determine truth, exploitability, severity, and remediation quality.
Conclusion: The Future of AI-Assisted Smart Contract Auditing
This Need4Audits case study shows why AI smart contract audit workflows are becoming a practical part of Web3 security engineering.
PashovAI helped identify core escrow and payout issues in the original contracts. After those fixes, NemesisAI still found deeper state-machine and refund-path vulnerabilities. Together, the two tools demonstrated a powerful pattern: AI is most effective when used iteratively, across multiple passes, and always with human review in the loop.
For teams building decentralized bug bounty infrastructure, DeFi protocols, or any onchain system with non-trivial state transitions, automated smart contract security is no longer just a nice-to-have. It is becoming a core part of secure development. The future of AI bug bounty analysis will likely belong to hybrid workflows where AI handles large-scale logic exploration and human auditors deliver the final adversarial judgment.
That future is already visible. And if this case study is any indication, the smartest move is not to ask whether AI belongs in smart contract security. It is to figure out how to integrate it well.