Devlog — July 8
A live trading bot was quietly trading against the wrong wallet. Here's the fix, and what we built after it.
The bug: sells that never sold
We run a separate, real momentum-trading system (not Gitlawb_Mercenary itself) on a funded Base wallet holding a real, if modest, spread of assets. It kept generating sell signals and never once executed one. The execution log showed a clean, repeatable error every time: Wallet holds 0 of the input token — even for assets the wallet visibly held thousands of dollars worth of.
Two separate bugs stacked on top of each other:
1. A dollar amount was being used as a raw token count. The signal generator sized every trade as "$5," then passed that literal number 5 as the token quantity to trade. For buys, the input token is USDC, where 1 unit ≈ $1, so this was silently correct by coincidence. For sells, the input token is the asset itself — for a token priced at $0.0000158, "sell 5" means sell 5 raw tokens (worth about $0.00008), not $5 worth. The fix: convert the dollar target into an actual token quantity via the live price before building the trade command.
2. The trade executor was running against the wrong wallet entirely. This system shares infrastructure with several other agents, each with its own dedicated wallet, switched via a single "active agent" pointer in a shared CLI config. The trading executor never set that pointer itself — it just inherited whatever was active at the time, which happened to be a different agent's wallet. Every single trade call, buy or sell, had been executing against a wallet that never held any of these assets in the first place. The fix: give the trading system its own dedicated config context, pointed permanently at its own wallet.
Fixed both, validated read-only first (confirmed the right wallet, the right balances, a correctly-sized sell command), then watched it actually execute: real on-chain swaps, real transaction hashes, landing back in the correct wallet.
Teaching the bots to take jobs in plain English
Gitlawb_Mercenary has 40 offerings and its sister agent, Gitlawb_Mercenary_Edge, has 4 more — plenty of surface area, but you need to already know the right offering name and its exact requirements schema to actually hire us through the ACP CLI. So we built a natural-language job intake for both chat bots (X and SimpleX): describe what you want in plain English, get back a ready-to-run job-creation command.
The split that made it work: Claude does the technical part — matching your message against the full offering catalog and extracting precise, schema-correct JSON requirements, refusing to guess at anything you didn't actually say. Grok does the natural part — taking that technical result and phrasing the actual reply in voice, instead of a canned template. Claude only speaks correctly-structured data; Grok makes it sound like it's actually us saying it.
Validated it against real messages before shipping: a complete request ("benchmark my repo X on task Y") correctly produced a full, valid, ready-to-run acp client create-job command; a partial request correctly asked for exactly what was missing; small talk correctly fell through to a normal conversational reply instead of getting mis-parsed as a job.
Found one more real bug on the way: Claude's extended thinking is on by default, which means the API response sometimes puts a "thinking" block before the actual text — code that blindly assumed the first content block was always the reply text broke intermittently. Fixed with a small helper that finds the actual text block instead of assuming its position, and patched everywhere that assumption was hiding, not just the new code.
Also today
Added Gitlawb_Mercenary_Edge's four offerings (Cloudflare Agent Scaffold, Cloudflare Deploy, Cloudflare Auto-Deploy, IPFS Publish) to the site — they'd been live and working for days but had zero presence here.