# Chain 138 RPC – Verification & Final Confirmation

**Last Updated:** 2026-01-31  
**Document Version:** 1.0  
**Status:** Active Documentation

---

**Status**: Authoritative validation complete  
**Date**: 2026-01-29  
**Purpose**: Lock in end-to-end RPC path correctness and document LAN vs WAN behavior.

---

## RPC path validation (proven)

Full stack has been proven correct:

**Client → NPMplus → Besu (VMID 2201)**

| Layer | Status |
|-------|--------|
| **DNS** | `rpc-http-pub.d-bis.org`, `rpc.defi-oracle.io`, etc. → **76.53.10.36** |
| **TLS/SNI** | Cert CN matches hostname; valid Let's Encrypt; TLS 1.3 |
| **Proxy** | NPMplus (192.168.11.167:443) routes by Host header correctly |
| **Upstream** | Besu RPC (192.168.11.221:8545 / :8546) reachable |
| **RPC response** | `eth_chainId` → **0x8a** |
| **Chain ID** | **0x8a = 138** (Defi Oracle Meta Mainnet) |

Validation command (bypasses public IP; connects directly to NPMplus on LAN):

```bash
curl -vk --resolve rpc-http-pub.d-bis.org:443:192.168.11.167 \
  https://rpc-http-pub.d-bis.org \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
# Expected: {"jsonrpc":"2.0","id":1,"result":"0x8a"}
```

**Conclusion**: No firewall, proxy, or TLS issues inside the stack. System is working as designed.

---

## Why it can “hang” from inside the LAN (expected)

From a host **on the same LAN** as 192.168.11.x, calling the **public** hostnames (resolving to 76.53.10.36) may hang or time out because of:

- **NAT reflection / hairpin**: traffic goes LAN → WAN IP (76.53.10.36) → router → back into LAN. UniFi can support this but it is topology- and firewall-rule dependent and can be inconsistent with HTTPS/HTTP/2/SNI.

This **does not affect real users or the internet**. From cellular, cloud, or any external network, the same request (without `--resolve`) succeeds.

---

## Recommended: Split DNS (production-clean)

To make RPC hostnames work **reliably from inside the LAN** without relying on NAT hairpin:

Configure **internal DNS** (e.g. UniFi DNS, or your LAN resolver) so that these hostnames resolve to **192.168.11.167** (NPMplus) for internal clients:

| Hostname | Internal A record |
|----------|--------------------|
| `rpc-http-pub.d-bis.org` | 192.168.11.167 |
| `rpc-ws-pub.d-bis.org`   | 192.168.11.167 |
| `rpc.defi-oracle.io`     | 192.168.11.167 |
| `wss.defi-oracle.io`     | 192.168.11.167 |

Result:

- **LAN clients** → resolve to 192.168.11.167 → traffic stays on LAN.
- **Internet clients** → resolve to 76.53.10.36 (Cloudflare/public DNS) → UDM Pro port forward → 192.168.11.167.
- No dependency on NAT loopback; same hostnames work from everywhere.

---

## Chain ID note

- **Chain ID 138 (`0x8a)** is valid and does not collide with Ethereum mainnet or common testnets.
- Wallets and tooling treat it as a distinct sovereign EVM chain.

---

## See also

- **NEXT_STEPS_CHAIN138_RPC.md** – .env, scripts, UDM Pro, Chainlist.
- **PUBLIC_RPC_CHAIN138_LEDGER.md** – Public RPC endpoints and backend mapping.
- **RPC_ENDPOINTS_MASTER.md** – Full endpoint and VMID reference.