Transaction 0x9f3… failed. Not due to an error, but due to hidden intent. The net flow showed a 12% slippage spike in a stablecoin pool—an anomaly that looked like a simple arbitrage until I traced the overlapping wallet clusters. But I didn't discover it by crafting a perfect Dune query. I discovered it by dumping 10 minutes of disjointed thoughts into a voice recorder and letting an AI reconstruct the real question. This is Andrej Karpathy's "long-form verbal prompt" method, dropped into a blockchain forensic context. And it changes everything.
Context The method is straightforward: instead of typing a polished prompt, you speak a messy, stream-of-consciousness description of your problem. The AI then asks clarifying questions, turning your monologue into a mini-interview. Karpathy, a founding member of OpenAI and now at Anthropic, presented this as a productivity hack for general complex tasks. But for on-chain analysts—people like me who spend hours stitching together transaction traces, token flows, and contract interactions—it is a paradigm shift. The technique explicitly relies on the model’s ability to parse fragmented intent, weak signals, and implicit goals from high-entropy speech. It moves the analyst from a tool operator to a collaborative thinker. The AI stops being a query executor and becomes an active interrogator.
Core: On-Chain Evidence Chain I tested this on a DeFi exploit trace from last month. A Curve pool had a suspicious sequence of swaps that drained 200 ETH. Normally, I would build a SQL pipeline: extract logs, filter by pool, join with transaction hashes, compute profit. That takes 45 minutes of mental planning and typing. This time, I opened a voice memo, hit record, and spoke: "So, there’s this pool, USDC/DAI, and on block 18,702,140 there’s a flashloan, then three swaps, then a withdraw. I think the attacker used a price oracle manipulation because the spot price deviated 3% from Chainlink. But the math doesn’t add up—the profit is too small for a typical oracle attack. Maybe it’s something with the pool’s internal imbalance? I’m not sure."
The AI—I used Claude 3.5 Sonnet, which is optimized for long context and conversational depth—responded with: "You mentioned a flashloan. Did the same EOA initiate the flashloan and the swaps? Can you confirm the amount of the third swap? If the profit is small, could the real goal be to depeg the pool temporarily for a subsequent arb? Let me rephrase: what is the time delta between the flashloan and the withdraw?"
It asked eight questions. Each question forced me to recall details I had almost skipped. Within three rounds, the AI reconstructed the hypothesis: the attacker used a donation-based manipulation of the pool’s internal price accumulator, a known vulnerability in Curve v2 pools but one I had overlooked because I was fixated on oracle logic. The model didn’t guess—it traced the logical chain from my scattered observations. The result was a terse report: "The drain was 200 ETH, but the profit was only 15 ETH. The remaining 185 ETH was moved to a secondary address via a contract that self-destructed. The attacker achieved this by exploiting the donation function to inflate the accumulator's denominator, calculating a distorted spot price, and executing a swap that front-runs the internal price update." Deciphering the hidden geometry of liquidity pools is rarely this fast.
Contrarian: Correlation ≠ Causation But the method has blind spots. The model reconstructed a narrative from my words—but that narrative could be a beautiful fiction. On-chain verification is still mandatory. I had to manually confirm the donation function calls, the accumulator formula, and the timestamp order. The AI’s questions improved my direction, but they cannot replace the forensic proof. Furthermore, the technique demands a model with high context tolerance and robust active questioning. Not all models handle crypto-specific jargon equally. GPT-4 Turbo, for example, tended to agree with my original hypothesis rather than challenge it, essentially reinforcing my initial bias. Following the trail of outliers that others ignore requires a model that questions, not one that flatters.
There is also a privacy risk. Speaking raw transaction details—some involving unreported exploits—into a cloud voice-to-text engine is a liability. The data remains on third-party servers. In my test, I used local transcription software paired with an API, but the reconstruction step still required sending the transcript to a remote model. Institutional analysts will need on-premise solutions or zero-trust architectures before adopting this at scale. The algorithm does not lie, but it may omit—especially when the omission is your own sensitive data.
Takeaway This method is not a replacement for rigorous data modeling. It is a scaffolding for thinking. It reduces the friction between raw observation and structured hypothesis. Next week, I expect to see blockchain analytics tools integrating voice-driven forensics—imagine clicking a microphone in Nansen or Dune, speaking your confusion, and having the platform guide you to the evidence. The question is: will the models that power these tools be trusted with the rawest on-chain truths, or will they only see what we choose to type? The answer will separate the tools that merely report from those that truly reconstruct.