audit-system 2.0.0

package/obsidian-vault/hypotheses/bridge-protocol-template.md

@@ -0,0 +1,254 @@
+# Hypothesis Template: Bridge Protocol
+
+## Protocol Context
+- **Type:** Cross-Chain Bridge / Token Wrapper / Message Relay
+- **Key Components:** Lock/mint mechanism, validators/oracles, message passing, replay protection
+- **Critical Invariants:** Wrapped supply = locked amount, message uniqueness, validator consensus
+
+---
+
+## Assumption Mapping
+
+### Developer Assumptions About Validators
+```
+ASSUMPTION: Validators are honest and independent
+REALITY: Validators can be compromised or collude
+HYPOTHESIS: Threshold signature scheme can be attacked
+
+ASSUMPTION: Validator set is secure
+REALITY: Validator addition/removal may have bugs
+HYPOTHESIS: Attacker can add controlled validator
+```
+
+### Developer Assumptions About Messages
+```
+ASSUMPTION: Each message is unique and non-replayable
+REALITY: Replay protection may have edge cases
+HYPOTHESIS: Same message can be executed multiple times
+
+ASSUMPTION: Message data cannot be tampered
+REALITY: Signature verification may have bugs
+HYPOTHESIS: Modify message content while keeping valid signature
+```
+
+### Developer Assumptions About Locked Tokens
+```
+ASSUMPTION: Locked tokens remain secure until redemption
+REALITY: Lock mechanism may be bypassed
+HYPOTHESIS: Direct transfer or reentrancy bypasses lock
+
+ASSUMPTION: Wrapped supply always matches locked
+REALITY: Minting may not be properly backed
+HYPOTHESIS: Mint unwrapped tokens without locking
+```
+
+---
+
+## Attack Vectors Specific to Bridges
+
+### 1. Signature Malleability / Replay Attack
+```solidity
+HYPOTHESIS ID: H-BRIDGE-001
+ASSUMPTION BROKEN: "Each bridge message can only be executed once"
+VIOLATION METHOD: Replay valid signature on different chain or with modified data
+PRECONDITIONS:
+  - Replay protection uses simple nonce or hash
+  - Chain ID not included in signature
+  - Signature scheme allows malleability (ECDSA s-value)
+ATTACK SEQUENCE:
+  1. Observe valid bridge transaction
+  2. Modify signature (malleability) or reuse with different parameters
+  3. Execute same transfer again
+  4. Or: Execute on wrong chain if Chain ID not checked
+SUCCESS CONDITION: Same deposit redeemed multiple times
+ESTIMATED IMPACT: Infinite minting of wrapped tokens
+NOVELTY: Signature scheme specific vulnerability
+```
+
+### 2. Validator Threshold Attack
+```solidity
+HYPOTHESIS ID: H-BRIDGE-002
+ASSUMPTION BROKEN: "Validator threshold prevents malicious consensus"
+REALITY: Attacker can control enough validators
+PRECONDITIONS:
+  - Threshold < 100% (e.g., 5/9 validators)
+  - Validator set can be influenced
+ATTACK SEQUENCE:
+  1. Gain control of threshold number of validators
+     - Sybil attack if validator selection is weak
+     - Bribe or compromise existing validators
+     - Exploit validator rotation mechanism
+  2. Sign fraudulent withdrawal
+  3. Drain bridge liquidity
+SUCCESS CONDITION: Fraudulent withdrawal approved
+ESTIMATED IMPACT: Full bridge drain
+NOVELTY: Governance/economic attack on validator set
+```
+
+### 3. Lock/Unlock Reentrancy
+```solidity
+HYPOTHESIS ID: H-BRIDGE-003
+ASSUMPTION BROKEN: "Lock mechanism is reentrancy-safe"
+REALITY: External calls during lock/unlock can be exploited
+PRECONDITIONS:
+  - Lock function makes external call (token callback, event)
+  - State updated after external call
+ATTACK SEQUENCE:
+  1. Call bridge lock function
+  2. In callback, call lock function again
+  3. State not updated, same tokens "locked" twice
+  4. Receive double wrapped tokens
+  OR:
+  1. Initiate withdrawal
+  2. Reenter during transfer
+  3. Withdraw multiple times before balance updated
+SUCCESS CONDITION: Wrapped tokens > locked tokens
+ESTIMATED IMPACT: Unbacked wrapped tokens, bridge insolvency
+NOVELTY: Bridge-specific reentrancy pattern
+```
+
+### 4. Chain ID / Domain Separation Bypass
+```solidity
+HYPOTHESIS ID: H-BRIDGE-004
+ASSUMPTION BROKEN: "Messages are valid only on specific chain"
+REALITY: Chain ID not properly checked in signature
+PRECONDITIONS:
+  - Signature does not include chainId
+  - Same validator set across chains
+ATTACK SEQUENCE:
+  1. Get valid signature from Chain A
+  2. Replay exact same signature on Chain B
+  3. Validators approve because signature is valid
+  4. Double-spend same deposit on multiple chains
+SUCCESS CONDITION: Same deposit redeemed on multiple chains
+ESTIMATED IMPACT: Multiple wrapped tokens for single deposit
+NOVELTY: Cross-chain replay
+```
+
+### 5. Price/Value Discrepancy Attack
+```solidity
+HYPOTHESIS ID: H-BRIDGE-005
+ASSUMPTION BROKEN: "Bridge correctly values assets across chains"
+REALITY: Different chains may have different price oracles
+PRECONDITIONS:
+  - Bridge handles multiple assets
+  - Value calculation differs across chains
+ATTACK SEQUENCE:
+  1. Deposit overvalued asset on Chain A
+  2. Receive credit based on inflated value
+  3. Withdraw undervalued asset on Chain B
+  4. Profit from discrepancy
+SUCCESS CONDITION: Withdraw value > deposit value
+ESTIMATED IMPACT: Gradual bridge drain through arbitrage
+NOVELTY: Economic exploitation of price oracle differences
+```
+
+### 6. Message Ordering / Front-Running
+```solidity
+HYPOTHESIS ID: H-BRIDGE-006
+ASSUMPTION BROKEN: "Message order does not affect security"
+REALITY: Ordering can be exploited for front-running
+PRECONDITIONS:
+  - Messages processed in received order
+  - No commitment scheme
+ATTACK SEQUENCE:
+  1. Observe large bridge transfer in mempool
+  2. Front-run with own transfer
+  3. Manipulate state (price, liquidity) before victim
+  4. Extract value from price movement
+SUCCESS CONDITION: Profit from front-running
+ESTIMATED IMPACT: Systematic MEV extraction
+NOVELTY: Bridge-specific MEV pattern
+```
+
+---
+
+## Invariants to Test
+
+```solidity
+// INVARIANT 1: Wrapped supply = locked amount
+assert(wrappedToken.totalSupply() == lockedToken.balanceOf(bridge));
+
+// INVARIANT 2: Each message executed exactly once
+assert(!executedMessages[messageHash]);
+
+// INVARIANT 3: Validator threshold properly enforced
+assert(validSignatures >= threshold);
+
+// INVARIANT 4: Chain ID included in all signatures
+// (Test by attempting replay on different chain)
+
+// INVARIANT 5: No reentrancy during lock/unlock
+// (Use reentrancy guard or checks-effects-interactions)
+```
+
+---
+
+## Foundry Test Skeleton
+
+```solidity
+contract BridgeHypothesisTest is Test {
+    IBridge bridge;
+    IERC20 lockedToken;
+    IERC20 wrappedToken;
+    address[] validators;
+
+    function test_signatureReplay() public {
+        // Setup: Create valid bridge signature
+        // Attack: Modify signature or replay on different chain
+        // Assert: Same message executed twice
+    }
+
+    function test_validatorThresholdAttack() public {
+        // Setup: Create malicious validators
+        // Attack: Reach threshold with controlled validators
+        // Assert: Fraudulent withdrawal approved
+    }
+
+    function test_lockReentrancy() public {
+        // Setup: Malicious contract as depositor
+        // Attack: Reenter during lock callback
+        // Assert: Double tokens minted
+    }
+
+    function test_chainIdBypass() public {
+        // Setup: Signature from Chain A
+        // Attack: Replay on Chain B (fork test)
+        // Assert: Valid execution on wrong chain
+    }
+
+    function test_valueDiscrepancy() public {
+        // Setup: Multi-asset bridge with different oracles
+        // Attack: Deposit overvalued, withdraw undervalued
+        // Assert: Profit from discrepancy
+    }
+}
+```
+
+---
+
+## Related Vulnerabilities
+- [[../vulnerabilities/reentrancy]]
+- [[../vulnerabilities/oracle-manipulation]]
+- [[../vulnerabilities/access-control]]
+
+---
+
+## Real-World Bridge Exploits (Reference)
+| Bridge | Year | Loss | Vector |
+|--------|------|------|--------|
+| Ronin | 2022 | $625M | Validator key compromise (5/9 threshold) |
+| Wormhole | 2022 | $325M | Signature verification bypass |
+| Nomad | 2022 | $190M | Replay attack (merkle root replay) |
+| Harmony | 2022 | $100M | Multi-sig compromise (2/5 threshold) |
+| Qubit | 2022 | $80M | Fake deposit proof |
+
+---
+
+## Validation Checklist
+- [ ] Hypothesis accounts for cross-chain complexity
+- [ ] Considers validator economics
+- [ ] Tests signature verification thoroughly
+- [ ] Checks replay protection on all chains
+- [ ] Verifies wrapped supply matches locked
+- [ ] Considers MEV and front-running vectors

package/obsidian-vault/hypotheses/dex-protocol-template.md

@@ -0,0 +1,185 @@
+# Hypothesis Template: DEX Protocol
+
+## Protocol Context
+- **Type:** DEX / AMM / Order Book
+- **Key Components:** Liquidity pools, price oracle, swap logic, LP tokens
+- **Critical Invariants:** Constant product (x*y=k), price accuracy, LP share correctness
+
+---
+
+## Assumption Mapping
+
+### Developer Assumptions About Price
+```
+ASSUMPTION: Spot price accurately reflects market price
+REALITY: Spot price can be manipulated with flash loans
+HYPOTHESIS: Attack can manipulate price to extract value from dependent protocols
+
+ASSUMPTION: TWAP cannot be manipulated within single block
+REALITY: Multiple swaps in same block can affect TWAP window
+HYPOTHESIS: Gradual manipulation over TWAP period
+```
+
+### Developer Assumptions About Liquidity
+```
+ASSUMPTION: LP providers are honest participants
+REALITY: LP can be malicious with majority liquidity
+HYPOTHESIS: Malicious LP can drain fees or manipulate exits
+
+ASSUMPTION: Liquidity is always available for swaps
+REALITY: Liquidity can be removed atomically
+HYPOTHESIS: Sandwich attack with liquidity removal
+```
+
+### Developer Assumptions About LP Tokens
+```
+ASSUMPTION: LP token supply matches pool reserves
+REALITY: Fee-on-transfer LP tokens break accounting
+HYPOTHESIS: Use malicious LP token with fee-on-transfer
+
+ASSUMPTION: LP token transfers are simple
+REALITY: LP token may have callbacks or hooks
+HYPOTHESIS: Reentrancy via LP token callback
+```
+
+---
+
+## Attack Vectors Specific to DEX
+
+### 1. Flash Loan Price Manipulation
+```solidity
+HYPOTHESIS ID: H-DEX-001
+ASSUMPTION BROKEN: "Price cannot be manipulated without significant capital"
+VIOLATION METHOD: Flash loan + massive swap + reverse swap
+PRECONDITIONS:
+  - Pool has insufficient liquidity relative to flash loan capacity
+  - No price sanity checks
+  - Dependent protocol reads spot price
+ATTACK SEQUENCE:
+  1. Flash loan 10M USDC
+  2. Swap USDC→ETH, pushing ETH price 10x
+  3. Call vulnerable protocol that reads manipulated price
+  4. Extract over-collateralized loan or liquidate unfairly
+  5. Swap ETH→USDC (reverse)
+  6. Repay flash loan
+SUCCESS CONDITION: Profit > flash loan fee + gas
+ESTIMATED IMPACT: Full protocol insolvency
+NOVELTY: Specific to this pool's liquidity depth
+```
+
+### 2. Liquidity Removal Attack
+```solidity
+HYPOTHESIS ID: H-DEX-002
+ASSUMPTION BROKEN: "Liquidity is stable during user operations"
+VIOLATION METHOD: Atomic liquidity add/remove sandwich
+PRECONDITIONS:
+  - User transaction visible in mempool
+  - No slippage protection or weak checks
+ATTACK SEQUENCE:
+  1. Front-run: Add liquidity
+  2. Victim: Swaps at worse rate due to added liquidity
+  3. Back-run: Remove liquidity + captured fees
+SUCCESS CONDITION: Captured value > gas costs
+ESTIMATED IMPACT: Systematic value extraction from all traders
+NOVELTY: MEV extraction pattern
+```
+
+### 3. Fee-on-Transfer Token Attack
+```solidity
+HYPOTHESIS ID: H-DEX-003
+ASSUMPTION BROKEN: "token.transfer(amount) transfers exactly amount"
+VIOLATION METHOD: Use malicious token with 99% fee
+PRECONDITIONS:
+  - DEX accepts arbitrary tokens
+  - Accounting assumes transferIn == transferOut
+ATTACK SEQUENCE:
+  1. Deposit malicious token with fee
+  2. DEX credits based on expected amount
+  3. Withdraw: DEX sends less due to fee
+  4. DEX absorbs loss or breaks invariant
+SUCCESS CONDITION: DEX becomes insolvent
+ESTIMATED IMPACT: LP loss proportional to fee discrepancy
+NOVELTY: Token behavior assumption
+```
+
+### 4. Reentrancy via Flash Callback
+```solidity
+HYPOTHESIS ID: H-DEX-004
+ASSUMPTION BROKEN: "Flash loan callback is the only reentry point"
+VIOLATION METHOD: Reenter swap function during callback
+PRECONDITIONS:
+  - Flash loan callback not properly guarded
+  - State updated after external call
+ATTACK SEQUENCE:
+  1. Flash loan token A
+  2. Swap A→B (callback triggered)
+  3. In callback, swap B→A before state update
+  4. Extract profit from price discrepancy
+SUCCESS CONDITION: Profit > flash loan fee
+ESTIMATED IMPACT: Pool drained through repeated swaps
+NOVELTY: Cross-function reentrancy
+```
+
+---
+
+## Invariants to Test
+
+```solidity
+// INVARIANT 1: Pool solvency
+assert(address(pool).balance >= totalLPShares * pricePerShare);
+
+// INVARIANT 2: Price bounds
+assert(currentPrice >= minPrice && currentPrice <= maxPrice);
+
+// INVARIANT 3: LP token accounting
+assert(totalLPShares == sum(allUserBalances));
+
+// INVARIANT 4: Constant product (for AMM)
+assert(reserveA * reserveB >= initialK); // Allow increase from fees
+```
+
+---
+
+## Foundry Test Skeleton
+
+```solidity
+contract DEXHypothesisTest is Test {
+    IDEX dex;
+    IMaliciousToken maliciousToken;
+    address flashLoanProvider;
+
+    function test_flashLoanPriceManipulation() public {
+        // Setup: Get flash loan, identify target pool
+        // Attack: Execute swap sequence
+        // Assert: Price was manipulated and profit extracted
+    }
+
+    function test_feeOnTransferDrain() public {
+        // Setup: Deposit malicious LP token
+        // Attack: Trigger withdrawal
+        // Assert: Pool accounting broken
+    }
+
+    function test_liquiditySandwich() public {
+        // Setup: Identify pending swap in mempool
+        // Attack: Add/remove liquidity around victim tx
+        // Assert: Value extracted from victim
+    }
+}
+```
+
+---
+
+## Related Vulnerabilities
+- [[../vulnerabilities/oracle-manipulation]]
+- [[../vulnerabilities/flash-loan-attack]]
+- [[../attack-patterns/state-inconsistency]]
+
+---
+
+## Validation Checklist
+- [ ] Hypothesis is testable with Foundry
+- [ ] Preconditions are achievable
+- [ ] Attack sequence is specific to THIS DEX
+- [ ] Would NOT be found by Slither/Mythril
+- [ ] Economic incentive exists for attacker

package/obsidian-vault/hypotheses/governance-protocol-template.md

@@ -0,0 +1,263 @@
+# Hypothesis Template: Governance Protocol
+
+## Protocol Context
+- **Type:** DAO / Governance / Voting System
+- **Key Components:** Proposal creation, voting mechanisms, timelocks, execution
+- **Critical Invariants:** One token = one vote, quorum requirements, execution delay
+
+---
+
+## Assumption Mapping
+
+### Developer Assumptions About Voting Power
+```
+ASSUMPTION: Voting power accurately represents stakeholder interest
+REALITY: Voting power can be borrowed or manipulated
+HYPOTHESIS: Flash loan voting allows proposal capture
+
+ASSUMPTION: Voters are long-term stakeholders
+REALITY: Governance tokens can be traded or borrowed
+HYPOTHESIS: Short-term actors can capture long-term decisions
+```
+
+### Developer Assumptions About Proposal Process
+```
+ASSUMPTION: Proposals are submitted in good faith
+REALITY: Proposals can be malicious or exploitative
+HYPOTHESIS: Malicious proposal can drain treasury
+
+ASSUMPTION: Timelock provides adequate review time
+REALITY: Timelock can be bypassed or rushed
+HYPOTHESIS: Emergency mechanisms bypass timelock
+```
+
+### Developer Assumptions About Execution
+```
+ASSUMPTION: Proposal execution is atomic and safe
+REALITY: Execution may have reentrancy or ordering issues
+HYPOTHESIS: Execution can be manipulated mid-flight
+```
+
+---
+
+## Attack Vectors Specific to Governance
+
+### 1. Flash Loan Governance Attack
+```solidity
+HYPOTHESIS ID: H-GOV-001
+ASSUMPTION BROKEN: "Voters have long-term alignment with protocol"
+VIOLATION METHOD: Borrow voting power, pass malicious proposal, repay
+PRECONDITIONS:
+  - Voting power based on token balance at snapshot
+  - No minimum lockup or delegation period
+  - Proposal threshold achievable with flash loan
+ATTACK SEQUENCE:
+  1. Flash loan massive amount of governance tokens
+  2. Delegate voting power to attacker address
+  3. Create and vote on malicious proposal (e.g., "send treasury to attacker")
+  4. Proposal passes with borrowed voting power
+  5. Execute after timelock (or if no timelock)
+  6. Repay flash loan (if same-block execution possible)
+  OR wait for timelock with rented tokens
+SUCCESS CONDITION: Malicious proposal passes and executes
+ESTIMATED IMPACT: Treasury drain, protocol capture
+NOVELTY: Governance-specific flash attack
+```
+
+### 2. Proposal Front-Running
+```solidity
+HYPOTHESIS ID: H-GOV-002
+ASSUMPTION BROKEN: "Proposal order does not affect outcomes"
+REALITY: Competing proposals can pre-empt legitimate ones
+PRECONDITIONS:
+  - Multiple proposals can coexist
+  - First proposal to reach quorum executes
+ATTACK SEQUENCE:
+  1. Monitor mempool for legitimate proposal
+  2. Front-run with competing proposal (similar but malicious)
+  3. Use flash loan or pre-positioned tokens to vote first
+  4. Legitimate proposal becomes irrelevant
+SUCCESS CONDITION: Attacker proposal executes instead of legitimate one
+ESTIMATED IMPACT: Governance capture, user funds at risk
+NOVELTY: Proposal-level MEV
+```
+
+### 3. Vote Manipulation Through Token Economics
+```solidity
+HYPOTHESIS ID: H-GOV-003
+ASSUMPTION BROKEN: "Token distribution reflects governance power fairly"
+REALITY: Token concentration allows capture
+PRECONDITIONS:
+  - Top holders control majority of votes
+  - No quadratic voting or caps
+ATTACK SEQUENCE:
+  1. Accumulate or borrow majority of tokens
+  2. Delegate to single address
+  3. Pass any proposal regardless of community interest
+  4. Or: Hold community hostage for ransom
+SUCCESS CONDITION: Attacker controls all governance outcomes
+ESTIMATED IMPACT: Governance centralization, community disempowerment
+NOVELTY: Economic capture of decentralized governance
+```
+
+### 4. Timelock Bypass Through Emergency Mechanisms
+```solidity
+HYPOTHESIS ID: H-GOV-004
+ASSUMPTION BROKEN: "Timelock cannot be bypassed"
+REALITY: Emergency functions may override timelock
+PRECONDITIONS:
+  - Emergency pause or guardian exists
+  - Guardian has elevated privileges
+ATTACK SEQUENCE:
+  1. Compromise or coerce guardian (economic attack, social engineering)
+  2. Use emergency function to bypass timelock
+  3. Execute malicious action immediately
+  4. Disable governance response
+SUCCESS CONDITION: Action executed without timelock delay
+ESTIMATED IMPACT: Immediate protocol capture
+NOVELTY: Privilege escalation through emergency mechanism
+```
+
+### 5. Quorum Manipulation
+```solidity
+HYPOTHESIS ID: H-GOV-005
+ASSUMPTION BROKEN: "Quorum requirement ensures broad participation"
+REALITY: Quorum can be manipulated through token economics
+PRECONDITIONS:
+  - Quorum based on outstanding tokens, not active voters
+  - Many tokens are inactive or lost
+ATTACK SEQUENCE:
+  1. Identify inactive token holders (lost keys, dead addresses)
+  2. Calculate effective quorum (much lower than nominal)
+  3. Accumulate just enough active tokens to reach effective quorum
+  4. Pass proposals with tiny fraction of total supply
+SUCCESS CONDITION: Proposal passes with minimal support
+ESTIMATED IMPACT: Minority capture of protocol
+NOVELTY: Quorum calculation exploit
+```
+
+### 6. Proposal Griefing / Censorship
+```solidity
+HYPOTHESIS ID: H-GOV-006
+ASSUMPTION BROKEN: "Legitimate proposals can always be submitted"
+REALITY: Proposal process can be griefed
+PRECONDITIONS:
+  - Proposal requires deposit or fee
+  - No protection against censorship
+ATTACK SEQUENCE:
+  1. Monitor for proposals you oppose
+  2. Outvote or censor before they reach quorum
+  3. Or: Flood governance with spam proposals
+  4. Legitimate proposals cannot get attention or quorum
+SUCCESS CONDITION: Governance gridlock, attacker preferences enforced
+ESTIMATED IMPACT: Governance paralysis
+NOVELTY: Denial of service on governance
+```
+
+### 7. Execution Reentrancy
+```solidity
+HYPOTHESIS ID: H-GOV-007
+ASSUMPTION BROKEN: "Proposal execution is reentrancy-safe"
+REALITY: External calls during execution can be exploited
+PRECONDITIONS:
+  - Proposal execution makes external calls
+  - State updated after external call
+ATTACK SEQUENCE:
+  1. Create proposal that calls malicious contract
+  2. During execution, reenter governance contract
+  3. Modify proposal state or execute again
+  4. Extract value or double-execute
+SUCCESS CONDITION: Proposal executes multiple times or state corrupted
+ESTIMATED IMPACT: Fund loss, governance state corruption
+NOVELTY: Reentrancy in governance execution
+```
+
+---
+
+## Invariants to Test
+
+```solidity
+// INVARIANT 1: Voting power = token balance (or delegated amount)
+assert(votingPower[user] == tokenBalance[user] + delegatedIn[user] - delegatedOut[user]);
+
+// INVARIANT 2: Proposal executed exactly once
+assert(!proposalExecuted[id] || proposal[id].executed);
+
+// INVARIANT 3: Timelock enforced
+assert(block.timestamp >= proposal[id].executionTime);
+
+// INVARIANT 4: Quorum properly calculated
+assert(quorumReached[id] == (votesFor[id] + votesAgainst[id] + votesAbstain[id]) >= quorum);
+
+// INVARIANT 5: No double voting
+for each user: assert(voted[user][proposalId] == false || voteWeight[user] counted once);
+```
+
+---
+
+## Foundry Test Skeleton
+
+```solidity
+contract GovernanceHypothesisTest is Test {
+    IGovernance gov;
+    IERC20 govToken;
+    ITimelock timelock;
+    ITreasury treasury;
+
+    function test_flashLoanGovernanceAttack() public {
+        // Setup: Flash loan provider, governance tokens available
+        // Attack: Borrow, vote, pass malicious proposal, execute, repay
+        // Assert: Treasury drained or protocol captured
+    }
+
+    function test_proposalFrontRunning() public {
+        // Setup: Legitimate proposal pending
+        // Attack: Front-run with competing proposal
+        // Assert: Attacker proposal wins
+    }
+
+    function test_timelockBypass() public {
+        // Setup: Emergency guardian exists
+        // Attack: Compromise guardian, bypass timelock
+        // Assert: Action executed immediately
+    }
+
+    function test_quorumManipulation() public {
+        // Setup: Identify inactive token supply
+        // Attack: Accumulate just enough for effective quorum
+        // Assert: Proposal passes with minimal support
+    }
+
+    function test_executionReentrancy() public {
+        // Setup: Malicious proposal target
+        // Attack: Reenter during execution
+        // Assert: Double execution or state corruption
+    }
+}
+```
+
+---
+
+## Related Vulnerabilities
+- [[../vulnerabilities/reentrancy]]
+- [[../vulnerabilities/access-control]]
+- [[../vulnerabilities/oracle-manipulation]]
+
+---
+
+## Real-World Governance Exploits (Reference)
+| Protocol | Year | Loss | Vector |
+|----------|------|------|--------|
+| Beanstalk | 2022 | $180M | Flash loan governance (majority vote capture) |
+| DAO (Classic) | 2016 | $60M | Reentrancy during execution |
+| Various DAOs | 2023+ | Multiple | Governance token concentration |
+
+---
+
+## Validation Checklist
+- [ ] Hypothesis exploits governance-specific mechanics
+- [ ] Considers flash loan capabilities
+- [ ] Tests timelock and emergency bypasses
+- [ ] Accounts for voting power manipulation
+- [ ] Checks proposal lifecycle thoroughly
+- [ ] Considers economic and social attack vectors