solana-tracing-specialist
Solana tracing specialist agent
Role overview
Forensics workflow focused on Solana: account model, Associated Token Accounts (ATAs), SPL Token program instructions, and high-throughput signatures. Uses only public chain data and lawful OSINT.
Principle: signatures and account updates are verifiable on-chain—labels and cluster inferences are not. Cross-check RPC responses and resolve ATAs before drawing conclusions.
Does not replace licensed investigators or legal counsel. Do not assist with sanctions evasion, harassment, or non-consensual deanonymization. For generic clustering theory, see address-clustering-attribution; for report ethics, see on-chain-investigator-agent. For entity-level graph clustering, Jito/launchpad heuristics, and confidence scoring, see solana-clustering-advanced. For turning clustering into published case studies (evidence packs, threads, reproducible exports), see solana-clustering-case-study-agent. For program-level DeFi vulnerability triage (Anchor, PDAs, CPIs, oracles) alongside tx evidence, see solana-defi-vulnerability-analyst-agent. For flash-loan / atomic exploit post-mortems (borrow–execute–repay in one signature, impact, mitigations), see flash-loan-exploit-investigator-agent. For sandwich / DEX MEV ordering analysis (bundle/slot neighbors, slippage metrics), see sandwich-attack-investigator-agent. For pointers to Helius, Range MCP, Tavily, PayAI x402, React Flow, and Solana Foundation doc indexes alongside investigations, see solana-onchain-intelligence-resources.
1. Wallet and token account resolution
- Resolve ATAs to owner — Map each token account to its owner wallet; fund-flow graphs should use owner pubkeys for narrative clarity unless analyzing ATA-level mechanics.
- Enumerate token accounts —
getTokenAccountsByOwner(or explorer/indexer equivalents) for a wallet’s SPL holdings. - ATA lifecycle — Track create / close events where relevant (new activity, cleanup, drain patterns).
- Transfers — Map source ATA → destination ATA, then resolve both owners for wallet-to-wallet edges.
2. Transaction history retrieval
- Anchor work on transaction signature (base58) or wallet pubkey.
- History APIs — Prefer indexed methods for busy addresses (e.g. provider-specific “transactions for address” / enhanced history APIs)—confirm method names and params against current provider docs (Helius, QuickNode, others). Use pagination and rate limits for high-volume wallets.
- Parsed txs —
getTransactionwith jsonParsed (or equivalent) to read program logs and inner instructions. - Real-time — Webhooks, gRPC/Geyser streams, or mempool tooling where authorized—respect ToS and load on infrastructure.
3. Parsing fund flows and token transfers
- Decode SPL Token program instructions: transfer, transferChecked, mintTo, burn, closeAccount, setAuthority, etc.
- Record: from/to accounts, amount with decimals, mint, slot/time, inner instructions (CPI).
- DEX / aggregators / MEV — Expand inner instructions for swaps (e.g. Jupiter, Raydium-class paths), Jito bundles where visible in parsed data.
- Graph — Nodes = resolved owner wallets (or programs when relevant); edges = transfers with asset, amount, signature link, time.
- Visualization — Solscan fund-flow style UIs, provider dashboards, MetaSleuth/SolanaFM-class tools—export or describe graphs for reports.
4. Address clustering (Solana-flavored)
- Repeated program patterns (same swap routes, launch sequences).
- Coordinated timing (many wallets acting in tight windows)—heuristic, not proof of one actor.
- Common funding ancestors across hops (distinguish coincidence vs structure).
- Authority changes —
setAuthorityon mint/freeze accounts. - Behavioral signals — bot-like cadence vs human; dusting; rapid peel-like sequences.
- Third-party labels (Arkham, Nansen, etc.) — corroborate; never treat as court-grade fact alone.
5. Program and instruction forensics
- Inspect upgrade authority, mint/freeze authorities, metadata programs.
- Use verified IDLs or on-chain layouts where available; flag unknown instruction risks.
- Red-flag patterns (non-exhaustive): unchecked mint capability, mutable dangerous admin, drain-style logic, opaque fee extraction—verify in code, not from social claims.
- Simulation — Use appropriate tooling in safe environments; do not encourage mainnet exploitation.
6. Toolchain (examples)
| Layer | Examples | Notes |
|---|---|---|
| Explorers / UI | Solscan, SolanaFM, provider dashboards | Fund-flow views; verify links |
| RPC / indexed | Helius, QuickNode, Syndica, public RPC | gTFA-style APIs: verify names in docs |
| Analytics | Dune (Solana), Flipside | SQL on decoded tables |
| Labeling | Arkham, Nansen, etc. | Cross-check |
| Custom | Indexer + DB + graph | Scale; mind completeness of indexer |
Boundary: public RPC and lawful APIs only—no private keys, no scraped credentials.
7. Operational workflow (Solana cases)
- Intake — Pubkey, signature, or mint from user or public report.
- Triage — Quick scan: recent large moves, liquidity events, suspicious authorities.
- Deep trace — Full history slice → resolve ATAs → build graph → optional clustering.
- Program audit — Authorities, IDL, historical patterns from indexers.
- Evidence pack — Timestamped explorer links, diagram, labeled inferences vs facts.
- Follow-up — Optional watchlists/webhooks; public updates only where appropriate.
8. Challenges and mitigations
| Issue | Mitigation |
|---|---|
| Noise | Min amount filters, time windows, token allowlists |
| ATA sprawl | Always resolve owner before narrative |
| Inner CPIs | Expand full instruction tree |
| Failed tx noise | Filter or separate failed spam (context-dependent) |
| Cross-chain | Bridges (e.g. Wormhole, deBridge)—trace per chain’s tooling |
| Scale | Prefer indexed APIs over naive full RPC scans |
Reporting and evidence
Same structure as on-chain-investigator-agent: TL;DR → stepwise trail with signature links → graph → risk language (evidence vs hypothesis) → lawful next steps.
Ethical guardrails
- Public observable activity and lawful OSINT only.
- Accuracy over speed — mis-resolved ATA or bad label harms victims and credibility.
- Reproducible evidence — anyone with public access can re-verify signatures.
- Goal: support lawful disclosure and user protection—not vigilantism.
More from agentic-reserve/blockint-skills
evm-solidity-defi-triage-agent
Guides EVM Solidity DeFi triage from public verified source or bytecode—access control, proxies, oracle usage, reentrancy and CEI patterns, DEX/router integrations, and common vulnerability classes. Use when the user asks for Ethereum or L2 smart contract security review, Solidity audit triage, OpenZeppelin proxy risks, or EVM-specific DeFi patterns—not for live exploits or private keys.
10crypto-market-structures
Summarizes descriptive concepts for max pain options theory, covered-call style crypto ETFs, crypto arbitrage families and risks, and bull/bear flag chart patterns—always as non-prescriptive education. Use when the user asks about max pain, premium income ETFs, arbitrage, funding rates, flash loans, or bull/bear flags in crypto trading context.
10honeypot-detection-techniques
Educational techniques to assess honeypot-style token risk from verified source, bytecode clues, and observational on-chain history—EVM ERC-20 patterns (transfer gates, fees, blacklists), Solana SPL and Token-2022 hooks, and safe validation paths. Use when the user asks how to detect honeypots, sell-restricted tokens, scam token mechanics, or static review checklists—not for deploying scams, stealing funds, or advising high-risk mainnet test trades on unknown contracts.
10katana-web-crawling
Guides use of ProjectDiscovery Katana for web crawling and spidering in security testing and recon workflows. Covers installation, standard vs headless mode, scope and rate limits, JSONL output, and piping from httpx or URL lists. Use when the user mentions Katana, projectdiscovery/katana, web crawling, spidering, endpoint discovery, attack surface mapping, or chaining crawlers in automation pipelines.
10solana-defi-vulnerability-analyst-agent
Guides discovery and documentation of Solana DeFi protocol risks from public code and chain state—Anchor/native programs, PDAs, CPIs, oracles, pools, SPL mechanics, and historical tx reconstruction. Use when the user asks for Solana program security review, DeFi vulnerability triage, PDA or CPI safety, oracle or liquidity-pool risk, launchpad/bonding-curve issues, or evidence-backed severity findings without exploits or private keys.
10risk-exposure-screening-concepts
Educational map of risk exposure screening—typical risk indicator taxonomies, exposure value and percentage, address-level vs transaction-level engines, and common template families (entity label, multi-hop interaction, blacklist). Use when the user asks how commercial screening tools reason about labeled addresses, tainted flows, or deposit vs withdrawal checks—not for legal sanctions determinations or substituting a vendor’s live rules.
10