solidity-argus 0.2.0 → 0.3.0

package/skills/vulnerability-patterns/proxy-vulnerabilities/SKILL.md

@@ -0,0 +1,209 @@
+---
+name: proxy-vulnerabilities
+description: Proxy pattern vulnerabilities including storage collision, uninitialized proxy, and function selector clash
+category: vulnerability-pattern
+pattern_category: proxy
+detection_rules:
+  - regex: 'delegatecall|IMPLEMENTATION_SLOT'
+    severity: Critical
+    confidence: Medium
+    swc: SWC-112
+    description: Delegatecall or implementation slot usage - potential storage collision between proxy and implementation contracts if storage layouts diverge
+  - regex: '_disableInitializers|initializer'
+    severity: High
+    confidence: Medium
+    description: Proxy initialization pattern detected - verify implementation contract calls _disableInitializers() in constructor and proxy calls initialize()
+  - regex: 'fallback\(\)|receive\(\).*delegatecall'
+    severity: Medium
+    confidence: Low
+    description: Fallback or receive function with delegatecall - risk of function selector clash between proxy admin functions and implementation functions
+---
+
+# Proxy Vulnerability Patterns
+
+## Overview
+
+Upgradeable proxy systems trade immutability for maintainability. That trade introduces a second security model: execution context and storage live in the proxy, while logic lives in implementations reached through `delegatecall`. Any mismatch between expected and actual layout, initialization state, or function routing can grant attackers full control.
+
+Most proxy exploits are not complex cryptographic breaks. They are integration failures across deployment scripts, upgrade procedures, and ABI boundaries. A proxy setup can be technically standards-compliant and still vulnerable if governance, initialization, or selector design is weak.
+
+Auditing proxies requires system-level reasoning across deployment transactions, upgrade authority, storage layout evolution, and fallback behavior. Reviewing only implementation code misses critical attack surface in proxy shell contracts and admin operations.
+
+## Key Attack Vectors
+
+- Storage collision between proxy slots and implementation variables.
+- Uninitialized implementation contracts that an attacker can initialize directly.
+- Uninitialized proxies where initializer can be called by arbitrary users.
+- Selector clashes between admin functions and delegated user functions.
+- Unsafe fallback routing that forwards admin calls into implementation logic.
+- Upgrade functions lacking role checks, timelocks, or upgrade validation.
+- Incompatible storage layout changes during upgrades.
+- Missing rollback testing for UUPS upgrades.
+- Delegatecall to untrusted implementation addresses.
+
+### Typical Takeover Sequence (Uninitialized Proxy)
+
+1. Proxy is deployed without atomic initialization.
+2. Initializer remains externally callable.
+3. Attacker calls `initialize()` first and becomes owner/admin.
+4. Attacker upgrades implementation or drains managed assets.
+5. Team loses control of proxy governance path.
+
+### Typical Storage Collision Sequence
+
+1. New implementation reorders or inserts state variables incorrectly.
+2. Critical admin/value fields map to unexpected slots.
+3. Routine function calls mutate sensitive proxy state.
+4. Access control breaks or funds accounting corrupts.
+5. Recovery requires emergency upgrade or migration.
+
+## Detection Heuristics
+
+### Proxy Primitive Identification
+
+- Detect `delegatecall`, `fallback`, `receive`, and implementation slot constants.
+- Identify whether system is Transparent, UUPS, Beacon, or custom hybrid.
+- Enumerate upgrade entry points and admin authority graph.
+- Verify proxy and implementation compile with compatible storage assumptions.
+
+### Initialization Safety Checks
+
+- Confirm implementation constructor calls `_disableInitializers()`.
+- Ensure proxy initialization happens in deployment transaction.
+- Verify initializer functions are single-use and role-gated where required.
+- Check reinitializer versioning for upgrade modules.
+
+### Storage Layout Safety Checks
+
+- Compare storage layout before and after upgrade.
+- Ensure inherited contracts preserve variable ordering.
+- Validate use of storage gaps (`uint256[50] private __gap`) where applicable.
+- Confirm EIP-1967 slots are used for implementation/admin/beacon pointers.
+
+### Selector Clash and Routing Checks
+
+- Enumerate proxy admin selectors and implementation public selectors.
+- Detect collisions where admin and user paths share selectors.
+- Ensure Transparent proxy blocks admin from falling through to implementation.
+- For UUPS, verify `proxiableUUID` and upgrade authorization checks.
+
+### Concrete Code Smells
+
+```solidity
+fallback() external payable {
+    (bool ok,) = implementation.delegatecall(msg.data);
+    require(ok);
+}
+```
+
+```solidity
+function initialize(address owner_) external initializer {
+    owner = owner_; // callable by first caller if not atomically initialized
+}
+```
+
+```solidity
+bytes32 internal constant IMPLEMENTATION_SLOT =
+    keccak256("implementation"); // non-standard slot risks conflicts
+```
+
+### Audit Checklist
+
+- Is every proxy deployed with initialization calldata in the same transaction?
+- Are implementation contracts permanently non-initializable post-deploy?
+- Are storage layout diffs reviewed and enforced in CI before upgrade?
+- Are upgrade operations timelocked, multisig-gated, and event-rich?
+- Are selector collisions tested against full ABI surface?
+
+## Prevention
+
+### Use Battle-Tested Standards
+
+- Prefer OpenZeppelin TransparentUpgradeableProxy or ERC1967/UUPS implementations.
+- Use EIP-1967 storage slots and audited upgrade libraries.
+- Avoid custom proxy shells unless necessary for protocol-specific requirements.
+- Keep proxy logic minimal and immutable where possible.
+
+### Initialization Hardening
+
+- Call `_disableInitializers()` in implementation constructor.
+- Supply initializer calldata during proxy deployment.
+- Restrict or remove external initializer exposure after setup.
+- Document and test upgrade-time reinitializer sequences.
+
+### Upgrade Governance Controls
+
+- Gate upgrades behind multisig + timelock.
+- Require explicit implementation validation (`code.length > 0`, interface checks).
+- Emit events for proposed and executed upgrades.
+- Maintain emergency pause/rollback procedures with clear authority boundaries.
+
+### Selector and Routing Safety
+
+- For Transparent proxies, separate admin and user call paths strictly.
+- For UUPS proxies, enforce `_authorizeUpgrade` with robust roles.
+- Run selector collision scans in CI against proxy and implementation ABIs.
+- Avoid exposing overlapping administrative selectors in implementations.
+
+### Hardened Pattern Example
+
+```solidity
+contract Impl is Initializable, UUPSUpgradeable, OwnableUpgradeable {
+    constructor() {
+        _disableInitializers();
+    }
+
+    function initialize(address owner_) external initializer {
+        __Ownable_init(owner_);
+    }
+
+    function _authorizeUpgrade(address newImplementation)
+        internal
+        override
+        onlyOwner
+    {}
+}
+```
+
+### Operational Practices
+
+- Store upgrade runbooks with preflight and postflight checks.
+- Simulate upgrades on forked state before production execution.
+- Track implementation bytecode hashes and signed release artifacts.
+- Include automated storage-layout regression gates in release pipelines.
+
+## Real-World Examples
+
+### Proxy Initialization Incidents
+
+- Pattern: implementation or proxy left uninitialized.
+- Impact: attacker claims ownership role and controls upgrade path.
+- Lesson: initialization must be atomic, single-use, and scripted.
+
+### Storage Layout Corruption Cases
+
+- Pattern: variable order/type changes between implementation versions.
+- Impact: admin slots and balances are overwritten unintentionally.
+- Lesson: treat storage layout as immutable contract between versions.
+
+### Selector Clash Risk in Custom Proxies
+
+- Pattern: fallback delegatecalls overlap with proxy admin selectors.
+- Impact: privileged calls routed incorrectly or user calls blocked.
+- Lesson: transparent separation and selector audits are mandatory.
+
+### Pattern-to-Impact Mapping
+
+- `storage-collision` -> critical state corruption and privilege compromise.
+- `uninitialized-proxy` -> hostile initialization and upgrade takeover.
+- `selector-clash` -> call-path confusion and admin bypass risk.
+
+## References
+
+- SWC-112 (Delegatecall to untrusted callee): https://swcregistry.io/docs/SWC-112
+- OpenZeppelin Upgrades docs: https://docs.openzeppelin.com/upgrades-plugins/1.x/
+- OpenZeppelin proxy patterns: https://docs.openzeppelin.com/contracts/4.x/api/proxy
+- EIP-1967 proxy storage slots: https://eips.ethereum.org/EIPS/eip-1967
+- EIP-1822 (UUPS): https://eips.ethereum.org/EIPS/eip-1822
+- ConsenSys best practices for upgradeability: https://consensys.github.io/smart-contract-best-practices/
+- Trail of Bits proxy audit notes: https://blog.trailofbits.com/

package/skills/vulnerability-patterns/reentrancy/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: reentrancy
 description: Reentrancy attack patterns, real incidents, and defensive coding checks for Solidity protocols.
+pattern_category: reentrancy
 source_url: https://github.com/kadenzipfel/smart-contract-vulnerabilities
 source_license: MIT
 imported_at: "2025-01-15T00:00:00Z"
@@ -14,6 +15,14 @@ detection_rules:
     severity: Medium
     confidence: Medium
     description: Low-level external call that can open a reentrancy window
+  - regex: '\.(transfer|transferFrom)\('
+    severity: Medium
+    confidence: Medium
+    description: ERC-20 token transfer that may precede state changes — reentrancy via token callback hooks (ERC-777, ERC-1155)
+  - regex: '(external|public)\s.*\{[^}]*\.call'
+    severity: High
+    confidence: Low
+    description: Public/external function with low-level call — potential cross-function reentrancy if shared state is read by other functions
 ---
 
 <!-- Source: DeFiFoFum/fofum-solidity-skills (MIT) -->

package/skills/vulnerability-patterns/shadowing-state-variables/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: shadowing-state-variables
-description: - Contract inherits from one or more parent contracts
+description: '- Contract inherits from one or more parent contracts'
+pattern_category: logic-error
+detection_rules:
+  - regex: 'override\b'
+    severity: Informational
+    confidence: Low
+    swc: SWC-119
+    description: Override-heavy inheritance context worth shadowing review
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/share-accounting-desynchronization/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: share-accounting-desynchronization
+description: "Asset/share systems drift out of sync across views, transfers, or reward logic, enabling value leakage, bypasses, or protocol lockups."
+category: vulnerability-pattern
+pattern_category: erc4626
+source_url: "https://github.com/bailsec/BailSec"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: "(sharesToToken|tokenToShares|previewWrap|previewUnwrap|accRewardPerShare|totalShares|totalSupply)"
+    severity: "High"
+    description: "Share conversion and accumulator surfaces prone to state drift"
+  - regex: "(round|mulDiv|division by zero|overflow|underflow)"
+    severity: "Medium"
+    description: "Numerical conditions that amplify desynchronization impact"
+---
+<!-- Source: BailSec audit reports (CC0) -->
+
+# Share Accounting Desynchronization Vulnerabilities
+
+## Overview
+Share-accounting desynchronization appears when a protocol tracks ownership in shares but exposes user actions, approvals, rewards, or integrations in asset-denominated values without guaranteed synchronization. If share supply, token supply, and fee accrual are updated at different times or with inconsistent caps, attackers and edge cases can exploit the mismatch to bypass approvals, drain value, lock funds, or break reward accounting.
+
+Unlike a single arithmetic bug, this is a system-level failure of consistency across view logic, state updates, and transfer semantics.
+
+## Common Patterns
+- Approval consumption and transfer amount are evaluated in different units.
+- View functions use theoretical future supply while state-changing paths use capped or delayed supply updates.
+- Reward accumulators assume minted fees that are not actually minted.
+- Rounding strategy differs across conversion helpers, causing exploitable drift in repeated operations.
+
+## Detection Heuristics
+- Map all conversions between shares and assets, then verify consistent rounding direction by context.
+- Compare view-only paths (`pending`, `preview`, `realBalance`) against state-changing mint/burn/update behavior.
+- Check behavior when fee collector address changes, updates are delayed, or supply caps are hit.
+- Fuzz with long periods of inactivity, then sudden updates to detect discontinuities.
+
+## Examples from Audits
+- Share transfer path that could bypass token-amount approval checks under specific conversion outcomes.
+- Reward preview functions allocating value from uncapped or unminted fees, creating inconsistent accumulator states.
+- Systems where stale supply updates or abrupt fee-recipient changes altered debase/reward behavior and destabilized accounting.
+
+## Remediation
+Adopt a single canonical accounting model and centralize conversions in audited helper functions with documented rounding policy. Enforce that view and state paths share the same cap logic and fee-mint assumptions. Add invariant tests ensuring `assets <-> shares` coherence under updates, pauses, and collector changes. When conversions can become stale, force synchronization before sensitive operations or require bounded slippage from callers. This reduces drift accumulation and makes behavior predictable for integrations.

package/skills/vulnerability-patterns/signature-malleability/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: signature-malleability
-description: - Contract uses ECDSA signatures for authorization or deduplication
+description: "Contract uses ECDSA signatures for authorization or deduplication"
+pattern_category: signature
 detection_rules:
   - regex: 'ecrecover'
     severity: Medium

package/skills/vulnerability-patterns/stateful-parameter-update-drift/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: stateful-parameter-update-drift
+description: "Changing live protocol parameters without synchronizing accrued state creates hindsight effects, unfair allocations, or broken invariants."
+category: vulnerability-pattern
+pattern_category: logic-error
+source_url: "https://github.com/bailsec/BailSec"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: "set[A-Z][A-Za-z0-9_]*\\(.*\\)"
+    severity: "Medium"
+    description: "State-changing parameter setter that may require pre-update synchronization"
+  - regex: "(lastUpdate|pending|accrued|epoch|index|reward|supply).*(set|change|update)"
+    severity: "High"
+    description: "Potential hindsight impact when mutable parameters affect accrued accounting"
+---
+<!-- Source: BailSec audit reports (CC0) -->
+
+# Stateful Parameter Update Drift Vulnerabilities
+
+## Overview
+Protocols with time-based accrual (fees, rebases, emissions, yield drips) often expose governance or admin setters that modify core parameters while accrual windows are still open. If the contract does not settle or checkpoint state before applying the new value, the update retroactively changes historical accounting. This creates hindsight effects: users can gain or lose value for periods that should already be fixed.
+
+The vulnerability is not just governance centralization. Even trusted governance can unintentionally trigger unfair redistribution or lockups when parameter updates are applied to stale state.
+
+## Common Patterns
+- Mutable fee collector or tax parameter changed without first syncing pending accrual.
+- Unstake tax, reward rate, or epoch frequency updates affecting already elapsed time.
+- Toggle-style parameters (`address(0)` sentinel, pause/unpause) that alter future and past calculations simultaneously.
+- Setter functions that bypass the same accounting hooks used by normal user actions.
+
+## Detection Heuristics
+- For each admin setter, identify all variables that depend on elapsed time since last update.
+- Verify setters call the same `_update*`, `_accrue*`, or checkpoint routines as user-facing flows.
+- Test state transitions with long inactivity windows and then a single governance change.
+- Check whether parameter changes can reorder who receives already-accrued rewards.
+
+## Examples from Audits
+- Fee-collector changes that prevented expected debasing in hindsight or triggered abrupt catch-up effects.
+- Tax parameter updates that applied to previously elapsed yield windows, redistributing value unexpectedly.
+- Configuration changes that could move protocol behavior into disruptive states immediately after activation.
+
+## Remediation
+Require a deterministic pre-update checkpoint in every setter that influences accrual math. Apply parameter changes only after accrued state is finalized to the current timestamp or epoch boundary. Where governance changes are sensitive, add delay and staged execution with explicit before/after snapshots. Include invariant tests asserting that total distributable value is conserved across parameter changes and that historical periods are not recomputed with new settings.

package/skills/vulnerability-patterns/unbounded-return-data/SKILL.md

@@ -1,6 +1,17 @@
 ---
 name: unbounded-return-data
-description: - Contract makes a low-level `.call()` to an untrusted or user-specified address
+description: '- Contract makes a low-level `.call()` to an untrusted or user-specified address'
+pattern_category: dos
+detection_rules:
+  - regex: '\.call\(.*\)'
+    severity: Low
+    confidence: Low
+    swc: SWC-110
+    description: Low-level call paths may copy attacker-controlled return data
+  - regex: 'returndatasize'
+    severity: Medium
+    confidence: Medium
+    description: Return-data handling path that warrants bounded-copy checks
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/unchecked-return-values/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: unchecked-return-values
-description: - Contract uses low-level calls: `.call()`, `.send()`, or `.delegatecall()`
+description: "Contract uses low-level calls: .call(), .send(), or .delegatecall()"
+pattern_category: logic-error
 detection_rules:
   - regex: '\.call\{'
     severity: Medium

package/skills/vulnerability-patterns/unencrypted-private-data-on-chain/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: unencrypted-private-data-on-chain
-description: - Sensitive data (passwords, secrets, private keys, game answers) is stored in contract storage
+description: '- Sensitive data (passwords, secrets, private keys, game answers) is stored in contract storage'
+pattern_category: logic-error
+detection_rules:
+  - regex: '(private|internal)\s+(uint|address|bytes|string)\s+\w*(secret|password|key|pin|seed)\w*'
+    severity: Medium
+    confidence: Low
+    swc: SWC-136
+    description: Sensitive identifier names stored in contract state
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/unexpected-ecrecover-null-address/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: unexpected-ecrecover-null-address
-description: - Contract uses `ecrecover` directly (not via OpenZeppelin's ECDSA library)
+description: '- Contract uses `ecrecover` directly (not via OpenZeppelin''s ECDSA library)'
+pattern_category: signature
+detection_rules:
+  - regex: 'ecrecover\([^\n]*\)'
+    severity: Medium
+    confidence: Medium
+    swc: SWC-117
+    description: Raw ecrecover call that requires explicit address(0) handling
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/uninitialized-storage-pointer/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: uninitialized-storage-pointer
-description: - Solidity version <0.5.0
+description: '- Solidity version <0.5.0'
+pattern_category: logic-error
+detection_rules:
+  - regex: 'storage\b'
+    severity: Low
+    confidence: Low
+    swc: SWC-109
+    description: Storage data-location usage that may indicate legacy pointer hazards
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/unsafe-erc20-transfers/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: unsafe-erc20-transfers
+description: Unsafe ERC20 transfer and approve calls that silently fail on non-standard tokens.
+category: vulnerability-pattern
+pattern_category: token-standard
+source_url: https://github.com/bailsec/BailSec
+source_license: CC0
+imported_at: "2026-02-20T00:00:00Z"
+detection_rules:
+  - regex: '\.transfer\([^)]+\)\s*;'
+    severity: Medium
+    confidence: Medium
+    description: Direct ERC20 transfer without SafeERC20 wrapper — may silently fail on non-standard tokens
+  - regex: '\.approve\([^)]+\)\s*;'
+    severity: Medium
+    confidence: Medium
+    description: Direct ERC20 approve without SafeERC20 wrapper — may silently fail on USDT-like tokens
+  - regex: 'IERC20\([^)]+\)\.transfer'
+    severity: Medium
+    confidence: High
+    description: Interface-cast ERC20 transfer without safe wrapper — return value not checked
+  - regex: 'IERC20\([^)]+\)\.approve'
+    severity: Medium
+    confidence: High
+    description: Interface-cast ERC20 approve without safe wrapper — return value not checked
+---
+
+<!-- Source: BailSec audit reports (CC0) -->
+<!-- Extracted via audit-ingest pipeline from 4 independent protocol audits -->
+
+# Unsafe ERC20 Transfer and Approve Calls
+
+## Overview
+
+The standard ERC20 interface specifies that `transfer()`, `transferFrom()`, and `approve()` return a `bool` indicating success. However, many widely-used tokens deviate from this standard:
+
+- **USDT** does not return a boolean on `transfer`/`approve`
+- **BNB**, **OMG** have missing return values
+- Some tokens return `false` on failure instead of reverting
+
+Contracts that call these functions directly (without SafeERC20) either:
+1. **Ignore the return value** → silent failure, tokens not actually transferred
+2. **Expect a boolean return** → revert on tokens that don't return one (like USDT)
+
+**Severity:** Low to Medium
+
+**Prevalence:** Found in 4 independent BailSec audits: Hypertrade V3 Core, Meuna, Robinos, SwapX Exchange.
+
+---
+
+## Vulnerable Pattern
+
+```solidity
+// VULNERABLE: Direct transfer — no return value check
+function withdraw(address token, uint256 amount) external {
+    IERC20(token).transfer(msg.sender, amount);
+    // If token returns false instead of reverting, this silently fails
+    // If token doesn't return bool (USDT), this reverts unexpectedly
+    balances[msg.sender] -= amount;  // State updated even if transfer failed!
+}
+
+// VULNERABLE: Direct approve — breaks with USDT
+function approveSpender(address token, address spender, uint256 amount) external {
+    IERC20(token).approve(spender, amount);
+    // USDT requires setting allowance to 0 before changing to non-zero
+    // Direct approve also doesn't handle missing return values
+}
+```
+
+## Secure Pattern
+
+```solidity
+import {SafeERC20} from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
+
+using SafeERC20 for IERC20;
+
+// SECURE: SafeERC20 handles all non-standard token behaviors
+function withdraw(address token, uint256 amount) external {
+    IERC20(token).safeTransfer(msg.sender, amount);
+    // Reverts on failure for ALL token types
+    balances[msg.sender] -= amount;
+}
+
+// SECURE: forceApprove handles USDT's approve quirk
+function approveSpender(address token, address spender, uint256 amount) external {
+    IERC20(token).forceApprove(spender, amount);
+    // Sets to 0 first if needed (USDT), handles missing return values
+}
+```
+
+## Impact
+
+- **Silent failure**: Token transfer returns `false` but contract proceeds as if successful — leads to accounting mismatch
+- **Unexpected revert**: Contract fails on widely-used tokens (USDT, BNB) that don't conform to standard return types
+- **Stuck funds**: Approve fails on USDT when changing non-zero allowance without zeroing first
+- **Loss of funds**: State changes applied after a silently failed transfer result in fund loss
+
+## Affected Token Examples
+
+| Token | Issue | Consequence |
+|-------|-------|-------------|
+| USDT | No bool return on transfer/approve | Reverts if caller expects bool return |
+| USDT | Requires approve(0) before approve(N) | Approve fails for non-zero to non-zero |
+| BNB | Missing return value | Reverts on standard interface call |
+| OMG | Missing return value | Reverts on standard interface call |
+| ZRX | Returns false on failure (no revert) | Silent failure if return unchecked |
+
+## Detection Checklist
+
+1. Does the contract use `IERC20.transfer()` or `IERC20.transferFrom()` directly?
+2. Is OpenZeppelin's `SafeERC20` imported and applied via `using SafeERC20 for IERC20`?
+3. Are `safeTransfer`, `safeTransferFrom`, and `forceApprove` used instead of raw calls?
+4. Does the contract need to support USDT or other non-standard tokens?
+
+## Relationship to Other Patterns
+
+- **unchecked-return-values**: Covers low-level `.call()`, `.send()`, `.delegatecall()` return values — different from ERC20 interface returns
+- **weird-tokens**: Broader reference covering all non-standard token behaviors — this skill focuses specifically on the transfer/approve safety wrapper pattern
+- **fee-on-transfer-tokens**: Covers amount mismatch due to transfer fees — complementary to this pattern
+
+## Remediation
+
+1. **Use SafeERC20**: Import and apply `using SafeERC20 for IERC20` for all ERC20 interactions
+2. **Use forceApprove**: Replace `approve()` with `forceApprove()` to handle USDT
+3. **Audit token list**: Verify which tokens the protocol supports and test with non-standard ones
+4. **Add integration tests**: Test deposit/withdraw flows with USDT, USDC, and at least one missing-return-value token
+
+## References
+
+- [OpenZeppelin SafeERC20](https://docs.openzeppelin.com/contracts/5.x/api/token/erc20#SafeERC20)
+- [Weird ERC20 — Missing Return Values](https://github.com/d-xo/weird-erc20#missing-return-values)
+- BailSec audit reports: Hypertrade V3 Core, Meuna, Robinos, SwapX Exchange

package/skills/vulnerability-patterns/unsafe-low-level-call/SKILL.md

@@ -1,6 +1,17 @@
 ---
 name: unsafe-low-level-call
-description: - Contract uses `.call()`, `.delegatecall()`, `.staticcall()`, or `.send()` for external interactions
+description: '- Contract uses `.call()`, `.delegatecall()`, `.staticcall()`, or `.send()` for external interactions'
+pattern_category: logic-error
+detection_rules:
+  - regex: '\.call\('
+    severity: Medium
+    confidence: Medium
+    swc: SWC-104
+    description: Low-level call usage requiring strict target and return-value checks
+  - regex: '\.delegatecall\('
+    severity: High
+    confidence: Medium
+    description: delegatecall usage with elevated storage-context risk
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/unsecure-signatures/SKILL.md

@@ -1,6 +1,17 @@
 ---
 name: unsecure-signatures
-description: - Contract uses ECDSA signatures for authorization, authentication, or message verification
+description: '- Contract uses ECDSA signatures for authorization, authentication, or message verification'
+pattern_category: signature
+detection_rules:
+  - regex: 'ecrecover\(\s*'
+    severity: Medium
+    confidence: Medium
+    swc: SWC-117
+    description: Signature recovery path needing malleability and null-address protections
+  - regex: 'keccak256\(abi\.encodePacked\('
+    severity: Medium
+    confidence: Low
+    description: Packed hash construction in signature domain may enable collisions
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/unsupported-opcodes/SKILL.md

@@ -1,6 +1,16 @@
 ---
 name: unsupported-opcodes
-description: - Contract is intended for deployment on an EVM-compatible chain other than Ethereum mainnet (zkSync Era, Arbitrum, Optimism, Polygon, BNB Chain, etc.)
+description: '- Contract is intended for deployment on an EVM-compatible chain other than Ethereum mainnet (zkSync Era, Arbitrum, Optimism, Polygon, BNB Chain, etc.)'
+pattern_category: logic-error
+detection_rules:
+  - regex: 'selfdestruct\('
+    severity: Medium
+    confidence: High
+    description: Opcode/functionality that can be unsupported or altered on target chains
+  - regex: '\.transfer\('
+    severity: Low
+    confidence: Low
+    description: transfer stipend behavior may break on non-mainnet EVMs
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/unused-variables/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: unused-variables
-description: - Contract declares state variables, local variables, function parameters, or imports that are never referenced
+description: '- Contract declares state variables, local variables, function parameters, or imports that are never referenced'
+pattern_category: logic-error
+detection_rules:
+  - regex: '(uint256|address|bool|bytes|string|mapping)\s+\w+\s*;'
+    severity: Informational
+    confidence: Low
+    swc: SWC-131
+    description: Declaration pattern that can surface potentially unused variables
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/use-of-deprecated-functions/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: use-of-deprecated-functions
-description: - Contract uses Solidity functions, keywords, or language features that have been deprecated or removed
+description: '- Contract uses Solidity functions, keywords, or language features that have been deprecated or removed'
+pattern_category: logic-error
+detection_rules:
+  - regex: '(suicide|sha3|block\.blockhash|msg\.gas)\('
+    severity: Informational
+    confidence: High
+    swc: SWC-111
+    description: Deprecated Solidity built-ins or aliases
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/weak-sources-randomness/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: weak-sources-randomness
-description: - Contract generates \"random\" values using on-chain data: `block.timestamp`, `blockhash`, `block.difficulty` / `block.prevrandao`, `block.number`, or combinations thereof
+description: '- Contract generates "random" values using on-chain data: `block.timestamp`, `blockhash`, `block.difficulty` / `block.prevrandao`, `block.number`, or combinations thereof'
+pattern_category: logic-error
+detection_rules:
+  - regex: '(block\.timestamp|block\.prevrandao|block\.difficulty|blockhash)\b'
+    severity: Medium
+    confidence: Medium
+    swc: SWC-120
+    description: On-chain attributes used as randomness source
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->