出典確認済みリサーチ: Uniswap V4 VS Pancakeswap

Decision Matrix

Source Map

• Uniswap Developers: Uniswap v4 Hooks (uniswap-v4-hooks)
• Uniswap Developers: Building Your First Hook (uniswap-build-first-hook)
• PancakeSwap Documentation: Hooks (pancakeswap-infinity-hooks)
• PancakeSwap Developer: Custom Layer Hook (pancakeswap-custom-layer-hook)

Control Notes

1. Hook address

Hook address is the point where public documentation must become an operating rule. In this package, it means the executable hook contract is the first object to identify before interpreting pool behavior. The practical action is to record the hook address, chain, source reference and explorer verification status. The unresolved edge is unverified bytecode, proxy assumptions, upgrade paths and frontend label drift, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

2. Callback lifecycle

Callback lifecycle is the point where public documentation must become an operating rule. In this package, it means hook logic can attach to different pool lifecycle points rather than one generic swap event. The practical action is to map which callback or pool event the hook can affect before supplying liquidity. The unresolved edge is callback ordering, integration bugs and undocumented edge behavior, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

3. Pool type

Pool type is the point where public documentation must become an operating rule. In this package, it means pool architecture and accounting model shape how a hook changes execution risk. The practical action is to identify whether the pool is a plain pool, hook-enabled route or custom layer before signing. The unresolved edge is future routing changes, UI abstraction and cross-version pool assumptions, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

4. Permission surface

Permission surface is the point where public documentation must become an operating rule. In this package, it means hook review is different from token approval review, but both can affect user exposure. The practical action is to separate wallet approvals, hook permissions, router path and recipient address in the checklist. The unresolved edge is wallet-specific prompts, allowance reuse and hidden route composition, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

5. Stop condition

Stop condition is the point where public documentation must become an operating rule. In this package, it means a hook-enabled pool should pause the user when the contract or route cannot be independently verified. The practical action is to stop before signing if hook address, source, pool identity, allowance or route differs from the record. The unresolved edge is future protocol changes, chain-specific deployments and third-party hook maintenance, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.

The operating test is narrow.

Known Unknowns

• unverified bytecode, proxy assumptions, upgrade paths and frontend label drift
• callback ordering, integration bugs and undocumented edge behavior
• future routing changes, UI abstraction and cross-version pool assumptions
• wallet-specific prompts, allowance reuse and hidden route composition
• future protocol changes, chain-specific deployments and third-party hook maintenance

Practical Takeaway

Uniswap v4 and PancakeSwap Infinity should be compared as programmable pool-control systems, not as generic DEX labels. Uniswap documentation describes hooks as contracts attached to v4 pools, while PancakeSwap documents Infinity hooks and a developer custom-layer hook surface. The decision outcome is to verify hook address, lifecycle callback, pool type, permission surface, source code, frontend route and stop condition before treating a hook-enabled pool as ordinary liquidity. The article stops at the evidence boundary. It helps the reader decide what to inspect next without converting public documentation into a promise that a private account, wallet, API key, pool route, stablecoin balance, tokenized asset or policy framework will work under every future condition.