RPC help for `protx update_service_evo`/`register_evo` documents platform/core addresses only as `["ADDR:PORT"]` arrays, but a version-2 (MnNetInfo) ProTx requires bare ports

[DashBot-0001]

Summary

For an EvoNode whose registration is a version-2 ProRegTx (the common basic-BLS registration, backed by MnNetInfo), protx update_service_evo (and register_evo) rejects the platform-address form that its own RPC help documents. The help describes platformP2PAddrs / platformHTTPSAddrs (and coreP2PAddrs) only as "Array of addresses in the form "ADDR:PORT"", but for a version-2 ProTx the platform fields accept only a bare port (the IP is inherited from the core address). Passing the documented ["ADDR:PORT"] form fails with a terse error that does not show the accepted format.

This is a developer-experience / documentation issue — the consensus behaviour is correct (MnNetInfo legitimately cannot store separate platform addresses); only the RPC help and the error message fail to communicate the version-conditional format.

Environment

• Dash Core v23.1.2 (reproduced on testnet)
• An EvoNode whose registration is version: 2 (protx info <proTxHash> → "version": 2)

Steps to reproduce

Using the platform-address form shown in help protx update_service_evo:

protx update_service_evo "<proTxHash>" "[\"<IP>:19999\"]" "<operatorKey>" \
      "<platformNodeID>" "[\"<IP>:36656\"]" "[\"<IP>:1443\"]"

→

error code: -8
error message:
Invalid param for platformP2PAddrs, ProTx version only supports ports

The same error occurs for every ADDR:PORT-style platform value tried — "<IP>:36656", "36656", "0.0.0.0:36656", [":36656"], [36656].

What actually works for a version-2 ProTx is a bare integer port for the platform fields (core still requires "ADDR:PORT"):

protx update_service_evo "<proTxHash>" "[\"<IP>:19999\"]" "<operatorKey>" \
      "<platformNodeID>" 36656 1443 "" "<feeSourceAddress>"

Root cause (source pointers, develop)

• src/evo/netinfo.h — MnNetInfo::CanStorePlatform() returns false (~L347), while ExtNetInfo::CanStorePlatform() returns true (~L434). A version-2 ProRegTx uses MnNetInfo, which stores only the core IP plus a platform port (no separate platform address), which is why an "ADDR:PORT" array is rejected for the platform fields. The array form is valid only once the registration uses ExtNetInfo.
• src/rpc/evo.cpp — the RPC help for both register_evo and update_service_evo describes the platform (and core) address args unconditionally as "Array of addresses in the form "ADDR:PORT"" (platform strings ~L186–210); the platform args are processed via ProcessNetInfoPlatform(...) (register_evo ~L774, update_service_evo ~L1052).

So the help documents the ExtNetInfo form unconditionally, even though the prevailing version-2 / MnNetInfo registrations require the bare-port form — and the error gives no example of what is accepted.

Suggested improvement (docs / UX only — no consensus change)

1. RPC help: note the version-conditional format for the platform (and core) address args — e.g. "for a version-2 (MnNetInfo) ProTx, pass a bare port for the platform fields; the "ADDR:PORT" array form requires an ExtNetInfo registration."
2. Error message: make Invalid param for platformP2PAddrs, ProTx version only supports ports show the accepted form / an example (e.g. "expected a bare port, e.g. 36656").
3. Optionally, a docs.dash.org walkthrough for reviving a PoSe-banned EvoNode via update_service_evo, covering the bare-port platform fields, an explicit funded feeSourceAddress (omitting it defaults to the payout address, which usually holds no wallet funds → No funds at specified address), and "" for operatorPayoutAddress when operatorReward == 0 (a real address there is consensus-rejected as bad-protx-operator-payee).

Happy to refine the wording or open a docs PR if useful.

---

🤖 This issue was researched and written by Claude (Anthropic's Claude Code), an AI agent, on behalf of the repository account owner. The reproduction was run against Dash Core v23.1.2; source line references are from the current develop branch.