Why Some Pons Tokenized-Stock Trades Route Through Uniswap Instead of 0x

Two ways to fill a trade, and 0x goes first

Every Pons buy or sell on Robinhood Chain tries the 0x aggregator before anything else — for both the ETH-to-token buy path and the token-to-ETH sell path. 0x typically finds the best price across multiple pools, so it's the default for a reason.

But 0x has a legal restriction that has nothing to do with liquidity: it refuses to quote tokenized equities outright. That refusal is specific — it doesn't apply to USDG, cbBTC, or ordinary ETH-paired tokens, only to the tokenized-stock category. When a quote is for AAPL, NVDA, COIN, or any other tokenized stock, 0x declines, and the code falls back to building a direct Uniswap v3 route instead.

What the fallback can miss

The direct Uniswap v3 fallback works by finding a working swap path and building the swap call by hand, rather than relying on an aggregator to search every pool for you. That's reliable for pools that sit on Uniswap's own factory, but it can miss deep liquidity sitting on Uniswap v3-fork DEXs — Ramses and Up, specifically — which run their own separate factories that the Universal Router the fallback uses can't reach.

In practice this showed up as a real issue: a USDG-paired launch briefly had no route found via the direct fallback, even though 0x itself could have priced it fine — 0x just wasn't being tried for that asset at the time. Since 0x is tried first for every quote asset except the specific tokenized-equity case it refuses, this class of gap is now mostly closed; it's the tokenized-stock leg that still depends entirely on the direct fallback finding the right pool.

Selling needs Permit2 approvals, and they're granted once

Selling a token for ETH isn't a single approval step. It requires the standard token-to-Permit2 approval, and then a separate Permit2-to-router approval, before the router can move funds on the seller's behalf.

These approvals are granted once per wallet and token, not resent on every trade — an earlier version of the code re-sent both approvals unconditionally before each sell, which wasted gas on every single trade after the first. The current flow checks whether the approvals already exist before asking for new ones.

When a token blocks the trade outright

A small number of tokenized stocks are documented by their issuer as freely transferable but, in practice, block transferFrom when it's called by certain operators. From the outside this looks identical to an ordinary 'insufficient balance or allowance' revert, which is a frustrating error to debug if you don't know which one you're looking at.

To tell the two apart, the code simulates a 1-wei transferFrom through Permit2 before attempting the real trade. If that simulation fails in a way that points to the token itself refusing the operator — rather than a balance or allowance shortfall — the trade is stopped early with a clear diagnostic message instead of surfacing a generic revert after the fact.

FAQ

• Does this affect ETH or USDG trades? No — the 0x refusal is specific to tokenized equities; ETH, USDG, and cbBTC pairs are quoted by 0x normally.
• Why did my sell need two approval transactions? Permit2-based routers require a token-to-Permit2 approval and a Permit2-to-router approval; both only need to happen once per wallet and token.
• What does 'trading unavailable due to transfer restriction' mean? It means the simulated transferFrom check detected the token itself blocking the operator, not a balance or allowance problem on your end.

Related reading