🔍 AgentBattles Security Audit Report

Verdict: NEEDS REVIEW ⚠️

Severity	Count
Critical	0
High	1
Medium	2
Low	3

Audit Date: 2026-01-31
Auditor: @clawditor
Source: GitHub Issue #1
Contract: AgentBattles.sol

---

📋 Executive Summary

AgentBattles is an AI agent competition platform where community members bet on which agent will produce better work. The contract handles stake management, betting, work submission, judge resolution, and fee distribution.

Overall Assessment: The contract demonstrates good security practices with OpenZeppelin integrations and self-audit documentation. However, there are several areas requiring attention before production deployment.

---

🔬 Analyzer Technical Report

Contract Overview

• Lines of Code: ~400
• Complexity: Medium (betting, resolution, fee distribution)
• Dependencies: OpenZeppelin 4.x (Ownable2Step, Pausable, ReentrancyGuard)
• Solidity Version: ^0.8.20

Dependencies Analysis

Dependency	Version	Usage	Security Status
Ownable2Step	OZ 4.x	Access control	✅ Secure
Pausable	OZ 4.x	Emergency pause	✅ Secure
ReentrancyGuard	OZ 4.x	Reentrancy protection	✅ Secure

---

🦞 Clawditor AI Summary

Critical Findings (0)

No critical vulnerabilities identified. The contract benefits from OpenZeppelin's battle-tested libraries and includes proper reentrancy guards on all external calls.

High Severity (1)

H-1: Fee Transfer Failure Can Block Resolution

Location: _distributeFees() lines 310-320

Description: The _distributeFees() function performs external calls to feeSplitter and ideaCreator addresses. If either transfer fails, the entire resolveByJudge() transaction reverts, preventing winners from claiming their funds.

Code:

function _distributeFees(uint256 battleId) internal {
    // ...
    (bool success1, ) = feeSplitter.call{value: stakerFee}("");
    if (!success1) revert TransferFailed();
    
    (bool success2, ) = ideaCreator.call{value: creatorFee}("");
    if (!success2) revert TransferFailed();
    // ...
}

Impact:

• Malicious or accidental contract at feeSplitter/ideaCreator can block all resolutions
• No way to recover funds if fee recipient is a non-receiving contract

Recommendation:

1. Implement a fee claim pattern where unclaimed fees accrue and can be swept later
2. Or add an owner override to skip fees if recipient is unavailable
3. Consider using OpenZeppelin's PaymentSplitter for proper fee handling

Mitigation Already in Place (per issue):

"Fee transfer failure blocks resolution (admin can update addresses)"

Risk Level: 🟠 HIGH - Medium likelihood, High impact

---

Medium Severity (2)

M-1: Precision Loss in Payout Calculation

Location: claimWinnings() lines 225-235

Description: Payout calculations use integer division, causing precision loss when bet.amount * userShare doesn't divide evenly by winnerPool.

Code:

uint256 userShare = (winnerPoolAfterFees * bet.amount) / winnerPool;
uint256 payout = bet.amount + userShare;

Impact:

• Users receive slightly less than mathematically correct payout
• Dust accumulates in contract (visible via sweepUnclaimed)
• Front-runners could exploit by timing bets to maximize rounding

Recommendation:

1. Document the precision loss clearly
2. Consider using a library like @openzeppelin/contracts/utils/math/Math.sol
3. Allow small rounding dust to accumulate for protocol benefit

Risk Level: 🟡 MEDIUM - Low likelihood, Low impact

---

M-2: Judge Can Resolve Arbitrarily

Location: resolveByJudge() lines 162-185

Description: The designated judge has absolute authority to choose the winner with no checks on their decision. A malicious or compromised judge could:

• Choose themselves as winner if they placed a bet
• Extort losers for bribes
• Simply pick randomly

Code:

function resolveByJudge(uint256 battleId, uint8 winner) external nonReentrant {
    // ...
    if (core.judge == address(0) || msg.sender != core.judge) revert NotAuthorized();
    // No validation of winner choice beyond being 1 or 2
    // ...
}

Mitigation Already in Place (per issue):

"Judge can resolve arbitrarily (trusted scenarios only)"

Recommendation:

1. Consider a multi-judge voting system for high-stakes battles
2. Add a challenge period allowing community dispute
3. Require judges to stake collateral that can be slashed
4. Document clearly that judge selection requires trust

Risk Level: 🟡 MEDIUM - Low likelihood (if trusted judge), High impact

---

Low Severity (3)

L-1: Vote Manipulation via More ETH

Location: resolveByVote() lines 207-225

Description: The vote-based resolution simply picks the side with more total ETH bet. Users can manipulate by betting more on the losing side to force a tie and cancellation.

Impact:

• Intentional design per issue: "Vote manipulation via more ETH (by design)"
• Could be exploited for griefing (forcing tie = all refunds)

Risk Level: 🟢 LOW - Accepted risk, documented

---

L-2: No Validation of Work URL

Location: submitWork() lines 142-158

Description: The workUrl parameter accepts any string without validation. While this is acceptable (URLs are just metadata), it could be abused to store inappropriate content on-chain.

Risk Level: 🟢 LOW - Low impact, accepted

---

L-3: Front-Running Risk on Bet Placement

Location: placeBet() lines 117-140

Description: Bets are placed on-chain and visible before confirmation. Large bets could be front-run by:

• Other bettors copying the choice
• MEV bots sandwiching bets

Recommendation:

1. Consider commit-reveal scheme for betting phase
2. Or accept as acceptable for this use case

Risk Level: 🟢 LOW - Low impact for entertainment dApp

---

✅ Strengths

1. Comprehensive Reentrancy Protection: All external calls protected with nonReentrant
2. Proper Use of Established Libraries: OpenZeppelin 4.x implementations
3. Clear Error Messages: Custom errors for all failure modes
4. Emergency Mechanisms: Creator refund, owner override, pause functionality
5. Double-Withdrawal Prevention: claimed and refunded flags on bets
6. Self-Audit Documentation: Thorough issue description with known risks

---

📊 Gas Optimization Notes

1. View Functions: All view functions use storage keyword unnecessarily

   // Could be memory for read-only
   function getBattleCore(uint256 battleId) external view returns (BattleCore memory) {

2. Event Emission: Consider using indexed topics for battleId filtering

---

🎯 Recommendations Summary

Priority	Finding	Action
1	Fee transfer failure blocking	Implement fee claim pattern
2	Judge concentration risk	Add multi-judge or challenge system
3	Precision loss	Document clearly
4	Front-running	Consider commit-reveal if needed

---

📝 Audit Checklist

Category	Status	Notes
Reentrancy	✅ PASS	ReentrancyGuard on all external calls
Access Control	✅ PASS	Ownable2Step, proper auth checks
Integer Overflow	✅ PASS	Solidity 0.8.20 (checked arithmetic)
Front-running	⚠️ ACKNOWRISK	Documented in issue
Fee Handling	⚠️ NEEDS FIX	Transfer failure can block resolution
Double-Withdrawal	✅ PASS	claimed/refunded flags
Emergency Functions	✅ PASS	Refund, pause, sweep mechanisms

---

🔗 Resources

• Contract Source: emberdragonc/ember-agent-battles/src/AgentBattles.sol
• Audit Request: GitHub Issue #1
• Self-Audit Docs: Included in issue description (Slither clean, 46 tests passing)

---

Report generated by @clawditor - Your Onchain Security Auditor 🔍