Verifier Assessment

Implement Verifier Assessment

Comprehensive feasibility assessment for integrating a ZK proof verification crate as a zkVerify verifier pallet. The assessment is structured in stages:

1. Prerequisites: no_std compatibility and stable toolchain support (delegated to specialized subagents running in parallel)
2. Verifier analysis: type mapping to the Verifier trait, unsafe code analysis, removal strategies, and Substrate compatibility
3. Final report: a consolidated feasibility report covering all dimensions, audited by an independent subagent

The assessment proceeds to stage 2 only if the prerequisite checks in stage 1 yield a positive result (Go or Conditional Go). If either prerequisite is a No Go, the process stops early and reports the blockers to the user.

Scope: assessment and reporting only — never modify the crate's code or create PRs.

Role

Operate as a senior Rust developer with strong zero-knowledge background. As applied cryptographer, understand what a zero-knowledge proof is and what verifying a proof means. Understand the distinction between Vk (verification key), Proof, and Pubs (public inputs) as described below.

Core Concepts

• Vk (Verification Key): Identifies uniquely what a set of proofs are proving. For a zkVM it identifies the executed program; for a SNARK it identifies the circuit.
• Pubs (Public Inputs): Public data for the program. Combined with the Vk they form the statement asserted by the proof.
• Proof: The variable data. The same statement can generate different proofs.

The target interface is the zkVerify Verifier trait from pallet-verifiers. Read and follow references/zkverify-verifier-trait.md for the full trait definition, type mapping patterns, and two worked examples (fflonk as simple, risc0 as complex).

Input

Collect the crate coordinates from the user. Accepted forms:

• GitHub repo + crate name: e.g., https://github.com/org/repo with crate my-verifier
• Local path: e.g., /home/user/code/my-verifier
• crates.io name: e.g., my-verifier (fetch from crates.io)

If the user does not provide coordinates, ask before proceeding. Do not guess.

Workflow

Phase 1: Plan

Before any analysis, create a plan and present it to the user for approval. The plan should outline:

1. What crate will be analyzed and how it will be accessed
2. The three-stage assessment approach (prerequisites → verifier analysis → final report)
3. What the expected outputs are (individual prerequisite reports + final consolidated report)

Phase 2: Prerequisite Assessment (Parallel Subagents)

Spawn two subagents in parallel, each with a clean context (no inherited state from this conversation). Each subagent receives the crate coordinates and the full content of its respective skill file as instructions.

Subagent 1: no_std Compatibility

Spawn a general-purpose subagent with the Agent tool. Build its prompt as follows:

1. Read the skill file at ${CLAUDE_PLUGIN_ROOT}/skills/zkverify-verifier-assessment/no-std-assessment/SKILL.md
2. Read all referenced files mentioned in that skill (under the same no-std-assessment/ directory: references/report-template.md, references/analysis-guide.md)
3. Include the crate coordinates
4. Instruct the subagent to follow the skill's workflow end-to-end, including its own audit step
5. The subagent must write the report to reports/<crate-name>-no-std-assessment.md

Subagent 2: Stable Toolchain Compatibility

Spawn a general-purpose subagent with the Agent tool. Build its prompt as follows:

1. Read the skill file at ${CLAUDE_PLUGIN_ROOT}/skills/zkverify-verifier-assessment/rust-stable-assessment/SKILL.md
2. Read all referenced files mentioned in that skill (under the same rust-stable-assessment/ directory: references/report-template.md, references/audit-prompt.md)
3. Include the crate coordinates
4. Instruct the subagent to follow the skill's workflow end-to-end, including its own audit step
5. The subagent must write the report to reports/<crate-name>-stable-assessment.md

Both subagents must be launched in the same tool-call message to run in parallel.

Phase 3: Gate Check

After both subagents complete, read their reports and evaluate the verdicts:

• Both Go or Conditional Go → proceed to Phase 4
• Either No Go → STOP. Present the blocker(s) to the user with the relevant report findings. Ask if they want to proceed anyway (e.g., if they plan to fix the blockers first) or abort.

When presenting the gate result to the user, include a brief summary of each prerequisite report's verdict and key findings.

Phase 4: Verifier-Specific Analysis

This phase analyzes the crate's suitability for implementing the zkVerify Verifier trait.

Step 1 — Locate the Verification Entry Point

Search the crate for the verify function or equivalent. Identify:

• The function signature
• The types used for verification key, proof, and public inputs
• Whether the crate exposes a clean verify(vk, proof, pubs) API or a more complex interface

Step 2 — Map Types to zkVerify Verifier Trait

For each of the three core types (Vk, Proof, Pubs), determine:

• The crate's native type
• How it serializes/deserializes (serde, custom, byte arrays)
• The complexity of mapping to the Verifier trait's associated types
• Whether fixed-size ([u8; N]) or variable-size (Vec<u8>) representation is appropriate
• Whether multiple proof versions exist (enum pattern needed)

Classify the facade as simple (fflonk-like) or complex (risc0-like). Read and follow references/zkverify-verifier-trait.md for the decision criteria.

Step 3 — Analyze Unsafe Code

Perform a two-level unsafe analysis:

1. Direct: Search the target crate source for unsafe blocks, unsafe fn, unsafe impl
2. Transitive: Identify dependencies on the verification path and check their unsafe usage

For each unsafe occurrence, classify it (FFI, transmute, pointer, asm, unsafe trait impl) and assess removability. Read and follow references/unsafe-assessment-rules.md for the full strategy framework.

Step 4 — Assess Substrate Compatibility

Using the findings from the prerequisite reports (Phase 2) plus additional checks:

• Availability of Encode, Decode, TypeInfo derives (or feasibility of adding them)
• Deterministic execution (no floating point, no randomness in verify path)
• alloc usage compatibility
• Any additional concerns surfaced by the no_std or stable toolchain reports

Phase 5: Final Report Generation

Generate the final consolidated report following the template in references/report-template.md. The report must incorporate and reference the prerequisite findings:

• Include a Prerequisites Summary section at the top that summarizes the no_std and stable toolchain verdicts with key findings from each report
• Reference the individual prerequisite reports by path for full details
• Cover the verifier-specific analysis (type mapping, unsafe, Substrate compatibility)

Rules for the report:

• Start from the most important concepts, then move to secondary considerations
• Use bullet points and simple, direct language
• Be skeptical — think about each statement more than once, deeply
• Apply confidence labels (GOOD/REASONABLE/POOR) per references/unsafe-assessment-rules.md

Output path: reports/<crate-name>-verifier-assessment.md

If a report already exists at any target path (including prerequisite reports), ask the user whether to overwrite or append a timestamp to the new filename (e.g., <crate-name>-verifier-assessment-20260316.md).

Phase 6: Audit

After writing the final report, spawn a clean subagent with no prior context to audit it. The subagent receives ONLY the final report text, the two prerequisite report texts, and the crate coordinates. It must:

1. Analyze every statement from a skeptical point of view
2. Verify conclusions against the actual crate code
3. Cross-check that prerequisite findings are accurately represented
4. Flag overconfident or unsupported claims
5. Suggest confidence adjustments

Update the report based on audit findings.

Critical Rules

• ASK DON'T GUESS: If anything is unclear — a type mapping, an API usage, the purpose of an unsafe block — ask the user before making assumptions.
• Unsafe-free goal: The target is that the verification code path should not use unsafe and the functions called from the underlying crate should not use unsafe. If this is not achievable, the report must clearly state why and what the alternatives are.
• Clean subagent contexts: All subagents (prerequisite assessments and final audit) must have NO context from the parent conversation. Pass only the necessary inputs. This prevents confirmation bias.
• Parallel execution: The two prerequisite subagents MUST be launched in the same tool-call message to run in parallel.
• Respect the gate: Do NOT proceed to verifier analysis if prerequisites are No Go, unless the user explicitly overrides.
• No implementation: This skill assesses feasibility only. Do not write Rust code for the verifier pallet itself.

Reference Files

• references/zkverify-verifier-trait.md — Full Verifier trait definition, type mapping patterns, fflonk (simple) and risc0 (complex) worked examples, weight system, pallet structure
• references/unsafe-assessment-rules.md — Two-level unsafe analysis methodology, five removal strategies (A–E) with pros/cons/PR feasibility, confidence evaluation rules, audit process
• references/report-template.md — Complete report template with all sections, tables, legend, and writing rules

Sibling Skills (used by prerequisite subagents)

• ${CLAUDE_PLUGIN_ROOT}/skills/zkverify-verifier-assessment/no-std-assessment/ — Full no_std compatibility assessment with scanner script, analysis guide, and report template
• ${CLAUDE_PLUGIN_ROOT}/skills/zkverify-verifier-assessment/rust-stable-assessment/ — Stable toolchain assessment with feature-by-feature evaluation, audit prompt, and report template