opBNB Mainnet RPC for Wallet Builders

opBNB is an OP Stack Layer 2 on BNB Smart Chain, not "BSC with a different RPC URL." Wallet builders who reuse a BSC mainnet config, paste chain ID 56, or treat a public gateway as production traffic will ship the wrong network, the wrong explorer, or a rate-limited backplane. Before you wire MetaMask, Rabby, Phantom, Rainbow, or your own add-network flow, prove the chain ID, separate L1 from L2, and probe the URL you intend to ship.

This is not a ranking of providers. Use the opBNB Mainnet hub to compare endpoints and paid rows, then run the checks below on the URL you configure. For parent-chain operator checks, see the BSC mainnet RPC guide.

Chain ID 204 is not BSC

Mainnet chain ID is 204, hex 0xcc. Testnet is 5611. BNB Smart Chain mainnet is 56. Those three IDs are different networks. A wallet that already has BSC added still needs a separate opBNB network entry.

Official wallet fields for mainnet (from BNB Chain docs):

• Network name: opBNB Mainnet
• Chain ID: 204 (or 0xcc if the form wants hex)
• Currency symbol: BNB
• RPC URL: a JSON-RPC HTTPS endpoint you have already probed
• Block explorer: https://opbnbscan.com (BNB Chain also documents https://opbnb.bscscan.com/)

Call eth_chainId on the exact RPC URL you will ship. Expect 0xcc. A gateway that returns 0x38 (56) is BSC, not opBNB. A gateway that returns a testnet ID, times out, or answers HTML is not mainnet for that transport. Do this after any load balancer or fallback so you are not checking a different backend than production.

Native gas is still BNB with 18 decimals, same symbol as BSC. The shared ticker is a common UX trap: users think they are on BSC when the network list says "BNB." Show the network name and chain ID in the UI, not the symbol alone.

OP Stack on BSC, not Ethereum L1

opBNB uses the Optimism OP Stack (Bedrock lineage) with BNB Smart Chain as the parent chain. That matters for wallets more than the marketing line "EVM compatible":

• Deposits and withdrawals go through the opBNB bridge against BSC, not against Ethereum mainnet. Official bridge: https://opbnb-bridge.bnbchain.org.
• Finality language follows OP Stack semantics (safe / finalized and sequencer vs L1 confirmation). Do not copy BSC "wait N blocks" heuristics into an opBNB receipt poller without checking what your RPC returns for those tags.
• Contract addresses are not portable from BSC. The same dapp on BSC and opBNB uses different deployments. Hard-coding a BSC USDT or Pancake address into an opBNB wallet path is a funds bug.
• Tooling that assumes Ethereum L1 as settlement (some bridge UIs, some "L2 of ETH" presets) will mis-label the parent. Prefer presets that name BSC / BNB Chain explicitly.

Public docs list mainnet RPC examples such as https://opbnb-mainnet-rpc.bnbchain.org and https://opbnb.publicnode.com, with WebSocket support on those public surfaces. Treat published URLs as starting points. Always re-probe before baking one into a release.

Wallet-add gotchas from the /add/opbnb/* traffic

Directory traffic already hits wallet-add paths for Phantom, MetaMask, Bifrost, Rainbow, Rabby, and Talisman. The failures that show up in support and QA are usually config, not cryptography:

1. Wrong chain ID - BSC 56 or opBNB testnet 5611 pasted into a mainnet form.
2. BSC RPC on an opBNB network row - eth_chainId will not return 0xcc.
3. Explorer mismatch - pointing users at bscscan.com for L2 tx hashes.
4. Missing parent network - BNB Chain's own wallet guide still tells users to add BSC (L1) and opBNB (L2). Bridge and withdraw flows need the parent configured even when the dapp only calls L2.
5. One shared "BNB" RPC bucket in app config - separate keys for bsc and opbnb so a fallback cannot silently swap networks.

When you implement wallet_addEthereumChain / wallet_switchEthereumChain, send chainId: "0xcc", a full EIP-3085 nativeCurrency object ({ name: "BNB", symbol: "BNB", decimals: 18 }), rpcUrls pointing at your probed HTTPS endpoint, and blockExplorerUrls for opBNBScan (or the BscScan opBNB explorer if that is your product choice). Wallets that receive only symbol can reject the add request. Prefer one primary RPC in the wallet payload; put failover in your own client, not as five public URLs the wallet may pick at random.

Public vs dedicated for wallet traffic

Public endpoints are fine for:

• Local development and wallet QA
• Low-volume eth_chainId / eth_blockNumber probes
• One-off scripts and docs examples

They are a poor primary path when you:

• Run production wallet RPC for many users (balance, nonce, send, receipt polls)
• Need predictable latency and a support channel when the gateway 429s
• Depend on historical state, wide eth_getLogs, or sustained WebSocket traffic
• Cannot absorb shared-node brownouts during a mint, airdrop, or market spike

Probe the candidate URL before you call it ready:

1. eth_chainId returns 0xcc.
2. The latest block or head advances when you poll twice a few seconds apart. Do not use an unchanged account balance as proof the node is live.
3. One balance or receipt read against a known mainnet address on opBNB (not a BSC address).
4. If you need push updates, a WebSocket path that survives a disconnect (many public sockets do not).
5. Optional: compare safe / finalized block tags if your confirmation policy depends on them.

Public rows on the hub are shared and rate-limited. Use them for the probe. For production wallet traffic, compare the paid rows on the same hub for method coverage, archive or historical access if you need it, and quota. Dwellir is one of those rows: a flat response-credit model that is easier to budget when the mix of reads and writes is not stable. It is not the only option. A cheaper URL that fails the probe above is not a savings. The public vs paid guide covers when a shared endpoint stops being enough. The pricing calculator is there for the rest.

Practical split for a wallet stack

• User-facing opBNB network row - chain ID 204 / 0xcc, BNB symbol, opBNB explorer, RPC you probed today.
• Parent BSC row - chain ID 56, kept for bridge and withdraw flows, never reused as the opBNB RPC.
• Backend / indexer - dedicated or paid endpoint with explicit method and archive needs; do not share the browser wallet's public URL.
• Receipt policy - decide whether "confirmed" means latest, safe, or finalized on this OP Stack chain, and document it next to the RPC URL.

Ship the hub comparison and the probe first. Marketing copy about "cheapest L2" does not replace eth_chainId returning 0xcc.