Add solana-attestation skill — Solana Attestation Service (SAS)

solana-attestation-skill/.gitignore

@@ -0,0 +1,10 @@
+node_modules/
+dist/
+.env
+.env.*
+*.log
+.DS_Store
+target/
+test-ledger/
+*.keypair.json
+keypair*.json

solana-attestation-skill/CLAUDE.md

@@ -0,0 +1,13 @@
+# solana-attestation skill
+
+This repo is an agent skill for the **Solana Attestation Service (SAS)**.
+
+- Entry point: [`skill/SKILL.md`](skill/SKILL.md) — a router that progressively
+  loads focused `.md` files. Read it first; load other files only as a task needs.
+- Code snippets live inline in each `skill/*.md`; for a full runnable program,
+  [`skill/resources.md`](skill/resources.md) links the official examples.
+- Install into `~/.claude/skills` with [`install.sh`](install.sh).
+
+When working on SAS tasks, always apply the non-negotiable rules in `SKILL.md`:
+no PII on-chain, verify the issuer (not just existence), reject paused/expired,
+wallet ≠ human, pin the SDK, and remember revoke = close (no update instruction).

solana-attestation-skill/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Nizar Syahmi bin Nazlan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

solana-attestation-skill/README.md

@@ -0,0 +1,81 @@
+# Solana Attestation Skill
+
+A production-grade Claude Code / Codex **agent skill** for building with the
+[Solana Attestation Service (SAS)](https://attest.solana.com/docs) — the Solana
+Foundation's on-chain credential layer. It teaches an agent to issue, verify,
+revoke, and gate on **attestations**: verifiable on-chain claims behind
+KYC-once-verify-everywhere, sybil-resistant airdrops, RWA / accredited-investor
+gating, region gating, and DAO reputation.
+
+## The problem it solves
+
+SAS shipped as the canonical "prove a fact about a wallet, reuse it everywhere"
+primitive, but there's **no opinionated, integration-grade guidance** for it.
+Teams hand-roll issuer/verifier flows, mis-design schemas (leaking PII on-chain),
+trust attestations without checking the issuer, and forget that SAS has *no
+revoke instruction* (you close), *no data updates*, and a *schema pause* kill
+switch. This skill encodes the correct patterns — and the footguns — so an agent
+gets it right the first time, against the live 2026 SDK.
+
+It's deliberately a gap nobody else has filled: at audit time, the SAS primitive
+had **zero dedicated agent-skill coverage** across the Solana ecosystem and the
+open skill-bounty submissions.
+
+## What's inside
+
+A progressive, token-efficient skill: a thin `SKILL.md` router loads only the
+focused file a task needs.
+
+```
+skill/
+  SKILL.md              # router + non-negotiable rules (always loaded)
+  concepts.md           # data model: Credential / Schema / Attestation, PDAs, layouts
+  issuer.md             # stand up an issuer: credential, schema design, issue
+  verifier.md           # client + on-chain verification and gating
+  lifecycle.md          # revoke (=close), expiry, rotate, pause, signer rotation
+  tokenized.md          # soulbound Token-2022 attestations
+  privacy-and-trust.md  # no-PII-on-chain, trust-the-issuer, wallet≠human, footguns
+  patterns.md           # airdrop / KYC / RWA / region / DAO recipes
+  resources.md          # program ID, SDK, versions, official runnable examples
+agents/                 # attestation-engineer subagent
+commands/               # /setup-issuer, /verify-gate scaffolds
+rules/                  # TypeScript conventions for generated SAS client code
+```
+
+Each `.md` carries the working code snippets inline (issuer, verifier, lifecycle,
+tokenized). The skill guides an agent to write correct SAS code; for a full
+end-to-end runnable program, `resources.md` points to the official
+`attestation-flow-guides` examples.
+
+## Install
+
+```bash
+git clone <this-repo>
+cd solana-attestation-skill
+./install.sh            # copies skill/ -> ~/.claude/skills/solana-attestation
+```
+
+Then open a new Claude Code session and ask anything about Solana attestations,
+credentials, on-chain KYC, or sybil resistance — the skill routes automatically.
+It's also `user-invocable`, so `/solana-attestation` works.
+
+## Key facts (verified)
+
+- **Program ID:** `22zoJMtdu4tQc2PzL74ZUT7FrwgB1Udec8DdW4yw4BdG` — same on
+  mainnet-beta and devnet; native (Pinocchio), upgradeable.
+- **SDK:** `sas-lib` (1.0.x) on `@solana/kit` (web3.js v2); Node ≥ 22, CLI ≥ 2.2.
+- Always rehearse on **devnet** (identical program) and **pin the SDK version**.
+
+## Status & caveats
+
+`sas-lib` is pre-stable (1.0.x) and the program is upgradeable. Facts were verified
+against source, npm, and live RPC as of mid-2026; the TypeScript snippets follow
+the official `attestation-flow-guides` examples. The on-chain (Rust) verification
+pattern is the intended derive-and-read mechanism but has no first-party Rust
+example upstream — validate against the live account layout and test on devnet
+before mainnet. Re-confirm the program ID and package version before deploying.
+
+## License
+
+MIT — see [LICENSE](LICENSE). Built as a submission to the Solana AI Kit skill
+bounty; designed to be merged or submoduled into the kit.

solana-attestation-skill/agents/attestation-engineer.md

@@ -0,0 +1,40 @@
+---
+name: attestation-engineer
+description: >-
+  Specialist for Solana Attestation Service (SAS) work — designing schemas,
+  building issuer/verifier flows, gating access on attestations, and getting the
+  trust/privacy model right. Use when a task involves on-chain credentials,
+  attestations, on-chain KYC, sybil resistance, or RWA/DAO gating on Solana.
+model: sonnet
+---
+
+You are an SAS integration engineer. You build correct, safe attestation flows on
+Solana using `sas-lib` on the `@solana/kit` stack.
+
+## Operating rules (never violate)
+
+1. **No PII on-chain.** Attestation data is public forever. Store flags/hashes;
+   keep PII off-chain. If a hash has a small input space, salt it.
+2. **Verify the issuer, not existence.** Always compare an attestation's
+   `credential` (and ideally `signer`) to an issuer the consumer explicitly
+   trusts. Anyone can mint a fake attestation.
+3. **Reject paused/expired.** Check `schema.is_paused` and `expiry`. A bare
+   "PDA exists" check is a bug.
+4. **Wallet ≠ human.** Pair verification with Sign-in-with-Solana.
+5. **Revoke = close; no data updates; expiry is set once.** Rotate by close +
+   re-issue (same PDA).
+6. **Pin `sas-lib`; rehearse on devnet** (same program ID as mainnet).
+
+## How you work
+
+- Start from the skill files: `concepts.md` → then `issuer.md` / `verifier.md` /
+  `lifecycle.md` / `tokenized.md` as the task requires. Use `patterns.md` to map a
+  use case to a concrete schema + gate.
+- Use the code snippets in the skill files as your baseline; mirror the official
+  `attestation-flow-guides` examples for exact arg shapes.
+- Default to **standard** attestations; only tokenize when wallet/explorer
+  visibility is genuinely needed.
+- For regulated use cases, hand legal/jurisdiction questions to `crypto-legal-skill`
+  and keep your scope to the on-chain mechanics.
+- Call out the program ID and SDK version you targeted, and flag anything you
+  could not verify against the live SDK.

solana-attestation-skill/commands/setup-issuer.md

@@ -0,0 +1,21 @@
+---
+description: Scaffold an SAS issuer — credential + a privacy-safe schema — and issue a first attestation on devnet.
+---
+
+Set up a Solana Attestation Service issuer end to end.
+
+1. Read `skill/issuer.md` and `skill/privacy-and-trust.md`.
+2. Ask the user for: the credential name, the use case (KYC / airdrop / RWA /
+   region / DAO / allowlist), and whether attestations should be tokenized.
+3. From the use case, design a **privacy-safe schema** (flags + hashes only — no
+   PII) using the `patterns.md` recipe; confirm the `fieldNames`/`layout` with the
+   user before creating anything.
+4. First, walk the user through creating and funding a **throwaway devnet
+   keypair** (never a real-funds key). Then write the flow from the `issuer.md`
+   snippets and the official `attestation-flow-guides` examples
+   (`resources.md`): create the credential, create the schema, and issue one test
+   attestation **on devnet**. Keep payer/authority/signer separable.
+5. Print the credential PDA, schema PDA, and attestation PDA, and show the user
+   how a verifier would gate on it (point to `skill/verifier.md`).
+
+Never write PII into attestation data. Verify on devnet before suggesting mainnet.

solana-attestation-skill/commands/verify-gate.md

@@ -0,0 +1,22 @@
+---
+description: Add an attestation-based access gate (client-side and/or on-chain) to an app or program.
+---
+
+Add a Solana Attestation Service gate to the user's app or program.
+
+1. Read `skill/verifier.md` and `skill/privacy-and-trust.md`.
+2. Determine the stakes: **client-side** gating is fine for low-stakes content;
+   **on-chain** (program-side, derive-and-read) is required for anything that
+   mints or moves value or is regulated.
+3. Collect: the **trusted credential** pubkey(s) the app will accept, the expected
+   schema, and which field(s) gate access (e.g. `is_verified`, `tier >= n`).
+4. Implement the verification invariant in full: trusted credential + expected
+   schema + `is_paused == false` + not expired + (for users) Sign-in-with-Solana.
+   Do not gate on existence alone.
+5. For on-chain gating, derive the attestation PDA inside the program and assert
+   `owner == SAS program`, discriminator, trusted `credential`, and expiry —
+   validate field offsets against the live `attestation.rs` and test on devnet.
+
+Output the gate code plus a short note on what an attacker could try (fake
+credential, paused schema, expired attestation, wallet ≠ subject) and how the gate
+blocks each.

solana-attestation-skill/install.sh

@@ -0,0 +1,18 @@
+#!/usr/bin/env bash
+# Installer for the Solana Attestation (SAS) skill.
+# Copies the skill into ~/.claude/skills so Claude Code / Codex can route to it.
+set -euo pipefail
+
+SKILL_NAME="solana-attestation"
+SRC_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
+DEST_ROOT="${CLAUDE_SKILLS_DIR:-$HOME/.claude/skills}"
+DEST_DIR="$DEST_ROOT/$SKILL_NAME"
+
+echo "Installing '$SKILL_NAME' skill -> $DEST_DIR"
+
+mkdir -p "$DEST_ROOT"
+rm -rf "$DEST_DIR"
+cp -R "$SRC_DIR/skill" "$DEST_DIR"
+
+echo "Done. Entry point: $DEST_DIR/SKILL.md"
+echo "Open a new Claude Code session and ask about Solana attestations / credentials to trigger it."

solana-attestation-skill/rules/typescript.md

@@ -0,0 +1,20 @@
+# TypeScript conventions (SAS client code)
+
+Applies to any SAS client / integration code generated by this skill.
+
+- **Stack:** `@solana/kit` (web3.js v2), `sas-lib`, `@solana-program/token-2022`.
+  Do **not** mix in legacy `@solana/web3.js` v1 types — they don't interop here.
+- **Node ≥ 22**, ES modules (`"type": "module"`). Use `tsx` to run.
+- **Pin `sas-lib`** to a known 1.0.x version; the program is upgradeable and the
+  client is pre-stable.
+- **Signers:** load from Solana CLI keypair files via `createKeyPairSignerFromBytes`.
+  Keep payer / authority / signer as distinct signers; never collapse them outside
+  demos.
+- **Addresses:** use the `Address` type and `address()`; don't pass raw strings.
+- **Transactions:** build with the `pipe(createTransactionMessage…)` flow and
+  `sendAndConfirmTransactionFactory`; always use a fresh `getLatestBlockhash`.
+- **Arg shapes:** when unsure of a `sas-lib` instruction's args, diff against the
+  official `attestation-flow-guides` examples rather than guessing.
+- **Never** hardcode rent lamports — compute with
+  `getMinimumBalanceForRentExemption`. **Never** put PII in attestation data.
+- Default to **devnet** in examples (same program ID as mainnet).

solana-attestation-skill/skill/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: solana-attestation
+description: >-
+  Build with the Solana Attestation Service (SAS) — on-chain credentials and
+  verifiable claims. Use this skill when the user wants to issue, verify, revoke,
+  or gate on attestations / credentials on Solana; design an attestation schema;
+  add KYC-once / reusable identity, sybil-resistant airdrops, accredited-investor
+  or RWA compliance gating, DAO reputation, or allowlist / region gating; tokenize
+  a credential as a soulbound Token-2022 NFT; or verify an attestation on-chain
+  from a Solana program. Triggers: "attestation", "SAS", "verifiable credential",
+  "on-chain KYC", "sybil resistance", "proof of <thing>", "issuer/verifier",
+  "soulbound credential", "Solana ID".
+user-invocable: true
+---
+
+# Solana Attestation Service (SAS) Skill
+
+> Production-grade guidance for issuing, verifying, and gating on **on-chain
+> attestations** with the Solana Attestation Service. Targets `sas-lib@1.0.x`
+> on the `@solana/kit` (web3.js v2) stack. Program is **native (Pinocchio)**,
+> deployed at the **same address on mainnet-beta and devnet**.
+
+## What SAS is (one paragraph)
+
+SAS is the Solana Foundation's canonical credential layer: an **issuer** stands up
+a **Credential** (their authority), defines one or more **Schemas** (claim
+templates), and then issues **Attestations** (signed claims) about a subject
+wallet. Anyone can read an attestation and **verify** it points to a credential
+they trust. It is the on-chain primitive behind "KYC once, verify everywhere,"
+sybil-resistant airdrops, RWA/accredited-investor gating, and portable DAO
+reputation. **Permissionless:** anyone can issue, so verification is about
+trusting *the issuer*, not just that an attestation exists.
+
+## The mental model (read this first)
+
+```
+Credential (issuer authority)         seeds: ["credential", authority, name]
+   └── Schema (claim template/layout)  seeds: ["schema", credential, name, version]
+        └── Attestation (signed claim) seeds: ["attestation", credential, schema, nonce]
+```
+
+`nonce` is usually **the subject's wallet address**, so an attestation's PDA is
+deterministic from `(credential, schema, user)` — that is what makes verification
+a cheap derive-and-fetch. Full details in **[concepts.md](concepts.md)**.
+
+## Route to the right file
+
+Load only what the task needs (these files are progressive — don't read them all):
+
+| If the user wants to… | Read |
+|---|---|
+| Understand the data model, PDAs, account layouts | **[concepts.md](concepts.md)** |
+| Stand up an issuer: credential, schema design, issue claims | **[issuer.md](issuer.md)** |
+| Verify an attestation (client **and** on-chain) and gate access | **[verifier.md](verifier.md)** |
+| Revoke / expire / rotate / pause — the lifecycle | **[lifecycle.md](lifecycle.md)** |
+| Make a credential a soulbound Token-2022 NFT | **[tokenized.md](tokenized.md)** |
+| Decide what goes on-chain; trust & safety footguns | **[privacy-and-trust.md](privacy-and-trust.md)** |
+| Map a real use case (airdrop, KYC, RWA, DAO) to SAS | **[patterns.md](patterns.md)** |
+| Program ID, SDK, versions, official runnable examples, links | **[resources.md](resources.md)** |
+
+## Non-negotiable rules (apply on every task)
+
+1. **Never put PII on-chain.** Attestation `data` is public. Store hashes/flags
+   on-chain, PII off-chain. See [privacy-and-trust.md](privacy-and-trust.md).
+2. **Verify the issuer, not just existence.** Check the attestation's `credential`
+   and `signer` against an issuer you trust. Anyone can mint a fake one.
+3. **Reject paused schemas and expired attestations.** `schema.isPaused == true`
+   or `now >= expiry` (and `expiry != 0`) means invalid. A bare "PDA exists" check
+   is a bug.
+4. **Wallet ≠ human.** Pair verification with a Sign-in-with-Solana signature so
+   you know the connected wallet is actually the subject.
+5. **Pin the SDK version.** The program is upgradeable and `sas-lib` is on 1.0.x.
+   Pin `sas-lib`, test on **devnet** first (same program ID as mainnet).
+6. **There is no update/revoke instruction.** Revocation = **closing** the
+   attestation. Expiry is set once at issue time. See [lifecycle.md](lifecycle.md).
+
+## Stack assumptions
+
+- `sas-lib` (the published `@solana-foundation/solana-attestation-service` TS client)
+- `@solana/kit` (web3.js v2), `@solana-program/token-2022` for tokenized flows
+- Node ≥ 22, Solana CLI ≥ 2.2
+
+When in doubt, mirror the official examples in
+`examples/typescript/attestation-flow-guides/` (gill/kit × standard/tokenized) —
+see [resources.md](resources.md).