solidity-argus 0.1.0

package/skills/vulnerability-patterns/dos-gas-limit/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: dos-gas-limit
+description: - Contract iterates over a dynamic array or mapping whose size can grow unboundedly
+---
+<!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
+
+# DoS with Block Gas Limit
+
+## Preconditions
+- Contract iterates over a dynamic array or mapping whose size can grow unboundedly
+- The iteration must complete in a single transaction (no batching/pagination)
+- OR: time-sensitive logic where block stuffing by an attacker can delay transaction inclusion
+
+## Vulnerable Pattern
+```solidity
+address[] public recipients;
+
+function addRecipient(address r) external {
+    recipients.push(r); // Array grows without bound
+}
+
+// Push-payment: one tx must process all recipients
+function distributeRewards() external {
+    for (uint256 i = 0; i < recipients.length; i++) {
+        // When recipients.length grows large enough,
+        // this loop exceeds block gas limit and ALWAYS reverts
+        payable(recipients[i]).transfer(reward);
+    }
+}
+```
+
+## Detection Heuristics
+1. Identify all loops (`for`, `while`) in the codebase
+2. For each loop, check if the iteration count depends on a dynamic array or storage structure that can grow over time
+3. If the loop is unbounded and must complete in a single transaction, flag it — it will eventually exceed the block gas limit
+4. Check if the function supports batching or pagination (e.g., `startIndex`, `batchSize` parameters) — if not, flag it
+5. For time-sensitive functions (auctions, deadlines, liquidations), check if an attacker could stuff blocks with high-gas transactions to delay inclusion
+
+## False Positives
+- Loop iterates over a fixed-size or bounded array (e.g., `uint256[10]`, array with a capped `maxLength`)
+- Function supports paginated/batched execution across multiple transactions
+- Loop iteration count is controlled by the caller (e.g., batch size parameter with reasonable max)
+- The array is admin-only appendable and has a practical maximum
+
+## Remediation
+- Replace push-payment (contract sends to all) with pull-payment (recipients withdraw individually)
+- If iteration is unavoidable, add batching/pagination with `startIndex` and `batchSize` parameters
+- Cap array sizes with a maximum length check on push operations
+- For time-sensitive logic, avoid designs where block stuffing can be profitable
+```solidity
+// Pull-payment pattern
+mapping(address => uint256) public pendingWithdrawals;
+
+function claimReward() external {
+    uint256 amount = pendingWithdrawals[msg.sender];
+    pendingWithdrawals[msg.sender] = 0;
+    payable(msg.sender).transfer(amount);
+}
+```

package/skills/vulnerability-patterns/dos-revert/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: dos-revert
+description: - Critical contract logic depends on an external call succeeding
+---
+<!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
+
+# DoS with (Unexpected) Revert
+
+## Preconditions
+- Critical contract logic depends on an external call succeeding
+- A single revert in the external call blocks the entire function
+- OR: strict equality checks on contract balance can be violated by force-sent ETH
+- OR: division by zero is possible due to unvalidated denominators
+
+## Vulnerable Pattern
+```solidity
+// Push-payment: one reverting recipient blocks all payments
+function payAll() external {
+    for (uint256 i = 0; i < recipients.length; i++) {
+        // If ANY recipient reverts (e.g., contract with no receive()),
+        // the entire function reverts — no one gets paid
+        require(payable(recipients[i]).send(amounts[i]), "transfer failed");
+    }
+}
+
+// Strict balance check broken by force-sent ETH
+function withdraw() external {
+    // Attacker sends ETH via selfdestruct, breaking this check
+    require(address(this).balance == expectedBalance, "invariant");
+    _processWithdrawal();
+}
+
+// Division by zero
+function distribute(uint256 totalShares) external {
+    // If totalShares == 0, this reverts and blocks the function
+    uint256 perShare = totalRewards / totalShares;
+}
+```
+
+## Detection Heuristics
+1. Search for loops containing `require` or `assert` on external call results — one failure blocks all iterations
+2. Search for push-payment patterns: contract iterating over recipients and sending ETH/tokens in one transaction
+3. Search for strict balance equality checks (`address(this).balance ==`) — these can be broken by `selfdestruct` or coinbase rewards force-sending ETH
+4. Search for division operations and check if the denominator can be zero
+5. Check for `require(success)` after `.send()` or `.call()` inside loops — this turns a single recipient failure into a full DoS
+6. Look for "highest bidder" or "king of the hill" patterns where the current leader's refund must succeed for a new leader to be set
+
+## False Positives
+- Pull-payment pattern is used (each recipient withdraws individually)
+- The external call target is a trusted, known contract that will not revert
+- Division denominator is guaranteed non-zero by prior checks or invariants
+- Balance checks use `>=` instead of `==`
+- The function handles individual failures gracefully (try/catch, continue on failure)
+
+## Remediation
+- Replace push-payment with pull-payment: let recipients withdraw individually
+- Use `>=` instead of `==` for balance checks to tolerate force-sent ETH
+- Validate all denominators before division: `require(totalShares > 0)`
+- In loops, handle individual call failures without reverting the whole transaction
+- Use try/catch for external calls where failure should not be fatal
+```solidity
+// Pull-payment pattern
+mapping(address => uint256) public pendingWithdrawals;
+
+function claimPayment() external {
+    uint256 amount = pendingWithdrawals[msg.sender];
+    require(amount > 0, "nothing to claim");
+    pendingWithdrawals[msg.sender] = 0;
+    (bool success,) = msg.sender.call{value: amount}("");
+    require(success);
+}
+```

package/skills/vulnerability-patterns/flash-loan-attacks/SKILL.md

@@ -0,0 +1,249 @@
+---
+name: flash-loan-attacks
+description: Flash-loan attack mechanics, exploit archetypes, and mitigations for capital-amplified threats.
+---
+
+<!-- Source: DeFiFoFum/fofum-solidity-skills (MIT) -->
+<!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
+
+# Flash Loan Attack Exploits
+
+## Overview
+
+Flash loans enable borrowing massive amounts with zero collateral, repaid within the same transaction. Attackers use this capital to:
+- Manipulate prices
+- Exploit governance
+- Amplify arbitrage
+- Attack economic assumptions
+
+**Key insight:** Any assumption about "no one would have $100M" is broken by flash loans.
+
+---
+
+## Attack Patterns
+
+### 1. Price Manipulation
+
+```
+1. Flash borrow $100M
+2. Swap to move AMM price
+3. Interact with victim (borrow, liquidate, swap)
+4. Swap back
+5. Repay flash loan
+6. Profit
+```
+
+### 2. Governance Attacks
+
+```
+1. Flash borrow governance tokens
+2. Create proposal or vote
+3. If snapshot-based: exploit timing
+4. Return tokens
+```
+
+```solidity
+// VULNERABLE: Instant voting power
+function vote(uint256 proposalId, bool support) external {
+    uint256 votes = token.balanceOf(msg.sender);  // Current balance!
+    proposals[proposalId].votes += votes;
+}
+
+// SECURE: Historical voting power
+function vote(uint256 proposalId, bool support) external {
+    uint256 votes = token.getPastVotes(msg.sender, proposals[proposalId].snapshot);
+    proposals[proposalId].votes += votes;
+}
+```
+
+### 3. Reentrancy Amplification
+
+Flash loans amplify reentrancy by providing initial capital:
+1. Flash loan large amount
+2. Deposit into vulnerable protocol
+3. Reenter to drain more than deposited
+4. Repay loan with profits
+
+### 4. Collateral Manipulation
+
+```
+1. Flash loan collateral asset
+2. Deposit as collateral in lending protocol
+3. Borrow maximum against it
+4. Manipulate collateral price down
+5. Abandon position (bad debt)
+```
+
+---
+
+## Real Exploits
+
+### Euler Finance (Mar 2023) — $197M
+
+**What happened:**
+- Attacker exploited donateToReserves() function
+- Flash loaned DAI, created leveraged position
+- Used donate function to inflate debt without updating health
+- Triggered liquidation at favorable rate
+
+**Root cause:** donateToReserves() increased liabilities without proper health check
+
+**Lesson:** All state-changing functions must maintain invariants.
+
+### Cream Finance (Oct 2021) — $130M
+
+**What happened:**
+- Attacker used flash loan to manipulate yUSD price
+- Created fake collateral value through price oracle manipulation
+- Borrowed real assets against fake collateral
+
+**Root cause:** Oracle manipulation + flash loan capital
+
+### Beanstalk (Apr 2022) — $182M
+
+**What happened:**
+- Attacker flash loaned governance tokens (BEAN + LP)
+- Achieved quorum for malicious proposal
+- Proposal drained treasury
+- All in one transaction
+
+**Root cause:** No time delay between proposal and execution
+
+**Lesson:** Governance needs timelocks AND snapshot-based voting.
+
+### Pancake Bunny (May 2021) — $45M
+
+**What happened:**
+- Flash loaned BNB
+- Manipulated BUNNY/BNB price
+- Minted excessive BUNNY tokens at wrong price
+- Dumped and repaid
+
+**Root cause:** Flash-loan-vulnerable price calculation
+
+---
+
+## Detection Checklist
+
+- [ ] Does the protocol assume capital constraints ("no one has $100M")?
+- [ ] Can governance actions occur in same block as token acquisition?
+- [ ] Does the protocol use spot prices? (See oracle.md)
+- [ ] Are there any actions profitable only with large capital?
+- [ ] Can positions be opened and closed in same transaction profitably?
+- [ ] Is collateral value determined at time of borrow?
+- [ ] Are there timelocks on sensitive operations?
+- [ ] Does the protocol track historical balances for voting?
+
+## Flash Loan Sources
+
+Attackers can source flash loans from:
+- **Aave** — Largest, 0.09% fee, many assets
+- **dYdX** — No fee (technically flash + repay)
+- **Uniswap V2/V3** — Flash swaps, 0.3% fee
+- **Balancer** — Flash loans, dynamic fee
+- **Maker** — DAI flash mint (up to debt ceiling)
+
+**Combined capital:** $10B+ available in single transaction
+
+## Secure Patterns
+
+### Snapshot-Based Governance
+
+```solidity
+// ERC20Votes pattern
+mapping(address => Checkpoint[]) private _checkpoints;
+
+function getPastVotes(address account, uint256 blockNumber) public view returns (uint256) {
+    require(blockNumber < block.number, "Block not yet mined");
+    return _checkpointsLookup(_checkpoints[account], blockNumber);
+}
+```
+
+### Time-Delayed Actions
+
+```solidity
+uint256 public constant TIMELOCK = 2 days;
+mapping(bytes32 => uint256) public pendingActions;
+
+function queueAction(bytes32 actionHash) external onlyGovernance {
+    pendingActions[actionHash] = block.timestamp + TIMELOCK;
+}
+
+function executeAction(bytes32 actionHash) external {
+    require(pendingActions[actionHash] != 0, "Not queued");
+    require(block.timestamp >= pendingActions[actionHash], "Timelock");
+    delete pendingActions[actionHash];
+    // Execute
+}
+```
+
+### Flash Loan Guards
+
+```solidity
+// Detect if called within flash loan context
+modifier noFlashLoan() {
+    require(
+        block.number > lastDepositBlock[msg.sender],
+        "Same block"
+    );
+    _;
+}
+```
+
+---
+
+## References
+
+- [Flash Loan Attack Taxonomy (Arxiv)](https://arxiv.org/abs/2003.03810)
+- [Beanstalk Exploit Analysis](https://rekt.news/beanstalk-rekt/)
+- [Euler Exploit (BlockSec)](https://blocksec.com/blog/how-the-200m-euler-exploit-worked)
+
+## Supplemental Heuristics (kadenzipfel)
+
+## Preconditions
+- Contract uses `block.timestamp` (or the deprecated `now` alias) for security-sensitive logic
+- The outcome of that logic can be influenced by a timestamp shift within the manipulation window (~15s on PoW chains, slot-fixed on PoS Ethereum but variable on L2s/sidechains)
+- OR: `block.number` is used as a proxy for elapsed time
+
+## Vulnerable Pattern
+```solidity
+// Timestamp as sole randomness source
+function roll() external {
+    // Validator can manipulate block.timestamp to bias outcome
+    uint256 result = uint256(keccak256(abi.encodePacked(block.timestamp))) % 6;
+    if (result == 0) {
+        _payWinner(msg.sender);
+    }
+}
+
+// Tight time window vulnerable to manipulation
+function claimBonus() external {
+    // 15-second window — validator can push timestamp to include/exclude
+    require(block.timestamp >= deadline && block.timestamp <= deadline + 15);
+    _sendBonus(msg.sender);
+}
+```
+
+## Detection Heuristics
+1. Search for `block.timestamp` and `now` (deprecated alias) usage
+2. If used for randomness (e.g., fed into `keccak256` for a random value), flag immediately — this is always exploitable
+3. If used in conditional logic, check the time window: can a ~15-second manipulation affect the outcome?
+4. Search for `block.number` used as a time proxy (e.g., `block.number * 12` for seconds) — flag as fragile since block times change
+5. For L2/sidechain deployments, check chain-specific timestamp guarantees — some have weaker constraints than mainnet PoS
+
+## False Positives
+- `block.timestamp` used only for logging or non-critical display purposes
+- Time windows are large enough (hours/days) that a 15-second manipulation is irrelevant
+- On PoS Ethereum mainnet, timestamps are fixed per 12-second slots — validator manipulation is constrained to slot boundaries, not arbitrary values
+- `block.timestamp` used with a commit-reveal scheme where the timestamp alone doesn't determine the outcome
+
+## Remediation
+- Never use `block.timestamp` for randomness — use Chainlink VRF or another verifiable randomness oracle
+- For time-dependent logic, ensure the acceptable window is significantly larger than the manipulation range
+- Avoid `block.number` as a time proxy; use `block.timestamp` with appropriate tolerance
+- On L2s/sidechains, verify chain-specific timestamp constraints before relying on `block.timestamp`
+```solidity
+// Safe: large time window where 15s manipulation is irrelevant
+require(block.timestamp >= vestingEnd, "still vesting");
+// vestingEnd is months/years away — manipulation doesn't matter
+```

package/skills/vulnerability-patterns/floating-pragma/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: floating-pragma
+description: - Deployable contract uses a floating or range pragma (e.g., `pragma solidity ^0.8.0`, `pragma solidity >=0.8.0`)
+---
+<!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
+
+# Floating Pragma
+
+## Preconditions
+- Deployable contract uses a floating or range pragma (e.g., `pragma solidity ^0.8.0`, `pragma solidity >=0.8.0`)
+- The contract is intended for deployment (not a library or package for external consumption)
+
+## Vulnerable Pattern
+```solidity
+// Floating pragma — could compile with any 0.8.x version
+pragma solidity ^0.8.0;
+
+contract Token {
+    // May be compiled with 0.8.0 (tested) or 0.8.25 (untested)
+    // Different compiler versions may have different bugs or behavior
+    mapping(address => uint256) public balances;
+}
+
+// Range pragma — even wider range
+pragma solidity >=0.7.0 <0.9.0;
+```
+
+## Detection Heuristics
+1. Search for `pragma solidity` declarations in all `.sol` files
+2. If the pragma contains `^`, `>=`, `>`, or a range (e.g., `>=0.8.0 <0.9.0`), flag it as floating
+3. Check if the file is a deployable contract or a library/package — libraries are exempt
+4. A locked pragma looks like `pragma solidity 0.8.20;` (exact version, no caret or range)
+5. Check if different files in the project use different Solidity versions — this creates inconsistency risk
+
+## False Positives
+- Libraries and packages intended for external consumption (e.g., npm packages, OpenZeppelin-style libraries) appropriately use floating pragmas for compatibility
+- Interface files (`.sol` files containing only `interface` definitions) may use floating pragmas
+- The floating pragma is in a test file, not a production contract
+
+## Remediation
+- Use locked pragmas for all deployable contracts: `pragma solidity 0.8.20;`
+- Verify the locked version is tested and free of known compiler bugs
+- Maintain consistent Solidity versions across the project
+```solidity
+// Locked pragma — deterministic compilation
+pragma solidity 0.8.20;
+
+contract Token {
+    mapping(address => uint256) public balances;
+}
+```

package/skills/vulnerability-patterns/hash-collision/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: hash-collision
+description: - Contract uses `abi.encodePacked()` to encode data before hashing (typically with `keccak256`)
+---
+<!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
+
+# Hash Collision with abi.encodePacked()
+
+## Preconditions
+- Contract uses `abi.encodePacked()` to encode data before hashing (typically with `keccak256`)
+- Two or more adjacent arguments in the `encodePacked` call are variable-length types (strings, bytes, dynamic arrays)
+- The resulting hash is used for authentication, deduplication, or signature verification
+
+## Vulnerable Pattern
+```solidity
+function verify(string memory a, string memory b, bytes memory sig) external {
+    // abi.encodePacked("a", "bc") == abi.encodePacked("ab", "c")
+    // Attacker shifts bytes between arguments to forge a valid hash
+    bytes32 hash = keccak256(abi.encodePacked(a, b));
+    require(ECDSA.recover(hash, sig) == trustedSigner);
+    _execute(a, b);
+}
+
+// Array variant:
+// abi.encodePacked([addr1, addr2], [addr3])
+//   == abi.encodePacked([addr1], [addr2, addr3])
+```
+
+## Detection Heuristics
+1. Search for `abi.encodePacked(` calls
+2. Check how many arguments are variable-length types (string, bytes, dynamic arrays like `address[]`, `uint256[]`)
+3. If two or more adjacent arguments are variable-length, flag it — elements can be shifted between arguments to produce an identical encoding
+4. Check if the packed result feeds into `keccak256` for security-sensitive purposes (signature verification, access control, deduplication)
+5. If only one argument is variable-length, or all arguments are fixed-length (address, uint256, bool), it is safe
+
+## False Positives
+- Only one argument is a variable-length type (no adjacent dynamic types to shift between)
+- All arguments are fixed-length types (address, uint256, bytes32, bool, etc.)
+- `abi.encode()` is used instead of `abi.encodePacked()` (includes length prefixes, no collision)
+- The hash is not used for any security-sensitive purpose
+
+## Remediation
+- Replace `abi.encodePacked()` with `abi.encode()` — it includes length prefixes that prevent collisions
+- If `encodePacked` must be used for gas efficiency, ensure at most one argument is a variable-length type
+- Alternatively, separate variable-length arguments with fixed-length delimiters
+```solidity
+// Safe: abi.encode includes length prefixes
+bytes32 hash = keccak256(abi.encode(a, b));
+
+// Also safe: only one variable-length argument
+bytes32 hash = keccak256(abi.encodePacked(fixedAddr, dynamicString));
+```

package/skills/vulnerability-patterns/inadherence-to-standards/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: inadherence-to-standards
+description: - Contract claims to implement a standard (ERC20, ERC721, ERC1155, etc.) but deviates from the specification
+---
+<!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
+
+# Inadherence to Standards
+
+## Preconditions
+- Contract claims to implement a standard (ERC20, ERC721, ERC1155, etc.) but deviates from the specification
+- OR: contract integrates external tokens assuming strict standard compliance without handling common deviations
+
+## Vulnerable Pattern
+```solidity
+// Non-compliant ERC20: missing return value on transfer
+// (matches USDT, BNB behavior — breaks callers that check return)
+function transfer(address to, uint256 amount) external {
+    balances[msg.sender] -= amount;
+    balances[to] += amount;
+    // Missing: return true;
+    // Missing: emit Transfer(msg.sender, to, amount);
+}
+
+// Caller assumes strict compliance — breaks on non-compliant tokens
+function depositToken(IERC20 token, uint256 amount) external {
+    // Reverts on tokens that don't return bool (USDT)
+    require(token.transfer(address(this), amount), "transfer failed");
+    deposits[msg.sender] += amount;
+    // Bug: doesn't account for fee-on-transfer tokens
+    // Actual received amount may be less than `amount`
+}
+```
+
+## Detection Heuristics
+1. For token implementations: check that all required functions, return values, and events match the standard exactly (e.g., ERC20 requires `transfer` returns `bool` and emits `Transfer`)
+2. For token integrations: check if `SafeERC20` is used for `transfer`/`transferFrom`/`approve` calls — raw IERC20 calls break on non-compliant tokens
+3. Check for hardcoded assumptions: 18 decimals, no fee-on-transfer, no rebasing, no blocklists
+4. For fee-on-transfer tokens: check if the contract uses balance-before/balance-after pattern to measure actual received amount
+5. Check for missing `safeTransfer`/`safeTransferFrom` wrappers
+
+## False Positives
+- The contract explicitly documents that it only supports fully compliant ERC20 tokens and enforces this via a whitelist
+- `SafeERC20` from OpenZeppelin is used, which handles missing return values
+- The contract checks balance differences to account for fee-on-transfer
+
+## Remediation
+- For token implementations: strictly follow the standard — include all return values, events, and function signatures
+- For token integrations: use OpenZeppelin's `SafeERC20` for all token interactions
+- Use balance-before/balance-after pattern for fee-on-transfer support
+- Don't hardcode decimals — read from the token contract
+```solidity
+import {SafeERC20, IERC20} from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
+using SafeERC20 for IERC20;
+
+function depositToken(IERC20 token, uint256 amount) external {
+    uint256 balBefore = token.balanceOf(address(this));
+    token.safeTransferFrom(msg.sender, address(this), amount);
+    uint256 received = token.balanceOf(address(this)) - balBefore;
+    deposits[msg.sender] += received;
+}
+```

package/skills/vulnerability-patterns/incorrect-constructor/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: incorrect-constructor
+description: - Solidity version <0.4.22 where constructors are named functions matching the contract name
+---
+<!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
+
+# Incorrect Constructor Name
+
+## Preconditions
+- Solidity version <0.4.22 where constructors are named functions matching the contract name
+- The function name does not exactly match the contract name (typo, case mismatch, or contract renamed without updating the constructor)
+
+## Vulnerable Pattern
+```solidity
+// Solidity <0.4.22: constructor is a named function
+contract Owned {
+    address public owner;
+
+    // Typo: "owned" != "Owned" (case mismatch)
+    // This becomes a regular public function anyone can call
+    function owned() public {
+        owner = msg.sender;
+    }
+}
+
+// Contract renamed but constructor not updated
+contract Treasury {
+    address public owner;
+
+    // Was "Wallet" before rename — now a regular public function
+    function Wallet() public {
+        owner = msg.sender;
+    }
+}
+```
+
+## Detection Heuristics
+1. Check the Solidity version: if >=0.4.22 and the `constructor` keyword is used, this vulnerability does not apply
+2. For <0.4.22 contracts: find the function that sets initial state (owner, parameters) and verify its name exactly matches the contract name (case-sensitive)
+3. Search for public/external functions that set `owner` or perform one-time initialization — these may be misnamed constructors
+4. Check if the contract was renamed at any point (git history, comments) but the constructor function was not updated
+5. Flag any named function that appears to perform initialization logic (sets owner, initializes critical state) but doesn't match the contract name
+
+## False Positives
+- Solidity >=0.4.22 using the `constructor` keyword (enforced by compiler)
+- The function is intentionally a public initializer (e.g., in proxy patterns) with proper access control
+
+## Remediation
+- Upgrade to Solidity >=0.4.22 and use the `constructor` keyword
+- For legacy contracts, verify the constructor function name exactly matches the contract name
+```solidity
+// Modern Solidity: compiler-enforced constructor
+contract Owned {
+    address public owner;
+
+    constructor() {
+        owner = msg.sender;
+    }
+}
+```

package/skills/vulnerability-patterns/incorrect-inheritance-order/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: incorrect-inheritance-order
+description: - Contract uses multiple inheritance (`is ContractA, ContractB, ...`)
+---
+<!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
+
+# Incorrect Inheritance Order
+
+## Preconditions
+- Contract uses multiple inheritance (`is ContractA, ContractB, ...`)
+- Two or more parent contracts define a function with the same name and signature
+- The inheritance order (left-to-right) does not match the developer's intended resolution
+
+## Vulnerable Pattern
+```solidity
+contract Ownable {
+    function owner() public view virtual returns (address) {
+        return _owner; // Returns EOA owner
+    }
+}
+
+contract Governance {
+    function owner() public view virtual returns (address) {
+        return governance; // Returns governance contract
+    }
+}
+
+// C3 linearization: rightmost (Ownable) takes precedence
+// Developer intended Governance.owner() but gets Ownable.owner()
+contract Treasury is Governance, Ownable {
+    // owner() resolves to Ownable (rightmost) — may not be intended
+    // Should be: is Ownable, Governance (if Governance should win)
+}
+```
+
+## Detection Heuristics
+1. Identify all contracts using multiple inheritance (`is A, B, C`)
+2. For each inheritance chain, check if parent contracts define functions with the same name and signature
+3. Verify the inheritance order follows general-to-specific (most base first, most derived last) — Solidity's C3 linearization gives precedence to the rightmost parent
+4. Check `override` specifiers: `override(A, B)` should explicitly list which parents are being overridden
+5. Trace the actual resolution order and compare against documented or intended behavior
+
+## False Positives
+- Only one parent defines the function (no ambiguity)
+- The contract explicitly overrides the function with `override(A, B)` and provides its own implementation
+- The inheritance order is intentionally general-to-specific and produces the correct resolution
+
+## Remediation
+- Order inheritance from most base to most derived (general-to-specific, left-to-right)
+- Explicitly override conflicting functions and specify which parents: `override(ContractA, ContractB)`
+- Test function resolution in complex hierarchies
+```solidity
+// Correct: general-to-specific order
+contract Treasury is Ownable, Governance {
+    function owner() public view override(Ownable, Governance) returns (address) {
+        return Governance.owner(); // Explicit resolution
+    }
+}
+```