Fix Allowlisted Hooks link and link allowlisting criteria on the v4 hook routing page - #1160
claude[bot] wants to merge 2 commits into
Conversation
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
|
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. |
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
|
Closing this in favour of https://github.com/Uniswap/universe/pull/42188, which makes the same change in the actual publishing source: For anyone who finds this later: the old link target, Zendesk article One observation for the docs team, not a request: this repo's copy of the page still points the allowlisting form at an internal Generated by Claude Code |
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:
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 article41305283155597, while the help-center listing API returns 200 — the article id is orphaned, not gated behind a login.beforeSwapReturnsDeltaneed manual review at all.After:
https://github.com/Uniswap/uniroute-public/blob/main/src/lib/poolCaching/util/hooksAddressesAllowlist.ts.Uniswap/uniroute-publicis a public repository, and an unauthenticated fetch of that same path throughraw.githubusercontent.comonmainreturns 200 (79,154 bytes), so the new target is reachable without a GitHub login.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
unirouteanywhere in the repo, so there are no sibling instances to fix. The otherallowlisthits —content/ecosystem/builder-support/get-reach.mdxand one line inarchive/— are different links about a related topic and were deliberately left alone.Type of change
How has this been verified?
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.Uniswap/uniroute-publicis a public repository, and an unauthenticatedGET https://raw.githubusercontent.com/Uniswap/uniroute-public/main/src/lib/poolCaching/util/hooksAddressesAllowlist.ts→ 200 (79,154 bytes). The default branch ismainand the path exists on it, so the/blob/main/path in the new URL is correct.GET https://support.uniswap.org/api/v2/help_center/en-us/articles/48291859140621.json→ 200, titleRouting for hooked pools,html_urlmatching 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 starting0x91…or usesbeforeSwapReturnsDelta,afterSwapReturnsDeltaordynamicFees, 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.github.com's HTML blob page nor thesupport.uniswap.orgHTML article page can be loaded from this environment —support.uniswap.orgreturns 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 andraw.githubusercontent.com) rather than by rendering the pages a reader would see. The Zendesk API confirms article48291859140621exists 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.uniroute; every otherallowlisthit was classified (see Summary). The second sentence of the section was left untouched by explicit request andgit diffconfirms it.content/has no build tooling in this repo (the onlypackage.jsonlives underarchive/, which is reference-only), and the configured workflows areclaude-code-review,notify-slackandpr-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: theuniroute-publicsource 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