A New Uniswap Proposal Would Let Tokens Tell Routers Exactly Where They Should Trade

MakeCryippreferred on

• A new Uniswap Request for Comment, URC-5, posted to the governance forum on October 21, 2026, proposes letting tokens declare canonical, preferred or enforced liquidity pools
• The proposal cites tokens like INDEX, STANDARD and FWA, which depend on Uniswap v4 hooks and have reportedly lost trading volume when routers sent trades to unsupported venues
• A same-day response from a routing-focused community member pushed back, arguing enforcement should stay fully on-chain rather than relying on router-level rules

A Uniswap community member posting under the name 0xBeans submitted a new Uniswap Request for Comment, designated URC-5 and titled “Token Venue Policy,” to the Uniswap governance forum on October 21, 2026. The proposal would introduce a token-level interface, called IVenuePolicy, that lets a token’s own smart contract declare which Uniswap v4 liquidity pools should be treated as its canonical, or official, trading venues, with two possible designations: “Preferred” or “Enforced.”

The motivation behind the proposal centers on a real problem some token projects have reportedly encountered: tokens such as INDEX, STANDARD, and FWA depend heavily on specific Uniswap v4 hooks, custom logic attached to a liquidity pool that can restrict or modify how trading works for that token, and these projects have intentionally restricted their trading to particular pools that support those hooks correctly. According to the proposal, STANDARD and FWA in particular lost significant trading volume because routing services and aggregators, the tools that find the best price across multiple available pools, were not aware of these restrictions and routed trades to pools that did not properly support the tokens’ intended hook logic.

By letting a token itself declare its preferred or enforced venues on-chain, URC-5 aims to give routers and aggregators a standardized, machine-readable way to respect those restrictions automatically, rather than relying on each individual routing service to separately learn about and manually account for every token’s specific quirks and hook dependencies.

The proposal drew a same-day response from a community member going by Gretzke, who is described as a routing-focused contributor connected to Uniswap Labs’ own routing work. Gretzke argued that enforcement of any venue policy should remain fully on-chain rather than depending on voluntary compliance at the router level, suggested that any consumer-facing rules should function only as non-binding guidance rather than hard enforcement, and proposed that a separate exit-fee mechanism referenced in the original proposal belongs in its own distinct URC rather than being bundled into this one. Gretzke also suggested specific technical changes, including replacing the proposal’s canonicalPools array and ordering system with a mapping structure, and adding an explicit “off” state that would let a token formally end its venue policy if it chose to.

The back-and-forth illustrates how Uniswap’s governance process often works in practice, with an initial proposal sparking detailed technical pushback from contributors close to the protocol’s existing infrastructure before any consensus forms around a final design. The proposal, posted on Uniswap’s governance forum, remained open for further community discussion with no vote yet scheduled.