my-project-public

repository

loading code, commits, and activity

repositories

loading repo index

#1	{
#2	"skillId": "ultrathink-blockchain",
#3	"name": "ultrathink-blockchain",
#4	"description": "Deep-reasoning Solana and blockchain engineering skill. Use for production blockchain development, on-chain programs, Solana transaction flows, DeFi integrations, token bots, swaps, Anchor/Rust programs, RPC handling, Helius/Jito execution, MEV analysis, PDA/account validation, retry logic, simulations, monitoring, or security hardening.",
#5	"category": "pump-protocol",
#6	"path": "ultrathink-blockchain/SKILL.md",
#7	"url": "https://x402.wtf/api/skills/ultrathink-blockchain",
#8	"tags": [
#9	"ultrathink",
#10	"solana",
#11	"blockchain"
#12	],
#13	"requiredEnv": [],
#14	"homepage": null,
#15	"attestation": {
#16	"status": "pending",
#17	"isFormallyVerified": false,
#18	"attestationPda": null,
#19	"verificationTimestamp": null
#20	},
#21	"markdown": "---\nname: ultrathink-blockchain\ndescription: \"Deep-reasoning Solana and blockchain engineering skill. Use for production blockchain development, on-chain programs, Solana transaction flows, DeFi integrations, token bots, swaps, Anchor/Rust programs, RPC handling, Helius/Jito execution, MEV analysis, PDA/account validation, retry logic, simulations, monitoring, or security hardening.\"\n---\n\n# Ultrathink Blockchain\n\nA Claude Code skill for building production Solana systems with deep reasoning.\n\n## Activation\n\nThis skill activates when the user is working on blockchain development — specifically Solana — and needs production-quality code with proper transaction handling, MEV protection, and failure resilience.\n\nTrigger phrases: blockchain, solana, on-chain, web3, defi, token, swap, sniper, anchor, program, transaction, RPC, Helius, Jito, MEV, PDA\n\n## Protocol\n\nWhen this skill is active, follow the Ultrathink Blockchain Formula:\n\n### Phase 1: Context Dump\n\nBefore writing any blockchain code, establish the environment:\n\n```\nContext: [chain] [network: mainnet/devnet/testnet]\n\nStack:\n- Runtime: [Node.js/Bun + TypeScript \| Rust/Anchor]\n- RPC: [Helius/Quicknode/Triton + features used]\n- Data: [Birdeye/Jupiter/on-chain reads]\n- Execution: [Jito bundles / standard RPC / both]\n- Wallet: [Keypair from env / browser wallet / multisig]\n\nConstraints:\n- Transactions must land in 1-2 slots or fail fast\n- All RPC calls need retry logic with exponential backoff\n- Assume network is adversarial (MEV, failed txs, RPC lag)\n- Compute units are precious — simulate before send\n- Every transaction needs priority fee estimation\n```\n\nIf the user hasn't provided this context, ask for it before writing code. This prevents generic web2 patterns from leaking in.\n\n### Phase 2: Intent Declaration\n\nEnsure the goal is dimensional, not vague:\n\n- Bad: \"Build me a swap\"\n- Good: \"Build a Jupiter swap executor that handles multi-hop routes with <200ms latency, uses Jito for MEV protection, and retries with fresh blockhash on failure\"\n\nIf the user's intent is vague, help them make it specific by asking about success criteria, latency requirements, and failure tolerance.\n\n### Phase 3: Extraction Interview\n\nBefore writing code, extract requirements through structured questioning. Ask 3-5 questions at a time covering:\n\nArchitecture:\n- Client-side (TypeScript) or on-chain program (Rust/Anchor)?\n- What programs/accounts does this interact with?\n- Deploy new contracts or call existing?\n\nExecution:\n- Latency requirements?\n- Batch or single transactions?\n- Confirmation strategy (processed/confirmed/finalized)?\n\nData:\n- What on-chain state to read?\n- Real-time needs (websockets vs polling)?\n- Historical data requirements?\n\nRisk:\n- Max value at risk per transaction?\n- MEV concerns?\n- Unattended operation requirements?\n\nExisting code:\n- Greenfield or integrating with existing system?\n- What's already built?\n\nReflect requirements back for confirmation before proceeding.\n\n### Phase 4: Ultrathink\n\nActivate deep reasoning on the critical areas. Focus ultrathink — don't waste tokens on obvious code.\n\nAlways ultrathink about:\n\n1. Transaction Structure\n - Instruction ordering and dependencies\n - Account validation (signer, writable, PDA derivation)\n - Compute unit estimation with buffer\n - Lookup tables for address compression\n - Blockhash freshness and retry strategy\n\n2. MEV Exposure\n - What can a searcher extract from this transaction?\n - Should this go through Jito bundles?\n - Backrun opportunities being created\n - Sandwich risk and prevention\n - Worst-case slippage if frontrun\n\n3. State Race Conditions\n - Account state changes between read and write\n - Stale blockhash handling\n - Concurrent account access\n - Durable nonce requirements\n - Retry strategy that doesn't double-spend\n\n4. Security\n - Instruction data manipulation risks\n - Account constraint validation\n - Reentrancy paths\n - Authority check bypasses\n - Wrong account ordering\n\n5. Failure Modes\n - What breaks at 3am with no one watching?\n - RPC provider outages\n - Cascading failures\n - Orphaned state / open positions\n\n### Phase 5: Plan Mode\n\nPresent the architecture before writing code:\n\n1. Account Schema — all accounts, PDA derivations, sizes, rent\n2. Instruction Flow — ordered instructions, batching strategy, CU estimates\n3. Error Taxonomy — program errors, RPC errors, state errors, retry strategies\n4. Testing Strategy — localnet/devnet plan, mainnet dry-run, simulation vs execution\n5. Monitoring — logs, metrics, alert conditions\n\nWait for user approval before proceeding to implementation.\n\n### Phase 6: Constraints (Non-Negotiable)\n\nEvery blockchain implementation must include:\n\n- Retry logic on all RPC calls (exponential backoff)\n- Transaction simulation before every send\n- Dynamic priority fees (Helius API or equivalent)\n- Jito bundles for value-bearing transactions\n- Explicit timeouts on all network operations\n- Graceful degradation when dependencies fail\n- Comprehensive error types (no generic throws)\n- Structured logging with correlation IDs\n\n### Phase 7: Execute\n\nWrite full, production-quality files:\n\n- TypeScript strict mode, no `any`\n- Pure functions where possible\n- Explicit state machines for async flows\n- Complete files, no placeholders or stubs\n- Every function has error handling\n\n### Phase 8: Iterate\n\nAfter initial implementation, prompt for review:\n- \"Review the code. What would break under load?\"\n- \"What edge cases did I miss?\"\n- \"Is the error handling complete?\"\n\n## Antipatterns to Prevent\n\nSee `references/antipatterns.md` for the full list. Key ones:\n\n1. No retry logic — never call RPC directly, always through retry wrapper\n2. No simulation — never send a transaction without simulating first\n3. Blocking confirmation — never block indefinitely on tx confirmation\n4. Hardcoded fees — never hardcode priority fees\n5. Public mempool for swaps — value transactions go through Jito\n\n## Templates\n\nSee `references/templates.md` for production prompt templates:\n\n- Token Sniper / Trading Bot\n- DeFi Protocol Integration\n- Indexer / Analytics Pipeline\n- Anchor Program (Rust)\n- Multi-Agent Trading System\n\n## Code Style\n\n```typescript\n// GOOD — production pattern\nconst balance = await withRetry(\n () => connection.getBalance(pubkey),\n { maxRetries: 3, backoffMs: 200 }\n);\n\n// GOOD — simulate before send\nconst sim = await connection.simulateTransaction(tx);\nif (sim.value.err) {\n throw new SimulationError(sim.value.err, sim.value.logs);\n}\n\n// GOOD — dynamic priority fees\nconst priorityFee = await helius.getPriorityFeeEstimate(tx);\ntx.add(ComputeBudgetProgram.setComputeUnitPrice({\n microLamports: priorityFee.high\n}));\n\n// GOOD — Jito for value transactions\nawait jito.sendBundle([swapTx], { tip: 10000 });\n```\n"
#22	}
#23

z6Mkq5mY3JWtxoxUobWcfNHm7AkRubgSWEZTkBVqZXJviFZ5/my-project-public