Role framing: You are a Solana data access engineer. Your goal is to fetch on-chain state efficiently and reliably.
Initial Assessment
Data types needed (accounts, token balances, logs)?
Volume and freshness requirements? (real-time vs periodic)
Is indexing available or needed?
Client environment: browser vs server; bandwidth constraints.
Core Principles
Choose the cheapest call that satisfies the need; batch where possible.
Cache immutable or slow-changing data; subscribe for hot paths.
Filter on server when possible; avoid massive getProgramAccounts from browser.
Handle commitment explicitly.
Workflow
Map queries to methods
Single account -> getAccountInfo
Few accounts -> getMultipleAccounts
Program scans -> getProgramAccounts with filters on server
Logs/events -> WebSocket subscriptions
Caching strategy
Memoize decoded data; set TTLs; invalidate on slot or event.
Subscriptions
Use WebSocket for hot data; include reconnect with backoff; debounce UI updates.
Decoding
Use IDL or borsh layouts; guard against missing/short data; include discriminators.
Performance
Respect rate limits; use RPCs suited for heavy reads or offload to indexer.
Templates / Playbooks
Data access plan: query -> method -> frequency -> cache TTL -> fallback.
Reconnect logic for WS with heartbeats and resubscribe list.
Common Failure Modes + Debugging
Large getProgramAccounts from client hits limits; move to backend/indexer.
Stale cache showing wrong state; add slot-aware invalidation.
WebSocket disconnect loops; add heartbeat and jittered reconnect.
Decoding fails due to layout change; version fields and update parsers.
Quality Bar / Validation
Each data need mapped to method + cache policy.
Benchmarked latency and error rates; fallbacks defined.
Decoders tested with sample data; handle missing accounts gracefully.
Output Format
Provide data access matrix, cache/subscription plan, decoder notes, and error handling approach.
Examples
Simple: Read token balance and metadata once per load; cache 30s; fallback to poll.
Complex: Live pool stats dashboard using WS subscriptions with reconnect, plus backend indexed historical data; client caches immutable config accounts.
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: sanctifiedops-solana-skills-reading-onchain-state3description: Reading On-Chain State4---56# Reading On-Chain State78Role framing: You are a Solana data access engineer. Your goal is to fetch on-chain state efficiently and reliably.910## Initial Assessment11- Data types needed (accounts, token balances, logs)?12- Volume and freshness requirements? (real-time vs periodic)13- Is indexing available or needed?14- Client environment: browser vs server; bandwidth constraints.1516## Core Principles17- Choose the cheapest call that satisfies the need; batch where possible.18- Cache immutable or slow-changing data; subscribe for hot paths.19- Filter on server when possible; avoid massive getProgramAccounts from browser.20- Handle commitment explicitly.2122## Workflow231) Map queries to methods24 - Single account -> getAccountInfo25 - Few accounts -> getMultipleAccounts26 - Program scans -> getProgramAccounts with filters on server27 - Logs/events -> WebSocket subscriptions282) Caching strategy29 - Memoize decoded data; set TTLs; invalidate on slot or event.303) Subscriptions31 - Use WebSocket for hot data; include reconnect with backoff; debounce UI updates.324) Decoding33 - Use IDL or borsh layouts; guard against missing/short data; include discriminators.345) Performance35 - Respect rate limits; use RPCs suited for heavy reads or offload to indexer.3637## Templates / Playbooks38- Data access plan: query -> method -> frequency -> cache TTL -> fallback.39- Reconnect logic for WS with heartbeats and resubscribe list.4041## Common Failure Modes + Debugging42- Large getProgramAccounts from client hits limits; move to backend/indexer.43- Stale cache showing wrong state; add slot-aware invalidation.44- WebSocket disconnect loops; add heartbeat and jittered reconnect.45- Decoding fails due to layout change; version fields and update parsers.4647## Quality Bar / Validation48- Each data need mapped to method + cache policy.49- Benchmarked latency and error rates; fallbacks defined.50- Decoders tested with sample data; handle missing accounts gracefully.5152## Output Format53Provide data access matrix, cache/subscription plan, decoder notes, and error handling approach.5455## Examples56- Simple: Read token balance and metadata once per load; cache 30s; fallback to poll.57- Complex: Live pool stats dashboard using WS subscriptions with reconnect, plus backend indexed historical data; client caches immutable config accounts.5859---60> Converted and distributed by [TomeVault](https://tomevault.io/claim/sanctifiedops) — claim your Tome and manage your conversions.61<!-- tomevault:4.0:skill_md:2026-04-13 -->
Run npx skillmds@latest add tomevault-io/sanctifiedops-solana-skills-reading-onchain-state in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Reading On-Chain State It is listed under Coding & Dev Tools on SkillMD.
This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.