Solana RedPill Verifier Skill
What this Skill is for
Use this Skill when the user asks for:
- Solana RedPill verifier implementation in
web/solana-redpill-verifier
- TEE proof anchoring on Solana with
StoreProofV2
TeeProof, TeeProofV2, ProofCounterDay, or verifier PDA layout
- Native Solana secp256k1 proof binding for TEE signatures
- CLAWD TEE Gateway proxying OpenAI-compatible requests and adding
_clawd proofs
- Intel TDX, Phala verifier, NVIDIA NRAS, or OP-TEE signer integration
- Solana Attestation Service credentials issued from verified TEE inference counts
- TypeScript client usage, CLI commands, proof lookup, or day counters
- Deployment, local testing, Docker, key handling, or production hardening
Source of truth
Read source files from web/solana-redpill-verifier before making code changes.
Do not read or copy secrets from:
web/solana-redpill-verifier/.keys
- real keypair paths referenced by
SOLANA_KEYPAIR_PATH
- generated build artifacts under
target/ unless a build error requires inspection
Prefer V2 unless the user explicitly asks for legacy V1. svm.md is useful historical handoff context, but the README and current source files include newer V2, gateway, SAS, and OP-TEE behavior.
Key concepts
TeeProofV2 is the default on-chain account. Its PDA is:
["tee_proof_v2", signed_payload_hash]
StoreProofV2 is instruction discriminator 2. It stores forensic hashes, a TEE signing address, verification level, status, expiry, nonce, policy metadata, and submitter slot/time.
signed_payload_hash binds the proof to an inference. For CLAWD-native gateway proofs it is:
SHA256("CLAWD_REDPILL_V2:" || request_hash || response_hash || model_hash || nonce)
Native secp256k1 verification is required when verification_level >= 1. The secp instruction must sign the exact 32-byte signed_payload_hash, and secp_ix_index must match its transaction index.
Gateway anchoring is optional at runtime. If SOLANA_KEYPAIR_PATH is absent, the gateway can still proxy and sign proofs, but Solana anchoring is skipped and only the expected proof PDA is returned.
SAS credentials are Token-2022 non-transferable NFT attestations issued when a wallet reaches SAS_PROOF_THRESHOLD verified inferences through the gateway.
Default stack decisions
- Use
StoreProofV2, TeeProofV2, and ProofCounterDay for new work.
- Keep Rust program constants, TypeScript client builders/decoders, and gateway Solana builders in sync.
- Use
verification_level = 0 for stored-only development and verification_level = 1 only when the secp256k1 instruction and signature are present.
- Treat V1
InitCounter and StoreProof as backwards-compatible legacy paths.
- Keep TEE signing keys inside the TEE boundary or an approved sealed-storage path. Never put real keys into skill files, examples, commits, or logs.
Operating procedure
- Classify the task:
- Architecture or flow: read architecture.md
- On-chain program or PDA layout: read onchain-program.md
- TypeScript client or CLI: read typescript-client.md
- Gateway proxy, signing, anchoring, or env vars: read gateway.md
- SAS credentials: read sas-credentials.md
- OP-TEE signer path: read optee.md
- Build, deploy, or operations: read deployment.md
- Failures or transaction errors: read debugging.md
- Inspect the current source files before editing. The skill docs summarize the repo, but code wins.
- Preserve the V2 security invariants:
- 32-byte
signed_payload_hash must be the PDA seed.
- secp message data must equal
signed_payload_hash.
- recovered Ethereum address must equal
signing_address.
day_tag must be exactly 8 ASCII bytes, YYYYMMDD.
expires_at != 0 must not be in the past at store time.
- When changing account layout or instruction data, update every mirror:
program/src/constants.rs
program/src/state/tee_proof.rs
program/src/processor/store_proof_v2.rs
clients/typescript/src/accounts.ts
clients/typescript/src/instructions.ts
clients/typescript/src/types.ts
clawd-tee-gateway/src/solana.rs
idl/solana_redpill_verifier.json if the public interface changed
- Verify with the narrowest useful build or test command and report any unrun checks.
Deliverables expectations
When implementing changes, include:
- Files changed and the exact behavioral change
- Build/test commands run
- Deployment or key-management assumptions
- Risk notes for signer, verifier level, secp index, PDA seeds, or account layout changes
Progressive disclosure
- System architecture and proof flow: architecture.md
- Pinocchio on-chain program and PDA layout: onchain-program.md
- TypeScript client and CLI: typescript-client.md
- CLAWD TEE Gateway: gateway.md
- Solana Attestation Service credentials: sas-credentials.md
- OP-TEE signer provider: optee.md
- Build and deployment: deployment.md
- Debugging guide: debugging.md
- Source map and external endpoints: resources.md
1---2name: solana-redpill-verifier3description: Solana RedPill TEE verifier development and operations for the `web/solana-redpill-verifier` stack. Use for Pinocchio SVM proof storage, TeeProofV2 PDA layout, StoreProofV2 transactions, RedPill/TDX and NVIDIA NRAS attestation anchoring, CLAWD TEE Gateway setup, OpenAI-compatible attested inference proxying, Solana Attestation Service Token-2022 credentials, TypeScript client integration, OP-TEE signer integration, deployment, and debugging proof anchoring on Solana.4---5
6# Solana RedPill Verifier Skill
7
8## What this Skill is for
9Use this Skill when the user asks for:
10- Solana RedPill verifier implementation in `web/solana-redpill-verifier`
11- TEE proof anchoring on Solana with `StoreProofV2`
12- `TeeProof`, `TeeProofV2`, `ProofCounterDay`, or verifier PDA layout
13- Native Solana secp256k1 proof binding for TEE signatures
14- CLAWD TEE Gateway proxying OpenAI-compatible requests and adding `_clawd` proofs
15- Intel TDX, Phala verifier, NVIDIA NRAS, or OP-TEE signer integration
16- Solana Attestation Service credentials issued from verified TEE inference counts
17- TypeScript client usage, CLI commands, proof lookup, or day counters
18- Deployment, local testing, Docker, key handling, or production hardening
19
20## Source of truth
21Read source files from `web/solana-redpill-verifier` before making code changes.
22
23Do not read or copy secrets from:
24- `web/solana-redpill-verifier/.keys`
25- real keypair paths referenced by `SOLANA_KEYPAIR_PATH`
26- generated build artifacts under `target/` unless a build error requires inspection
27
28Prefer V2 unless the user explicitly asks for legacy V1. `svm.md` is useful historical handoff context, but the README and current source files include newer V2, gateway, SAS, and OP-TEE behavior.
29
30## Key concepts
31**TeeProofV2** is the default on-chain account. Its PDA is:
32
33```text
34["tee_proof_v2", signed_payload_hash]
35```
36
37**StoreProofV2** is instruction discriminator `2`. It stores forensic hashes, a TEE signing address, verification level, status, expiry, nonce, policy metadata, and submitter slot/time.
38
39**signed_payload_hash** binds the proof to an inference. For CLAWD-native gateway proofs it is:
40
41```text
42SHA256("CLAWD_REDPILL_V2:" || request_hash || response_hash || model_hash || nonce)
43```
44
45**Native secp256k1 verification** is required when `verification_level >= 1`. The secp instruction must sign the exact 32-byte `signed_payload_hash`, and `secp_ix_index` must match its transaction index.
46
47**Gateway anchoring** is optional at runtime. If `SOLANA_KEYPAIR_PATH` is absent, the gateway can still proxy and sign proofs, but Solana anchoring is skipped and only the expected proof PDA is returned.
48
49**SAS credentials** are Token-2022 non-transferable NFT attestations issued when a wallet reaches `SAS_PROOF_THRESHOLD` verified inferences through the gateway.
50
51## Default stack decisions
521. Use `StoreProofV2`, `TeeProofV2`, and `ProofCounterDay` for new work.
532. Keep Rust program constants, TypeScript client builders/decoders, and gateway Solana builders in sync.
543. Use `verification_level = 0` for stored-only development and `verification_level = 1` only when the secp256k1 instruction and signature are present.
554. Treat V1 `InitCounter` and `StoreProof` as backwards-compatible legacy paths.
565. Keep TEE signing keys inside the TEE boundary or an approved sealed-storage path. Never put real keys into skill files, examples, commits, or logs.
57
58## Operating procedure
591. Classify the task:
60 - Architecture or flow: read [architecture.md](architecture.md)
61 - On-chain program or PDA layout: read [onchain-program.md](onchain-program.md)
62 - TypeScript client or CLI: read [typescript-client.md](typescript-client.md)
63 - Gateway proxy, signing, anchoring, or env vars: read [gateway.md](gateway.md)
64 - SAS credentials: read [sas-credentials.md](sas-credentials.md)
65 - OP-TEE signer path: read [optee.md](optee.md)
66 - Build, deploy, or operations: read [deployment.md](deployment.md)
67 - Failures or transaction errors: read [debugging.md](debugging.md)
682. Inspect the current source files before editing. The skill docs summarize the repo, but code wins.
693. Preserve the V2 security invariants:
70 - 32-byte `signed_payload_hash` must be the PDA seed.
71 - secp message data must equal `signed_payload_hash`.
72 - recovered Ethereum address must equal `signing_address`.
73 - `day_tag` must be exactly 8 ASCII bytes, `YYYYMMDD`.
74 - `expires_at != 0` must not be in the past at store time.
754. When changing account layout or instruction data, update every mirror:
76 - `program/src/constants.rs`
77 - `program/src/state/tee_proof.rs`
78 - `program/src/processor/store_proof_v2.rs`
79 - `clients/typescript/src/accounts.ts`
80 - `clients/typescript/src/instructions.ts`
81 - `clients/typescript/src/types.ts`
82 - `clawd-tee-gateway/src/solana.rs`
83 - `idl/solana_redpill_verifier.json` if the public interface changed
845. Verify with the narrowest useful build or test command and report any unrun checks.
85
86## Deliverables expectations
87When implementing changes, include:
88- Files changed and the exact behavioral change
89- Build/test commands run
90- Deployment or key-management assumptions
91- Risk notes for signer, verifier level, secp index, PDA seeds, or account layout changes
92
93## Progressive disclosure
94- System architecture and proof flow: [architecture.md](architecture.md)
95- Pinocchio on-chain program and PDA layout: [onchain-program.md](onchain-program.md)
96- TypeScript client and CLI: [typescript-client.md](typescript-client.md)
97- CLAWD TEE Gateway: [gateway.md](gateway.md)
98- Solana Attestation Service credentials: [sas-credentials.md](sas-credentials.md)
99- OP-TEE signer provider: [optee.md](optee.md)
100- Build and deployment: [deployment.md](deployment.md)
101- Debugging guide: [debugging.md](debugging.md)
102- Source map and external endpoints: [resources.md](resources.md)