DEV Community: Pavel Espitia

Oracle Manipulation: How a $392K Silo Finance Loss Happened in 2026

Pavel Espitia — Mon, 06 Jul 2026 17:09:03 +0000

While the nine-figure hacks of 2026 grabbed headlines, the smaller ones are more instructive because they are the bugs you and I might actually write. On April 3, 2026, lending protocol Silo Finance lost about $392,000 to a misconfigured oracle. No exotic attack. A price feed that lied, and a contract that believed it. Here is how oracle manipulation works and why it keeps draining protocols.

The shape of every oracle bug

A lending protocol needs to know what your collateral is worth. It asks an oracle. If the oracle can be fooled, the protocol can be fooled: borrow against collateral that is suddenly "worth" far more than it is, or get liquidated when it is suddenly "worth" far less.

Every oracle exploit reduces to the same question: can the attacker move the number the contract trusts, cheaply enough that the manipulation costs less than the profit?

The classic mistake: pricing off a spot DEX pool

The most common version reads the price directly from an AMM pool's reserves:

function getPrice() public view returns (uint256) {
    (uint112 reserve0, uint112 reserve1, ) = pair.getReserves();
    return (reserve1 * 1e18) / reserve0; // spot price, right now
}

This is the spot price at this instant. An attacker with a flash loan can swap a huge amount into the pool, move the reserves, call the function that reads this price, and unwind, all in one transaction. For the duration of that transaction the price is whatever they pushed it to. They borrow against the inflated value and walk away.

The cost is the swap fees and the flash loan fee. The profit is the over-borrowed amount. When the pool is shallow, the cost is tiny.

Why TWAP helps and where it does not

The standard defense is a time-weighted average price. Instead of the instant reserves, you read the price averaged over a window:

// Uniswap V3 style: average tick over `secondsAgo`
function getTwap(uint32 secondsAgo) public view returns (uint256) {
    uint32[] memory secondsAgos = new uint32[](2);
    secondsAgos[0] = secondsAgo;
    secondsAgos[1] = 0;
    (int56[] memory tickCumulatives, ) = pool.observe(secondsAgos);
    int24 avgTick = int24((tickCumulatives[1] - tickCumulatives[0]) / int56(uint56(secondsAgo)));
    return tickToPrice(avgTick);
}

A flash loan cannot move a multi-minute average in one transaction, because the average includes blocks the attacker does not control. That kills the single-transaction flash-loan version.

But TWAP is not a magic word. Two things still bite:

A short window. A 30-second TWAP on a shallow pool can still be moved by an attacker willing to hold the position across a couple of blocks. Longer windows are safer but lag real price, which creates its own risk during fast moves.
A thin pool. TWAP averages the manipulation; it does not prevent it. On a low-liquidity pair, sustained manipulation across the window is affordable.

What "misconfigured" usually means

When a post-mortem says "misconfigured oracle," it is rarely that the team did not know what an oracle is. It is usually one of these:

They used a robust oracle (like Chainlink) for the main asset but a spot DEX price for a newer or thinner asset, and the attacker hit the weak one.
They set a TWAP window too short for the pool's liquidity.
They did not validate the oracle's freshness, so a stale price from a paused or laggy feed was treated as current.

The freshness check is the one people forget:

(, int256 price, , uint256 updatedAt, ) = priceFeed.latestRoundData();
require(price > 0, "bad price");
require(block.timestamp - updatedAt < MAX_STALENESS, "stale price"); // often missing

How I audit for this

When I review a protocol that prices assets, I trace every price read back to its source and ask three things:

Can a single transaction move this number? If it reads spot reserves, yes. Flag it.
Is the averaging window appropriate for the pool's depth? A 30-second TWAP on a $50K pool is not safe.
Is staleness checked? If the code trusts a feed without checking updatedAt, a paused feed becomes an attack.

This is a place where AI-assisted review genuinely helps, because the vulnerability spans multiple functions and requires reasoning about economics, not just syntax. The prompt I use asks the model to "trace each price source, determine whether it is manipulable within one transaction or one block, and estimate the cost of manipulation relative to the protocol's borrow limits." That economic framing is what separates "I see a getReserves call" from "this $50K pool gates a $1M borrow cap, which is exploitable."

The Silo loss was small by 2026 standards, but the lesson scales: the protocol is only as honest as the cheapest number it trusts. Find the cheapest number, and you have found the bug.

I Built a Coding Agent With the Manual Tool-Use Loop. Here's What It Taught Me

Pavel Espitia — Sun, 05 Jul 2026 15:20:02 +0000

Everyone reaches for the SDK's tool runner because it hides the agentic loop. I wrote the loop by hand instead, for a small tool that edits files based on instructions. It was more code, and it taught me exactly what an agent is doing under the hood, which paid off the first time I needed human approval before a destructive action. Here is the manual loop, and what controlling it directly buys you.

What the loop actually is

An "agent" sounds mysterious. It is a while loop. The model responds, and either it is done (end_turn) or it wants to call a tool (tool_use). If it wants a tool, you run the tool, feed the result back, and call the model again. Repeat until done.

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();
const tools: Anthropic.Tool[] = [ /* your tool defs */ ];
let messages: Anthropic.MessageParam[] = [{ role: "user", content: task }];

while (true) {
  const response = await client.messages.create({
    model: "claude-opus-4-8",
    max_tokens: 16000,
    thinking: { type: "adaptive" },
    output_config: { effort: "xhigh" },
    tools,
    messages,
  });

  if (response.stop_reason === "end_turn") break;

  // Preserve the assistant turn, including tool_use blocks
  messages.push({ role: "assistant", content: response.content });

  const toolUses = response.content.filter(
    (b): b is Anthropic.ToolUseBlock => b.type === "tool_use",
  );

  const results: Anthropic.ToolResultBlockParam[] = [];
  for (const t of toolUses) {
    const output = await runTool(t.name, t.input);
    results.push({ type: "tool_result", tool_use_id: t.id, content: output });
  }

  messages.push({ role: "user", content: results });
}

That is the entire thing. The tool runner does this for you. Writing it yourself means you own every step.

The two rules that took me longest to internalize

Always append the full response.content, not just the text. The assistant turn contains the tool_use blocks, and the next request needs them so the tool_result blocks can be matched by tool_use_id. If you strip to just text, the model has no record it asked for a tool, and the conversation breaks.

Every tool_result needs the matching tool_use_id. The model fired N tool calls; you return N results, each tagged with the id it answers. Send them all in one user message. Mismatch the ids and you get a 400.

Why I did not use the tool runner

The tool runner is great until you need to do something between the model deciding to call a tool and the tool actually running. For my file editor, I wanted a human to approve any write before it happened. The manual loop makes that a one-line insert:

for (const t of toolUses) {
  if (t.name === "write_file") {
    const approved = await askHuman(`Write to ${t.input.path}? (y/n)`);
    if (!approved) {
      results.push({
        type: "tool_result",
        tool_use_id: t.id,
        content: "User denied the write. Suggest an alternative.",
        is_error: true,
      });
      continue;
    }
  }
  const output = await runTool(t.name, t.input);
  results.push({ type: "tool_result", tool_use_id: t.id, content: output });
}

Notice the denial goes back to the model as a tool result with is_error: true and a message. The model reads "user denied the write" and adapts, maybe proposing a different file or asking why. With the tool runner hiding the loop, inserting that gate is awkward. With the manual loop it is obvious.

The gates worth adding

Once you own the loop, the natural gates appear:

Approval for destructive or external actions (writes, sends, deletes).
Logging of every tool call and result, which is gold for debugging why an agent did something weird.
A turn limit, so a confused agent does not loop forever burning tokens.
Conditional execution, like "skip this tool call if we already ran it this session."

let turns = 0;
while (turns++ < MAX_TURNS) {
  // ...
}
if (turns >= MAX_TURNS) console.warn("hit turn limit, agent may be stuck");

When to go back to the runner

I am not saying always hand-roll. For an agent with no approval gates, no special logging, and tools that are all safe to auto-run, the tool runner is less code and just as correct. The decision is whether you need to intervene between decision and action. If yes, manual loop. If no, runner.

What writing it by hand gave me, beyond the approval gate, was a real mental model. When an agent misbehaves now, I do not think "the magic broke." I think "the model returned a tool_use I did not handle" or "I fed back a malformed result." The loop is small enough to hold in your head, and holding it in your head is worth the extra code at least once.

Proxy Contracts and Storage Collisions: The Upgrade That Corrupts Your State

Pavel Espitia — Sat, 04 Jul 2026 15:14:47 +0000

Upgradeable contracts are everywhere in DeFi, and they hide a category of bug that has nothing to do with the logic you wrote and everything to do with where Solidity puts your variables. Storage collisions corrupt state silently: no revert, no error, just a balance that is suddenly an address or an owner that is suddenly a number. Here is how proxies store data, how collisions happen, and how to avoid them.

How a proxy works in 30 seconds

An upgradeable contract is actually two contracts. The proxy holds the state (the storage) and the address of the implementation. When you call the proxy, it delegatecalls into the implementation. The implementation's code runs, but it runs against the proxy's storage.

That last part is the whole source of the danger. The logic contract's code reads and writes storage slots, but those slots belong to the proxy. So the proxy and every implementation must agree, exactly, on what lives in each storage slot.

Where Solidity puts variables

Solidity assigns state variables to storage slots in declaration order, starting at slot 0:

contract V1 {
    address public owner;    // slot 0
    uint256 public total;    // slot 1
    mapping(address => uint256) public balances; // slot 2
}

owner is slot 0, total is slot 1, and so on. The implementation reads slot 0 expecting an address. As long as that is true, everything works.

The collision: reordering on upgrade

Now you ship V2 and, innocently, reorder the variables or insert a new one at the top:

contract V2 {
    uint256 public total;    // slot 0  ← was address owner!
    address public owner;    // slot 1  ← was uint256 total!
    mapping(address => uint256) public balances; // slot 2
}

You did not change the proxy's storage. The proxy still has the old owner address sitting in slot 0. But V2's code now reads slot 0 as total, a uint256. So total is now the numeric value of the old owner's address, and owner is whatever number used to be total.

No revert. The contract runs. It is just operating on garbage. An attacker who notices can often exploit the corrupted owner slot to take control.

The rules that prevent it

The fix is discipline about storage layout across versions:

Never reorder existing variables. Their slots are fixed forever once deployed.
Never change a variable's type in a way that changes its slot size.
Only append new variables at the end, after all existing ones.
Never remove a variable. Leave it (you can rename it to deprecated_x for clarity), or its slot gets reused by the next variable and you have a collision.

contract V2 {
    address public owner;    // slot 0, unchanged
    uint256 public total;    // slot 1, unchanged
    mapping(address => uint256) public balances; // slot 2, unchanged
    uint256 public feeRate;  // slot 3, NEW, appended at the end. Safe.
}

Storage gaps and namespaced storage

Two patterns make this safer. The older one is a storage gap: reserve empty slots in a base contract so child contracts have room to add variables without colliding with the next contract in the inheritance chain:

contract Base {
    address public owner;
    uint256[49] private __gap; // reserved slots for future variables
}

The modern one, ERC-7201 namespaced storage, sidesteps the problem by putting each module's storage at a hashed, collision-resistant slot rather than packing everything from slot 0. If you are starting a new upgradeable contract in 2026, prefer namespaced storage; it makes whole classes of collision structurally impossible.

How I check for it in an audit

When I review an upgradeable contract, the implementation logic is only half the job. The other half is comparing the storage layout of the new version against the deployed one. Foundry and Hardhat both have tooling that dumps the storage layout:

forge inspect V2 storageLayout

I diff that against V1's layout and look for any variable whose slot changed. A changed slot for an existing variable is a collision, full stop. The check is mechanical, which is exactly why it gets skipped under deadline pressure, and exactly why it bites.

The unsettling part of storage collisions is that your code can be perfect and your upgrade still corrupts everything, because the bug is in the layout, not the logic. Treat the storage layout as a contract in its own right: append-only, never reordered, diffed on every upgrade. The compiler will not warn you. You have to look.

Effort Levels in Practice: I Benchmarked low Through max on Real Tasks

Pavel Espitia — Fri, 03 Jul 2026 15:56:37 +0000

The current Claude models give you an effort knob with five settings: low, medium, high, xhigh, max. The docs tell you what each is for. I wanted numbers, so I ran the same three real tasks across all five levels and measured tokens, latency, and quality. The results changed how I set effort, and one of them surprised me. Here is the data and what I do with it now.

What effort controls

Effort is not just "how much the model thinks." It controls overall token spend: how much it thinks and how it acts. Lower effort means fewer, more consolidated tool calls, less preamble, terser output. Higher effort means more exploration before answering. The default is high if you omit it.

const response = await client.messages.create({
  model: "claude-opus-4-8",
  max_tokens: 16000,
  thinking: { type: "adaptive" },
  output_config: { effort: "medium" }, // the knob
  messages,
});

The three tasks

I picked tasks that span the range of what I actually do:

Classification: label a contract finding as low/medium/high/critical. Short, scoped.
Code generation: write a TypeScript function with edge-case handling. Medium difficulty.
Multi-step audit: analyze a 200-line contract for vulnerabilities across functions. Hard, agentic.

I ran each at all five effort levels, three times, and averaged. I scored quality against a known-correct answer for tasks 1 and 3, and by manual review for task 2.

The results

Task 1, classification. Quality was flat across every effort level. The right label is the right label, and the model nailed it at low just as well as at max. But token usage climbed steeply: max used roughly 8x the tokens of low for an identical answer. Latency tracked tokens.

The lesson: for genuinely simple, scoped tasks, high effort is pure waste. I set classification to low.

Task 2, code generation. Quality improved from low to high, then plateaued. At low the model sometimes skipped an edge case. At high it caught them. xhigh and max produced essentially the same code as high but spent more tokens getting there. Sweet spot: high.

Task 3, the multi-step audit. This is the one that surprised me. I expected token usage to climb monotonically with effort, like task 1. Instead, total tokens were lower at xhigh than at medium for this task. At medium, the model explored less per step, took more turns, hit some dead ends, and re-derived things. At xhigh, it planned better up front and finished in fewer turns. Higher per-step effort, fewer steps, lower total cost. And the quality was clearly best at xhigh.

The counterintuitive bit

I had been treating effort as a cost dial: turn it up, pay more. For one-shot tasks, that holds. For multi-step agentic work, it does not. Higher effort can reduce total cost because better planning means fewer wasted turns. The relationship is not monotonic once a feedback loop is involved.

That matches what Anthropic says about the agentic-coding default being xhigh. I had read it as "they want the best quality regardless of cost." After the benchmark, I read it as "for agentic work, xhigh is often cheaper and better." Both, really.

How I set effort now

A per-call-site decision, not a global default:

Task type	Effort	Why
Classification, routing, extraction	`low`	Quality flat, tokens scale, no reason to pay
Single-shot code or content	`high`	Quality plateaus here; higher is waste
Agentic loops, multi-step audits	`xhigh`	Better planning, fewer turns, often cheaper
Correctness over everything, rare	`max`	Only when a wrong answer costs more than the tokens

Run your own

My numbers are for my tasks. Yours will differ. The point is not to copy my table; it is to stop guessing. Pick three representative tasks, run them across the five levels, and measure tokens and quality. It took me an afternoon and saved me from two wrong defaults: paying high effort for classification (waste) and being scared of high effort on agentic work (wrong, it was cheaper).

The knob is cheap to test and expensive to leave on the wrong setting. Measure it once.

Reading a Verified Contract You Didn't Write: A Systematic Approach

Pavel Espitia — Thu, 02 Jul 2026 14:53:40 +0000

Opening a 600-line Solidity contract you have never seen is intimidating. Where do you even start? Over time I developed a reading order that turns the wall of code into something I can reason about in an hour instead of a day. It is the same order whether I am auditing for vulnerabilities, integrating against the contract, or just trying to understand a protocol. Here it is.

Don't read top to bottom

The instinct is to read the file from line 1. That is the worst approach, because the important parts (who can do what, where money moves) are scattered and the top is usually imports and boilerplate. You burn your attention before you reach anything that matters.

Read in order of power, not order of appearance.

Step 1: find the money

Before anything else, I search for every place value moves:

transfer, transferFrom, send, call{value:, safeTransfer, mint, burn

These are the lines where the contract's assets change hands. Everything else exists to gate these. If I understand who can trigger each of these and under what conditions, I understand the contract's risk surface. So I list them first and treat them as the destinations I am working backward from.

Step 2: map the access control

Next I find every modifier and every require that checks msg.sender or a role:

onlyOwner, onlyRole, require(msg.sender ==, hasRole, _checkOwner

I build a small mental (or literal) table: function, who can call it, what it does. The functions that move money and have weak or missing access control are the first thing I look at hard. This is where the access-control bugs live, the single most common cause of hacks.

setFeeRecipient   → anyone        → sets where fees go   ⚠️
withdrawFees      → feeRecipient  → drains fee balance

Two minutes of this table and a privilege-escalation path (anyone sets themselves as recipient, then withdraws) jumps out, where reading line by line you would never connect the two functions.

Step 3: trace the state variables

Now I look at the storage: what state exists, and which functions write it. The dangerous pattern is a critical variable (a balance, an owner, a price) that more than one function can write, especially if one of those functions is less protected than the others. State that can be set from an unexpected path is where logic bugs hide.

For upgradeable contracts I also check the storage layout here, because a proxy that reorders variables corrupts state silently.

Step 4: external calls and the reentrancy question

For every external call I found in step 1, I ask: does the contract update its state before or after the call? Checks-effects-interactions means state first, external call last. If a balance is decremented after a .call, that is a reentrancy flag. I also note any delegatecall, because that runs foreign code against this contract's storage and is a much sharper edge.

Step 5: the math and the edges

Last, I look at the arithmetic. Division before multiplication (precision loss), decimal mismatches between tokens (USDC has 6, WETH has 18), array operations that could divide by zero on an empty array, and anything that assumes a value cannot be zero. These are quieter bugs but they are real, and they cluster in pricing and accounting code.

Where AI fits in this flow

I do not hand the whole file to a model and say "find bugs." That produces a wall of maybe-findings with no priority. Instead I use the model to accelerate each step. After step 2, I ask it to "list every function that can move assets and the exact access control gating each one," which gives me the table faster than I can build it by hand. After step 4, I ask it to "trace each external call and report whether state is updated before or after it."

The structure comes from me. The model fills in the structure faster than I can. That division of labor is the whole point of AI-assisted auditing: it is a force multiplier on a method, not a replacement for having one.

The payoff

This order works because it follows the actual risk. Money first (the targets), then access control (the gates), then state (the levers), then external calls (the escape hatches), then math (the quiet errors). By the time I have done steps 1 and 2, I usually already have a hypothesis about where the contract is weak, and steps 3 through 5 confirm or kill it.

A 600-line contract is not 600 lines of equal importance. Maybe 30 of them matter. The reading order is how you find those 30 fast.

What I Learned Submitting a Chrome Extension to the Web Store

Pavel Espitia — Wed, 01 Jul 2026 15:08:29 +0000

I built Argus, an AI transaction firewall as a Chrome extension, and submitting it to the Web Store was its own small adventure separate from writing the code. The review process, the permissions justifications, the manifest gotchas: none of it is hard, but all of it is undocumented in the way that matters. Here is what I wish I had known before I hit submit.

The extension, briefly

Argus inspects Web3 transactions before you sign them and warns you if something looks dangerous: an unlimited approval, a drainer pattern, an address that does not match what the dApp claims. It is built with WXT (a modern extension framework) and TypeScript, with an LLM-backed analysis step behind a freemium proxy. The technical part was the part I knew how to do. The store submission was the part that surprised me.

Manifest V3 is the only option now, and it changes your architecture

If you are starting an extension in 2026, it is Manifest V3, period. The biggest practical consequence: no persistent background page. You get a service worker that the browser can kill at any time and restart on the next event. State does not survive.

This bit me. I had assumed a long-lived background context where I could cache analysis results in memory. In MV3 that cache evaporates whenever the worker sleeps. The fix was to treat the service worker as stateless and put anything that needs to persist into chrome.storage:

// Wrong assumption: this Map is gone when the worker sleeps
const cache = new Map<string, Analysis>();

// Right: persist to chrome.storage, which survives worker restarts
async function cacheAnalysis(txHash: string, result: Analysis) {
  await chrome.storage.local.set({ [`tx:${txHash}`]: result });
}
async function getCached(txHash: string): Promise<Analysis | undefined> {
  const data = await chrome.storage.local.get(`tx:${txHash}`);
  return data[`tx:${txHash}`];
}

Design as if the background context can vanish between any two events, because it can.

Permissions are where reviews stall

The store review scrutinizes permissions hard, and rightly so. Every permission you request, you have to justify in the submission form, in plain language, tied to a specific feature. Requesting a broad permission "just in case" is the fastest way to a rejection or a long back-and-forth.

I went through my manifest and cut every permission I was not actively using. For the ones I kept, I wrote the justification before submitting:

storage: cache transaction analyses so we do not re-analyze the same transaction.
activeTab instead of broad host permissions: only read the page the user is actively on, only when they invoke the extension.

The principle is least privilege, and the store enforces it. If you cannot write a one-sentence justification tying a permission to a feature, you do not need the permission.

The privacy disclosure is not optional

Because Argus sends transaction data to a backend for analysis, I had to disclose exactly what data leaves the user's machine and why. The store wants a privacy policy URL and a data-use declaration. "We send transaction details to our server for security analysis and do not retain them beyond the request" is the kind of specific, honest statement they want. Vague or missing disclosures get flagged.

Write this for the user, not for the lawyer. The people reading it are deciding whether to trust your extension with their wallet activity.

Review takes longer than you expect, plan for it

I submitted and then waited. Review is not instant, and if they have a question about a permission or the privacy disclosure, that is another round trip. Build the wait into your launch timeline. I had a soft launch date in mind and the review queue did not care about it.

The lesson: submit earlier than you think you need to, with the cleanest possible permission set and a clear privacy disclosure, so there is nothing to question.

What I would tell past me

The code was 90% of the effort and 10% of the risk to launch. The submission was 10% of the effort and most of the launch risk, because a rejection there blocks everything. So front-load it:

Start with MV3 and a stateless service-worker design.
Request the minimum permissions and write the justification for each one as you add it, not at submission time.
Write the privacy disclosure honestly and specifically.
Submit with buffer time before any date you have promised anyone.

None of this is hard once you know it. All of it is friction if you discover it at submission time. Now you know it.

RAG for Code: Why Chunking by Function Beats Chunking by Lines

Pavel Espitia — Tue, 30 Jun 2026 15:03:05 +0000

I built a retrieval system over a codebase so an LLM could answer questions about it, and my first version was nearly useless. The problem was not the model or the embeddings. It was how I cut the code into chunks. Splitting source by line count shreds the very structure that makes code meaningful. Here is why function-aware chunking works so much better, and how to do it.

The naive approach and why it fails

The standard RAG tutorial says: split your documents into fixed-size chunks (say 500 tokens), embed each chunk, retrieve the closest ones to the query. For prose, fine. For code, this is destructive.

A 500-token window does not respect function boundaries. You end up with chunks like "the last third of transfer() and the first half of approve()." Neither function is complete. The embedding represents a fragment that means nothing on its own, and when you retrieve it, you hand the model half a function with no signature and no context.

My early system would confidently answer questions about functions it had only seen the middle of. The retrieval was the bottleneck, and the chunking was the cause.

Chunk by structure, not by size

Code has natural units: functions, methods, classes, contracts. Those are the units a developer reasons about, so those are the units to chunk by. One function, one chunk. The chunk includes the full signature, the body, and ideally the doc comment above it.

interface CodeChunk {
  name: string;        // function or method name
  signature: string;   // full signature for context
  body: string;        // the complete function body
  filePath: string;    // where it lives
  startLine: number;
}

Now each chunk is a complete, meaningful thing. Retrieve it and the model gets a whole function it can reason about, with its name and signature intact.

Extracting functions

For Solidity or TypeScript, you can get a long way with a parser rather than regex. For TypeScript I use the compiler API or a tool like ts-morph; for Solidity, a proper parser that gives you the AST. The point is to walk the syntax tree and emit one chunk per function-level node, rather than slicing the raw text.

A simplified shape of the extractor:

import { Project } from "ts-morph";

function chunkByFunction(filePath: string): CodeChunk[] {
  const project = new Project();
  const source = project.addSourceFileAtPath(filePath);
  const chunks: CodeChunk[] = [];

  for (const fn of source.getFunctions()) {
    chunks.push({
      name: fn.getName() ?? "anonymous",
      signature: fn.getSignature().getDeclaration()?.getText() ?? "",
      body: fn.getText(),          // the whole function, intact
      filePath,
      startLine: fn.getStartLineNumber(),
    });
  }
  // also walk classes/methods the same way
  return chunks;
}

Each function comes out whole. No more half-functions.

Embedding and retrieval, locally

I run this entirely on a local model so a private codebase never leaves my machine. Ollama serves an embedding model; I embed each function chunk and store the vectors:

import { Ollama } from "ollama";
const ollama = new Ollama();

async function embed(text: string): Promise<number[]> {
  const r = await ollama.embeddings({ model: "nomic-embed-text", prompt: text });
  return r.embedding;
}

I embed ${chunk.name}\n${chunk.signature}\n${chunk.body} so the function name and signature are part of the vector, not just the body. That makes name-based queries ("what does withdraw do") retrieve well, because the name is in the embedded text.

The payoff in retrieval quality

After switching to function chunks, the same questions that used to get fragmented, half-wrong answers got crisp ones. "How does this contract handle reentrancy in withdrawals?" now retrieves the complete withdraw function plus the modifier it uses, and the model can actually reason about the checks-effects-interactions order because it can see the whole thing.

The model did not get smarter. The retrieval got honest. I was handing it complete units of meaning instead of arbitrary text windows.

A small refinement: include callers

One thing I added later: for a retrieved function, I also pull in the one-line signatures of functions that call it. That gives the model a sense of how the function is used without bloating the chunk. It is cheap context that often answers the follow-up question before it is asked.

The general lesson

RAG quality is mostly retrieval quality, and retrieval quality is mostly chunking quality. The instinct to chunk by size comes from text-document tutorials, but code is not prose. It has structure, and that structure is exactly what carries the meaning. Chunk along the structure, embed the name and signature with the body, and run it locally if the code is private. The embeddings and the model were never the problem. The scissors were.

The Drift Protocol Hack: A Six-Month Social Engineering Operation

Pavel Espitia — Mon, 29 Jun 2026 15:19:00 +0000

On April 1, 2026, attackers drained about $285 million from Drift Protocol on Solana. It was the second-largest exploit in Solana's history, and the post-mortem is the most important security reading of the year, because there was no exploit in the code. It was six months of patient social engineering against the people who held the admin keys. Here is the timeline and the uncomfortable lesson for everyone who builds in this space.

What happened, in order

Drift confirmed the drain on April 1. TVL collapsed from $550 million to under $300 million within an hour. The laundering was aggressive, each bridging transaction moving hundreds of thousands or millions in USDC, faster and more aggressive than even the Bybit laundering of 2025.

But the drain on April 1 was the end of the operation, not the beginning. The post-mortem revealed it was a six-month campaign targeting the humans who controlled the admin keys. The attackers, linked to the Lazarus Group, did not find a bug in the Solana programs. They found a path to the keys, and they took six months to walk it.

This is the pattern, not an exception

Pair Drift with KelpDAO, the $292M LayerZero bridge hack two weeks later, which also traced to a developer being socially engineered six weeks before the drain. Two of the largest hacks of 2026, both human-targeted, both patient, both attributed to state-backed actors.

The numbers back up the pattern. North Korea-linked actors accounted for 76% of crypto hack losses in the first months of 2026, up from 64% in 2025 and under 10% in 2020. Private-key compromise, not code exploits, is now the dominant loss vector. The attack moved up the stack: from the contract to the keys to the people.

What "six months of social engineering" actually looks like

It is not a single phishing email. State-backed campaigns against crypto teams have a recognizable shape, drawn from incident reports across the year:

A fake recruiter or collaborator builds a relationship over weeks.
A "coding test" or "demo project" arrives as a repo. (I have written before about catching one of these aimed at me.)
The repo, or a dependency it pulls in, runs code at install or build time that exfiltrates secrets.
Or the target is socially engineered into approving a transaction, sharing a credential, or running a script on a machine that can reach a hot key.

The throughline: the attacker exploits trust and time, two things no audit covers and no linter detects.

The uncomfortable lesson for builders

I find smart contract bugs for a living, and I have to be honest about the limits of that work. A flawless audit would not have saved Drift or KelpDAO. The code was not the weak point. The team was.

That does not make security work pointless. It relocates the most important part of it. The questions that would have mattered:

How many independent humans must approve a privileged action? If the answer is one, you are one phished engineer away from a drain.
Are admin keys in hardware, behind a time delay, with a circuit breaker? KelpDAO's 46-minute freeze cut the loss by $100M. Operational controls bought what code could not.
Does the team treat every unsolicited repo, recruiter, and "quick favor" as a potential attack? Because in 2026, they are.

What I changed personally

After the year we have had, I tightened my own operational security, not my Solidity:

Unsolicited repos run only in a sandbox, never on a machine with any key or credential. I built a static scanner specifically because I got targeted by one of these lures.
Secrets live in one place with strict permissions, loaded explicitly by the scripts that need them, never auto-exported into every shell. A malicious build in one project cannot slurp every key at once.
I assume any "job opportunity" that leads with a coding test is a lure until proven otherwise. The friction of being paranoid is small. The cost of being wrong is $285 million if you are Drift.

Where AI cuts both ways

The same year that AI made me a faster auditor, reports note it is lowering the bar for exploit discovery, with automated reconnaissance scanning old and unverified contracts. Attackers use AI too. But the Drift and KelpDAO hacks are a reminder that the frontier of attack is not better code analysis. It is better social engineering, and AI helps there as well, generating more convincing personas and lures.

The defense is not a tool. It is a culture that treats people and keys as the primary attack surface, because in 2026 they demonstrably are. Audit the contract. Then audit who can drain it, and how hard you have made their day if they get phished.

Token Counting Done Right: Stop Using tiktoken for Claude

Pavel Espitia — Sun, 28 Jun 2026 14:41:31 +0000

I had a cost estimator that was wrong by 20%, and the reason was embarrassing: I was counting Claude tokens with tiktoken, which is OpenAI's tokenizer. Different model, different tokenizer, different counts. If you are estimating Claude costs or context budgets with a borrowed tokenizer, your numbers are fiction. Here is how to count correctly, and where the wrong way bites.

Why tiktoken is wrong for Claude

tiktoken tokenizes for OpenAI models. Claude uses a different tokenizer. They do not agree on how text splits into tokens. On typical English prose, tiktoken undercounts Claude tokens by roughly 15 to 20%. On code or non-English text, the gap is worse, because tokenizers diverge most on the inputs they were not each optimized for.

So a "cost estimate" or "will this fit in context" check built on tiktoken is systematically off. It told me a prompt was 8,000 tokens when Claude saw closer to 9,500. Multiply that across a busy day and the budget projection is meaningfully wrong.

The right way: the count_tokens endpoint

Claude has a dedicated endpoint for this, and the SDK wraps it. Counts are model-specific, so you pass the same model you will use for inference:

import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic();

const result = await client.messages.countTokens({
  model: "claude-opus-4-8",
  messages: [{ role: "user", content: contractSource }],
});

console.log(result.input_tokens); // the real count Claude will charge for

This is the actual count, from the actual tokenizer, for the actual model. No approximation.

Counting a cost estimate

Once you have the real input count, the cost math is straightforward. For Opus 4.8 at $5 per million input tokens:

const tokens = result.input_tokens;
const inputCost = (tokens / 1_000_000) * 5; // $5/M for Opus 4.8 input
console.log(`Estimated input cost: $${inputCost.toFixed(4)}`);

If you are deciding between tiers, the per-million rates that matter in 2026:

Model	Input $/M	Output $/M
Haiku 4.5	1	5
Opus 4.8	5	25
Fable 5	10	50

The count is the same per model only on the input side; remember output tokens dominate cost on generation-heavy tasks, and you do not know those until you run the request.

Watch the model-specific drift

One subtlety that surprised me: token counts changed between Claude model versions. The same input text produces a higher count on Opus 4.7 than on Opus 4.6, because they count differently. So if you cached a token count from an older model and reused it, you would be wrong again, just less wrong than tiktoken.

The fix is to never cache a count across a model change. Re-run countTokens against the model you are actually using. Do not apply a blanket multiplier to convert between models; the divergence is not uniform.

Diffing a file across versions

A handy pattern for "how many tokens did this change add" is to count both versions and subtract. The endpoint is stateless, so you just count each and diff:

import { execSync } from "node:child_process";
import fs from "node:fs";

async function count(text: string): Promise<number> {
  const r = await client.messages.countTokens({
    model: "claude-opus-4-8",
    messages: [{ role: "user", content: text }],
  });
  return r.input_tokens;
}

const before = execSync("git show HEAD:CLAUDE.md").toString();
const after = fs.readFileSync("CLAUDE.md", "utf8");
console.log(`Delta: ${(await count(after)) - (await count(before))} tokens`);

I use this to keep an eye on system-prompt bloat. When a prompt creeps up by a few thousand tokens, that is real money on every cached-miss request, and the diff makes it visible.

The takeaway

The tokenizer is part of the model. Borrowing another model's tokenizer to estimate counts is like measuring in the wrong units and hoping the error cancels. It does not cancel; it compounds. Use countTokens against the exact model, never reuse a count across model versions, and remember output tokens are the unknown that dominates generation cost. It is one API call, it is free, and it is the difference between a budget projection you can trust and one that is off by a fifth.

Detecting Supply-Chain Malware Without Running the Code

Pavel Espitia — Sat, 27 Jun 2026 14:40:14 +0000

After I got targeted by a fake-job-interview repo designed to steal my keys, I built a scanner that checks a repository for supply-chain attacks without cloning, installing, or running any of it. The whole point is to find the malicious code statically, before it ever executes, because by the time you run npm install it is already too late. Here is how static detection of these attacks works and what it looks for.

Why static, and why before install

The dangerous moment in a supply-chain attack is install or build time. A postinstall script, a malicious dependency, a build step that runs arbitrary code. Once you run npm install, that code has already executed with your shell's environment, including any secrets it can reach.

So a scanner that runs the code to analyze it has already lost. The analysis has to be static: read the files, parse them, reason about them, and never execute a line. That constraint shapes everything.

What the scanner looks for

Three categories cover most of what I have seen in real lures.

1. Build-time code execution. The first thing I check is anything that runs during install or build:

// package.json scripts that fire automatically
const dangerousScripts = ["preinstall", "install", "postinstall", "prepare"];

A postinstall that runs an obfuscated script, downloads and executes a remote payload, or shells out to curl | sh is the single biggest red flag. Legitimate packages occasionally use these hooks, but a postinstall that fetches and runs remote code is almost never benign.

2. Dependencies missing from the lockfile. This is the subtle one, and it is how the attack that targeted me worked. The package.json declares a dependency, but it is not in the lockfile, or the lockfile points a known package name at a malicious tarball URL. The intent is that you trust the familiar name in package.json and never check what the lockfile actually resolves it to.

// Flag dependencies in package.json that the lockfile resolves
// to an unexpected registry or a direct tarball URL
function checkResolutions(pkg: PackageJson, lock: Lockfile) {
  for (const [name] of Object.entries(pkg.dependencies ?? {})) {
    const resolved = lock.packages[name]?.resolved;
    if (resolved && !resolved.startsWith("https://registry.npmjs.org/")) {
      flag(`${name} resolves to a non-registry URL: ${resolved}`);
    }
  }
}

A package named like a popular library but resolved from a random URL is a classic typosquat or hijack.

3. Obfuscation. Malicious payloads are usually obfuscated to hide what they do and slip past a casual reader. So I look for the fingerprints of obfuscation: long hex or base64 string literals, dense \x escape sequences, eval of a decoded string, arrays of character codes assembled at runtime.

function looksObfuscated(source: string): boolean {
  const longHexString = /["'][0-9a-f]{120,}["']/i.test(source);
  const evalOfDecoded = /eval\s*\(\s*(atob|Buffer\.from|decode)/.test(source);
  const charCodeArray = /String\.fromCharCode\s*\(\s*\d+(\s*,\s*\d+){20,}/.test(source);
  return longHexString || evalOfDecoded || charCodeArray;
}

None of these is proof of malice on its own. Together, on a file that also has a postinstall hook, they are damning.

The analyzer core is pure and testable

The most important architectural decision was keeping the analysis logic pure: it takes file contents as input and returns findings, with no I/O of its own. Fetching the repo is a separate layer. That separation means I can unit-test the analyzer against known-malicious and known-clean fixtures without any network or filesystem:

test("flags postinstall that pipes curl to sh", () => {
  const findings = analyze({ "package.json": MALICIOUS_FIXTURE });
  expect(findings).toContainEqual(
    expect.objectContaining({ rule: "remote-code-execution-on-install" }),
  );
});

A security tool that I cannot test thoroughly is a security tool I do not trust. Pure functions make the testing trivial.

Where AI fits, carefully

I do use an LLM as one layer, but not as the gate. The deterministic rules above catch the known patterns reliably. The model is for the judgment call on suspicious-but-not-obviously-malicious code: "this script downloads a config file and parses it, is that benign or a staged payload?" The model reasons about intent in a way regex cannot.

But the model never executes anything either, and I never let it be the sole reason to pass or fail a repo. Deterministic rules first, model for nuance, human for the final call. The model is an advisor, not an authority, because a model can be talked out of a finding and a regex cannot.

The real lesson

The attack that targeted me relied on me trusting a friendly repo and running its install step. The entire defense is to break that chain: analyze before you install, statically, and treat install-time code execution, lockfile mismatches, and obfuscation as the three things most likely to hurt you. You do not need to run hostile code to know it is hostile. You need to read it before it gets the chance to run.

Chatting With Any EVM Contract: How Scry Resolves Proxies and Unverified Bytecode

Pavel Espitia — Fri, 26 Jun 2026 15:03:11 +0000

Scry lets you talk to any EVM smart contract in plain English. Point it at an address on six chains and ask "what does this do?" or "can I withdraw my funds?" The hard part is not the chat. It is getting a usable interface for a contract when the ABI is hidden behind a proxy, or when there is no verified source at all. Here is how the resolution pipeline works.

The easy case, and why it is rare

If a contract is verified on a block explorer, you fetch its ABI and you are done. The ABI tells you every function, its inputs, and its outputs, and you can build a chat interface on top of it. With the unified Etherscan V2 API, one key covers all the chains Scry supports, which simplifies the fetch considerably.

The trouble is that "verified with a clean ABI" is the minority case for the contracts people actually want to inspect. Two things break it constantly: proxies and unverified bytecode.

Problem 1: the proxy hides the real interface

Most serious protocols use upgradeable proxies. You query the address, the explorer hands you the proxy's ABI, and the proxy's ABI is almost empty: a fallback function and an upgrade mechanism. The functions you actually care about (transfer, withdraw, the protocol logic) live in the implementation contract, which sits at a different address.

So step one of resolution is detecting that you are looking at a proxy and following it to the implementation. The implementation address lives at a known storage slot for standard proxy patterns. For EIP-1967 proxies, it is a specific, deterministic slot:

import { createPublicClient, http } from "viem";

// EIP-1967 implementation slot
const IMPL_SLOT = "0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc";

async function resolveImplementation(client, proxyAddress: `0x${string}`) {
  const raw = await client.getStorageAt({ address: proxyAddress, slot: IMPL_SLOT });
  // The slot holds the implementation address, right-aligned in 32 bytes
  const impl = `0x${raw.slice(-40)}` as `0x${string}`;
  return impl === "0x0000000000000000000000000000000000000000" ? null : impl;
}

If the slot is non-zero, that is the implementation, and that is the address whose ABI you fetch. Scry follows the proxy automatically so the user does not have to know the contract is upgradeable. There are other proxy patterns (UUPS, beacon, transparent), so the resolver checks several known slots before giving up.

Problem 2: no verified source at all

Sometimes there is no verified source anywhere: not on the proxy, not on the implementation. You have bytecode and nothing else. This is where most tools stop and where Scry uses bytecode reconstruction.

Even without source, the bytecode contains the function selectors: the first four bytes of the keccak hash of each function signature, which the contract uses to dispatch calls. A library like whatsabi scans the bytecode, extracts those selectors, and reconstructs a partial ABI:

import { whatsabi } from "@shazow/whatsabi";

async function reconstructAbi(client, address: `0x${string}`) {
  const result = await whatsabi.autoload(address, {
    provider: client,
    // resolve selectors against a signature database to recover names
  });
  return result.abi;
}

The selectors are just four-byte hashes, so on their own they are opaque. But many of them are known: 0xa9059cbb is transfer(address,uint256). Resolving the selectors against a public signature database recovers human-readable names for the common ones, and the rest are presented as raw selectors the user can still call.

Layering the resolution

Put together, the pipeline is a cascade, trying the richest source first:

Is it verified? Use the ABI. Done.
Is it a proxy? Resolve the implementation, then go back to step 1 for that address.
No verified source? Reconstruct the ABI from bytecode selectors.
Resolve selectors against a signature database for readable names.

Each step degrades gracefully into the next. The user gets the best interface available for that contract, and Scry never just throws up its hands because a contract is unverified.

Where the LLM comes in

The resolved ABI is the interface; the LLM is the translator. With a function list in hand, the model maps the user's plain-English question ("can I get my money out?") to the relevant function (withdraw), explains what it does, and tells the user what they would need to call it. The ABI gives the model a precise, structured surface to reason about, which is far more reliable than asking it to guess about an address from raw bytecode.

That is the architecture: deterministic resolution to build the most complete interface possible, then the model on top to make it conversational. The intelligence is in the chat. The hard engineering is in never giving up on a contract just because someone forgot to verify it.

Foundry Fuzzing vs Invariant Testing: When Each One Finds the Bug

Pavel Espitia — Thu, 25 Jun 2026 15:07:46 +0000

Foundry gives you two automated testing tools that sound similar and find very different bugs: property fuzzing and invariant testing. I see people reach for one when they need the other and conclude "fuzzing didn't find anything" when the bug was never in fuzzing's reach. Here is the difference, with the kind of bug each one actually catches.

Fuzzing: random inputs to one function

A fuzz test takes parameters, and Foundry throws hundreds of random values at them, looking for an assertion that breaks:

function testFuzz_depositThenWithdraw(uint256 amount) public {
    amount = bound(amount, 1, 1e24);     // keep inputs in a sane range
    vault.deposit{value: amount}();
    vault.withdraw(amount);
    assertEq(address(vault).balance, 0); // property: deposit+withdraw nets to zero
}

Foundry runs this with many random amount values. If some value breaks the property (an off-by-one in the math, an overflow at a boundary, a precision loss when amount is tiny), it finds the counterexample and shrinks it to the minimal failing input.

Fuzzing is excellent at finding edge cases in a single operation. The boundary value, the zero, the max, the value that triggers a rounding error. It is testing "for all inputs to this function, does this property hold?"

Where fuzzing misses

Fuzzing tests one call (or a fixed sequence you wrote). It does not explore sequences of operations in an order you did not anticipate. The bugs that live in "deposit, then someone else withdraws, then you transfer, then you withdraw again" are sequence bugs, and a single-function fuzz test will never stumble into that ordering.

That is exactly the class of bug that drains protocols: not a bad input to one function, but a bad interleaving of several functions across several actors.

Invariant testing: random sequences across the whole system

Invariant testing flips the model. Instead of fuzzing inputs to one function, Foundry calls many functions in random order with random inputs, across the whole contract, and after every call it checks that a system-wide invariant still holds:

contract VaultInvariants is Test {
    Vault vault;

    function setUp() public {
        vault = new Vault();
        targetContract(address(vault)); // Foundry calls its functions randomly
    }

    // This must be true after ANY sequence of operations
    function invariant_solvency() public view {
        assertGe(address(vault).balance, vault.totalDeposits());
    }
}

invariant_solvency says: the vault's actual balance must always cover what it owes depositors. Foundry now runs thousands of random call sequences (deposits, withdrawals, transfers, in every order it can think of) and checks solvency after each one. If any sequence breaks solvency, you have found a bug that no single-function test would surface.

This is how you catch the "withdraw twice through a reentrant path" or "the accounting drifts after this specific interleaving" bugs. The invariant is the property that should survive any history, and Foundry attacks the history.

Choosing the invariant is the hard part

Writing the test is easy. Choosing the right invariant is the skill. Good invariants are global truths about the system that should never be violated:

Solvency: assets held >= liabilities owed.
Conservation: total supply equals the sum of balances.
Monotonicity: a nonce only increases, never resets.
Access: only authorized roles ever changed a privileged variable.

A weak invariant (one that is trivially true) passes forever and tests nothing. A strong invariant (solvency) is where the real bugs hide, because it constrains the whole system at once.

Handler contracts: making the random calls realistic

Out of the box, invariant testing calls functions with fully random arguments, which often just reverts (you cannot withdraw from an account with no balance). To get useful coverage you write a handler: a wrapper that makes the random calls plausible, tracking ghost state so withdrawals target accounts that actually have balances. The handler is what turns invariant testing from "everything reverts" into "realistic sequences that actually exercise the logic."

contract Handler is Test {
    Vault vault;
    uint256 public ghostDeposited; // track what we've put in

    function deposit(uint256 amount) public {
        amount = bound(amount, 1, 1e22);
        vault.deposit{value: amount}();
        ghostDeposited += amount;
    }
}

You point the invariant suite at the handler, and now the random sequences are sequences of valid-ish operations, which is where real protocols actually break.

The rule of thumb

Reach for fuzzing when the bug would be a bad input to one operation: an overflow, a boundary, a precision error. Reach for invariant testing when the bug would be a bad interaction between operations: a drained vault after a specific call ordering, accounting that drifts over a history.

Most serious protocol bugs are interaction bugs, which is why invariant testing earns its keep. But it costs more to set up (the handler, the right invariant), so fuzzing is the cheaper first pass. Run both. Fuzz the functions, then constrain the system, and let Foundry try to violate the truth you said could never be violated.