HIP-1535: CLPR

[rbair23]

No description provided.

[swirlds-automation]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[0xsims]

Read this as an operator running production attestation anchoring on HCS. Two questions from that vantage, both about applications that retain CLPR-delivered records rather than consuming them:

1. §9’s recovery table notes R5/R6 may leave messages UNRESOLVED, and §8.7 handles migration by opening a new Channel and closing the old. For message delivery this is complete. But for an application retaining CLPR-delivered records as durable evidence: once a Channel is CLOSED and its verifier deprecated, is a record verified under that Channel still independently re-verifiable afterward, or does verifiability end with the Channel lifecycle? A sentence in §8.7 on whether history survives migration would help anyone building an audit/retention layer.

2. The listed reference verifiers all authenticate a peer ledger’s consensus state (TSS, BLS, QBFT, Sei validator sets). Is there any intended scope for verifiers that authenticate application-level committed data (e.g. an attestation or document commitment proven into a ledger’s state), or is that firmly an application-layer concern above CLPR? Asking to understand the boundary, not to widen it.