docs: document trade-type constraints for hooked pools

[wangluolingxing]

Summary

This PR documents a routing constraint for non-vanilla v4 hooks: allowlisting makes a hooked pool eligible for routing, but it does not change the hook's swap validation or make the pool compatible with every direction and trade type.

The update:

• adds a four-quadrant compatibility checklist for both directions and EXACT_INPUT/EXACT_OUTPUT;
• tells hook builders to test and document direction-, state-, and trade-type-specific constraints;
• scopes BEST_PRICE to the submitted trade type for Uniswap Protocol AMM routing; and
• explains that an input-budget experience for an exact-output-only direction needs hook-specific intent translation or an explicitly requested output amount.

This is a generic documentation change. It does not add Morphogen-specific content to the published docs and does not change routing behavior.

Why this is needed

The current hook-routing page explains allowlisting, but not that an allowlisted hook can still reject a quote because of its direction, trade type, or current state. The Swap Routing page explains protocols and routingPreference, but does not currently explain how type constrains Uniswap Protocol AMM routing.

A verified production case makes the missing guidance concrete:

User formulation	Interface trade type	Canonical Morphogen buy behavior
Enter ETH on the pay side	EXACT_INPUT	Rejected by the hook with BuyRequiresExactOutput
Enter the desired MGEN output	EXACT_OUTPUT	Accepted by the canonical hook

The Morphogen hook is source-verified, marked vanillaSwap: false, and publicly allowlisted on Robinhood Chain. Its verified source requires MGEN buys to use exact output and MGEN sells to use exact input in both formation and permanent phases. EXACT_OUTPUT is a first-class v4 quote and execution mode, but it is a separate request type. The canonical quoter and router expose the corresponding exact-output purchase path, and a successful production transaction exercises that path with a declared maximum input and a nonzero refund.

Uniswap's public Interface derives tradeType from the edited field and preserves it in the quote request. In the public UniRoute request-to-execution path reviewed for this change, tradeType is likewise preserved through quote processing, route selection, and trade construction.

The hook registry can identify Morphogen as non-vanilla, but its current schema has no direction-specific EXACT_INPUT/EXACT_OUTPUT capability fields. Allowlisting therefore makes the pool eligible for routing without expressing this constraint in a standard machine-readable form.

This PR does not claim that the public UniRoute repository is byte-for-byte identical to every production service. It documents the integration constraint demonstrated by Uniswap's public API definitions, interface source, routing source, hook registry, and the verified deployed hook.

Canonical production identifiers

• Chain: Robinhood Chain (4663)
• MGEN: 0x822850e3d25A19258eE160F8Bb33FB1345B70372
• Hook: 0xD27596adD474e5f645Cc1D2141e8Ff2A3FD33AEC
• Pool ID: 0xae0acc3836678141dc58ac679d2ab66619afedf32095fde8f773aead524847ca
• Reference router: 0xFCB9b9dC8DDCaA1a71869Bf0003d6da493C8BABb
• Reference quoter: 0x5f586aBcED4982a88426034CD1c0Fa72F59b5756
• Canonical market: Dexscreener

The linked production transaction requested 110,651.713076158913831201 MGEN, declared a maximum input of 1.009999999964863360 ETH, spent 0.999999999965211247 ETH, refunded 0.009999999999652113 ETH, and succeeded onchain.

Documentation changes

Hook routing

• Clarifies that allowlisting does not change hook validation or guarantee quote compatibility.
• Adds a direction and trade-type test matrix for every relevant hook state.
• Adds multi-hop testing guidance where applicable.
• Documents safe integration options for an exact-output-only direction.
• Limits bounded inverse-search guidance to hooks that guarantee monotonic required-input quotes over a known range for a fixed state, with revalidation before execution.

Swap routing

• Documents the type field alongside protocols and routingPreference.
• Clarifies exact-input and exact-output semantics for Uniswap Protocol AMM routing.
• Clarifies that BEST_PRICE optimizes routes for the submitted type and does not reinterpret EXACT_INPUT as EXACT_OUTPUT.
• Cross-links the hook compatibility and Chained Actions guidance.

Type of change

• Fix (typo, broken link, incorrect or outdated content)
• New content (guide, page, code example)
• Update to existing content
• Other

How has this been verified?

Integration and registry evidence

• Morphogen hooklist submission and approval
• Pinned Morphogen hook registry entry
• Current UniRoute hook definition and Robinhood allowlist inclusion
• Hooklist schema, which records vanillaSwap but has no direction or trade-type capability fields
• Official hook allowlisting guidance

Morphogen contract and production evidence

• Formation-phase trade-type validation
• Permanent-phase trade-type validation
• Pinned production deployment manifest
• Canonical exact-output quoter
• Maximum-input and refund implementation
• Successful exact-output production transaction
• Verified deployed hook

Uniswap request and routing evidence

• Official Quote API exact-input/exact-output definitions
• Interface trade-type derivation
• Interface quote-request construction
• UniRoute public-repository scope
• Public UniRoute request parsing
• Public UniRoute quote processing
• Public UniRoute route selection
• Public UniRoute exact-mode ranking
• Public UniRoute trade construction
• v4 router exact-input and exact-output interfaces
• v4 quoter exact-input and exact-output methods

Additional corroborating public routing sources

• Unified Routing API request parsing
• Unified Routing API quoter dispatch
• Routing API exact-in/exact-out dispatch
• Smart Order Router v4 exact-in/exact-out quoter dispatch

Repository checks

• Ran git diff --check.
• Verified the edited MDX frontmatter, tables, and <Callout> structure.
• Verified every internal documentation target exists.
• Checked the pinned GitHub, Blockscout, API, and supplementary links.

The current public docs repository contains documentation content but no runnable current-site package, so validation covers the MDX structure and links rather than claiming a local full-site build.

Scope and non-claims

• This PR does not change routing or interface behavior.
• It does not claim a Uniswap v4 core-contract failure.
• It does not claim that allowlisting guarantees route selection.
• It does not claim that every aggregator uses Uniswap's API.
• It does not prescribe inverse search for arbitrary hooks. The published guidance requires a monotonicity guarantee over a known range or hook-specific integration logic.
• It does not claim that the public UniRoute snapshot is byte-for-byte identical to every production service.

Documentation alone does not resolve the observed routing behavior. This PR intentionally limits itself to making the constraint clear for hook builders and API integrators while capability metadata or intent-translation changes are evaluated separately.

Applicable screenshots

Not applicable to the rendered documentation change. The supplementary reports below contain the reproduced interface comparison.

Supplementary reproduction and analysis

These reports contain the observed UI reproduction, screenshots, source trace, limitations, and longer-form analysis. The documentation change relies on the pinned primary sources above rather than these reports.

• Part 1: When "best route" depends on how you ask
• Part 2: What Uniswap's open-source router confirms after allowlisting

Anything else reviewers should know?

The docs diff intentionally stays focused and cross-links existing pages. A routing or interface implementation change would require a separate issue or RFC with raw quote payloads and implementation-specific tests.

Implementation follow-up: Uniswap/interface#8057

[github-actions]

Thanks for contributing to Uniswap Docs! 🦄

Quick heads up on how this repo works: the docs you see on developers.uniswap.org are built from a separate source repo. When we accept a change here, we port it over there, so your fix might show up on the live site before it lands in this repo.

Updates to this repo come in batches on a regular cadence. When yours is included, you'll be credited as a co-author on the commit, so the contribution counts on your GitHub profile and in Uniswap/docs.

We review every PR but can't merge everything. Either way, someone from the docs team will follow up here once we've taken a look.

One legal bit: by submitting a PR you agree your contribution is licensed under the repo's MIT license.