feat: add Platform Tenderdash chain id to CChainParams

[PastaPastaPasta]

Issue being fixed or feature implemented

A Dash Platform client verifies that signed response metadata comes from the Platform chain it expects. The chain id is part of what the quorum signs. The DashPay GUI in dash-qt (tracking issue #7512) needs each network's Platform chain id. Core already carries the other Platform network parameters (nDefaultPlatformP2PPort, nDefaultPlatformHTTPPort and the bech32 HRP), so this PR puts the chain id next to them.

Earlier, the value was proposed for dash-sdk's own configuration (dashpay/platform#4963). The maintainer closed that PR, so the Platform shell keeps the check, and Core supplies the value from CChainParams. This answers knst's question about where the chain id should live, asked on the earlier composite branch.

What was done?

• CChainParams::PlatformChainId() returns "evo1" on mainnet and "dash-testnet-51" on testnet. Both match the genesis chain_id in dashmate's mainnet and testnet config defaults. Devnet and regtest have no canonical Platform chain, so their id is empty.
• The chain id is a network parameter, not a consensus rule, so it stays out of Consensus::Params.
• No command-line options are added. The GUI adds a GUI-only -platformchainid override for testnet and devnets, which is refused on mainnet.

How Has This Been Tested?

No unit test is added. The values are constants, so a test would only repeat them. Instead, I checked the values against the genesis chain_id in dashmate's mainnet and testnet config defaults. The branch builds on top of develop (0f876369f9c7) on aarch64-apple-darwin.

The DashPay GUI verified every live testnet response against dash-testnet-51 from this parameter. -platformchainid=bogus produced an explicit chain-id mismatch (see #7512).

Breaking Changes

None.

Checklist:

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone (for repository code-owners and collaborators only)

🤖 Generated with Claude Code

[thepastaclaw]

🔍 Review in progress — actively reviewing now (commit f0d9d6a) · triage: low
█░░░░░░░░░░░░░░░░░░░ 5% · about 20 min left · running for 1 min
✅ triage → ⏳ Phase 1 (0/1 lanes) → ▫️ verify 1 → ▫️ gate → ▫️ Phase 2 → ▫️ verify 2 → ▫️ publish
_{Estimated from recent reviews of this tier · updated 00:53 UTC · live progress}

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: 5a9f5b80-f827-4a54-a828-139d6fe0f8ef

📥 Commits

Reviewing files that changed from the base of the PR and between 3ba0805 and bf7ad04.

📒 Files selected for processing (5)

• src/Makefile.test.include
• src/chainparams.cpp
• src/chainparams.h
• src/test/chainparams_platform_tests.cpp
• test/util/data/non-backported.txt

Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 2 remain after this review.

---

Walkthrough

CChainParams now exposes a PlatformChainId() accessor. Mainnet uses evo1, testnet uses dash-testnet-51, and devnet and regtest use an empty string. A test checks these values, and the test source is added to the test build.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~8 minutes

Merge Risk: ⚪ Minimal · up to bf7ad

This adds per-network Platform ID access. No concrete behavior mismatch or merge-blocking issue was established in the reviewed code.

Security Architecture Review

Security architecture risk: 🔵 Low · up to bf7ad

The new values are fixed per network and tested. This change does not add a response verifier or expose a new network entrypoint, but the downstream verification behavior is outside the reviewed change.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The visible change exposes network-selected constants to callers, without adding an attacker-controlled endpoint or a response-processing path.

Trust Boundaries and Controls

• inferred — Whether downstream verification rejects mismatched or empty expected chain IDs cannot be determined from the added accessor and value-comparison test.

Hardening Proposals

• proposed — At the downstream verifier boundary, require an explicit expected ID or an intentional network-specific override, and reject mismatches rather than treating an empty ID as a disabled check.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 14.29% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 7 functions across 3 files. (2 skipped: 2…	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly summarizes the main change: adding the Platform Tenderdash chain ID to CChainParams.
Description check	✅ Passed	The description explains the chain ID values, why Core provides them, and how the change was tested. It is related to the changeset.

Full details: Docstring Coverage

Explanation

Docstring coverage is 14.29% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 7 functions across 3 files. (2 skipped: 2 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

Final validation — Phase 1 + Phase 2

Verified the complete single-commit change at bf7ad04 and found no actionable defects: all four network values match the PR description, the accessor is additive, and the new test is registered in both required lists. The unit-test target built successfully; chainparams_platform_tests, pow_tests, llmq_params_tests, and evo_netinfo_tests passed, git diff --check passed, and the worktree remains clean. External Platform genesis values and the reported mutation check were not independently verified; the claimed chainparams_tests suite was not present in the executed binary.

Review provenance

Source: reviewer 1: glm-5.3-flash (agent: phase1-reviewer, role: general); reviewer 2: glm-5.3-flash (agent: phase1-reviewer, role: dash-core-commit-history); reviewer 3: gpt-6-astra (agent: phase2-reviewer, role: general); reviewer 4: gpt-6-astra (agent: phase2-reviewer, role: dash-core-commit-history); final verifier: gpt-6-astra (agent: astra-verifier, role: final-verifier)

• Triage: low by gpt-6-astra (effort low) — The diff adds a small, self-contained network parameter and accessor with straightforward per-network tests and build registration, without changing consensus, signature verification, or other critical logic.
• Phase 1 reviewers: glm-5.3-flash — general (completed, effort high); agent phase1-reviewer, glm-5.3-flash — dash-core-commit-history (completed, effort high); agent phase1-reviewer
• Phase 1 model: glm-5.3-flash — zai quota: 5h 89% left, weekly 94% left; passed over gemini-3.8-flash-high (antigravity below 15% reserve: weekly 13% left, 5h 100% left)
• Fresh verifier: gpt-6-astra — final-verifier; agent astra-verifier
• Phase 2 reviewers: gpt-6-astra — general (completed, effort medium); agent phase2-reviewer, gpt-6-astra — dash-core-commit-history (completed, effort medium); agent phase2-reviewer

[PastaPastaPasta]

Closing this. The Platform client does not need an expected chain id.

chain_id is already part of the message the quorum signs (StateId::calculate_msg_hash and CanonicalVote in verify_tenderdash_proof). A response that verifies against a quorum from our own Core chain is already bound to a chain that quorum signed. Comparing it to a pinned value adds no security. The reasoning is the same as in dashpay/platform#4963:

• A forged chain id breaks the signature.
• A response replayed from another network fails because that network's quorums are not in our Core chain.
• Mainnet quorums have only ever signed evo1.
• The one case left, a stale testnet node after a Platform reset, is covered by the SDK's signed-time window and ChainLock lag gate.

With no check, nothing reads PlatformChainId(), so the parameter has no reason to be in CChainParams. The pinned testnet value would also go stale on every testnet Platform reset. The chain-id check and -platformchainid will be removed from the Platform GUI stack (dashpay/platform#4633, #7670, #7671, #7765, #7767) separately.

---

🤖 Posted autonomously by Codex on behalf of pasta.