my-project-public

repository

loading code, commits, and activity

repositories

loading repo index

my-project-public — gitlawb

#1	# Ultrathink Deep Dive + Blockchain Adaptation
#2
#3	## Extended Thinking Mechanics & Chain-Native Prompting
#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	### Ultrathink 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: Domain-Specific Templates
#274
#275	### Template: Token Sniper / Trading Bot
#276
#277	```
#278	I want a production Solana token sniper that:
#279	- Monitors [Raydium/Pump.fun/Moonshot] for new pools via websocket
#280	- Evaluates tokens against [criteria: liquidity, holder distribution, etc.]
#281	- Executes buys within [X]ms of detection using Jito bundles
#282	- Implements [trailing stop / take profit / time-based exit] strategy
#283	- Exposes a terminal UI with real-time PnL
#284
#285	Interview me about:
#286	- My RPC setup (Helius tier, dedicated nodes?)
#287	- Risk parameters (max position size, daily loss limit)
#288	- The specific signals I want to filter on
#289	- My existing infra this needs to integrate with
#290
#291	ultrathink about:
#292	- The latency budget from detection → execution
#293	- Race conditions between the monitor and executor
#294	- State management for open positions
#295	- Failure modes when RPC lags or Jito rejects bundles
#296	- How to avoid getting rekt by rugs and honeypots
#297
#298	plan mode: on — I need to see the architecture before code.
#299
#300	Constraints:
#301	- TypeScript with strict mode
#302	- Use Helius websockets for pool detection
#303	- Jito bundle submission for execution
#304	- All secrets from environment variables
#305	- Graceful shutdown that doesn't leave orphan positions
#306	```
#307
#308	---
#309
#310	### Template: DeFi Protocol Integration
#311
#312	```
#313	I want to integrate with [Protocol] to [action: swap/stake/lend/etc.].
#314
#315	Context:
#316	- Protocol address: [address]
#317	- IDL available: [yes/no, location]
#318	- Documentation: [link if exists]
#319
#320	Interview me about:
#321	- The specific user flow I'm building
#322	- Whether I need to handle [token accounts, ATAs, wrapping SOL]
#323	- Expected transaction frequency
#324	- Error handling requirements
#325
#326	ultrathink about:
#327	- The exact instruction sequence this protocol expects
#328	- Account validation — what PDAs need derivation?
#329	- Edge cases: what if user has no ATA? What if balance insufficient?
#330	- How to simulate this transaction before sending
#331
#332	Before writing code, show me:
#333	1. The account schema for each instruction
#334	2. The instruction data layout
#335	3. Example transaction structure
#336
#337	Then implement with full error handling.
#338	```
#339
#340	---
#341
#342	### Template: Indexer / Analytics Pipeline
#343
#344	```
#345	I want to index [event type] from [program/token/protocol] and:
#346	- Store in [Postgres/SQLite/Redis]
#347	- Expose via [REST API / GraphQL / websocket]
#348	- Update in [real-time / batched]
#349
#350	Interview me about:
#351	- Historical depth needed (how far back?)
#352	- Query patterns (what questions am I answering?)
#353	- Update latency requirements
#354	- Scale expectations (events per second)
#355
#356	ultrathink about:
#357	- The gRPC vs websocket vs polling tradeoff for ingestion
#358	- Schema design for the query patterns I described
#359	- Handling chain reorgs and missed slots
#360	- Backfill strategy for historical data
#361	- Rate limit management with the RPC provider
#362
#363	plan mode: on
#364
#365	Constraints:
#366	- Use Helius webhooks or geyser if applicable
#367	- Idempotent processing (re-running is safe)
#368	- Include health checks and lag monitoring
#369	- Document the schema with example queries
#370	```
#371
#372	---
#373
#374	### Template: Anchor Program (Rust)
#375
#376	```
#377	I want an Anchor program that [functionality].
#378
#379	Interview me about:
#380	- The accounts this program will manage
#381	- Who can call which instructions (authority model)
#382	- Fee structure if any
#383	- Upgrade authority plan
#384
#385	ultrathink about:
#386	- Account sizing and rent implications
#387	- PDA derivation strategy (seeds, bump handling)
#388	- Access control vulnerabilities
#389	- Integer overflow/underflow risks
#390	- Reentrancy potential
#391	- What happens if accounts are passed in wrong order
#392
#393	plan mode: on — show me:
#394	1. Account struct definitions
#395	2. Instruction signatures
#396	3. Error enum
#397	4. Events emitted
#398	5. Key security invariants
#399
#400	Constraints:
#401	- Anchor 0.29+ patterns
#402	- All math uses checked operations or safe-math
#403	- Events for every state change
#404	- Comprehensive error types (no generic errors)
#405	- Include test scaffolding in TypeScript
#406	```
#407
#408	---
#409
#410	### Template: Multi-Agent Trading System
#411
#412	```
#413	I want a multi-agent system where:
#414	- Agent A monitors [data source] for signals
#415	- Agent B evaluates signals against [strategy]
#416	- Agent C executes approved trades via [execution venue]
#417	- Agent D manages risk and position limits
#418	- All agents coordinate via [message bus / shared state]
#419
#420	Interview me about:
#421	- The specific signal sources and their data format
#422	- Strategy parameters (what makes a "good" signal?)
#423	- Execution requirements (speed, MEV protection)
#424	- Risk limits (position size, correlation, drawdown)
#425	- How I want to monitor and intervene
#426
#427	ultrathink about:
#428	- Agent coordination — avoiding race conditions and conflicts
#429	- State consistency across agents
#430	- Failure isolation — one agent crashing shouldn't kill the system
#431	- Human override mechanisms
#432	- Backtest vs live mode switching
#433
#434	plan mode: on
#435
#436	Show me the message schemas, state machine for each agent,
#437	and the coordination protocol before writing implementation.
#438	```
#439
#440	---
#441
#442	## Part 4: Blockchain Antipatterns
#443
#444	### What Claude Code Gets Wrong (And How to Fix It)
#445
#446	Problem: Generic RPC patterns without retries
#447	```typescript
#448	// BAD — Claude's default
#449	const balance = await connection.getBalance(pubkey);
#450
#451	// GOOD — production pattern
#452	const balance = await withRetry(
#453	() => connection.getBalance(pubkey),
#454	{ maxRetries: 3, backoffMs: 200 }
#455	);
#456	```
#457
#458	Fix prompt:
#459	```
#460	All RPC calls must use retry logic with exponential backoff.
#461	Never call the RPC directly — always through a retry wrapper.
#462	```
#463
#464	---
#465
#466	Problem: Ignoring transaction simulation
#467	```typescript
#468	// BAD — YOLO send
#469	await sendAndConfirmTransaction(connection, tx, [signer]);
#470
#471	// GOOD — simulate first
#472	const sim = await connection.simulateTransaction(tx);
#473	if (sim.value.err) {
#474	throw new SimulationError(sim.value.err, sim.value.logs);
#475	}
#476	// then send with priority fee based on simulation CU
#477	```
#478
#479	Fix prompt:
#480	```
#481	Every transaction must be simulated before sending.
#482	Use simulation results to set compute unit limit accurately.
#483	Never send a transaction that hasn't been simulated.
#484	```
#485
#486	---
#487
#488	Problem: Blocking on confirmation
#489	```typescript
#490	// BAD — blocks forever on congestion
#491	await sendAndConfirmTransaction(...); // can hang for 60s+
#492
#493	// GOOD — timeout and retry strategy
#494	const sig = await sendWithTimeout(tx, { timeoutMs: 5000 });
#495	const confirmed = await pollConfirmation(sig, { maxAttempts: 10 });
#496	```
#497
#498	Fix prompt:
#499	```
#500	Transaction confirmation must have explicit timeouts.
#501	Implement a retry strategy for transactions that don't land.
#502	Never block indefinitely waiting for confirmation.
#503	```
#504
#505	---
#506
#507	Problem: Hardcoded priority fees
#508	```typescript
#509	// BAD — hardcoded, stale
#510	tx.add(ComputeBudgetProgram.setComputeUnitPrice({ microLamports: 1000 }));
#511
#512	// GOOD — dynamic based on network
#513	const priorityFee = await helius.getPriorityFeeEstimate(tx);
#514	tx.add(ComputeBudgetProgram.setComputeUnitPrice({
#515	microLamports: priorityFee.high // or medium based on urgency
#516	}));
#517	```
#518
#519	Fix prompt:
#520	```
#521	Priority fees must be estimated dynamically using Helius priority fee API.
#522	Never hardcode priority fees — network conditions change constantly.
#523	```
#524
#525	---
#526
#527	Problem: No MEV protection for swaps
#528	```typescript
#529	// BAD — public mempool, sandwichable
#530	await sendTransaction(swapTx);
#531
#532	// GOOD — Jito bundle
#533	await jito.sendBundle([swapTx], { tip: 10000 });
#534	```
#535
#536	Fix prompt:
#537	```
#538	All value-bearing transactions (swaps, liquidations, arb)
#539	must go through Jito bundles for MEV protection.
#540	Public mempool submission only for non-sensitive operations.
#541	```
#542
#543	---
#544
#545	## Part 5: The Complete Blockchain Formula
#546
#547	### One-Shot Production Prompt
#548
#549	```
#550	Context: Solana mainnet-beta production environment.
#551	Stack: TypeScript, Helius RPC + websockets, Birdeye data, Jito execution.
#552
#553	I want [detailed goal with success metrics].
#554
#555	Before writing code, interview me about requirements, constraints,
#556	existing infrastructure, and edge cases. Ask 3-5 questions at a time.
#557
#558	After the interview:
#559	1. Reflect requirements back for confirmation
#560	2. ultrathink about:
#561	- Transaction structure and instruction ordering
#562	- Account validation and PDA derivation
#563	- MEV exposure and protection strategy
#564	- Failure modes and retry logic
#565	- State race conditions
#566	3. Present plan (accounts, instructions, error taxonomy, tests)
#567	4. Wait for my approval
#568
#569	Constraints:
#570	- All RPC calls through retry wrapper with backoff
#571	- All transactions simulated before sending
#572	- Dynamic priority fees via Helius
#573	- Value transactions through Jito bundles
#574	- Explicit timeout on all network operations
#575	- Graceful degradation when dependencies fail
#576	- Comprehensive error types (no generic throws)
#577	- Structured logging with correlation IDs
#578
#579	Code style:
#580	- TypeScript strict mode, no `any`
#581	- Pure functions where possible
#582	- Explicit state machines for async flows
#583	- Full files, no placeholders
#584
#585	Write production code. I'm shipping this.
#586	```
#587
#588	---
#589
#590	## Quick Reference Card
#591
#592	```
#593	┌─────────────────────────────────────────────────────────────────┐
#594	│ CLAUDE CODE × BLOCKCHAIN FORMULA │
#595	├─────────────────────────────────────────────────────────────────┤
#596	│ │
#597	│ 1. CONTEXT DUMP Set chain, stack, constraints │
#598	│ 2. INTENT Goal + success criteria │
#599	│ 3. INTERVIEW Requirements extraction │
#600	│ 4. ULTRATHINK Focus on: TX, MEV, races, security │
#601	│ 5. PLAN Accounts, instructions, errors, tests │
#602	│ 6. CONSTRAINTS Retries, simulation, Jito, timeouts │
#603	│ 7. EXECUTE Full files, production patterns │
#604	│ 8. ITERATE Review → steer → continue │
#605	│ │
#606	├─────────────────────────────────────────────────────────────────┤
#607	│ ULTRATHINK FOCUS AREAS FOR BLOCKCHAIN: │
#608	│ • Transaction atomicity and instruction ordering │
#609	│ • MEV exposure — who can extract value from this? │
#610	│ • State races — what if account changes mid-operation? │
#611	│ • Failure modes — what breaks at 3am with no one watching? │
#612	│ • Security — can this be exploited? How? │
#613	│ │
#614	├─────────────────────────────────────────────────────────────────┤
#615	│ NEVER SHIP WITHOUT: │
#616	│ ✓ Retry logic on all RPC calls │
#617	│ ✓ Transaction simulation before send │
#618	│ ✓ Dynamic priority fees │
#619	│ ✓ Jito bundles for value transactions │
#620	│ ✓ Explicit timeouts on network ops │
#621	│ ✓ Graceful shutdown / position cleanup │
#622	│ │
#623	└─────────────────────────────────────────────────────────────────┘
#624	```
#625
#626	---
#627
#628	Ultrathink. Build on-chain. Ship to mainnet.
#629

z6Mkq5mY3JWtxoxUobWcfNHm7AkRubgSWEZTkBVqZXJviFZ5/my-project-public