Forem: Mr. 0x1

We Ran Four Security Tools Against Express.js. They Found Each Other's Proof.

Mr. 0x1 — Sun, 12 Apr 2026 21:44:53 +0000

When you run a single security scanner against a codebase, you get a list. When you run four different tools — each operating at a different layer of the problem — you get something else entirely. You get corroboration. Findings from one tool explain findings from another. Patterns that look like noise in isolation become signal when you see them converge from different angles.

We pointed a four-layer security analysis stack at Express.js — the most depended-upon web framework in Node.js, roughly 30 million weekly downloads — and ran the full audit in under fifteen minutes.

The tools found what the community is actively reporting right now. Not retroactively, not after reading the issues. The tools surfaced the vulnerabilities first, and when we checked GitHub afterward, the issues were already there — some filed days ago, one still unpatched after two and a half years.

The Stack

Four layers. Each does one thing well. The value is in the correlation.

VulnGraph MCP — a graph database with 469,942 nodes aggregating 9 vulnerability intelligence sources (CVE List V5, EPSS, CISA KEV, ExploitDB, PoC-in-GitHub, Nuclei, MITRE ATT&CK, OSV, CWE). Exposed as an MCP server — 16 tools, sub-millisecond queries, zero network calls. This is the threat intelligence layer. It answers: what is known about this vulnerability, how likely is it to be exploited, and who is exploiting it?

Semgrep — static application security testing. Pattern-matching against source code for known vulnerability classes. This is the code-level layer. It answers: does this codebase contain code patterns that match known vulnerability categories?

Zentinel — static analysis with security-focused rule sets for language-specific and universal patterns. This is the pattern detection layer. It answers: what code constructs in this codebase deviate from security best practices?

Vajra — deterministic structural analysis. Inspects project manifests, dependency trees, and data shapes for anomalies. This is the project health layer. It answers: what does the structure of this project tell us about its risk profile?

We ran all four against Express.js v5.2.1. 141 JavaScript files, 28 direct dependencies, 386 transitive dependencies. The entire experiment — from cold data refresh to validated findings correlated against live GitHub issues — took under fifteen minutes.

What Each Tool Found

VulnGraph MCP: The Dependency Intelligence

We queried VulnGraph for every known CVE affecting Express and its core dependency chain. Six CVEs came back with full enrichment:

CVE	Package	CVSS	EPSS	Maturity
CVE-2022-24999	qs	7.5	1.54%	POC
CVE-2024-47764	cookie	6.9	0.21%	NONE
CVE-2024-29041	express	6.1	0.11%	NONE
CVE-2024-43796	express	5.0	0.12%	NONE
CVE-2024-43799	send	5.0	0.18%	NONE
CVE-2024-38372	undici	2.0	0.22%	NONE

CVE-2022-24999 stands out: prototype pollution in qs that causes a Node process hang. It has a public proof-of-concept and 1.54% EPSS — roughly a 1 in 65 chance of exploitation in the next 30 days. Express 5.2.1 requires a patched version, but any project pinned to an older qs is exposed.

VulnGraph also flagged the devDependency chain. Express pulls Handlebars and Mocha (which pulls serialize-javascript) for its test and example infrastructure. npm audit confirmed: 1 critical against Handlebars (8 advisories including prototype pollution and code injection) and 3 high against serialize-javascript (RCE).

The EPSS enrichment told a story that CVSS alone would have missed. CVE-2019-19919 — Handlebars prototype pollution leading to RCE — has a CVSS that reads as unscored, but VulnGraph returned an EPSS of 17.8%. Nearly 1 in 5 probability of exploitation. That number comes from observed scanning activity, not theoretical severity. It's the difference between "this is bad in theory" and "this is being probed right now."

Semgrep: The Code Patterns

53 findings across the codebase. 48 warnings, 5 informational. Every single finding was in the examples/ directory. The core lib/ was clean.

30 cookie session misconfigurations — sessions without httpOnly, secure, domain, path, or expires
6 open redirect vulnerabilities — res.redirect(req.body.url) with no validation
6 direct response writes — res.send(req.params.*) with no escaping (XSS)
4 hardcoded secrets — secret: 'shhhh' in session config
1 template unescape — <%- ... %> in an EJS template

On its own, you might dismiss this. "It's just example code." But these examples are the most-copied code in the Node.js ecosystem. They show up in tutorials, starter templates, Stack Overflow answers, and AI-generated code suggestions. The patterns map to CWE-601 (open redirect), CWE-79 (XSS), CWE-798 (hardcoded credentials), and CWE-614 (missing secure cookie flags).

Zentinel: The Deep Patterns

50 rules loaded across JavaScript security and community rule sets. Zentinel found patterns Semgrep didn't surface — and vice versa.

The most notable: 40+ instances of undefined assignment patterns across Express's core files (application.js, response.js, request.js). Express uses === undefined checks extensively to determine whether settings have been configured — a known antipattern since undefined isn't a reserved keyword in JavaScript.

Zentinel also flagged missing CSRF middleware in the example apps and confirmed the hardcoded secret pattern Semgrep independently found. Two tools, different engines, same conclusion.

Vajra: The Structural Profile

28 direct dependencies (lean for a framework), Node >= 18 engine requirement (drops legacy attack surface), 7 listed contributors (concentrated maintainership), OpenCollective funding.

All dependency versions use caret ranges (^), meaning minor and patch updates are accepted automatically. Double-edged: you get patches quickly, but you inherit any regression from a transitive dependency update.

Where It Gets Interesting: The Cross-Layer Correlation

Each tool produced useful findings on its own. The real signal emerged when we cross-referenced the layers.

Semgrep's open redirect findings + VulnGraph's CVE-2024-29041. Semgrep flagged res.redirect(req.body.url) in six example files. VulnGraph returned CVE-2024-29041 — an open redirect in Express patched in 4.19.0. The framework fixed the bug, but the examples still demonstrate the unsafe pattern. Developers who copy the examples are reintroducing the exact vulnerability the framework patched.

Semgrep's XSS findings + VulnGraph's CVE-2024-43796. Same pattern. Semgrep found direct response writes with user input. VulnGraph returned CVE-2024-43796 — XSS in response.redirect(), fixed in Express 4.20.0. The fix is in the framework. The vulnerable pattern is still in the examples.

npm audit's Handlebars critical + VulnGraph's EPSS. npm audit said "critical." VulnGraph said 17.8% EPSS. Those are different statements. "Critical" is a theoretical severity rating. 17.8% EPSS means the vulnerability is actively being scanned for in the wild — observed, not theoretical. Without VulnGraph's enrichment, you'd treat this as a devDependency problem and deprioritize it. With the EPSS data, you understand it's a supply chain attack vector against your CI/build pipeline.

Zentinel's undefined patterns + Express trust proxy behavior. The === undefined pattern in application.js is how Express determines whether trust proxy has been explicitly configured. If it hasn't, Express defaults to not trusting proxies. This interacts directly with CVE-2024-29041's open redirect — the vulnerability depends on how Express resolves the redirect URL, which depends on proxy trust, which depends on a setting checked via the exact pattern Zentinel flagged.

No single tool produced that chain. It took four.

The Validation: Open GitHub Issues

After completing the analysis, we checked whether the open-source community had independently identified the same problems. They had.

expressjs/express#7140 (filed March 30 — 13 days before our audit). View.prototype.lookup() lacks path containment check. A security-labeled issue reporting that res.render() with user input allows path traversal — exactly the class of issue our stack identified through the combination of Zentinel's core code analysis and Semgrep's example code findings.

handlebars-lang/handlebars.js#2146 (filed April 9 — 3 days before our audit). Proto-access control bypass via Map Symbol.toStringTag spoofing + HTML escape bypass. Three separate findings in one report, disclosing that the mitigations added to fix the original prototype pollution CVEs can be bypassed. Our stack flagged Handlebars as the highest-priority finding through VulnGraph's 17.8% EPSS. Three days later, a researcher confirmed the original fixes are incomplete.

yahoo/serialize-javascript#208 (filed February 28). Backport request for the RCE fix to version 6. The fix exists in v7, but webpack and the broader ecosystem can't upgrade due to Node.js version constraints. Seven comments, no resolution.

expressjs/express#5309 (filed November 2023 — 2.4 years before our audit). "Split the examples from this repo." The Express maintainers themselves identified the root cause of our Semgrep findings. Vulnerable devDependencies in examples cause CVE reports against Express, and dependency upgrades break CI. Eight comments, no resolution. Our 53 Semgrep findings are the quantified evidence for this 2.4-year-old open discussion.

jshttp/cookie#200 (filed October 2024). cookie.parse ignores HttpOnly and Secure flags. Twenty comments, highly active. VulnGraph flagged the related CVE-2024-47764 (cookie injection, CVSS 6.9). The community is experiencing the downstream effects of the same parsing weakness our tools identified.

Fifteen Minutes

Here's what the timeline actually looked like.

Minutes 0–2:30 — Data refresh. Pull the latest from 5 git-cloned source repos. Download fresh EPSS scores, CISA KEV, CAPEC, and the full OSV database (1.2 GB). Rebuild the graph — 469,942 nodes, 610,564 edges — and atomically swap it into the live database. Restart the MCP server. Health check passes.

Minutes 2:30–5:30 — Scan. Clone Express, generate the lockfile, launch all four tools in parallel. They finish within seconds of each other. 53 Semgrep findings, 40+ Zentinel findings, 6 enriched CVEs from VulnGraph, full structural profile from Vajra.

Minutes 5:30–8:30 — Enrichment. Cross-reference the layers. Feed Semgrep's CWE classifications into VulnGraph for ATT&CK mapping. Deep-dive the Handlebars chain. Query exploit intelligence. Feed npm audit results back through VulnGraph for EPSS enrichment that CVSS alone wouldn't provide.

Minutes 8:30–11:30 — Validation. Search six GitHub repos for open issues matching our findings. Pull details on five high-signal matches. Confirm that independently-filed community reports describe the same vulnerabilities the stack surfaced.

Minutes 11:30–15 — Synthesis. Compile the cross-layer correlations. Map findings to issue numbers. Done.

That's the full audit cycle — fresh intelligence, four-layer scan, enrichment, validation against live community reports — in the time it takes most teams to get through a morning standup.

What This Changes for Teams

The speed isn't a flex. It's the point.

Security teams are drowning. The average enterprise application has hundreds of dependencies, each with its own CVE history, each updating on its own cadence. A senior security engineer doing this manually — pulling CVE databases, running Semgrep, cross-referencing EPSS, checking GitHub issues, building the correlation — would spend a day or more. For one repository. Then the data goes stale.

Fifteen minutes changes the math. You can audit a dependency before you approve the pull request. You can re-scan daily or hourly and know your findings reflect what's being exploited right now, not last quarter. A team of three can maintain continuous security posture across dozens of repositories instead of periodic deep-dives on two or three.

The parallelism matters. Running four tools in parallel and cross-referencing the output produces findings none of them would surface alone — and does it in the same wall-clock time as running one. The correlation is free. You're already waiting for Semgrep to finish; VulnGraph, Zentinel, and Vajra are done before it is.

The freshness matters. VulnGraph's graph was rebuilt from sources updated within the hour. The EPSS score that flagged Handlebars at 17.8% is based on current observed scanning activity, not a snapshot from last week. When the stack says "this is being probed right now," it means right now.

And the validation matters. Checking findings against live GitHub issues isn't a manual afterthought — it's a 3-minute step that turns tool output into evidence. The difference between "our scanner flagged this" and "our scanner flagged this, and three days ago a researcher confirmed the fix is incomplete" is the difference between a ticket and an escalation.

What This Means

We didn't read the GitHub issues first. The tools found the vulnerabilities. The issues confirmed them.

This is what a multi-layered security analysis stack is supposed to do. Not replace human judgment — amplify it. Each tool sees one facet. The correlation between layers is where the real intelligence lives. VulnGraph's EPSS data tells you Handlebars is under active scanning. Semgrep tells you the vulnerable patterns exist in copyable example code. Zentinel tells you the core framework has structural patterns that interact with the vulnerability. Vajra tells you the dependency tree auto-accepts minor updates from these packages.

No single scanner produced a complete picture. The stack did. In fifteen minutes.

Express.js is well-maintained and actively developed. The findings here aren't an indictment — they're evidence that even the most mature, most scrutinized open-source projects benefit from multi-angle analysis. If four tools can independently surface findings that map to real, actively-discussed issues in a project with this level of community attention, the approach works. And if it works in fifteen minutes, it works at the cadence that modern software actually ships.

We're calling it the Sigma stack. It's still developing. But the Express experiment is the proof point — four layers, converging independently on the same real problems that human researchers are filing issues about right now, in less time than it takes to triage a single Jira ticket.

The interesting question isn't whether the tools work. It's what happens when you stop treating security scanners as isolated checklist machines and start treating them as complementary lenses on the same problem.

They start finding each other's proof.

The VulnGraph MCP graph contains 469,942 nodes and 610,564 edges across 9 sources, refreshed within the hour of the audit. Express.js findings are based on the public repository (v5.2.1, April 2026). All referenced GitHub issues are public. Semgrep is open source. VulnGraph's interactive demo is at vulngraph.tools.

I Asked My AI Agent About axios. It Knew Everything in 0.03ms.

Mr. 0x1 — Sun, 05 Apr 2026 16:56:21 +0000

I pointed an AI agent at a single npm package — axios, the HTTP client installed 55 million times per week — and asked: how risky is this?

In under a millisecond, it came back with 13 known vulnerabilities correlated across CVE databases, EPSS exploitation scores, CISA KEV, public exploits, weakness classifications, and ATT&CK mappings.

No API keys. No network calls. No rate limits.

One local graph. Sub-millisecond.

Here's what happened.

The Setup

VulnGraph is a vulnerability intelligence graph that pre-joins 9 authoritative sources into a single memory-mapped file. It exposes 16 tools via the Model Context Protocol (MCP) — the standard for giving AI agents access to tools.

I connected it to an agent and started asking questions about axios.

13 CVEs. 7 High Severity. 0.14ms.

The first call — lookup_package — returned the full vulnerability profile:

CVE	Severity	CVSS	EPSS	PoCs
CVE-2025-27152	HIGH	7.7	0.07%	3
CVE-2025-58754	HIGH	7.5	0.11%	—
CVE-2026-25639	HIGH	7.5	0.05%	—
CVE-2021-3749	HIGH	7.5	8.26%	1
CVE-2024-39338	MEDIUM	4.0	2.88%	—
CVE-2023-45857	—	—	0.13%	3
CVE-2019-10742	—	—	13.52%	—

That's not just CVE IDs. Every row has a CVSS base score, an EPSS exploitation probability (likelihood of exploitation in the next 30 days), and proof-of-concept counts from GitHub and ExploitDB. All pre-joined. All instant.

Is axios@1.6.0 Safe?

{
  "package": "axios",
  "version": "1.6.0",
  "vulnerable": true,
  "cve_count": 13,
  "highest_severity": "HIGH"
}

0.019ms. The agent now knows not to suggest this version in any code it writes.

What Should You Fix First?

This is where it gets interesting. VulnGraph doesn't just list CVEs — it triages them.

The assess_risk tool scored the top axios CVEs using a weighted model: CVSS severity, EPSS probability, exploit maturity, and exposure context.

Priority	CVE	Risk Score	Level	Fix Within
1	CVE-2021-3749	5.62	MEDIUM	7 days
2	CVE-2025-27152	5.60	MEDIUM	7 days
3	CVE-2026-25639	3.75	LOW	30 days
4	CVE-2024-39338	2.04	LOW	30 days
5	CVE-2023-45857	1.75	LOW	30 days

Notice something? CVE-2021-3749 outranks CVE-2025-27152 despite a lower CVSS score. Why? Its EPSS is 8.26% (92nd percentile) — it's far more likely to be exploited in the wild.

CVSS alone would have gotten this wrong. Most vulnerability scanners would have gotten this wrong.

Deep Dive: SSRF in axios (CVE-2025-27152)

I asked the agent to go deeper on CVE-2025-27152. The get_exploit_intel tool mapped the full threat context in 0.034ms:

Severity: HIGH (CVSS 7.7)
Exploit Maturity: POC — 3 public proof-of-concept exploits on GitHub
Weakness: CWE-918 (Server-Side Request Forgery)
KEV Listed: No (not yet seen in the wild)
EPSS: 0.07% — low current probability

Following the CWE-918 thread, VulnGraph revealed that SSRF is classified across 1,401 CVEs in the graph. The most dangerous? CVE-2021-40438 — Apache mod_proxy SSRF, EPSS 94.4%, CISA KEV listed, CVSS 9.0.

One CVE pulled a thread that unraveled an entire weakness class across the graph.

The Graph Traversal

This is the core advantage. The get_related tool traced all connections from CVE-2025-27152 in a single traversal:

CVE-2025-27152
  |-- affects --> npm:axios
  |-- affects --> cpe:axios:axios
  |-- has_poc --> GitHub-PoC:CVE-2025-27152:0
  |-- has_poc --> GitHub-PoC:CVE-2025-27152:1
  |-- has_poc --> GitHub-PoC:CVE-2025-27152:2
  +-- classified_as --> CWE-918 (SSRF)

It's not 6 separate API calls stitched together. It's a single hop across pre-joined data. 0.05ms.

This Was Just axios

The demo exercised 7 of VulnGraph's 16 MCP tools. The full toolset:

Category	Tools
Lookup	`lookup_cve` `lookup_package` `lookup_weakness`
Search	`search_vulnerabilities` `search_packages`
Analysis	`analyze_dependencies` `assess_risk` `check_version`
Exploit Intel	`get_exploit_intel` `trending_threats`
Graph	`map_attack_surface` `get_related`
Timeline	`get_timeline`
Batch	`scan_sbom` `scan_lockfile`
Meta	`graph_stats`

467,939 Nodes. 9 Sources. One File.

VulnGraph pre-joins data from 9 authoritative sources:

Source	Records	What It Provides
CVE List V5	342,360	Every published vulnerability
EPSS	324,894	Exploitation probability — what's likely to be attacked
CISA KEV	1,557	Confirmed actively-exploited vulnerabilities
OSV	43,606	Ecosystem advisories with affected version ranges
ExploitDB	30,409	Published exploits
PoC-in-GitHub	14,826	Proof-of-concept code
MITRE ATT&CK	18,224	Techniques, threat actors, malware
Nuclei Templates	3,999	Automated scanning templates
CWE	745	Weakness taxonomy

The graph opens in ~100 microseconds via mmap. Point lookups run in <1ms. There are no network calls, no cold starts, no rate limits.

Every response includes a data_freshness envelope showing exactly when each source was last synced — because stale vulnerability data is worse than no data.

Why MCP?

The Model Context Protocol is the emerging standard for giving AI agents access to tools. VulnGraph implements it natively — 16 tools over JSON-RPC, available via HTTP or stdio.

Any MCP-compatible agent can discover these tools automatically. The agent calls tools/list, sees 16 vulnerability intelligence tools with full input schemas, and starts querying — no docs, no integration code.

{
  "method": "tools/call",
  "params": {
    "name": "check_version",
    "arguments": {
      "ecosystem": "npm",
      "package": "axios",
      "version": "1.7.4"
    }
  }
}

0.019ms later, the agent knows whether the dependency it's about to recommend is safe.

What this enables:

Code review agents that flag vulnerable dependencies before merge
Security copilots that triage by real exploit intelligence, not just CVSS
Incident response agents that map CVE to package to technique to threat actor
CI/CD gates that block deploys with actively-exploited vulnerabilities

Try It

vulngraph.tools — the full 467K-node graph running in your browser via WebAssembly. Search any CVE, explore relationships, see the data freshness live.

VulnGraph is a Rust graph engine backed by memory-mapped binary files. 467,939 nodes. 602,467 edges. 9 sources. Sub-millisecond. Built for agents.

We Built a Financial Solver That Protects Jobs. Then We Tried to Break It 1.1 Billion Times.

Mr. 0x1 — Sat, 04 Apr 2026 15:54:51 +0000

The Problem Nobody Wants to Solve

A company is running out of money. The runway is eight months. The board says cut costs or die.

The default answer is layoffs. Pick 87 people. Walk them out. The math works: fewer salaries, longer runway. But the people who stay carry survivor's guilt, institutional knowledge walks out the door, and the company that was supposed to be "family" just proved it wasn't.

We asked a different question: what if everyone took a small, temporary pay cut instead?

Not forced. Not uniform. Each person declares the maximum percentage they're willing to give. An algorithm distributes the burden fairly, respects every individual's limit, and extends the runway. Nobody loses their job.

This is Seuil. French for "threshold." The threshold where individual sacrifice becomes collective strength.

The Constraint That Makes It Hard

Here's the thing about this algorithm. It has one rule that cannot bend:

∀i : adjustment_i ≤ declared_threshold_i

Every person's adjustment must be less than or equal to what they consented to. Not approximately. Not on average. For every single employee, every single time, without exception.

If the algorithm ever violates this, even by a fraction of a percent for one person in one run, the entire system loses legitimacy. You can't ask people to trust a salary adjustment tool that sometimes overrides their consent.

This constraint turns what looks like a simple optimization problem into something genuinely interesting. You're maximizing headcount retention subject to hard consent constraints, a savings floor, fairness requirements across tiers and departments, and the reality that people change their minds mid-plan.

The Algorithm: Iterative Clamping

The core of Seuil's Rempart engine is a weighted proportional allocation with iterative clamping. Here's the intuition.

Each employee gets a "burden weight" based on the active fairness mode. In executive-heavy mode, executives get a 2x weight. In equalized mode, everyone gets the same weight. In critical-protection mode, employees with high criticality scores get lower weights.

The algorithm finds a single scale factor, λ (lambda), such that:

λ = target_savings / Σ(salary_i × weight_i)

Each employee's adjustment is λ × weight_i. Simple. But some employees will exceed their declared threshold at this λ. So we clamp them at their ceiling and remove them from the active set. This reduces the denominator, which increases λ for the remaining employees. Some of them now exceed their thresholds. Clamp again. Repeat.

The trick that makes this fast: sort employees by ceiling / weight ascending before starting. Then the clamping loop is a single linear scan. Employees who clamp first are at the front of the sorted list. You walk forward, clamping and accumulating, until you find the first employee who fits under the current λ. Everyone after that fits too. Done.

Total complexity: O(n log n) for the sort, O(n) for the scan. For 1,240 employees, this runs in about 3ms. For 100,000, about 10ms.

Why Rust. Why Integers.

The first prototype was TypeScript. It worked. 15 test cases passed. The simulator dashboard used it directly via useMemo. But TypeScript has a problem for financial computing: IEEE 754.

Floating point arithmetic is not associative. (a + b) + c is not always equal to a + (b + c). When you're summing salary adjustments across a thousand employees, the order of operations affects the result. The same input can produce different outputs depending on how the JavaScript engine optimizes the computation. And the rounding errors accumulate.

For a system where people's livelihoods depend on the math, "close enough" isn't.

So we rebuilt in Rust with integer arithmetic throughout. Every monetary value is stored as i64 cents. Every percentage is stored as u16 basis points (hundredths of a percent). The clamping comparison uses u128 cross-multiplication to avoid division entirely:

// Does this employee need clamping?
// remaining × weight × 10000 > active_wp × ceiling
let lhs = remaining_cents as u128 * item.weight_millionths as u128 * 10000;
let rhs = active_wp as u128 * item.ceiling_bps as u128;
if lhs > rhs { /* clamp */ }

No floating point touches the solver. The API layer converts between f64 JSON (what the frontend speaks) and integer core (what the engine computes) at a single boundary. Inside the engine, it's integers all the way down.

This gave us something that floating point never could: determinism. The same input produces the exact same output on every platform, every run, every time. The 100-run determinism test doesn't check for "close enough." It checks for bit-identical results.

How We Test: Everything TigerBeetle Taught Us

TigerBeetle is a financial transactions database that tests itself with a VOPR (Viewstamped Operation Replicator), a fuzzer that generates random operation sequences and checks invariants after every single operation. Their philosophy: if a financial system can be broken by any sequence of valid operations, it will be broken by real users. Find it first.

We adopted this wholesale.

The VOPR

Our VOPR generates random sequences of operations: solves, mass declines, threshold changes, fairness mode switches, target adjustments. After each operation, it checks seven invariants:

Consent inviolability. No adjustment exceeds any threshold.
Conservation of savings. No money created or destroyed by rounding.
Monotonic feasibility. More participation never makes things less feasible.
Determinism. Same inputs always produce same outputs.
Fairness ordering. Equalized mode always produces lower Gini than executive-heavy.
Rebalance convergence. Any sequence of accepts/declines produces a valid state.
No phantom money. Reported totals match the sum of individual contributions.

We run 10,000 sequences at a time. Each sequence is 10 to 50 operations on a randomly generated company of 100 to 2,000 employees. That's roughly 350,000 operations with invariant checking after every single one.

The first version ran at 264 operations per second. That's where TigerBeetle's other lesson kicked in.

TigerStyle: Zero Allocation in the Hot Path

TigerBeetle pre-allocates all memory at startup and never allocates during operation. We were doing the opposite: cloning the employee array on every solve, allocating new Vec for each sort, building string-heavy output structs, and then running a determinism re-check (which doubles the work) inside the invariant checker.

We applied TigerStyle principles:

SolverArena: pre-allocated scratch space for all solver buffers. Allocated once, reused across every solve. The VOPR loop does zero heap allocation after init.
solve_arena(): borrows &[Employee] instead of owning Vec<Employee>. No clone at the boundary.
Integer-only check_invariants(): reads from arena.adjustments_full[i] by index. No string matching. O(n) per check.
Determinism checked by replay, not re-execution. TigerBeetle's insight: determinism is a property of the code, not of individual operations.

Result: 38,469 ops/sec. A 146x speedup. An overnight 8-hour run executes approximately 1.1 billion invariant-checked operations.

The Multiverse

The VOPR tests random operations within one company. But the algorithm must work for any company. So we built 20 universes:

Universe	Employees	What it tests
Sole Proprietor	1	N=1 edge case
Garage Startup	5	Fairness at intimate scale
Mega Corp	100,000	Integer overflow at scale
All Executives	500	Flat hierarchy, stingy limits
Engineering Strike	1,500	Entire department walks out
Geographic Pay Gap	2,000	Same role, 10x salary by location
Concentration Risk	200	One person earns 25% of payroll
Razor's Edge	500	Target barely feasible
Contractor Heavy	1,500	60% can't participate
Pay Equity Stress	1,200	Systematic salary gap

Each universe has its own salary distribution, threshold culture, participation pattern, and tier structure. The VOPR runs against all of them. Zero violations across all 20.

God Mode

The final test: one million employees calibrated to the actual economic structure of planet Earth.

We used ILO World Employment data, World Bank income distribution, and Milanovic's global inequality research. The salary distribution follows a log-normal body with a Pareto tail (alpha 1.7). Eight global regions weighted by workforce share. Salaries from $150/year (Burundi) to $5.8 million/year. A 30,000:1 dynamic range.

At this scale, every subtle bug becomes loud:

A 1-cent rounding error per employee is $10,000 of phantom money
The u128 cross-multiplication in the clamping comparison handles values up to 10^38
The sort processes one million 32-byte structs in about 35ms
The Gini coefficient computation must handle a distribution vastly more unequal than any single company

All invariants held. The $150/year Burundian worker and the $5.8M/year executive both got adjustments within their declared thresholds. Not one dollar of phantom money.

The Arithmetic Bug That Almost Shipped

This is the part where I'm supposed to say everything worked perfectly. It didn't.

When porting the TypeScript solver to Rust integer arithmetic, we got the unit scaling wrong in the clamping loop. The formula should have been:

adj_bps = remaining_cents × 10000 × weight / active_wp

But we wrote:

adj_bps = remaining_cents × weight × 10000 / (active_wp × 1_000_000)

That extra 1_000_000 in the denominator. The adjustment calculation was dividing by a million too much. Every employee got an adjustment of zero. The "baseline sanity" test caught it immediately: total savings was zero, which is not what you want from a cost-cutting algorithm.

The fix was one line. But the fact that the test caught it in under a second, before the code ever ran against real data, is the entire point of this kind of testing. Financial bugs don't announce themselves. They hide in rounding, in edge cases, in the difference between what you meant to compute and what you actually computed. You find them with proofs, not with demos.

Run It Yourself

We compiled the Rempart engine to WebAssembly and built a visualization at bench.seuil.dev.

It's not a demo with mock data. The production Rust engine, compiled to 379KB of WASM, runs real constrained optimization in your browser. You can click any of the 36 tests and watch the Rempart engine solve, verify, and prove its guarantees in real time.

The signal field visualization (adapted from a previous project) shows the solver's internal stages as a node graph. Tier 1 nodes are solver stages: filter, feasibility, weight computation, iterative clamping. Tier 2 nodes are verification: consent check, drift check, determinism. The verdict node at the bottom lights up green only when all invariants hold. Particles flow between nodes as the computation proceeds.

Each test tells a three-act story:

The Situation. What's at stake. In human terms.
The Challenge. What goes wrong. The chaos.
The Proof. Did the engine protect everyone?

The Numbers

Metric	Value
Solver language	Rust, integer arithmetic
Arithmetic	i64 cents, u16 basis points, u128 comparisons
Test suites	36 (14 adversarial + 20 multiverse + 1 VOPR + 1 God Mode)
VOPR throughput	38,469 ops/sec with invariant checking
Overnight capacity	~1.1 billion checked operations in 8 hours
Max employees tested	1,000,000 (planetary economics)
Salary dynamic range	30,000:1 ($150/yr to $5.8M/yr)
Consent violations	0
Phantom money	0
Non-deterministic results	0
WASM bundle size	379KB (108KB gzipped)

What This Is Really About

There's a tendency in software to ship fast and fix later. Move fast and break things. The problem is, some things shouldn't break. A salary adjustment algorithm that tells a junior employee "we're taking 12% of your pay" when they consented to 10% is not a bug to fix in the next sprint. It's a betrayal of trust that you can't unfix.

We didn't build this testing infrastructure because it was fun (though the VOPR is genuinely fun to watch). We built it because the alternative was asking people to trust software that we couldn't prove was correct.

We don't ship promises. We ship proofs.

Try it: bench.seuil.dev

The Seuil Continuity System and Rempart engine are open source. The Rust engine, TypeScript prototype, and WASM benchmark visualization are all available on GitHub.

I Built a Stream Processor That Only Recomputes What Changed

Mr. 0x1 — Wed, 25 Mar 2026 14:37:25 +0000

I spent weeks studying how incremental computation works in production trading systems. Not the papers. The actual implementations. How self-adjusting computation engines track dependencies, propagate changes, and avoid redundant work.

One thing kept bothering me: the model is incredibly powerful, but it's locked inside single-process libraries. If you want surgical recomputation — where changing one input only touches the nodes that actually depend on it — you have to give up distribution. If you want distribution, you're back to recomputing entire windows on every tick.

That gap is where Ripple came from.

The experiment that started it

I built a prototype. A simple incremental graph: 10,000 leaf nodes (one per stock symbol), each feeding through a map node into a fold that aggregates them all. The question was simple: when one leaf changes, how many nodes actually need to recompute?

The answer should be 3. The leaf, its map, and the fold. Not 10,000. Not 40,000. Three.

The first implementation used a linear scan to find dirty nodes. It worked, but stabilization took 27 microseconds at 10,000 symbols. That sounds fast until you multiply it by the event rate. At 100K events per second, you're spending 2.7 seconds per second just on stabilization. The math doesn't work.

So I replaced the linear scan with a min-heap ordered by topological height. Nodes get processed parents-before-children, and only dirty nodes enter the heap. The same stabilization dropped to 250 nanoseconds. That's a 100x improvement from one data structure change.

But the heap alone wasn't enough. The fold node was still O(N) — it re-summed all 10,000 parents on every stabilization, even though only one parent changed. The fix was an incremental fold: track which parents changed during dirty propagation, then subtract the old value and add the new. O(1) per changed parent, regardless of how many parents exist.

That combination — heap-based propagation plus incremental fold — is what makes the whole thing work.

The delta algebra rabbit hole

Once the graph engine was fast, I needed to figure out how to send changes between distributed nodes. Not full values. Deltas.

This turned into a deeper problem than I expected. If you're sending deltas over a network, and the network can duplicate or reorder messages, your deltas need to be idempotent. Applying the same update twice has to produce the same result as applying it once.

That rules out relative patches like "increment price by 5." You need absolute patches: "set price to 150." It feels wasteful, but it's the only way to get effectively-once semantics without distributed transactions.

I ended up with a small algebra:

apply(Set(v), _)              = Ok v              -- replacement
apply(d, apply(d, v))         = apply(d, v)       -- idempotent
apply(diff(old, new), old)    = Ok new            -- roundtrip
compose(d, Remove)            = Remove            -- annihilation
compose(d, Set(v))            = Set(v)            -- right identity
apply(compose(d1,d2), v)      = apply(d2, apply(d1, v))  -- compatible

Six laws. Every one of them is verified by property-based tests across thousands of random inputs. If any law breaks, the commit is blocked.

The roundtrip property — apply(diff(old, new), old) = new — is the one that matters most. It means you can always reconstruct the new value from the old value and the delta. This is the foundation of checkpoint and replay.

The checkpoint/restore discovery

I had a hypothesis: if the graph is deterministic (same inputs always produce same outputs), and deltas are idempotent (retries are safe), then checkpoint/restore should be straightforward. Snapshot the leaf values, save them, and on recovery, restore the leaves and re-stabilize. The compute nodes don't need checkpointing — they'll recompute from their dependencies.

I wrote a chaos test to verify. Process 100 events. Crash at a random point. Restore from checkpoint. Continue processing. Compare the final output against an uninterrupted run.

I ran it at 100 different random crash points. All 100 produced the correct output.

That was the moment I knew the architecture was sound. Not because I proved it on paper, but because I tried to break it 100 times and couldn't.

The effect injection pattern

One of the less obvious decisions: every source of non-determinism goes through an injectable interface. Time, randomness, I/O — none of it is called directly. There's a module type:

module type EFFECT = sig
  val now : unit -> Time_ns.t
  val random_int : int -> int
end

Production uses the live clock. Tests use a deterministic clock that only advances when you tell it to. This means replay is truly deterministic — given the same inputs and the same effect implementation, you get the same outputs. Every time.

This pattern isn't original. Jane Street uses it extensively. But applying it to a distributed system — where you need deterministic replay across multiple nodes after a crash — makes it load-bearing infrastructure, not just a testing convenience.

What actually got built

The final system is 6,200 lines of OCaml across 16 libraries:

Graph engine — heap-based stabilization, incremental fold, cutoff optimization
Schema layer — type-safe schemas derived from OCaml types, backward/forward compatibility checking
Wire protocol — bin_prot serialization with CRC-32C integrity on every message
Delta transport — sequence-ordered delivery with gap detection and retransmission
Checkpointing — snapshot/restore with pluggable stores (memory, disk, S3)
Windowing — tumbling, sliding, session windows with watermark tracking
Observability — Prometheus metrics, W3C distributed tracing, graph introspection
Coordinator — consistent hashing, partition assignment, failure detection
Worker — lifecycle state machine with health endpoints

Three binaries: a VWAP demo pipeline, a worker process, and a CLI.

The numbers, measured not projected:

What	Measured
Stabilization at 10K symbols	250 ns
Serde roundtrip	82 ns
VWAP throughput	2.16M events/sec
6M event replay recovery	2.1 seconds
Heap growth over 1M events	0.1%

What I learned building it

Data structures matter more than algorithms. The 100x improvement from linear scan to min-heap wasn't a clever algorithm. It was picking the right data structure for the access pattern. The heap gives you O(R log R) where R is the number of dirty nodes. The linear scan gives you O(N) where N is the total graph. When R is 3 and N is 40,000, that's the whole game.

Algebraic properties are testable contracts. The six delta laws aren't documentation. They're property-based tests that run on every commit. When I accidentally introduced a non-idempotent patch variant (list insertion by index), the tests caught it immediately. The law apply(d, apply(d, v)) = apply(d, v) failed. I removed the variant. The algebra stays clean because the tests enforce it.

Chaos testing builds confidence that proofs can't. I could reason about why checkpoint/restore should work. I could trace through the logic. But running 100 random crash points and seeing 100 correct recoveries — that's a different kind of confidence. It's the difference between believing your parachute works and having jumped with it.

The pre-commit hook is the best decision I made. Every commit runs: build, all 117 tests, and a benchmark regression gate. If stabilization time exceeds 3 microseconds, the commit is blocked. Not a CI notification. Not a Slack alert. The commit literally does not happen. This means the benchmarks in the README are always true. They're not aspirational numbers from a good run six months ago. They're what the code does right now.

The experimentation process

The honest version: this didn't come out clean. The first graph engine was too slow. The first delta type had non-idempotent variants that I had to remove. The first fold was O(N) and I didn't realize it until the benchmark showed 42 microseconds instead of the expected 600 nanoseconds.

Each of those failures taught me something specific:

The slow engine taught me that O(N) scanning is the enemy, even when N feels small. 40,000 nodes at 50 nanoseconds per check is 2 milliseconds. That's invisible in a unit test and fatal at production event rates.

The non-idempotent delta taught me that algebraic properties aren't academic. They're the contract that makes distributed recovery work. If apply(d, apply(d, v)) != apply(d, v), your effectively-once guarantee is a lie.

The O(N) fold taught me to benchmark before trusting projections. I projected 600 nanoseconds. I measured 42,000. The projection was based on heap overhead per node. The measurement included the fold re-scanning every parent. The number you measure is the number that matters.

The beautiful part of this process is that each failure narrowed the design space. By the time I had the heap, the incremental fold, and the idempotent deltas, the architecture was almost inevitable. Not because I designed it top-down, but because the experiments eliminated everything else.

Try it

The whole thing is open source under MIT.

There's a live simulation on the landing page where you can watch the graph work — 50 symbols, trades arriving, only the affected path lighting up while everything else stays dark.

Landing page: https://copyleftdev.github.io/ripple/

Source: https://github.com/copyleftdev/ripple

git clone https://github.com/copyleftdev/ripple.git
cd ripple
make build
make demo    # 2M+ events/sec VWAP pipeline
make test    # 117 inline + property + load + chaos tests

If you work on trading systems, real-time analytics, or any pipeline where you're recomputing more than you should — take a look. The core insight is simple: track dependencies, propagate only what changed, make deltas idempotent. The rest is engineering.

Fuck Around and Find Out: How a $6.99 Phishing Scam Got 1.2 Million Fake Victims

Mr. 0x1 — Fri, 20 Mar 2026 22:09:31 +0000

A forensic teardown and hostile response to the Smishing Triad's Lighthouse phishing kit.

The Hustle

It started, as these things always do, with a text message.

California DMV Final Notice: Enforcement will begin on March 21.
Our system indicates you have an unresolved traffic violation.
Per relevant regulations, if payment is not completed by March 20, 2026, the following will apply:

Update your record in the DMV system

Suspend your vehicle registration starting March 21

Temporarily restrict driving privileges for 30 days

Refer your account for further processing with an additional administrative fee

Possible legal follow-up and impact to your credit record

Please settle this promptly to avoid service restrictions and additional procedures.
Link: https://ca.gov-axb.cfd/dmv

Classic. Urgency. Authority. Escalating consequences. A $6.99 "traffic violation" — just low enough that a panicked person might pay it without thinking. The link even starts with ca.gov- to give it that government feel, like the digital equivalent of a trench coat and a fake badge.

They sent this to the wrong phone.

The Forensics

Twenty-two hours. That's the entire lifespan of this operation from domain registration to active phishing campaign. Let's appreciate the speedrun:

Timestamp	Event
2026-03-19 14:10	Domain `gov-axb.cfd` registered via Gname.com (Singapore)
2026-03-20 ~12:17	Let's Encrypt SSL certificate issued for `ca.gov-axb.cfd`
2026-03-20 ~13:00	Smishing messages begin arriving

The domain was registered on a .cfd TLD — that's "Clothing Fashion Design," in case you were wondering what haute couture has to do with the California DMV. It costs about $0.98 to register. The attackers configured wildcard DNS pointing everything at 47.89.135.90 — an Alibaba Cloud server — so ca.gov-axb.cfd, tx.gov-axb.cfd, fl.gov-axb.cfd, and literally any subdomain you can dream up all resolve to the same phishing kit. Seven confirmed state-targeted subdomains on a single domain. Assembly line phishing.

The nameservers (share-dns.com, share-dns.net) are a Chinese DNS provider. The registrar abuse contact is in Singapore. The hosting is Alibaba Cloud's US allocation. It's a jurisdictional lasagna designed to make takedowns as painful as possible.

Meet the Kit: Lighthouse

The phishing page itself is a slick California DMV impersonation — official logo, official color scheme, footer links to real .ca.gov pages. It's built on Vue.js 3, bundled with Vite, communicating over Socket.IO with AES-128-CBC encrypted WebSocket messages. This isn't some amateur HTML form. This is a commercial product.

It's called Lighthouse — a phishing-as-a-service (PhaaS) platform operated by the Smishing Triad, a Chinese cybercrime operation that Google literally filed a federal lawsuit against in November 2025. The operator, attributed to someone going by Wang Duo Yu, runs a platform serving ~300 "front desk staff" worldwide, targeting 316+ brands across 74 countries through an estimated 194,000+ malicious domains.

The kit has a real-time operator panel. When a victim lands on the page, the operator sees their session appear in real time. As the victim fills in their name, address, credit card — the data streams live to the operator's dashboard. They can push the victim through verification steps in real time: "Enter the code we just sent to your phone." "Now enter your card PIN." It's live, interactive social engineering at industrial scale.

The victim flow:

Landing Page → Contact Info Form → Credit Card Form → Verification Codes → 💀

Every field submission, every page navigation, every keystroke-level interaction — all wrapped in AES encryption and shuttled over WebSocket. The kit even has anti-debugging protections in its JavaScript, string obfuscation tables, and mobile User-Agent gating (it won't even load if you're not on a phone browser).

They thought of everything.

Almost.

The Reverse Engineering

The kit's JavaScript is two files totaling ~570KB of heavily obfuscated code. Here's what that looks like:

function xe(){const t=["YWdl","message","Y2hhbm","Zmllb","c3VibW","bm90a..."];
// ... 260,000 more characters of this

Every meaningful string — event names, API paths, encryption keys — is routed through a deobfuscation function (be()) that indexes into a shuffled, Base64-encoded string table. The Socket.IO connection path isn't /socket.io/ like normal. It's been moved. The encryption key and IV aren't in plaintext. Nothing is where it should be.

Step 1: Find the Socket.IO Path

After failing to statically decode the obfuscation (the string table uses a self-modifying shuffle — it rearranges itself during initialization), I pivoted to empirical observation. Loaded the page in a headless browser with a mobile User-Agent, captured the WebSocket traffic:

wss://ca.gov-axb.cfd:443/console/?uuid=<uuid>&EIO=4&transport=websocket

The Socket.IO path is /console/. Not /socket.io/. Not /ws/. Not anything in the standard playbook.

Step 2: Crack the Encryption

All WebSocket messages are encrypted. Client sends 42["message","<base64>"], server responds the same way. The actual event data is AES-128-CBC encrypted inside that base64 blob.

From the obfuscated source, I could see the key and IV were assembled from string fragments:

const We = Be(226) + ye(250) + ze(254) + "LDND";   // AES key
const Se = "OJGJHHFMJEJB" + we(259);                // AES IV
Ne = CryptoJS.enc.Utf8.parse(We);                    // → WordArray
Te = CryptoJS.enc.Utf8.parse(Se);                    // → WordArray

The Be(), ye(), ze(), we() functions are all aliases for the same deobfuscator, returning short string fragments. I couldn't decode them statically — the shuffle function defeats that approach.

So I intercepted the JavaScript in flight. Using Playwright's route API, I caught the JS file as it loaded, injected a single line that exposed the computed key values to the global scope, and read them out:

await context.route('**/CPD9iRZf.js', async (route) => {
    const response = await route.fetch();
    let body = await response.text();
    body = body.replace(
        /Se="OJGJHHFMJEJB"\+\w+\(\d+\)/,
        (match) => match + ';window.__AES_KEY=We;window.__AES_IV=Se'
    );
    await route.fulfill({ response, body });
});

Key: KIKOCCJCFILDLDND
IV: OJGJHHFMJEJBDFAI

Verified by decrypting a captured server message:

{"data":{"money":"","successUrl":"","currencySymbol":"","products":[]},"event":"userSiteConfig"}

And a captured client message:

{"event":"changleField","data":{"router":"首页"}}

That typo — changleField instead of changeField — is a known Lighthouse kit fingerprint. It's in every deployment. Somewhere, a developer fat-fingered it once, and now it's a forensic signature stamped across 194,000 domains.

Also: 首页 is Mandarin for "home page." The Chinese-language strings are everywhere in the source: 手机验证页 (phone verification page), 运通CVV验证页 (Amex CVV verification page), 加密异常! (encryption exception!). For a kit that goes to great lengths to look like the California DMV, it sure does think in Mandarin.

The Weapon

With the encryption cracked and the protocol reverse-engineered, it was time to build.

Not a Python script. Not a Node.js hack. Rust. Specifically: an async, multi-session, zero-copy WebSocket flood engine using Tokio, with native AES-128-CBC encryption, realistic fake data generation, and the exact Socket.IO protocol the kit expects.

Each session:

Opens a WebSocket to /console/ with a mobile User-Agent
Completes the Engine.IO handshake
Sends the Socket.IO connect packet
Responds to server heartbeats (ping 2 → pong 3)
Encrypts and sends 12 events mimicking a complete victim session:
- Router navigation (changleField — yes, with the typo)
- Full personal info (name, address, city, state, zip, phone, email)
- Full credit card data (Luhn-valid card number, holder name, expiry, CVV)
- Phone verification code
- Email verification code
- PIN code
- Express CVV re-verification
- Custom verification code
Closes gracefully

Every piece of fake data is realistic:

Names drawn from US census frequency tables
Addresses with real California street patterns and cities
ZIP codes matching California postal zones
Phone numbers with correct California area codes
Credit cards that pass Luhn validation (Visa, Mastercard, Amex, Discover prefixes)
Email addresses with realistic username patterns at common providers

From the server's perspective, each session is indistinguishable from a real victim clicking through the phishing flow.

The Flood

╔══════════════════════════════════════════════════════════╗
║       LIGHTHOUSE FLOOD — Pure Rust WebSocket Engine     ║
║       AES-128-CBC | Direct Socket.IO | Max Throughput   ║
╚══════════════════════════════════════════════════════════╝
Target:       https://ca.gov-axb.cfd
WS Path:      /console/
Concurrency:  100
Count:        ∞

First test: 5 sessions, 3 concurrent. 60 events, 0 errors. Proof of concept.

Second test: 200 sessions, 30 concurrent. 2,400 events, 0 errors, 28 seconds. Warming up.

Third test: 1,000 sessions, 100 concurrent. 12,000 events, 0 errors, 42 seconds. Now we're talking. ~24 complete fake victims per second.

Then we let it rip.

╔══════════════════════════════════════════════════════════╗
║                     FLOOD COMPLETE                      ║
╠══════════════════════════════════════════════════════════╣
║  Submitted: 100700  |  Events: 1208984  |  Errors:    0 ║
╚══════════════════════════════════════════════════════════╝

One hundred thousand fake victim sessions. 1.2 million encrypted events. Zero errors.

One hour. One machine. One Rust binary. Their operator's dashboard — the same one they use to monitor real victims in real time — is now a firehose of:

Jennifer Wilson from San Jose, CA 95132, card ending in 8388
Kevin Sanchez from Chula Vista, CA 92101, card ending in 6501
Laura Martin from Santa Ana, CA 92701, card ending in 4787
... times one hundred thousand.

Every single entry looks real. Luhn-valid card numbers that'll fail at the processor. California addresses that go to actual streets. Phone numbers that ring actual area codes. The operators can't tell which data is real and which is garbage. Their entire database is poisoned.

For every real victim they managed to phish today, there are now thousands of fake records burying them. Good luck finding the needle in that haystack.

The Takeaway

This particular phishing operation is part of a massive, well-funded, commercially operated cybercrime ecosystem. The Smishing Triad runs Lighthouse as a business — subscription model, customer support, Telegram channels, the works. Google sued them. The FBI has received thousands of complaints. They're still operating.

Individual takedowns are whack-a-mole. The domain gov-axb.cfd will die, and tomorrow there'll be gov-xyz.cfd and gov-abc.win and a hundred more. The kit itself rotates, the infrastructure shifts, the TLDs change.

But today? Today, one specific operator's database is garbage. One specific campaign's ROI just cratered. One specific Lighthouse instance's real-time dashboard is scrolling fake Californians faster than any human could possibly triage.

They set up an encrypted, obfuscated, anti-debugging, mobile-gated phishing operation.

We reverse-engineered the encryption in an afternoon and flooded them with a million fake victims before dinner.

Fuck around. Find out.

Technical Summary

Component	Detail
Target	`ca.gov-axb.cfd` (California DMV phishing)
Threat Actor	Smishing Triad / Lighthouse PhaaS
Kit Stack	Vue.js 3 + Vite + Socket.IO + AES-128-CBC
Socket.IO Path	`/console/` (non-standard)
Encryption Key	`KIKOCCJCFILDLDND` (UTF-8)
Encryption IV	`OJGJHHFMJEJBDFAI` (UTF-8)
Kit Fingerprint	`changleField` typo in all event names
Flood Tool	Rust + Tokio + tungstenite (async WebSocket)
Sessions Completed	100,700+
Events Sent	1,208,984+
Error Rate	0.000%
Throughput	~24 complete victim sessions/second
Duration	~63 minutes

Filed under: threat intelligence, active defense, phishing disruption, and not taking shit from scammers.

I Got Sick of Getting Rugged, So I Built a Rug-Pull Detection Engine in Rust

Mr. 0x1 — Mon, 09 Mar 2026 15:37:16 +0000

TL;DR: I was tired of not knowing whether a token contract was about to drain my wallet. So I built Rugrat — a real-time EVM smart contract scanner that analyzes deployed bytecode for rug-pull patterns, runs on-chain state checks, and scores risk across 8 categories. It scans a contract in ~3 microseconds. No verified source code required. This is the story of why I built it and what I learned about adversarial smart contracts along the way.

The Problem No One Talks About Honestly

Here's the thing about crypto: everyone knows rug pulls happen. The stats are ugly — billions lost annually. But the tooling to detect them? It's either:

Too slow — waiting 30 seconds for a scan while the liquidity drains
Too dependent on verified source — most scam tokens never verify on Etherscan
Too shallow — checking if owner() returns zero and calling it a day
Too opaque — "Risk Score: 78" with no explanation of why

I'd been burned a few times. Not life-changing money, but enough to make me angry. And the anger wasn't at the scammers — it was at myself for not understanding what I was looking at. I could read Solidity, kind of. But when someone deploys a contract with a hidden fee function that can be cranked to 100% after launch? That's not in the README.

So I decided: I'm going to understand this problem deeply enough to build something that catches it.

Starting From Ground Truth

Before writing a single line of code, I needed data. Not vibes, not Twitter threads — labeled, verified data.

I collected datasets of confirmed malicious contracts and known benign ones from multiple research sources, covering rug-pull types like unauthorized minting, balance leaking, transfer limits, and several categories of honeypot traps.

Then I built offline tooling to analyze these corpora — computing precision and recall for dozens of pattern detectors against the labels.

What I Found

Some patterns are almost perfectly discriminative. A tradingEnabled boolean in the transfer path that the owner controls? Never appeared in a single benign contract in our dataset. Same for mutable max transaction amounts and anti-whale logic that can be toggled by the deployer.

The first "aha" moment: rug pulls aren't subtle. They're structurally distinct. The patterns are there — you just need to look at the right level.

And that level isn't Solidity source code. It's the bytecode.

Why Bytecode? Why Not Source Code?

Only ~30% of contracts on Ethereum are verified on Etherscan. Scam tokens almost never verify. If your scanner requires source code, you've already lost the battle.

Bytecode analysis covers 100% of deployed contracts. Every public function, every storage operation, every control flow path is encoded in the bytecode whether the deployer wants you to see it or not. You can't add comments to make SELFDESTRUCT look friendly.

Rugrat works directly on raw deployed bytecode. No Etherscan API key. No source code. No waiting for verification that will never come.

What Rugrat Actually Does

When you paste a contract address into Rugrat, here's what happens:

Static Analysis (~3 microseconds)

The engine examines the raw bytecode for structural patterns associated with rug pulls:

Function signatures — identifying risky admin functions (blacklisting, fee manipulation, minting, pause controls) even without source
Opcode patterns — detecting proxy mechanisms, kill switches, and hidden state manipulation
Compound rule evaluation — combining multiple signals across 8 risk categories, because individual features can be benign but certain combinations are not

Each contract gets a risk score with a full breakdown: which categories flagged, which specific patterns matched, and why they matter.

On-Chain State Checks

Static analysis tells you what a contract can do. On-chain checks tell you what it has done:

Ownership — Has the owner renounced? Or is someone still holding the keys?
Liquidity — Does a DEX pair exist? Is there real liquidity?
LP Lock Status — Is the liquidity provider token locked? In which locker? For how long?
Proxy Detection — Is this an upgradeable contract that can be swapped out?
Honeypot Simulation — Can you actually sell this token, or will the transaction fail?

This is where it gets decisive. A contract with a blacklist function and a non-renounced owner and unlocked liquidity and a failing sell simulation? That's not ambiguous.

The Result

You get a full risk report: overall score, risk level (Clean → Critical), category-by-category breakdown, specific findings with severity ratings, and the complete on-chain state. Everything explained, nothing hidden behind a magic number.

Real-Time Surveillance: The Live Feed

The scan-on-demand feature is useful, but the live feed is what changes how you think.

Rugrat monitors new contract deployments across 5 EVM chains — Ethereum, BSC, Base, Polygon, and Arbitrum. Every new contract gets scanned automatically and streamed to the UI in real-time via Server-Sent Events, color-coded by risk level.

Open the page. Watch. See what's deploying right now.

Watching the feed for 10 minutes and seeing how many contracts deploy with blacklist functions and mutable fees… it's eye-opening. The volume of contracts with risky patterns is much higher than most people expect.

Five Chains, One Scanner

The same detection pipeline works identically across all supported networks:

Chain	DEX Coverage
Ethereum	Uniswap V2
BSC	PancakeSwap V2
Base	Uniswap V2
Polygon	QuickSwap
Arbitrum	Camelot

Each chain has its own DEX routing, liquidity locker contracts, and native token configuration. The analysis is identical — same rules, same bytecode patterns, same risk categories. Select your chain and scan.

The Telegram Bot

The web UI is great for surveillance, but sometimes you just want to check a contract from your phone before aping in.

So I built a Telegram bot that runs the entire detection engine — same analysis, same on-chain checks, same risk scoring. No separate codebase, no watered-down version.

The flow:

Send /start — get a welcome message with all 5 supported chains
Paste any 0x... address — inline buttons ask which chain
Tap a chain — full scan report delivered right in the chat

Or use /scan eth 0x1234... for a one-shot command. Risk score, category breakdown, on-chain state, explorer link — all formatted and delivered in seconds.

It runs 24/7 as a lightweight background service. 12MB binary, ~10MB memory footprint.

Why Rust?

Speed was non-negotiable. If you're monitoring new contract deployments in real-time across 5 chains, each scan needs to take essentially no time. The actual bytecode analysis runs in ~3 microseconds — that's 300× under a 1ms budget.

The real bottleneck is network I/O to the RPCs (~200-500ms per eth_getCode call). The analysis itself is noise compared to fetching the data. That headroom means we can add more rules, more chains, and more checks without ever worrying about the scan engine.

What I Learned About Adversarial Smart Contracts

Building this changed how I think about the space:

1. Rug pulls are not sophisticated. Most use the same dozen patterns. The scammers aren't brilliant — they're using templates and tutorials. The problem isn't that scams are hard to detect. It's that nobody's looking at the bytecode.

2. Compound patterns beat individual signals. A mint function alone isn't malicious — ERC-20 tokens need it. But mint + blacklist + mutable fees + owner not renounced? That's a combination that appeared in malicious contracts 100% of the time in our dataset — and never in benign ones.

3. On-chain state is the tiebreaker. Static analysis tells you what a contract could do. Ownership status, liquidity locks, and honeypot simulation tell you whether it will.

4. The real arms race hasn't started. Current rug-pull techniques are detectable because nobody was systematically detecting them at the bytecode level. As scanners improve, attackers will evolve — metamorphic contracts, time-delayed activation, cross-contract splitting. But there's still enormous low-hanging fruit.

5. Speed is a feature, not a luxury. If your scanner takes 30 seconds and the rug pull executes in block N+1, your scan result arrives at block N+3. Too late. Microsecond analysis means you can scan before deciding to trade.

What's Next

Behavioral analysis — Post-deployment transaction pattern monitoring
Cross-contract analysis — Factory patterns, deployer reputation
Uniswap V3 support — Concentrated liquidity honeypot simulation
API for integrators — Let wallets and DEX frontends query risk scores before users swap

Try It

Live: https://rugrat.network

Paste any contract address. Pick a chain. See the full risk breakdown in microseconds.

Or watch the live feed and see what's deploying right now. You might be surprised.

Rugrat — fast little snitch for shady contracts.

How I Found $300,000 Worth of Secrets in a Download Button

Mr. 0x1 — Wed, 04 Feb 2026 08:05:33 +0000

A tale of curiosity, incompetence, and why you should never trust a software engineer who makes more than you.

In Which I Click a Button Like a Normal Person

It started, as most disasters do, with mild curiosity and a free afternoon.

I downloaded an application. Not because I'm a hacker. Not because I'm conducting corporate espionage. Not because I have any idea what I'm doing. I downloaded it because I wanted to use it.

Revolutionary concept, I know.

The installer was a .exe file. For the uninitiated, this is the software equivalent of a wrapped gift. And like any gift from a stranger on the internet, I decided to unwrap it.

"What's inside?" I wondered, the way a child wonders what's inside a clock before destroying it with a hammer.

The Electron Inside

Every modern desktop application, it turns out, is just a website pretending to be software.

It's like finding out your "homemade" meal came from a freezer bag—technically real, philosophically disappointing.

This particular application was built with Electron, which means somewhere inside was a file called app.asar. Think of it as a zip file that really, really wants you to think it's not a zip file.

I extracted it:

npx asar extract app.asar ./unpacked

Inside was JavaScript. Thousands of lines of minified, obfuscated JavaScript that looked like someone had sneezed on a keyboard and called it architecture.

And there, sitting in the open like a wallet on a park bench, was a .env file.

The .env File, or: How to Fail at Security 101

For those blissfully unaware, a .env file is where developers store secrets. API keys. Database credentials. The sort of things you absolutely, positively, under no circumstances should ship to production.

It's Security 101. Literally. It's the first thing they teach you:

🚨 Rule #1 of Software Development: Don't commit your .env file.

This is not advanced knowledge. This is not arcane wisdom passed down through generations of security researchers.

This is the "wash your hands after using the bathroom" of software development.

And yet.

There it was. Gleaming. Unencrypted. Full of credentials.

What I Found

I won't name names. I won't point fingers. I'll simply describe what I found, in the same way a nature documentary describes a lion eating a gazelle: with clinical detachment and mild horror.

Discovery	Severity	My Reaction
API Keys	🔴 Critical	Multiple. Active. Expensive.
Infrastructure URLs	🔴 Critical	Internal endpoints. Very not public.
Service Credentials	🟠 High	Analytics logging everything.
ML Inference Endpoints	🟠 High	Cloud GPUs go brrrr on their dime.

The total potential exposure?

Let's just say it was significant enough that I briefly considered a career change.

The $300,000 Question 💸

Now, here's where it gets personal.

The engineer who shipped this? Based on industry averages, location, and the general state of the tech job market, they're probably making around $300,000 a year.

Three. Hundred. Thousand. Dollars.

To do the software equivalent of leaving your house keys under the doormat, except the doormat is see-through and you've put up a sign that says "KEYS UNDER HERE."

I'm not bitter. I'm not bitter at all.

I am simply noting, for the record, that I—a person of humble curiosity—managed to find this in approximately forty-five minutes of casual investigation while eating leftover pizza.

Meanwhile, somewhere, a senior software engineer is collecting stock options.

📍 Plot twist: The pizza was cold. The credentials were not.

The Investigation Continues

Having found the obvious vulnerabilities, I did what any responsible researcher would do: I kept looking.

The JavaScript bundle was minified, but minification is obfuscation in the same way a trench coat is a disguise. It technically conceals things, but anyone who looks for more than five seconds can see what's underneath.

I found:

🗂️ Source map hints pointing to internal repositories
🐛 Debug symbols that should have been stripped
📋 Hardcoded configuration copy-pasted from dev
📡 gRPC definitions outlining the entire API structure

Each discovery was like opening a nesting doll, except instead of smaller dolls, it was smaller failures.

The Moral of the Story

If you've made it this far, you might be expecting a dramatic conclusion. A confrontation with the company. A bug bounty payout. A heartfelt apology from a CEO.

Instead, I'll offer you something more valuable: a lesson.

To the Developers 👩‍💻

Your build pipeline is not a security feature. Electron apps are zip files with extra steps. Minification is not encryption.

And for the love of all that is holy, check what you're shipping before you ship it.

# Before you ship, maybe run:
npx asar extract your-app.asar ./check-this
grep -r "API_KEY\|SECRET\|PASSWORD" ./check-this

To the Companies 🏢

That engineer you're paying $300,000?

Maybe budget $50 for a security audit. I'll do it. I'm available. I have pizza.

To the Users 👤

Every application you download is a mystery box.

The mystery is usually "how badly is my data being handled?"

The answer is usually "badly."

Responsible Disclosure

I want to be clear: I didn't exploit anything.

I didn't access systems I wasn't supposed to. I looked at what was shipped to me, as a user, in an application I downloaded from their official website.

Everything I found was sitting in a package that anyone with fifteen minutes and a search engine could have extracted. The only sophisticated tool I used was npm and a vague sense of disbelief.

This article names no names. Points no fingers that haven't already been pointed by the act of shipping credentials in a desktop application.

Epilogue: The Download Button

I still use the application. It's actually quite good.

I just use it with the quiet knowledge that somewhere, in a data center, there's a server running endpoints I wasn't supposed to know about, processing requests through an API I could technically call, protected by credentials that are sitting in my Downloads folder.

The download button that started all this sits innocently on their website, cheerfully inviting users to install their app.

Beneath it, there should probably be a disclaimer:

"By downloading this software, you agree to receive a free education in application security."

TL;DR Checklist

If you ship Electron apps, please check:

[ ] No .env files in your build
[ ] No hardcoded API keys
[ ] No internal URLs exposed
[ ] No debug symbols in production
[ ] Source maps are NOT included
[ ] You've actually looked inside your .asar file

If you found credentials in your own app while reading this, you're welcome.

If you're the $300k engineer who shipped this... we should talk.

The author is a security researcher in the same way that someone who finds a wallet on the ground is a "detective." DMs are open. Pizza recommendations welcome.

I Replaced My LLM Orchestrator with Plant Biology — Here's What Happened

Mr. 0x1 — Tue, 20 Jan 2026 16:49:41 +0000

What if your AI agents coordinated like plants instead of following a script?

That question led me down a rabbit hole that ended with Robin×SMESH — a dark web OSINT framework where agents discover, scrape, and analyze threat intelligence through signal diffusion rather than central orchestration.

The Problem: LLM Pipelines Are Fragile

The original Robin is a solid Python tool for dark web reconnaissance. It queries .onion search engines, filters results with an LLM, scrapes content, and extracts IOCs. Classic pipeline architecture:

Query → Search → Filter → Scrape → Extract → Analyze

But pipelines have problems:

Single point of failure — One timeout kills everything
Sequential bottlenecks — Each stage waits for the previous
No emergent behavior — Agents can't adapt or collaborate
Rigid orchestration — Adding new capabilities means rewriting the controller

I wanted something more... organic.

Enter SMESH: Plant-Inspired Coordination

SMESH (Signal-Mediated Emergent Swarm Heuristics) is a coordination protocol inspired by how plants communicate through chemical signals.

Plants don't have brains, yet they:

Coordinate growth toward light across millions of cells
Respond to threats by releasing warning chemicals
Share resources through root networks
Adapt to damage without central control

The key insight: coordination emerges from simple local rules + shared signals.

How SMESH Works

┌────────────────────────────────────────────────────────────┐
│                    SHARED SIGNAL FIELD                      │
│   Signals decay over time · Reinforcement = consensus       │
│              No central controller                          │
└────────────────────────────────────────────────────────────┘
       ▲              ▲              ▲              ▲
  ┌────┴────┐    ┌────┴────┐    ┌────┴────┐    ┌────┴────┐
  │ Agent A │    │ Agent B │    │ Agent C │    │ Agent D │
  └─────────┘    └─────────┘    └─────────┘    └─────────┘

Each agent follows three rules:

Sense — Detect signals above your threshold
Process — Do your specialized work
Emit — Broadcast results as new signals

Signals have:

Intensity — How "loud" the signal is (decays over time)
Confidence — How reliable (multiple agents agreeing = reinforcement)
TTL — Time-to-live before signal dies

No agent knows the full plan. Coordination emerges.

Marrying Robin + SMESH

Here's how I mapped OSINT operations to signal types:

Signal Type	Emitter	Consumer	Purpose
`UserQuery`	CLI	Refiner	Initial investigation request
`RefinedQuery`	Refiner	Crawlers	Optimized search terms
`RawResults`	Crawlers	Filter	.onion URLs from search engines
`FilteredResults`	Filter	Scrapers	Relevant URLs only
`ScrapedContent`	Scrapers	Extractor, Analyst	Page content
`ExtractedArtifacts`	Extractor	Enricher, Analyst	IOCs (IPs, emails, hashes)
`EnrichedArtifacts`	Enricher	Analyst	Surface web context
`Summary`	Analyst	CLI	Final intelligence report

The magic: agents don't know about each other. The Crawler doesn't call the Filter. It just emits RawResults signals. The Filter happens to be listening for those.

Key Discovery #1: Fault Tolerance for Free

With the pipeline approach, if one Tor request times out, you need retry logic, circuit breakers, and error handling spaghetti.

With SMESH? Signals just decay. Other crawlers pick up the slack. If crawler-1 fails to emit results for a query, crawler-2 and crawler-3 might succeed. The Field doesn't care who produces the signal — it just propagates whatever arrives.

// No error handling needed at the orchestration level
// Agents fail silently, signals decay, life goes on
for agent in &mut self.agents {
    let _ = agent.process(&mut self.field).await;
}
self.field.tick(); // Advance time, decay signals

Key Discovery #2: Multi-Agent Consensus

When multiple crawlers find the same URL, the signal gets reinforced:

pub fn reinforce(&mut self, signal_hash: &str, boost: f64) {
    if let Some(signal) = self.signals.get_mut(signal_hash) {
        signal.confidence = (signal.confidence + boost).min(1.0);
    }
}

This is huge for filtering noise. URLs that appear in multiple search engines naturally bubble up. Duplicate artifacts get higher confidence scores. Agreement = signal strength.

Key Discovery #3: Specialists Emerge from Personas

I defined agent behaviors in TOML files:

# prompts/analyst_threat_intel.toml
[persona]
name = "Threat Intelligence Analyst"
role = "specialist"

[persona.expertise]
primary = "Threat actor TTPs and campaign analysis"
domains = [
    "APT group identification",
    "Malware family classification",
    "Attack pattern recognition",
]

Now I can run 6 specialist analysts in parallel, each sensing the same signals but interpreting through different lenses:

🎯 Threat Intel — Actor TTPs, campaigns
💰 Financial Crime — Crypto flows, money laundering
🔐 Technical — Malware, exploits
🌍 Geopolitical — Nation-state attribution
⚖️ Legal — Evidence handling, jurisdiction
🔮 Strategic — Trend forecasting

A lead analyst then synthesizes their reports. Emergent multi-perspective analysis.

Key Discovery #4: Bridging Dark ↔ Surface Web

The EnrichmentAgent was a late addition that proved surprisingly powerful:

// When we extract an email from a dark web forum...
let artifact = Artifact { 
    artifact_type: ArtifactType::Email,
    value: "h4ck3r@protonmail.com".into(),
};

// ...query GitHub for commits with that email
let github_results = self.search_github(&artifact).await;

// ...and Brave Search for breach mentions
let brave_results = self.search_brave(&artifact).await;

Dark web pseudonyms often leak into legitimate platforms. GitHub commits, forum posts, domain registrations. The enricher finds these connections automatically.

The Architecture

robin-smesh/
├── robin-core/      # Signals, artifacts, field mechanics
├── robin-tor/       # Tor proxy, crawlers, scrapers
├── robin-agents/    # Specialized OSINT agents
│   ├── refiner.rs   # Query optimization
│   ├── crawler.rs   # .onion search engines
│   ├── filter.rs    # LLM-based relevance filtering
│   ├── scraper.rs   # Content extraction
│   ├── extractor.rs # IOC/artifact identification
│   ├── enricher.rs  # Surface web correlation
│   └── analyst.rs   # Intelligence synthesis
├── robin-runtime/   # SMESH swarm coordinator
└── robin-cli/       # User interface

Results: Before vs After

Metric	Python Robin	Robin×SMESH
Fault tolerance	Manual retries	Automatic via decay
Parallelism	ThreadPool	N independent agents
Analysis depth	Single LLM call	6 specialists + synthesis
Extensibility	Modify pipeline	Add new agent type
Dark↔Surface bridge	None	GitHub + Brave enrichment

Try It Yourself

# Clone and build
git clone https://github.com/copyleftdev/robin-smesh
cd robin-smesh
cargo build --release

# Run with multi-specialist analysis + enrichment
ANTHROPIC_API_KEY=sk-ant-... ./target/release/robin-smesh query \
  -q "ransomware bitcoin wallets" \
  --specialists \
  --enrich \
  --timeout 300

What I Learned

Bio-inspired != bio-realistic — I'm not actually simulating plant hormones. I'm borrowing the abstraction of signal-mediated coordination.
Emergence requires constraints — Agents need clear sensing thresholds and signal types. Too much freedom = chaos.
Decay is a feature — Letting signals die naturally is more elegant than explicit garbage collection.
LLMs are better as specialists — Instead of one god-model orchestrating everything, use focused experts that emit structured signals.
The dark web is surprisingly chatty — Threat actors reuse emails, leak usernames, and leave breadcrumbs across platforms. Automated enrichment catches what manual analysis misses.

What's Next

More enrichment sources — Shodan, VirusTotal, Have I Been Pwned
Signal visualization — Real-time field state dashboard
Agent breeding — Spawn more of whichever agent type is most productive
Cross-investigation memory — Signals that persist across runs

The code is MIT/Apache-2.0 licensed at github.com/copyleftdev/robin-smesh.

If you've experimented with swarm intelligence or bio-inspired AI, I'd love to hear about it. Drop a comment or find me on GitHub.

Happy hunting. 🕸️

Optimizing LLM Context Windows: Reducing Token Usage by 40% with TOON and Rust

Mr. 0x1 — Sat, 17 Jan 2026 07:37:02 +0000

Abstract

As Large Language Models (LLMs) integration becomes ubiquitous in distributed systems, the cost of context window consumption has emerged as a critical infrastructure metric. While JSON remains the de facto standard for data interchange, its syntactic verbosity imposes a measurable "token tax" on every API call. This article introduces TOON (Token-Oriented Object Notation), a data serialization format designed explicitly for LLM token efficiency, and details the implementation of a Model Context Protocol (MCP) server in Rust. We demonstrate how this architecture achieves an 18-40% reduction in token usage while maintaining type safety and interoperability.

1. The Economics of Context

In the modern AI stack, tokens are a finite capability and a direct cost center. Whether you are running inference on OpenAI's GPT-4, Anthropic's Claude 3.5, or a self-hosted Llama 3, the billing model remains consistent: you pay for what you send.

Standard JSON, while human-readable and universally supported, is suboptimal for token-based pricing models. Consider the structural redundancy in a typical array of objects:

[
  { "id": "u_001", "name": "Alice Corp", "access_level": "admin", "region": "us-east-1" },
  { "id": "u_002", "name": "Bob Ltd", "access_level": "write", "region": "eu-west-1" },
  { "id": "u_003", "name": "Charlie Inc", "access_level": "read", "region": "ap-northeast-1" }
]

Every repeated key ("access_level", "region") and every predictable delimiter consumes context window space. For large datasets—such as RAG (Retrieval-Augmented Generation) payloads, log analysis, or historical data ingestion—this overhead accumulates rapidly, increasing both latency and operational expendature.

2. The Solution: Token-Oriented Object Notation (TOON)

TOON was architected to solve this specific inefficiency. It eliminates redundant keys and minimizes syntactic noise without sacrificing the schema-less flexibility that makes JSON attractive.

The previous example, encoded in TOON:

users[3]{id,name,access_level,region}:
  u_001,Alice Corp,admin,us-east-1
  u_002,Bob Ltd,write,eu-west-1
  u_003,Charlie Inc,read,ap-northeast-1

Key Technical Characteristics

Header-Row Schematization: Keys are defined once per object list, drastically reducing character count.
Minimal Delimiters: Commas and newlines replace heavy bracketing.
Type Inference: The format supports strict typing while allowing for concise representation.

In our benchmarks, this transformation yields a consistent 30-40% reduction in token count for array-heavy structures.

3. System Architecture: The Rust MCP Server

To operationalize TOON, we leveraged the Model Context Protocol (MCP). MCP provides a standardized interface for AI models to interact with external tools and data contexts. By wrapping the TOON logic in an MCP server, we decouple the implementation from the client, allowing any MCP-compliant agent (Claude Desktop, Cursor, IDE assistants) to utilize these optimization tools natively.

3.1 Why Rust?

We selected Rust for the server implementation (toon-mcp) to satisfy three non-functional requirements:

Zero-Cost Abstractions: The serde ecosystem allows for high-performance serialization/deserialization with minimal memory overhead.
Safety: Rust's ownership model ensures memory safety without a garbage collector, crucial for continuous-running sidecar processes.
Portability: Compiling to a single, static binary simplifies the deployment of the MCP server across diverse engineering environments.

3.2 Tool Implementation

The server exposes a suite of distinct tools via the MCP protocol. The core logic is defined using the rmcp SDK's procedural macros, ensuring type-safe interfaces between the LLM and the Rust runtime.

The `toon_encode` Tool

This functional primitive accepts a generic JSON value and returns the compressed TOON string.

// Simplified signature for the MCP tool handler
#[tool(
    name = "toon_encode",
    description = "Optimizes JSON payloads into TOON format for token efficiency."
)]
pub fn encode(args: EncodeArgs) -> Result<EncodingResult, Error> {
    let options = args.options.unwrap_or_default();
    let toon_string = toon::to_string_with_options(&args.json, options)
        .map_err(|e| Error::custom(format!("Serialization failed: {}", e)))?;

    Ok(EncodingResult { content: toon_string })
}

The server also enables toon_decode for bi-directional interoperability (allowing the LLM to output TOON for the system to process) and toon_stats, a utility for realtime cost-benefit analysis.

4. Integration & Real-World Usage

Deploying the toon-mcp server involves a simple configuration addition to your MCP client (e.g., claude_desktop_config.json). Once active, the LLM treats toon_encode as a native capability.

Agent Workflow Example

When tasked with analyzing a large log file, an agent equipped with toon-mcp can autonomously optimize its context:

Agent Logic: Recognizes a large JSON dataset in the prompt.
Tool Invocation: Calls toon_encode(json=dataset).
Context Injection: Receives the compact TOON string.
Analysis: Processes the data using significantly fewer tokens.

This workflow is transparent to the end-user but results in faster inference and lower bills.

5. Benchmark Results

We conducted a series of tests against standard datasets to quantify the efficiency gains.

Dataset Type	Size (JSON)	Size (TOON)	Reduction (Bytes)	Est. Token Reduction
User Logs (1k rows)	145 KB	92 KB	36%	~38%
E-commerce Config	24 KB	19 KB	21%	~20%
Geo-spatial Points	512 KB	290 KB	43%	~45%

Note: Token counts are estimated using the cl100k_base tokenizer (GPT-4).

Conclusion

The toon-mcp server represents a pragmatic application of systems engineering to the problem of AI operational costs. By combining the efficiency of the TOON format with the performance of Rust and the standardization of MCP, we have created a robust tool for modern AI workflows.

For engineers looking to optimize their LLM infrastructure, toon-mcp captures the ethos of doing more with less—less latency, less cost, and less waste.

Repository:

copyleftdev / toon-mcp

MCP server for TOON format - token-efficient JSON alternative for LLM prompts

TOON MCP Server

MCP server exposing TOON format for LLM cost optimization. 18-40% token savings over JSON.

Repository: github.com/copyleftdev/toon-mcp

Demo

Installation

cargo build --release

Usage

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "toon": {
      "command": "/path/to/toon-mcp"
    }
  }
}

Claude Code CLI

Add to ~/.claude/settings.json:

{
  "mcpServers": {
    "toon": {
      "command": "/path/to/toon-mcp"
    }
  }
}

Or for project-specific configuration, create .mcp.json in your project root:

{
  "mcpServers": {
    "toon": {
      "command": "/path/to/toon-mcp"
    }
  }
}

Cursor IDE

Add to .cursor/mcp.json in your project:

{
  "mcpServers": {
    "toon": {
      "command": "/path/to/toon-mcp"
    }
  }
}

Generic MCP Client

The server uses stdio transport. Connect by spawning the process and communicating via stdin/stdout:

# Start server and send initialize request
echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"my-client","version":"1.0"}}}' | ./toon-mcp

…

View on GitHub

The Infinite Buffer: Why AI Agents Are Rebuilding the Lisp Machine

Mr. 0x1 — Tue, 13 Jan 2026 17:57:53 +0000

1. The GUI Trap

For the last decade, the evolution of software development tools has been driven by a single imperative: Visual Ergonomics. We built tools like VS Code, IntelliJ, and Zed to be visually intuitive for human eyes. We optimized for pixel-perfect rendering, mouse interactions, and discoverability via menus.

But with the rise of Large Language Models (LLMs), this "Visual Imperative" has become a liability.

When an AI Agent tries to use a modern IDE, it encounters a wall of opaque pixels. To perform a simple action—like opening a file or running a test—it often has to navigate complex accessibility trees or hallucinate coordinate clicks. The very features that make IDEs friendly to humans make them hostile to machines.

2. Text as the Universal Solvent

Intelligence, in its current artificial form, is fundamentally text-processing at scale.

If we want to build a true "AI Control Plane," we must abandon the notion of the screen. An efficient AI environment should not be a collection of buttons; it should be a collection of Buffers.

Filesystem: Instead of a file tree widget, the AI needs a text buffer listing files (like dired).
Process Management: Instead of a "Terminal Tab," the AI needs a read-eval-print loop (REPL) where input and output are just strings.
State: Instead of hidden memory structures, the AI needs a text representation of the editor's own state.

In this paradigm, reading the state of the world is just read(), and changing the world is just write(). The friction of "UI navigation" disappears.

3. The Return of the Lisp Machine

This isn't a new idea. It is the philosophy of the Lisp Machine, seemingly lost to history but preserved in one enduring artifact: Emacs.

Emacs is often mocked for being "an operating system lacking a decent editor," but that architectural quirk is exactly what AI Agents require. In Emacs (and Lisp environments generally), there is no distinction between the "Editor" and the "User Code." Everything is data. Everything is malleable.

Introspection: An agent can query the documentation of a function it is about to call.
Extensibility: An agent can redefine a buggy function at runtime without restarting the environment.

This Code/Data Duality (Homoiconicity) allows the agent to be a participant in the system, not just an external operator.

4. ZEMACS: A Reference Implementation

To demonstrate this architecture, we built ZEMACS.

ZEMACS is a "Headless Control Plane" that exposes the semantics of a Lisp Machine over the Model Context Protocol (MCP). It strips away the GUI entirely, leaving only the pure textual essence of the editor.

It provides the AI with:

Universal Search: grep and find as first-class primitives.
Persistent REPLs: Stateful Python/Bash sessions that persist across "thoughts."
LSP Integration: Type definitions and diagnostics as text streams.

By treating the "Editor" as a textual API rather than a visual application, we found that agents became significantly more capable, autonomous, and reliable.

5. Conclusion

The future of AI-assisted coding isn't a better chatbot in your sidebar. It is a fundamental architectural shift back to text-centric computing.

As we build the next generation of developer tools, we should stop trying to build "Better GUIs for AIs." We should be building Infinite Buffers. We should be rebuilding the Lisp Machine.

Because in the end, for an AI, text isn't just an interface. It's the whole world.

I Asked My Dog How Trees Talk. Now I'm Rethinking LLM Orchestration.

Mr. 0x1 — Tue, 06 Jan 2026 04:47:49 +0000

A hippie's journey from forest walks to sub-microsecond signal processing.

The Walk That Started Everything

I was walking my dog last month. Nothing special—just the usual loop through the neighborhood, past the old oaks and overgrown hedges.

But I kept looking at the trees.

Not in a "oh, pretty leaves" way. More like... really looking. The way they grew toward each other. How the roots of different species seemed to know where the others were. How a whole grove of aspens will change color at almost the same time.

I turned to my dog and said out loud: "How do you think these things talk to each other?"

She didn't answer. (She's not that kind of dog.)

But the question wouldn't leave me alone.

Down the Rabbit Hole

So I did what any reasonable person does at 11pm on a Tuesday: I fell down a research rabbit hole.

Turns out, plants do communicate. And it's wild.

The Wood Wide Web

Forests have an underground network of fungal threads called mycorrhizal networks—scientists literally call it the "Wood Wide Web." Trees use it to:

Send chemical signals when they're under attack
Share nutrients with struggling neighbors (even different species!)
Warn each other about incoming pests
Coordinate responses without any central controller

There's no "master tree" running the show. No message queue. No orchestrator. Just... signals diffusing through a shared medium, decaying over time, getting reinforced when multiple trees "agree."

And I thought: wait, that sounds like the opposite of how we build AI systems.

The LangChain Problem

At work, I'd been wrestling with multi-agent LLM systems. You know the drill:

chain = agent_1 | router | agent_2 | aggregator | agent_3

Central orchestration. Explicit routing. If agent_2 times out, the whole thing dies. Every new agent means updating the router logic. Debugging is a nightmare because you're tracing through a rigid DAG.

It works. But it felt... brittle.

Meanwhile, a forest coordinates millions of trees across decades without a single config file.

What if we built LLM coordination the way forests work?

From Hypothesis to Validation

I'm not one to just vibe on an idea. I needed to know if this would actually work.

So I built a simulation framework. Python first (because fast iteration), then Rust (because I'm not a monster who deploys Python to production).

The Hypothesis

If agents communicate via decaying signals in a shared field, and consensus emerges through reinforcement rather than explicit voting, we can achieve:

Better fault tolerance

Lower coordination overhead

Emergent behavior without explicit choreography

The Method

I used simulated annealing to explore the parameter space:

Decay rates (exponential, linear, sigmoid)
Reinforcement thresholds
Trust propagation models
Network topologies (ring, mesh, small-world, scale-free)

Thousands of simulations. Different failure modes. Byzantine agents. Network partitions.

The Results

Metric	Traditional Orchestration	Signal Diffusion
Coordination latency	10-50ms	~1μs
Failure recovery	Manual intervention	Automatic decay
Scaling behavior	O(n) routing complexity	O(1) emit to field
Consensus mechanism	Explicit voting/aggregation	Emergent via reinforcement

The numbers were almost too good. I re-ran everything three times.

It actually works.

Building SMESH

So I built the real thing. SMESH (Signal-MESHing)—a plant-inspired coordination protocol for multi-agent LLM systems.

The Core Ideas

1. Signals, Not Messages

Instead of sending messages to specific agents, you emit signals into a shared field. Any agent can sense signals that match their interests.

let signal = Signal::builder(SignalType::Task)
    .payload(b"review this code".to_vec())
    .intensity(1.0)  // Will decay over time
    .confidence(0.9)
    .build();

field.emit(signal);

2. Decay Is a Feature

Signals lose intensity over time. Stale tasks fade away naturally. No garbage collection. No manual cleanup. The system forgets things that don't matter anymore.

3. Reinforcement = Consensus

When multiple agents observe the same signal and reinforce it, confidence goes up. Consensus emerges from agreement, not from a voting protocol.

4. No Central Controller

Every node is equal. There's no orchestrator to become a bottleneck. No single point of failure. Agents self-organize based on skill affinity and signal sensing.

The Numbers Don't Lie

After porting to Rust and optimizing:

Operation	Time
Signal creation	216 nanoseconds
Signal reinforcement	48 nanoseconds
Field tick (10k signals)	1.2 milliseconds

That's not a typo. Nanoseconds.

For comparison, a single HTTP request to an LLM takes ~500ms. The coordination overhead is now completely negligible.

The Trippy Part

Here's what I didn't expect: emergent behavior.

In simulations with 20+ agents, patterns started appearing that I never programmed:

Agents naturally specialized based on which signals they reinforced most
"Reputation" emerged—agents that consistently provided good signals got reinforced more
The system developed something like memory through signal history patterns

I was just trying to copy how trees talk. I accidentally built something that learns.

Try It Yourself

SMESH is open source. MIT/Apache-2.0. Steal it, fork it, tell me I'm wrong.

git clone https://github.com/copyleftdev/smesh-rust
cd smesh-rust
cargo build --release

# Watch signals flow
cargo run --bin smesh -- sim --nodes 50 --ticks 100

# Compare with your LLM
cargo run --bin smesh -- compare

It supports both Ollama (local, free) and Claude (API) out of the box.

What I Learned

Nature solved this already. Forests have been coordinating distributed systems for 400 million years. Maybe we should pay attention.
Decentralization isn't just political. It's an engineering pattern that eliminates bottlenecks and single points of failure.
Let things decay. Not every piece of state needs to be persisted forever. Sometimes the best garbage collection is just... time.
Emergence > Choreography. The most interesting behaviors come from simple rules interacting, not from complex orchestration logic.
Walk your dog. The best ideas come when you're not trying to have them.

What's Next

Python bindings (for the Pythonistas)
WebAssembly build (for browser-based agents)
Formal verification of convergence properties
A paper, maybe? (If anyone wants to collaborate, DM me)

But mostly, I'm going to keep walking my dog and looking at trees.

Who knows what I'll accidentally discover next.

If you build something cool with SMESH, I want to hear about it. Find me on GitHub @copyleftdev or drop a comment below.

Star the repo if this resonated: github.com/copyleftdev/smesh-rust

🌿 The Takeaway

"The forest doesn't have a Kubernetes cluster. But it's been running a distributed consensus protocol for longer than animals have existed."

Maybe the next breakthrough in AI infrastructure isn't in a whitepaper.

Maybe it's in your backyard.

P.S. — My dog still doesn't know how trees talk. But I think I'm getting closer.

I wrote a Vibe Check for your code (Runs on a Potato 🥔)

Mr. 0x1 — Mon, 29 Dec 2025 07:44:07 +0000

You know that feeling when you push code at 3 AM and you're pretty sure you left a // FIXME: this is garbage somewhere?

Yeah. We all do.

So I wrote a tool to find it. But not just "find it"—I wanted a tool that would look me in the eye and tell me my vibes were off.

Meet VibeCheck 🤙

VibeCheck is a high-performance Zig CLI tool that scans your codebase for "unfinished vibes"—To-Dos, hardcoded secrets, debug prints, and other signs of developer desperation.

It builds to a single ~149KB static binary. No runtime. No node_modules black hole. It runs on my laptop, my server, and probably my smart fridge.

Why? (The Vibe)

Linters check syntax. Static analysis checks logic. VibeCheck checks your soul.

It comes with a built-in pack called Crucial Vibes:

Desperation: FIX ME, XXX
Mock Data: lorem ipsum, John Doe
Fragile Paths: localhost:3000
Security Laziness: verify=False, chmod 777

If it finds them, it lets you know. Loudly.

The Specs (The Flex)

I built this in Zig because I wanted it to be fast and small.

Size: 149KB (Statically linked, stripped)
Speed: Scanned a 50,000 file monorepo in < 1 second.
Deps: Zero. None. Nada.
AI Mode: It has a built-in MCP Server so you can plug it into Claude Desktop and let the AI vibe check your code. 🤖

Usage

It's simple.

# Human readable scan
vibecheck .

Output:

[WARN]  Desperation Marker (FIXME)
  src/main.js:42:10
    | // FIXME: terrible hack, remove before launch

Or plug it into CI/CD to fail the build if the vibes are off:

vibecheck . --json

Get It

It's open source (MIT).

copyleftdev / vibecheck

High-performance static analysis tool for developer vibes. Finds TODOs, secrets, and code smells in milliseconds. Written in Zig (~149KB). Native MCP Server for AI Agents.

VibeCheck 🤙

"Yes, I even vibe checked vibe check 🤯"

VibeCheck is a high-performance Zig CLI tool that scans your codebase for "unfinished vibes"—To-Dos, hardcoded secrets, debug prints, and other signs of developer desperation.

It's fast, configurable, and CI/CD ready.

Features

⚡ Blazing Fast: Recursively scans thousands of files in milliseconds.
🪶 Featherweight: ~149KB static binary. Zero dependencies. Runs on a potato 🥔 🎤
📦 Portable: Single executable. Linux, Mac, Windows. No node_modules in sight.
🛡️ Battle Tested: Validated against a 50,000-file "Google-scale" monorepo.
🧩 Modular: Load custom pattern packs via JSON plugin system.
🤖 CI/CD Native
- Non-zero exit codes for build failures.
- JSON output for machine parsing.
- GitHub Actions Annotations support (--github).
🧠 AI Ready: Built-in Model Context Protocol (MCP) Server.

Installation

Build from Source

Requirements: Zig 0.13+

git clone https://github.com/copyleftdev/vibecheck.git
cd vibecheck
zig build -Doptimize=ReleaseSmall

The binary will be…

View on GitHub

Go give it a star, or better yet, run it on your focused project and see just how "unfinished" those vibes really are.

Happy coding. 🤙