AI Prompts

---
description: Distribute compressed tokens via airdrop
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Distribute compressed tokens via airdrop

Context:
- Guide: https://zkcompression.com/compressed-tokens/token-distribution
- Skills and resources index: https://zkcompression.com/skill.md
- Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/airdrop
- Packages: @lightprotocol/compressed-token, @lightprotocol/stateless.js, @solana/spl-token
- Example repo: https://github.com/Lightprotocol/example-token-distribution
- Webapp alternative: https://airship.helius.dev/ (Airship by Helius Labs, up to 200k recipients)

Key APIs: LightTokenProgram.compress(), getTokenPoolInfos(), selectTokenPoolInfo(), getStateTreeInfos(), selectStateTreeInfo(), buildAndSignTx(), sendAndConfirmTx()

### 1. Index project
- Grep `LightTokenProgram|compress|getTokenPoolInfos|selectTokenPoolInfo|getStateTreeInfos|@lightprotocol|airdrop|distribution` across src/
- Glob `**/*.ts` for project structure
- Identify: existing airdrop/distribution logic, token minting setup, recipient list format
- Check package.json for existing @lightprotocol/* or @solana/spl-token dependencies
- Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

### 2. Read references
- WebFetch the guide above — review all three tabs (Localnet Guide, Simple Airdrop, Batched)
- WebFetch skill.md — check for a dedicated skill and resources matching this task
- TaskCreate one todo per phase below to track progress

### 3. Clarify intention
- AskUserQuestion: what scale? (<10k recipients = simple airdrop, 10k+ = batched)
- AskUserQuestion: localnet testing first, or production deploy?
- AskUserQuestion: do you have an existing SPL mint, or need to create one?
- AskUserQuestion: do you need decompression/claim functionality, or just direct distribution?
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan
- For simple airdrop: create mint → mint SPL tokens → LightTokenProgram.compress() with recipients array
- For batched: create instruction batches → manage blockhash refresh → sign and send with retry logic
- Address lookup table needed for production (mainnet: 9NYFyEqPkyXUhkerbGHXUXkvb4qpzeEdHuGpgbgpH1NJ)
- If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
- Present the plan to the user for approval before proceeding

### 5. Implement
- Add deps if missing: Bash `npm install @lightprotocol/compressed-token @lightprotocol/stateless.js @solana/spl-token`
- Set up RPC: `createRpc(RPC_ENDPOINT)` with a ZK Compression endpoint (Helius, Triton)
- Follow the guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `tsc --noEmit`
- Bash run existing test suite or execute localnet test airdrop
- TaskUpdate to mark complete

### Tools
- mcp__zkcompression__SearchLightProtocol("<query>") for API details
- mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
- Task subagent with Grep/Read/WebFetch for parallel lookups
- TaskList to check remaining work

---
description: Create rent-free nullifier PDAs to prevent duplicate actions
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Create rent-free nullifier PDAs to prevent duplicate actions

Context:
- Guide: https://zkcompression.com/compressed-pdas/nullifier-pda
- Skills and resources index: https://zkcompression.com/skill.md
- Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/zk-nullifier
- Rust crates: light-nullifier-program, light-client
- TS packages: @lightprotocol/nullifier-program, @lightprotocol/stateless.js
- Example: https://github.com/Lightprotocol/examples-light-token/blob/main/rust-client/actions/create_nullifier.rs
- Program source: https://github.com/Lightprotocol/nullifier-program/

Key APIs:
- Rust: create_nullifier_ix(), fetch_proof(), build_instruction(), derive_nullifier_address()
- TS: createNullifierIx(), fetchProof(), buildInstruction(), deriveNullifierAddress()

### 1. Index project
- Grep `nullifier|create_nullifier|createNullifierIx|deriveNullifierAddress|NFLx5WGPrTHHvdRNsidcrNcLxRruMC92E4yv7zhZBoT` across src/
- Glob `**/*.rs` and `**/*.ts` for project structure
- Identify: existing transaction building, duplicate prevention logic, payment flow
- Check Cargo.toml or package.json for existing light-* dependencies
- Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

### 2. Read references
- WebFetch the guide above — review both Rust and TS code samples
- WebFetch skill.md — check for a dedicated skill and resources matching this task
- TaskCreate one todo per phase below to track progress

### 3. Clarify intention
- AskUserQuestion: Rust or TypeScript?
- AskUserQuestion: what is the goal? (prevent duplicate payments, idempotent instruction execution, other use case)
- AskUserQuestion: do you need the helper (create_nullifier_ix) or manual proof fetching (fetch_proof + build_instruction)?
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
- Follow the guide's pattern: create unique 32-byte ID → build nullifier instruction → prepend to transaction
- If checking existence is needed, add derive_nullifier_address + get_compressed_account check
- If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
- Present the plan to the user for approval before proceeding

### 5. Implement
- For Rust: Bash `cargo add light-nullifier-program@0.1 light-client@0.23`
- For TypeScript: Bash `npm install @lightprotocol/nullifier-program @lightprotocol/stateless.js@^0.23.0`
- Follow the guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Rust: Bash `cargo check` + `cargo test` if tests exist
- TypeScript: Bash `tsc --noEmit` + run existing test suite if present
- TaskUpdate to mark complete

### Tools
- mcp__zkcompression__SearchLightProtocol("<query>") for API details
- mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
- Task subagent with Grep/Read/WebFetch for parallel lookups
- TaskList to check remaining work

---
description: Write client code to interact with compressed PDA programs
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Write client code to interact with compressed PDA programs

Context:
- Guide: https://zkcompression.com/compressed-pdas/guides/client-guide
- Skills and resources index: https://zkcompression.com/skill.md
- TS packages: @lightprotocol/stateless.js, @lightprotocol/compressed-token, @solana/web3.js
- Rust crates: light-client, light-sdk
- TS example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/create/tests
- Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/create/programs/create/tests
- All operations: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor

Key APIs:
- TS: createRpc(), deriveAddressSeedV2(), deriveAddressV2(), getValidityProofV0(), PackedAccounts, SystemAccountMetaConfig, getStateTreeInfos(), selectStateTreeInfo()
- Rust: LightClientConfig, LightClient, derive_address(), get_validity_proof(), PackedAccounts, SystemAccountMetaConfig, get_random_state_tree_info()

### 1. Index project
- Grep `@lightprotocol|stateless\.js|createRpc|deriveAddress|getValidityProof|PackedAccounts|light_client|light_sdk|derive_address|get_validity_proof` across src/
- Glob `**/*.ts` and `**/*.rs` for project structure
- Identify: RPC setup, existing compressed account operations, program ID references
- Check package.json or Cargo.toml for existing light-* dependencies
- Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

### 2. Read references
- WebFetch the guide above — review both TypeScript and Rust code samples
- WebFetch skill.md — check for a dedicated skill and resources matching this task
- TaskCreate one todo per phase below to track progress

### 3. Clarify intention
- AskUserQuestion: TypeScript or Rust?
- AskUserQuestion: what is the goal? (new client from scratch, add client calls to existing project, migrate from regular accounts)
- AskUserQuestion: which operations? (create only, full CRUD, specific subset like create + update)
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
- Follow the guide's step order: Setup → Address derivation → Validity proof → PackedAccounts → Instruction data → Build instruction → Send transaction
- If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
- Present the plan to the user for approval before proceeding

### 5. Implement
- For TypeScript: Bash `npm install @lightprotocol/stateless.js @lightprotocol/compressed-token @solana/web3.js`
- For Rust: Bash `cargo add light-client@0.23 light-sdk@0.23`
- Follow the guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- TypeScript: Bash `tsc --noEmit` + run existing test suite if present
- Rust: Bash `cargo check` + `cargo test` if tests exist
- TaskUpdate to mark complete

### Tools
- mcp__zkcompression__SearchLightProtocol("<query>") for API details
- mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
- Task subagent with Grep/Read/WebFetch for parallel lookups
- TaskList to check remaining work

---
description: Build a program that creates compressed accounts with addresses
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Build a program that creates compressed accounts with addresses

Context:
- Guide: https://zkcompression.com/compressed-pdas/guides/how-to-create-compressed-accounts
- Skills and resources index: https://zkcompression.com/skill.md
- Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
- Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/create
- Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/create

Key SDK API: LightAccount::new_init(), derive_address()

### 1. Index project
- Grep `declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|seeds|init|payer|space` across src/
- Glob `**/*.rs` and `**/Cargo.toml` for project structure
- Identify: program ID, existing instructions, account structs, framework (Anchor or native)
- Read Cargo.toml — note existing dependencies and Solana SDK version
- Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

### 2. Read references
- WebFetch the guide above — review both Anchor and Native Rust code samples
- WebFetch skill.md — check for a dedicated skill and resources matching this task
- TaskCreate one todo per phase below to track progress

### 3. Clarify intention
- AskUserQuestion: what is the goal? (new program from scratch, add account creation to existing program, migrate from regular accounts)
- AskUserQuestion: Anchor or Native Rust framework?
- AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
- Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Derive Address → Address Tree Check → Initialize Account → Light System Program CPI
- If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
- Present the plan to the user for approval before proceeding

### 5. Implement
- Add deps: Bash `cargo add light-sdk@0.23` (add `anchor_lang@0.31` for Anchor or `solana-program@2.2` + `borsh@0.10` for Native Rust)
- Follow the guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `cargo build-sbf` or `anchor build`
- Bash `cargo test-sbf` or `anchor test` if tests exist
- TaskUpdate to mark complete

### Tools
- mcp__zkcompression__SearchLightProtocol("<query>") for API details
- mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
- Task subagent with Grep/Read/WebFetch for parallel lookups
- TaskList to check remaining work

---
description: Build a program that updates compressed accounts
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Build a program that updates compressed accounts

Context:
- Guide: https://zkcompression.com/compressed-pdas/guides/how-to-update-compressed-accounts
- Skills and resources index: https://zkcompression.com/skill.md
- Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
- Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/update
- Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/update

Key SDK API: LightAccount::new_mut()

### 1. Index project
- Grep `declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|mut|update|modify` across src/
- Glob `**/*.rs` and `**/Cargo.toml` for project structure
- Identify: program ID, existing instructions, account structs, framework (Anchor or native)
- Read Cargo.toml — note existing dependencies and Solana SDK version
- Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

### 2. Read references
- WebFetch the guide above — review both Anchor and Native Rust code samples
- WebFetch skill.md — check for a dedicated skill and resources matching this task
- TaskCreate one todo per phase below to track progress

### 3. Clarify intention
- AskUserQuestion: what is the goal? (new program from scratch, add account update to existing program, migrate from regular accounts)
- AskUserQuestion: Anchor or Native Rust framework?
- AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
- Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Update Compressed Account → Light System Program CPI
- If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
- Present the plan to the user for approval before proceeding

### 5. Implement
- Add deps: Bash `cargo add light-sdk@0.23` (add `anchor_lang@0.31` for Anchor or `solana-program@2.2` + `borsh@0.10` for Native Rust)
- Follow the guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `cargo build-sbf` or `anchor build`
- Bash `cargo test-sbf` or `anchor test` if tests exist
- TaskUpdate to mark complete

### Tools
- mcp__zkcompression__SearchLightProtocol("<query>") for API details
- mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
- Task subagent with Grep/Read/WebFetch for parallel lookups
- TaskList to check remaining work

---
description: Build a program that closes compressed accounts
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Build a program that closes compressed accounts

Context:
- Guide: https://zkcompression.com/compressed-pdas/guides/how-to-close-compressed-accounts
- Skills and resources index: https://zkcompression.com/skill.md
- Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
- Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/close
- Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/close

Key SDK API: LightAccount::new_close()

### 1. Index project
- Grep `declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|close|delete|remove` across src/
- Glob `**/*.rs` and `**/Cargo.toml` for project structure
- Identify: program ID, existing instructions, account structs, framework (Anchor or native)
- Read Cargo.toml — note existing dependencies and Solana SDK version
- Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

### 2. Read references
- WebFetch the guide above — review both Anchor and Native Rust code samples
- WebFetch skill.md — check for a dedicated skill and resources matching this task
- TaskCreate one todo per phase below to track progress

### 3. Clarify intention
- AskUserQuestion: what is the goal? (new program from scratch, add account close to existing program, migrate from regular accounts)
- AskUserQuestion: Anchor or Native Rust framework?
- AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
- Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Close Compressed Account → Light System Program CPI
- If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
- Present the plan to the user for approval before proceeding

### 5. Implement
- Add deps: Bash `cargo add light-sdk@0.23` (add `anchor_lang@0.31` for Anchor or `solana-program@2.2` + `borsh@0.10` for Native Rust)
- Follow the guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `cargo build-sbf` or `anchor build`
- Bash `cargo test-sbf` or `anchor test` if tests exist
- TaskUpdate to mark complete

### Tools
- mcp__zkcompression__SearchLightProtocol("<query>") for API details
- mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
- Task subagent with Grep/Read/WebFetch for parallel lookups
- TaskList to check remaining work

---
description: Build a program that reinitializes closed compressed accounts
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Build a program that reinitializes closed compressed accounts

Context:
- Guide: https://zkcompression.com/compressed-pdas/guides/how-to-reinitialize-compressed-accounts
- Skills and resources index: https://zkcompression.com/skill.md
- Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
- Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/reinit
- Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/reinit

Key SDK API: LightAccount::new_empty()

### 1. Index project
- Grep `declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|reinit|empty|reset` across src/
- Glob `**/*.rs` and `**/Cargo.toml` for project structure
- Identify: program ID, existing instructions, account structs, framework (Anchor or native)
- Read Cargo.toml — note existing dependencies and Solana SDK version
- Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

### 2. Read references
- WebFetch the guide above — review both Anchor and Native Rust code samples
- WebFetch skill.md — check for a dedicated skill and resources matching this task
- TaskCreate one todo per phase below to track progress

### 3. Clarify intention
- AskUserQuestion: what is the goal? (new program from scratch, add account reinitialization to existing program, migrate from regular accounts)
- AskUserQuestion: Anchor or Native Rust framework?
- AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
- Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Reinitialize Closed Account → Light System Program CPI
- If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
- Present the plan to the user for approval before proceeding

### 5. Implement
- Add deps: Bash `cargo add light-sdk@0.23` (add `anchor_lang@0.31` for Anchor or `solana-program@2.2` + `borsh@0.10` for Native Rust)
- Follow the guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `cargo build-sbf` or `anchor build`
- Bash `cargo test-sbf` or `anchor test` if tests exist
- TaskUpdate to mark complete

### Tools
- mcp__zkcompression__SearchLightProtocol("<query>") for API details
- mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
- Task subagent with Grep/Read/WebFetch for parallel lookups
- TaskList to check remaining work

---
description: Build a program that permanently burns compressed accounts
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Build a program that permanently burns compressed accounts

Context:
- Guide: https://zkcompression.com/compressed-pdas/guides/how-to-burn-compressed-accounts
- Skills and resources index: https://zkcompression.com/skill.md
- Crate: light-sdk (LightAccount, CpiAccounts, LightSystemProgramCpi, derive_light_cpi_signer!)
- Anchor example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/anchor/burn
- Native Rust example: https://github.com/Lightprotocol/program-examples/tree/main/basic-operations/native/programs/burn

Key SDK API: LightAccount::new_burn()

### 1. Index project
- Grep `declare_id|#\[program\]|entrypoint!|Pubkey|AccountInfo|burn|destroy|permanent` across src/
- Glob `**/*.rs` and `**/Cargo.toml` for project structure
- Identify: program ID, existing instructions, account structs, framework (Anchor or native)
- Read Cargo.toml — note existing dependencies and Solana SDK version
- Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

### 2. Read references
- WebFetch the guide above — review both Anchor and Native Rust code samples
- WebFetch skill.md — check for a dedicated skill and resources matching this task
- TaskCreate one todo per phase below to track progress

### 3. Clarify intention
- AskUserQuestion: what is the goal? (new program from scratch, add account burn to existing program, migrate from regular accounts)
- AskUserQuestion: Anchor or Native Rust framework?
- AskUserQuestion: does the program already have compressed account instructions, or is this the first one?
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan: which files to modify, what code to add, dependency changes
- Follow the guide's step order: Dependencies → Constants → Account Struct → Instruction Data → Burn Compressed Account → Light System Program CPI
- If anything is unclear or ambiguous, loop back to step 3 (AskUserQuestion)
- Present the plan to the user for approval before proceeding

### 5. Implement
- Add deps: Bash `cargo add light-sdk@0.23` (add `anchor_lang@0.31` for Anchor or `solana-program@2.2` + `borsh@0.10` for Native Rust)
- Follow the guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `cargo build-sbf` or `anchor build`
- Bash `cargo test-sbf` or `anchor test` if tests exist
- TaskUpdate to mark complete

### Tools
- mcp__zkcompression__SearchLightProtocol("<query>") for API details
- mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "<q>") for architecture
- Task subagent with Grep/Read/WebFetch for parallel lookups
- TaskList to check remaining work

---
argument-hint: <path_to_program>
description: Migrate Light Protocol program from v1 to v2 Merkle trees
allowed-tools: [Bash, Read, Glob, Grep, Task, WebFetch]
---

Migrate this Light Protocol program from v1 to v2 Merkle trees.

## Goal

Produce a **fully working migration** that builds and tests pass.

## Available commands

Via Bash tool:
- **cargo build-sbf**, **cargo test-sbf**, **cargo fmt**, **cargo clippy**
- **anchor build**, **anchor test**
- **grep**, **sed**

## Documentation

- Migration Guide: https://zkcompression.com/references/migration-v1-to-v2
- Reference PR: https://github.com/Lightprotocol/program-examples/commit/54f0e7f15c2972a078f776cfb40b238d83c7e486

## Reference repos

program-examples/counter/anchor/
├── programs/counter/src/lib.rs    # v2 patterns: derive_address, CpiAccounts
├── Cargo.toml                      # v2 feature flags
└── tests/counter.ts                # v2 client patterns

## Workflow

### Phase 1: Index program

Find all v1 patterns:

    grep -r "::v1::" src/ tests/
    grep -r "ADDRESS_TREE_V1" src/
    grep -r "into_new_address_params_packed" src/
    grep -r "get_address_tree_v1" tests/

### Phase 2: Update dependencies

Update Cargo.toml. V2 is the default - no feature flag needed:

    # On-chain program
    [dependencies]
    light-sdk = { version = "0.17.1", features = ["anchor"] }
    light-hasher = "5.0.0"

    # Off-chain client
    [dependencies]
    light-client = "0.17.2"

Note: V2 is now the default in all crates. Only specify `features = ["v2"]` if you disabled default features.

### Phase 3: Rust SDK replacements

| v1 Pattern | v2 Replacement |
|------------|----------------|
| address::v1::derive_address | address::v2::derive_address |
| cpi::v1::CpiAccounts | cpi::v2::CpiAccounts |
| cpi::v1::LightSystemProgramCpi | cpi::v2::LightSystemProgramCpi |
| constants::ADDRESS_TREE_V1 | constants::ADDRESS_TREE_V2 |
| .into_new_address_params_packed(seed) | .into_new_address_params_assigned_packed(seed, Some(0)) |
| .add_system_accounts(config) | .add_system_accounts_v2(config) |

### Phase 4: TypeScript SDK replacements

| v1 Pattern | v2 Replacement |
|------------|----------------|
| deriveAddress( | deriveAddressV2( |
| deriveAddressSeed( | deriveAddressSeedV2( |
| defaultTestStateTreeAccounts().addressTree | batchAddressTree |
| .newWithSystemAccounts( | .newWithSystemAccountsV2( |
| get_address_tree_v1() | get_address_tree_v2() |
| get_random_state_tree_info_v1() | get_random_state_tree_info() |

### Phase 5: Build and test loop

**Required commands (no shortcuts):**

For Anchor programs: **anchor build && anchor test**

For Native programs: **cargo build-sbf && cargo test-sbf**

**NO shortcuts allowed:**

- Do NOT use **cargo build** (must use **cargo build-sbf**)
- Do NOT use **cargo test** (must use **cargo test-sbf**)
- Tests MUST run against real BPF bytecode

**On failure:** Spawn debugger agent with error context.

**Loop rules:**

1. Each debugger gets fresh context + previous debug reports
2. Each attempt tries something DIFFERENT
3. **NEVER GIVE UP** - keep spawning until fixed

Do NOT proceed until all tests pass.

## DeepWiki fallback

If no matching pattern in reference repos:

    mcp__deepwiki__ask_question("Lightprotocol/light-protocol", "How to migrate {pattern} from v1 to v2?")