uups-checker 1.0.0

package/audits/basedAIFarm-security-audit-20260324.md

@@ -0,0 +1,330 @@
+# BasedAI Farm Security Audit Report
+
+**Contract**: basedAIFarm  
+**Type**: Yield Farming / Staking Contract (MasterChef-style)  
+**Audit Date**: March 24, 2026  
+**Auditor**: Kiro AI Security Analysis  
+
+---
+
+## Executive Summary
+
+**Risk Level**: 🔴 **CRITICAL**
+
+The basedAIFarm contract is a MasterChef-style yield farming contract with **CRITICAL VULNERABILITIES** that make it:
+1. **EXPLOITABLE** by the owner (rug pull vector)
+2. **DANGEROUS** for users (reward theft risk)
+3. **BROKEN** reward accounting system
+
+---
+
+## Contract Overview
+
+Standard MasterChef farming pattern:
+- Multiple pools with different LP tokens
+- Users deposit LP tokens to earn basedAI rewards
+- Rewards distributed per block based on pool allocation points
+- Owner can add/modify pools and adjust reward parameters
+
+---
+
+## Critical Findings
+
+### 🔴 CRITICAL #1: Owner Can Drain All Rewards Anytime
+**Severity**: CRITICAL  
+**Function**: `redeemAllRewards()`
+
+```solidity
+function redeemAllRewards(address _to) public onlyOwner {
+    uint256 basedAIBal = basedAI.balanceOf(address(this));
+    basedAI.transfer(_to, basedAIBal);
+}
+```
+
+**Impact**:
+- Owner can steal ALL basedAI tokens from the contract at any time
+- This includes rewards meant for users who have already earned them
+- Users who have pending rewards will lose everything
+- **INSTANT RUG PULL FUNCTION**
+
+**Exploit Scenario**:
+1. Users deposit LP tokens and earn rewards over time
+2. Owner calls `redeemAllRewards(owner_address)`
+3. All basedAI tokens transferred to owner
+4. Users' `claimReward()` and `withdraw()` calls fail (no tokens to transfer)
+5. Users lose all earned rewards
+
+**Recommendation**: REMOVE this function entirely. It serves no legitimate purpose.
+
+---
+
+### 🔴 CRITICAL #2: Broken Reward Accounting in claimReward()
+**Severity**: CRITICAL  
+**Function**: `claimReward()`
+
+```solidity
+function claimReward(uint256 _pid) public {
+    PoolInfo storage pool = poolInfo[_pid];
+    UserInfo storage user = userInfo[_pid][msg.sender];
+    uint256 poolRewardPerShare = getPoolRewardPerShare(_pid);  // ❌ WRONG
+    uint256 pending =
+        user.amount.mul(poolRewardPerShare).div(
+            accbasedAIPerShareMultiple
+        ).sub(user.rewardDebt);
+    if (pending > 0) {
+        safebasedAITransfer(msg.sender, pending);
+    }
+    user.rewardDebt = user.amount.mul(poolRewardPerShare).div(
+        accbasedAIPerShareMultiple
+    );
+    emit ClaimReward(msg.sender, _pid);
+}
+```
+
+**The Bug**:
+- Uses `getPoolRewardPerShare(_pid)` which calculates FUTURE rewards
+- Does NOT call `updatePool(_pid)` first
+- Does NOT update `pool.accbasedAIPerShare` in storage
+- Next time user interacts, they'll be charged for rewards they already claimed
+
+**Impact**:
+- Users can claim rewards multiple times for the same period
+- Reward accounting becomes completely broken
+- Contract will run out of rewards faster than intended
+- Some users will get nothing while others drain the pool
+
+**Correct Pattern** (from deposit/withdraw):
+```solidity
+updatePool(_pid);  // Update pool state FIRST
+uint256 pending = user.amount.mul(pool.accbasedAIPerShare).div(...).sub(user.rewardDebt);
+```
+
+---
+
+### 🔴 CRITICAL #3: Owner Can Change Reward Rate Anytime
+**Severity**: HIGH  
+**Function**: `updateRewardPerBlock()`
+
+```solidity
+function updateRewardPerBlock(uint256 _rewardPerBlock) public onlyOwner {
+    rewardPerBlock = _rewardPerBlock;
+}
+```
+
+**Impact**:
+- Owner can set `rewardPerBlock` to 0, stopping all rewards
+- Owner can increase it to drain rewards faster
+- No timelock, no limits, instant effect
+- Users have no protection against reward manipulation
+
+**Recommendation**: Add timelock delay and reasonable limits.
+
+---
+
+### 🔴 CRITICAL #4: Owner Can Extend Farming Indefinitely
+**Severity**: MEDIUM-HIGH  
+**Function**: `updateMaxRewardBlockNumber()`
+
+```solidity
+function updateMaxRewardBlockNumber(uint256 _newMaxRewardBlockNumber)
+    public
+    onlyOwner
+{
+    maxRewardBlockNumber = _newMaxRewardBlockNumber;
+}
+```
+
+**Impact**:
+- Owner can extend farming period indefinitely
+- Dilutes rewards for existing stakers
+- No limit on how far it can be extended
+- Combined with `updateRewardPerBlock()`, allows complete reward manipulation
+
+---
+
+### 🟡 HIGH #5: Pool Allocation Manipulation
+**Severity**: HIGH  
+**Function**: `set()`
+
+```solidity
+function set(uint256 _pid, uint256 _allocPoint, bool _withUpdate) public onlyOwner {
+    if (_withUpdate) {
+        massUpdatePools();
+    }
+    totalAllocPoint = totalAllocPoint.sub(poolInfo[_pid].allocPoint).add(_allocPoint);
+    poolInfo[_pid].allocPoint = _allocPoint;
+}
+```
+
+**Impact**:
+- Owner can change pool allocation points anytime
+- Can set a pool to 0 allocation (no more rewards)
+- Can favor certain pools over others arbitrarily
+- If `_withUpdate = false`, skips `massUpdatePools()` causing accounting issues
+
+**Issue**: No limits, no timelock, instant effect.
+
+---
+
+### 🟡 MEDIUM #6: Missing Pool State Update in set()
+**Severity**: MEDIUM  
+**Function**: `set()`
+
+**The Bug**:
+```solidity
+function set(uint256 _pid, uint256 _allocPoint, bool _withUpdate) public onlyOwner {
+    if (_withUpdate) {
+        massUpdatePools();  // Updates all pools
+    }
+    totalAllocPoint = totalAllocPoint.sub(poolInfo[_pid].allocPoint).add(_allocPoint);
+    poolInfo[_pid].allocPoint = _allocPoint;
+    // ❌ Does NOT update pool.accbasedAIPerShare for this specific pool
+}
+```
+
+**Impact**:
+- When allocation changes, the pool's `accbasedAIPerShare` should be updated
+- Even with `_withUpdate = true`, the pool state is updated BEFORE the allocation change
+- This causes incorrect reward calculations for the period between update and allocation change
+
+**Correct Pattern**: Should call `updatePool(_pid)` AFTER changing allocation.
+
+---
+
+### 🟡 MEDIUM #7: No Reentrancy Protection
+**Severity**: MEDIUM  
+**Functions**: `deposit()`, `withdraw()`, `claimReward()`
+
+**Issue**:
+- No `nonReentrant` modifier on external functions
+- Transfers happen before state updates in some cases
+- If pool token is malicious ERC20 with callback, could cause issues
+
+**Current Order in withdraw()**:
+```solidity
+updatePool(_pid);
+uint256 pending = ...;
+if (pending > 0) {
+    safebasedAITransfer(msg.sender, pending);  // External call
+}
+if (_amount > 0) {
+    user.amount = user.amount.sub(_amount);  // State update
+    pool.token.safeTransfer(address(msg.sender), _amount);  // External call
+}
+user.rewardDebt = ...;  // State update
+```
+
+**Risk**: Medium (requires malicious pool token, but owner controls pool addition).
+
+---
+
+### 🟢 INFORMATIONAL #8: Inefficient View Function
+**Severity**: INFORMATIONAL  
+**Function**: `getTotalReward()`
+
+```solidity
+function getTotalReward(address _address) public view returns (uint256) {
+    uint256 totalReward = 0;
+    uint256 length = poolInfo.length;
+    for (uint256 pid = 0; pid < length; ++pid) {
+        // Loops through all pools
+    }
+    return totalReward;
+}
+```
+
+**Issue**: Gas-intensive for many pools, but it's a view function so not critical.
+
+---
+
+### 🟢 INFORMATIONAL #9: No Emergency Withdraw
+**Severity**: INFORMATIONAL  
+
+**Missing Feature**: No emergency withdraw function that lets users pull their LP tokens without claiming rewards.
+
+**Use Case**: If reward token is broken/exploited, users should be able to withdraw their principal.
+
+**Recommendation**: Add `emergencyWithdraw()` function.
+
+---
+
+## Exploitability Assessment
+
+### Can External Attackers Exploit This?
+
+**NO** - External attackers cannot exploit this contract directly because:
+- All critical functions are `onlyOwner`
+- Reward calculation bugs hurt users, not help attackers
+- No flash loan attack vectors
+- No price manipulation vectors
+
+### Can Owner Exploit This?
+
+**YES** - Owner has MULTIPLE rug pull vectors:
+
+1. **Instant Reward Theft**: Call `redeemAllRewards()` to steal all tokens
+2. **Reward Manipulation**: Set `rewardPerBlock` to 0 or manipulate allocations
+3. **Indefinite Extension**: Extend `maxRewardBlockNumber` to dilute rewards
+4. **Add Malicious Pool**: Add pool with malicious token for reentrancy
+
+---
+
+## Risk Summary
+
+| Risk Category | Level | Details |
+|--------------|-------|---------|
+| **Rug Pull Risk** | 🔴 CRITICAL | Owner can drain all rewards instantly |
+| **Reward Accounting** | 🔴 CRITICAL | Broken `claimReward()` function |
+| **Centralization** | 🔴 CRITICAL | Complete owner control over all parameters |
+| **External Exploit** | 🟢 LOW | Not exploitable by external attackers |
+| **Code Quality** | 🟡 MEDIUM | Standard MasterChef pattern but with bugs |
+
+---
+
+## Recommendations
+
+### Immediate Actions Required:
+
+1. **REMOVE** `redeemAllRewards()` function entirely
+2. **FIX** `claimReward()` to call `updatePool()` first and use `pool.accbasedAIPerShare`
+3. **ADD** timelock to `updateRewardPerBlock()` and `updateMaxRewardBlockNumber()`
+4. **ADD** limits to parameter changes (max reward rate, max extension period)
+5. **ADD** `nonReentrant` modifier to all external functions
+6. **ADD** `emergencyWithdraw()` function for users
+7. **FIX** `set()` to update pool state AFTER allocation change
+
+### Security Best Practices:
+
+1. Transfer ownership to multi-sig wallet with timelock
+2. Make reward parameters immutable after deployment
+3. Add events for all owner actions
+4. Consider using OpenZeppelin's `ReentrancyGuard`
+5. Add comprehensive testing for reward calculations
+
+---
+
+## Conclusion
+
+**VERDICT**: 🔴 **DO NOT USE - CRITICAL VULNERABILITIES**
+
+This contract has:
+- ✅ Standard MasterChef pattern (good foundation)
+- ❌ Critical rug pull function (`redeemAllRewards`)
+- ❌ Broken reward accounting (`claimReward`)
+- ❌ Excessive owner control with no protections
+- ❌ No timelock or limits on parameter changes
+
+**For Users**: EXTREMELY RISKY - Owner can steal all rewards at any time.
+
+**For Owner**: If you're the owner and want to run this legitimately:
+1. Remove the rug pull function
+2. Fix the reward accounting bug
+3. Add timelocks and limits
+4. Transfer to multi-sig with timelock
+5. Get a professional audit before deploying
+
+**Exploitability**: Not exploitable by external attackers, but owner has complete control to rug pull users.
+
+---
+
+**Audit Complete** ✓