Uniswap v4 and JUSTYPE
Understand the canonical Classic V1 stack and the explicit boundary around programmable execution.
Documentation index
LAUNCHER→UERC20 + INSTANT
LAUNCH STRATEGY
The executable rule subset, hook callbacks, storage, custody, upgrades, settlement routing, audits, and addresses are not defined or deployed.
Classic V1 is one canonical transaction
JUSTYPE uses the official Liquidity Launcher SDK to predict a UERC20 address and build one atomic LiquidityLauncher multicall. It creates the fixed-supply token, distributes the full supply to the selected InstantLaunchStrategy, initializes the v4 pool, and mints the launch liquidity position. The production launch flag remains disabled until separate activation.
For the current Robinhood deployment, supply is fixed at 1,000,000,000 tokens with 18 decimals, the pair is native ETH, the pool is hookless, and the static LP fee is 0.25%. The Review screen resolves the current launcher, strategy, fee split, and position recipient from the pinned official SDK.
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 programmable 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 is simple: a future compiler/adapter could map a validated JUSTYPE configuration into specifically designed v4 hook behavior. Classic V1 does not do so.