Skip to main content

​
Light Token Recipes

Copy the prompt below or view the guide.

Add rent-free mint with token metadata

CursorOpen in Cursor
---
description: Add rent-free mint with token metadata
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Add rent-free mint with token metadata

Context:
- Guide: https://zkcompression.com/light-token/cookbook/create-mint
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Packages: @lightprotocol/compressed-token, @lightprotocol/stateless.js

SPL equivalent: createMint() → Light Token: createMintInterface()

### 1. Index project
- Grep `@solana/spl-token|Connection|Keypair|createMint` across src/
- Glob `**/*.ts` for project structure
- Identify: RPC setup, existing mint logic, entry point for mint creation
- Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

### 2. Read references
- WebFetch the guide above — follow the TypeScript Client tab
- 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 feature, migrate existing SPL code, add alongside existing)
- AskUserQuestion: does the project already have mint operations to extend, or is this greenfield?
- 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
- Verify existing connection/signer setup is compatible with the cookbook prerequisites
- 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`
- Follow the cookbook 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 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
Copy the prompt below or view the guide.

Create rent-free associated token account

CursorOpen in Cursor
---
description: Create rent-free associated token account
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Create rent-free associated token account

Context:
- Guide: https://zkcompression.com/light-token/cookbook/create-ata
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Packages: @lightprotocol/compressed-token, @lightprotocol/stateless.js

SPL equivalent: createAssociatedTokenAccount() → Light Token: createAtaInterface()

### 1. Index project
- Grep `@solana/spl-token|Connection|Keypair|createAssociatedTokenAccount|createAtaInterface` across src/
- Glob `**/*.ts` for project structure
- Identify: RPC setup, existing ATA logic, entry point for ATA creation
- Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

### 2. Read references
- WebFetch the guide above — follow the TypeScript Client tab
- 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 feature, migrate existing SPL code, add alongside existing)
- AskUserQuestion: does the project already have ATA operations to extend, or is this greenfield?
- 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
- Verify existing connection/signer setup is compatible with the cookbook prerequisites
- 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`
- Follow the cookbook 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 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
Copy the prompt below or view the guide.

Create Light Token account

CursorOpen in Cursor
---
description: Create Light Token account
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Create Light Token account

Context:
- Guide: https://zkcompression.com/light-token/cookbook/create-token-account
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Crates: light-token-client (actions), light-token (instructions), light-client (RPC)

SPL equivalent: spl_token::instruction::initialize_account → Light Token: CreateTokenAccount

### 1. Index project
- Grep `light_token::|light_token_client::|solana_sdk|Keypair|async|CreateTokenAccount|initialize_account` across src/
- Glob `**/*.rs` for project structure
- Identify: RPC setup, existing token ops, entry point for token account creation
- Check Cargo.toml for existing light-* 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 — follow the Rust Client tab
- 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 feature, migrate existing SPL code, add alongside existing)
- AskUserQuestion: does the project already have token account operations to extend, or is this greenfield?
- AskUserQuestion: action-level API (high-level, fewer lines) or instruction-level API (low-level, full control)?
- 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
- Verify existing Rpc/signer setup is compatible with the cookbook prerequisites (light_client::rpc::Rpc, solana_sdk::signature::Keypair)
- 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 `cargo add light-token-client light-token light-client --features light-client/v2`
- Follow the cookbook guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `cargo check`
- Bash `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
Copy the prompt below or view the guide.

Mint tokens to Light Token account

CursorOpen in Cursor
---
description: Mint tokens to Light Token account
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Mint tokens to Light Token account

Context:
- Guide: https://zkcompression.com/light-token/cookbook/mint-to
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Packages: @lightprotocol/compressed-token, @lightprotocol/stateless.js

SPL equivalent: mintTo() → Light Token: mintToInterface()

### 1. Index project
- Grep `@solana/spl-token|Connection|Keypair|mintTo|mintToInterface` across src/
- Glob `**/*.ts` for project structure
- Identify: RPC setup, existing mint logic, entry point for minting
- Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

### 2. Read references
- WebFetch the guide above — follow the TypeScript Client tab
- 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 feature, migrate existing SPL code, add alongside existing)
- AskUserQuestion: does the project already have mint operations to extend, or is this greenfield?
- 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
- Verify existing connection/signer setup is compatible with the cookbook prerequisites
- 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`
- Follow the cookbook 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 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
Copy the prompt below or view the guide.

Transfer tokens between Light Token and SPL accounts

CursorOpen in Cursor
---
description: Transfer tokens between Light Token and SPL accounts
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Transfer tokens between Light Token and SPL accounts

Context:
- Guide: https://zkcompression.com/light-token/cookbook/transfer-interface
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Packages: @lightprotocol/compressed-token, @lightprotocol/stateless.js

transferInterface() transfers tokens between token accounts (SPL, Token 2022, or Light Token) in a single call.
- Light Token → Light Token: transfers between Light Token accounts
- SPL → Light Token: locks SPL tokens in interface PDA, mints to Light Token account
- Light Token → SPL: burns Light Token balance, releases SPL tokens from interface PDA

### 1. Index project
- Grep `@solana/spl-token|Connection|Keypair|transfer|transferInterface` across src/
- Glob `**/*.ts` for project structure
- Identify: RPC setup, existing transfer logic, entry point for transfers
- Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

### 2. Read references
- WebFetch the guide above — follow the TypeScript Client tab
- 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 feature, migrate existing SPL code, add alongside existing)
- AskUserQuestion: does the project already have transfer operations to extend, or is this greenfield?
- 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
- Verify existing connection/signer setup is compatible with the cookbook prerequisites
- 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`
- Follow the cookbook 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 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
Copy the prompt below or view the guide.

Transfer tokens with decimal validation

CursorOpen in Cursor
---
description: Transfer tokens with decimal validation
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Transfer tokens with decimal validation

Context:
- Guide: https://zkcompression.com/light-token/cookbook/transfer-checked
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Crates: light-token-client (actions), light-token (instructions), light-client (RPC)

TransferChecked validates that the decimals parameter matches the mint's decimals. Use for Light→Light transfers when you need decimal verification. For transfers involving SPL or Token 2022 accounts, use TransferInterface instead.

SPL equivalent: spl_token::instruction::transfer_checked → Light Token: TransferChecked

### 1. Index project
- Grep `light_token::|light_token_client::|solana_sdk|Keypair|async|TransferChecked|transfer_checked` across src/
- Glob `**/*.rs` for project structure
- Identify: RPC setup, existing token ops, entry point for transfer checked
- Check Cargo.toml for existing light-* 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 — follow the Rust Client tab
- 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 feature, migrate existing SPL code, add alongside existing)
- AskUserQuestion: does the project already have transfer operations to extend, or is this greenfield?
- AskUserQuestion: action-level API (high-level, fewer lines) or instruction-level API (low-level, full control)?
- 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
- Verify existing Rpc/signer setup is compatible with the cookbook prerequisites (light_client::rpc::Rpc, solana_sdk::signature::Keypair)
- 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 `cargo add light-token-client light-token light-client --features light-client/v2`
- Follow the cookbook guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `cargo check`
- Bash `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
Copy the prompt below or view the guide.

Approve and revoke token delegates

CursorOpen in Cursor
---
description: Approve and revoke token delegates
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Approve and revoke token delegates

Context:
- Guide: https://zkcompression.com/light-token/cookbook/approve-revoke
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Packages: @lightprotocol/compressed-token, @lightprotocol/stateless.js

SPL equivalent: approve() / revoke() → Light Token: approve() / revoke()

### 1. Index project
- Grep `@solana/spl-token|Connection|Keypair|approve|revoke|delegate` across src/
- Glob `**/*.ts` for project structure
- Identify: RPC setup, existing delegation logic, entry point for delegation
- Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

### 2. Read references
- WebFetch the guide above — follow the TypeScript Client tab
- 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 feature, migrate existing SPL code, add alongside existing)
- AskUserQuestion: does the project already have delegate operations to extend, or is this greenfield?
- 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
- Verify existing connection/signer setup is compatible with the cookbook prerequisites
- 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`
- Follow the cookbook 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 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
Copy the prompt below or view the guide.

Freeze and thaw Light Token accounts

CursorOpen in Cursor
---
description: Freeze and thaw Light Token accounts
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Freeze and thaw Light Token accounts

Context:
- Guide: https://zkcompression.com/light-token/cookbook/freeze-thaw
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Crates: light-token-client (actions), light-token (instructions), light-client (RPC)

- Freeze: prevents all transfers or token burns from a specific Light Token account
- Thaw: re-enables transfers on a frozen Light Token account
- Only the freeze authority (set at mint creation) can freeze or thaw accounts

SPL equivalent: spl_token::instruction::freeze_account / thaw_account → Light Token: Freeze / Thaw

### 1. Index project
- Grep `light_token::|light_token_client::|solana_sdk|Keypair|async|Freeze|Thaw|freeze_account|thaw_account` across src/
- Glob `**/*.rs` for project structure
- Identify: RPC setup, existing token ops, entry point for freeze/thaw
- Check Cargo.toml for existing light-* 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 — follow the Rust Client tab
- 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 feature, migrate existing SPL code, add alongside existing)
- AskUserQuestion: does the project already have freeze/thaw operations to extend, or is this greenfield?
- AskUserQuestion: action-level API (high-level, fewer lines) or instruction-level API (low-level, full control)?
- 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
- Verify existing Rpc/signer setup is compatible with the cookbook prerequisites (light_client::rpc::Rpc, solana_sdk::signature::Keypair)
- 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 `cargo add light-token-client light-token light-client --features light-client/v2`
- Follow the cookbook guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `cargo check`
- Bash `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
Copy the prompt below or view the guide.

Wrap and unwrap SPL tokens to Light Token

CursorOpen in Cursor
---
description: Wrap and unwrap SPL tokens to Light Token
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Wrap and unwrap SPL tokens to Light Token

Context:
- Guide: https://zkcompression.com/light-token/cookbook/wrap-unwrap
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Packages: @lightprotocol/compressed-token, @lightprotocol/stateless.js

- Wrap: Move tokens from SPL or Token 2022 account → Light Token associated token account (hot balance)
- Unwrap: Move tokens from Light Token associated token account (hot balance) → SPL or Token 2022 account

### 1. Index project
- Grep `@solana/spl-token|Connection|Keypair|wrap|unwrap|WrapTokens|UnwrapTokens` across src/
- Glob `**/*.ts` for project structure
- Identify: RPC setup, existing wrap/unwrap logic, entry point for wrap/unwrap
- Task subagent (Grep/Read/WebFetch) if project has multiple packages to scan in parallel

### 2. Read references
- WebFetch the guide above — follow the TypeScript Client tab
- 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 feature, migrate existing SPL code, add alongside existing)
- AskUserQuestion: does the project already have wrap/unwrap operations to extend, or is this greenfield?
- 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
- Verify existing connection/signer setup is compatible with the cookbook prerequisites
- 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`
- Follow the cookbook 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 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
Copy the prompt below or view the guide.

Close Light Token account

CursorOpen in Cursor
---
description: Close Light Token account
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Close Light Token account

Context:
- Guide: https://zkcompression.com/light-token/cookbook/close-token-account
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Crates: light-token-client (actions), light-token (instructions), light-client (RPC)

SPL equivalent: spl_token::instruction::close_account → Light Token: CloseAccount

### 1. Index project
- Grep `light_token::|light_token_client::|solana_sdk|Keypair|async|CloseAccount|close_account` across src/
- Glob `**/*.rs` for project structure
- Identify: RPC setup, existing token ops, entry point for close account
- Check Cargo.toml for existing light-* 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 — follow the Rust Client tab
- 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 feature, migrate existing SPL code, add alongside existing)
- AskUserQuestion: does the project already have close operations to extend, or is this greenfield?
- AskUserQuestion: action-level API (high-level, fewer lines) or instruction-level API (low-level, full control)?
- 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
- Verify existing Rpc/signer setup is compatible with the cookbook prerequisites (light_client::rpc::Rpc, solana_sdk::signature::Keypair)
- 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 `cargo add light-token-client light-token light-client --features light-client/v2`
- Follow the cookbook guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `cargo check`
- Bash `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
Copy the prompt below or view the guide.

Burn Light Tokens

CursorOpen in Cursor
---
description: Burn Light Tokens
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Burn Light Tokens

Context:
- Guide: https://zkcompression.com/light-token/cookbook/burn
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Crates: light-token-client (actions), light-token (instructions), light-client (RPC)

SPL equivalent: spl_token::instruction::burn → Light Token: Burn

### 1. Index project
- Grep `light_token::|light_token_client::|solana_sdk|Keypair|async|Burn|burn` across src/
- Glob `**/*.rs` for project structure
- Identify: RPC setup, existing token ops, entry point for burn
- Check Cargo.toml for existing light-* 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 — follow the Rust Client tab
- 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 feature, migrate existing SPL code, add alongside existing)
- AskUserQuestion: does the project already have burn operations to extend, or is this greenfield?
- AskUserQuestion: action-level API (high-level, fewer lines) or instruction-level API (low-level, full control)?
- 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
- Verify existing Rpc/signer setup is compatible with the cookbook prerequisites (light_client::rpc::Rpc, solana_sdk::signature::Keypair)
- 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 `cargo add light-token-client light-token light-client --features light-client/v2`
- Follow the cookbook guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `cargo check`
- Bash `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

​
DeFi

Copy the prompt below or view the guide.

Add rent-free accounts to an Anchor DeFi program

CursorOpen in Cursor
---
description: Add rent-free accounts to an Anchor DeFi program
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Add rent-free accounts to an Anchor DeFi program

Context:
- Guide: https://zkcompression.com/light-token/defi/programs
- Skills and resources index: https://zkcompression.com/skill.md
- Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/light-sdk
- Crates: light-sdk (features: anchor, v2, cpi-context), light-sdk-macros, light-token (features: anchor), light-anchor-spl
- AMM reference: https://github.com/Lightprotocol/cp-swap-reference

Key macros/APIs: #[light_program], LightAccount, LightAccounts, #[light_account(init)], CompressionInfo

### 1. Index project
- Grep `#\[program\]|anchor_lang|Account<|Accounts|InitSpace|seeds|init|payer` across src/
- Glob `**/*.rs` and `**/Cargo.toml` for project structure
- Identify: existing program module, account structs, PDA seeds, token accounts, init instructions
- Read Cargo.toml — note existing dependencies and framework version
- Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

### 2. Read references
- WebFetch the guide above
- 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, migrate existing program to rent-free, add rent-free accounts to specific instructions)
- AskUserQuestion: which account types need to be rent-free? (PDAs, token accounts, ATAs, mints)
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan
- Follow the guide's step order: Dependencies → State Struct → Program Module → Accounts Struct → Instructions
- Identify which existing structs need changes (CompressionInfo field, LightAccount derive, etc.)
- 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 `cargo add light-sdk@0.19 --features anchor,v2,cpi-context` and `cargo add light-sdk-macros@0.19` and `cargo add light-token@0.4 --features anchor` and `cargo add light-anchor-spl@0.31`
- Follow the guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `anchor build`
- Bash `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
Copy the prompt below or view the guide.

Add rent-free accounts to a Pinocchio DeFi program

CursorOpen in Cursor
---
description: Add rent-free accounts to a Pinocchio DeFi program
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Add rent-free accounts to a Pinocchio DeFi program

Context:
- Guide: https://zkcompression.com/light-token/defi/programs-pinocchio
- Skills and resources index: https://zkcompression.com/skill.md
- Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/light-sdk
- Crates: light-account-pinocchio (features: token, std), light-token-pinocchio, pinocchio
- Swap reference: https://github.com/Lightprotocol/examples-light-token/tree/simplify-trait/pinocchio/swap

Key macros/APIs: LightPinocchioAccount, LightProgramPinocchio, CreateTokenAccountCpi, derive_light_cpi_signer!

### 1. Index project
- Grep `pinocchio|entrypoint!|ProgramError|AccountInfo|process_instruction` across src/
- Glob `**/*.rs` and `**/Cargo.toml` for project structure
- Identify: existing program module, account structs, PDA seeds, token accounts, init instructions
- Read Cargo.toml — note existing dependencies and framework version
- Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

### 2. Read references
- WebFetch the guide above
- 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, migrate existing program to rent-free, add rent-free accounts to specific instructions)
- AskUserQuestion: which account types need to be rent-free? (PDAs, token accounts, ATAs, mints)
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan
- Follow the guide's step order: Dependencies → State Struct → Program Enum → Entrypoint → Init Handler
- Identify which existing structs need changes (CompressionInfo field, LightPinocchioAccount derive, etc.)
- 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 `cargo add light-account-pinocchio@0.20 --features token,std` and `cargo add light-token-pinocchio@0.20` and `cargo add pinocchio@0.9`
- 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`
- Bash `cargo test-sbf` 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
Copy the prompt below or view the guide.

Integrate rent-free AMM markets into a router or aggregator

CursorOpen in Cursor
---
description: Integrate rent-free AMM markets into a router or aggregator
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Integrate rent-free AMM markets into a router or aggregator

Context:
- Guide: https://zkcompression.com/light-token/defi/routers
- Skills and resources index: https://zkcompression.com/skill.md
- Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/light-sdk
- Crate: light-client (features: v2) — provides AccountInterface, LightProgramInterface, create_load_instructions
- AMM reference: https://github.com/Lightprotocol/cp-swap-reference
- Streaming guides: https://zkcompression.com/light-token/toolkits/for-streaming-tokens

Key APIs: create_load_instructions(), LightProgramInterface trait, get_account_interface(), get_multiple_account_interfaces(), is_cold()

### 1. Index project
- Grep `LightProgramInterface|create_load_instructions|AccountInterface|is_cold|get_account_interface|swap|amm|router|aggregator` across src/
- Glob `**/*.rs` and `**/Cargo.toml` for project structure
- Identify: existing routing/quoting logic, account caching, swap instruction building, streaming setup
- Read Cargo.toml — note existing dependencies and light-client version
- Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

### 2. Read references
- WebFetch the guide above
- 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? (add cold market support to existing router, build new router with rent-free market support, integrate a specific AMM SDK)
- AskUserQuestion: does the project already stream account updates, or does it fetch at swap time?
- AskUserQuestion: does the project use Jito bundles for multi-transaction swaps?
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan
- Follow the guide's progression: Cold Account Cache → Detecting Cold Accounts → Building Swap Transactions with Load Instructions
- If streaming: add account + transaction subscriptions for the Light Token Program
- If fetch-at-swap-time: add get_multiple_account_interfaces + is_cold() check before building swap tx
- 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 `cargo add light-client@0.19 --features v2`
- Add AMM SDK dependency per the approved plan
- Follow the guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `cargo check`
- Bash `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

​
Data Streaming

Copy the prompt below or view the guide.

Stream light-mint accounts and metadata via Laserstream gRPC

CursorOpen in Cursor
---
description: Stream light-mint accounts and metadata via Laserstream gRPC
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Stream light-mint accounts and metadata via Laserstream gRPC

Context:
- Guide: https://zkcompression.com/light-token/toolkits/for-streaming-mints
- Skills and resources index: https://zkcompression.com/skill.md
- Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/data-streaming
- Crates: helius-laserstream, light-token-interface, borsh, futures
- Token accounts streaming: https://zkcompression.com/light-token/toolkits/for-streaming-tokens

Key APIs: LaserstreamConfig, subscribe(), Mint::deserialize(), ExtensionStruct::TokenMetadata

### 1. Index project
- Grep `helius_laserstream|laserstream|subscribe|StreamExt|light_token_interface|Mint|cTokenmWW8bLPjZEBAUgYy3zKxQZW6VKi7bqNFEVv3m` across src/
- Glob `**/*.rs` and `**/Cargo.toml` for project structure
- Identify: existing gRPC streaming setup, account caching, deserialization logic
- Read Cargo.toml — note existing dependencies
- Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

### 2. Read references
- WebFetch the guide above — follow the Steps (Connect, Subscribe, Deserialize, Detect cold, Extract metadata)
- 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 streaming pipeline for mints, add mint streaming to existing token streaming, specific use case like metadata indexing)
- AskUserQuestion: mainnet or devnet?
- AskUserQuestion: do you need cold/hot transition detection, or just live mint state?
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan
- Follow the guide's step order: Connect → Subscribe (account + transaction subs) → Deserialize Mint → Detect Cold → Extract Metadata
- 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 `cargo add helius-laserstream@0.1 light-token-interface@0.3 borsh@0.10 futures@0.3 bs58@0.5 tokio --features full`
- Follow the guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `cargo check`
- Bash `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
Copy the prompt below or view the guide.

Stream light-token accounts via Laserstream gRPC

CursorOpen in Cursor
---
description: Stream light-token accounts via Laserstream gRPC
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Stream light-token accounts via Laserstream gRPC

Context:
- Guide: https://zkcompression.com/light-token/toolkits/for-streaming-tokens
- Skills and resources index: https://zkcompression.com/skill.md
- Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/data-streaming
- Crates: helius-laserstream, light-token-interface, spl-pod, spl-token-2022-interface, borsh, futures
- Mint accounts streaming: https://zkcompression.com/light-token/toolkits/for-streaming-mints
- Point queries: light-client (LightClient, get_account_interface)

Key APIs: LaserstreamConfig, subscribe(), PodAccount (pod_from_bytes), LightClient::get_account_interface()

### 1. Index project
- Grep `helius_laserstream|laserstream|subscribe|PodAccount|pod_from_bytes|spl_token_2022_interface|cTokenmWW8bLPjZEBAUgYy3zKxQZW6VKi7bqNFEVv3m` across src/
- Glob `**/*.rs` and `**/Cargo.toml` for project structure
- Identify: existing gRPC streaming setup, token account caching, SPL parser usage
- Read Cargo.toml — note existing dependencies
- Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

### 2. Read references
- WebFetch the guide above — follow the Steps (Connect, Subscribe) and the transition detection sections
- 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 streaming pipeline for token accounts, add to existing pipeline, integrate cold/hot detection for routing)
- AskUserQuestion: mainnet or devnet?
- AskUserQuestion: do you need point queries (get_account_interface) in addition to streaming?
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan
- Follow the guide's structure: Connect → Subscribe (account + transaction subs) → Detect Transitions (hot-to-cold, cold-to-hot) → Point Queries (optional)
- Token accounts use the same 165-byte SPL layout — existing SPL parsers work directly
- 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 `cargo add helius-laserstream@0.1 light-token-interface@0.3 spl-pod spl-token-2022-interface borsh@0.10 futures@0.3 bs58@0.5 tokio --features full`
- For point queries, also: Bash `cargo add light-client@0.19 --features v2`
- Follow the guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `cargo check`
- Bash `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

​
Stablecoin Payments

Copy the prompt below or view the guide.

Integrate light-token APIs for stablecoin payments

CursorOpen in Cursor
---
description: Integrate light-token APIs for stablecoin payments
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Integrate light-token APIs for stablecoin payments

Context:
- Guide: https://zkcompression.com/light-token/toolkits/for-payments
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/payments-and-wallets
- Packages: @lightprotocol/compressed-token, @lightprotocol/stateless.js
- Full examples: https://github.com/Lightprotocol/examples-light-token/tree/main/toolkits/payments-and-wallets

SPL → Light Token API mapping:
| Operation    | SPL                               | Light Token                              |
| Receive      | getOrCreateAssociatedTokenAccount() | createLoadAtaInstructions() / loadAta()  |
| Transfer     | createTransferInstruction()        | createTransferInterfaceInstructions()    |
| Get Balance  | getAccount()                      | getAtaInterface()                        |
| Tx History   | getSignaturesForAddress()         | getSignaturesForOwnerInterface()         |
| Wrap SPL     | N/A                               | createWrapInstruction() / wrap()         |
| Unwrap       | N/A                               | createUnwrapInstructions() / unwrap()    |

### 1. Index project
- Grep `@solana/spl-token|@lightprotocol|createTransferInstruction|getAccount|Connection|Keypair|stablecoin|payment` across src/
- Glob `**/*.ts` and `**/*.tsx` for project structure
- Identify: RPC setup, existing token operations, payment flow, wallet signing pattern
- 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 Instruction and Action tabs for each operation
- 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 payment integration, migrate existing SPL payment flow, add alongside existing SPL)
- AskUserQuestion: which operations? (receive, send, balance, history, wrap, unwrap — or all)
- AskUserQuestion: instruction-level API (build your own transactions) or action-level API (high-level, fewer lines)?
- 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
- Verify existing connection/signer setup is compatible (createRpc with ZK Compression endpoint)
- Key pattern: import from `@lightprotocol/compressed-token/unified` for all interface APIs
- 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`
- Set up RPC: `createRpc(RPC_ENDPOINT)` with a ZK Compression endpoint (Helius, Triton)
- Import from `@lightprotocol/compressed-token/unified` for the interface APIs
- 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 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
Copy the prompt below or view the guide.

Create rent-free nullifier PDAs to prevent duplicate actions

CursorOpen in Cursor
---
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/pda/compressed-pdas/guides/how-to-create-nullifier-pdas
- 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.19`
- For TypeScript: Bash `npm install @lightprotocol/nullifier-program @lightprotocol/stateless.js@beta`
- 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

​
Wallets

Copy the prompt below or view the guide.

Add light-token support to a wallet application

CursorOpen in Cursor
---
description: Add light-token support to a wallet application
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Add light-token support to a wallet application

Context:
- Guide: https://zkcompression.com/light-token/toolkits/for-wallets
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/payments-and-wallets
- Packages: @lightprotocol/compressed-token, @lightprotocol/stateless.js
- Full examples: https://github.com/Lightprotocol/examples-light-token/tree/main/toolkits/payments-and-wallets

SPL → Light Token API mapping:
| Operation    | SPL                               | Light Token                              |
| Receive      | getOrCreateAssociatedTokenAccount() | createLoadAtaInstructions() / loadAta()  |
| Transfer     | createTransferInstruction()        | createTransferInterfaceInstructions()    |
| Get Balance  | getAccount()                      | getAtaInterface()                        |
| Tx History   | getSignaturesForAddress()         | getSignaturesForOwnerInterface()         |
| Wrap SPL     | N/A                               | createWrapInstruction() / wrap()         |
| Unwrap       | N/A                               | createUnwrapInstructions() / unwrap()    |

### 1. Index project
- Grep `@solana/spl-token|@lightprotocol|createTransferInstruction|getAccount|wallet|signTransaction|signAllTransactions|Connection` across src/
- Glob `**/*.ts` and `**/*.tsx` for project structure
- Identify: RPC setup, existing token display/balance logic, wallet adapter, transaction signing pattern
- 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 Instruction and Action tabs for each operation
- 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 wallet integration, migrate existing SPL wallet to light-token, add light-token alongside existing SPL)
- AskUserQuestion: which operations? (receive, send, balance, history, wrap, unwrap — or all)
- AskUserQuestion: instruction-level API (build your own transactions) or action-level API (high-level, fewer lines)?
- 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
- Verify existing connection/signer setup is compatible (createRpc with ZK Compression endpoint)
- Key pattern: import from `@lightprotocol/compressed-token/unified` for all interface APIs
- APIs return TransactionInstruction[][] — handle multi-tx case with signAllTransactions
- 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`
- Set up RPC: `createRpc(RPC_ENDPOINT)` with a ZK Compression endpoint (Helius, Triton)
- Import from `@lightprotocol/compressed-token/unified` for the interface APIs
- 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 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
Copy the prompt below or view the guide.

Integrate light-token with Solana Wallet Adapter

CursorOpen in Cursor
---
description: Integrate light-token with Solana Wallet Adapter
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Integrate light-token with Solana Wallet Adapter

Context:
- Guide: https://zkcompression.com/light-token/toolkits/for-wallet-adapter
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/payments-and-wallets
- Packages: @lightprotocol/compressed-token, @lightprotocol/stateless.js
- React example: https://github.com/Lightprotocol/examples-light-token/tree/main/toolkits/sign-with-wallet-adapter/react

SPL → Light Token API mapping:
| Operation        | SPL                          | Light Token                              |
| Transfer         | createTransferInstruction()  | createTransferInterfaceInstructions()    |
| Wrap SPL→Light   | N/A                          | createWrapInstruction()                  |
| Unwrap Light→SPL | N/A                          | createUnwrapInstructions()               |
| Get balance      | getAccount()                 | getAtaInterface()                        |
| Tx history       | getSignaturesForAddress()    | getSignaturesForOwnerInterface()         |

### 1. Index project
- Grep `wallet-adapter|useWallet|WalletProvider|useConnection|createTransferInstruction|@solana/spl-token|Connection` across src/
- Glob `**/*.ts` and `**/*.tsx` for project structure
- Identify: wallet adapter packages, existing wallet setup, RPC config, token operations
- 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 the React code examples
- 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 wallet adapter integration, migrate existing wallet-adapter+SPL code, add light-token alongside existing SPL)
- AskUserQuestion: which operations? (transfer, wrap, unwrap, balances, tx history — or all)
- 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
- Verify existing wallet adapter setup is compatible (signTransaction pattern from useWallet)
- Key integration pattern: build unsigned tx with light-token SDK → sign with `signTransaction` from `useWallet()` → send to RPC
- 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`
- Set up RPC: `createRpc(RPC_ENDPOINT)` with a ZK Compression endpoint (Helius, Triton)
- Import from `@lightprotocol/compressed-token/unified` for the interface APIs
- Use `useWallet()` to get `publicKey` and `signTransaction`
- 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 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
Copy the prompt below or view the guide.

Integrate light-token with Privy embedded wallets

CursorOpen in Cursor
---
description: Integrate light-token with Privy embedded wallets
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Integrate light-token with Privy embedded wallets

Context:
- Guide: https://zkcompression.com/light-token/toolkits/for-privy
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Dedicated skill: https://github.com/Lightprotocol/skills/tree/main/skills/payments-and-wallets
- Packages: @lightprotocol/compressed-token, @lightprotocol/stateless.js
- Node.js example: https://github.com/Lightprotocol/examples-light-token/tree/main/privy/nodejs
- React example: https://github.com/Lightprotocol/examples-light-token/tree/main/privy/react

SPL → Light Token API mapping:
| Operation        | SPL                          | Light Token                              |
| Transfer         | createTransferInstruction()  | createTransferInterfaceInstructions()    |
| Receive          | getOrCreateAssociatedTokenAccount() | createLoadAtaInstructions()       |
| Wrap SPL→Light   | N/A                          | createWrapInstruction()                  |
| Unwrap Light→SPL | N/A                          | createUnwrapInstructions()               |
| Get balance      | getAccount()                 | getAtaInterface()                        |
| Tx history       | getSignaturesForAddress()    | getSignaturesForOwnerInterface()         |

### 1. Index project
- Grep `privy|@privy-io|usePrivy|PrivyProvider|createTransferInstruction|@solana/spl-token|Connection` across src/
- Glob `**/*.ts` and `**/*.tsx` for project structure
- Identify: Privy SDK version, existing wallet setup, RPC config, token operations
- 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 both Node.js and React code examples
- 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: Node.js or React?
- AskUserQuestion: what is the goal? (new Privy integration, migrate existing Privy+SPL code, add light-token alongside existing SPL)
- AskUserQuestion: which operations? (transfer, wrap, unwrap, balances, tx history — or all)
- 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
- Verify existing Privy wallet setup is compatible (signTransaction or sendTransaction pattern)
- Key integration pattern: build unsigned tx with light-token SDK → sign with Privy → send to RPC
- 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`
- Set up RPC: `createRpc(RPC_ENDPOINT)` with a ZK Compression endpoint (Helius, Triton)
- Import from `@lightprotocol/compressed-token/unified` for the interface APIs
- 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 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

​
Light-PDA

Copy the prompt below or view the guide.

Add rent-free PDAs to an Anchor program

CursorOpen in Cursor
---
description: Add rent-free PDAs to an Anchor program
allowed-tools: Bash, Read, Write, Edit, Glob, Grep, WebFetch, AskUserQuestion, Task, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskOutput, mcp__deepwiki, mcp__zkcompression
---

## Add rent-free PDAs to an Anchor program

Context:
- Guide: https://zkcompression.com/pda/light-pda/overview
- Skills and resources index: https://zkcompression.com/skill.md
- SPL to Light reference: https://zkcompression.com/api-reference/solana-to-light-comparison
- Crates: light-account (features: anchor), light-sdk (features: anchor, v2, cpi-context)
- Counter example: https://github.com/Lightprotocol/examples-light-token/tree/main/programs/anchor/basic-macros/counter

Key macros/APIs: #[light_program], LightAccount, LightAccounts, #[light_account(init)], CompressionInfo, CreateAccountsProof

### 1. Index project
- Grep `#\[program\]|anchor_lang|Account<|Accounts|InitSpace|seeds|init|payer` across src/
- Glob `**/*.rs` and `**/Cargo.toml` for project structure
- Identify: existing program module, account structs, PDA seeds, token accounts, init instructions
- Read Cargo.toml — note existing dependencies and framework version
- Task subagent (Grep/Read/WebFetch) if project has multiple crates to scan in parallel

### 2. Read references
- WebFetch the guide above
- 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, migrate existing program to rent-free, add rent-free accounts to specific instructions)
- Summarize findings and wait for user confirmation before implementing

### 4. Create plan
- Based on steps 1–3, draft an implementation plan
- Follow the guide's step order: Dependencies → State Struct → Program Module → Accounts Struct
- Identify which existing structs need changes (CompressionInfo field, LightAccount derive, etc.)
- 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 `cargo add light-account@0.20 --features anchor` and `cargo add light-sdk@0.20 --features anchor,v2,cpi-context`
- Follow the guide and the approved plan
- Write/Edit to create or modify files
- TaskUpdate to mark each step done

### 6. Verify
- Bash `anchor build`
- Bash `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

​
Compressed PDA

Copy the prompt below or view the guide.

Write client code to interact with compressed PDA programs

CursorOpen in Cursor
---
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/pda/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.16 light-sdk@0.16`
- 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
Copy the prompt below or view the guide.

Build a program that creates compressed accounts with addresses

CursorOpen in Cursor
---
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/pda/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.16` (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
Copy the prompt below or view the guide.

Build a program that updates compressed accounts

CursorOpen in Cursor
---
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/pda/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.16` (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
Copy the prompt below or view the guide.

Build a program that closes compressed accounts

CursorOpen in Cursor
---
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/pda/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.16` (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
Copy the prompt below or view the guide.

Build a program that reinitializes closed compressed accounts

CursorOpen in Cursor
---
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/pda/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.16` (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
Copy the prompt below or view the guide.

Build a program that permanently burns compressed accounts

CursorOpen in Cursor
---
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/pda/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.16` (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
Copy the prompt below or view the guide.

Migrate Light Protocol program from v1 to v2 Merkle trees

CursorOpen in Cursor
---
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?")

​
Token Distribution

Copy the prompt below or view the guide.

Distribute compressed tokens via airdrop

CursorOpen in Cursor
---
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/airdrop
- 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