[Bug] Swaps always fail on Robinhood Chain (4663): /swap returns non-canonical hex in `value`, rejected by RPC per EIP-1474

📱 Interface Affected

• Web (app.uniswap.org)
• Wallet Extension (wallet.uniswap.org)
• Wallet Mobile App

---

🧩 App Version

• Version (if known): production web app, 2026-09-08
• Production build
• Development build

---

💻 System / Environment Info

• Browser (name + version): Chrome 152.0.0.0
• OS / Platform: Windows 11
• Device: Desktop
• Wallet used: Phantom (EVM). Not wallet-specific — see Additional Context
• Network: Robinhood Chain (chain ID 4663)

---

🔁 Steps to Reproduce

1. Go to app.uniswap.org and select Robinhood Chain (4663)
2. Set up any swap with native ETH as the input (e.g. ETH → USDG)
3. Click Review, then Swap
4. Observe: no wallet signature prompt ever appears, and the UI shows
   "Swap failed — Try adjusting slippage to a higher value."
5. Inspect the network tab: the /swap response value carries a leading zero
6. Replay eth_estimateGas against the chain RPC with that exact value, then
   again with the leading zero removed — the first errors -32602, the second succeeds

Raising slippage to any value never resolves it.

---

✅ Expected Behavior

/swap returns value as canonical hex per EIP-1474, gas estimation succeeds,
and the wallet prompts for a signature.

---

❌ Actual Behavior

POST https://entry-gateway.backend-prod.api.uniswap.org/swap returns:

{
  "swap": {
    "to": "0x8876789976dEcBfCbBbe364623C63652db8C0904",
    "value": "0x033f55c29d710000",
    "data": "0x3593564c...",
    "gasLimit": "403897"
  }
}

value is 0x033f55c29d710000 — 0.234 ETH with a leading zero.

EIP-1474 requires QUANTITY values to be
hex-encoded with no leading zeroes (except 0x0). Robinhood Chain parses value
with Go's hexutil.Big, which enforces this. Gas estimation fails, so the flow
never reaches signing and the wallet is never prompted.

Client-side the failure surfaces as:

TransactionStepFailedError
  step: { type: "SwapTransaction", txRequest: { chainId: 4663, ... } }

---

📸 Screenshots or Screen Recording

Not attached — the failure is fully characterised by the request/response and RPC
error below, and reproduces without any account-specific data.

---

🧾 Additional Context

Isolating evidence. Same transaction, same RPC
(https://rpc.mainnet.chain.robinhood.com), only the value encoding differs:

value	eth_estimateGas result
0x033f55c29d710000 (as returned by /swap)	Error -32602
0x33f55c29d710000 (canonical)	Success — 0x2c59e

Verbatim error:

-32602: invalid argument 0: json: cannot unmarshal hex number with
leading zero digits into Go struct field TransactionArgs.value
of type *hexutil.Big

Stripping the leading zero and submitting the byte-identical calldata produces
a successful on-chain swap. Route, pools, quote and slippage are all correct —
only the encoding is wrong.

Impact. Uniswap is unusable on Robinhood Chain for any user whose wallet
forwards value unmodified. Not intermittent, not user-specific. Wallets that
re-serialise transaction params before submitting may mask it. Other aggregators
on the same chain (KyberSwap, LI.FI/Jumper) are unaffected — they build their own
calldata and emit canonical hex. Most other chains' nodes are lenient parsers,
which is likely why this hasn't surfaced elsewhere.

Suggested fix. Canonicalise quantity fields before returning them from the
swap endpoint — '0x' + BigInt(value).toString(16) — for value and any other
QUANTITY field with the same serialisation path.

Secondary issue. TransactionStepFailedError on a -32602 JSON-RPC error is
not a slippage condition, and defaulting to the slippage message actively misleads
— it sends users to tune a setting that cannot possibly help. Surfacing the
underlying RPC error would have made this self-diagnosing.

---

Addresses, transaction hashes and full calldata omitted deliberately; the issue
reproduces on any account and requires none of them.

Start at the /swap request path and trace how the response value reaches the transaction request, then inspect TransactionStepFailedError handling for -32602 responses. Reproduce on Robinhood Chain with eth_estimateGas using the returned and canonical values; done means the swap response uses canonical QUANTITY encoding and the failure is no longer reported as a slippage issue.