The theory: Systemic complexity vs linear review

1. Decomposition: Slicing the system into isolated modules with clear boundaries.
2. Invariant Definition: Defining the "Laws of Physics" for each module.
3. Local Verification: Proving the module obeys its laws in isolation.
4. Compositional Analysis: Verifying that the modules interact safely.

Phase 1: The Divide (Architectural Mapping)

1. The Vault/Asset Cluster: Where is the capital? (ERC20s, ETH balances).
2. The Logic Cluster: The "brains." (Pricing, Swapping, Rate calculation).
3. The Data/Oracle Cluster: External truth sources.
4. The Governance Cluster: Admin powers and time-locks.

General Application: This applies to any system. In a Lending Protocol, we separate the Comptroller (Logic) from the cToken (Vault). In a Bridge, we separate the Relayer (Governance) from the Custody (Vault). The goal is always to identify the Trust Boundaries—where does data enter, and where does money leave?

Visualizing Uniswap V2

• The Factory: The Governance/Admin cluster. It deploys pairs and manages the feeTo address.
• The Pair: The Logic and Vault cluster. This is the "God Class" of the protocol.

Phase 2: The Invariants (Defining Solvency)

The Solvency Invariant: After any Swap operation, the product of the reserves must be greater than or equal to the product before the swap (adjusting for fees).

Phase 3: The Conquer (Case Study: UniswapV2Pair.sol)

1. The asset layer check (optimistic transfer)

1// UniswapV2Pair.sol
2function swap(uint amount0Out, uint amount1Out, address to, bytes calldata data) external lock {
3    require(amount0Out > 0 || amount1Out > 0, 'UniswapV2: INSUFFICIENT_OUTPUT_AMOUNT');
4    (uint112 _reserve0, uint112 _reserve1,) = getReserves(); 
5    
6    // ... logic ...
7
8    // OPTIMISTIC TRANSFER
9    if (amount0Out > 0) _token0.safeTransfer(to, amount0Out); 
10    if (amount1Out > 0) _token1.safeTransfer(to, amount1Out);
11    
12    // FLASH LOAN HOOK
13    if (data.length > 0) IUniswapV2Callee(to).uniswapV2Call(msg.sender, amount0Out, amount1Out, data);
14    
15    // ... check invariants ...
16}

2. The logic layer check (enforcing k)

1    uint balance0 = IERC20(_token0).balanceOf(address(this));
2    uint balance1 = IERC20(_token1).balanceOf(address(this));
3
4    uint amount0In = balance0 > _reserve0 - amount0Out ? balance0 - (_reserve0 - amount0Out) : 0;
5    uint amount1In = balance1 > _reserve1 - amount1Out ? balance1 - (_reserve1 - amount1Out) : 0;

• State: The contract trusts balanceOf(address(this)).
• Logic: It calculates amountIn based on the delta between the current balance and the cached reserve.

3. The vulnerability hunt: fee-on-transfer tokens

• Expectation: Logic layer assumes a user transfer of 100 tokens results in a balanceOf increase of 100.
• Reality: Certain tokens (USDT, PAXG) levy a fee on transfer. A user sends 100, the contract receives 99.

Phase 4: The Reassembly (Interaction Risks)

The reentrancy vector

1modifier lock() {
2    require(unlocked == 1, 'UniswapV2: LOCKED');
3    unlocked = 0;
4    _;
5    unlocked = 1;
6}

Phase 5: The Verification (The Proof)

Property-based testing (Foundry)

1// Foundry Invariant Test
2contract UniswapInvariant is Test {
3    UniswapV2Pair pair;
4
5    function invariant_k_never_decreases() public {
6        (uint112 reserve0, uint112 reserve1,) = pair.getReserves();
7        uint k = uint(reserve0) * uint(reserve1);
8        
9        // Assert that K is always maintained (allowing for small fee growth)
10        assert(k >= initial_k);
11    }
12}

Conclusion

1. Divide: Separate the Money (Vaults) from the Math (Logic).
2. Define: Establish the Invariants (e.g., $x \cdot y = k$).
3. Conquer: Verify the implementation of those invariants in isolation.
4. Verify: Check the seams (Reentrancy, Interoperability).

Applying This to Your Own Audits

1. Start with Documentation: Before reading code, map the protocol architecture using documentation and deployment diagrams.
2. Define Invariants First: Write down the mathematical truths that must hold (e.g., total shares = sum of individual shares).
3. Isolate Components: Audit the vault logic separately from pricing logic, governance separately from execution.
4. Test Boundaries: Focus on interaction points between components—this is where most critical bugs hide.
5. Automate Verification: Use Foundry invariant tests to continuously verify your identified invariants.

Partner with Zealynx

FAQ: Divide and Conquer Methodology