my-project-public

repository

loading code, commits, and activity

repositories

loading repo index

#1	{
#2	"skillId": "solana-formal-verification",
#3	"name": "qedgen",
#4	"description": "Formally verify programs by writing Lean 4 proofs. Trigger this skill whenever the user wants to formally verify code, generate Lean 4 proofs, prove properties about algorithms or smart contracts, verify invariants, convert program logic into formal specifications, or anything involving Lean 4 and formal verification. Also trigger when the user mentions \"qedgen\", \"lean proof\", \"formal proof\", \"verify my code\", \"prove correctness\", \"formal verification\", or wants mathematical guarantees about their implementation.",
#5	"category": "solana-dev",
#6	"path": "solana-formal-verification/SKILL.md",
#7	"url": "https://x402.wtf/api/skills/solana-formal-verification",
#8	"tags": [
#9	"solana",
#10	"formal",
#11	"verification"
#12	],
#13	"requiredEnv": [],
#14	"homepage": null,
#15	"attestation": {
#16	"status": "pending",
#17	"isFormallyVerified": false,
#18	"attestationPda": null,
#19	"verificationTimestamp": null
#20	},
#21	"markdown": "---\nname: qedgen\ndescription: Formally verify programs by writing Lean 4 proofs. Trigger this skill whenever the user wants to formally verify code, generate Lean 4 proofs, prove properties about algorithms or smart contracts, verify invariants, convert program logic into formal specifications, or anything involving Lean 4 and formal verification. Also trigger when the user mentions \"qedgen\", \"lean proof\", \"formal proof\", \"verify my code\", \"prove correctness\", \"formal verification\", or wants mathematical guarantees about their implementation.\n---\n\n# QEDGen — Agent-Driven Formal Verification\n\nYou (Claude) are the proof engineer. You read the codebase, write Lean 4 models and proofs, iterate on compiler errors, and call Leanstral (Mistral's theorem prover) only for hard sub-goals you cannot fill yourself.\n\n## Architecture\n\n```\nYou (Claude) Leanstral (remote model)\n ├── Read spec / source code ├── Fill sorry markers\n ├── Write Lean 4 models └── Suggest tactics for hard goals\n ├── Write theorem statements\n ├── Write proof attempts\n ├── Run `lake build`, read errors\n └── Fix and iterate\n```\n\n## Step 1: Understand the program\n\nCheck for existing artifacts in this priority order:\n\n1. spec.md exists → Read it. An existing spec captures the author's intent, state model, invariants, and operations. Extract security goals, state model, and formal properties. Skip the scoping quiz and go directly to Step 2.\n2. IDL exists (`target/idl/<program>.json`) → Run `qedgen spec --idl <path>` to generate a draft SPEC.md with TODO markers, then refine interactively.\n3. Neither exists → Read the source code directly. Ask broader scoping questions.\n\n## Step 2: Scope the verification\n\nIf no spec.md was found, run a short interactive quiz — one question at a time, with checkbox options derived from the program's structure. Ask about functionality and risks, not implementation details.\n\nQuestion 1: \"What does this program need to guarantee above all else?\"\nOptions derived from the program's structure:\n- Authorization / access control\n- Tokens are never lost / correct routing\n- One-shot safety / no replay\n- Arithmetic safety / no overflow\n- Conservation (e.g., vault >= total claims)\n- All of the above\n\nQuestion 2: \"Which scenario worries you most?\"\nGenerate concrete risk scenarios from the program.\n\nQuestion 3: \"Does the program make any assumptions that aren't enforced on-chain?\"\n\nAsk questions one at a time. Wait for the user's answer before presenting the next question.\n\n## Step 3: Write SPEC.md\n\nWrite `formal_verification/SPEC.md` using normative language (MUST, MUST NOT, MAY). Structure:\n\n```markdown\n# <Program Name> Verification Spec v1.0\n\n<1-2 sentences describing what the program does>\n\n## 0. Security Goals\n1. <Goal name>: <normative statement>\n\n## 1. State Model\n<State struct with field names, types, and comments>\n<Lifecycle diagram if applicable>\n\n## 2. Operations\n### 2.1 <Operation name>\nSigners: <who MUST sign>\nPreconditions: <what MUST be true before>\nEffects: <numbered steps>\nPostconditions: <what MUST be true after>\n\n## 3. Formal Properties\n### 3.1 <Category>\n<property_id>: For all <quantified variables>,\nif <transition predicate> then <conclusion>.\n\n## 4. Trust Boundary\n<What is axiomatic and why>\n\n## 5. Verification Results\n\| Property \| Status \| Proof \|\n\|---\|---\|---\|\n\| ... \| Open \| \|\n```\n\nPresent SPEC.md to the user and get confirmation before proceeding.\n\n## Step 4: Set up the Lean project\n\n```bash\nqedgen setup # Ensure global Mathlib cache exists (first time: 15-45 min)\n```\n\nCreate the project structure:\n\n```\nformal_verification/\n lakefile.lean # import lean_support and Mathlib\n lean-toolchain # leanprover/lean4:v4.15.0\n lean_support/ # Solana axiom library (copy from qedgen)\n Proofs.lean # root import: import Proofs.AccessControl etc.\n Proofs/\n AccessControl.lean\n CpiCorrectness.lean\n Conservation.lean\n StateMachine.lean\n ArithmeticSafety.lean\n```\n\n## Step 5: Write Lean proofs\n\nThis is the core step. You write Lean 4 directly — models, transitions, theorems, and proofs.\n\n### Modeling workflow\n\nFor each property in SPEC.md:\n\n1. Define the state as a Lean structure (map fields from source/spec)\n2. Define the transition as `Option StateType` (return `none` on precondition failure)\n3. State the theorem matching the SPEC.md property\n4. Write the proof using the patterns below\n5. Run `lake build` and iterate on errors\n\n### Support library API\n\nAfter `import QEDGen.Solana` and `open QEDGen.Solana`:\n\nTypes:\n- `Pubkey` (= Nat), `U64` (= Nat), `U8` (= Nat)\n- `Account` — `{ key : Pubkey, authority : Pubkey, balance : Nat, writable : Bool }`\n- `Lifecycle` — `open \| closed` (with DecidableEq)\n- `TransferCpi` — `{ program, «from», «to», authority, amount }`\n- `MintToCpi`, `BurnCpi`, `CloseCpi`\n\nConstants:\n- `TOKEN_PROGRAM_ID`, `SYSTEM_PROGRAM_ID`\n- `U8_MAX`, `U16_MAX`, `U32_MAX`, `U64_MAX`, `U128_MAX`\n\nFunctions:\n- `findByKey : List Account → Pubkey → Option Account`\n- `findByAuthority : List Account → Pubkey → Option Account`\n- `canWrite : Pubkey → Account → Prop`\n- `transferCpiValid : TransferCpi → Prop`\n- `closes : Lifecycle → Lifecycle → Prop`\n- `valid_u64 : Nat → Prop` (and u8, u16, u32, u128)\n\nKey lemmas:\n- `closes_is_closed`, `closes_was_open`, `closed_irreversible`\n- `valid_u64_preserved_by_zero`, `valid_u64_preserved_by_same`\n- `find_map_update_other`, `find_map_update_same` (axioms for account list updates)\n\n### Proof patterns\n\nAccess control — signer must match authority:\n```lean\nstructure ProgramState where\n authority : Pubkey\n\ndef cancelTransition (s : ProgramState) (signer : Pubkey) : Option Unit :=\n if signer = s.authority then some () else none\n\ntheorem cancel_access_control (s : ProgramState) (signer : Pubkey)\n (h : cancelTransition s signer ≠ none) :\n signer = s.authority := by\n unfold cancelTransition at h\n split_ifs at h with h_eq\n · exact h_eq\n · contradiction\n```\n\nCPI correctness — parameters match (pure `rfl`):\n```lean\ndef cancel_build_cpi (ctx : CancelContext) : TransferCpi :=\n { program := TOKEN_PROGRAM_ID, «from» := ctx.escrow_token, «to» := ctx.dest,\n authority := ctx.authority, amount := ctx.amount }\n\ntheorem cancel_cpi_correct (ctx : CancelContext) :\n let cpi := cancel_build_cpi ctx\n cpi.program = TOKEN_PROGRAM_ID ∧ cpi.«from» = ctx.escrow_token ∧\n cpi.«to» = ctx.dest ∧ cpi.authority = ctx.authority ∧\n cpi.amount = ctx.amount := by\n unfold cancel_build_cpi\n exact ⟨rfl, rfl, rfl, rfl, rfl⟩\n```\n\nState machine — lifecycle transitions:\n```lean\ndef cancelTransition (s : ProgramState) : Option ProgramState :=\n if s.escrow.lifecycle = Lifecycle.open then\n some { escrow := { s.escrow with lifecycle := Lifecycle.closed } }\n else none\n\ntheorem cancel_closes_escrow (pre post : ProgramState)\n (h : cancelTransition pre = some post) :\n post.escrow.lifecycle = Lifecycle.closed := by\n unfold cancelTransition at h\n split_ifs at h with h_open\n cases h\n rfl\n```\n\nConservation — invariant preserved across operations:\n```lean\ndef conservation (s : EngineState) : Prop := s.V >= s.C_tot + s.I\n\ndef depositTransition (s : EngineState) (amount : Nat) : Option EngineState :=\n if s.V + amount <= MAX_VAULT_TVL then\n some { V := s.V + amount, C_tot := s.C_tot + amount, I := s.I }\n else none\n\ntheorem deposit_conservation (s s' : EngineState) (amount : Nat)\n (h_inv : conservation s)\n (h : depositTransition s amount = some s') :\n conservation s' := by\n unfold depositTransition at h\n split_ifs at h with h_le\n · cases h\n unfold conservation at h_inv ⊢ -- MUST unfold in BOTH hypothesis and goal\n omega\n · contradiction\n```\n\nArithmetic safety — bounds preserved:\n```lean\ndef initializeTransition (amount taker : Nat) : Option ProgramState :=\n if amount > 0 ∧ amount ≤ U64_MAX ∧ taker > 0 ∧ taker ≤ U64_MAX then\n some { initializer_amount := amount, taker_amount := taker }\n else none\n\ntheorem initialize_arithmetic_safety (amount taker : Nat) (post : ProgramState)\n (h : initializeTransition amount taker = some post) :\n post.initializer_amount ≤ U64_MAX ∧ post.taker_amount ≤ U64_MAX := by\n unfold initializeTransition at h\n split_ifs at h with h_bounds\n cases h\n exact ⟨h_bounds.2.1, h_bounds.2.2.2⟩\n```\n\n### Critical tactic rules\n\n\| Do \| Don't \|\n\|---\|---\|\n\| `unfold f at h` before `split_ifs` \| `simp [f] at h` before `split_ifs` (kills if-structure) \|\n\| `unfold pred at h_inv ⊢` for named predicates \| `unfold pred` only in goal (omega can't see hypotheses) \|\n\| `cases h` after `split_ifs` on `some = some` \| `injection h` (unnecessary, cases handles it) \|\n\| `omega` for linear arithmetic \| `norm_num` for linear goals (omega is more reliable) \|\n\| `exact ⟨rfl, rfl, rfl⟩` for conjunctions of rfl \| `constructor` + `rfl` + `constructor` + `rfl` (verbose) \|\n\| `if cond then ... else ...` without proof binding \| `if h : cond then ...` when `h` is unused \|\n\n### Common errors and fixes\n\n\| Error \| Fix \|\n\|---\|---\|\n\| `omega could not prove the goal` \| Unfold named predicates in hypotheses: `unfold pred at h ⊢` \|\n\| `no goals to be solved` \| Remove redundant tactic (e.g., `· contradiction` after auto-closed branch) \|\n\| `unknown constant 'X'` \| Check imports; add `import QEDGen.Solana.X` or `open QEDGen.Solana` \|\n\| `tactic 'split_ifs' failed, no if-then-else` \| Use `unfold` first, not `simp` \|\n\| `unused variable 'h'` \| Remove proof binding: `if h : cond` → `if cond` \|\n\n## Step 6: Call Leanstral for hard sub-goals\n\nWhen you have a proof with `sorry` markers you cannot fill after 2-3 attempts:\n\n```bash\nqedgen fill-sorry --file formal_verification/Proofs/Hard.lean --validate\n```\n\nThis sends each `sorry` location to Leanstral with focused context. Review the result — Leanstral may introduce tactics you can learn from for future proofs.\n\nIf `fill-sorry` also fails, simplify the theorem statement or split the property into smaller lemmas.\n\n## Step 7: Verify and report\n\n```bash\ncd formal_verification && lake build\n```\n\nUpdate SPEC.md verification results table:\n- Verified: Theorem compiles, no `sorry`\n- Partial: Proof has `sorry` markers\n- Open: No compiling proof\n\n## Environment\n\n- `MISTRAL_API_KEY` — required for `fill-sorry`. Free from [console.mistral.ai](https://console.mistral.ai)\n- `QEDGEN_VALIDATION_WORKSPACE` — optional override for global Mathlib cache location\n\n## Error handling\n\n- First `lake build` is slow: Mathlib compilation takes 15-45 min on first run. Subsequent builds reuse the cache.\n- `could not resolve 'HEAD' to a commit`: Remove `.lake/packages/mathlib` and run `lake update`.\n- Rate limiting (429): Built-in exponential backoff in `fill-sorry`.\n"
#22	}
#23

z6Mkq5mY3JWtxoxUobWcfNHm7AkRubgSWEZTkBVqZXJviFZ5/my-project-public