# Handoff: RN Multichain Proxy Probe — 2026-05-28

## Probe execution

Script: `backend/scripts/probe-rn-chains.ts` (commit `01b9ea0`, backend 2.6.46)
Executed: 2026-05-28T15:48:48Z

## Results summary

| Chain | Chain ID | Proxy Address | RPC | Reachable | Has Code | Call Valid | Status |
|-------|----------|---------------|-----|-----------|----------|------------|--------|
| BNB Smart Chain | 56 | `0x0DfbEe143b42B41eFC5A6F87bFD1fFC78c2f0aC9` | publicnode | ✅ | ✅ | ✅ | **Verified** |
| Arbitrum One | 42161 | `0x0DfbEe143b42B41eFC5A6F87bFD1fFC78c2f0aC9` | publicnode | ✅ | ✅ | ✅ | **Verified** |
| Ethereum Mainnet | 1 | `0x0DfbEe143b42B41eFC5A6F87bFD1fFC78c2f0aC9` | publicnode | ✅ | ✅ | ✅ | **Verified** |
| Polygon | 137 | `0x0DfbEe143b42B41eFC5A6F87bFD1fFC78c2f0aC9` | publicnode | ✅ | ✅ | ✅ | **Verified** |
| Base | 8453 | `0x0DfbEe143b42B41eFC5A6F87bFD1fFC78c2f0aC9` | publicnode | ✅ | ❌ | ❌ | **NOT DEPLOYED** |

## Methodology

1. **Reachability**: `eth_blockNumber` against each chain's public RPC endpoint.
2. **Code presence**: `eth_getCode` at the canonical CREATE2 address.
3. **Function validity**: `eth_call` with a dummy `transferFromWithReferenceAndFee` payload. A valid proxy reverts with an ERC-20/execution error (proving the selector is recognized). An invalid address would revert with "unknown function selector" or return empty.

## Key findings

- **BSC / Arbitrum / Ethereum / Polygon**: Canonical proxy `0x0DfbEe143b42B41eFC5A6F87bFD1fFC78c2f0aC9` is deployed and responds to the RN fee-proxy function selector on all four chains. ✅
- **Base**: The canonical CREATE2 address has **no code** on Base as of block `0x2c7037e`. RN has either not deployed the ERC20FeeProxy on Base yet, or deployed it at a different address. ⚠️

## Action taken

- Removed Base (8453) from the active `supportedChains.json` registry.
- Moved Base to `_unverified` section with a verification note.
- Removed Base USDC/USDT entries from `tokens.json`.
- Frontend wagmi config retains `base` chain support for future use, but the backend will return `unsupported_chain:8453` for any RN payment configured to Base until the correct proxy address is found and verified.

## Remaining work

- [ ] Find the actual RN ERC20FeeProxy address on Base (if deployed) from RN official docs / subgraph / Discord.
- [ ] Re-verify Base once the correct address is known.
- [ ] BSC USDT paid end-to-end probe (PRD §2 AC #3).
- [ ] Mainnet USDT `approve(0)` reset verification (PRD §2 AC #4) — see note below.

## Mainnet USDT approve(0) reset — implementation note

The frontend approve flow in `rn-in-house-checkout-view.tsx` now detects the USDT-mainnet quirk:

```ts
const needsUsdtReset =
  block.chainId === 1 &&
  block.tokenSymbol.toUpperCase() === 'USDT' &&
  allowance > BigInt(0) &&
  allowance < amountWei;
```

When `needsUsdtReset` is true, the UI first sends `approve(spender, 0)`, waits for confirmation, then sends `approve(spender, amountWei)`. The button label changes to "بازنشانی USDT" during the reset phase.

**Status: implemented but NOT verified.** Mainnet USDT testing costs real ETH gas. Options:
1. **Tenderly fork test** — fork Ethereum mainnet, simulate a buyer with existing USDT allowance > 0, verify the two-step approve flow executes correctly.
2. **Wait for first real mainnet usage** — the code path is well-contained; if a real buyer hits this case, the UI will guide them through the reset.

Do NOT claim PRD §2 AC #4 green until one of the above verifies the flow.