How UniGuard works

UniGuard is a single Uniswap v4 hook contract (PinkShieldHook.sol) that a project creator configures and attaches to a new pool. Uniswap v4 allows exactly one hook per pool, so UniGuard composes three independent protection modules into that one slot: Launch Guard, Adaptive MEV Defense, and Dynamic Anti-Dump. Each is independently configurable, and each can be disabled entirely if a creator doesn't want it.

Every numeric parameter — every cap, every fee, every duration, every threshold — is set once, before deployment, validated on-chain by ConfigurationValidation.sol, and becomes permanently immutable the moment the pool initializes. There is no admin function anywhere in the deployed contracts that can change a locked parameter afterward. The pool itself is a real Uniswap v4 pool — standard liquidity, standard settlement, fully compatible with any v4 router once the Launch Guard window ends.

UniGuard protects a token's market — the pool it trades in — not the token contract itself. If you already have a token, you use its address directly. If you don't, PinkShieldTokenFactory.sol can create one for you as the first step of the same launch flow, so the whole thing happens in one place without needing a separate token deployer.

The token this creates is deliberately minimal: a standard, OpenZeppelin-based ERC20 with a fixed supply, minted once, in full, to the address you specify (typically your own wallet) — and almost nothing else. No owner, no mint function, no pause, no blacklist. Once deployed, there is no function anywhere that can change its supply or restrict who can hold or transfer it. This is intentional: a token with a hidden mint or pause function would undermine every guarantee the pool-level protection makes, no matter how well the hook itself is built.

The one exception: an optional description and image URI, written once into the token's own storage in the same deployment transaction. Same rule as everything else here — no setter, permanent the instant the token deploys. image is a link (an https:// or ipfs:// URI), not raw image bytes — storing an actual picture on-chain would cost gas proportional to its file size.

What this does not do is seed liquidity or handle tokenomics beyond the fixed mint — you decide how much of your own supply to add as pool liquidity (via Uniswap's own position manager, after your pool initializes) versus keep. UniGuard does not take a cut of the token supply, hold any of it in escrow, or have any privileged claim on it after deployment.

Every fee value uses Uniswap v4's own LP-fee unit — hundredths of a basis point, denominator 1,000,000. For a given swap, four components are summed, then clamped to the lesser of the pool's own configured maximum and the protocol-wide hard cap of 5.00%:

effectiveFee = min(baseFee + launchComponent + impactComponent + sellPressureComponent,
                    min(poolMaxFee, HARD_MAX_FEE_BPS))

This is FeeMath.composeAndCap — the single choke point every effective fee passes through. No configuration and no code path can produce a fee above the hard cap, regardless of how the four components are configured (proven for arbitrary inputs by the contracts' own property-based fuzz tests).

Both rolling accumulators (Adaptive MEV Defense's velocity window and Dynamic Anti-Dump's sell-pressure window) use the same primitive — RollingFlowState.sol — rather than an explicit sliding-window buffer, which would need unbounded storage or an unbounded loop to prune. Decay is instead applied lazily, in O(1), the next time the accumulator is touched:

halvings   = floor(secondsElapsed / halfLifeSeconds)
value(t)   = value₀ >> halvings          (a right bit-shift — an exact halving each step)

This is a piecewise approximation of continuous exponential decay — precise to within one half-life, not a smooth curve — which is why the chart below steps rather than curves. Plotted for this policy's actual configured half-life of 5 minutes:

Uniswap v4's flash-accounting design means the hook only ever sees sender = the router contract that called PoolManager.swap() — never a raw wallet address (a wallet has no code to run PoolManager's required unlock callback). If per-wallet caps relied on sender directly, every trader sharing a router like Universal Router would collapse into a single identity.

PinkShieldRouter is the one contract the hook trusts to honestly report the true trader: it sets hookData to the trader's own address as seen by the router's own code, and the hook only accepts that claim when the immediate caller is exactly this router. Any other router is rejected — but only on the buy side, and only during the Launch Guard's active window. Sells are never blocked by this check, at any time, by design — this constraint can never trap a holder's exit liquidity. Outside the guard window, per-wallet identity isn't needed at all (Adaptive MEV Defense and Dynamic Anti-Dump both operate on pool-wide rolling aggregates), so any router works normally for both buys and sells once the guard window ends.

This authenticates which address initiated a swap — not that the address is controlled by a distinct human. See Known limitations below for what this does and doesn't protect against.

• Sells: always work through any router, at any time. No identity check ever applies to a sell.
• Buys outside the Launch Guard window: work through any router normally — per-wallet caps are not enforced once the guard window has elapsed.
• Buys during the Launch Guard window: must route through PinkShieldRouter to be attributed to the trader's real address (and therefore subject to, and benefit from, per-wallet caps rather than a shared router identity). A buy through any other router during this window reverts with UnverifiedRouter unless the address is on the pool's allowlist.
• The pool itself is a completely standard Uniswap v4 pool — its address, pool key, and dynamic-fee flag are all readable the normal way. Nothing about UniGuard requires a proprietary front end to trade against a protected pool outside the guard window.

/pools and every pool dashboard on this site read on-chain state directly: readContract calls for current configuration and live fee quotes, and getLogs scans (chunked, with an explicit cap) for HookDeployed and ProtectedSwap event history. There is no backend database and no separate indexing service for this MVP — that's a deliberate scoping decision for a launch with a modest number of pools and no deep historical-analytics requirement yet, not an oversight. Where a scan hits its range cap, the affected page says so explicitly rather than silently presenting a partial result as complete.

A dedicated indexer is a natural next step once pool count and history depth justify it — the event schema in IPinkShieldHook.sol was written with that in mind.