Skip to content

Fix Allowlisted Hooks link and link allowlisting criteria on the v4 hook routing page - #1160

Closed
claude[bot] wants to merge 2 commits into
mainfrom
fix/hook-routing-allowlist-link
Closed

claude[bot] wants to merge 2 commits into
mainfrom
fix/hook-routing-allowlist-link

Conversation

@claude

@claude claude Bot commented Sep 15, 2026 •

Copy link
Copy Markdown

Requested by Alex Francisci · Slack thread

Summary

Two changes to the "Hook Allowlisting" section of Hook Routing: the broken Allowlisted Hooks link is repointed, and a sentence is added telling hook builders where to find the allowlisting criteria.

Before:

  1. The "Allowlisted Hooks" link pointed at https://support.uniswap.org/hc/en-us/articles/41305283155597-Allowlisted-Hooks. That help-center article no longer exists, so a reader who clicks it never gets to see which hooks are actually allowlisted. The Zendesk Help Center API returns 404 {"error":"RecordNotFound"} for article 41305283155597, while the help-center listing API returns 200 — the article id is orphaned, not gated behind a login.
  2. The section told builders to fill out the allowlisting form and where to see the current allowlist, but nothing told them what a hook actually has to look like to be allowlisted. A builder had to submit the form to find out that, for example, hooks using beforeSwapReturnsDelta need manual review at all.

After:

  1. The "Allowlisted Hooks" link points at the allowlist source of truth in code — https://github.com/Uniswap/uniroute-public/blob/main/src/lib/poolCaching/util/hooksAddressesAllowlist.ts. Uniswap/uniroute-public is a public repository, and an unauthenticated fetch of that same path through raw.githubusercontent.com on main returns 200 (79,154 bytes), so the new target is reachable without a GitHub login.
  2. A new sentence sits between the form sentence and the allowlist sentence: "You can look up the current allowlisting criteria in Routing for hooked pools." That article documents both the two conditions that make a hook need manual allowlisting and the explicit criteria that improve its chances, so the word "criteria" matches what the page actually says.

How: Both edits are in content/protocols/v4/concepts/hook-routing.mdx — a one-line change to the markdown link target, plus one added paragraph. The link fix leaves the link text ("Allowlisted Hooks") and its surrounding sentence unchanged; the added sentence leaves both existing sentences byte-for-byte unchanged (the diff is purely additive: 2 insertions(+) in the second commit). Both links use the page's existing external-absolute-URL style and its second-person voice.

A repo-wide search found the bad URL exactly once, and zero prior occurrences of uniroute anywhere in the repo, so there are no sibling instances to fix. The other allowlist hits — content/ecosystem/builder-support/get-reach.mdx and one line in archive/ — are different links about a related topic and were deliberately left alone.

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?

  • Old target is a dead article id, not a permissions gate: GET https://support.uniswap.org/api/v2/help_center/en-us/articles/41305283155597.json → 404 {"error":"RecordNotFound"}, while the help-center listing API returns 200. Login state is therefore irrelevant — the article id is orphaned.
  • New target of the fixed link is publicly reachable: Uniswap/uniroute-public is a public repository, and an unauthenticated GET https://raw.githubusercontent.com/Uniswap/uniroute-public/main/src/lib/poolCaching/util/hooksAddressesAllowlist.ts → 200 (79,154 bytes). The default branch is main and the path exists on it, so the /blob/main/ path in the new URL is correct.
  • The newly linked article says what the new sentence claims it says: GET https://support.uniswap.org/api/v2/help_center/en-us/articles/48291859140621.json → 200, title Routing for hooked pools, html_url matching the URL used in the docs. Its body states that the routing algorithm picks up most hooks automatically unless the hook is deployed to an address starting 0x91… or uses beforeSwapReturnsDelta, afterSwapReturnsDelta or dynamicFees, and then lists the criteria that "will increase the likelihood of your hook being allowlisted" (deployed on a supported L1/L2 mainnet, code verified in a block explorer, does not modify or bypass the AMM protocol fee, not behind an upgradeable proxy, not malicious or extractive, no custom calldata the Uniswap Labs router could not produce). The word "criteria" in the new sentence is the article's own word, not an inference.
  • Measurement limits: neither github.com's HTML blob page nor the support.uniswap.org HTML article page can be loaded from this environment — support.uniswap.org returns a 403 Cloudflare bot challenge on HTML requests, and GitHub blob pages are blocked by egress policy before the request reaches GitHub. Both targets were therefore verified through their APIs (Zendesk JSON and raw.githubusercontent.com) rather than by rendering the pages a reader would see. The Zendesk API confirms article 48291859140621 exists and is published; it does not prove the public HTML page renders for an anonymous reader, and a reviewer on an unblocked network should click both links once.
  • Scope: repo-wide grep found the bad URL exactly once and zero prior occurrences of uniroute; every other allowlist hit was classified (see Summary). The second sentence of the section was left untouched by explicit request and git diff confirms it.
  • No content build or link-check was run: content/ has no build tooling in this repo (the only package.json lives under archive/, which is reference-only), and the configured workflows are claude-code-review, notify-slack and pr-welcome — none is a link checker. The diff is one URL substitution and one added markdown paragraph.

Applicable screenshots

None — both changes are text in one markdown file: one link target (rendered link text identical) and one added sentence, quoted in full above. The HTTP statuses above are the equivalent proof.

Anything else reviewers should know?

The help-center article is now linked rather than offered as an alternative. The old, dead article's content was republished as Routing for hooked pools (https://support.uniswap.org/hc/en-us/articles/48291859140621-Routing-for-hooked-pools, updated 2026-09-03, confirmed via the Zendesk API). The section now points at both: the uniroute-public source file remains the authoritative list of allowlisted hook addresses, and the help-center article is the place a builder reads the criteria. If the docs team would rather have only one of the two, say which and I'll drop the other.

Wording choice: the new sentence says "the current allowlisting criteria" rather than naming specific requirements, so the docs page does not have to be re-edited when Uniswap Labs changes the list — the article states that allowlisting decisions are at Labs' sole discretion and may change at any time.

🤖 Generated with Claude Code

https://claude.ai/code/session_016NBfmXuBzyQ5arpLrLpJ3g


Generated by Claude Code

The "Allowlisted Hooks" link on
content/protocols/v4/concepts/hook-routing.mdx pointed at
support.uniswap.org/hc/en-us/articles/41305283155597-Allowlisted-Hooks,
which returns HTTP 404 for a logged-out reader (the Zendesk article id no
longer exists: the help-center API answers RecordNotFound for 41305283155597).

Point it at the allowlist source of truth instead:
https://github.com/Uniswap/uniroute-public/blob/main/src/lib/poolCaching/util/hooksAddressesAllowlist.ts
Uniswap/uniroute-public is a public repository and the file resolves with
HTTP 200 unauthenticated on the default branch.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016NBfmXuBzyQ5arpLrLpJ3g
@github-actions

Copy link
Copy Markdown

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.

@claude
claude Bot marked this pull request as ready for review September 15, 2026 17:51
The Hook Allowlisting section linked the submission form and the current
allowlist, but nothing told builders what a hook has to look like to be
allowlisted. Add a sentence linking the "Routing for hooked pools" support
article, which documents both when a hook needs manual allowlisting and the
criteria that improve its chances.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016NBfmXuBzyQ5arpLrLpJ3g
@claude claude Bot changed the title Fix broken Allowlisted Hooks link on the v4 hook routing page Fix Allowlisted Hooks link and link allowlisting criteria on the v4 hook routing page Sep 15, 2026
@claude

claude Bot commented Sep 15, 2026

Copy link
Copy Markdown
Author

Closing this in favour of https://github.com/Uniswap/universe/pull/42188, which makes the same change in the actual publishing source: apps/dev-portal/content/docs/protocols/v4/concepts/hook-routing.mdx.

For anyone who finds this later: the old link target, Zendesk article 41305283155597, is an orphaned ID — the Zendesk API returns RecordNotFound for it while the help-center listing responds normally, so it 404s for everyone regardless of login state. The content was republished as Routing for hooked pools (48291859140621).

One observation for the docs team, not a request: this repo's copy of the page still points the allowlisting form at an internal notion.so/uniswaplabs/... URL, while the universe copy already uses the /hook-allowlist dev-portal route — so this copy looks behind on that line too.


Generated by Claude Code

@claude claude Bot closed this Sep 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant