@dvmkit/sdk 0.1.5-rc.9 → 0.2.1-rc.9

package/dist/{chunk-MLRCSJYX.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 () => {
@@ -208,7 +207,7 @@ var PostgresX402ChannelStorage = class {
    *
    * Both accessors run on the settlement pool: every caller reads or writes the
    * marker while {@link withFleetSettlementLock} holds a host-pool client, which
-   * is the nesting the internal-review split exists to keep off a non-terminal pool.
+   * is the nesting the split exists to keep off a non-terminal pool.
    */
   async isSettlePending(scope) {
     const reader = await this.settlementWriter();
@@ -235,9 +234,9 @@ var PostgresX402ChannelStorage = class {
    *
    * On the dedicated settlement pool like every other marker, and for a sharper
    * reason than they had: this and {@link prepareSettlement} now run *inside*
-   * the channel transaction (internal-review), which holds a host-pool client for its
+   * the channel transaction, which holds a host-pool client for its
    * whole duration. Taking a second client from that same pool is the
-   * self-deadlock internal-review fixed — at pool max every client is a holder and a
+   * self-deadlock fixed — at pool max every client is a holder and a
    * waiter — and moving these calls under the transaction is exactly what would
    * reintroduce it.
    */
@@ -250,7 +249,7 @@ var PostgresX402ChannelStorage = class {
   }
   /**
    * The refund on this channel that is neither finished nor abandoned, if there
-   * is one — the credit ledger's spend gate (internal-review).
+   * is one — the credit ledger's spend gate.
    *
    * `statuses` is the caller's, because the two gates disagree by design: a
    * draw is blocked by {@link X402_SPEND_BLOCKING_SETTLEMENT_STATUSES}, a fresh
@@ -258,12 +257,12 @@ var PostgresX402ChannelStorage = class {
    *
    * On the dedicated settlement pool, and that is what makes the gate callable
    * at all: a draw routinely runs inside an open channel transaction holding a
-   * host-pool client, and taking a second one from that pool is the internal-review
+   * host-pool client, and taking a second one from that pool is the
    * self-deadlock. The oldest blocking row wins, so a channel that somehow
    * accumulated two names the one an operator should reach for first.
    *
    * Projects three columns rather than decoding a whole {@link
-   * X402SettlementIntent}: the decoder refuses a pre-internal-review row that carries
+   * X402SettlementIntent}: the decoder refuses a legacy row that carries
    * no reconciliation snapshot, and a gate that throws on one would take every
    * draw on that channel down with it — when the row is exactly the kind that
    * ought to block them.
@@ -282,7 +281,7 @@ var PostgresX402ChannelStorage = class {
   }
   /**
    * Read one settlement by its own identifier — the handle an operator holds
-   * (internal-review). Same dedicated pool as {@link getSettlement}, for the same
+   * Same dedicated pool as {@link getSettlement}, for the same
    * reason: the repair reads this while a channel transaction may be open.
    */
   async getSettlementById(settlementId) {
@@ -308,7 +307,7 @@ var PostgresX402ChannelStorage = class {
   }
   /**
    * The operator's repair queue: settlements stuck between "chain paid" and
-   * "ledger booked", oldest write first (internal-review).
+   * "ledger booked", oldest write first.
    *
    * Keyset-paginated on `(created_at, settlement_id)` for the reason the
    * blocked-invoice queue is: a wedged row never self-clears, so a fixed first
@@ -350,7 +349,7 @@ var PostgresX402ChannelStorage = class {
     };
   }
   /**
-   * Close a wedged settlement without booking anything (internal-review).
+   * Close a wedged settlement without booking anything.
    *
    * A single-statement CAS on the wedged statuses, on the settlement pool —
    * there is no ledger effect to be atomic with, which is the whole point:
@@ -460,7 +459,7 @@ var PostgresX402ChannelStorage = class {
    * Mark that the next operation is the ambiguous external-call boundary.
    *
    * `channelAtSubmission` is the live channel the facilitator is about to size
-   * and sign the settlement against (internal-review) — bookmarked here, with the
+   * and sign the settlement against — bookmarked here, with the
    * block height, because these two are the only description of that instant
    * that survives the call.
    */
@@ -521,7 +520,7 @@ var PostgresX402ChannelStorage = class {
   /**
    * Mark the external settlement and ledger effect complete in the active transaction.
    *
-   * `resolvedAtMs` is set only by the operator repair (internal-review), so an audit
+   * `resolvedAtMs` is set only by the operator repair, so an audit
    * read can tell a settlement that completed on its own from one a human had
    * to finish.
    */
@@ -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(
@@ -591,7 +589,7 @@ var PostgresX402ChannelStorage = class {
    * this is how the settlement layer says "this exact decrease is the one the
    * payer's verified refund voucher authorises". Outside this scope a decrease
    * of `chargedCumulativeAmount` is refused flat, which is what keeps the
-   * arbitrary-decrease guard meaningful (internal-review).
+   * arbitrary-decrease guard meaningful.
    */
   withSanctionedRefundBase(base, operation) {
     return this.refundBase.run(base, operation);
@@ -617,7 +615,7 @@ var PostgresX402ChannelStorage = class {
    * The lock is session-scoped, so its client stays checked out for the whole
    * operation — and `operation()` (upstream's claim/settle) re-enters the pool
    * through {@link updateChannel}. Two bounds keep that from wedging the pool
-   * (internal-review): local callers are serialized in-process, so this holds at most
+   * local callers are serialized in-process, so this holds at most
    * one client per process no matter how many requests arrive, and a waiting
    * acquire carries a `lock_timeout` so a wedged fleet-mate can't pin that
    * client — and the caller's request — indefinitely. A timeout reports the
@@ -640,7 +638,7 @@ var PostgresX402ChannelStorage = class {
     }
   }
   /**
-   * Hold the fleet-wide self-relay submission lock for one chain submission (internal-review).
+   * Hold the fleet-wide self-relay submission lock for one chain submission.
    *
    * The session lock keeps one per-DVM gas EOA to one in-flight submission
    * across the whole fleet — two machines submitting at once collide on the
@@ -997,46 +995,29 @@ var CreditLedger = class {
   tempoSessionStore;
   /**
    * Postgres-backed: balances survive a restart and are shared across the
-   * fleet, so this DVM may advertise credit (internal-review).
+   * fleet, so this DVM may advertise credit.
    */
   durable = true;
   x402Settlements;
   expiryReleaseOutbox;
   /**
-   * Bind the durable x402 settlement state this ledger gates spending on
-   * (internal-review).
-   *
-   * 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 (internal-review).
-   *
-   * 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} (internal-review). */
   async createTables() {
     await this.pool.query(`
       CREATE TABLE IF NOT EXISTS credits (
@@ -1314,25 +1295,11 @@ var CreditLedger = class {
     );
   }
   /**
-   * Give every open non-channel Bitcoin credit a funding lot (internal-review).
-   *
-   * 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
-   * internal-review. 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 (internal-review) — 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(
@@ -1368,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 (spec §5 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 internal-review
-   * 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
-   * (internal-review), and reverses any standing expiry release (internal-review) — 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 (internal-review) 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** (internal-review), 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 (internal-review). 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 (internal-review) — 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 });
@@ -1449,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,
@@ -1591,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 (internal-review — 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` (spec §5 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(
@@ -1642,37 +1542,15 @@ var CreditLedger = class {
     return restored[0];
   }
   /**
-   * Release the undrawn remainder of every credit whose TTL has run out
-   * (internal-review). 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 (internal-review) 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();
@@ -1708,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);
@@ -1779,34 +1639,12 @@ var CreditLedger = class {
     return row;
   }
   /**
-   * Record this funding's in-kind basis as a lot (internal-review).
-   *
-   * 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;
@@ -1827,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 (spec §5: 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 internal-review 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 });
@@ -1961,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 (internal-review).
-   *
-   * `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 internal-review, 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` (internal-review) — 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 (internal-review).
-   *
-   * **`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
-   * (internal-review)**, 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 });
@@ -2204,7 +1990,7 @@ var CreditLedger = class {
   }
   /**
    * Release a pending draw: the hold evaporates, the balance is untouched —
-   * this is how "no debit on job failure" is mechanically real (spec §1).
+   * this is how "no debit on job failure" is mechanically real (the credit lifecycle contract).
    * Idempotent: releasing a released draw returns the original tuple. A
    * settled draw cannot be released (`invalid_draw_state`) — un-settling
    * booked revenue is a reconciliation problem, not a ledger verb.
@@ -2213,18 +1999,9 @@ var CreditLedger = class {
     return this.resolveDraw({ ...args, to: "released" });
   }
   /**
-   * Record a fund-only top-up under its client-generated `fundId` (internal-review).
-   * 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 (spec §2 condition 3). 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 });
@@ -2295,7 +2072,7 @@ var CreditLedger = class {
     return rows[0].receipt;
   }
   /**
-   * Record the bolt11 issued for a `(creditId, fundId)` top-up (internal-review), or
+   * Record the bolt11 issued for a `(creditId, fundId)` top-up, or
    * return the one already issued for it.
    *
    * **Returning the existing row is the point.** A caller re-polling an unpaid
@@ -2349,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`,
@@ -2374,22 +2150,10 @@ var CreditLedger = class {
     return rows.map(invoiceRecordFromRow);
   }
   /**
-   * Apply an observed Lightning settlement to the ledger — **the exactly-once
-   * boundary** (internal-review; spec §2 condition 3 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);
@@ -2483,19 +2247,9 @@ var CreditLedger = class {
     return this.getInvoice(args);
   }
   /**
-   * Retire an invoice that **was paid** and can never be credited (internal-review).
-   *
-   * 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(
@@ -2505,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`,
@@ -2514,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 (internal-review).
-   *
-   * **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 internal-review shape one page up.
-   *
-   * `includeResolved` widens to the operator-resolved statuses so a run can be
-   * audited after the fact — the acceptance criterion this verb exists for.
-   * 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"];
@@ -2546,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 (internal-review).
-   *
-   * 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);
@@ -2676,17 +2399,9 @@ var CreditLedger = class {
     }
   }
   /**
-   * Record that an operator reviewed a blocked invoice and chose not to credit
-   * it (internal-review) — 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(
@@ -2720,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`,
@@ -2736,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`,
@@ -2746,7 +2459,7 @@ var CreditLedger = class {
   }
   /**
    * All pending holds on a credit, in `ledger_seq` order (no lock). Read
-   * surface for the internal-review sweeper wiring — a worker that dies mid-job
+   * surface for the sweeper wiring — a worker that dies mid-job
    * leaves its hold `pending` until something releases it.
    */
   async listPendingDraws(creditId) {
@@ -2757,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 (internal-review): 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;
@@ -2794,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 (internal-review): 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(
@@ -2828,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 (internal-review).
-   *
-   * 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(
@@ -2844,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();
@@ -2910,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 });
   }
@@ -3004,33 +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 });
   }
-  // ── Drains (internal-review) ─────────────────────────────────────────────────
   /**
-   * Debit the caller's entire available balance into a drain liability
-   * (spec §5: 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();
@@ -3140,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
@@ -3151,7 +2816,7 @@ var CreditLedger = class {
     return rows.length > 0 ? drainRecordFromJoinRow(rows[0]) : void 0;
   }
   /**
-   * One credit's undepleted funding lots, oldest first (internal-review) — the
+   * One credit's undepleted funding lots, oldest first — the
    * public read behind the reclaim's own arithmetic, for anything that needs
    * to show its work.
    */
@@ -3159,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 (internal-review) — 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(
@@ -3205,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;
@@ -3235,6 +2908,8 @@ var CreditLedger = class {
     }
     liability.byRail = [...byRail.values()];
     liability.byCurrency = [...byCurrency.values()];
+    liability.uncoveredByCurrency = [...uncoveredByCurrency.values()];
+    liability.unbackedByCurrency = [...unbackedByCurrency.values()];
     return liability;
   }
   /**
@@ -3254,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 (internal-review).
-   *
-   * 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 pre-internal-review `'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 internal-review's rename sweep and
-   * internal-review's 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];
@@ -3307,7 +2958,7 @@ var CreditLedger = class {
   }
   /**
    * Record that an operator reviewed a floor-refused channel drain and is not
-   * booking it (internal-review). Books nothing anywhere — no status change, no
+   * booking it. Books nothing anywhere — no status change, no
    * balance movement, no platform report.
    *
    * A single-statement CAS on `written_off_at IS NULL`, so the first note on
@@ -3450,7 +3101,7 @@ var CreditLedger = class {
    * loss, so the caller's re-poll keeps returning the same token either way.
    *
    * Returns `replayed` because this is a **terminal** transition and the money
-   * has left at exactly one of these calls (internal-review): the platform drain
+   * has left at exactly one of these calls: the platform drain
    * report must be emitted by that caller and no other. Pass `tx` to write the
    * report through the same transaction as the CAS.
    */
@@ -3497,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;
@@ -3511,7 +3160,6 @@ var CreditLedger = class {
       [args.creditId, args.drainId, JSON.stringify([args.receipt])]
     );
   }
-  // ── Internals ─────────────────────────────────────────────────────────
   async readDrain(q, creditId, drainId) {
     const { rows } = await q.query(
       `SELECT * FROM credit_drains WHERE credit_id = $1 AND drain_id = $2`,
@@ -3519,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
@@ -3528,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) {
@@ -3544,26 +3190,10 @@ var CreditLedger = class {
     );
   }
   /**
-   * Price a reclaim in kind and say which lots it takes (internal-review).
-   *
-   * 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
-   * credit funded before internal-review). 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** (internal-review): 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 internal-review, 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);
@@ -3575,7 +3205,7 @@ var CreditLedger = class {
     };
   }
   /**
-   * This credit's undepleted funding lots, oldest first (internal-review).
+   * This credit's undepleted funding lots, oldest first.
    *
    * Ordered in SQL on the same `(created_at, lot_id)` key the partial index
    * carries, so FIFO is the index's own order rather than something a reader
@@ -3608,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);
@@ -3718,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`,
@@ -3739,7 +3367,7 @@ var CreditLedger = class {
   /**
    * Held-but-unresolved totals for a credit, in all three units at once — the
    * fiat micro that defines available balance plus the rail-value remainders
-   * a new draw allocates against (internal-review). One round-trip, since every
+   * a new draw allocates against. One round-trip, since every
    * caller needs the micro sum anyway.
    */
   async pendingSums(q, creditId) {
@@ -3814,7 +3442,7 @@ function isFundingRail(rail) {
 }
 function assertFundingBasis(basis) {
   if (!basis) {
-    throw new CreditLedgerError("invalid_basis", "basis is required (internal-review)");
+    throw new CreditLedgerError("invalid_basis", "basis is required");
   }
   if (!isFundingRail(basis.rail)) {
     throw new CreditLedgerError(