Repository navigation
test: record NS-3 deployment acceptance results - #87
Merged
Merged
Conversation
…yment absent) W2 read-only acceptance exercise against the approved public-cluster endpoint (https://api.devnet.solana.com), run per the PR #83 runbook (docs/DEVNET.md §5, Mode 3) with the unmodified scripts/devnet/verify_ns3_deployment.mjs at commit eaaf935. Verifier verdict: overall FAIL (pass 3 / fail 26 / unverified 0 / info 4, exit 1), two consistent runs (terminal + --json), zero verifier changes. Key observations: - Cluster identity PASS: observed genesis equals the pinned Solana Devnet genesis EtWTRABZaYq6iMfeYKouRu166VU2xqa1wcaWoxPkrZBG — this is the correct cluster (identity proven by genesis, not by URL). - Both NS-3 program accounts are ABSENT (A1/A6 FAIL): GraveScanner EFJpKtWx5gDnc4Hh6GEEgPLUrPh377E4Nfic8jsJAQJL and GraveVault 7VxUGJNgi1bZ8x4rTtLBNdgLs9sCLmUTpVE3on1nshya are not deployed. - Both ProtocolConfig PDAs derive exactly to the pinned addresses (B1/B8 PASS), but the config accounts do not exist (B2/B9 FAIL); governance, oracle, paused-state and defaults checks are therefore FAIL. - Deployed-ELF digest check (established loaded-byte procedure, repo helper modules, read-only): no deployed bytes exist to hash — reported UNVERIFIABLE, not a pass. - Legacy NS-1/NS-2 programs remain present as historical residue (INFO). W2 classification: REJECTED — the observed state contradicts the approved NS-3 deployment specification. This is consistent with the runbook's recorded PENDING deployment status (assigned, NOT yet deployed); it is a not-yet-executed owner deployment from the verifier's point of view, not evidence of tampering — and either way acceptance is not met. Strictly read-only: no keys, no signing, no transactions, no initialization of missing accounts, no pause/unpause, no verifier changes; raw outputs preserved verbatim and sanitized.
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
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.
Summary
Records the W2 NS-3 deployment acceptance exercise: a strictly read-only, owner-controlled verification of the existing public-cluster deployment against the approved deployment specification, using the unmodified PR #83 verifier (
scripts/devnet/verify_ns3_deployment.mjs) per the runbook (docs/DEVNET.md§5, Mode 3).W2 classification: REJECTED — do not read this as a passing acceptance record.
The verifier's overall result is FAIL (pass 3 / fail 26 / unverified 0 / info 4, exit 1), reproducible across two runs (terminal +
--json):EtWTRABZaYq6iMfeYKouRu166VU2xqa1wcaWoxPkrZBG— this is the correct cluster, proven by genesis hash rather than by URL string.EFJpKtWx5gDnc4Hh6GEEgPLUrPh377E4Nfic8jsJAQJLand GraveVault7VxUGJNgi1bZ8x4rTtLBNdgLs9sCLmUTpVE3on1nshyaare not deployed (Section A, A1/A6 and dependent checks).['protocol_config']PDAs derive exactly to the pinned addresses (B1/B8 PASS), but neither config account exists (B2/B9 FAIL); governance authority, dedicated-oracle, paused-state and spec-defaults checks are therefore not observable and FAIL.getAccountInfo, 45-byte header strip, SHA-256) found no deployed bytes to hash against the approved pins; reported as unverifiable, not as a pass.Interpretation. The observed state contradicts the approved NS-3 deployment specification, hence REJECTED. This is consistent with the runbook's recorded status — the NS-3 deployment is "assigned, NOT yet deployed (PENDING)" — i.e., most plausibly an owner deployment step that has not been executed, not evidence of tampering. The verifier cannot distinguish "not yet deployed" from "deployed and later removed"; either way acceptance is not met and the gate stays closed. Closing the gap is an owner-executed Mode 2 deployment per the runbook; a fresh W2 run of this same unmodified verifier is the acceptance path.
Scope and security
docs/w2-ns3-acceptance/(acceptance report, verbatim verifier outputs in terminal and--jsonform, deployed-ELF digest check results). No verifier corrections are proposed — none are needed; the verifier already produces machine-readable output natively (--json) and its fail-closed behavior performed exactly as designed (absence is FAIL, RPC failure would be INCOMPLETE, and 0 checks were UNVERIFIED).main@eaaf935683a3a602bf34bfc0f52e199c571d1ad9; verifier blob3215fa62a4af92a5ea1ab32863f622d3b7b2c9b9; working tree clean throughout.Documentation checks
scripts/doc-links-lint.sh— 143 relative link targets checked, all resolve (exit 0).scripts/terminology-lint.sh— no forbidden vocabulary detected (exit 0).prettier --check .(3.9.10, repo config) — all files pass (exit 0).