No network is passed and staticNetwork is not set, so ethers 6.17 runs _detectNetwork on first use; on failure provider-jsonrpc.js:474 does console.log('JsonRpcProvider failed to detect network and cannot start up; retry in 1s ...') and repeats it every second for as long as the RPC is down. Over StdioServerTransport that line goes to the client as a non-JSON frame between protocol messages.

The SDK client survives it (processReadBuffer reports via onerror and continues) but it violates the explicit 'stdout carries only the protocol' requirement, and stricter clients drop the server.

Fix: construct the provider with a static network for chain 4663 (new JsonRpcProvider(url, Network.from(4663), { staticNetwork: true, cacheTimeout: -1 })), and/or redirect console.log to stderr in src/index.ts before anything else runs.

The exclusive queue only covers one process. FileLedger does read-modify-write with no lock (ledger.ts add(): read(), mutate, rename). Running the server from two MCP clients at once with the same DERBY_PRIVATE_KEY (e.g. Claude Desktop and Cursor both configured per the README) is an ordinary setup.

Each instance reads spent=0, each passes spent + cost > maxImdWei, each signs a buy, so the wallet spends 2 x cap before either records anything; with N instances, N x cap. The README's claim 'concurrent calls cannot both pass the cap check' is only true inside one process.

Fix: take an exclusive lock on the ledger (e.g. O_EXCL lock file with retry, or proper-lockfile) around check+buy+write, or reserve the cost in the file before broadcasting under that lock.

buyPacks(league, packs) has no max-price argument; the contract charges packs * packPrice at execution. The server computes cost from a read a moment earlier and records that number.

When the allowance is short the exact approve(cost) incidentally protects (transferFrom of a larger amount reverts), but when the allowance already covers the new price (allowance left from the website's arcade approve, or any larger approval) the wallet pays the new price and the ledger books the old one, so the cap is passed by the difference and derby_buy_pack reports a wrong costImd.

The contract emits TurnsBought(player, league, count, cost, burned) in the same receipt; recording cost from that event (or the IMD balance delta) keeps the ledger truthful regardless of price changes.

After the poll loop sees blockNumber > targetBlock the server calls reveal() once. If that single call fails for a recoverable reason (a lagging RPC node answering eth_blockNumber ahead of the node that runs estimateGas -> TooEarly; a NETWORK_ERROR on send; a nonce race), the tool returns isError and the PendingSwing closure holding the salt is dropped.

The swing can never be revealed again and becomes a FOUL after 255 blocks: the turn (0.1 IMD at current prices) is lost for a failure that a retry within revealTimeoutMs would have recovered. The spec allows 'a failed reveal is isError with the swingId', so this is low, but retrying reveal() on TooEarly/network errors until the deadline (and only then failing) is cheap and keeps the salt in memory.

ethers' wait() with no timeout polls indefinitely. If eth_sendRawTransaction returns a hash but the tx is never included (dropped by the sequencer, nonce gap after a replaced tx, RPC node that accepted but did not relay), derby_buy_pack / derby_swing / derby_settle never return, and because write tools run through exclusive, every subsequent derby_buy_pack, derby_swing and derby_settle call queues behind it until the server is restarted.

Nothing is spent beyond the stuck tx, so this is availability only.

Fix: tx.wait(1, timeoutMs) (ethers supports a timeout argument) and surface the hash in the isError text.

FakeChain.buyPacks always succeeds and always charges exactly PRICE*packs; nothing makes it throw after debiting, return a different charge, or run concurrently with another server. The ledger tests cover FileLedger in isolation but no test drives derby_buy_pack with a FileLedger, so the restart guarantee is asserted only indirectly.

There is also no test that stdout stays clean when the RPC is unreachable, and explainError is tested only via the revert.name shortcut, never via iface.parseError on raw revert data. Adding the three scratch cases (failed-confirmation buy, price change at mining, two servers on one ledger file) would have caught findings 1, 3 and 4.

The build-mcp-server skill prescribes ignoring node_modules/ and dist/, and the implementation followed it. The task's own rule says anything installed must be committed as ordinary files because verification runs with no network. On a clean checkout without network, npm test fails with ERR_MODULE_NOT_FOUND for tsx and npm run build for typescript, so 'tests pass through the SDK client with fakes' can only be confirmed with network access (it does: 28/28 after npm ci).

Not a code defect; a scope question for the requester about which rule wins.

Prior finding 15189983 is only partially fixed: the original two-pack success now records the correct amount and blocks a second confirmed buy. However, reconciling TurnsBought.cost after execution cannot enforce the hard cap on that execution. An existing allowance larger than the estimate still lets an ordinary owner price update charge more than the remaining budget.

A confirmation failure also leaves only the smaller estimate reserved. This requires no malicious owner or ledger tampering; the stated changed-packPrice invariant is still violated.

The reservation fix says a confirmed status-0 receipt releases the charge, but ethers v6 wait() throws CALL_EXCEPTION with err.receipt.status=0 instead of returning that receipt. This catch replaces that error without setting confirmedNoCharge, so the rc.status branch below is unreachable for an ordinary mined revert. The server permanently counts a purchase or approval that demonstrably spent no IMD, and can exhaust the entire cap after one failed transaction.

This is a reproduced regression in the new reservation/release path; the original unknown-confirmation overspending reproduction is fixed at a stable price.

Prior finding 965c427f remains reproducible. No installed dependencies or offline dependency artifacts are tracked. The assignment requires installed dependencies to be available as ordinary committed files for a verifier without network access; package-lock.json alone cannot supply them.

Prior finding 4f099c06 remains: the author says the committed tests were extended, but the suite still contains the same 28 cases. This fake always succeeds at the quoted price and returns a string, so it never exercises the new BuyReceipt.costWei adjustment. No SDK test supplies FileLedger or a spend-then-throw fake, and no test starts the stdio server against an unreachable RPC.

Existing calls through the new implementation do not test these failure behaviors.