b8613905bd
- Submodule pins: dbis_core, cross-chain-pmm-lps, mcp-proxmox (local, push may be pending), metamask-integration, smom-dbis-138 - Atomic swap + cross-chain-pmm-lops-publish, deploy-portal workflow, phoenix deploy-targets, routing/aggregator matrices - Docs, token-lists, forge proxy, phoenix API, runbooks, verify scripts Made-with: Cursor
3.1 KiB
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):
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.