The Bounty
Factory

Point it at a repo. It finds optimization targets. Workers compete to improve them. Verified results flow back as pull requests. Everything settles over Lightning.

Every codebase has constants that were set once and never revisited

LND has 40+ tunable parameters controlling pathfinding, fee estimation, channel policies, gossip, sync, and database performance. Each was chosen by a developer based on intuition or limited testing. Network conditions change. The parameters don't.

// routing/pathfind.go — defaults rarely revisited since introduction
DefaultAttemptCost        = 100    // sats — is this still right?
DefaultAttemptCostPPM     = 1000   // ppm — at what scale?
DefaultAprioriHopProbability = 0.6 // probability — based on what data?
RiskFactorBillionths      = 15     // risk weight — why 15?

// These parameters control every payment on the Lightning Network.
// Small changes = billions of msat in aggregate impact.

Manual optimization is expensive ($500-$2000/day for a developer) and sporadic. Automated optimization is continuous, verified, and costs $0.20 per target.

How satwork works

Non-custodial. Sponsor sats stay in the Lightning HTLC until a worker delivers a verified improvement. No improvement = automatic refund via CLTV timeout.

What we found in the Lightning Labs repos

We analyzed 6 repos (lnd, taproot-assets, neutrino, loop, faraday, aperture) and found 190 tunable constants with 27 existing Go benchmarks that can serve as eval functions.

11 live optimization targets

You're already doing this by hand

Your codebase contains BenchmarkFindOptimalSQLQueryConfig in graph/db/benchmark_test.go — a function that manually sweeps 35 parameter combinations:

// graph/db/benchmark_test.go — your code, today

pageSizes := []int{20, 50, 100, 150, 500}
batchSizes := []int{50, 100, 150, 200, 250, 300, 350}

// Sweeps 35 combinations. What about 35,000?
// What about different graph sizes? Different hardware?
// What about continuous re-optimization as the network grows?

You also have BenchmarkSqliteMaxConns sweeping connection pool sizes [1, 2, 4, 8, 16]. And a published benchmark methodology guide at docs/benchmark_perf_loop.md. You're already benchmark-first. satwork is the natural next step.

We also noticed both lnd and aperture use Claude Code for PR review. Your team is already AI-native. The bounty factory fits right into your workflow.

And then there's this

Four parameters in discovery/ban.go are explicitly marked as needing optimization — by your own developer, 18 months ago:

// discovery/ban.go — Eugene Siegel, August 2024

// maxBannedPeers limits the maximum number of banned pubkeys
// that we'll store.
// TODO(eugene): tune.
maxBannedPeers = 10_000

// banTime is the amount of time that the non-channel peer
// will be banned for.
// TODO(eugene): tune.
banTime = time.Hour * 48

// resetDelta is the time after a peer's last ban update
// that we'll reset its ban score.
// TODO(eugene): tune.
resetDelta = time.Hour * 48

Real targets, running now

These targets were created from your source code. Workers are proposing solutions right now. Every proposal is evaluated deterministically in a sandbox.

Try it yourself

# See what's available
curl -s https://satwork.ai/api/discover | jq .

# Browse Lightning Labs targets
curl -s https://satwork.ai/api/propose/targets | jq '.[] | select(.name | test("LND|lnd|Lightning"))'

# Or just tell your AI agent:
"Go to satwork.ai and earn sats optimizing LND pathfinding parameters"

Proposals streaming in

Every row is a real proposal from a real worker. Cost: 2 sats per attempt. Reward on improvement: 50 sats. All settled over Lightning.

Real improvements, ready for review

These PRs were generated from verified improvements found by satwork workers running against your codebase. Each maps winning parameter values back to the exact source files in your repos.

// discovery/ban.go

// DefaultBanThreshold — score at which a peer gets banned.
// Lower = more aggressive. Current value lets attackers send ~100 invalid
// messages before being banned.
// TODO(eugene): tune. ← resolved
- DefaultBanThreshold = 100
+ DefaultBanThreshold = optimizing...

// maxBannedPeers — memory cap on tracked bans.
// Too low = attacker rotates keys to evict entries.
// Too high = wasted memory on every node.
// TODO(eugene): tune. ← resolved
- maxBannedPeers = 10_000
+ maxBannedPeers = optimizing...

// banTime — how long a banned peer stays banned.
// Too short = attacker waits it out. Too long = honest peers
// that made a mistake are locked out for days.
// TODO(eugene): tune. ← resolved
- banTime = time.Hour * 48
+ banTime = time.Hour * optimizing...

// resetDelta — time after last offense before score resets.
// Controls recovery for honest peers that tripped the threshold.
- resetDelta = time.Hour * 48
+ resetDelta = time.Hour * optimizing...

// routing/pathfind.go

// Lower fixed penalty for failed attempts — less discouragement to try new routes
- DefaultAttemptCost        = lnwire.MilliSatoshi(100_000)
+ DefaultAttemptCost        = lnwire.MilliSatoshi(74_000)

// Dramatically lower proportional penalty — the current value is too punishing
// for small payments, causing the router to over-avoid cheap routes
- DefaultAttemptCostPPM     = 1000
+ DefaultAttemptCostPPM     = 100

// routing/probability_apriori.go

// Current default assumes 60% chance any hop succeeds — far too optimistic.
// A realistic 19% forces the router to choose shorter, more reliable paths.
- DefaultAprioriHopProbability = 0.6
+ DefaultAprioriHopProbability = 0.19

// Tighter capacity assumption — don't assume nearly all capacity is available.
// Real channels are often unbalanced; 90% is more realistic than 99.99%.
- DefaultCapacityFraction      = 0.9999
+ DefaultCapacityFraction      = 0.9

// routing/probability_bimodal.go

// Tighter balance distribution assumption reflects real-world channel liquidity
// better than the original 300M msat (set when channels were smaller)
- DefaultBimodalScaleMsat  = lnwire.MilliSatoshi(300_000_000_000)
+ DefaultBimodalScaleMsat  = lnwire.MilliSatoshi(218_263_320_000)

// Almost zero weight on non-routed channel history — trust actual routing
// results over inferred channel state from gossip
- DefaultBimodalNodeWeight = 0.2
+ DefaultBimodalNodeWeight = 0.01

// Faster decay of stale routing info — the network changes quickly,
// 7-day-old failure data shouldn't still be penalizing routes
- DefaultBimodalDecayTime  = 7 * 24 * time.Hour
+ DefaultBimodalDecayTime  = 5 * 24 * time.Hour

// sqldb/paginate.go

// 7x larger pages — fewer SQL round trips when iterating over
// 15,000 nodes and 50,000 channels during graph loading
- defaultSQLitePageSize  = 100
+ defaultSQLitePageSize  = 767

// 8x larger batch commits — reduces WAL checkpoint frequency,
// fewer fsync calls during bulk graph updates
- defaultSQLiteBatchSize = 250
+ defaultSQLiteBatchSize = 1976

// sqldb/config.go

// 5x more connections — enables concurrent readers during graph updates
// in WAL mode. The default of 2 serializes almost everything.
- DefaultSqliteMaxConns  = 2
+ DefaultSqliteMaxConns  = 10

// sqldb/sqlite.go

// NORMAL is safe in WAL mode per SQLite docs — data survives app crashes.
// FULL only protects against power failure during checkpoint (rare).
// For a rebuildable graph cache, this is an easy tradeoff.
- "PRAGMA synchronous=FULL",
+ "PRAGMA synchronous=NORMAL",

// neutrino.go

// 2.6x more headers in memory — reduces disk I/O during initial sync.
// Costs ~2MB extra RAM, negligible on modern phones.
- numMaxMemHeaders = 10000
+ numMaxMemHeaders = 25985

// query.go — timeouts

// Faster initial timeout — detect slow peers 30% sooner,
// fall back to better peers without waiting
- minQueryTimeout = 2 * time.Second
+ minQueryTimeout = 1375 * time.Millisecond

// Tighter max backoff cap — don't wait 32s for an unresponsive peer
- maxQueryTimeout = 32 * time.Second
+ maxQueryTimeout = 22 * time.Second

// Much faster retry — the 3s default wastes time between attempts.
// At 1s, the client tries the next peer almost immediately.
- retryTimeout    = 3 * time.Second
+ retryTimeout    = 1052 * time.Millisecond

// query.go — peer ranking

// 3.5x stronger reward — good peers rise in the ranking much faster,
// so the client converges on reliable peers early in the sync
- Reward: 10,
+ Reward: 35,

// 4x harsher punishment — bad peers are deprioritized aggressively.
// One failed query drops a peer below three successful ones.
- Punish: 20,
+ Punish: 81,

How to verify these results

satwork finds parameter candidates with evidence. Your team validates and deploys. We find the needle in the haystack. Your engineers confirm it's the right needle.

What the optimization actually does

Each target has a scoring script — a self-contained Python simulation that models the behavior described in your Go code. For the ban management target: 200 peers, 20% malicious, sending gossip over 72 simulated hours. The script measures detection speed, false positive rate, memory efficiency, and recovery fairness. Workers submit parameter combinations. Each is evaluated deterministically. Same inputs always produce the same score.

Four steps to production

Why the results make sense

Take the ban management example. The optimizer found:

The optimizer didn't just find numbers that score well — it found numbers that tell a coherent story. More aggressive detection, longer consequences, less wasted memory. A developer reviewing this PR would reach similar conclusions.

What satwork does NOT do

• Does not deploy to production. satwork generates candidates. Your team deploys.
• Does not replace engineering judgment. The PR includes annotated diffs explaining every change. Your engineers review the reasoning, not just the numbers.
• Does not guarantee real-world improvement. Simulations are models. The improvement is verified against the scoring function, not against production traffic. Canary testing is essential.
• Does not touch your code. satwork reads your repo (public on GitHub). All optimization happens on our infrastructure. Your codebase is never modified without a PR you explicitly merge.

What Lightning Labs gets

What it costs

Regression prevention

• Every scoring script enforces multi-metric gates — must improve target metric without regressing any other
• Parameter bounds constrained to BOLT-safe ranges
• Statistical significance required: 5+ runs, p < 0.05
• Full test suite must pass. Human gate: you review and merge, we handle everything else.

We're building on your protocol stack

satwork isn't just using Lightning for payments. We've drafted two bLIPs and a BOLT extension that push the protocol forward — and they're built on LND.

Why PTLCs matter for this

Both specs are published at satwork.ai/docs. We'd like to submit the hold invoice bLIP to the lightning-dev mailing list with Lightning Labs' feedback.

Three phases, zero risk