@dvmkit/sdk 0.2.0-rc.9 → 0.3.0-rc.9

package/dist/{chunk-V7EVFLAK.js → chunk-2D75MNNG.js}

@@ -1,6 +1,6 @@
 import {
   withSdkInitLock
-} from "./chunk-S3XAHZQY.js";
+} from "./chunk-COYKJRMM.js";
 import {
   applyRetryToPool
 } from "./chunk-C3MTFLC6.js";
@@ -108,7 +108,6 @@ var PostgresX402ChannelStorage = class {
   fleetLockQueueDepth = 0;
   relayLockTimeoutMs;
   terminalizeUnbackedCredit;
-  /** Create the durable channel table under the SDK-wide DDL lock. */
   async init() {
     this.settlementPool ??= createSettlementPool(this.pool);
     await withSdkInitLock(this.pool, async () => {
@@ -541,7 +540,6 @@ var PostgresX402ChannelStorage = class {
       );
     }
   }
-  /** Load one channel snapshot. */
   async get(channelId) {
     const q = this.transaction.getStore() ?? this.pool;
     const { rows } = await q.query(
@@ -1003,39 +1001,23 @@ var CreditLedger = class {
   x402Settlements;
   expiryReleaseOutbox;
   /**
-   * Bind the durable x402 settlement state this ledger gates spending on
-   *
-   * Late, because the settlement store is built with the batch-settlement
-   * server, which is built *after* the ledger it reads earned draws from. An
-   * unbound ledger simply does not gate — correct for a DVM with no x402
-   * channel storage, where no settlement row can exist to wedge.
+   * Bound after construction because the settlement store shares this ledger and is
+   * initialized separately. Ledger effects and route preflights use the same refund gate.
    */
   useX402SettlementGate(gate) {
     this.x402Settlements = gate;
   }
   /**
-   * Bind the durable outbox that reports credit-expiry releases and their
-   * revivals to the platform.
-   *
-   * Held on the ledger rather than threaded through {@link fund} for the same
-   * reason as the gate above: the revival half fires from *every* funding path
-   * Cashu commit, x402 exact and channel, Tempo, the Lightning invoice
-   * settle, the implicit N=1 per-call payment — and a seam each of those has to
-   * remember to pass is a seam one of them will eventually forget.
-   *
-   * Unbound (a `dvmctl dev` server, a self-hosted builder, a test host) the
-   * sweep and the reversal still run and still write the ledger's own rows;
-   * only the platform report is skipped. Reporting is bookkeeping and must
-   * never gate the ledger.
+   * Expiry release and revival reports join the ledger transaction. A caller-owned funding
+   * transaction must not commit a reversal independently of its outbox row. Without this
+   * wiring, ledger transitions still run.
    */
   useCreditExpiryReleaseOutbox(outbox) {
     this.expiryReleaseOutbox = outbox;
   }
-  /** Create the `credits` / `credit_draws` tables if absent. Call once at SDK boot. */
   async init() {
     await withSdkInitLock(this.pool, () => this.createTables());
   }
-  /** The boot DDL itself — always runs under {@link withSdkInitLock}. */
   async createTables() {
     await this.pool.query(`
       CREATE TABLE IF NOT EXISTS credits (
@@ -1313,25 +1295,11 @@ var CreditLedger = class {
     );
   }
   /**
-   * Give every open non-channel Bitcoin credit a funding lot.
-   *
-   * Runs inside the boot DDL, is guarded per credit by `NOT EXISTS`, and is
-   * therefore both the one-time migration and a standing self-heal for a
-   * credit that somehow reaches a positive balance with no lot behind it.
-   *
-   * The lot is derived from `credits.msats_remaining`, not replayed out of
-   * `credit_fundings`. That is not a shortcut: `credit_fundings` records only
-   * `{amount_micro, rail}` — no instrument amount at all — and is not written
-   * on every funding path, whereas `msats_remaining` **is** the credit's
-   * current unspent rail value, maintained pro rata on every draw since
-   * One synthetic lot pairing it with `balance_micro` therefore
-   * reproduces today's in-kind position exactly, and FIFO over a single lot is
-   * trivially correct. Historic per-funding rates are unrecoverable and would
-   * change nothing: only the remaining position is owed.
-   *
-   * The semantics change is deliberately retroactive — every
-   * current holder is first-party, so there is one regime and no legacy
-   * branch.
+   * Backfill an open non-channel Bitcoin credit only when it has no funding lot. Pair
+   * balance_micro with current msats_remaining; credit_fundings lacks historical instrument
+   * amounts and does not cover every funding path. Historical per-funding rates cannot be
+   * recovered. Existing lots are left untouched, so this does not repair partial coverage
+   * gaps.
    */
   async backfillFundingLots() {
     const { rowCount } = await this.pool.query(
@@ -1367,60 +1335,19 @@ var CreditLedger = class {
     );
   }
   /**
-   * Create a credit, or top up an existing one (same `creditId`). Top-ups add
-   * to the balance and overwrite `expiry_ms` with the provided value — funding
-   * an expired credit revives it (the caller-ownership contract carry-forward: the credit is a
-   * rolling buffer, not per-job escrow). The existing row's `caller_pubkey`
-   * and `currency` must match or the fund is refused with a typed error —
-   * without that check a top-up against someone else's `credit_id` would
-   * silently merge two callers' money.
-   *
-   * Pass `tx` (a client inside a caller-owned `BEGIN`) to commit the rail
-   * receive and the ledger credit atomically (spec condition 3 — the
-   * verifier does this). The ledger issues **no** transaction control on `tx`.
-   *
-   * Without `tx` it opens one of its own, because a funding is no longer a
-   * single statement: it upserts the credit, records its funding lot
-   * and reverses any standing expiry release — and that
-   * last leg restores balance and queues a report. A crash between the upsert
-   * and the reversal would leave a revived credit whose release still stands,
-   * which the sweep's own exclusion then makes permanent: `balance_micro > 0`
-   * but a standing release means it is neither drainable nor re-releasable.
-   *
-   * `basis` records the rail value behind the fiat so each draw can
-   * be allocated its share of the rail-native amount actually received. A
-   * top-up on a different rail than the credit's is refused with
-   * `rail_mismatch`: sats and USDC microunits aren't summable, so a blended
-   * credit would have no coherent native basis to allocate from.
-   *
-   * It is **required**, in the type and again at runtime via
-   * {@link assertFundingBasis}. A basis-less fund wrote `rail = NULL`, and a
-   * draw against such a credit settles — a real debit — while
-   * `railAsFundingMethod` correctly declines to guess a rail, so `bookRevenue`
-   * books nothing and outstanding liability (`deposits − draw revenue`) stays
-   * overstated by the drawn amount forever. `credits.rail` stays nullable
-   * because rows written before this change still exist in live databases:
-   * **write is closed, read is not.** A legacy row adopts a rail from its first
-   * typed top-up via the `COALESCE` below.
-   *
-   * The rail-native **instrument** is pinned at first funding too, and both
-   * channel guards are symmetric for the same reason. A reusable
-   * channel — Tempo session or x402 batch-settlement — may only ever top up
-   * the credit it opened, and a credit opened by a one-shot (a Tempo charge, an
-   * x402 exact authorization) may never adopt one. The x402 half used to admit
-   * `credits.x402_channel_id IS NULL`, so a channel deposit bound itself to a
-   * credit already holding exact-funded value: `earnedNativeForX402Channel`
-   * then read that credit's whole settled-draw history as the channel's
-   * earnings, and the first claim tick swept a deposit nobody had consumed,
-   * while the unspent balance lost every exit (the drain's refund base goes
-   * below `totalClaimed`, and a channel-bound credit refuses every non-x402
-   * drain). `credits_x402_channel_uidx` does not cover this: it guards
-   * one-credit-per-channel, not one-source-per-credit.
-   *
-   * An x402 channel deposit is additionally refused `settlement_pending` while
-   * that channel carries an unresolved refund — see the gate read
-   * below. This method is the authority on that rule, as it is on the binding
-   * rules above; every door preflights it where a refusal is still free.
+   * Funding adds balance and overwrites expiry, reviving an expired credit. It is additive,
+   * not idempotent: the caller’s rail marker or funding record must prevent replay. Owner and
+   * currency must match; rail and reusable-channel bindings cannot be mixed with other
+   * instruments. A legacy NULL rail adopts its first typed top-up.
+   *
+   * With tx, all writes join the caller’s transaction without transaction control. Otherwise
+   * the ledger owns a transaction covering balance, funding lot, reversal of standing expiry
+   * releases and their reports. A partial revival would leave restored balance with a release
+   * still counted.
+   *
+   * An incoming x402 channel with an unresolved refund is refused before the upsert. That
+   * preflight is not atomic with a concurrent cooperative drain; see the incoming-channel
+   * gate below.
    */
   async fund(args) {
     assertAmount(args.amountMicro, { min: 1 });
@@ -1448,11 +1375,6 @@ var CreditLedger = class {
       client.release();
     }
   }
-  /**
-   * The funding itself, on whichever handle {@link fund} chose. Every refusal
-   * it raises is the caller's to see unchanged; a self-opened transaction rolls
-   * back around it.
-   */
   async fundOn(q, args, b, nowMs, creditId) {
     const wedged = await this.blockingX402Refund(
       b.x402Channel?.channelId,
@@ -1590,33 +1512,12 @@ var CreditLedger = class {
     return this.snapshotFromRow(revived ?? rows[0], q, nowMs);
   }
   /**
-   * Undo any expiry release this credit still carries, because a funding just
-   * landed on it (the revival rule), restoring the balance the
-   * release took.
+   * Funding reverses standing expiry releases, restores their released micro and queues
+   * reversal reports on the funding transaction. Do this even when the new expiry is already
+   * past: the next sweep must release the enlarged remainder as a new episode.
    *
-   * A release records the credit's **final** undrawn remainder and zeroes it
-   * (see {@link releaseExpiredCreditLocked}). Funding adds to the balance and
-   * overwrites `expiry_ms` (the caller-ownership contract carry-forward: the credit is a rolling
-   * buffer), so the moment money arrives the recorded remainder is no longer
-   * final: the release stops counting and its micro come back.
-   *
-   * Deliberately unconditional on the incoming expiry rather than gated on
-   * `expiryMs > nowMs`. A release exists only for a credit that had already
-   * lapsed, so any funding that reaches one is money the release did not
-   * account for — and a funding that arrives with an already-past expiry leaves
-   * a credit the very next sweep re-releases at its new, larger remainder. One
-   * rule, self-healing in both directions, and it never needs to read the
-   * pre-funding expiry the upsert has already overwritten.
-   *
-   * Runs on the funding's own handle — which {@link fund} now guarantees is a
-   * transaction — so the reversal, the restored balance and the report commit
-   * with the money or not at all. A reversal that committed without its report
-   * would be unrecoverable: `WHERE reversed_at IS NULL` means no later pass
-   * re-derives it.
-   *
-   * @returns the credit row as the restore left it, or undefined when there was
-   * nothing to reverse. The caller reads its snapshot off this rather than off
-   * the funding upsert's `RETURNING`, which predates the restore.
+   * Returns the row after restoration, or undefined when no release stood. The upsert’s
+   * RETURNING row predates the restoration and is not the final balance.
    */
   async reverseExpiryReleases(q, creditId, nowMs) {
     const { rows } = await q.query(
@@ -1641,37 +1542,15 @@ var CreditLedger = class {
     return restored[0];
   }
   /**
-   * Release the undrawn remainder of every credit whose TTL has run out
-   * Returns the releases this pass recorded.
-   *
-   * **What is released.** The credit's whole `balance_micro`. Expiry ends
-   * spending but never ownership of the record, so the balance stays readable;
-   * what ends is the caller's claim on it, and on the prepaid rails the value
-   * behind it is already in builder custody.
-   *
-   * **Tempo is excluded**, at both of its markers (`tempo_channel_id` and a
-   * `tempo` rail). A Tempo credit is channel-backed and its undrawn value
-   * returns to the *caller* at channel exit, so releasing it would book the
-   * builder money the chain is about to hand back.
-   *
-   * **A credit with a pending hold is skipped, not partially released.** A draw
-   * placed before expiry stays settleable afterwards (`draw`'s replay lookup
-   * runs above the expiry check, so a lost response is still recoverable), so
-   * the remainder is not final while a hold is outstanding. Skipping costs one
-   * sweep interval and keeps the released figure exactly "what nothing bought";
-   * holds do resolve — the orphan-draw watchdog is what guarantees
-   * a stranded one still reaches a terminal state.
-   *
-   * **Idempotent** two ways. `release_id` is derived from the expiry instant,
-   * so a re-sweep after a crash between the insert and its report collides on
-   * the same primary key instead of writing a second row; and the candidate
-   * scan excludes any credit that already has an un-reversed release.
-   *
-   * Each candidate is re-checked under the credit row lock every
-   * `credit_draws` write is taken under, so a draw racing the sweep either
-   * loses the race (its credit is already released and it would have been
-   * refused `credit_expired` anyway) or wins it and leaves a pending hold the
-   * locked re-check sees.
+   * Release expired undrawn balances, retaining readable credit records. Tempo rail or
+   * channel-backed credits are excluded because their collateral returns to the caller
+   * through the channel lifecycle.
+   *
+   * Pending holds prevent release: jobs accepted before expiry may still settle or release.
+   * Candidates are rechecked under the same parent-credit lock used by draw writes. The
+   * balance debit, episode record and report commit together; standing releases exclude
+   * repeat work. A later revival may reuse the expiry instant but receives a new release
+   * sequence.
    */
   async sweepExpiredCredits(args) {
     const nowMs = args?.nowMs ?? Date.now();
@@ -1707,30 +1586,12 @@ var CreditLedger = class {
     return { released };
   }
   /**
-   * Write one credit's expiry release under its row lock, zero the balance it
-   * released, and re-assert every condition the unlocked candidate scan tested.
-   * Returns undefined when the credit no longer qualifies — funded, drawn
-   * against, or already released between the scan and the lock.
-   *
-   * **Zeroing the balance is what makes the release real**, and it is the whole
-   * reason this runs under the lock rather than as a bare INSERT. The row alone
-   * records that the caller's claim ended; it does not *end* it. `requestDrain`
-   * has no expiry check by design (expiry gates new draws, not reclaims), so a
-   * credit whose remainder had been released and reported was still fully
-   * drainable: the DVM would pay out money the platform had already booked as
-   * the builder's, and `deposited - drawn - drained - released` would go
-   * negative on the same micro. With the balance at zero, `requestDrain`'s
-   * existing `availableMicro <= 0` guard refuses with `nothing_to_drain` and no
-   * new check is needed anywhere. {@link reverseExpiryReleases} puts the
-   * balance back when a funding revives the credit.
+   * Recheck eligibility under the credit lock and zero the released balance in the same
+   * transaction as its episode/report. Otherwise requestDrain, which intentionally ignores
+   * expiry, could reclaim value already released to the builder.
    *
-   * `status` deliberately stays `active`: a released credit must remain
-   * fundable, or the revival rule has nothing to revive.
-   *
-   * The zeroed balance also takes the credit out of `BITCOIN_CREDIT_PREDICATE`
-   * (`balance_micro > 0`), so the in-kind sweep floor stops counting sats the
-   * builder no longer owes back — and counts them again after a revival, with
-   * the credit's funding lots untouched throughout.
+   * Keep status active so future funding can revive it. Funding lots remain intact: balance
+   * zero excludes this credit from Bitcoin liability, and reversal restores that liability.
    */
   async releaseExpiredCreditLocked(client, credit, nowMs) {
     const expiryMs = toSafeInt(credit.expiry_ms);
@@ -1778,34 +1639,12 @@ var CreditLedger = class {
     return row;
   }
   /**
-   * Record this funding's in-kind basis as a lot.
-   *
-   * Called from inside {@link fund}, on the same handle, so the lot shares
-   * whatever transaction the rail opened — `withCommitTx` for Cashu,
-   * `ProcessedPaymentStore.withTx` for x402/Tempo, `settleInvoice`'s own
-   * `BEGIN` for Lightning. The funding-atomicity invariant therefore extends
-   * to it structurally rather than by every call site remembering: a lot
-   * cannot exist without its ledger credit, or the credit without its lot.
-   *
-   * Only a **channel-backed** credit writes no lot: it is in-kind already —
-   * the escrow itself retains the unused value — so a lot on one would be
-   * counted as Bitcoin deposit liability the hub does not hold.
-   *
-   * Every other non-channel Bitcoin funding writes one, the implicit N=1
-   * per-call payment included. That one funds and draws the same amount in
-   * this transaction, so it looks like a lot born depleted — but the draw is a
-   * *pending hold*, not a debit, and only a `completed` job settles it
-   * (`JobManager.settlesDraw`). A failed, cancelled or stale-swept job
-   * releases the hold and the whole funded amount becomes reclaimable balance,
-   * so suppressing the lot here would leave routine traffic reclaiming off a
-   * live rate and missing from the sweep floor. One small insert on the hot
-   * path buys the invariant the liability read depends on: open lots cover
-   * `balance_micro` for every Bitcoin credit, always.
+   * Record non-channel Bitcoin funding lots on the funding transaction. An implicit payment
+   * also needs a lot: its draw is initially only a hold, and failure releases the whole
+   * balance for reclaim. Channel collateral is excluded from Bitcoin lots.
    *
-   * A zero-sats basis still writes a lot. It is honest — the credit exists and
-   * we know its rail — and it is what makes "covered but unbacked" a
-   * distinguishable state from "no lot at all" for the reclaim and the
-   * liability rollup, instead of both reading as a gap.
+   * A zero-sats basis still records a lot, distinguishing covered but basisless credit from a
+   * missing-lot coverage gap.
    */
   async recordFundingLot(q, creditId, amountMicro, basis, nowMs) {
     if (!isNonChannelBitcoinRail(basis.rail)) return;
@@ -1826,25 +1665,13 @@ var CreditLedger = class {
     );
   }
   /**
-   * Place a two-phase `pending` hold of `amountMicro` against the credit and
-   * assign the next `ledger_seq`. Idempotent on `(creditId, drawId)`: a replay
-   * returns the original `{balanceAfterMicro, ledgerSeq}` with
-   * `replayed: true` and places no second hold — this is how a caller recovers
-   * a lost response (spec condition 1). A replay whose `amountMicro` or
-   * `jobId` differs from the recorded draw is not a replay but a money bug in
-   * the caller, refused with `draw_conflict`.
+   * Place a pending hold with the next shared per-credit sequence. A matching (creditId,
+   * drawId) replay returns its recorded tuple without another hold; conflicting amount or
+   * jobId is draw_conflict.
    *
-   * The replay lookup runs **before** the expiry check, deliberately: a draw
-   * placed pre-expiry must stay recoverable after the credit expires, or the
-   * DVM holds a debit the caller can never reconcile. Fresh draws on an
-   * expired credit are refused with `credit_expired`; the balance stays
-   * intact and readable (the caller-ownership contract: expiry ends spending, never ownership).
-   *
-   * Pass `tx` (a client inside a caller-owned `BEGIN`) to place the hold in
-   * the same transaction as the rail commit and the `fund` upsert (spec
-   * condition 3 — the implicit N=1 path). The ledger issues no
-   * transaction control on `tx`; the `SELECT … FOR UPDATE` row lock is still
-   * taken on the caller's transaction, so the locking invariant holds.
+   * Replay precedes expiry and settlement gates so a lost response stays recoverable. Fresh
+   * draws require spendable credit. With tx, take the parent-credit lock on the caller’s
+   * transaction without issuing transaction control.
    */
   async draw(args) {
     assertAmount(args.amountMicro, { min: 0 });
@@ -1960,66 +1787,26 @@ var CreditLedger = class {
     return this.withCreditLock(args.creditId, (client, credit) => run(client, credit));
   }
   /**
-   * The unresolved refund on `channelId` that must stop this ledger effect, if
-   * any.
-   *
-   * `undefined` whenever there is nothing to ask — an unbound credit, or a DVM
-   * with no durable settlement store, where a settlement row cannot exist.
-   *
-   * Public since the behavior was introduced, so `/v1/credit`'s pre-payment preflight can ask the
-   * same question `fund` will ask from inside the rail transaction — one read,
-   * one answer, rather than a second copy of the rule in the routes.
+   * Return the unresolved refund that blocks an effect on this channel, or undefined. Route
+   * preflights use the same rule before moving money; draw and drain also read it under the
+   * credit lock.
    */
   async blockingX402Refund(channelId, statuses) {
     if (!channelId || !this.x402Settlements) return void 0;
     return this.x402Settlements.pendingRefundSettlement(channelId, statuses);
   }
   /**
-   * Grow a pending draw by `addAmountMicro` — the ledger half of a
-   * mid-job `requestPayment` top-up. One job keeps **one** draw: the mid-job
-   * money funds the same credit and enlarges the hold the upfront leg placed,
-   * so the receipt's `ReceiptCredit` block countersigns the job's full cost
-   * and `revenue_events` still books exactly one row per job.
-   *
-   * `draw()` cannot express this: a same-`draw_id` call with a different
-   * amount is `draw_conflict` by design (a replayed draw must never re-price).
-   *
-   * The arithmetic is `draw()`'s, unchanged: `addAmountMicro` is checked
-   * against — and `balance_after_micro` recomputed from — the balance net of
-   * **every** pending hold, this draw's own included. That is deliberately the
-   * conservative reading (a fresh draw of `addAmountMicro` would see exactly
-   * the same figure), and it is what keeps the total held after growth inside
-   * the credit's balance.
-   *
-   * The increment's rail value comes from {@link growthRailValue}: earmarked
-   * to the funding that backs it when the caller names one (the mid-job case),
-   * pro-rata otherwise. Either way the draws of a credit keep summing to
-   * precisely what the rails paid.
-   *
-   * **`ledger_seq` is not re-taken.** The per-credit sequence is gap-free
-   * (`credit_draws_seq_uidx`), so moving this draw forward would strand its
-   * original number. The consequence is deliberate and worth knowing: the
-   * recorded `balance_after_micro` is the post-growth figure stamped at the
-   * *original* seq, so a credit with interleaved sibling activity has a
-   * trajectory that is truthful per draw rather than monotonic across seqs.
-   *
-   * **No expiry check**, matching `settle`/`release`: the job was accepted
-   * pre-expiry and is still running. Refusing here would strand the handler
-   * mid-flight over a clock the caller can't influence.
+   * Grow an accepted job’s pending hold while preserving its original ledger_seq. The balance
+   * tuple is updated at that sequence, so interleaved draws need not form a monotonic balance
+   * trajectory. No expiry check applies to an already accepted job.
    *
-   * **Not idempotent by itself.** Growth carries no key of its own — it
-   * inherits the rail's (the accumulator's `(dvm_id, request_id)` UNIQUE rolls
-   * the whole transaction back on replay; x402/mpp collide on the
-   * `processed_payments` marker). Never call it outside a rail commit.
+   * Available balance excludes every pending hold, including this one. An earmark allocates
+   * the incoming funding’s rail value; absent one, growth uses the pool.
    *
-   * **`capMicro` bounds cumulative growth at what the job cumulatively asked,**
-   * and it is the only ceiling that can refuse a top-up: the
-   * available-balance check cannot, because the `fund` a moment earlier in
-   * this same transaction raised the balance by exactly the amount being
-   * drawn. Excess is **granted partially or not at all rather than thrown** —
-   * this runs inside the rail commit, so a throw would roll back cashu proofs
-   * the caller already sent. The refused remainder stays funded balance the
-   * caller owns and can drain.
+   * Growth has no independent replay key: compose it with the rail’s replay protection in one
+   * transaction. capMicro bounds cumulative growth at the job’s cumulative ask. Excess
+   * remains caller-owned funded balance; partial or zero growth returns that excess rather
+   * than throwing and rolling back accepted proofs.
    */
   async growDraw(args) {
     assertAmount(args.addAmountMicro, { min: 1 });
@@ -2212,18 +1999,9 @@ var CreditLedger = class {
     return this.resolveDraw({ ...args, to: "released" });
   }
   /**
-   * Record a fund-only top-up under its client-generated `fundId`.
-   * The deposit half of the evidence chain, and the top-up path's idempotency
-   * key: `PRIMARY KEY (credit_id, fund_id)` means a concurrent duplicate
-   * loses with a typed `funding_replayed` rather than crediting twice.
-   *
-   * Call it inside the same `tx` as {@link fund} — the rail commit, the
-   * funding record, and the balance increment must land together or not at
-   * all (the funding-commitment rule). Like `fund`, this issues no transaction
-   * control on `tx`; it is a single statement.
-   *
-   * This does **not** move money on its own. `fund` still does the crediting;
-   * this row is what lets a retry be answered with the original outcome.
+   * Record the fund-only replay key without moving money. A duplicate (credit_id, fund_id)
+   * raises funding_replayed. Compose this insert, fund and rail acceptance on the same
+   * caller-owned transaction; a retry reads the recorded funding outcome.
    */
   async recordFunding(args) {
     assertAmount(args.amountMicro, { min: 1 });
@@ -2348,7 +2126,6 @@ var CreditLedger = class {
     }
     return existing;
   }
-  /** Read one invoice (no lock). */
   async getInvoice(args) {
     const { rows } = await this.pool.query(
       `SELECT * FROM credit_invoices WHERE credit_id = $1 AND fund_id = $2`,
@@ -2373,22 +2150,10 @@ var CreditLedger = class {
     return rows.map(invoiceRecordFromRow);
   }
   /**
-   * Apply an observed Lightning settlement to the ledger — **the exactly-once
-   * boundary** (the funding-commitment rule for a rail whose commit happens
-   * off-box).
-   *
-   * One transaction covers the funding record, the balance, and the invoice's
-   * own status flip, so the three can never disagree. A crash anywhere inside
-   * leaves the invoice `pending` and the balance untouched: the next
-   * `lookup_invoice` observes the same settled payment and credits it, once.
-   * A replayed check after the commit sees `settled` and moves nothing.
-   *
-   * The lock is on the **invoice** row, not the credit row: the first
-   * Lightning top-up is what opens the credit, so there is frequently no
-   * `credits` row to take `FOR UPDATE` yet. That does not weaken the ledger's
-   * concurrency contract — no `credit_draws` write happens here, and `fund`'s
-   * upsert is a single statement — while still serialising two settlement
-   * checks racing on the same invoice.
+   * Serialize settlement on the invoice row, which exists before the first credit does.
+   * Funding record, balance, invoice status and optional deposit outbox commit together. An
+   * interrupted transaction leaves the prior invoice status intact for retry; a settled replay
+   * moves no money.
    */
   async settleInvoice(args) {
     assertFundingBasis(args.basis);
@@ -2482,19 +2247,9 @@ var CreditLedger = class {
     return this.getInvoice(args);
   }
   /**
-   * Retire an invoice that **was paid** and can never be credited.
-   *
-   * Distinct from `expired` because the money is the opposite way round: an
-   * expired invoice was never paid and owes nobody anything, whereas a blocked
-   * one has sats sitting in the builder's wallet with no ledger row to put them
-   * on. Only an operator can resolve that, so the row records `reason` and
-   * stops being swept — leaving it `pending` would spend one of the sweep's few
-   * slots re-deriving the same verdict on every request the caller makes, and
-   * three of them would wedge that caller's sweep so a genuinely payable
-   * invoice behind them never credits.
-   *
-   * A CAS on `pending`, like the expiry retirement: a settlement observed
-   * concurrently must win.
+   * Mark a paid invoice blocked when its payment cannot be credited. This removes it from the
+   * bounded pending sweep and leaves its reason for operator repair. The pending-only CAS
+   * cannot overwrite a committed settlement.
    */
   async markInvoiceBlocked(args) {
     await this.pool.query(
@@ -2504,7 +2259,6 @@ var CreditLedger = class {
     );
     return this.getInvoice(args);
   }
-  /** Read one invoice by the wallet's own identifier for the payment (no lock). */
   async getInvoiceByPaymentHash(paymentHash) {
     const { rows } = await this.pool.query(
       `SELECT * FROM credit_invoices WHERE payment_hash = $1`,
@@ -2513,17 +2267,9 @@ var CreditLedger = class {
     return rows.length > 0 ? invoiceRecordFromRow(rows[0]) : void 0;
   }
   /**
-   * The operator's queue: invoices the sweep gave up on.
-   *
-   * **Keyset-paginated, not offset.** Blocked rows are terminal and never
-   * self-clear, so a row the operator declines to act on sits at the head of
-   * the age ordering forever; a fixed first page would starve everything
-   * behind it on every run, which is the shape one page up.
-   *
-   * `includeResolved` widens to the operator-resolved statuses so a run can be
-   * audited after the fact.
-   * Host-wide, like `listPendingDrains`: the ledger has no `dvm_id`, so on a
-   * multi-mount host one builder's admin credential reads every mount's rows.
+   * Host-wide operator queue, keyset-paginated so an untouched blocked row does not starve
+   * later rows. includeResolved also exposes reconciled and written-off history; the ledger
+   * has no per-mount dvm_id.
    */
   async listBlockedInvoices(args) {
     const statuses = args.includeResolved ? ["blocked", "reconciled", "written_off"] : ["blocked"];
@@ -2545,37 +2291,15 @@ var CreditLedger = class {
     return rows.map(invoiceRecordFromRow);
   }
   /**
-   * Apply a blocked invoice's payment to a credit an operator named — the
-   * repair for the one Lightning outcome the DVM cannot fix itself.
-   *
-   * Shaped statement-for-statement on {@link settleInvoice}, because it is the
-   * same money doing the same thing a different way: one transaction covering
-   * the funding record, the balance, the invoice's status flip and the deposit
-   * outbox row, so the four can never disagree. Three deliberate differences:
-   *
-   * - **The lock is taken on `payment_hash`**, which is UNIQUE and is the
-   * identifier the operator actually holds (it is what the
-   * `lightning_settlement_blocked` log carries and what names the payment in
-   * their wallet). Invoice row first, credit row second via `fund`'s upsert —
-   * the same order `settleInvoice` takes, which is what keeps a reconcile and
-   * a concurrent settlement check from deadlocking against each other.
-   * - **The funding lands at `(targetCreditId, paymentHash)`, not the invoice's
-   * own `(credit_id, fund_id)`.** That key is frequently the reason the row
-   * is blocked at all — `funding_replayed_on_cashu` means something else
-   * already holds it — and the operator's most natural target is that very
-   * credit. The payment hash cannot collide with it, and it makes all three
-   * references to this payment agree: `basis.fundingRef`, the deposit's
-   * `funding_id`, and the funding row's `fund_id`.
-   * - **`written_off` is an accepted input status.** A write-off unwound
-   * nothing, so an operator who closed a row by mistake must not need raw SQL
-   * against a money table to reopen it.
-   *
-   * The invoice row's status — never the funding row — is the idempotency
-   * source of truth. `fund_id` is caller-chosen and the payment hash is
-   * disclosed to them, so a caller *can* squat `(theirCredit, thatHash)` with a
-   * top-up on another rail; when they have, `recordFunding` throws
-   * `funding_replayed` and that surfaces as its own loud failure rather than
-   * being absorbed as "already reconciled".
+   * Apply a blocked or written-off invoice to an operator-named credit. Lock the invoice by
+   * its unique payment_hash before funding the credit, matching settlement’s
+   * invoice-to-credit lock order. Funding, balance, resolution and optional outbox share one
+   * transaction.
+   *
+   * The repair funding key is (targetCreditId, paymentHash), distinct from the original
+   * caller-chosen fundId. Invoice status determines replay. A caller can still occupy the
+   * repair key with another payment; funding_replayed must remain a refusal, not be absorbed
+   * as already reconciled. Preserve blocked_reason and the wallet’s settlement instant.
    */
   async reconcileBlockedInvoice(args) {
     assertFundingBasis(args.basis);
@@ -2675,17 +2399,9 @@ var CreditLedger = class {
     }
   }
   /**
-   * Record that an operator reviewed a blocked invoice and chose not to credit
-   * it — no ledger effect, purely a queue transition.
-   *
-   * A CAS on `blocked`, and idempotent: re-running returns the recorded row
-   * rather than overwriting the first note. It cannot capture a `reconciled`
-   * row, because that one moved money.
-   *
-   * `written` reports whether *this* call was the transition. The caller has
-   * no other way to tell — the row reads identically either way — and the
-   * write-off's audit log is the only record of the amount, so a re-emitted
-   * one reads as a second decision about the same sats.
+   * Write off an invoice without crediting or moving money. Only the first transition records
+   * the note; its written bit controls the audit event. An operator can later reconcile a
+   * written-off invoice, because write-off did not return its payment.
    */
   async writeOffBlockedInvoice(args) {
     const { rowCount } = await this.pool.query(
@@ -2719,7 +2435,6 @@ var CreditLedger = class {
     }
     return out;
   }
-  /** Read one draw (no lock), with its credit's rail basis joined in. */
   async getDraw(args) {
     const { rows } = await this.pool.query(
       `${DRAW_WITH_BASIS_SELECT} WHERE d.credit_id = $1 AND d.draw_id = $2`,
@@ -2735,7 +2450,6 @@ var CreditLedger = class {
     );
     return rows.length === 1 ? drawRecordFromRow(rows[0], rows[0]) : void 0;
   }
-  /** Read every draw linked to a job, including already-resolved rows. */
   async listDrawsByJobId(jobId) {
     const { rows } = await this.pool.query(
       `${DRAW_WITH_BASIS_SELECT} WHERE d.job_id = $1 ORDER BY d.created_at, d.credit_id, d.ledger_seq`,
@@ -2756,22 +2470,10 @@ var CreditLedger = class {
     return rows.map((row) => drawRecordFromRow(row, row));
   }
   /**
-   * One page of pending holds host-wide placed before `createdBeforeMs`,
-   * oldest first (no lock). The orphan sweeper's read surface: a
-   * draw commits with its `job_id` before the job row is persisted, so a crash
-   * or a fail-closed refusal in that window strands a hold nothing can ever
-   * resolve — the only release path keys off the `credit_id`/`draw_id` written
-   * on the job row.
-   *
-   * Host-wide like {@link listPendingDrains}, not per-credit: the sweeper has
-   * no candidate credit to start from. Age-bounded so it never sees a draw
-   * whose job row is merely still in flight.
-   *
-   * `limit` is required and `after` keyset-paginates: an aged hold whose job
-   * row *does* exist is legitimately un-sweepable and stays `pending`
-   * indefinitely, so a caller that re-issues the same first page would never
-   * see past a `limit`-sized wall of them. Pass the last row's
-   * {@link StalePendingDrawCursor} to advance.
+   * Page host-wide pending holds older than createdBeforeMs by (created_at, credit_id,
+   * ledger_seq). Use the same compound key for ordering and continuation, preserving
+   * same-millisecond rows. Terminal resolution still rechecks state under the parent-credit
+   * lock.
    */
   async listStalePendingDraws(args) {
     const after = args.after;
@@ -2793,21 +2495,9 @@ var CreditLedger = class {
     return rows.map((row) => drawRecordFromRow(row, row));
   }
   /**
-   * Rail-native value the credit an x402 settlement channel funded has
-   * actually earned — the sum of its **settled** draws, in the credit's native
-   * atomic units (USDC micro on this rail). The batch-settlement claim job's
-   * ceiling: a channel is claimable up to what its credit's draws
-   * have earned, never up to the deposit that funded it.
-   *
-   * `undefined` when no credit is bound to the channel, which the claim job
-   * treats as "cannot be resolved" and claims nothing for — distinct from a
-   * resolved credit that has earned `0`.
-   *
-   * Deliberately a sum over settled draws rather than `funded − remaining`:
-   * a drain lowers `native_remaining` without earning anything, so the
-   * subtraction would read the caller's own reclaim as revenue. Pending holds
-   * are excluded for the mirror reason — a hold is work in flight, and
-   * claiming against it would take money a release still owes back.
+   * Sum settled draws’ native value for the credit bound to this x402 channel.
+   * Pending/released holds and drains earn nothing. Return undefined for an unbound channel,
+   * distinct from earned zero, so settlement cannot guess a claim limit.
    */
   async earnedNativeForX402Channel(channelId) {
     const { rows } = await this.pool.query(
@@ -2827,14 +2517,8 @@ var CreditLedger = class {
     return toSafeInt(rows[0].earned);
   }
   /**
-   * The credit an x402 settlement channel funded, if one is bound to it — the
-   * binding is UNIQUE, so at most one row can answer.
-   *
-   * The operator repair's entry point: a wedged settlement row carries the
-   * channel and an `effect_id`, and this is what turns them back into the
-   * credit id, the caller pubkey, and the drain id the effect encodes. Deriving
-   * the credit id by splitting `effect_id` instead would be wrong — credit ids
-   * carry their own colons (`imp:`, `fnd:` and the rail segment inside them).
+   * Resolve the unique credit bound to the channel. The ID is opaque and can contain colons;
+   * do not reconstruct it by splitting settlement effect IDs.
    */
   async getCreditByX402Channel(channelId) {
     const { rows } = await this.pool.query(
@@ -2843,7 +2527,6 @@ var CreditLedger = class {
     );
     return rows[0] ? this.snapshotFromRow(rows[0], this.pool, Date.now()) : void 0;
   }
-  /** Retire every active credit backed by a chain-proven lost Tempo channel. */
   async terminalizeTempoCredits(evidence, tx) {
     const channelId = evidence.channelId.toLowerCase();
     const observedAt = evidence.observedAt ?? Date.now();
@@ -2909,7 +2592,6 @@ var CreditLedger = class {
     }
     return this.readTempoCreditLosses(q, { channelId });
   }
-  /** List terminal Tempo credit losses, newest observation first. */
   async listTempoCreditLosses(args) {
     return this.readTempoCreditLosses(this.pool, { limit: args?.limit ?? 50 });
   }
@@ -3003,32 +2685,18 @@ var CreditLedger = class {
     }
     return this.readX402CreditLosses(q, { channelId });
   }
-  /** List terminal x402 credit losses, newest observation first. */
   async listX402CreditLosses(args) {
     return this.readX402CreditLosses(this.pool, { limit: args?.limit ?? 50 });
   }
   /**
-   * Debit the caller's entire available balance into a drain liability
-   * (the caller-ownership contract: expiry ends spending, never ownership — this is the
-   * builder-honored reclaim floor). Runs under the credit row lock: the
-   * amount is `balance − pending holds` read under `FOR UPDATE`, the balance
-   * is decremented in the same transaction, and the drain takes the next
-   * gap-free `ledger_seq` — so the balance zeroes exactly once however many
-   * machines race the request.
-   *
-   * Idempotent on `(creditId, drainId)`: a replay returns the recorded drain
-   * (this is also the poll/pickup read). A replay whose `method` or `payout`
-   * differs from the recorded drain is refused with `drain_conflict` —
-   * silently honouring a changed payout would ship the caller's money to a
-   * destination they never signed alongside this `drain_id`.
-   *
-   * Pending holds are NOT drained — in-flight jobs keep their money until
-   * they settle or release. A release after a drain restores available
-   * balance the caller reclaims with a **new** `drain_id`; drains are ledger
-   * arithmetic, not a terminal credit state, so `status` stays `active`.
-   *
-   * Deliberately **no expiry check**: draining works before and after
-   * expiry. The one thing expiry gates is new draws.
+   * Move all available balance to a drain liability under the credit lock; pending holds stay
+   * reserved. Expiry alone does not prevent reclaim before a sweep releases the balance.
+   * Repeating (creditId, drainId) returns the recorded liability; owner, method and payout
+   * conflicts refuse.
+   *
+   * An unresolved channel refund blocks fresh drain IDs but admits its own effect ID for
+   * repair. Caller-supplied payout validation belongs to the route. With tx, join the channel
+   * transaction without controlling it.
    */
   async requestDrain(args) {
     const nowMs = args.nowMs ?? Date.now();
@@ -3138,7 +2806,6 @@ var CreditLedger = class {
     }
     return this.withCreditLock(args.creditId, run);
   }
-  /** Read one drain (no lock), joined with its credit for currency + owner. */
   async getDrain(args) {
     const { rows } = await this.pool.query(
       `SELECT d.*, ${DRAIN_CREDIT_COLUMNS} FROM credit_drains d
@@ -3157,25 +2824,11 @@ var CreditLedger = class {
     return this.openLots(this.pool, creditId);
   }
   /**
-   * What this DVM owes back in satoshis if every open non-channel Bitcoin
-   * credit reclaimed right now — the deposit half of the hub
-   * balance, and the floor a payout sweep must never go below.
-   *
-   * Read entirely off the funding lots, at their own funding rates, with no
-   * exchange-rate lookup anywhere: the obligation is in kind, so a rate has
-   * nothing to say about it. Pending job holds are deliberately **not**
-   * subtracted — a hold either settles into revenue or releases back to the
-   * caller, and until it does, treating it as already earned would understate
-   * the floor. The figure is conservative by exactly that amount.
-   *
-   * The two coverage holes ride along rather than being folded in silently, so
-   * a gap reads as a gap: `uncovered` is a credit whose lots fall short of its
-   * balance, `unbacked` is one holding any open micro with no sats basis. A
-   * reclaim on either prices the **whole** balance off a live rate — the
-   * depletion refuses a mixture rather than blending two bases — so both are
-   * reported as the whole balance, and neither contributes to `depositSats`.
-   * A figure that counted the backed half of a mixed credit would be a floor
-   * the payout never matches.
+   * Host-wide in-kind Bitcoin deposit liability, excluding channel collateral. Credits with
+   * missing coverage or any basisless lot are reported as gaps and use the live-rate fallback
+   * rather than a guessed sats obligation. Group fiat micro by currency; never sum
+   * denominations.
+   * Pending job holds remain liabilities until settled because they may release to the caller.
    */
   async bitcoinDepositLiability() {
     const { rows } = await this.pool.query(
@@ -3203,21 +2856,43 @@ var CreditLedger = class {
       byRail: [],
       byCurrency: [],
       uncoveredCredits: 0,
-      uncoveredMicro: 0,
+      uncoveredByCurrency: [],
       unbackedCredits: 0,
-      unbackedMicro: 0
+      unbackedByCurrency: []
     };
     const byRail = /* @__PURE__ */ new Map();
     const byCurrency = /* @__PURE__ */ new Map();
+    const uncoveredByCurrency = /* @__PURE__ */ new Map();
+    const unbackedByCurrency = /* @__PURE__ */ new Map();
     for (const row of rows) {
       const sats = toSafeInt(row.owed_sats);
       const credits = toSafeInt(row.credits);
+      const uncoveredCredits = toSafeInt(row.uncovered_credits);
+      const unbackedCredits = toSafeInt(row.unbacked_credits);
       liability.depositSats += sats;
       liability.credits += credits;
-      liability.uncoveredCredits += toSafeInt(row.uncovered_credits);
-      liability.uncoveredMicro += toSafeInt(row.uncovered_micro);
-      liability.unbackedCredits += toSafeInt(row.unbacked_credits);
-      liability.unbackedMicro += toSafeInt(row.unbacked_micro);
+      liability.uncoveredCredits += uncoveredCredits;
+      liability.unbackedCredits += unbackedCredits;
+      if (uncoveredCredits > 0) {
+        const currency2 = uncoveredByCurrency.get(row.currency) ?? {
+          currency: row.currency,
+          micro: 0,
+          credits: 0
+        };
+        currency2.micro += toSafeInt(row.uncovered_micro);
+        currency2.credits += uncoveredCredits;
+        uncoveredByCurrency.set(row.currency, currency2);
+      }
+      if (unbackedCredits > 0) {
+        const currency2 = unbackedByCurrency.get(row.currency) ?? {
+          currency: row.currency,
+          micro: 0,
+          credits: 0
+        };
+        currency2.micro += toSafeInt(row.unbacked_micro);
+        currency2.credits += unbackedCredits;
+        unbackedByCurrency.set(row.currency, currency2);
+      }
       const rail = byRail.get(row.rail) ?? { rail: row.rail, sats: 0, credits: 0 };
       rail.sats += sats;
       rail.credits += credits;
@@ -3233,6 +2908,8 @@ var CreditLedger = class {
     }
     liability.byRail = [...byRail.values()];
     liability.byCurrency = [...byCurrency.values()];
+    liability.uncoveredByCurrency = [...uncoveredByCurrency.values()];
+    liability.unbackedByCurrency = [...unbackedByCurrency.values()];
     return liability;
   }
   /**
@@ -3252,34 +2929,10 @@ var CreditLedger = class {
     return rows.map(drainRecordFromJoinRow);
   }
   /**
-   * One page of still-`pending` drains on a channel-backed credit, oldest
-   * first (no lock) — the operator's repair queue.
-   *
-   * Keyset-paginated for the x402 settlement queue's reason: a wedged row
-   * never self-clears, so a caller that re-issues the same first page would
-   * never see past a `limit`-sized wall of them. The keyset is
-   * `(created_at, credit_id, drain_id)` — `created_at` is immutable, so no
-   * concurrent write can push an unexamined row past the cursor. It is a
-   * BIGINT of epoch milliseconds rather than a `TIMESTAMPTZ`, so the
-   * microsecond-vs-millisecond cursor trap that bit `listSettlements` cannot
-   * arise here: the value round-trips as the integer it already is.
-   *
-   * `createdBeforeMs` is the staleness floor. A healthy cooperative close
-   * moves the drain to `sent` inside the request that opened it, so anything
-   * younger is in flight rather than stuck.
-   *
-   * The method filter is `'tempo'`, and it is the one line here worth a second
-   * look: `init()` migrates the legacy `'mpp'` spelling away and
-   * `DrainMethod` no longer carries it, so a query naming it matches nothing a
-   * DVM has ever written. It named it anyway until rename sweep and
-   * live rung caught it independently — the whole operator queue
-   * read empty in production while every route test stayed green, because
-   * those run on `MemoryCreditLedger`, which filters on the typed value. The
-   * two implementations of this one predicate must be read together.
-   *
-   * A written-off row is excluded unless `includeResolved`: the operator has
-   * already decided about it, and leaving it on the live queue would re-serve
-   * a closed decision on every walk.
+   * Page pending Tempo-channel drains by (created_at, credit_id, drain_id), optionally
+   * age-bounded, excluding written-off rows. Accept the legacy mpp stored method as well as
+   * tempo so pre-migration drains remain repairable. Use the compound key for both ordering
+   * and continuation.
    */
   async listChannelDrains(args) {
     const params = [args.createdBeforeMs, args.limit];
@@ -3495,11 +3148,9 @@ var CreditLedger = class {
     });
   }
   /**
-   * Append a countersigned reclaim-event receipt to the drain's evidence
-   * trail. A single-statement JSONB append — receipts are emitted after the
-   * state transition they attest, and losing one never loses money (the
-   * transition is the source of truth; the receipt is the proof the caller
-   * can carry away).
+   * Append an opaque supplied receipt observation to the drain’s JSONB evidence array.
+   * Issuance and authentication belong to callers/consumers; this store does not verify
+   * signatures. Preserve append order on replay/poll reads.
    */
   async appendDrainReceipt(args) {
     const q = args.tx ?? this.pool;
@@ -3516,7 +3167,6 @@ var CreditLedger = class {
     );
     return rows[0];
   }
-  /** Re-read the credit join fields for a freshly-updated drain row. */
   async rejoin(q, row) {
     const { rows } = await q.query(
       `SELECT currency, caller_pubkey, tempo_channel_id, x402_channel_id
@@ -3525,7 +3175,6 @@ var CreditLedger = class {
     );
     return drainRecordFromRow(row, rows[0]);
   }
-  /** Shared refusal tail for the CAS transitions: idempotent replay or typed error. */
   async refuseTransition(q, creditId, drainId, opts) {
     const row = await this.readDrain(q, creditId, drainId);
     if (!row) {
@@ -3541,26 +3190,10 @@ var CreditLedger = class {
     );
   }
   /**
-   * Price a reclaim in kind and say which lots it takes.
-   *
-   * The debits are returned whether or not the reclaim can be priced, and the
-   * caller applies them either way: the money is leaving the credit, so the
-   * lots have to shrink with it or the deposit-liability rollup would keep
-   * counting a balance that is gone.
-   *
-   * `owedSats` is `null` where {@link isInKindDepletion} refuses — the lots
-   * are short of the balance, or the covering lots carry no sats basis (a
-   * legacy credit whose funding recorded no sats basis. That row is priced off a live rate by the
-   * admin surface instead, which is what *every* row did before this change,
-   * so the fallback is the old behaviour rather than a new failure mode.
-   *
-   * What it publishes is **net of the delivery reserve**: handing a
-   * refund over costs a mint fee and, when the notes have to be minted just in
-   * time, a Lightning hop. The caller carries that cost per and a
-   * flat reserve is how they carry it without the figure moving — an
-   * actual-fee true-up could only be applied after the promise was made. The
-   * debits stay gross because they are denominated in micro and are what
-   * `releaseDrain` restores; only the sats figure is netted.
+   * Deplete FIFO lots even when they cannot price the reclaim; stale open lots must not
+   * remain behind a debited balance. Publish owedSats only with complete positive sats
+   * coverage, net of one delivery reserve. Otherwise preserve null for a live-rate fallback.
+   * Returned debits allow an unpaid drain release to restore the exact lots.
    */
   async reclaimInKind(q, creditId, amountMicro) {
     const depletion = depleteLots(await this.openLots(q, creditId), amountMicro);
@@ -3605,7 +3238,6 @@ var CreditLedger = class {
       );
     }
   }
-  /** Shared settle/release state machine — see the public JSDoc on each verb. */
   async resolveDraw(args) {
     if (args.tx) {
       const credit = await this.lockCreditRow(args.tx, args.creditId);
@@ -3715,7 +3347,6 @@ var CreditLedger = class {
       client.release();
     }
   }
-  /** `SELECT … FOR UPDATE` the credit row on `q` (which must be inside a transaction). */
   async lockCreditRow(q, creditId) {
     const { rows } = await q.query(
       `SELECT * FROM credits WHERE credit_id = $1 FOR UPDATE`,