my-project-public

repository

loading code, commits, and activity

repositories

loading repo index

#1	# The Complete Ultrathink Blockchain Formula
#2
#3	A comprehensive guide to using Claude Code's extended thinking for production blockchain development.
#4
#5	---
#6
#7	## Part 1: Understanding Ultrathink
#8
#9	### What Actually Happens
#10
#11	When you invoke `ultrathink`, you're triggering Claude Code's extended thinking mode — an internal reasoning chain that runs before any output is generated. This isn't just "think longer." It's a fundamentally different cognitive process:
#12
#13	Standard mode:
#14	```
#15	Input → Pattern match → Generate output
#16	```
#17
#18	Ultrathink mode:
#19	```
#20	Input → Decompose problem → Generate hypotheses →
#21	Evaluate tradeoffs → Simulate failure modes →
#22	Select approach → Generate output
#23	```
#24
#25	The key insight: ultrathink explores the solution space before committing. It considers multiple architectures, anticipates problems, and makes reasoned choices — all before you see a single line of code.
#26
#27	---
#28
#29	### The Depth Ladder
#30
#31	\| Invocation \| Token Budget \| Best For \|
#32	\|------------\|--------------\|----------\|
#33	\| `think` \| ~500 tokens internal \| Simple decisions, quick fixes \|
#34	\| `think step by step` \| ~1000 tokens \| Multi-step problems, debugging \|
#35	\| `think hard` \| ~2000 tokens \| Architecture decisions, complex logic \|
#36	\| `think harder` \| ~4000 tokens \| System design, security analysis \|
#37	\| `ultrathink` \| ~8000+ tokens \| Production systems, critical code \|
#38	\| `megathink` \| Maximum depth \| Novel problems, research-grade work \|
#39
#40	The tradeoff: Deeper thinking = better reasoning but slower response and higher token cost. Use the right level for the task.
#41
#42	---
#43
#44	### Activation Patterns
#45
#46	These phrases reliably trigger deep reasoning:
#47
#48	```
#49	ultrathink about...
#50	think very carefully about...
#51	before answering, deeply consider...
#52	explore multiple approaches before deciding...
#53	reason through this step by step, considering edge cases...
#54	think like a senior [blockchain/security/systems] engineer would...
#55	```
#56
#57	Stacking for maximum depth:
#58	```
#59	ultrathink. Consider this from multiple angles:
#60	- Performance implications on-chain
#61	- Security attack vectors
#62	- MEV exposure
#63	- Failure modes under load
#64	- Gas/compute unit optimization
#65
#66	Then give me your recommended approach with justification.
#67	```
#68
#69	---
#70
#71	### Focusing Ultrathink (Don't Waste It)
#72
#73	Raw `ultrathink` burns tokens on everything, including obvious parts. Focus it:
#74
#75	Unfocused (wasteful):
#76	```
#77	Build me a Solana swap aggregator. ultrathink.
#78	```
#79
#80	Focused (surgical):
#81	```
#82	Build me a Solana swap aggregator.
#83
#84	ultrathink specifically about:
#85	- Route optimization across Jupiter, Raydium, Orca
#86	- Slippage calculation with real-time liquidity depth
#87	- Transaction assembly for atomic multi-hop swaps
#88	- Priority fee estimation using recent block data
#89
#90	For the standard parts (CLI parsing, config loading, logging),
#91	just write clean straightforward code.
#92	```
#93
#94	This pattern: deep reasoning where it matters, efficient execution everywhere else.
#95
#96	---
#97
#98	### Ultrathink + Verification Loop
#99
#100	The most powerful pattern combines deep thinking with explicit verification:
#101
#102	```
#103	ultrathink about [problem].
#104
#105	Then:
#106	1. State your assumptions explicitly
#107	2. Identify the 3 biggest risks in your approach
#108	3. Explain what would make this solution fail
#109	4. Give me the implementation
#110
#111	I'll review before we proceed.
#112	```
#113
#114	This forces Claude Code to think adversarially about its own solution — which catches bugs that normal generation misses entirely.
#115
#116	---
#117
#118	## Part 2: Blockchain-Native Adaptation
#119
#120	### The Blockchain Context Dump
#121
#122	Every blockchain session should start with context that prevents generic web2 patterns from leaking in:
#123
#124	```
#125	Context: We're building on Solana mainnet-beta.
#126
#127	Stack:
#128	- Runtime: Node.js / Bun with TypeScript
#129	- RPC: Helius (DAS API + websockets + priority fee API)
#130	- Data: Birdeye API for price/market data
#131	- Execution: Jito bundles for MEV protection
#132	- Wallet: Keypair from env, no browser wallet
#133
#134	Constraints:
#135	- Transactions must land in 1-2 slots or fail fast
#136	- All RPC calls need retry logic with exponential backoff
#137	- Assume network is adversarial (MEV, failed txs, RPC lag)
#138	- Compute units are precious — simulate before send
#139	- Every transaction needs priority fee estimation
#140
#141	Do not:
#142	- Use deprecated @solana/web3.js patterns
#143	- Assume transactions confirm on first try
#144	- Ignore partial failures in batch operations
#145	- Use synchronous RPC calls in hot paths
#146	```
#147
#148	This context primes Claude Code to think like a Solana developer, not a generic JS developer.
#149
#150	---
#151
#152	### Solana-Specific Ultrathink Triggers
#153
#154	These prompts activate blockchain-native reasoning:
#155
#156	Transaction Construction:
#157	```
#158	ultrathink about the transaction structure:
#159	- Instruction ordering and dependencies
#160	- Account validation (signer, writable, PDA derivation)
#161	- Compute unit estimation with buffer
#162	- Lookup tables for address compression
#163	- Blockhash freshness and retry strategy
#164	```
#165
#166	MEV Awareness:
#167	```
#168	ultrathink about MEV exposure:
#169	- What can a searcher extract from this transaction?
#170	- Should this go through Jito bundles?
#171	- Is there a backrun opportunity we're creating?
#172	- Can the transaction be sandwiched? How do we prevent it?
#173	- What's the worst case slippage if we're frontrun?
#174	```
#175
#176	State Race Conditions:
#177	```
#178	ultrathink about state races:
#179	- What if the account state changes between read and write?
#180	- How do we handle stale blockhash?
#181	- What if another transaction touches this account first?
#182	- Should we use durable nonces?
#183	- What's the retry strategy that doesn't double-spend?
#184	```
#185
#186	Program Security:
#187	```
#188	ultrathink about attack vectors:
#189	- Can instruction data be manipulated to drain funds?
#190	- Are all account constraints validated on-chain?
#191	- Is there a reentrancy path?
#192	- Can authority checks be bypassed?
#193	- What happens if accounts are passed in wrong order?
#194	```
#195
#196	---
#197
#198	### The Blockchain Interview Protocol
#199
#200	Adapt the interview phase for chain development:
#201
#202	```
#203	Before writing any code, interview me about:
#204
#205	Architecture:
#206	- Is this a program (Rust/Anchor) or client-side (TS)?
#207	- What programs/accounts does this interact with?
#208	- Do I need to deploy anything or just call existing contracts?
#209
#210	Execution:
#211	- Latency requirements? (< 200ms for sniping, relaxed for analytics)
#212	- Batch operations or single transactions?
#213	- Confirmation strategy (processed, confirmed, finalized)?
#214
#215	Data:
#216	- What on-chain state do I need to read?
#217	- Real-time requirements? (websockets vs polling)
#218	- Historical data needs? (archive RPC, indexed data)
#219
#220	Risk:
#221	- What's the max value at risk per transaction?
#222	- MEV concerns? Need Jito?
#223	- What happens if this fails at 3am with no one watching?
#224
#225	Existing code:
#226	- Is this greenfield or integrating with existing system?
#227	- What's already built that I should know about?
#228
#229	Ask me 3-5 questions at a time.
#230	```
#231
#232	---
#233
#234	### Blockchain-Specific Planning Mode
#235
#236	When you enable plan mode for blockchain projects, add these requirements:
#237
#238	```
#239	plan mode: on
#240
#241	Your plan must include:
#242
#243	1. Account Schema
#244	- All accounts this touches (PDAs, token accounts, system accounts)
#245	- Derivation paths for PDAs
#246	- Account sizes and rent calculations
#247
#248	2. Instruction Flow
#249	- Ordered list of instructions per transaction
#250	- Which can be batched vs must be sequential
#251	- Compute unit estimates per instruction
#252
#253	3. Error Taxonomy
#254	- Program errors we might hit
#255	- RPC errors and retry strategy
#256	- State errors (insufficient balance, wrong owner, etc.)
#257
#258	4. Testing Strategy
#259	- Localnet/devnet test plan
#260	- Mainnet dry-run approach
#261	- What we simulate vs what we actually execute
#262
#263	5. Monitoring
#264	- How do we know this is working?
#265	- What logs/metrics do we emit?
#266	- Alert conditions
#267
#268	Present the plan. I'll review before you write code.
#269	```
#270
#271	---
#272
#273	## Part 3: Quick Reference
#274
#275	```
#276	┌─────────────────────────────────────────────────────────────┐
#277	│ CLAUDE CODE × BLOCKCHAIN FORMULA │
#278	├─────────────────────────────────────────────────────────────┤
#279	│ │
#280	│ 1. CONTEXT DUMP Set chain, stack, constraints │
#281	│ 2. INTENT Goal + success criteria │
#282	│ 3. INTERVIEW Requirements extraction │
#283	│ 4. ULTRATHINK Focus on: TX, MEV, races, security │
#284	│ 5. PLAN Accounts, instructions, errors │
#285	│ 6. CONSTRAINTS Retries, simulation, Jito │
#286	│ 7. EXECUTE Full files, production patterns │
#287	│ 8. ITERATE Review → steer → continue │
#288	│ │
#289	├─────────────────────────────────────────────────────────────┤
#290	│ ULTRATHINK FOCUS AREAS FOR BLOCKCHAIN: │
#291	│ • Transaction atomicity and instruction ordering │
#292	│ • MEV exposure — who can extract value from this? │
#293	│ • State races — what if account changes mid-operation? │
#294	│ • Failure modes — what breaks at 3am? │
#295	│ • Security — can this be exploited? How? │
#296	│ │
#297	├─────────────────────────────────────────────────────────────┤
#298	│ NEVER SHIP WITHOUT: │
#299	│ ✓ Retry logic on all RPC calls │
#300	│ ✓ Transaction simulation before send │
#301	│ ✓ Dynamic priority fees │
#302	│ ✓ Jito bundles for value transactions │
#303	│ ✓ Explicit timeouts on network ops │
#304	│ ✓ Graceful shutdown / position cleanup │
#305	│ │
#306	└─────────────────────────────────────────────────────────────┘
#307	```
#308
#309	---
#310
#311	Ultrathink. Build on-chain. Ship to mainnet.
#312

z6Mkq5mY3JWtxoxUobWcfNHm7AkRubgSWEZTkBVqZXJviFZ5/my-project-public