DEV Community: Aniket Misra

When Your Security Tool Says "LOOKS SAFE" (TxnLense, Part 2)

Aniket Misra — Sun, 04 Oct 2026 18:17:36 +0000

Part 1 ended on the first transaction I ever ran through TxnLense end to end: an unlimited ERC-20 approval, the single most-cited pattern behind wallet-draining attacks, and the exact scenario the extension exists to catch. It decoded correctly. Function name, spender, amount: all correct, the amount displayed as MAX (unlimited).

The badge across the top said LOOKS SAFE.

This part is about why, what else I found sitting next to it once I started actually reading the code instead of trusting the pipeline I'd just finished verifying, and what a tool like this can and can't honestly claim once you've seen it fail once.

How a verdict gets made

Decoding and risk-flagging are separate stages on purpose. The decoder's only job is to turn a hex blob into structured data: function name, arguments, a list of "token flows" (who sends what to whom). The risk engine never looks at raw calldata. It only looks at what the decoder already produced:

// Rule 1 — unlimited token approval
const approvalFlow = partial.tokenFlows?.find(
  f => f.symbol?.includes('approval') && f.amount === '∞',
)
if (approvalFlow) {
  flags.push({
    level: 'high',
    label: 'Unlimited Approval',
    reason: `You are granting unlimited ${approvalFlow.symbol.replace(' approval', '')} spending rights. …`,
  })
}

Read that rule on its own and it's correct. If a flow exists whose symbol contains "approval" and whose amount is the infinity symbol, flag it high. The question the rule never asks, because it isn't its job to ask, is: did a flow get built at all?

Where the flow comes from

That's the decoder's job, in extractTokenFlows. Before my fix, the approve branch looked like this:

const tokenMeta = KNOWN_TOKENS[to?.toLowerCase()]

if (functionName === 'approve' && tokenMeta) {
  const spenderParam = params.find(p => p.name === 'spender')
  const amountParam = params.find(p => p.name === 'amount')
  if (spenderParam && amountParam) {
    flows.push({
      /* … */
      symbol: `${tokenMeta.symbol} approval`,
      /* … */
    })
  }
}

KNOWN_TOKENS is a hardcoded map, a handful of well-known mainnet addresses to their symbol and decimals. tokenMeta is undefined for anything not on that list, and the && in the if means the entire block, the entire flow, is skipped when it is. Call approve on a token nobody's heard of and this function returns nothing, every time, no matter what the amount is.

Here's the test case I ran it against, from Part 1's mock wallet:

await window.ethereum.request({
  method: 'eth_sendTransaction',
  params: [{ to: FAKE_TOKEN, data: encodeApprove(FAKE_SPENDER, MAX_UINT256) }],
})

FAKE_TOKEN is a made-up address. It was never going to be in KNOWN_TOKENS. The decoder found nothing, tokenFlows came back empty, and the risk rule — correctly, by its own logic — had nothing to find.

Why "found nothing" and "couldn't look" are not the same answer

Rule 1 is written as if an empty result always means "no unlimited approval here." The allowlist gate means an empty result can also mean "I never checked, because I didn't recognize the token." The function returns the same shape either way, so nothing downstream can tell the two apart. The badge collapses them into one label: safe.

That gap is a bigger deal here than it would be in most software, because of who's likely to be on the other side of it. The hardcoded list covers tokens everyone already knows to trust. The dangerous case, almost by construction, is the unfamiliar one: an attacker's own token, or a brand-new deployment nobody's added to any list yet. The allowlist was most likely to fail exactly where the tool mattered most.

The fix, and what I had to check twice

The fix removes the gate and falls back to a generic label when the token isn't recognized:

const tokenMeta = KNOWN_TOKENS[to?.toLowerCase()] ?? {
  symbol: 'Token',
  decimals: 18,
  name: 'Unknown Token',
}

if (functionName === 'approve') {
  // … builds the flow unconditionally now
}

The amount and the spender were always fully decoded; only the pretty symbol was ever in question. Displaying "Token approval" instead of "USDC approval" costs nothing. Returning no flag at all for a genuinely unlimited approval cost everything the feature was built for.

I didn't trust that reasoning on its own, so I ran the fixed function directly, the same way I'd read it:

evaluateRisk({
  tokenFlows: [{ amount: '∞', symbol: 'Token approval', /* … */ }],
})
// → { riskLevel: 'high', riskFlags: [{ label: 'Unlimited Approval', … }] }

evaluateRisk({
  ethFlow: { /* ordinary 0.01 ETH transfer */ },
})
// → { riskLevel: 'safe', riskFlags: [] }

The second call matters as much as the first. A fix that makes everything flag high is just a different kind of broken, so the control case, the same one from Part 1's mock harness, has to still come back clean.

Two more silent failures, found the same way

Once I stopped trusting "it compiled" as a stand-in for "it works," two more problems turned up nearby, both sharing the exact shape of the one above: something fails quietly, and a try/catch or a missing build step hides it from view.

Buffer doesn't exist in a service worker. The function that decodes a transaction's revert reason used Buffer.from(hex, 'hex').toString('utf8') to turn the raw return data into readable text. Buffer is a Node.js global. The background script runs as an actual Manifest V3 service worker, a browser environment, not Node, and Buffer is simply undefined there. Every call threw, every throw landed in a surrounding catch, and the UI fell back to a generic message: "transaction would revert," with no reason. The feature had never once worked, and nothing said so. The fix swaps in TextDecoder, the browser-native equivalent.

The project had never actually been typechecked. vite build uses esbuild to transpile TypeScript, and esbuild strips types without checking them: that's what makes it fast. There was no separate tsc --noEmit step anywhere in the project's scripts, so none of this had ever been verified against the type checker it was written with. Once I added that script and ran it, it surfaced the Buffer issue again, from a different angle: Cannot find name 'Buffer', a declaration-level version of the exact bug above. The fact that both paths pointed at the same line independently is a decent argument that the bug was real rather than a one-off. It also meant window.ethereum's type had never been declared anywhere in the codebase, and vite.config.ts's own Node-only APIs (__dirname, path) were leaking into the same type-checking pass as the browser code, which is the general version of the Buffer mistake: nothing was stopping a Node-only API from being used somewhere it would only ever fail silently at runtime.

None of these three bugs would show up in a demo. They all share the same failure mode: something that looks like a result, isn't flagged as suspicious, and is wrong. A missing flag doesn't look different from an absent one. A caught exception doesn't look different from success. A green build doesn't look different from a checked one. The demo only exercises the paths you decided to click through, and "it compiled" was never actually evidence that any of this worked.

What should actually be on the badge

The deeper issue outlives the specific bug. "LOOKS SAFE" is a single, confident word standing in for two situations that should never share a label:

The decoder understood the call completely, and none of the five active rules fired.
The decoder couldn't fully make sense of the call, so there was nothing to check it against.

A reassuring label is the wrong output for the second case. It isn't a finding, it's the absence of one, and treating absence of evidence as evidence of safety is exactly how an attacker's own unlisted token walked through the version I'd just built with the badge intact.

I haven't shipped a fix for this yet, and I don't want to claim otherwise. The honest version is a tri-state verdict: risky, no known risks found, or couldn't fully evaluate this. Even just renaming the label from "LOOKS SAFE" to "NO KNOWN RISKS FOUND" would be a real improvement with no code change at all, because it stops implying a judgment the tool didn't actually make.

A second asymmetry, caught while writing this post

Rereading the risk rules for this post, rather than just to patch the one bug I already knew about, turned up something I hadn't looked for: the unlimited-amount check only exists for one of the two approval mechanisms TxnLense decodes.

A plain EIP-2612 Permit with the maximum value gets exactly the escalation you'd want:

evaluateRisk({ typedDataType: 'Permit', typedDataMessage: { value: MAX_UINT256 } })
// → riskLevel: 'high', label: 'Unlimited Permit Signature'

A Permit2 PermitSingle with the same maximum amount does not:

evaluateRisk({ typedDataType: 'PermitSingle', typedDataMessage: { details: { amount: MAX_UINT160 } } })
// → riskLevel: 'medium', label: 'Permit2 Signature'

The Permit2 rule flags every Permit2 signature at a flat "medium," with a generic "verify the spender and expiration," regardless of amount. It never reads details.amount at all. An unlimited Permit2 grant, structurally the same risk as the unlimited approval this whole post is about, gets less visual weight than a five-dollar one. I haven't fixed this yet either. It's going in the next pass, and I'm naming it here rather than quietly patching it before anyone noticed, for the same reason as the badge: a post about a tool overstating what it checked shouldn't itself overstate what's already fixed.

One more small thing worth knowing if you read the source: the risk levels are high, medium, low, and safe, and the popup has styling for all four. But every rule that pushes a flag currently sets its level to high or medium explicitly. There's no path through the current rules that produces low — it's reachable in the type and in the UI, not in the logic. Not a bug exactly, since nothing breaks, but worth knowing the fourth state is aspirational right now, not active.

What this can't promise, even once every bug above is fixed

Writing all of this down is also a reasonable time to be honest about the ceiling, not just the bugs under it.

It runs in the same world it's watching. The interception patch lives in the page's own JavaScript context, which Part 1 covered as the reason it can see window.ethereum at all. The flip side is that a sufficiently hostile page shares that same context and could, in principle, detect or interfere with a patch running alongside it. "Informational only, never blocks" lowers the stakes of a false positive. It doesn't make the patch invisible to the page it's sitting on.

It only patches window.ethereum. A newer connection pattern, EIP-6963, lets multiple wallets announce themselves without all of them colliding on that one global. I haven't checked whether a dapp using that pattern exclusively would ever call through the object TxnLense patches, or whether it would route around it entirely. I'm flagging it as an open question rather than a confirmed gap, because I'd rather say "I don't know yet" than quietly assume coverage I haven't verified.

Function names come from a public, user-submitted database. When calldata doesn't decode against a known ABI, the fallback looks up the selector on 4byte.directory, which is editable by anyone. A wrong or malicious submission there would come back as a wrong name here. It's a reasonable fallback for a project at this stage, and it's not infallible in a way worth remembering before trusting an unfamiliar function name at face value.

None of these are reasons not to build the thing. They're the difference between "this extension flags some real risks" and "this extension flags all risk," and that difference is exactly what a badge that just says "LOOKS SAFE" was quietly erasing.

The through-line across both of these posts, and honestly across this whole run of writing about my own bugs, is the same each time: the parts that look finished are the parts I'd stopped checking, not the parts that were actually correct. The fix was never cleverness. It was going back and checking the part I'd already decided was fine.

If you want to look yourself rather than take any of this on faith: github.com/Aniket98Misra/TxnLense.

Intercepting a Wallet from a Browser Extension (TxnLense, Part 1)

Aniket Misra — Sun, 04 Oct 2026 18:12:43 +0000

Every time you sign something, an application asked your wallet to do it through a single JavaScript call, and your wallet showed you its interpretation of that call. Sometimes the interpretation is good. Often it's a hex blob and a confirm button. I wrote about the standards effort to fix this at the source in The End of Blind Signing: ERC-7730, clear signing, wallets and dapps agreeing on a way to describe what a signature does.

TxnLense is the other approach: what can you do today, without waiting for any wallet or dapp to adopt anything? Sit between the two. Read the call as it goes by, decode it, and tell the user in plain language what they're about to authorize.

This is a two-part series. Part 1 is about how interception works in a Manifest V3 extension, and the long, instructive way I got it working, including how I tested a wallet-interception extension on a machine that couldn't run a wallet. Part 2 is about the part I trust least in hindsight: the moment the decoder confidently told me something dangerous looked safe.

What it does, and what it deliberately doesn't

The pipeline is four steps:

Intercept: catch eth_sendTransaction, eth_signTypedData, and eth_signTypedData_v4 calls as the page makes them.
Decode: turn calldata into a function name and named arguments, and typed-data payloads (including Permit2) into something readable.
Flag: run a small set of deterministic rules over the result: unlimited approvals, unlimited permits, high-value transfers, unrecognized functions, Permit2 signatures.
Show: render all of it in the extension popup.

The design decision I care most about is what it doesn't do: it never blocks, alters, or delays the call. The patched function records what it saw and then hands the original arguments to the original wallet function, unmodified. Version 0.1 is informational only.

That's a deliberate choice. A third-party extension with the power to veto a signature is a much heavier thing to ask a user to trust than one that only reads, and a rules-based flagger will have false positives; a false positive that silently blocks a legitimate transaction is a worse failure than a warning the user can read and ignore. Observing is a smaller, more defensible promise, and the code makes it structurally obvious:

return originalRequest(args)   // always. never blocks, never mutates.

Everything hard about this project comes from a much less glamorous problem: getting your code to run in the right place.

The fact that shapes the whole architecture

When a wallet like MetaMask is installed, it injects an object at window.ethereum in the page. Every dapp talks to it through window.ethereum.request({ method, params }). That's the interface (it's specified in EIP-1193), and it's the seam TxnLense hooks: replace request with a wrapper that observes and then forwards.

The catch is that a browser extension's code can run in three different places, and they can't all see the same things:

Where	Can see `window.ethereum`?	Can use `chrome.runtime`?	Good for
The page itself ("MAIN world")	Yes, it's the same JS realm the wallet writes into	No	Patching the provider
Content script ("isolated world")	No, it shares the DOM but gets its own JavaScript globals	Yes	Relaying messages
Service worker	No DOM at all	Yes, plus network access	Decoding, simulation, storage

That middle row is the one that trips everyone. A content script and the page share the same DOM, but they get separate JavaScript worlds, so a variable the page defines is invisible to the content script even though both are "on the page." Isolation is a security feature: it stops a hostile page from reaching into an extension's variables. It's also why a content script's window.ethereum is undefined even when the wallet is sitting right there.

So the job splits along those lines. The provider has to be patched from the page's world, but only the isolated world and the service worker can talk to the extension. Two pieces of code, one message boundary between them:

   PAGE (main world)              CONTENT SCRIPT (isolated)         SERVICE WORKER
   ─────────────────              ─────────────────────────         ──────────────
   dapp calls request()
   patched wrapper ──postMessage──▶ content.js ──sendMessage──▶  decode → flag → simulate
                                        │                              │
                                  store for popup  ◀──────────── response ┘

window.postMessage is the only thing that crosses the page-to-isolated boundary, and chrome.runtime.sendMessage is the only thing that crosses to the service worker. Nothing else connects them. Once you see it as three rooms and two doors, the architecture stops being mysterious. It also tells you exactly what a bug in any one of the rooms will look like from the others: silence.

The first version, and why it couldn't have worked

The version I started with put nearly everything in one content script. It patched window.ethereum, it called chrome.runtime.sendMessage to reach the worker, and to bridge worlds it built a <script> element with inline code as text and appended it to the page, relaying events through a CustomEvent. The manifest declared that one file with "world": "MAIN", so it would run in the page's context.

If you read the table above, that plan has a contradiction in it: the file needs chrome.runtime (isolated world) and window.ethereum (main world) at the same time. No single world offers both. The design leaned on two different tricks to paper over that, an inline script and a manifest flag, and both of them turned out to be wrong for reasons I'd only find out by running it.

Five failures, in order

1. Loading the wrong folder

The first error wasn't even in the interception logic. Loading the project root as an unpacked extension failed with Could not load javascript 'content.js' for content script. The manifest at the root referred to files that existed only in the build output, dist/. Loading dist/ fixed it, but it left two copies of manifest.json in the project that could quietly drift apart, which is a problem I'd meet again in Part 2.

2. The CSP wall

With the extension loaded, I opened the test page and triggered a transaction. Nothing happened: no popup update, no service-worker activity. But the extension's Errors panel had something:

Refused to execute inline script because it violates the following Content
Security Policy directive: "script-src 'self' 'wasm-unsafe-eval'".

That policy is Manifest V3's default: no inline script, only files from the extension itself. The culprit was the inline <script> my content script built from a string. The fix for that was to delete the bridge, which turned out to be solving a problem that doesn't exist: postMessage already crosses between worlds natively, so a CustomEvent relay through injected inline code was never needed.

I made that change, reloaded, and the error disappeared. The extension still did nothing at all.

That was the first useful lesson: the absence of an error is not the absence of a bug. The CSP error had been the loud symptom, and clearing it just exposed the quiet one underneath.

3. Silence, and the decision to instrument

At this point I had a manifest with two scripts, one supposedly running in the page world (inject.js, declared "world": "MAIN") and one relay in the isolated world. No errors anywhere. I checked the popup, the service-worker console, the Errors panel, and the network tab. Nothing.

When you can't tell which of several components is failing, the fix isn't more staring. It's making silence impossible. I rewrote inject.js so it logged at every step: on load, on every poll attempt for window.ethereum, on success, on failure. Then I learned something that cost me a while: code running in the page's world logs to the page's console, not the extension's. I'd been checking every extension console and none of them would ever show it.

Opening DevTools on the test page itself finally showed something:

[txlens] inject.js: file is executing, top of file
[txlens] inject.js: starting to poll for window.ethereum
[txlens] inject.js: poll attempt 0, window.ethereum = undefined
[harness] script block starting
[harness] window.ethereum assigned successfully: {isMetaMask: true, …}
[txlens] inject.js: poll attempt 1, window.ethereum = undefined
…
[txlens] inject.js: poll attempt 20, window.ethereum = undefined
[txlens] inject.js: gave up after 20 attempts, window.ethereum never appeared

The script was running, and running exactly as written. The polling loop even survived the expected race: it started before the page's own script had set the provider, which is normal at document_start. But after the page logged that it had assigned window.ethereum, the extension kept reading undefined for the rest of its two-second window. Typing console.log(window.ethereum) by hand in the console printed the object.

Same name, same page, two different answers.

4. The context dropdown

DevTools has a small dropdown at the top of the Console panel, defaulting to top, that selects which JavaScript context your expressions run in. I'd never had a reason to open it. When I did, it listed top (the page) and, underneath, three separate entries labelled txlens.

I selected each one and ran window.ethereum.__probe = 'hello'. In top, it worked. In every txlens entry:

Uncaught TypeError: Cannot set properties of undefined (setting '__probe')

That's proof. The extension's script wasn't in the page's world. It was in an isolated one, looking at a window that had never heard of the wallet. (I don't know exactly why there were three entries. Presumably one per script or context. It didn't matter: none of them could see the provider.)

5. The actual cause, and the wrong theory I had first

My first theory was that Chromium's MAIN-world support was flaky. When three JavaScript contexts disagree about a global and nothing throws, "browser bug" is a natural conclusion. It was wrong.

The real cause was the machine. I develop on Windows 8.1, where Chrome and Edge both stop at version 109. The manifest-level "world": "MAIN" option shipped in Chrome 111, and older versions silently ignore the key. No warning, no error, no partial support. My "page-world" script had simply been running as an ordinary isolated content script the whole time. That fits every observation: the script executed, the polls ran, the provider was invisible.

There's a symmetry in this that I find funny in hindsight. On my old browser, the original design failed because the flag was ignored. On a modern browser it would have failed differently: once "world": "MAIN" is honored, the file has no chrome.runtime, so the very first chrome.runtime.sendMessage would throw. Same design, opposite failure, same root mistake, which was asking one file to live in two worlds.

The fix: two files, and a `<script>` tag with a `src`

The version that works separates the two jobs completely.

inject.js runs in the page and does only what only the page can do: patch the provider and post a message. No chrome.* calls anywhere in it. (Excerpts here are trimmed for length.)

function interceptProvider() {
  const provider = window.ethereum
  if (!provider || (provider as any).__txlens_patched) return

  const originalRequest = provider.request.bind(provider)

  provider.request = async function (args) {
    const { method, params } = args
    if (PASSTHROUGH.has(method) || !INTERCEPT.has(method)) return originalRequest(args)

    const payload = {
      type: 'ETH_TX_INTERCEPTED',
      interceptType: method === 'eth_sendTransaction' ? 'eth_sendTransaction' : 'eth_signTypedData',
      id: generateId(),
      data: params,
      timestamp: Date.now(),
    }
    window.postMessage({ __txlens: true, payload }, '*')
    return originalRequest(args) // never blocks, never mutates
  }
  ;(provider as any).__txlens_patched = true
}

content.js runs in the isolated world, where chrome.runtime lives. It has two jobs: get inject.js into the page, and relay what comes back (the return path, which stores the decoded result for the popup, is omitted here).

const script = document.createElement('script')
script.src = chrome.runtime.getURL('inject.js')
script.onload = () => script.remove()
;(document.head || document.documentElement).appendChild(script)

window.addEventListener('message', (event) => {
  if (event.source !== window || !event.data?.__txlens) return
  chrome.runtime.sendMessage(event.data.payload) // → service worker
})

And the manifest stops declaring inject.js as a content script at all. Instead it makes it fetchable:

"content_scripts": [
  { "matches": ["<all_urls>"], "js": ["content.js"], "run_at": "document_start" }
],
"web_accessible_resources": [
  { "resources": ["inject.js"], "matches": ["<all_urls>"] }
]

Why does this work when the inline version didn't? A <script src="chrome-extension://…/inject.js"> isn't inline code. It's an external file load, so the CSP has nothing to refuse. And because the page parses and runs that tag, the code lands in the page's real JavaScript world regardless of which Chrome version is running. It doesn't depend on "world": "MAIN", so it works on my Chrome 109 exactly as it does on a current release. That's the older technique, and it ended up being the more portable one.

Two costs come with it. The first is that inject.js loads asynchronously, so it can lose a race with the page. The polling handles a wallet that isn't there yet, but not a dapp that captured a reference to request before the patch landed. The second is that a web-accessible resource can be fetched by any page that matches, so a site can probe for it and learn that TxnLense is installed. Both go on Part 2's list of things this can't hide.

I reloaded, refreshed the test page, clicked a button, clicked the toolbar icon, and the popup showed a decoded approve call for the first time.

Testing an interceptor without a wallet

There was one more constraint worth writing about, because it changed how I tested. Current MetaMask releases require Chrome 123 or newer. My browser tops out at 109. I couldn't run the wallet I was building around.

The workaround came from looking at the seam again. TxnLense doesn't care which wallet is on the other side. It only cares that window.ethereum exists and has a request method. EIP-1193 is the entire contract. Which means anything that implements request is a wallet as far as the extension can tell. So I wrote one:

window.ethereum = {
  isMetaMask: true, // some detection logic checks for this
  selectedAddress: FAKE_ACCOUNT,
  chainId: '0x1',
  async request({ method, params }) {
    log('>> ethereum.request  method=' + method)
    switch (method) {
      case 'eth_requestAccounts': return [FAKE_ACCOUNT]
      case 'eth_sendTransaction': return '0x' + 'ab'.repeat(32)  // fake tx hash
      case 'eth_signTypedData_v4': return '0x' + 'cd'.repeat(65) // fake signature
      default: return null
    }
  },
  on() {}, removeListener() {},
}

Around that mock is a single HTML page with five buttons, each firing one scenario at it:

An approve(spender, uint256.max) call: the unlimited-approval case
A Permit2 PermitSingle typed-data signature with the maximum amount
A native transfer of 5 ETH
Calldata with a selector nothing recognizes
An ordinary 0.01 ETH transfer

The fifth one is a control, and it matters as much as the other four. A flagger that warns on everything isn't cautious, it's broken, and you can only see that if you also feed it something that should pass clean. The harness serves over http://localhost (python -m http.server) rather than as a local file, since extensions need an extra opt-in permission to run on file:// pages.

Two honest caveats about this approach. First: I wish I'd made each button label its own scenario in the popup and the log. I ended up with a list of decoded transactions and no way to tell which button produced which, and I had to work it out from timestamps. Second, and more important: the harness proves the pipeline, not wallet compatibility. A fake provider can't reproduce the quirks of a real one: multiple wallets fighting over window.ethereum, providers that freeze their own methods, injection timing that differs per wallet. I still owe TxnLense a real test on a modern browser with real wallets before I'd claim it works with them.

Three gotchas that each cost me an hour

"Extension context invalidated." After I edited a stylesheet and reloaded the extension, every click on the test page threw this error from content.js. Nothing was wrong with the code. Reloading an extension gives new pages a fresh extension context, but a tab that was already open keeps running the old content script, which now holds a dead connection to a service worker that no longer exists. Refresh the tab after every reload. It's a one-keystroke fix that looks like a catastrophic regression.

The popup won't open itself. I kept waiting for a popup to appear when I triggered a transaction. In Manifest V3 it never will: an extension's popup opens only when the user clicks its toolbar icon, and there's no API to force it. That has a design consequence. Everything the interceptor sees has to be stored so the popup can read it whenever it's opened, because the popup isn't there when the interesting thing happens. It also suggests an obvious next feature: a badge on the toolbar icon when something risky goes by, since a badge is the one thing an extension is allowed to do unprompted.

Logs live where the code lives. Page-world code logs to the page's console; isolated-world code logs to the page's console under the extension's context; the service worker has its own separate DevTools. I lost real time reading the wrong console. When something is silent, check that you're looking at the right room.

What Part 1 leaves out

At the end of all this, the pipe works. A call goes in through a fake wallet, crosses two boundaries, gets decoded in a service worker, and lands in a popup, on a browser old enough that half the modern extension platform doesn't exist.

But "the pipe works" and "the verdict is right" are different claims, and I'd only proven the first. The first decoded result I actually looked at was the unlimited approval, the single most famous wallet-drainer pattern there is, and the one scenario TxnLense exists to catch. The popup opened. It decoded the function correctly. It displayed the spender. It displayed the amount as MAX (unlimited).

And across the top, in reassuring type, it said: LOOKS SAFE.

That's Part 2.

Escaping the Event Loop — A Deep Dive into worker_threads (Part 3/3)

Aniket Misra — Tue, 04 Aug 2026 23:25:00 +0000

In part 1, we built the core stack/microtask/macrotask model. In part 2, we saw how the browser and Node implement that model differently — rendering interleaved with tasks in the browser, libuv's phase-based loop in Node.

Both of those posts share an unspoken assumption: your callbacks are fast. A few milliseconds, do their thing, return, let the loop move on. But what happens when that assumption breaks? What happens when you genuinely need to do slow, CPU-bound work — and there's no I/O to wait on, no callback to defer, just raw computation that has to happen?

That's what this post is about. No amount of clever queue ordering saves you here. You need actual parallelism, and in Node, that means worker_threads.

The problem worker_threads solves

Everything from parts 1 and 2 works because the actual JS execution — the code inside your callbacks — is assumed to be short. The event loop is brilliant at making single-threaded JS feel concurrent when the bottleneck is I/O: waiting on a database, a file read, a network response. While you wait, the thread is free to do other things.

But CPU-bound work is a different beast entirely. Consider this:

function fibonacci(n) {
  if (n < 2) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

const server = require('http').createServer((req, res) => {
  if (req.url === '/fib') {
    const result = fibonacci(40); // this takes a few seconds
    res.end(`Result: ${result}`);
    return;
  }
  res.end('OK');
});

server.listen(3000);

Hit /fib, and for however long that synchronous computation runs, the entire server is frozen. Not just that request — every request. No other client's /OK request gets served, no timers fire, no I/O callbacks run, because the single JS thread is stuck inside fibonacci(40) and the event loop can't do anything until the call stack unwinds.

This is the single most common misunderstanding about Node's concurrency model: async I/O doesn't make your CPU-bound code non-blocking. fs.readFile doesn't block because the actual disk read happens off the JS thread, in libuv's thread pool, and only the (fast) callback runs on the JS thread. But a tight synchronous loop, a big JSON parse, a hash computation, image processing — there's no I/O to hand off. It's just your code, doing math, on the one thread you've got.

You have three tools in Node for genuinely parallel work, and knowing which one to reach for actually matters.

worker_threads vs child_process vs cluster

These get confused constantly because they all sound like "run more stuff at once." They solve different problems.

child_process spawns an entirely separate OS process, potentially running a different program altogether (a shell command, a Python script, another Node script). Full isolation — separate memory space, separate V8 instance. Good for running external programs or when you want maximum isolation (a crash in the child can't take down the parent). Heavier to spin up, and communication happens via serialized IPC (stdin/stdout/message passing) — no shared memory.

cluster is built on top of child_process, specifically for scaling Node servers across multiple CPU cores. It forks multiple copies of your entire Node process, and the OS (or a Node-managed load balancer) distributes incoming connections across them. Great for "I have a web server and want to use all my CPU cores" — but each worker is a full separate process with its own memory, event loop, everything. It's about scaling throughput of independent requests, not about parallelizing a single computation.

worker_threads spawns actual OS-level threads within the same process — lighter weight than a full process, and critically, capable of sharing memory via SharedArrayBuffer. Each worker gets its own V8 instance and its own event loop, so it's still not shared-everything like threads in languages such as Java or C++, but message passing is fast and structured data doesn't need full IPC serialization to a separate process. This is the right tool when you have one chunk of CPU-heavy work you want to offload without blocking the main thread — image processing, cryptographic hashing, parsing a huge file, running a compute-heavy algorithm.

Quick way to decide: scaling a whole server across cores → cluster. Running an external program or needing hard process isolation → child_process. Offloading one CPU-bound task from inside your existing app → worker_threads.

The rest of this post is about that last one.

Anatomy of a worker

A worker is created from the main thread by pointing at a separate JS file:

// main.js
const { Worker } = require('worker_threads');

const worker = new Worker('./worker.js');

worker.on('message', (result) => {
  console.log('Got result:', result);
});

worker.on('error', (err) => {
  console.error('Worker error:', err);
});

worker.on('exit', (code) => {
  if (code !== 0) console.error(`Worker stopped with exit code ${code}`);
});

// worker.js
const { parentPort } = require('worker_threads');

// do some CPU-heavy work here
const result = heavyComputation();

parentPort.postMessage(result);

A few key pieces:

parentPort — the worker's side of the communication channel back to whoever created it. .postMessage() sends data out; listening on parentPort.on('message', ...) receives data in.
workerData — lets you pass initial data into the worker at creation time, instead of messaging it in after startup:

// main.js
const worker = new Worker('./worker.js', {
  workerData: { n: 40 }
});

// worker.js
const { workerData, parentPort } = require('worker_threads');

function fibonacci(n) {
  if (n < 2) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

parentPort.postMessage(fibonacci(workerData.n));

Message passing between main thread and worker uses the structured clone algorithm — the same mechanism postMessage uses in browsers between windows/iframes. It can handle most JS values (objects, arrays, Maps, Sets, dates, even ArrayBuffers by transfer), but not everything — functions and certain non-serializable values can't cross the boundary. Each message is cloned by default, which has a real memory/CPU cost for large payloads — that's part of why SharedArrayBuffer exists, more on that below.

Fixing the frozen server

Let's rewrite the earlier example properly:

// main.js
const http = require('http');
const { Worker } = require('worker_threads');

function runFibWorker(n) {
  return new Promise((resolve, reject) => {
    const worker = new Worker('./fib-worker.js', { workerData: { n } });
    worker.on('message', resolve);
    worker.on('error', reject);
    worker.on('exit', (code) => {
      if (code !== 0) reject(new Error(`Worker exited with code ${code}`));
    });
  });
}

const server = http.createServer(async (req, res) => {
  if (req.url === '/fib') {
    const result = await runFibWorker(40);
    res.end(`Result: ${result}`);
    return;
  }
  res.end('OK');
});

server.listen(3000);

// fib-worker.js
const { workerData, parentPort } = require('worker_threads');

function fibonacci(n) {
  if (n < 2) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

parentPort.postMessage(fibonacci(workerData.n));

Now hitting /fib spins up a worker thread to do the computation, and the main thread's event loop stays completely free to keep serving other requests while it waits for the message event. This is the actual fix — not a clever async trick, but real parallel execution on a separate thread.

Don't spin up a worker per request — use a pool

The example above works, but spawning a brand-new Worker (and its own V8 instance) for every single request is expensive — worker startup isn't free. In any real system, you want a worker pool: a fixed set of long-lived workers that pick up jobs from a queue, so you pay the startup cost once and reuse threads across many tasks.

Here's a reasonably complete pool implementation:

// worker-pool.js
const { Worker } = require('worker_threads');
const os = require('os');

class WorkerPool {
  constructor(workerScript, poolSize = os.cpus().length) {
    this.workerScript = workerScript;
    this.poolSize = poolSize;
    this.workers = [];
    this.freeWorkers = [];
    this.taskQueue = [];

    for (let i = 0; i < poolSize; i++) {
      this._addWorker();
    }
  }

  _addWorker() {
    const worker = new Worker(this.workerScript);
    worker.on('message', (result) => {
      const { resolve } = worker.currentTask;
      worker.currentTask = null;
      resolve(result);
      this._takeNextTask(worker);
    });
    worker.on('error', (err) => {
      const { reject } = worker.currentTask || {};
      if (reject) reject(err);
      // Replace the crashed worker so the pool stays at full size
      this.workers = this.workers.filter((w) => w !== worker);
      this._addWorker();
    });
    this.workers.push(worker);
    this.freeWorkers.push(worker);
  }

  _takeNextTask(worker) {
    if (this.taskQueue.length === 0) {
      this.freeWorkers.push(worker);
      return;
    }
    const { data, resolve, reject } = this.taskQueue.shift();
    worker.currentTask = { resolve, reject };
    worker.postMessage(data);
  }

  runTask(data) {
    return new Promise((resolve, reject) => {
      const freeWorker = this.freeWorkers.pop();
      if (freeWorker) {
        freeWorker.currentTask = { resolve, reject };
        freeWorker.postMessage(data);
      } else {
        this.taskQueue.push({ data, resolve, reject });
      }
    });
  }

  async destroy() {
    await Promise.all(this.workers.map((w) => w.terminate()));
  }
}

module.exports = WorkerPool;

// pool-worker.js
const { parentPort } = require('worker_threads');

function fibonacci(n) {
  if (n < 2) return n;
  return fibonacci(n - 1) + fibonacci(n - 2);
}

parentPort.on('message', (n) => {
  parentPort.postMessage(fibonacci(n));
});

// main.js
const http = require('http');
const WorkerPool = require('./worker-pool');

const pool = new WorkerPool('./pool-worker.js');

const server = http.createServer(async (req, res) => {
  if (req.url === '/fib') {
    const result = await pool.runTask(40);
    res.end(`Result: ${result}`);
    return;
  }
  res.end('OK');
});

server.listen(3000);

Sizing the pool to os.cpus().length is a sensible default — one worker per logical core, so you're not oversubscribing the CPU with more compute-bound threads than you have cores to run them on. This pattern (or a maintained library like piscina, which does essentially this with more polish) is genuinely how you'd offload CPU work in production Node.

SharedArrayBuffer and Atomics — when message passing isn't enough

By default, data sent between the main thread and a worker is cloned. For most use cases that's fine, but for large datasets — a big typed array you want multiple workers reading and writing without copying gigabytes back and forth — cloning becomes the bottleneck itself.

SharedArrayBuffer gives you a chunk of memory that's genuinely shared between threads — no cloning, both sides see the same bytes:

// main.js
const { Worker } = require('worker_threads');

const sharedBuffer = new SharedArrayBuffer(4); // 4 bytes = one Int32
const sharedArray = new Int32Array(sharedBuffer);

const worker = new Worker('./increment-worker.js', {
  workerData: { sharedBuffer }
});

worker.on('exit', () => {
  console.log('Final value:', sharedArray[0]); // both threads touched the same memory
});

// increment-worker.js
const { workerData, parentPort } = require('worker_threads');

const sharedArray = new Int32Array(workerData.sharedBuffer);
Atomics.add(sharedArray, 0, 1);
parentPort.close();

Note the use of Atomics.add rather than sharedArray[0]++. This matters: when multiple threads can touch the same memory simultaneously, plain read-modify-write operations are subject to race conditions — two threads can both read the same old value before either writes back, and one increment gets silently lost. Atomics provides operations (add, sub, compareExchange, load, store, and more) that are guaranteed to be indivisible at the hardware level, so concurrent access doesn't corrupt the value. Atomics.wait and Atomics.notify go further, letting threads actually block and signal each other — a real synchronization primitive, not just safe arithmetic.

This is a genuinely deep topic on its own — safe concurrent memory access is one of the harder problems in any multithreaded system, not a JS-specific quirk — so treat this section as "know it exists and roughly what it's for," not a complete guide. Most real workloads are well served by message passing through a pool; reach for SharedArrayBuffer specifically when you've profiled and confirmed that cloning large data is the actual bottleneck.

When to actually reach for worker_threads

Worth being honest about the tradeoffs before you reach for this in your own code:

Worker startup has real cost. Spinning up a V8 instance per thread isn't free — this is exactly why pooling matters for anything beyond a one-off script.
Not everything benefits. If your bottleneck is I/O (database calls, network requests, file reads), workers don't help — that's exactly what the async event loop from parts 1 and 2 already handles well, without the overhead of a thread.
Message passing has a cost too. For small payloads it's negligible; for large ones, either restructure to send less data or use SharedArrayBuffer.
Debugging is harder. Errors in a worker don't naturally propagate the way synchronous exceptions do — you have to explicitly listen for 'error' events, and stack traces across threads are less convenient to work with.

The honest heuristic: profile first. If your server is slow because it's waiting on a database, adding worker threads won't fix anything — that's an I/O problem, and the event loop already handles it well. Worker threads earn their complexity specifically when you've identified genuine CPU-bound work — a synchronous computation heavy enough to visibly block the main thread — and optimizing the algorithm itself isn't enough.

Tying the series together

Three parts, one throughline:

Part 1 gave you the spec-level model — stack, microtask queue, macrotask queue, and the rule that microtasks always drain first.
Part 2 showed that model isn't implemented identically everywhere — the browser interleaves it with rendering, Node runs it through libuv's ordered phases, and Node adds process.nextTick() as a queue-jumper the browser doesn't have.
Part 3 showed the model's actual limit — a single thread, no matter how cleverly you schedule callbacks on it, can't parallelize genuine CPU-bound work. worker_threads is Node's way out of that constraint.

Put together, this is really the full picture of "how does async JS work" — from the queue ordering that decides what runs next, to the runtime-specific machinery underneath it, to the point where you need real threads instead of clever scheduling. If you made it through all three, you're in a genuinely small group of JS developers who could actually explain why setImmediate and setTimeout(fn, 0) race unpredictably at the top level of a script, or why a recursive .then() chain can freeze a browser tab without ever blocking the call stack.

That's the kind of understanding that turns "the event loop is confusing" into "the event loop is just a queue, some phases, and a very specific set of rules about what runs first" — which, at the end of the day, it is.

Browser vs Node — Where the Event Loop Actually Diverges (Part 2/3)

Aniket Misra — Tue, 04 Aug 2026 18:21:11 +0000

In part 1, we built the shared mental model: call stack, microtask queue, macrotask queue, and the rule that microtasks fully drain before the next macrotask runs. That model is spec-level JavaScript behavior — but it's not the whole story once you actually run code.

The event loop isn't part of the JS language spec. It's part of the host environment — the browser or Node — and each one implements it differently around that shared core. This is the post most "event loop" explainers skip, because it means going past the diagram and into how each runtime is actually built.

The browser: event loop meets rendering

In a browser, the event loop isn't just juggling callbacks — it's also responsible for keeping the page visually responsive. That means rendering has to get a turn too, and the browser has to decide when.

Here's the roughly accurate sequence per loop iteration:

Execute one macrotask (a click handler, a setTimeout callback, a network event, whatever's next in the queue)
Drain the entire microtask queue
Maybe render a frame — the browser doesn't render after every single task; it tries to hit ~60fps and will batch work between paints
Go back to step 1

The "maybe render" part is where two APIs come in that don't exist in Node at all:

requestAnimationFrame(callback) — schedules a callback to run right before the next repaint. It's not a macrotask or microtask in the queue sense — it's tied directly to the rendering pipeline. Use it for anything visual (animations, DOM measurements) instead of setTimeout, because it's synced to when the browser is actually about to paint, not an arbitrary delay.

requestIdleCallback(callback) — schedules a callback to run when the browser is idle, after layout and paint, with a deadline. Meant for low-priority work you don't want competing with rendering — analytics, prefetching, non-urgent DOM updates.

Here's the key interaction that's easy to miss: microtasks can starve rendering. If a promise chain keeps queueing more microtasks, the browser can't get to the paint step, because microtasks always drain fully before rendering gets a turn. This is a real, debuggable performance bug — a runaway .then() chain can visibly freeze a page even though "nothing is blocking the main thread" in the traditional sync-loop sense.

function recursiveMicrotask() {
  Promise.resolve().then(recursiveMicrotask);
}
recursiveMicrotask();
// Page becomes unresponsive — not because the stack is blocked,
// but because the microtask queue never empties long enough for a paint.

Compare that to a setTimeout-based recursive loop — because each iteration is a separate macrotask, the browser gets a chance to render between them.

Node: no rendering, but a much more structured loop

Node doesn't render anything, so it doesn't need the "maybe paint" logic. Instead, it's built on libuv, a C library that gives Node its event loop, thread pool, and async I/O. libuv organizes the loop into distinct phases, each with its own FIFO queue of callbacks. This is a meaningfully different shape from the browser's single task queue.

The phases, in order, each loop tick:

timers — runs callbacks scheduled by setTimeout / setInterval whose threshold has elapsed
pending callbacks — executes I/O callbacks deferred from the previous loop iteration (some system-level TCP errors, etc.)
idle, prepare — internal use only
poll — the big one: retrieves new I/O events, executes I/O-related callbacks (almost everything — file reads, network requests). Node will block here waiting for new events if there's nothing else scheduled
check — setImmediate() callbacks run here, specifically after poll
close callbacks — e.g. socket.on('close', ...)

Then it loops back to timers.

Between every single callback — not just between phases, but between individual callbacks within a phase — Node drains the microtask queue. Same drain-fully rule as the browser, just applied at a finer grain because there's no rendering to interleave with.

`process.nextTick()` — Node's queue-jumper

Node has a queue that doesn't exist in the browser at all: process.nextTick(). Despite the name, it doesn't queue for "next tick" of the event loop — it runs before microtasks, after the current operation finishes, no matter what.

Priority order in Node, after any synchronous code completes:

process.nextTick() queue (fully drained)
Promise microtask queue (fully drained)
Next macrotask/phase callback

setTimeout(() => console.log('timeout'), 0);

process.nextTick(() => console.log('nextTick'));

Promise.resolve().then(() => console.log('promise'));

console.log('sync');

Output: sync, nextTick, promise, timeout

nextTick beats the promise every time, because Node checks and drains the nextTick queue first, and — same recursion risk as the microtask-starvation example above — a recursive process.nextTick() call can starve I/O entirely, since Node won't proceed past it to the poll phase.

`setImmediate()` vs `setTimeout(fn, 0)` — the ambiguous one

This is the example that shows up in almost every Node interview, and the honest answer is: it depends on where you call it from.

setTimeout(() => console.log('timeout'), 0);
setImmediate(() => console.log('immediate'));

Run this at the top level of a script, and the order is not guaranteed — it depends on process startup timing, specifically whether the timers phase's threshold has already elapsed by the time the loop starts. You'll see it flip between runs.

But inside an I/O callback, the order is deterministic:

const fs = require('fs');

fs.readFile(__filename, () => {
  setTimeout(() => console.log('timeout'), 0);
  setImmediate(() => console.log('immediate'));
});

Output is always immediate, then timeout. Why? Because fs.readFile's callback runs in the poll phase. From there, the loop moves to check next — where setImmediate lives — before it wraps back around to timers. The phase order guarantees it here, where at the top level there's no such guarantee.

This is a genuinely useful thing to internalize: setImmediate means "run in the check phase, this loop iteration," while setTimeout(fn, 0) means "run in the timers phase, next time the loop gets there" — and those are different guarantees depending on what phase you're currently in when you schedule them.

Side-by-side: browser vs Node

Concept	Browser	Node
Underlying engine	V8 (Chrome), SpiderMonkey (Firefox), etc.	V8 + libuv
Queue structure	Single task queue + microtask queue	Multiple phase-specific queues (libuv) + microtask queue
Rendering concern	Yes — interleaved between tasks	No rendering at all
`setTimeout(fn, 0)`	Runs as next macrotask, after microtasks drain	Runs in the timers phase, next time loop reaches it
`setImmediate()`	Doesn't exist	Runs in the check phase
`process.nextTick()`	Doesn't exist	Runs before microtasks, after current operation
Idle/low-priority work	`requestIdleCallback()`	No direct equivalent — usually just `setImmediate()` or offloading
Animation timing	`requestAnimationFrame()`	No equivalent — no rendering to sync to
I/O model	Web APIs (fetch, XHR, DOM events)	libuv (thread pool for fs, async for network)

What carries over, and what doesn't

The stack/microtask/macrotask model from part 1 is real in both environments — that part's spec-driven and doesn't change. But the shape of the macrotask side is genuinely different: the browser has one queue and a rendering step to juggle; Node has an ordered set of phases with distinct semantics per phase, plus process.nextTick() sitting in front of everything.

If you've been assuming "the event loop" is one universal thing you can reason about the same way in a React component and an Express handler, this is usually where that assumption breaks — and where subtle bugs (starved I/O from recursive nextTick, or a setTimeout-vs-setImmediate race at startup) actually come from in production code.

Coming up next

Both of these models assume your callbacks are fast. But what happens when you genuinely have CPU-heavy work — image processing, large computations, parsing — that can't be broken into tiny async chunks? No amount of clever queue ordering saves you if a single synchronous function blocks the thread for 500ms.

Part 3 covers Node's answer to that: worker_threads — real OS-level threads, how to actually use them, and when reaching for a worker beats just optimizing your algorithm.

The JS Event Loop — Core Mental Model (Part 1/3)

Aniket Misra — Tue, 04 Aug 2026 18:13:49 +0000

JavaScript is single-threaded. One call stack, one thing happening at a time. And yet your code fetches data, sets timers, listens for clicks, and handles I/O — all without blocking. How?

The answer is the event loop, and it's one of those concepts every JS developer thinks they understand until someone asks them to predict the output of five nested setTimeout and Promise calls.

This is part 1 of a 3-part series:

The core event loop model (this post)
Where Node and the browser actually diverge
Escaping the event loop with worker_threads

Let's build the mental model properly.

JS is single-threaded — so what's actually running your async code?

The JS engine (V8, SpiderMonkey, etc.) only executes one thing at a time on the call stack. There's no multithreading inside the engine itself.

But the runtime around the engine — the browser or Node — provides extra machinery: Web APIs in the browser (timers, DOM events, fetch), or C++ APIs via libuv in Node (timers, file I/O, network). These run outside the JS thread. When they finish, they don't just barge into your running code — they queue up a callback to be run later.

That queueing and "run later" part is the event loop's job.

The three pieces: stack, queue, loop

Call stack — where synchronous code executes, frame by frame. If a function calls another function, it stacks. When a function returns, it pops.

Queue(s) — where callbacks wait after some async operation completes. There isn't just one queue (more on that in a second).

Event loop — a simple, repeating check: "Is the call stack empty? If yes, take the next thing from a queue and push it onto the stack."

That's genuinely most of it. The complexity comes from which queue goes first.

Macrotasks vs microtasks

This is the part that trips people up, so let's be precise.

Macrotasks (aka "tasks") include:

setTimeout / setInterval callbacks
I/O callbacks
UI rendering-related callbacks (browser)

Microtasks include:

Promise.then / .catch / .finally callbacks
queueMicrotask()
async/await continuations (they're sugar over promises)

The rule that matters: after every single macrotask, the event loop fully drains the microtask queue before it does anything else — including before rendering a frame or running the next macrotask.

Not "checks it once." Drains it completely. If a microtask queues another microtask, that runs too, before moving on.

The classic gotcha, explained properly

console.log('1');

setTimeout(() => console.log('2'), 0);

Promise.resolve().then(() => console.log('3'));

console.log('4');

Try to predict the order before reading on.

Here's what happens, step by step:

console.log('1') runs synchronously → prints 1
setTimeout(...) hands its callback off to the runtime's timer API and registers a macrotask for later — even with a 0ms delay, it doesn't run immediately
Promise.resolve().then(...) queues a microtask
console.log('4') runs synchronously → prints 4
Call stack is now empty. Event loop checks the microtask queue first → runs it → prints 3
Microtask queue is empty. Event loop moves to the macrotask queue → runs the timeout callback → prints 2

Output: 1, 4, 3, 2

The part people get wrong is assuming setTimeout(fn, 0) means "run next." It doesn't mean "run next" — it means "run next macrotask turn," and microtasks always cut the line first.

Why this ordering exists at all

It's not arbitrary. Microtasks are meant for finishing up work that's already in flight — resolving a promise chain, reacting to something that just happened — before the system moves on to genuinely new, separately-scheduled work like a timer firing or an I/O event arriving. It keeps related async logic coherent and predictable, rather than letting it get interleaved with unrelated queued tasks.

Quick check — predict the output

console.log('start');

setTimeout(() => console.log('timeout'), 0);

Promise.resolve()
  .then(() => console.log('promise 1'))
  .then(() => console.log('promise 2'));

console.log('end');

Drop your answer in the comments before scrolling through devtools to check — this is exactly the kind of ordering that gets asked in interviews, and exactly the kind of bug that shows up in real async code when you assume timers run "immediately."

Answer

start, end, promise 1, promise 2, timeout

Both .then() callbacks are microtasks and both drain before the macrotask queue is touched — even though the second .then() is only queued once the first one runs.

What's next

This model — stack, microtask queue, macrotask queue, drain-before-next-task — is the shared spec-level behavior both browsers and Node implement. But they don't implement the runtime around it the same way.

Browsers have to interleave this with rendering. Node runs on libuv with distinct phases (timers, I/O, setImmediate, close callbacks) and has its own microtask-like queue via process.nextTick() that jumps the line even ahead of promises.

That's where things get genuinely different — and where most "event loop" explanations stop short. Part 2 goes there.

Before Solana Went Native: What the EVM Actually Is (And Why It Was Built to Be Slow)

Aniket Misra — Mon, 13 Jul 2026 18:04:17 +0000

To understand why Solana's decision to repurpose BPF was radical, you first need to understand what it was radical against. That's the Ethereum Virtual Machine — the thing every other "VM for smart contracts" design, Solana included, is implicitly arguing with.

The EVM isn't slow because Ethereum's engineers were careless. It's slow because of a set of design choices that made total sense in 2014, when the problem being solved wasn't "how do we get 50,000 TPS" — it was "how do we get a global network of mutually distrusting strangers to agree on the exact same computation, byte for byte, forever." Every property that makes the EVM feel heavy today is downstream of that one requirement.

This is the prequel to a piece I wrote on how Solana re-engineered a Linux kernel packet filter into its execution layer. Before we get to what Solana did differently, here's what it was different from.

1. A Stack Machine, Not a Register Machine

The EVM is a 256-bit stack-based virtual machine. There are no general-purpose registers. Every operation — arithmetic, comparisons, memory access — pushes and pops values from a stack, one instruction at a time.

PUSH1 0x05
PUSH1 0x03
ADD

That's the entire bytecode for "5 + 3." No register allocation, no scheduling — the EVM interprets it top to bottom, exactly as written. This is also why Solidity compiles down to something conceptually close to this, opcode by opcode, rather than to a register-mapped instruction set the way a Rust program compiling to BPF does.

The 256-bit word size isn't an accident either — it matches the output width of Keccak-256, the hash function baked into almost everything Ethereum does (addresses, storage slots, opcodes like SHA3). The VM's fundamental data type was chosen to fit the cryptography, not the hardware.

Compare that to a register machine like BPF or SBF, where the instruction set is designed to map closely to what a real CPU already does. The EVM was never trying to be fast on real silicon. It was trying to be unambiguous — every implementation, on every machine, computing the exact same stack transitions.

2. Interpreted, All the Way Down

There's no JIT. No AOT compilation to native code. Every EVM opcode, on every node, for every transaction, gets interpreted at runtime, instruction by instruction, by whatever client software that node happens to run (Geth, Nethermind, Besu — doesn't matter, they all have to agree).

This is a deliberate constraint, not an oversight. If clients were free to JIT-compile bytecode to native machine code, you'd be trusting each client's compiler to preserve exact semantics across compilation — including edge cases like integer overflow behavior and gas accounting quirks. One divergent optimization and the network forks. Interpretation is slow, but it's slow in a way that's trivially auditable: the reference behavior is the implementation.

Some newer EVM implementations do experiment with JIT compilation for performance, but the base protocol was never designed assuming it — correctness came first, speed was whatever was left over.

3. Gas: Metering Before Execution, Not Verification Before Execution

The EVM has no static verifier checking that your bytecode terminates before it runs — there's no equivalent of eBPF's compile-time proof-of-termination. Instead, every single opcode has a fixed gas cost, charged as execution proceeds. Run out of gas, execution halts immediately and any state changes revert.

function withdraw(uint amount) public {
    require(amount <= balances[msg.sender], "insufficient balance");
    balances[msg.sender] -= amount;
    payable(msg.sender).transfer(amount);
}

Every line here costs gas — SLOAD to read balances[msg.sender], SSTORE to write it back, CALL to send funds. The sender pre-pays an upper bound before the transaction even starts, and unused gas gets refunded. This is a fundamentally different safety model than a verifier: instead of proving a program can't misbehave, you make misbehaving economically self-limiting. An infinite loop doesn't hang the network — it just burns through the caller's gas and reverts, at their expense.

4. Account-Based State and Why Everything Runs in Order

Ethereum's state is a giant key-value mapping — accounts to balances, contract storage slots to values — represented as a Merkle Patricia Trie so any node can cryptographically prove the current state root. Crucially, a transaction doesn't declare up front which storage slots it's going to touch. It just runs, and reads/writes whatever it wants as it goes, including calling into other contracts that touch state you couldn't have predicted ahead of time.

That's the detail that quietly determines Ethereum's entire concurrency story. If you don't know in advance what a transaction will touch, you can't safely run two transactions at once without risking a race on shared state. So the EVM, as a base protocol, executes transactions strictly sequentially, one at a time, in block order. Parallel execution research exists (both inside and outside core Ethereum client teams), but it's an optimization bolted on after the fact, not a property the VM was built around.

This is precisely the constraint Solana's Sealevel runtime sidesteps — by requiring transactions to declare their account access lists upfront, Solana's runtime can prove non-overlap before execution and schedule accordingly. That's not a coincidence; it's a direct response to this exact bottleneck.

Why It's Built This Way

None of this is Ethereum "doing it wrong." A stack machine with no JIT, gas-metered instead of statically verified, sequential by default — every one of these was the correct trade-off for a network whose founding problem was trustless consensus among strangers, not raw throughput. Determinism and auditability were the product. Speed was never the spec.

That's exactly the gap Solana's architects looked at and decided to close from a completely different direction — not by making a better stack machine, but by throwing the stack-machine model out and grabbing a register-based, hardware-native VM that Linux had already spent two decades optimizing. What that actually involved — stripping the kernel verifier, zero-copy account access, AOT compilation to native code, and the account-declaration trick that unlocks parallelism — is the subject of the piece this one precedes.

If you haven't read it yet: From Packet Filter to High-Performance Execution Layer: How Solana Re-Engineered BPF.

Kill the Server: Why Holepunch Threw Away Node.js and Built 'Bare'

Aniket Misra — Sat, 11 Jul 2026 03:07:00 +0000

When the Holepunch team set out to build Pear—a decentralized, peer-to-peer application runtime—they started with the obvious choice: Node.js.

Node is the undisputed king of JavaScript outside the browser. It has a massive ecosystem, a battle-tested asynchronous event loop (libuv), and the raw execution speed of Google's V8 engine. It seemed like the perfect foundation for a P2P stack.

But as they dug deeper into cross-platform routing, NAT traversal, and mobile embedding, they hit a fundamental architectural roadblock: Node.js makes too many assumptions, and the biggest assumption it makes is that you are running a server.

Node was built for the data center. It carries decades of legacy APIs (http, net, tls) that are tightly coupled to centralized, client-server web architecture. When you want to build a purely peer-to-peer, serverless network where devices connect directly via a Distributed Hash Table (DHT), all of that built-in Node bloat becomes dead weight.

So, they did what any obsessive systems engineering team does. They stripped Node down to its studs, threw away the bloated standard library, and built Bare.

Here is a technical look at the Bare runtime, and why throwing away Node’s HTTP assumptions is the key to true P2P applications.

1. Deconstructing the Runtime: What is Bare?

At its core, Bare is a minimalist JavaScript runtime designed specifically for desktop, mobile, and IoT embedding.

It keeps the best parts of Node's foundational architecture but aggressively decouples the JavaScript engine from the system APIs.

[ Traditional Node.js Stack ]        [ The Bare Runtime Stack ]
┌─────────────────────────┐          ┌─────────────────────────┐
│     User Application    │          │     User Application    │
├─────────────────────────┤          ├─────────────────────────┤
│ Node Standard Library   │          │     Userland Modules    │
│ (http, fs, net, crypto) │          │ (HyperDHT, Hyperdrive)  │
├─────────────────────────┤          ├─────────────────────────┤
│    Node C++ Bindings    │          │           Bare          │
├────────────┬────────────┤          ├────────────┬────────────┤
│     V8     │   libuv    │          │    libjs   │   libuv    │
└────────────┴────────────┘          ├────────────┴────────────┤
                                     │V8/ QuickJS / JerryScript│
                                     └─────────────────────────┘

Notice the key difference at the bottom of the stack: libjs.

Node is rigidly bound to Google’s V8 engine. Bare abstracts the JavaScript engine behind a C-API wrapper called libjs. This is a massive systems-level advantage. While Bare runs V8 by default for desktop performance, libjs allows developers to swap out the engine entirely. If you are deploying a P2P application to a highly constrained LTE router or a microcontroller, you can swap V8 for lightweight engines like QuickJS or JerryScript without changing the core runtime architecture.

2. The Missing Standard Library (A Feature, Not a Bug)

If you install Bare and try to spin up a quick web server, it will fail:

// This works in Node. It fails in Bare.
const http = require('http'); 
// Error: Cannot find module 'http'

Bare intentionally ships with almost nothing. There is no http. There is no net. There is no crypto.

Why? Because in a true peer-to-peer architecture, standard HTTP is an anti-pattern. If you rely on http, you are relying on DNS routing, centralized Certificate Authorities (TLS), and exposed public IP addresses.

Instead of forcing a heavy standard library into the binary, Bare leaves feature implementation entirely to userland modules. The runtime provides only three core primitives:

1.A module system (with bidirectional CJS and ESM interoperability).

2.A native addon system (for linking low-level C/C++ libraries).

3.Lightweight threads (with SharedArrayBuffer support).

Everything else is imported a-la-carte. When you want to build a network connection in Bare, you don't use http. You use Holepunch's hyperdht, utilizing cryptographic keys instead of IPs.

3.Bare-Metal Embedding (Desktop to Mobile)

Node is notoriously difficult to embed cleanly into mobile applications. If you want to run a Node instance inside an iOS app, you end up wrestling with massive binaries, battery drain, and messy IPC (Inter-Process Communication) bridges.

Because Bare shed the standard library, its memory footprint is drastically reduced. It treats mobile as a first-class citizen.

Through Bare Kit, developers can spin up "worklets"—isolated Bare threads running directly inside native mobile frameworks (SwiftUI for iOS, or Android Services).

// Spawning a Bare worklet for background P2P sync
import { Worklet } from 'bare-kit'

const syncThread = new Worklet('/hyperdrive-sync.js')

syncThread.on('message', (msg) => {
  console.log('Mobile UI received state update from P2P swarm:', msg)
})

syncThread.postMessage({ command: 'START_SYNC' })

This allows a React Native or Swift frontend to offload all the heavy lifting—DHT routing, UDP hole punching, and data replication—to a highly efficient, native background thread that won't freeze the mobile UI.

The Takeaway: Stop Building Servers

When you look at Bare, you realize that the Node.js architecture we’ve been using for 15 years has subtly brainwashed us. We assume that writing backend JavaScript inherently means writing server logic.Bare proves that JavaScript can be used for something far more resilient. By stripping away the bloated legacy of the Web2 data center, Holepunch has created a runtime that actually belongs on the edge. It forces you to stop thinking about endpoints and status codes, and start thinking about swarms, peers, and cryptographic tunnels. If you want to build systems that governments can't block and cloud providers can't crash, you have to kill the server. Bare is the runtime designed to do exactly that.

The Dark Art of UDP Hole Punching: How to Build a Serverless Web

Aniket Misra — Fri, 10 Jul 2026 19:57:35 +0000

If you want to build a truly decentralized application—one that doesn't rely on AWS, Vercel, or a centralized RPC node—you immediately run into a brick wall of network physics.

You want User A to talk directly to User B.
The problem? Neither of them has a public IP address.

Because we ran out of IPv4 addresses decades ago, ISPs placed almost every consumer device on earth behind a NAT (Network Address Translation) router. NAT is a one-way mirror. You can send outbound requests to a public server, and the router will allow the response back in. But if an external device tries to initiate a connection with you, the NAT drops the packet immediately. It assumes it is hostile.

This single piece of hardware killed the peer-to-peer internet.

To build a sovereign, serverless application layer (like what Holepunch and Pear are doing), you have to bypass the NAT. You have to trick the router into letting inbound traffic through. This technique is called UDP Hole Punching.

Here is the architectural deep dive into how it works, and how modern cryptographic routing makes it scalable.

1. The Mechanics of the "Hole Punch"

Unlike TCP, which requires a rigid 3-way handshake, UDP is connectionless. It just fires raw datagrams into the void.

When your laptop sends a UDP packet to an external server, your NAT router intercepts it, temporarily maps your local IP/port to its public IP/port, and adds a record to its State Table. For the next 30 to 60 seconds, it leaves a "hole" open. If any UDP packet hits that specific public port, the NAT assumes it is a valid response and forwards it to your laptop.

If Alice and Bob are both behind strict NATs, they cannot ping each other. But if they coordinate, they can exploit the state table.

The Signaling Phase: Alice and Bob both connect to a third-party relay to discover their own respective public IP addresses and ports.
The Simultaneous Strike: Alice fires a UDP packet directly at Bob's public IP. Bob fires a UDP packet directly at Alice's public IP.
The Rejection: Alice's first packet hits Bob's router and gets instantly dropped, because Bob's router hasn't opened a hole yet.
The Breakthrough: But when Alice fired that packet, her router opened a hole, expecting a response from Bob's IP. A millisecond later, Bob's packet arrives at Alice's router. Because the IP and port match the state table, the router lets it through.

The hole is punched. Alice and Bob now have a direct, peer-to-peer data stream.

[Alice's Laptop] ──► (Local Port 3000)
       │
 [Alice's NAT] ────► Opens Hole: Public IP A, Port 50000 
       │ 
       ▼ (Direct UDP Stream) ▲
       │                     │
 [Bob's NAT] ◄─────► Opens Hole: Public IP B, Port 60000
       │
[Bob's Laptop] ◄─── (Local Port 4000)

2. The Holepunch Architecture: Cryptographic Routing

In traditional WebRTC architecture, the "Signaling Phase" requires centralized infrastructure: STUN servers (to find your public IP) and TURN servers (to relay traffic if hole punching fails). If you use STUN/TURN, you are back to relying on centralized cloud providers.The brilliance of the Holepunch stack (and its underlying engine, Bare) is that it throws out STUN and TURN entirely. Instead, it uses HyperDHT, a Kademlia-based Distributed Hash Table. In this architecture, your public cryptographic key is your IP address.

1.When Alice boots her application, she joins the DHT. The decentralized nodes in the DHT naturally observe her public IP and port, effectively doing the job of a STUN server without corporate ownership.

2.She announces her 32-byte public key (ed25519) to the swarm.
3.When Bob wants to connect, he doesn't query a DNS server. He searches the DHT for Alice's public key.
4.The DHT nodes coordinate the UDP hole punch. Once the connection is established, Alice and Bob perform a Noise IK handshake to generate a direct, end-to-end encrypted tunnel.

Visit documentation

3. The Code: Bare-Metal P2P

Because Holepunch uses the Bare runtime (stripping away Node.js's heavy HTTP server legacy), establishing this encrypted, serverless connection takes mere lines of code.

Here is what establishing a serverless, hole-punched P2P connection looks like using hyperdht:
Alice (The Target):

import DHT from 'hyperdht'

const node = new DHT()
const keyPair = DHT.keyPair() // Cryptographic identity

const server = node.createServer(socket => {
  console.log('Direct encrypted P2P stream established!')

  // The socket is a standard duplex stream. 
  // No server required.
  process.stdin.pipe(socket).pipe(process.stdout)
})

await server.listen(keyPair)
console.log('Listening on Public Key:', keyPair.publicKey.toString('hex'))

Bob (The Dialer):

import DHT from 'hyperdht'

const node = new DHT()
const alicePubKey = Buffer.from('<ALICE_PUBLIC_KEY_HEX>', 'hex')

// The DHT locates Alice, orchestrates the UDP hole punch, 
// and establishes the Noise IK encrypted tunnel natively.
const socket = node.connect(alicePubKey)

socket.on('open', () => {
  console.log('Punched through NAT. Connected to Alice.')
})

process.stdin.pipe(socket).pipe(process.stdout)

The Unstoppable Web

By utilizing UDP hole punching and a cryptographic DHT, you remove the ultimate single point of failure in modern architecture: the data center.

You cannot DDoS a network where every user is dynamically routing traffic. You cannot de-platform an application that has no static IP to block. When we talk about true decentralization, it isn't just about putting a financial ledger on a blockchain; it is about reclaiming the physical routing layer of the internet.

The Tether Paradox: Shitty ERC-20s, OpenZeppelin, and the Unstoppable Web

Aniket Misra — Fri, 10 Jul 2026 18:24:31 +0000

I have a confession to make. When I first saw that Tether—the behemoth behind the $110 billion USDT stablecoin—was the primary financial backer of Holepunch, Keet, and the Bare JavaScript runtime, my brain short-circuited.

I struggled with the cognitive dissonance. Why? Because if you have ever written a smart contract that interacts with USDT on Ethereum Mainnet, you know it is an absolute nightmare.

Before we can talk about Tether’s brilliant vision for a decentralized, serverless future, we have to talk about the trauma they inflicted on a generation of Solidity developers.

1. The Original Sin: USDT is not actually an ERC-20

When you are deep in protocol-level engineering, you rely on standards. EIP-20 explicitly states that a token's transfer and transferFrom functions must return a boolean value to indicate success or failure.

// The standard EIP-20 Interface
interface IERC20 {
    function transfer(address to, uint256 amount) external returns (bool);
}

Tether completely ignored this. When they deployed the USDT contract, they omitted the return value entirely. Their functions return void.

// The actual USDT Mainnet Implementation (simplified)
function transfer(address to, uint value) public {
    // ... logic ...
    // Notice: No return statement.
}

If you blindly write a vault or a swap contract using the standard IERC20 interface to move USDT, your transaction will seamlessly execute the logic, move the funds, and then violently revert at the very last microsecond.

Why? Because modern Solidity uses a strict ABI decoder. When your contract calls USDT.transfer(), the EVM executes a low-level CALL. When the call finishes, Solidity checks the RETURNDATASIZE. Since it expects a bool (32 bytes), but USDT returns absolutely nothing (0 bytes), the decoder panics and reverts the entire transaction.

For years, the only way to build DeFi safely with USDT has been to wrap it in OpenZeppelin's SafeERC20 library, which uses low-level assembly to explicitly check the return data size and bypass the strict ABI decoding:

import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";

contract Vault {
    using SafeERC20 for IERC20;
    IERC20 public usdt;

    function deposit(uint256 amount) external {
        // We have to use safeTransferFrom because USDT is non-compliant
        usdt.safeTransferFrom(msg.sender, address(this), amount);
    }
}

So, imagine my skepticism. The company that deployed a non-compliant proxy contract that breaks standard EVM interfaces is now funding the most radical, bare-metal, peer-to-peer web infrastructure of the decade?

It felt like a bad joke. Until I looked at the system architecture.

2. The Geopolitics of Decentralized Routing

Tether isn't funding Holepunch out of the goodness of their hearts. They are doing it out of existential necessity.

Look at the architectural dependency graph of the modern financial system. Tether has achieved incredible product-market fit; USDT is the shadow dollar of the global south. But no matter how secure the Ethereum, Tron, or Solana blockchains are, the access layer to those blockchains is controlled by a tiny cartel of Web2 tech monopolies.

[ Traditional Web3 Access Flow ]

User Wallet (Browser) 
      │
      ▼
Cloud-Hosted React Frontend (AWS / Vercel) ──► DNS Providers (Cloudflare)
      │
      ▼
Centralized RPC Node (Infura / Alchemy)
      │
      ▼
The Blockchain (Decentralized)

If a sovereign state decides to sanction Tether, they don't have to attack the blockchain. They just force Amazon Web Services to drop the frontend hosting, force Cloudflare to revoke the DNS, and force Infura to block the RPC requests. The blockchain keeps ticking, but the users go dark.

This is the exact vulnerability Tether is actively engineering out of existence.

3. Holepunch: Bypassing the Cloud

By funding the Bare runtime and the Holepunch protocol, Tether is building an application delivery layer that completely bypasses centralized cloud infrastructure.

The Bitfinex Blog

Instead of hosting a trading terminal on AWS, Tether can build a financial application where the binary, the UI, and the data are seeded via Hyperdrive (a BitTorrent-like distributed file system).

When a user opens the application, they connect directly to other users via a Kademlia Distributed Hash Table (DHT). There is no DNS. There is no cloud server.

[ Holepunch P2P Access Flow ]

Peer A (User) ◄──────── (Noise IK Handshake via UDP) ────────► Peer B (User)
      │                                                           │
      └──► Local Application Logic & State (Seeded via DHT) ◄─────┘

This isn't a blockchain. There is no global consensus, no blocks, and no gas fees. It is simply raw, encrypted, peer-to-peer data replication. Tether is building this to ensure that even if every cloud provider on earth blacklists them, people can still download, run, and communicate through their financial terminals.

The Architect's Realization

I spent hours frustrated by Tether's sloppy smart contract engineering. But looking at their macro-architecture, I have to respect the pivot.

They realized that putting a stablecoin on a decentralized ledger is completely useless if the physical wires connecting the users are owned by three centralized corporations. They are funding a non-blockchain JavaScript runtime because they understand that true decentralization requires severing the dependency on the server entirely.

We spend our time optimizing Solidity gas down to the byte and debating EVM storage slots. But if we don't start thinking about how our applications are actually distributed, we are just building decentralized sandcastles inside a centralized walled garden.

The Great Web3 Lie: AWS, Infura, and the Return of True Peer-to-Peer

Aniket Misra — Sat, 04 Jul 2026 18:26:20 +0000

There is a glaring, uncomfortable hypocrisy at the heart of modern Web3 engineering, and we all collectively agree to ignore it.

We preach the gospel of the "unstoppable web." We write endless threads about censorship resistance, decentralized consensus, and sovereign infrastructure. We build brilliant, mathematically flawless zero-knowledge circuits and deploy them to immutable ledgers.

And then, to actually let users interact with our cryptographic masterpieces, we wrap them in a React frontend, deploy it to Vercel, and route the transactions through an Infura RPC endpoint running on Amazon Web Services.

If a centralized cloud provider decides to pull the plug on a data center in us-east-1, half of the "unstoppable" decentralized web goes completely dark. We haven't actually decentralized the internet; we have just decentralized the backend database while leaving the entire application delivery mechanism firmly in the hands of three massive tech monopolies.

This architectural dissonance has been bothering me for a while. It is what happens when a financial movement (crypto) hijacks an architectural movement (distributed systems). But while digging through alternative runtimes outside of the EVM and Solana ecosystems, I stumbled onto something profoundly disruptive. It isn't a blockchain. It has no token. But it solves the exact infrastructural vulnerability that Web3 ignores.

It is a stack built by Holepunch—specifically, the Pear Runtime and its underlying engine, Bare.

When you strip away the marketing, Pear is essentially a modern, hyper-optimized resurrection of the 1990s BitTorrent ethos, applied directly to application development. It forces us to ask a terrifying question: what if true decentralization doesn't require global consensus at all?

To understand why this is so subversive, you have to look at the traditional deployment model. When you build a modern application, you assume the existence of a server. Even Node.js and Deno fundamentally assume they are running on a machine that will sit in a data center, listen on a port, and serve state to thin clients over HTTP.

The Holepunch architecture violently rejects this premise.

When you build an app on Pear, there is no web server. There is no cloud hosting. The application’s source code, assets, and state are distributed via Hyperdrive, a secure, real-time distributed peer-to-peer file system. When a user "downloads" a Pear application, they aren't fetching it from AWS; they are fetching the encrypted pieces from other users who are currently running the app.

The moment you open the application, you become a seeder. The deployment infrastructure scales infinitely, automatically, and at zero cost, entirely powered by the aggregate compute of the users themselves. It is serverless, not in the sanitized AWS Lambda sense of the word, but in the literal, anarchic Napster sense.

Under the hood, this requires a complete teardown of standard networking. You cannot rely on DNS to find a server that doesn't exist. Instead, Holepunch relies on Hyperswarm and a Kademlia-based Distributed Hash Table (DHT). In this architecture, cryptography isn't used to reach a global financial consensus; it is used purely for routing. Your public cryptographic key becomes your global, static IP address. Devices perform a Noise IK handshake across the DHT, punch through their local NAT firewalls via UDP, and establish a direct, end-to-end encrypted tunnel.

To make this viable, they had to ditch Node.js. Node is too bloated, carrying decades of legacy APIs designed for centralized web servers. Instead, they built Bare—a stripped-down, modular C-based JavaScript runtime. Bare throws away the HTTP server assumptions. It keeps the V8 engine and the asynchronous event loop, but optimizes entirely for low-level, peer-to-peer data streams across desktop and mobile.

This architecture fundamentally alters the threat model of the web. You cannot DDoS an application that has no central server. A government cannot compel a cloud provider to take down a user interface if that interface is being seeded dynamically by thousands of autonomous laptops across the globe.

Web3 promised us an apocalypse-proof internet, but handed us a decentralized ledger heavily tethered to Silicon Valley cloud infrastructure. Seeing a stack like Pear proves that the actual missing layer of the "unstoppable web" was never about consensus mechanisms or tokenomics. It was about raw data availability.

It turns out, if you want to build truly sovereign software, you have to stop trying to put the server on the blockchain, and simply kill the server altogether.

Next time, I am going to dive deeper into why the company behind the $100 billion stablecoin USDT (Tether) is the one secretly bankrolling this entire non-blockchain JavaScript ecosystem, because the geopolitical implications of that are wild.

The Architecture Spiral: RPC, SQL, and the Myth of Linear Evolution

Aniket Misra — Wed, 01 Jul 2026 12:42:20 +0000

If you sit in on enough system design meetings, you inevitably witness the exact same debate play out on a repeating loop. It usually starts when a team is breaking down a monolithic backend and trying to figure out how the new microservices should talk to each other.

Someone suggests standard REST. It’s stateless, ubiquitous, and deeply understood.
Then, a more performance-minded engineer interjects: "JSON over HTTP/1.1 is too heavy for internal service-to-service chatter. We need strict contracts and lower latency. Let's use gRPC."

It feels like a hyper-modern debate—the battle-tested standard of the 2010s versus the cutting-edge, high-performance tooling of the 2020s.

But if you zoom out, the illusion of modern innovation shatters. Remote Procedure Call (RPC) isn't new. It was conceptualized in the 1970s and standardized in the 1980s. We aren't inventing a new way for computers to communicate; we are just resurrecting a 50-year-old paradigm, dressing it in Protobufs, and multiplexing it over HTTP/2.

This is the quiet truth of software engineering: Technological progress is not a straight line. It is a spiral.

We rarely invent entirely new architectures. Instead, we revisit the exact same fundamental concepts, just one layer higher on the Z-axis of abstraction.

1. The REST vs. RPC Pendulum

To understand the spiral, look at how we got to REST in the first place.

In the late 90s and early 2000s, RPC implementations (like CORBA, DCOM, and SOAP) were miserable. They were tightly coupled, brittle, and notoriously difficult to debug across different languages. If a developer updated a method signature on a server, clients across the network would immediately fracture.

Roy Fielding’s REST (Representational State Transfer) won the web because it provided the ultimate decoupled escape hatch. Instead of executing remote actions, clients interacted with remote resources using standardized, predictable HTTP verbs. It was beautiful, cacheable, and heavily adopted.

But as we transitioned into the era of distributed microservices, REST hit a wall. When you have 40 internal services pinging each other to fulfill a single user request, the overhead of parsing massive JSON payloads and managing stateless HTTP connections becomes a devastating bottleneck.

So, what did we do? We went right back to RPC.

We realized that for internal, tightly-bound systems, we actually wanted strict coupling. We wanted type safety. We wanted binary serialization. Tools like gRPC and tRPC dominate modern backend discussions not because they are conceptually novel, but because they are the 1980s RPC architecture built with 2020s infrastructure.

2. The Return of the Relational Database

You can see this same spiral evolution in data storage.

If you were building a startup around 2012, you were explicitly told that relational databases were legacy tech. "SQL is dead," the thought leaders said. "Schema-less NoSQL is web-scale." We poured billions of dollars into document stores like MongoDB and wide-column stores like Cassandra, convinced that abandoning the rigid constraints of tables and foreign keys was the only way to achieve horizontal scalability.

Fast forward to today. What is the default, undisputed king of databases? PostgreSQL.

Not only has SQL made a dominant comeback, but the very NoSQL databases that tried to kill it have spent the last five years desperately bolting SQL-like query languages onto their engines.

Why did this happen? Because Edgar F. Codd’s "Relational Model of Data," published in 1970, wasn't just a technological trend. It was based on fundamental relational algebra. The math was always correct. The only problem in the 2010s was that the underlying storage engines struggled to distribute that math across multiple physical servers.

Once engineers figured out how to build distributed, globally consistent relational engines (like Google Spanner or CockroachDB), the need for NoSQL evaporated for 95% of use cases. We went right back to SQL.

3. Mainframes to Edge: The Physics of Compute

Perhaps the most massive spiral is where compute actually happens.

The 1970s (Centralized): The era of the Mainframe. Massive central computers handled all the logic. Users interacted via "dumb terminals" on their desks that did nothing but render the output.
The 1990s (Decentralized): The era of the Personal Computer. Moore’s Law made chips cheap. We moved compute away from the center and put it directly on the user's desk.
The 2010s (Centralized): The era of the Cloud. We realized managing thousands of local machines was a nightmare. So, we moved the compute back to massive centralized data centers (AWS, GCP). Our high-powered laptops essentially became very expensive, glowing dumb terminals for web browsers.
The 2020s (Decentralized): The era of the Edge. The cloud is now too slow for AI inference and high-performance UX. So, via WebAssembly (Wasm), local-first databases (SQLite in the browser), and edge networking, we are pushing the compute right back down to the user's local machine.

Mainframe to PC. Cloud to Edge. It is the exact same architectural breath, inhaling and exhaling across decades.

Why the Spiral?

Why do we constantly go backwards to move forwards? Is it just a lack of imagination? Are we victims of sunk cost, clinging to the paradigms we learned in university?

No. The spiral exists because software architecture is ultimately bound by physical reality.

We are constantly negotiating between conflicting, immutable constraints: the speed of light (network latency), the cost of silicon (compute power), and the CAP theorem (consistency vs. availability).

When we invent a "new" paradigm, we are usually just optimizing for one of these constraints by willingly sacrificing another. When we moved to NoSQL, we sacrificed consistency for availability. When we moved to the Cloud, we sacrificed latency for centralized management.

Eventually, we push a paradigm to its absolute breaking point. We hit the physical limit of what it can do. And the only way out is to flip the trade-off, looking back into the past for the architecture that optimized for the exact thing we are now starving for.

We aren't failing to innovate. We are just maturing. We are slowly realizing that the engineers of the 1970s weren't primitive; they were dealing with the exact same fundamental laws of computer science that we are. We just happen to have faster Wi-Fi.

The Rhythm of the Primitives: Cryptography, Poisson, and the False Memory of the 90s

Aniket Misra — Tue, 30 Jun 2026 18:28:59 +0000

When we look back at the 1990s, our collective cultural memory betrays us. We retroactively paint the decade as an era of primitive digital toys—a neon-tinted landscape of screeching dial-up modems, bulky pagers, and kids feeding pixelated Tamagotchis. We treat it like the infancy of the digital age, a time before real engineering took hold.

But a funny thing happens when you step away from modern abstractions, sit down with a Rust compiler, and read Satoshi Nakamoto’s 2008 whitepaper in its original context. The illusion shatters. You realize that the foundational architecture of decentralized consensus wasn't invented in the wake of the 2008 financial crisis. Every single piece of the cryptographic puzzle was already breathing, compiling, and thriving in that exact "primitive" decade.

Satoshi didn't invent Web3. He was just the ultimate systems integrator.

Digging into the cypherpunk archives of early Usenet groups is like walking into an ancient library and finding the blueprints for a spaceship. The intellectual breeding ground for decentralized technology was fully formed while the rest of the world was struggling to load JPEGs. The concept of sovereign-less "electronic money" was relentlessly debated. Wei Dai’s B-money and Nick Szabo’s Bit Gold laid the philosophical groundwork. The data structures required to keep a ledger lightweight—Merkle Trees—had already been patented by Ralph Merkle back in 1979.

The missing link was always sybil resistance. How do you stop a malicious actor from spinning up a million fake identities to rewrite the ledger? The answer was sitting in 1997 with Adam Back’s Hashcash. Hashcash wasn't designed for global finance; it was a clever, brute-force hack to make email spam economically unviable by forcing a computer to expend CPU cycles to calculate a cryptographic hash.

Satoshi took this anti-spam mechanism, lifted it from the forgotten corners of the 90s internet, and weaponized it into the heartbeat of global consensus.

But where the whitepaper transitions from a clever engineering integration into an absolute masterpiece is in its mathematical rigor. Satoshi didn't just theorize that a decentralized network was secure; he proved it statistically. In the quietest, most devastatingly elegant section of the paper, he addresses the system's core vulnerability—a 51% attack—by framing it as a Binomial Random Walk.

It is the classic Gambler’s Ruin problem applied to global finance. If an honest node has a probability (p) of finding the next block, and a malicious attacker has a probability (q, which is 1-p, that is, unless we are in a universe with probabilities>100%), the math becomes a beautiful, brutal reality. Because block discovery is probabilistic, Satoshi maps the attacker's potential progress to a Poisson distribution.

He proves, with cold mathematical certainty, that as long as honest nodes control more CPU power (p > q), the probability of an attacker successfully rewriting history drops exponentially with every passing block. It is a masterpiece of statistical poetry. He built a trustless system by mathematically proving that betrayal is too expensive.

Uncovering these anachronisms in technology—realizing that the heavy cryptographic lifting was happening parallel to the Tamagotchi—triggered a weird cognitive dissonance. It made me question what else I was misremembering about that era. Being a musician, I naturally turned to the rhythm of the decade.

For my entire life, I have retrospectively framed the 90s as the decade of relentless, underground Eurotechno. In my head, the soundtrack of that era was an endless loop of Haddaway’s "What is Love" thumping out of a dark, synthesized European club basement. I equated the 90s with the four-on-the-floor kick drum of early electronic dance music.

I was completely wrong. Look at the actual cultural footprint of the decade. It wasn't defined by cold European synthesizers; it was a massively hispanophile era. The Macarena didn't just exist; it conquered the globe. Latin pop exploded into the global mainstream. The rhythm of the decade was fundamentally organic, percussive, and intensely Latin. The aesthetic I had projected onto the past was a complete fabrication.

This historical unearthing has bled into my own physical reality. I’ve realized that my own rhythms need a structural shift. The tabla is a beautiful, complex instrument, and it will always be a part of my percussive foundation. But you cannot lug a heavy set of brass and wood up a mountain on a hike. It is geographically anchoring.

So, I’m reviving my old school assembly chops. I am packing up the bongos. They fit in a backpack. They carry that organic, Afro-Cuban groove that actually defined the era I’ve been misremembering. And to make sure I’m not just an isolated rhythm section on the trail, I’ve picked up a harmonica to build out some melodic grit.

Afro-Cuban percussion and delta Blues are officially on. It turns out, whether you are integrating 1990s cypherpunk primitives to build decentralized state machines, or blending bongos with a blues harp on a hiking trail, the magic is never in inventing something entirely new. The magic is in the assembly.

Time to get back to the Rust compiler.