uups-checker 1.0.0

package/BSCSLOCKTOKEN_CRITICAL_FINDING.md

@@ -0,0 +1,240 @@
+# 🚨 CRITICAL: BSCSLockToken Over-Withdrawal Vulnerability
+
+## Summary
+The BSCSLockToken vesting contract has a **CRITICAL MATH ERROR** that allows the owner to withdraw **102% of locked tokens** instead of 100%.
+
+---
+
+## Vulnerability Details
+
+### The Math Error
+
+**Percentages Array:**
+```solidity
+percents = [2,2,2,2,2,2,2,3,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5];
+```
+
+**Calculation:**
+- 2% × 7 periods = 14%
+- 3% × 1 period = 3%
+- 5% × 17 periods = 85%
+- **Total: 102%** ❌
+
+**Should be 100%** ✅
+
+---
+
+## Impact
+
+### Scenario 1: Exact Balance
+```
+Contract has: 1,000,000 tokens
+Owner claims: 102% = 1,020,000 tokens
+Result: LAST CLAIM FAILS (not enough tokens)
+```
+
+### Scenario 2: Over-Funded
+```
+Contract has: 1,020,000 tokens (102% funded)
+Owner claims: 102% = 1,020,000 tokens
+Result: Owner gets 2% extra (20,000 tokens)
+```
+
+### Scenario 3: Under-Funded
+```
+Contract has: 980,000 tokens (98% funded)
+Owner claims: 102% = 999,600 tokens
+Result: FAILS at 98% mark
+```
+
+---
+
+## Root Cause
+
+The developer made a counting error when setting up the percentages:
+
+**Intended:**
+- 2% × 7 = 14%
+- 3% × 1 = 3%
+- 5% × 17 = 85%
+- Total: 102% ❌
+
+**Should be:**
+- 2% × 7 = 14%
+- 2% × 1 = 2%  (or remove one 2% period)
+- 5% × 17 = 85%
+- Total: 101% (still wrong!)
+
+**OR:**
+- 2% × 6 = 12%
+- 3% × 1 = 3%
+- 5% × 17 = 85%
+- Total: 100% ✅
+
+---
+
+## Additional Vulnerabilities
+
+### 1. Array Length Mismatch
+```solidity
+rangesBlock: 25 elements
+withdraws: 26 elements  // BUG!
+percents: 25 elements
+```
+
+The `withdraws` array has 26 `false` values but only 25 periods. The last element is never used.
+
+**Impact:** Minor - causes confusion but doesn't break functionality
+
+---
+
+### 2. totalAmount vs Actual Balance
+
+```solidity
+constructor(..., uint256 totalLock) public {
+    totalAmount = totalLock;  // Set by deployer
+}
+
+function ClaimToken() public {
+    amount = (percents[i].mul(totalAmount)).div(100);  // Uses totalAmount
+    tokenBep20.transfer(msg.sender, amount);  // Actual balance
+}
+```
+
+**Problem:** `totalAmount` is set in constructor, not from actual token balance.
+
+**Exploit Scenarios:**
+
+**A) Under-Funding:**
+1. Deploy with totalAmount = 1,000,000
+2. Send only 500,000 tokens
+3. First claims work (2% of 1M = 20k)
+4. Later claims FAIL (not enough tokens)
+
+**B) Over-Funding:**
+1. Deploy with totalAmount = 1,000,000
+2. Send 2,000,000 tokens
+3. Owner claims 102% of 1M = 1,020,000
+4. 980,000 tokens STUCK forever!
+
+**Impact:** HIGH - Funds can be lost or locked
+
+---
+
+### 3. Arbitrary Token Withdrawal
+
+```solidity
+function withdraw(address contractToken, uint256 amount) public {
+    require(addressOwner == msg.sender, 'not owner');
+    IERC20(contractToken).safeTransfer(addressOwner, amount);
+}
+```
+
+**Problem:** Owner can withdraw ANY token, not just the locked token.
+
+**Impact:** 
+- MEDIUM if intentional (rescue function)
+- HIGH if users send tokens thinking they're safe
+
+---
+
+## Proof of Concept
+
+### Calculate Total Percentage
+```python
+percents = [2,2,2,2,2,2,2,3,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5]
+total = sum(percents)
+print(f"Total: {total}%")  # Output: 102%
+```
+
+### Exploit Path
+```solidity
+// If contract is over-funded by 2%:
+1. Deploy with totalAmount = 1,000,000
+2. Send 1,020,000 tokens (102%)
+3. Owner claims all 25 periods
+4. Owner receives 1,020,000 tokens
+5. Owner profits 20,000 tokens (2% extra)
+```
+
+---
+
+## Real-World Impact
+
+### If This Contract Is Deployed:
+
+**Check 1: What's the actual balance?**
+```bash
+cast call <CONTRACT> "tokenBep20()(address)" --rpc-url https://bsc-dataseed.binance.org/
+cast call <TOKEN> "balanceOf(address)(uint256)" <CONTRACT> --rpc-url https://bsc-dataseed.binance.org/
+```
+
+**Check 2: What's totalAmount?**
+```bash
+cast call <CONTRACT> "totalAmount()(uint256)" --rpc-url https://bsc-dataseed.binance.org/
+```
+
+**Check 3: How many claims completed?**
+```bash
+# Check withdraws array
+cast call <CONTRACT> "withdraws(uint256)(bool)" 0 --rpc-url https://bsc-dataseed.binance.org/
+```
+
+---
+
+## Recommended Fixes
+
+### Fix #1: Correct the Percentages
+```solidity
+// Option A: Remove one 2% period
+percents = [2,2,2,2,2,2,3,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5];  // 100%
+
+// Option B: Change 3% to 1%
+percents = [2,2,2,2,2,2,2,1,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5];  // 100%
+```
+
+### Fix #2: Use Actual Balance
+```solidity
+function ClaimToken() public {
+    require(addressOwner == msg.sender, 'not owner');
+    
+    // Use actual balance on first claim
+    if (withdraws[0] == false) {
+        totalAmount = tokenBep20.balanceOf(address(this));
+    }
+    
+    // ... rest of function
+}
+```
+
+### Fix #3: Fix Array Length
+```solidity
+// Remove extra false from withdraws
+withdraws = [false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false,false];  // 25 elements
+```
+
+---
+
+## Severity Assessment
+
+| Vulnerability | Severity | Exploitable | Impact |
+|---------------|----------|-------------|---------|
+| 102% Math Error | CRITICAL | YES | 2% over-withdrawal or failed claims |
+| totalAmount Mismatch | HIGH | YES | Funds locked or lost |
+| Arbitrary Withdrawal | MEDIUM | YES | Any token can be withdrawn |
+| Array Length Bug | LOW | NO | Cosmetic issue |
+| No Reentrancy Guard | LOW | NO | Mitigated by state updates |
+
+---
+
+## Conclusion
+
+This contract has a **CRITICAL MATH ERROR** allowing 102% withdrawal. Depending on how it's funded:
+
+1. **If funded at 100%:** Last claims will FAIL
+2. **If funded at 102%:** Owner gets 2% extra tokens
+3. **If funded differently:** Tokens get locked or lost
+
+The commented-out code shows the developer was aware of the totalAmount issue but didn't fix it properly. The 102% bug appears to be an accidental counting error.
+
+**Recommendation:** DO NOT USE this contract without fixing the percentage calculation.

package/BSW_BISWAP_SECURITY_AUDIT.md

@@ -0,0 +1,330 @@
+# Biswap (BSW) Token Security Audit
+
+## Contract Information
+- **Contract Name**: BSWToken
+- **Token Name**: Biswap
+- **Token Symbol**: BSW
+- **Address**: 0x965F527D9159dCe6288a2219DB51fc6Eef120dD1
+- **Chain**: BSC (BNB Smart Chain)
+- **Compiler**: Solidity 0.6.12
+- **Deployment Date**: May 24, 2021
+
+## Executive Summary
+
+The Biswap (BSW) token is a BEP-20 token with governance capabilities (delegation/voting) and a multi-minter system. The contract is based on standard OpenZeppelin patterns with Compound-style governance features.
+
+### Overall Risk Assessment: **MEDIUM**
+
+The contract has several security concerns that should be addressed, though no critical vulnerabilities that allow immediate fund theft were identified.
+
+---
+
+## Findings
+
+### HIGH SEVERITY
+
+#### H-1: Silent Mint Failure Can Lead to Accounting Issues
+
+**Location**: `BEP20._mint()` (lines 118-127)
+
+**Description**: The `_mint()` function returns `false` when attempting to mint beyond `_maxSupply` instead of reverting. This can lead to silent failures where:
+1. The minter believes tokens were minted successfully
+2. Delegate votes are updated via `_moveDelegates()` even though no tokens were minted
+3. Accounting mismatches between actual balances and voting power
+
+**Code**:
+```solidity
+function _mint(address account, uint256 amount) internal returns(bool) {
+    require(account != address(0), 'BEP20: mint to the zero address');
+    if (amount.add(_totalSupply) > _maxSupply) {
+        return false;  // ❌ Silent failure
+    }
+    _totalSupply = _totalSupply.add(amount);
+    _balances[account] = _balances[account].add(amount);
+    emit Transfer(address(0), account, amount);
+    return true;
+}
+```
+
+**Impact**: 
+- Voting power can be inflated without corresponding token balance
+- Governance manipulation potential
+- Confusion for minters who don't check return values
+
+**Proof of Concept**:
+```solidity
+// BSWToken.mint() calls _mint() and _moveDelegates()
+function mint(address _to, uint256 _amount) public onlyMinter returns(bool) {
+    _mint(_to, _amount);  // Returns false but doesn't revert
+    _moveDelegates(address(0), _delegates[_to], _amount);  // Still executes!
+    return true;
+}
+```
+
+**Recommendation**: 
+```solidity
+function _mint(address account, uint256 amount) internal returns(bool) {
+    require(account != address(0), 'BEP20: mint to the zero address');
+    require(amount.add(_totalSupply) <= _maxSupply, 'BEP20: mint exceeds max supply');
+    _totalSupply = _totalSupply.add(amount);
+    _balances[account] = _balances[account].add(amount);
+    emit Transfer(address(0), account, amount);
+    return true;
+}
+```
+
+---
+
+### MEDIUM SEVERITY
+
+#### M-1: Timestamp Dependency in Signature Validation
+
+**Location**: `BSWToken.delegateBySig()` (line 45)
+
+**Description**: The function uses `now` (alias for `block.timestamp`) to validate signature expiry. Miners can manipulate timestamps within a ~15 second window.
+
+**Code**:
+```solidity
+require(now <= expiry, "BSW::delegateBySig: signature expired");
+```
+
+**Impact**: 
+- Miners could potentially use expired signatures within the manipulation window
+- Low practical impact as the window is small
+
+**Recommendation**: This is a known limitation of blockchain timestamp usage. Document this behavior and ensure expiry times account for potential manipulation.
+
+---
+
+#### M-2: Centralization Risk - Owner Can Mint Unlimited Tokens
+
+**Location**: `BEP20.mint()` (line 96)
+
+**Description**: The contract owner can mint tokens directly without going through the minter system, bypassing any minter-specific controls.
+
+**Code**:
+```solidity
+function mint(uint256 amount) public onlyOwner returns (bool) {
+    _mint(_msgSender(), amount);
+    return true;
+}
+```
+
+**Impact**:
+- Owner has unchecked minting power up to maxSupply
+- Centralization risk
+- No delegate vote updates when owner mints (inconsistency with minter minting)
+
+**Recommendation**: 
+1. Remove owner mint function or route it through the same logic as minter mint
+2. Implement timelock for owner actions
+3. Consider multi-sig ownership
+
+---
+
+#### M-3: Missing Return Value Check in Minter Mint Function
+
+**Location**: `BSWToken.mint()` (line 6)
+
+**Description**: The function doesn't check if `_mint()` succeeded before updating delegate votes.
+
+**Code**:
+```solidity
+function mint(address _to, uint256 _amount) public onlyMinter returns(bool) {
+    _mint(_to, _amount);  // Return value ignored
+    _moveDelegates(address(0), _delegates[_to], _amount);
+    return true;
+}
+```
+
+**Impact**: See H-1 - this is the call site that enables the silent failure issue.
+
+**Recommendation**:
+```solidity
+function mint(address _to, uint256 _amount) public onlyMinter returns(bool) {
+    bool success = _mint(_to, _amount);
+    require(success, "BSW: mint failed");
+    _moveDelegates(address(0), _delegates[_to], _amount);
+    return true;
+}
+```
+
+---
+
+### LOW SEVERITY
+
+#### L-1: Solidity 0.6.12 is Outdated
+
+**Description**: The contract uses Solidity 0.6.12, which is several years old and missing security improvements from newer versions.
+
+**Recommendation**: Consider upgrading to 0.8.x which includes:
+- Built-in overflow protection (no need for SafeMath)
+- Better error messages
+- Security improvements
+
+**Note**: This would require significant refactoring and testing.
+
+---
+
+#### L-2: Use of `now` Keyword (Deprecated)
+
+**Location**: `BSWToken.delegateBySig()`
+
+**Description**: The `now` keyword is deprecated in favor of `block.timestamp`.
+
+**Recommendation**: Replace `now` with `block.timestamp` for clarity.
+
+---
+
+#### L-3: Missing Events for Critical State Changes
+
+**Description**: The `addMinter()` and `delMinter()` functions don't emit events.
+
+**Recommendation**:
+```solidity
+event MinterAdded(address indexed minter);
+event MinterRemoved(address indexed minter);
+
+function addMinter(address _addMinter) public onlyOwner returns (bool) {
+    require(_addMinter != address(0), "BSW: _addMinter is the zero address");
+    bool success = EnumerableSet.add(_minters, _addMinter);
+    if (success) {
+        emit MinterAdded(_addMinter);
+    }
+    return success;
+}
+```
+
+---
+
+#### L-4: Potential Integer Underflow in getMinter
+
+**Location**: `BSWToken.getMinter()` (line 73)
+
+**Description**: The check `_index <= getMinterLength() - 1` could underflow if `getMinterLength()` returns 0.
+
+**Code**:
+```solidity
+function getMinter(uint256 _index) public view onlyOwner returns (address){
+    require(_index <= getMinterLength() - 1, "BSW: index out of bounds");
+    return EnumerableSet.at(_minters, _index);
+}
+```
+
+**Impact**: Low - SafeMath would catch this, but it's cleaner to check explicitly.
+
+**Recommendation**:
+```solidity
+function getMinter(uint256 _index) public view onlyOwner returns (address){
+    require(_index < getMinterLength(), "BSW: index out of bounds");
+    return EnumerableSet.at(_minters, _index);
+}
+```
+
+---
+
+### INFORMATIONAL
+
+#### I-1: Governance Delegation Not Updated on Transfers
+
+**Description**: When tokens are transferred between addresses, delegate votes are not automatically updated. This is by design (following Compound's model) but should be documented.
+
+**Impact**: Users must manually call `delegate()` after receiving tokens to update voting power.
+
+---
+
+#### I-2: No Burn Functionality Exposed
+
+**Description**: While `_burn()` and `_burnFrom()` exist internally, there's no public burn function.
+
+**Impact**: Tokens cannot be burned by users, only by internal contract logic (if any).
+
+---
+
+#### I-3: Constructor Mints to Deployer
+
+**Description**: The constructor mints 10M tokens (preMineSupply) to the deployer address.
+
+**Code**:
+```solidity
+constructor(string memory name, string memory symbol) public {
+    _name = name;
+    _symbol = symbol;
+    _decimals = 18;
+    _mint(msg.sender, _preMineSupply);  // 10M tokens to deployer
+}
+```
+
+**Recommendation**: Document this clearly in project documentation.
+
+---
+
+## Security Best Practices Analysis
+
+### ✅ Implemented Correctly
+- Standard BEP-20 interface implementation
+- SafeMath usage for arithmetic operations
+- Access control via Ownable and custom modifiers
+- Reentrancy protection (no external calls in critical functions)
+- Zero address checks
+- Compound-style governance implementation
+
+### ⚠️ Areas of Concern
+- Silent failure in mint function (H-1)
+- Centralized owner control (M-2)
+- Outdated Solidity version (L-1)
+- Missing events for minter management (L-3)
+
+### ❌ Missing Features
+- No timelock for admin actions
+- No pause functionality
+- No upgrade mechanism
+- No multi-sig requirement for critical operations
+
+---
+
+## Gas Optimization Opportunities
+
+1. **Storage packing**: The `Checkpoint` struct uses `uint32` for `fromBlock` but `uint256` for `votes`. Consider if votes could use a smaller type.
+
+2. **Redundant checks**: Some functions have redundant zero address checks that could be optimized.
+
+3. **View function optimization**: Several view functions could be marked as `pure` or optimized for gas.
+
+---
+
+## Recommendations Summary
+
+### Critical Actions
+1. **Fix H-1**: Make `_mint()` revert instead of returning false when exceeding max supply
+2. **Fix M-3**: Check return value in `BSWToken.mint()` before updating delegates
+
+### High Priority
+1. Implement timelock for owner actions
+2. Add events for minter management
+3. Consider multi-sig for owner role
+4. Add comprehensive documentation
+
+### Medium Priority
+1. Upgrade to Solidity 0.8.x (requires extensive testing)
+2. Add pause functionality for emergency situations
+3. Implement more comprehensive testing
+
+### Low Priority
+1. Gas optimizations
+2. Code cleanup (replace `now` with `block.timestamp`)
+3. Add burn functionality if needed
+
+---
+
+## Conclusion
+
+The Biswap (BSW) token contract is generally well-implemented following standard patterns. However, the silent mint failure issue (H-1) is a significant concern that could lead to governance manipulation. The centralization risks should also be addressed through timelock mechanisms and multi-sig controls.
+
+The contract has been deployed and running since May 2021 without major incidents, which suggests the practical risk is lower than the theoretical analysis might indicate. However, the identified issues should still be addressed in any future upgrades or similar implementations.
+
+---
+
+## Disclaimer
+
+This audit is provided for informational purposes only and does not constitute financial, legal, or investment advice. The audit was performed based on the source code available at the time of analysis. Smart contracts are complex systems and this audit may not identify all potential vulnerabilities.