Uniswap v4 and JUSTYPE
Learn the verified v4 concepts and the explicit boundary around JUSTYPE's planned integration.
Documentation index
POOLMANAGER→FINAL DELTAS
SETTLE
Contract design, custody, upgrade model, supported subset, and addresses remain unspecified.
PoolManager is the singleton core
Uniswap v4 keeps pool state and core logic in one PoolManager contract rather than deploying one core contract per pool. Pool creation supplies currencies, fee configuration, tick spacing, and an optional hook address. Swaps are generally initiated through a router that interacts with PoolManager.
A pool may attach one optional hook
A hook is an external smart contract attached when a pool is initialized. Each pool can have one hook, while one hook contract can serve many pools. The hook cannot simply be added to an existing pool later because it is part of the pool key.
beforeSwap and afterSwap are real callbacks
When enabled by the hook’s address permissions, beforeSwap runs before the core swap and afterSwap runs after it. The official interface defines their arguments and return values. Other callback families cover initialization, adding/removing liquidity, and donation.
Custom accounting can modify deltas
v4 tracks net credits and debts as deltas during an unlocked operation and requires them to settle before completion. Permissioned hooks can return deltas to implement custom accounting, including hook fees. That is powerful and security-sensitive.
Hook fees are distinct from dynamic LP fees. Dynamic LP fees accrue to liquidity providers and are configured as a pool capability; JUSTYPE must not describe a routed token behavior fee as if it were automatically the same mechanism.
Official custom accounting guide ↗ · Official dynamic fees documentation ↗
What a future JUSTYPE model still has to define
A production design would need to define the executable rule subset, configuration ownership, mutability, hook permissions, custody and routing, settlement, failure behavior, oracle dependencies, access-control data, deployment provenance, upgrade policy, indexing, and audits. None of those details should be inferred from the frontend rule types.
The safe architectural statement today is simple: a future compiler/adapter could map a validated JUSTYPE configuration into specifically designed v4 hook behavior. It has not done so yet.