Files

Deploy to Phoenix / deploy (push) Has been cancelled

Details

docs: Ledger Live integration, contract deploy learnings, NEXT_STEPS updates

- ADD_CHAIN138_TO_LEDGER_LIVE: Ledger form done; public code review repo bis-innovations/LedgerLive; init/push commands
- CONTRACT_DEPLOYMENT_RUNBOOK: Chain 138 gas price 1 gwei, 36-addr check, TransactionMirror workaround
- CONTRACT_*: AddressMapper, MirrorManager deployed 2026-02-12; 36-address on-chain check
- NEXT_STEPS_FOR_YOU: Ledger done; steps completable now (no LAN); run-completable-tasks-from-anywhere
- MASTER_INDEX, OPERATOR_OPTIONAL, SMART_CONTRACTS_INVENTORY_SIMPLE: updates
- LEDGER_BLOCKCHAIN_INTEGRATION_COMPLETE: bis-innovations/LedgerLive reference

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-02-12 15:46:57 -08:00

3.1 KiB

Raw Blame History

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.

3.1 KiB Raw Blame History Unescape Escape