Files
nick-doc/08 - Operations/Handoff - RN Multichain Probe - 2026-05-28.md
Siavash Sameni 85cb439ce2 docs: Task #8 probe results + handoff + PRD AC updates
- Add Handoff - RN Multichain Probe - 2026-05-28.md
- Update Handoff - Request Network In-House Checkout with Task #8 status
- Update Activity Log with backend@ae17b18, frontend@0ebb2f1
- Update PRD §2 acceptance criteria for Task #8
- Update Payment API.md with /api/admin/rn/networks endpoints
2026-05-28 19:53:06 +04:00

3.5 KiB

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:

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.