Uniswap v4 Core

Uniswap v4 uses a singleton-style architecture where all pool state is managed within a single contract: PoolManager.sol.

Instead of interacting with individual pool contracts, integrators interact with the PoolManager using an unlock mechanism. To perform actions, an integrator must:

1. Call unlock on the PoolManager.
2. Implement the IUnlockCallback interface to receive the unlockCallback call.
3. Execute pool actions (like swap, modifyLiquidity, etc.) within that callback.

Key Constraints:

• Delta Accounting: The PoolManager tracks net balances (the delta field) during an unlock. All accumulated deltas must reach 0 by the time the unlock is released.
• Hooks: Pools can be initialized with a hook contract that executes {before,after} callbacks for lifecycle events like Initialize, AddLiquidity, RemoveLiquidity, Swap, and Donate. The set of callbacks executed for a pool is fixed after initialization.

To interact with the PoolManager, your contract must implement the IUnlockCallback interface. The workflow involves calling unlock on the PoolManager, which then triggers your contract's unlockCallback function. Inside the callback, you can perform various pool actions such as swap, modifyLiquidity, donate, take, settle, mint, or burn.

Note that you should implement security checks within unlockCallback to ensure only the PoolManager can call it.

import {IPoolManager} from 'v4-core/contracts/interfaces/IPoolManager.sol';
import {IUnlockCallback} from 'v4-core/contracts/interfaces/callback/IUnlockCallback.sol';

contract MyContract is IUnlockCallback {
    IPoolManager poolManager;

    function doSomethingWithPools() {
        // this function will call `unlockCallback` below
        poolManager.unlock(...);
    }

    function unlockCallback(bytes calldata data) external returns (bytes memory) {
        // disallow arbitrary caller
        if (msg.sender != address(poolManager)) revert Unauthorized();
        // perform pool actions
        poolManager.swap(...);
    }
}

error Unauthorized();

Echidna configuration is managed through a YAML file. This file controls the behavior of the fuzzer, including gas limits, transaction sequences, address management, and compiler arguments.

Key configuration categories include:

• Output & Reporting: Control output format (format), assertion checking (checkAsserts), and verbosity (quiet).
• Fuzzing Parameters: Define the number of test sequences (testLimit), length of sequences (seqLen), and shrinking effort (shrinkLimit).
• Gas & Economics: Set gas limits for property failures (propMaxGas), sequence termination (testMaxGas), maximum gas price (maxGasprice), and maximum value for payable functions (maxValue).
• Address & Account Management: Specify the contract address (contractAddr), the deployer (deployer), transaction senders (sender), and default balances (balanceAddr, balanceContract).
• Compiler & Tooling: Pass arguments to solc (solcArgs) or crytic (cryticArgs).

format: "text"
checkAsserts: true
coverage: false
# ... other settings

The following configuration keys are available in echidna.config.yml: