docs(specs): a Verifier Version beside the Platform Ceremony Version - #23
Merged
Wondertan merged 1 commit intoSep 2, 2026
Merged
Conversation
The Platform Ceremony Version identifies the ceremony boundary and is bound in the digest, so it is the same on every Consumer Chain. What a Consumer Chain routes on is a second number, the Verifier Version: local to that chain, assigned on its own cadence, and not in the digest. Two Verifier Versions may implement one Platform Ceremony Version, so a proof stays acceptable across a verifier upgrade; the Consumer's nullifier, not the route, prevents replay. Because routing no longer names what the digest binds, the Proof Verifier can no longer recompute the digest. The Submission becomes a platform, a Verifier Version, a value, and an opaque Submission Payload that only the selected Platform Verifier decodes. That verifier refuses any ceremony version but its own before a fee moves, recomputes the digest from what it decoded and its own Chain ID, and returns the digest with its fields. REQ-COMMON-02, 46 and 06C move accordingly. Signed-off-by: xgreenx <xgreenx9999@gmail.com> Assisted-by: Claude Fable 5.1
xgreenx
force-pushed
the
spec/verifier-version-axis
branch
from
September 2, 2026 18:22
cc4f406 to
50230fa
Compare
xgreenx
marked this pull request as ready for review
September 2, 2026 18:28
Wondertan
approved these changes
Sep 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A proof made for a ceremony version is acceptable at every registered Platform Verifier implementing it; the Consumer's nullifier (REQ-COMMON-03) prevents replay among them, so a verifier upgrade strands nothing in flight.
Consequence: the Proof Verifier cannot recompute the digest, because routing no longer names what the digest binds. The Submission is now
(platform, Verifier Version, value, Submission Payload); only the selected Platform Verifier decodes the payload, refuses a foreign ceremony version before a fee moves, recomputes the digest from what it decoded and its own Chain ID, and returns the digest with its fields.Touched: terminology (
Verifier Version,Submission Payloadadded; six entries reworded); REQ-COMMON-01B, 01C, 02, 05, 05A, 05B, 05E, 06, 06B, 06C, 06E, 18, 45, 46; §5.1; §12; TEST-COMMON-16/22/23;platform-ceremonies.md§2 and REQ-PLAT-01B.Linted with
.agents/skills/trust-min-protocol-specs: no findings introduced over the base; one pre-existing W2/W4 pair removed.Implemented this way in libid-org/libid-contracts#18 (merged into #13).
Not in scope: #20 also rewrites §7 PKCE to
SHA256(authorizationDigest || authorizationNonce); the contracts still implement main's construction withPKCE_DOMAINand a separatepkceNonce. Separate decision.