DEV Community: Space

The bounty trap: how open source reward systems exploit the people they claim to serve

Space — Tue, 07 Apr 2026 09:37:37 +0000

Open source bounty systems — from Web3 audit contests to traditional bug bounties — share a single structural flaw that corrupts nearly every platform in the ecosystem: the entity deciding whether to pay is the same entity that benefits from not paying. This conflict of interest, combined with AI-generated spam, platform collapses, and extreme earnings inequality, has created a system where skilled developers and security researchers routinely perform high-value work for free. The evidence spans every major platform and reveals not isolated bad actors but a systemic pattern of value extraction dressed up as opportunity.

The judge is the defendant: why every platform has the same problem

The core failure is architectural. In virtually every bounty system — HackerOne, Bugcrowd, Immunefi, Code4rena, Algora — the bounty poster unilaterally decides whether to pay. There is no binding contract, no neutral arbiter, and no meaningful legal recourse for the researcher. Bug bounty terms are written with phrases like "at the company's sole discretion," and platforms consistently side with their paying customers over their unpaid labor force.

Katie Moussouris, who helped create the Pentagon's bug bounty program and co-authored the ISO vulnerability disclosure standards, has publicly called this "an inherent conflict of interest." Andrew Crocker, Senior Staff Attorney at the EFF, noted that bounty program terms "give the company leeway to determine 'in its sole discretion' whether a researcher has met the criteria." Immunefi's own blog acknowledges: "We've seen some less-than-healthy behavior from projects, and whitehats end up feeling like they don't have any negotiating power and that they should be happy to just accept whatever payment they're offered."

The tactics for avoiding payment are remarkably consistent across platforms. Companies retroactively narrow scope to exclude reported vulnerabilities. They mark critical findings as "informational" to avoid payouts. They claim bugs were "already known" — without producing evidence or timestamps. They silently patch reported vulnerabilities and then deny the report was valid. When Immunefi removed a project for failing to pay a minimum of $500,000 in bounties, the whitehats still received nothing; Immunefi has no enforcement mechanism beyond removal.

The power asymmetry extends to silencing. Bugcrowd classifies all submissions as "Confidential Information of the Program Owner" by default. Researchers who go public risk suspension or permanent bans — as Trust Security discovered when Immunefi suspended them for 90 days after they criticized a bounty decision publicly. Jonathan Leitschuh, who discovered a critical Zoom vulnerability, declined the bounty because the NDA would have prevented him from ever discussing the flaw: "A lot of these programs are structured on this idea of non-disclosure. What I end up feeling like is that they are trying to buy researcher silence." Bruce Schneier shared academic research showing "legal agreements surrounding vulnerability disclosure muzzle researchers while allowing companies to not fix the vulnerabilities."

A wall of shame worth $2.5 million in unpaid Web3 bounties

The Web3 bounty ecosystem, anchored by Immunefi and Code4rena, demonstrates these failures at scale. The Bug Bounty Wall of Shame — a community-maintained ledger of projects that "rugged" security researchers — documents nearly $2.5 million in unpaid bounties across dozens of projects.

The cases follow a pattern. Arbitrum advertised a $2 million maximum bounty; when a whitehat found a vulnerability putting 352,000 ETH (~$680 million) at risk, they received only 25% of the maximum. Cronos had $2.5 million at risk; after the project silently fixed the bug before even responding to the report, the researcher received $1,600 as a "token of appreciation." dHEDGE, with $14.44 million at risk, paid $500 in "goodwill." Magic Link ignored a vulnerability affecting $10 million in user funds through eight reminders over a month, paid nothing, then publicly announced the patch as a "new security feature." GhostMarket ignored Immunefi's mediation order entirely and went silent.

Immunefi's explicit "No Fix, No Pay" policy creates a perverse incentive: projects can acknowledge a critical vulnerability and still avoid payment by choosing not to fix it. The platform admits this is "an eternally frustrating experience for whitehats."

One anonymous researcher documented "14 weeks in Immunefi limbo" on Medium after discovering a critical vulnerability in a project advertising seven-figure payouts. The project closed the report within two days citing an irrelevant technical reason. After Immunefi mediation confirmed the report was valid, the project changed its rejection reason to "duplicate" — two months after submission. The researcher observed: "Beyond pausing a BBP, Immunefi actually has no enforcement mechanisms in place for most projects, and bad-faith actors clearly don't care about being booted from the platform."

Code4rena's competitive audit model compounds the problem with extreme earnings inequality. In 2023, the platform processed 31,512 bug submissions across 114 audits and paid out $4,823,059 total. Of more than 10,000 registered wardens, only 1,323 earned anything — meaning roughly 87% earned zero. The average earning warden took home $3,646 for the year. cmichel, the first person to earn $1 million on Code4rena, watched his hourly rate drop from $2,000 to $500 as competition increased from ~10 to ~59 wardens per contest. "This is great for the sponsors who receive an insane amount of value," he wrote, "but bad for the auditors as they all compete for the same pot." Zellic, which acquired Code4rena in 2024, eventually admitted the economics "make more sense as a public good rather than a rent-seeking business."

AI slop made the economics completely untenable

On January 31, 2026, Daniel Stenberg shut down curl's bug bounty program after 6.5 years, 87 confirmed vulnerabilities, and over $100,000 paid to researchers. The reason: AI-generated submissions had overwhelmed the program's volunteer security team. The confirmed vulnerability rate plummeted from above 15% to below 5% — "not even one in twenty was real." By July 2025, submission volume had spiked to eight times the normal rate. In the first 21 days of January 2026 alone, 20 submissions arrived with zero valid vulnerabilities.

The reports weren't obviously bad. They featured walls of perfectly formatted text, plausible-sounding technical language, and references to functions that simply don't exist. Stenberg wrote: "We are effectively being DDoSed," and later: "The never-ending slop submissions take a serious mental toll to manage and sometimes also a long time to debunk. Time and energy that is completely wasted while also hampering our will to live."

The economic mechanism is simple. Previously, generating a credible security report required time, skill, and deep codebase knowledge — a natural quality filter. AI reduced the submission cost to near zero while leaving the triage cost unchanged or higher, since AI-generated reports look more plausible and take longer to debunk. This is a classic market failure: when the cost of filing claims drops to zero but the cost of evaluating claims stays constant, the system collapses.

Curl was not alone. Django's Security Team documented receiving AI-fabricated reports "on a nearly daily basis." Node.js dealt with a 19,000-line AI-generated pull request and imposed minimum reputation scores. libxml2's sole maintainer ended support for embargoed vulnerability reports entirely, citing the "unsustainable burden of handling security triage as an unpaid volunteer." CycloneDX pulled its bounty program after receiving "almost entirely AI slop reports." Apache Log4j's maintainer reported reviewing 67 submissions since July 2024, half arriving in the final two months. tldraw began auto-closing all external pull requests in January 2026.

Mitchell Hashimoto's Ghostty terminal emulator moved to invitation-only contributions, requiring all contributors be vouched for by existing trusted members. His assessment: "It's a fucking war zone out here man. Maintainer morale at an all time low." RedMonk analyst Kate Holterhoff coined the term "AI Slopageddon" to describe the phenomenon. An Oxford Academic paper studying COVID-19's supply shock on Bugcrowd — when submissions increased 151% — showed that AI represents a far larger version of the same dynamic.

HackerOne and Bugcrowd: the traditional platforms are failing too

Traditional security bounty platforms exhibit the same structural failures with additional layers of institutional dysfunction. Tommy DeVoss, one of HackerOne's highest-earning researchers with over $2 million earned, stated flatly: "Historically, mediation with HackerOne has been worthless." John Jackson of Sakura Samurai described submitting a vulnerability to Ford, watching it get fixed, being ignored for months on disclosure requests, and then getting banned from Ford's program when he pushed back. Patrick Martin had a plaintext credential disclosure go 10 months without response or payment despite being silently fixed.

In February 2022, HackerOne froze $50,000 in already-earned bounties from Russian researcher Anton Subbotin after the Ukraine invasion — for work already completed, discussed, and patched. CEO Mårten Mickos initially tweeted the funds would be donated to UNICEF without the researcher's consent. In January 2026, researcher Jakub Ciolek reported that HackerOne completely ghosted him on an $8,500 payout from the Internet Bug Bounty program for months; the company responded only after The Register published the story. HackerOne's IBB program has since paused submissions entirely.

The earnings data reveals stark inequality behind the platform's marketing. HackerOne touts $81 million in annual payouts and "hacker millionaires," but only about 1.6% of registered accounts produce valid work. Only 12% of researchers earn $20,000 or more annually. The median per-bounty payment is approximately $800. One researcher tracked 782 hours over 150 days and earned $5,650 — an hourly rate of $9.80, below minimum wage in most Western countries. A critical RCE vulnerability that pays $500–$5,000 on bounty platforms could fetch $50,000–$500,000 on the gray market — a gap of 100x to 500x. Lviv Van Houtven of Latacora put it bluntly: "HackerOne has weaponized triage... Their business model is misery."

Apple's program drew particular criticism. Researcher RenwaX23 discovered a Universal Cross-Site Scripting vulnerability in Safari rated Critical at 9.8/10, capable of impersonating users and accessing iCloud. Apple paid $1,000 — from a program advertising payouts up to $2 million. The Washington Post interviewed more than two dozen researchers who complained about Apple's pattern of slow fixes, limited feedback, and non-payment.

Bountysource proved platforms can simply steal the money

The Bountysource collapse is the clearest illustration of how bounty systems can fail catastrophically. The platform, which facilitated bounties across 55,000 GitHub issues for projects including BorgBackup, elementary OS, Nextcloud, and Nim, was acquired by cryptocurrency company CanYa in 2017 and then sold to The Blockchain Group in 2020.

On June 16, 2020, Bountysource emailed users announcing a new Terms of Service with a critical clause: any bounty unclaimed for two years would be "retained by Bountysource." The change was retroactive, with only two weeks' notice. After backlash forced a reversal, trust was destroyed — elementary OS published "Goodbye, Bountysource" and withdrew entirely.

The final collapse was quieter. By mid-2023, payouts stopped entirely. Bountysource went silent on all communication. The Blockchain Group filed for bankruptcy in November 2023. Investigative reporting by Evan Boehs documented at least $21,000 in stolen developer earnings — money for work already completed. The NewPipe project lost approximately €6,400 in accumulated bounties. Users on GitHub issue #1586 — titled "CRITICAL: Bountysource is Insolvent, do not use!" — called the behavior "abuse of the escrow, essentially an embezzlement" and discussed filing with French financial authorities.

Boehs observed: "There has been shockingly little discussion of this event. The community quietly accepted their loss, and the voices of developers who lost thousands of dollars were never amplified."

The maintainer-as-judge problem enables quiet self-dealing

Beyond platform-level failures, bounty systems create perverse dynamics at the project level. In September 2023, Wasmer's CEO used Algora to post a $5,000 bounty on the Zig project's repository without consulting maintainers, triggering multiple developers to start duplicate work simultaneously. Zig's community manager responded: "We're not going to let startups burn our contributor community so that they can squeeze one extra tweet out of their moat-building efforts." The Zig team later published a landmark critique arguing that development bounties "foster competition at expense of cooperation," transfer all risk to workers, and "penalize any form of thoughtfulness in favor of reckless action."

Developer Valentin Chmara documented a pattern on the Orama project: "The maintainer eventually closed every related PR, including mine, and shipped the fix internally." A review of 23 crypto bounty programs found systemic use of Contributor License Agreements as gates — developers sign away code rights, their PR gets closed without merge, and their code may appear in the product anyway. Academic research on Bountysource confirms the pattern: bounty issues actually have lower closing rates than non-bounty issues, and it takes longer for bounty issues to get closed.

What a fair bounty system would actually require

A handful of models point toward solutions. The FreeBSD Foundation acts as an intermediary, taking money from companies wanting a feature, finding a qualified contractor, and ensuring quality review — exclusive assignment rather than competition. Opire charges zero fees to developers, placing all platform costs on bounty creators. Immunefi enforces "The Bug Bounty Program Is Law" — projects cannot retroactively change terms, and minimum payouts for critical bugs are binding. Zellic now runs Code4rena contests at zero platform fee, acknowledging the old model was extractive.

The structural reforms needed are clear from the evidence. Escrow would prevent companies from receiving vulnerability information before committing funds. Independent arbitration by named third parties would eliminate the judge-is-the-defendant problem. Binding scope would prevent retroactive exclusions. Duplicate splitting — dividing bounties among researchers who independently find the same bug within a reasonable window — would compensate parallel work. Mandatory disclosure rights after 90 days would prevent indefinite NDAs from buying silence. Exclusive assignment for development bounties would eliminate the wasteful battle-royale dynamic and allow collaboration.

The quiet extraction engine behind the opportunity narrative

The bounty ecosystem functions as a remarkably efficient mechanism for extracting high-value labor at below-market rates. A program paying $100,000 per year in bounties replaces $500,000+ of professional penetration testing. The platform takes a 20% cut. Researchers split the remainder for work that, if sold on the gray market, would be worth orders of magnitude more. HackerOne's own data shows top earners in India earn 16x the median local software engineer salary — revealing that developing-world researchers accept far lower absolute amounts, creating a global race to the bottom.

63% of ethical hackers have withheld security flaws they discovered, with the top reason being threatening legal language. Parsia Hakimian, a senior offensive security engineer, compared the economics to "multilayer marketing operations, where very few people make most of the money while the rest don't make much at all." Legal experts told CSO Online that bounty platforms likely violate California AB 5 and the Federal Labor Standards Act by treating researchers as independent contractors when they meet employee criteria.

The system persists because the marketing works. Headlines about hacker millionaires and $81 million annual payouts obscure the reality that the median researcher earns poverty-level wages for highly skilled work, has no legal protection, cannot build a public portfolio due to NDAs, and can have completed work rejected without explanation or recourse. As one Hacker News commenter who spent seven years in the bug bounty community summarized: "The problem is that the majority of companies don't act in good faith. Even when you have something fully exploitable and valid, they will many times find some way to not pay you or lower the severity to pay you very little."

Conclusion

The evidence across every major bounty platform — Immunefi, Code4rena, HackerOne, Bugcrowd, Bountysource, Algora — reveals not a collection of individual failures but a single structural defect replicated across the entire ecosystem. When the party deciding payment is the party that benefits from non-payment, exploitation is not a bug but the equilibrium state. AI slop has accelerated the collapse by making it economically impossible for volunteer-maintained programs to process submissions, but the underlying power asymmetry existed long before large language models. The bounty economy's fundamental promise — that talented individuals can earn fair compensation for valuable security and development work — requires structural reforms that no major platform has yet been willing to implement fully: escrow, binding contracts, independent arbitration, and the elimination of the judge-as-defendant model. Until those changes arrive, bounty systems will continue to function as what they demonstrably are: mechanisms for transferring risk and extracting labor from the people who can least afford to absorb it.

Built a Tool That Deep-Links to Exact Answers, Not Question Pages

Space — Tue, 31 Mar 2026 11:57:16 +0000

The Problem That Wouldn't Stop Bugging Me

Last year I spent 6+ years building HashiCorp Vault infrastructure at Expedia. Every week, the same pattern:

Junior dev hits a Vault 403 error
They search Stack Overflow
They find a question page with 23 answers
They scroll past 8 wrong answers to find the right one
Next week, different dev, same error, same scroll

The answer existed. The address was permanent — stackoverflow.com/a/38716397. But nobody could get to it directly. They always landed on the question page and had to dig.

One day I was looking at how Slack threads work internally. Every message has a coordinate: channel/p{unix_microseconds}?thread_ts={parent_ts}. The timestamp IS the ID. If you know the coordinate, you go straight to the message — no scrolling, no searching.

I realized: this isn't just Slack. Every platform has permanent answer addresses.

Stack Overflow: /a/{answer_id} — the accepted answer, not the question
Reddit: /comments/{post}/{slug}/{comment_id} — the top comment, not the post
Hacker News: /item?id={objectID} — if Algolia says it's a comment, the objectID IS the deep-link
GitHub: /{org}/{repo}/issues/{n} — direct to the issue
Twitter/X: /{user}/status/{snowflake} — snowflake IDs embed the timestamp: ts = (id >> 22) + 1288834974657

Every answer on every platform has a deterministic address in (platform, thread_id, timestamp) space. I started calling this "thread coordinates."

What I Built

phi-thread is a Chrome extension (also a Python CLI on PyPI) that searches across 5 platforms simultaneously and returns deep-links to the exact answer — not the question page, not the post, the answer itself.

Here's what happens when you search "docker container keeps restarting":

Stack Overflow: The API returns questions. But phi-thread doesn't stop there — it fetches the accepted_answer_id, calls the answers endpoint, pulls the answer body, and gives you stackoverflow.com/a/38716397. You click, you're at the fix. No scrolling past 22 other answers.

Reddit: For each matching post, phi-thread fetches {permalink}.json?limit=1&sort=top to extract the top comment. You get a link to the actual comment, not the post.

Hacker News: Algolia's API returns both stories AND comments. If the result is a comment (has story_id and comment tag), the objectID is already the deep-link: news.ycombinator.com/item?id={objectID}.

Then it ranks them. Platform score × title relevance. A perfectly matching SO answer with 5 upvotes beats a Reddit post with 500 upvotes but irrelevant title.

The Three-Layer Architecture

The interesting part (to me) is how the knowledge base builds itself.

Layer 1 — Exact cache. SHA-256 hash of the normalized query → JSON in chrome.storage.local. 24-hour TTL. Same exact question = instant results, < 1ms.

Layer 2 — Keyword index. This is the one I'm most proud of. Every answer that comes back from a search gets its keywords extracted. Each keyword maps to the answer's coordinate and score in a persistent index.

Why this matters: you search "docker container restarting" today. Tomorrow you search "docker restart loop" — different query, but the keyword index finds yesterday's answers because they share the keywords "docker" and "restart." The KB builds itself from your search history.

The index grows forever. After a few hundred searches, it knows your stack. Searches for things you've queried before resolve from the index in ~5ms instead of 12 seconds of live API calls.

Layer 3 — Live search. Parallel fetch() calls to SO, Reddit, HN, GitHub, and DuckDuckGo (catches Medium, Dev.to, blogs, Twitter). All in the service worker, all client-side.

The "CONNECT" Feature

This is the one I'm most excited about. When you're on a Stack Overflow question page, phi-thread automatically extracts the question title, searches OTHER platforms (Reddit, HN, GitHub), and shows you a small floating panel: "φ 3 answers found on other platforms."

The question you're reading on SO might already be answered in an HN comment or a Reddit thread. phi-thread bridges that gap. No one platform has all the answers, but collectively they do.

Zero Dependencies, Zero Server

The entire extension is vanilla JS — no React, no build step, no bundler. The search engine is ~550 lines of code. It uses fetch() for API calls and chrome.storage.local for persistence. Installs in 1 second.

No API keys. All platforms are queried through their public free-tier APIs. Rate limits are generous enough for individual use.

No server. Everything runs in your browser. Your search history, your keyword index, your cache — all local. Nothing leaves your machine.

The Spacetime Analogy (for the Curious)

I found a fascinating paper while building this: Krioukov et al. (2012) proved that complex networks and de Sitter spacetime share identical large-scale causal structure. Past light cones in spacetime map to hyperbolic discs in networks, both producing the same power-law degree distributions.

This isn't a coincidence I'm forcing. The math is genuinely there. Lamport's happened-before relation in distributed systems (1978) was explicitly inspired by special relativity. Partially ordered sets — where "A happened before B" is defined but "A and B are concurrent" is also possible — describe both spacetime events and thread replies.

An answer on Stack Overflow and an event in spacetime are both points in a partially ordered set with a permanent coordinate. I wrote a literature review on this if anyone's interested (links in the repo).

I'm not claiming threads ARE spacetime. But they share mathematical structure, and that structure is what makes permanent answer coordinates possible.

What's Next

The self-building KB has an interesting property: if thousands of users each build their own index, and we aggregate them (anonymously — just keyword → URL → count), we get community-validated answers. When 50 developers independently find the same SO answer for "postgres connection pooling," that answer is probably excellent — without anyone voting or curating.

I'm working on cloud sync as a Pro feature, which would enable this aggregated intelligence layer. But the free version is fully functional right now.

Try It

Chrome Web Store: phi-thread (search for "phi-thread")
PyPI: pip install phi-thread (CLI version)
GitHub: github.com/0x-auth/phi-thread
How it works: phi-thread.netlify.app

Zero dependencies. Zero tracking. Zero server. Just a router to the answer that already exists.

Connect, don't create.
🌌

Built a K8s Scheduler That Beats the Default in Every Benchmark.

Space — Sun, 29 Mar 2026 08:58:44 +0000

Your Kubernetes cluster is wasting 10-20% of its compute budget right now. Here's proof, and a fix.

The Problem Nobody Talks About

Kubernetes default scheduler uses "Least Allocated" scoring. It picks the node with the most free resources. Sounds fair, right?

Wrong. Here's what actually happens:

Node A: 90% CPU used, 10% RAM used  → score: ~50
Node B: 50% CPU used, 50% RAM used  → score: ~50

They score the same. But Node A is practically dead — 90% of its RAM is stranded because no pod can use it (CPU is full). You're paying for that RAM every month.

At 50 nodes, this adds up to thousands of dollars per month in wasted resources.

The Fix: Vector Alignment Scheduling

I built Lambda-G — a drop-in K8s scheduler plugin that replaces the default Score phase with vector-alignment scoring.

Instead of treating CPU and RAM as independent numbers, Lambda-G treats each node as a vector:

Node vector:  [cpu_free, ram_free, iops_free, network_free]
Pod vector:   [cpu_req, ram_req, iops_req, network_req]

The score is the directional alignment between these vectors. A CPU-heavy pod gets steered toward a RAM-heavy node. Result: symmetric exhaustion — all resources drain evenly.

The Math (30 seconds)

Score = φ × alignment + exhaustion_bonus - entropy_penalty

Where:

alignment = cosine similarity between pod request and node capacity vectors
exhaustion_bonus = how much more balanced the node becomes after placement
entropy_penalty = punishment for creating stranded resources
φ = 1.618 (golden ratio — the optimal self-reference weight)

Why golden ratio? It's the fixed point of self-reference: φ - 1 = 1/φ. Each scoring layer decays by exactly 1/φ from the previous, creating a mathematically optimal relevance function.

Benchmark Results

I tested Lambda-G against the default scheduler across 5 scenarios:

Scenario	Default	Lambda-G	Winner
Mixed Workload (20 nodes, 200 pods)	87.2	97.0	Lambda-G
Scale Test (50 nodes, 500 pods)	85.9	96.7	Lambda-G
CPU-Heavy Skew (10 nodes)	98.2	99.1	Lambda-G
RAM-Heavy Skew (10 nodes)	96.2	98.2	Lambda-G
Dense Packing (10 nodes, 150 pods)	88.0	96.0	Lambda-G

Lambda-G wins all 5 scenarios. Zero stranded nodes in 4/5 scenarios (vs 1-10 with default).

Architecture

┌─────────────────┐     ┌──────────────┐     ┌─────────────┐
│  K8s API Server  │────▶│  Lambda-G    │────▶│  Rust Brain  │
│  (watches pods)  │     │  Controller   │     │  (scoring)   │
└─────────────────┘     │  (Python/kopf)│     │  379ns/score │
                        └──────────────┘     └─────────────┘

Rust scoring engine: Sub-microsecond per-node scoring
Python controller: kopf-based K8s operator, watches for annotated pods
Helm chart: One-command install
Safety valve: FailurePolicy: Ignore — if Lambda-G crashes, K8s falls back to default. Zero risk.

Try It

# Docker
docker pull bitsabhi/lambda-g-controller:latest

# Helm
helm install lambda-g ./charts/lambda-g

# Or just run the benchmark yourself
git clone https://github.com/0x-auth/lambda-g-scheduler
cd lambda-g-scheduler
python3 benchmark_simulation.py

The Auditor (Free)

Before installing the scheduler, run the auditor to see how much you're wasting:

python3 coherence_engine/auditor/auditor.py

It scans your cluster and shows stranded resources + estimated monthly cost.

How It Works Under the Hood

Pod arrives with schedulerName: lambda-g annotation
Controller fetches all nodes' capacity vectors
Rust brain scores each node in <1μs using cosine alignment + entropy metrics
Pod gets bound to the highest-scoring node
If controller is down, K8s default scheduler takes over (safety valve)

The scoring function in Rust:

fn calculate_score(cpu_free: f64, ram_free: f64, cpu_req: f64, ram_req: f64) -> f64 {
    let phi = 1.618033988749895;
    let initial_entropy = (cpu_free - ram_free).abs();
    let final_entropy = ((cpu_free - cpu_req) - (ram_free - ram_req)).abs();
    let recovery = initial_entropy - final_entropy;
    let exhaustion = 1.0 - ((cpu_free - cpu_req) + (ram_free - ram_req));
    (recovery * phi * 100.0) + (exhaustion * 10.0)
}

17 lines. That's the entire brain.

What's Next

Benchmarking on real EKS/GKE clusters (simulation results above, live results coming)
4-dimensional scoring (CPU + RAM + IOPS + Network)
AWS/GCP Marketplace listing
PDF audit reports for enterprise

How I Built a Route Optimizer Within 0.13% of LKH-3 (Rust + API)

Space — Tue, 10 Mar 2026 16:08:25 +0000

How I Built a Route Optimizer Within 0.13% of LKH-3 (Rust + API)

I spent months trying to match the best TSP solver in the world. Here's the story of how I got within 0.13%.

The Challenge

LKH-3, written by Keld Helsgaun, is the solver everyone measures against. It's been the gold standard for the Travelling Salesman Problem for over two decades. Researchers have spent entire careers trying to beat it.

I didn't set out to beat it. I wanted to see how close a clean, modern Rust implementation could get — and then make it accessible as a simple API call.

Where I Ended Up

Instance	Cities	LKH-3	Lambda-G	Gap
kroA100	100	21,907	21,908	0.005%
pr1002	1,002	259,045	261,921	1.11%
shared_benchmark	1,000	23,342	23,373	0.13%

On kroA100, Lambda-G finds essentially the exact same tour as LKH-3. On 1,000 cities, we're within 0.13%. And it beats Google OR-Tools on the same benchmark.

All tests: 60 second time limit, same hardware.

Try it live — click to place cities and watch the optimization happen →

The Wall I Hit

My first 8 versions were mediocre. I was getting 3-5% gaps on 1,000-city problems — respectable, but nowhere near LKH-3. The algorithm was correct. The code was clean. But something was off.

I profiled the code. The bottleneck wasn't the search strategy — it was the inner loop overhead. The solver was spending too much time on bookkeeping and not enough on actual search.

I was running out of iterations long before I was running out of good moves to find.

The Breakthrough

The fix came from careful profiling and micro-optimizations. No single silver bullet — just relentless attention to what the CPU was actually doing.

Same time budget, but significantly more iterations. And more iterations means finding better solutions.

This dropped my gap from 3-5% to under 1%. The rest of the improvement came from tuning the perturbation strategy.

The Algorithm

Lambda-G uses Iterated Local Search — conceptually simple, but the details matter:

1. Build initial tour (nearest-neighbour + greedy patching)
2. Local search: 2-opt + Or-opt until no improvement
3. Perturb: double-bridge (4-opt, non-sequential reconnection)
4. Accept or reject perturbation
5. Repeat until time limit

Why Double-Bridge Matters

2-opt and Or-opt are greedy — they always improve the tour. But they get stuck in local minima. You need a way to escape.

Double-bridge cuts the tour in 4 places and reconnects the segments in a way that no sequence of 2-opt moves can reach. It's like teleporting to a different region of the solution space.

After each perturbation, the local search kicks in again and optimizes from the new starting point. Sometimes it finds something better. Sometimes it doesn't. But over thousands of iterations, it converges toward the global optimum.

Candidate Lists

Checking every possible 2-opt swap is O(n²). For 10,000 cities, that's 100 million comparisons per iteration — way too slow.

The trick: precompute a set of nearest neighbours for each city. Only consider swaps involving these neighbours. This prunes the search space dramatically with almost no loss in solution quality, because good moves almost always involve nearby cities.

Parallelism

Multiple independent workers run with different random seeds. Best tour wins. Simple, embarrassingly parallel, and scales linearly with cores.

Beyond Delivery Trucks

Here's the thing most people don't realize: TSP isn't just about delivery routes. It's about optimal ordering of anything.

The algorithm doesn't care what your "cities" are:

Logistics & Delivery → minimize fuel and driver hours
Chip Design / VLSI → minimize total wire length between components
DNA Sequencing → order fragments for genome assembly
Warehouse Picking → minimize picker travel time
CNC / Laser Cutting → minimize toolhead movement
Telescope Scheduling → minimize slew time between targets

Send coordinates for Euclidean problems. Send a distance matrix for everything else — road networks, genomic distances, whatever.

Making It an API

I wanted this to be useful, not just a benchmark trophy. So I wrapped it in a REST API:

import httpx

result = httpx.post("https://api.bitsabhi.com/optimize",
    headers={"Authorization": "Bearer YOUR_KEY"},
    json={
        "points": [[0,0], [100,0], [100,100], [0,100]],
        "time_limit": 25.0
    }
).json()

print(result["tour"])        # [0, 3, 1, 2]
print(result["length"])      # 341.42
print(result["improvement"]) # 17.6% vs nearest-neighbour

Response times:

100 cities → ~0.5 seconds
1,000 cities → ~3 seconds
10,000 cities → ~25 seconds

It also accepts CSV uploads and distance matrices. One endpoint, any format.

Distance Matrix (for non-Euclidean problems):

result = httpx.post("https://api.bitsabhi.com/optimize",
    headers={"Authorization": "Bearer YOUR_KEY"},
    json={
        "matrix": [
            [0, 29, 82, 46],
            [29, 0, 55, 46],
            [82, 55, 0, 68],
            [46, 46, 68, 0]
        ],
        "time_limit": 25.0
    }
).json()

What I Learned

1. Profiling beats intuition. The bottleneck was never where I thought it was. The profiler doesn't lie.

2. Candidate lists are essential. Pruning the search space is what separates toy solvers from production solvers.

3. Distance matrices unlock everything. The moment you accept an arbitrary matrix instead of just coordinates, you go from "route optimizer" to "universal ordering optimizer." DNA sequencing, road networks, financial portfolio rebalancing — same API call.

4. Rust is worth the rewrite. Porting from Python to Rust took about a week. The speedup is permanent and compounds with every iteration of the solver. For compute-bound problems, the language matters.

5. Perturbation is everything. A perfect local search that gets stuck in local minima will lose to a mediocre local search with good perturbation. Double-bridge was the key to escaping local optima.

Pricing

No subscriptions. Pay once, use forever.

Free: 100 cities, $0 forever
Research: 500 cities, $0 (.edu email required)
Builder: 1,000 cities, $49 lifetime
Pro: 10,000 cities, $149 lifetime

Try it free → lambda-g-optimizer.netlify.app

What's Next

I'm exploring vehicle routing (multiple trucks with capacity constraints), time windows, and asymmetric TSP. If you have a real-world problem that needs optimal ordering, I'd love to hear about it — especially edge cases and weird domains I haven't thought of.

What are you solving that needs optimal ordering?

Abhishek Srivastava — ORCID — bitsabhi@gmail.com