zk-nullifier
For custom ZK Solana programs and privacy-preserving applications to prevent double spending. Guide to integrate rent-free nullifier PDAs for double-spend prevention.
50
56%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/zk-nullifier/SKILL.mdQuality
Discovery
40%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description targets a very specific niche (ZK nullifier PDAs on Solana) which gives it strong distinctiveness, but it lacks an explicit 'Use when...' clause and reads somewhat redundantly—the two sentences essentially say the same thing. It would benefit from clearer structure separating capabilities from trigger conditions and expanding the range of natural trigger terms.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when building zero-knowledge Solana programs that need double-spend prevention, nullifier tracking, or privacy-preserving state management.'
Expand trigger terms to include common variations like 'zero-knowledge proofs', 'zk-SNARKs', 'program derived address', 'on-chain privacy', and 'Solana anchor'.
Eliminate redundancy between the two sentences and instead use the second sentence to describe additional concrete actions, such as 'Generates nullifier hash logic, configures rent-exempt PDA accounts, and implements verification checks.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (ZK Solana programs, privacy-preserving applications) and a specific action (integrate rent-free nullifier PDAs for double-spend prevention), but doesn't list multiple concrete actions—it's essentially one capability described twice. | 2 / 3 |
Completeness | It describes what the skill does (integrate nullifier PDAs for double-spend prevention in ZK Solana programs) but has no explicit 'Use when...' clause or equivalent trigger guidance, which per the rubric caps completeness at 2—and the 'what' is also somewhat redundant and unclear, pushing it to 1. | 1 / 3 |
Trigger Term Quality | Includes relevant technical keywords like 'ZK', 'Solana', 'nullifier', 'PDA', 'double spending', and 'privacy-preserving', which are terms a developer would use. However, it misses common variations like 'zero-knowledge proofs', 'zk-SNARKs', 'program derived address', or 'on-chain privacy'. | 2 / 3 |
Distinctiveness Conflict Risk | The combination of ZK, Solana, nullifier PDAs, and double-spend prevention is a very specific niche that is unlikely to conflict with other skills. This is a clearly distinct domain. | 3 / 3 |
Total | 8 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, actionable skill with excellent reference implementations in both Rust and TypeScript. The main weaknesses are the generic workflow boilerplate that doesn't add nullifier-specific value, and some unnecessary explanatory content that Claude would already know. The progressive disclosure and actionability are excellent, with well-organized sections and executable code.
Suggestions
Remove or significantly trim the generic 'Workflow' section (steps 1-5) which is boilerplate planning advice not specific to nullifier implementation.
Add explicit error handling guidance for the address-already-exists case (double-spend attempt) to improve workflow clarity with a validation/recovery loop.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient with good code examples, but includes some unnecessary content like the generic workflow section (steps 1-5) that applies to any skill and the security section which is more about the skill metadata than the task. The overview also explains what nullifiers are at a level Claude likely already knows. | 2 / 3 |
Actionability | Provides fully executable Rust and TypeScript code examples with complete account structures, address derivation, CPI building, and client-side proof fetching. The reference implementation is copy-paste ready with concrete types, function signatures, and instruction building patterns. | 3 / 3 |
Workflow Clarity | The pattern overview provides a clear 5-step sequence, and testing commands are provided. However, the generic workflow (steps 1-5) is a boilerplate planning process, not specific to nullifier implementation. There are no explicit validation checkpoints for the nullifier creation process itself (e.g., verifying the validity proof was obtained correctly, handling address-already-exists errors). | 2 / 3 |
Progressive Disclosure | Content is well-structured with clear sections progressing from overview to pattern to reference implementation to client code. External references are one level deep and clearly signaled with links to example repos, documentation sites, and SDK references in a clean table format. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 9 / 11 Passed | |
- Repository
- Lightprotocol/skills
- Commit
e149bdc
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.