@arkade-os/swap 0.0.6 → 0.0.8

package/dist/index.d.ts

@@ -1,9 +1,186 @@
-import { asset, IWallet, arkade, RestIndexerProvider, Transaction, IContractManager, RestArkProvider, VHTLC, Identity, ActivityResolver } from '@arkade-os/sdk';
-import { A as AssetSwapRepository, a as AssetSwap, M as MarketsCacheEntry } from './repository-BwnZ8N62.js';
-export { b as AssetSwapStatus, B as BTC_ASSET_ID, I as InMemoryAssetSwapRepository, P as PreimageBlockedReason, c as PreimageNotRecoverableError, S as SwapSecretsProjection, d as addAssetSwap, g as getAssetSwaps, e as getAssetSwapsOrThrow, p as preimageForSwapRecord, s as swapSecretsToRecord, u as updateAssetSwap, f as updateAssetSwapBestEffort } from './repository-BwnZ8N62.js';
+import { ProvisionedKey, ProvisionedClaimSecret, asset, IWallet, arkade, RestIndexerProvider, Transaction, IContractManager, VHTLC, Identity, ActivityResolver } from '@arkade-os/sdk';
+import { S as SwapSecretsProjection, R as RfqSwapRecord, A as AssetSwapRepository, a as AssetSwap, M as MarketsCacheEntry, b as RefundArkProvider, c as RefundIndexer, L as LockupVtxo, d as RfqSwap, e as ArkadeRefundResult, f as LockupSpendIndexer, g as RfqSwapState } from './repository-BcZ9LXRP.js';
+export { h as AssetSwapStatus, i as AvailableRfqSwapManagerCallbacks, B as BTC_ASSET_ID, I as InMemoryAssetSwapRepository, j as LightningReceiveSwap, k as LightningSendSwap, l as LockupFate, m as LockupNeedsRecoveryError, n as LockupParams, o as LockupSpend, O as OnchainSendAction, p as OnchainSendSwap, P as PersistableRfqSwap, q as PreimageBlockedReason, r as PreimageNotRecoverableError, s as REFUND_MTP_LAG_SECONDS, t as RFQ_RESOLVED_STATES, u as RFQ_SWAP_RETENTION_SECONDS, v as RFQ_SWAP_TERMINAL_STATES, w as RefundOutcome, x as RfqRestoreFailure, y as RfqRestoreOptions, z as RfqRestoreResult, C as RfqSwapActionName, D as RfqSwapLockup, E as RfqSwapManager, F as RfqSwapManagerCallbacks, G as RfqSwapManagerConfig, H as RfqSwapManagerDeps, J as RfqSwapManagerEvents, K as RfqSwapOrigin, N as RfqSwapOriginRequired, Q as RfqSwapOutcome, T as RfqSwapRecordStore, U as SwapContractRegistry, V as addAssetSwap, W as awaitRfqResolution, X as createRfqSwapRecord, Y as findLockupVtxos, Z as getAssetSwaps, _ as getAssetSwapsOrThrow, $ as isRfqSwapTerminal, a0 as isRfqTerminal, a1 as nextOnchainAction, a2 as preimageForSwapRecord, a3 as pushRefundWithoutReceiver, a4 as readLockupFate, a5 as rebuildRfqSwap, a6 as refundIfUnresolved, a7 as rfqSwapOriginOf, a8 as shouldRetainRfqSwap, a9 as swapSecretsToRecord, aa as updateAssetSwap, ab as updateAssetSwapBestEffort, ac as updateRfqSwapRecord } from './repository-BcZ9LXRP.js';
 import { Network, LocalCardInput, DiscoveredMarket, Side, OfferPlan } from '@arkade-os/solver-discovery';
-import { R as RfqStatus, a as RfqTransport, O as OnchainHtlc, C as ChainSource, b as ChainUtxo, c as OnchainHtlcPhase } from './rfq-3jWha5xA.js';
-export { A as ARKADE_ASSET, d as ARKADE_BTC, e as AddressMismatch, H as HtlcUtxo, I as InvoiceFacts, L as LIGHTNING_BTC, f as LIGHTNING_RECEIVE_PAIR, g as LIGHTNING_SEND_PAIR, M as MAX_MIN_CONFIRMATIONS, h as MIN_CLAIM_WINDOW_SECONDS, i as MIN_HEADROOM_SECONDS, j as ONCHAIN_BTC, k as ONCHAIN_CLAIM_MARGIN_SECONDS, l as ONCHAIN_DUST_SATS, m as ONCHAIN_ORDER_MARGIN_SECONDS, n as ONCHAIN_RECEIVE_PAIR, o as ONCHAIN_SECONDS_PER_BLOCK, p as ONCHAIN_SEND_PAIR, q as OnchainHtlcParams, r as OnchainNetwork, s as RFQ_TERMINAL_STATES, t as RelaySocket, u as RfqQuote, v as RfqRefusalReason, S as SOLO_REFUND_HEADROOM_SECONDS, w as SwapRefusal, x as arkadeSwapRequest, y as assertFundable, z as assertReceivable, B as awaitOnchainFill, D as buildHtlcClaim, E as buildHtlcRefund, F as claimOnchainFill, G as classifyOnchainHtlc, J as deriveLightningReceive, K as deriveOnchainReceive, N as deriveOnchainSend, P as extractPreimage, Q as httpTransport, T as lightningReceiveRequest, U as lightningSendRequest, V as lightningSendVtxoScript, W as newPreimage, X as newRfqId, Y as offerTermsFromQuote, Z as onchainHtlcScript, _ as onchainReceiveRequest, $ as onchainSendRequest, a0 as paymentHashOf, a1 as receiveVtxoScript, a2 as relayTransport, a3 as requestLightningReceive, a4 as requestLightningSend, a5 as requestOnchainReceive, a6 as requestOnchainSend, a7 as rfqPair, a8 as unilateralClaimDelay, a9 as unilateralRefundDelay, aa as unilateralRefundWithoutReceiverDelay, ab as verifyLockupAddress, ac as verifyReceiveInvoice } from './rfq-3jWha5xA.js';
+import { O as OnchainNetwork, a as OnchainHtlc, b as OnchainHtlcParams } from './rfq-C-aq5LDJ.js';
+export { A as ARKADE_ASSET, c as ARKADE_BTC, d as AddressMismatch, C as ChainSource, e as ChainUtxo, H as HtlcUtxo, I as InvoiceFacts, L as LIGHTNING_BTC, f as LIGHTNING_RECEIVE_PAIR, g as LIGHTNING_SEND_PAIR, h as LightningReceiveTreeParams, i as LightningSendTreeParams, M as MAX_MIN_CONFIRMATIONS, j as MIN_CLAIM_WINDOW_SECONDS, k as MIN_HEADROOM_SECONDS, l as ONCHAIN_BTC, m as ONCHAIN_CLAIM_MARGIN_SECONDS, n as ONCHAIN_DUST_SATS, o as ONCHAIN_ORDER_MARGIN_SECONDS, p as ONCHAIN_RECEIVE_PAIR, q as ONCHAIN_SECONDS_PER_BLOCK, r as ONCHAIN_SEND_PAIR, s as OnchainHtlcPhase, R as RFQ_TERMINAL_STATES, t as RelaySocket, u as RfqQuote, v as RfqRefusalReason, w as RfqStatus, x as RfqTransport, S as SOLO_REFUND_HEADROOM_SECONDS, y as SwapRefusal, z as arkadeAssetLeg, B as arkadeSwapRequest, D as assertFundable, E as assertReceivable, F as awaitOnchainFill, G as buildHtlcClaim, J as buildHtlcRefund, K as claimOnchainFill, N as classifyOnchainHtlc, P as deriveLightningReceive, Q as deriveOnchainReceive, T as deriveOnchainSend, U as extractPreimage, V as httpTransport, W as lightningReceiveRequest, X as lightningSendRequest, Y as lightningSendVtxoScript, Z as newPreimage, _ as newRfqId, $ as offerTermsFromQuote, a0 as onchainHtlcScript, a1 as onchainReceiveRequest, a2 as onchainSendRequest, a3 as paymentHashOf, a4 as receiveVtxoScript, a5 as relayTransport, a6 as requestLightningReceive, a7 as requestLightningSend, a8 as requestOnchainReceive, a9 as requestOnchainSend, aa as rfqPair, ab as unilateralClaimDelay, ac as unilateralRefundDelay, ad as unilateralRefundWithoutReceiverDelay, ae as verifyLockupAddress, af as verifyReceiveInvoice } from './rfq-C-aq5LDJ.js';
+
+/**
+ * Which wallet key signs this leg. Stored at `profile.signer`.
+ *
+ * Independent of any hashlock: it feeds `senderIdentityForSwapRecord` on the
+ * refund side, and a corridor that settles with no preimage at all still needs
+ * it. A corridor whose leg this wallet never signs omits the key entirely — as
+ * with everything else here, absent rather than blank.
+ */
+interface RfqSignerProjection {
+    /** Public. The wallet re-derives the signer from it; no key material is at
+     * rest. */
+    signingDescriptor: string;
+}
+/**
+ * What a leg locked to a preimage records about the LOCK. Stored at
+ * `profile.hashlock`, and absent entirely from a corridor that has none.
+ *
+ * `paymentHash` is identity, not capability — `lightning_send` carries one and
+ * can never open it. The preimage fields are the capability, and only a corridor
+ * where WE claim ever writes them: `provisionClaimSecret` produces that arm,
+ * `provisionRefundKey` does not.
+ */
+type RfqHashlockProjection = Omit<SwapSecretsProjection, "signingDescriptor"> & {
+    /** `sha256(P)`, hex. Not recoverable from the covenant, which binds
+     * `hash160(P)`. */
+    paymentHash: string;
+};
+/**
+ * The composed view `preimageForSwapRecord` reads — the signer's descriptor plus
+ * the hashlock's. **Never a stored shape**: nothing writes this object,
+ * {@link rfqClaimSecretOf} assembles it from the two keys above, which is what
+ * keeps the descriptor stored once.
+ *
+ * Structurally `SwapSecretsProjection & { paymentHash }`, which is exactly that
+ * helper's parameter.
+ */
+type RfqClaimSecretProjection = RfqSignerProjection & RfqHashlockProjection;
+/**
+ * The corridor-owned counterpart of `onchainSendProfile`: the one supported way
+ * to turn a provisioned secret into stored profile keys.
+ *
+ * Writes what the provisioning result actually has. Omit `paymentHash` and you
+ * get `signer` alone — which is what a non-hashlock corridor calls, and why it
+ * never has to reach for `hashlock`.
+ */
+declare const rfqSecretsProfile: (secrets: ProvisionedKey | ProvisionedClaimSecret, paymentHash?: string) => {
+    signer: RfqSignerProjection;
+    hashlock?: RfqHashlockProjection;
+};
+/**
+ * The stored signer projection, for `senderIdentityForSwapRecord`.
+ *
+ * `undefined` ONLY when the profile carries no `signer` key — a corridor whose
+ * leg this wallet does not sign. A `signer` that is present and unusable throws:
+ * "this corridor has no local signer" and "this record came back corrupt" are
+ * different answers, and `senderIdentityForSwapRecord` turns the first into a
+ * permanent `RefundNotLocallyPossibleError("no-secrets")` the manager acts on.
+ * Handing it a silently-emptied projection would report "no local refund is
+ * possible" for a storage bug.
+ */
+declare const rfqSignerOf: (record: RfqSwapRecord) => RfqSignerProjection | undefined;
+/**
+ * The claim inputs, or `undefined` when this record's corridor cannot produce P
+ * — no hashlock, or a leg we refund rather than claim.
+ *
+ * Answered by the corridor's handler (`claimSecret`), not by a kind list here:
+ * whether a leg claims is the corridor's fact.
+ *
+ * When the handler DOES claim, this validates and throws
+ * `PreimageNotRecoverableError("malformed-record")` rather than returning a
+ * partial projection — which `preimageForSwapRecord` would claim with, its hash
+ * check being conditional on the very field that went missing.
+ */
+declare const rfqClaimSecretOf: (record: RfqSwapRecord) => RfqClaimSecretProjection | undefined;
+
+/**
+ * `arkade:BTC->lightning:BTC`. Nothing beyond its keys and the covenant: the
+ * solver claims the lockup, the trader's only move is the refund, and the rest
+ * of the leg is fully described by the contract row.
+ *
+ * The one leg with a hashlock it can never open — P belongs to the payee — so
+ * `hashlock` here is `{ paymentHash }` alone and `signer` holds a REFUND key.
+ */
+interface LightningSendProfile extends Record<string, unknown> {
+    signer: RfqSignerProjection;
+    hashlock: RfqHashlockProjection;
+}
+/** `lightning:BTC->arkade:BTC`. */
+interface LightningReceiveProfile extends Record<string, unknown> {
+    signer: RfqSignerProjection;
+    hashlock: RfqHashlockProjection;
+    /** The quote's `to_amount`, captured at REQUEST time. */
+    expectedAmount: number;
+    /** Where the claim pays. */
+    payoutAddress: string;
+    /**
+     * Our Arkade claim's txid, once submitted.
+     *
+     * Here rather than on the record's common half, which is for fields all
+     * three legs carry: this one is the receive leg's alone, the counterpart of
+     * the onchain leg's `claimTxid`. Restoring without it re-arms the value gate
+     * against a lockup we have already partly claimed — `claimIfFunded` reads
+     * `partiallyClaimed` off exactly this — so the remainder is refused over a
+     * preimage that is already public, and a swap that did claim is relabelled
+     * `needs_counterparty` once its window shuts.
+     */
+    claimArkTxid?: string;
+}
+/** `arkade:BTC->onchain:BTC`. */
+interface OnchainSendProfile extends Record<string, unknown> {
+    signer: RfqSignerProjection;
+    hashlock: RfqHashlockProjection;
+    /** The trader's L1 claim key. */
+    claimKey: string;
+    /** The solver's L1 key, from `profile.htlc_pubkey`. */
+    refundKey: string;
+    /** `profile.htlc_locktime` — the trader's L1 recourse deadline, distinct
+     * from the arkade lockup's `refundLocktime`. */
+    htlcLocktime: number;
+    network: OnchainNetwork;
+    /**
+     * The L1 address the fill was expected at — `htlc.address` from
+     * `requestOnchainSend`, which `deriveOnchainSend` has already checked
+     * against the quote's own `profile.htlc_address`.
+     *
+     * The counterpart of the record's `lockupAddress`, and here for the same
+     * reason: the inputs above and this address reach the record by independent
+     * routes, so requiring the rebuild to reproduce it is what catches a
+     * parameter that came back wrong. The arkade lockup gets that check from
+     * `rebuildRfqSwap`; this leg, the one whose parameters have no second source
+     * anywhere, would otherwise get none — and a swapped or corrupted key
+     * derives another perfectly valid HTLC, at an address nobody funded.
+     */
+    htlcAddress: string;
+    /** `profile.min_confirmations`; gates when the fill is claimable. */
+    minConfirmations: number;
+    /** The fill's outpoint, learned on first sighting. Without it a SPENT htlc
+     * reads as never funded — see `classifyOnchainHtlc`. */
+    funding?: {
+        txid: string;
+        vout: number;
+    };
+    /** Our own L1 claim, so a restart does not re-broadcast it. */
+    claimTxid?: string;
+}
+/**
+ * Build the profile from what `requestOnchainSend` returned.
+ *
+ * Pass the whole result: every field this needs is on it, so the mapping is
+ * done here, once, instead of at each call site.
+ *
+ * That mapping is the reason this exists. `htlcParams.refundLocktime` becomes
+ * `htlcLocktime` — the same value under a different name, because the record
+ * already has a `refundLocktime` and it is the arkade lockup's, a different
+ * deadline entirely. The keys go from bytes to hex. `htlcAddress` is not an
+ * input to anything, it is the derived value the rebuild checks the inputs
+ * against, so writing it is easy to skip and impossible to reconstruct later.
+ * A caller copying fields across by hand gets all three right or restores a
+ * swap that watches nothing.
+ *
+ * The other two corridors have no such builder, deliberately: their profiles
+ * are the request result's own fields under their own names, with nothing
+ * derived and nothing renamed.
+ *
+ * The L1 half ONLY. `signer` and `hashlock` come from `rfqSecretsProfile`, which
+ * every corridor calls — folding them in here would give this leg a one-call
+ * mapper the other two cannot have, and the uniform rule ("`rfqSecretsProfile`
+ * first, then whatever the corridor adds") is what keeps the per-corridor
+ * instructions short enough to follow.
+ */
+declare function onchainSendProfile(result: {
+    htlc: Pick<OnchainHtlc, "address">;
+    htlcParams: OnchainHtlcParams;
+    l1Network: OnchainNetwork;
+    minConfirmations: number;
+}): Omit<OnchainSendProfile, "signer" | "hashlock">;
 
 /** The contracts — pure data, shared verbatim with any other implementation. */
 declare const swapPrograms: Record<"wantAsset" | "wantBtc", ReturnType<typeof arkade.parseArtifact>>;
@@ -219,18 +396,21 @@ declare const validatePlan: (plan: OfferPlan, giveBalance: bigint, dust: bigint)
 /** Browser backend over the SDK's shared IndexedDB manager — the same
  * infrastructure the wallet already uses for its Boltz swap repository. */
 declare class IndexedDbAssetSwapRepository implements AssetSwapRepository {
-    private readonly dbName;
-    readonly version: 2;
-    private dbPromise;
+    readonly version: 4;
+    private readonly connection;
     constructor(dbName?: string);
     private ensureDb;
     private readStore;
     /** Every write in one place, so none of them can forget to await the
      * commit. Requests need no individual await: a failed one aborts the
-     * transaction, which `txDone` reports. */
+     * transaction, which `awaitTransaction` reports. */
     private write;
     saveSwap(swap: AssetSwap): Promise<void>;
     getAllSwaps(): Promise<AssetSwap[]>;
+    saveRfqSwap(record: RfqSwapRecord): Promise<void>;
+    getRfqSwap(rfqId: string): Promise<RfqSwapRecord | undefined>;
+    getAllRfqSwaps(): Promise<RfqSwapRecord[]>;
+    removeRfqSwap(rfqId: string): Promise<void>;
     getScannedTxids(): Promise<Set<string>>;
     markTxidsScanned(txids: Iterable<string>): Promise<void>;
     getCachedMarkets(network: string, registry: string): Promise<MarketsCacheEntry | undefined>;
@@ -464,386 +644,6 @@ interface ClaimPacketInput {
  */
 declare function sealClaimPacket(input: ClaimPacketInput): Promise<SealedClaimPacket>;
 
-/** True for the states after which the solver will report nothing further. */
-declare const isRfqTerminal: (state: string) => boolean;
-/**
- * The terminal states that mean the swap is OVER and the lockup is already
- * gone — the solver either claimed it (`settled`, revealing the preimage) or
- * returned it (`refunded`). A trader seeing one of these has nothing left to
- * do.
- *
- * Deliberately narrower than {@link RFQ_TERMINAL_STATES}: `refused`, `expired`
- * and `stuck` are terminal for the NEGOTIATION but say nothing about whether
- * the trader's sats are still sitting at the lockup. A trader that funded just
- * as the quote expired, or whose solver wedged mid-payment, is exactly the
- * trader who needs the refund most — so those states must not short-circuit
- * it. {@link refundIfUnresolved} treats them as "keep going", and lets the
- * on-chain VTXO lookup be the authority on whether anything is actually there.
- */
-declare const RFQ_RESOLVED_STATES: readonly ["settled", "refunded"];
-/**
- * Poll a swap's status until it reaches a terminal state.
- *
- * Same shape and conventions as {@link awaitOnchainFill}: a `pollMs` interval,
- * an optional unix-seconds `deadline`, and a thrown error carrying a stable
- * `reason` when that deadline passes.
- *
- * A `null` status (the solver has no record of this `rfq_id`) is treated as
- * "not yet", not as an answer — a status route can legitimately 404 for a
- * moment after a quote is issued. The deadline is what bounds that wait.
- *
- * Transport errors are NOT swallowed; a failing `status()` call rejects this
- * function. Callers polling across a long refund window should expect to
- * restart it after a network blip — nothing is lost by doing so, since the
- * refund path this feeds is gated on an absolute timelock that does not
- * expire.
- */
-declare function awaitRfqResolution(transport: RfqTransport, rfqId: string, options?: {
-    pollMs?: number;
-    deadline?: number;
-}): Promise<RfqStatus>;
-/** The Ark surface the refund push needs — narrower than a full provider, and
- * satisfied by {@link RestArkProvider}. Same seam style as `RestoreIndexer`. */
-type RefundArkProvider = Pick<RestArkProvider, "getInfo" | "submitTx" | "finalizeTx">;
-/** The indexer surface the lockup lookup needs. */
-type RefundIndexer = Pick<RestIndexerProvider, "getVtxos">;
-/** A still-refundable virtual output sitting at the swap lockup. */
-interface LockupVtxo {
-    txid: string;
-    vout: number;
-    value: number;
-    /**
-     * The batch this output lived in expired and the operator swept it, so it
-     * is no longer a live leaf — it can be RECOVERED, but not spent offchain.
-     *
-     * It is still the trader's money and it is still visible, which is why
-     * {@link findLockupVtxos} returns it. What it is not is refundable by
-     * {@link pushRefundWithoutReceiver}: that builds an offchain Ark
-     * transaction, and the SDK's own predicates make the two states mutually
-     * exclusive — `canSpendOffchain` is false exactly when `canRecoverOnchain`
-     * is true (`wallet/vtxo.ts`), and the latter is documented as "must be
-     * recovered into a fresh batch rather than spent offchain". Holding the
-     * trader's `sender` key does not change that; a sweep removes the leaf from
-     * the live tree, not the signature from the trader.
-     *
-     * `packages/boltz-swap` splits on exactly this fact rather than working
-     * around it: `settleRefundWithoutReceiver` sends a live VTXO through an
-     * offchain tx and a recoverable one through `joinBatch` — "a swept
-     * (recoverable) VTXO is no longer a live leaf, so it can only be reclaimed
-     * by re-registering it into a batch".
-     *
-     * So the remedy is recovery (renewing the output into a fresh batch),
-     * after which the ordinary CLTV refund works again. This package does not
-     * build that round — see {@link pushRefundWithoutReceiver}, which refuses
-     * rather than submitting a spend that cannot succeed.
-     */
-    recoverable: boolean;
-}
-/**
- * Thrown when a refund was asked for over outputs that have been swept.
- *
- * Carries the outpoints so a caller can act — recover exactly those, then
- * retry — instead of reading a server rejection and guessing. `reason` follows
- * the same convention as `awaitOnchainFill`'s `fill_timeout` and
- * `claimOnchainFill`'s `claim_window_closed`.
- *
- * **The remedy already exists; this package does not reimplement it.** The SDK
- * recovers swept outputs by re-registering them into a fresh batch, through
- * `IVtxoManager.recoverVtxos()` — the same batch round `packages/boltz-swap`
- * reaches via its own `joinBatch`. It reads the wallet's registered-contract
- * snapshot (`recoverVtxos` → `wallet.getVtxos({ withRecoverable: true })` →
- * `contractSnapshot()` → `contractManager.getContractsWithVtxos()`), so it
- * covers a swap lockup as soon as that lockup is registered as a contract —
- * which is what {@link RfqSwapManagerDeps.contracts} does. Registration is
- * therefore not only a latency optimization; it is what turns a swept lockup
- * from a dead end into something the ordinary wallet path can recover.
- *
- * Two caveats a caller must hold, neither enforceable from here:
- *
- * - **The wallet must hold the lockup's `sender` key**, because recovery
- *   settles through `refundWithoutReceiver` — the leaf `vhtlc-v2` annotates
- *   these VTXOs with.
- * - **`refundLocktime` must have matured.** That leaf carries a CLTV, so a
- *   recovery round including this VTXO earlier is rejected. `recoverVtxos`
- *   sweeps every recoverable output in ONE settlement and has no CLTV
- *   awareness, so recovering early can fail the whole batch rather than just
- *   this output. `packages/boltz-swap` encodes the same rule as "pre-CLTV
- *   recoverable → skipped".
- */
-declare class LockupNeedsRecoveryError extends Error {
-    readonly name = "LockupNeedsRecoveryError";
-    readonly reason = "needs_recovery";
-    /** `txid:vout` for each output that must be recovered first. */
-    readonly outpoints: string[];
-    /**
-     * The contract's `refundLocktime`. Recovering before this matures is the
-     * hazard described above: `recoverVtxos()` sweeps EVERY recoverable output
-     * into one settlement with no CLTV awareness, so an early attempt can fail
-     * the whole batch — including unrelated outputs that were otherwise fine.
-     *
-     * Exposed as a value, not only inside the message, so a caller can encode
-     * `packages/boltz-swap`'s "pre-CLTV recoverable → skipped" rule without
-     * parsing prose. Seconds-based locktimes mature against the chain tip's
-     * timestamp rather than wall clock, so treat this as a floor to wait past,
-     * not an exact alarm.
-     */
-    readonly recoverableAfter: bigint;
-    constructor(outpoints: string[], recoverableAfter: bigint);
-}
-/**
- * Every output still sitting at the lockup script — spendable AND
- * swept-but-recoverable, each tagged with which it is.
- *
- * All of them, not the first: a trader may fund a lockup in more than one
- * send, and refunding only `vtxos[0]` returns part of the money and strands
- * the rest at a script whose other refund paths are all longer.
- *
- * BOTH queries, because they are disjoint sets and `spendableOnly` alone goes
- * blind at exactly the wrong moment. A lockup whose batch expiry passed is
- * swept into the recoverable set, and this function exists to serve swaps that
- * sat unresolved — which are precisely the ones most likely to have got there.
- * Reading only the spendable set would report `nothing_to_refund` over money
- * that is still sitting at the script, which is worse than an error: it looks
- * like a resolved swap. `packages/boltz-swap` merges the same two queries for
- * the same reason (`arkade-swaps.ts`'s `refundableVtxos`).
- *
- * **Visible is not the same as refundable.** A `recoverable` output cannot be
- * spent offchain at all — see {@link LockupVtxo.recoverable} — so this set is
- * "what is there", not "what {@link pushRefundWithoutReceiver} can take back".
- * That function refuses the recoverable ones by name rather than submitting a
- * spend the server must reject.
- *
- * This read — not the RFQ's reported state — is the authority on whether
- * there is anything left at the lockup.
- *
- * **Not replaced by the contract manager's VTXO state, deliberately.** Once a
- * lockup is registered (see `RfqSwapManagerDeps.contracts`) the wallet tracks
- * these same outputs, and `getContractsWithVtxos` plus `canSpendOffchain` /
- * `canRecoverOnchain` would classify them. That is a WEAKER answer here on two
- * counts: it serves the wallet REPOSITORY, which a degraded sync will happily
- * hand back stale (`getSyncState()` reports `degraded` and returns cached rows
- * rather than failing), and its height-based expiry test needs a chain tip this
- * module does not have. The two queries below ask the indexer itself and need
- * neither. Ask-the-indexer, don't-trust-local-state — the same posture
- * {@link readLockupFate} takes, and for the same reason: this decides money.
- */
-declare function findLockupVtxos(indexer: RefundIndexer, swapPkScript: Uint8Array): Promise<LockupVtxo[]>;
-/**
- * The indexer surface the lockup-spend read needs: the vtxo lookup, plus the
- * raw transactions those vtxos were spent by. Same narrow-seam style as
- * {@link RefundIndexer} and `restore.ts`'s `RestoreIndexer`, and satisfied by
- * {@link RestIndexerProvider}.
- */
-type LockupSpendIndexer = Pick<RestIndexerProvider, "getVtxos" | "getVirtualTxs">;
-/**
- * What chain data says became of a swap lockup — the whole answer, with no
- * solver involvement and nothing taken on the solver's word.
- */
-type LockupFate = 
-/** At least one output at the lockup is still unspent. Not over. */
-{
-    fate: "open";
-}
-/** Spent by a witness carrying a preimage that HASHES to the quote's
- * `payment_hash`. Only the claim leaf can reveal one, and the only
- * legitimate way the solver obtains it is by completing its side. */
- | {
-    fate: "claimed";
-    preimage: Uint8Array;
-}
-/** Fully spent, and nothing that spent it revealed a matching preimage —
- * so the money went back to the trader. See {@link readLockupFate}. */
- | {
-    fate: "returned";
-}
-/** Nothing was learned: no outputs visible, an output spent by nothing the
- * indexer names, a spend it could not produce, or a blob that would not
- * decode. Never an answer. */
- | {
-    fate: "unknown";
-};
-/**
- * Decide from chain data alone whether a swap lockup settled, came back, or is
- * still live.
- *
- * **Why this is decidable without asking anyone.** The lockup's claim leaf can
- * only be spent by revealing `P`, so a spend witness carrying a value that
- * hashes to the quote's `payment_hash` is proof the claim leaf was used — and
- * the only legitimate way the counterparty obtains `P` is by completing its
- * side of the swap. Every OTHER leaf is a refund: `nonInteractiveRefund` is
- * covenant-pinned to the trader's own address (`enforcePayTo(senderPkScript)`),
- * and `refund`, `refundWithoutReceiver`, `unilateralRefund` and
- * `unilateralRefundWithoutReceiver` all require the trader's own signature. So
- * "spent, but not by a hash-verified claim" means the money went back to the
- * trader, and nothing here has to trust a counterparty to say so.
- *
- * **A matching witness SHAPE is not proof.** Only a candidate that hashes to
- * `paymentHash` may be read as a claim; a 32-byte item that hashes to anything
- * else is just bytes, and is treated as a refund. Getting this wrong in the
- * permissive direction would report "settled" for a swap that actually
- * refunded, which is precisely the fact a trader is relying on.
- *
- * **`unknown` is not `returned`.** An empty vtxo set (indexer lag, or a lockup
- * not visible yet), a `spentBy` the indexer cannot produce a transaction for,
- * or a blob that will not decode all come back as `unknown`. `getVirtualTxs`
- * may legitimately return fewer transactions than were asked for, so the
- * observed set is counted rather than assumed complete. The caller's correct
- * response to `unknown` is the same as to `open`: keep watching, and let the
- * refund timelock — which no outage can move — be what ends the wait.
- *
- * Ask-the-indexer, don't-trust-local-state: read fresh on every poll, never
- * cached, the same posture {@link findLockupVtxos} already establishes.
- */
-declare function readLockupFate(indexer: LockupSpendIndexer, input: {
-    swapPkScript: Uint8Array;
-    /** `sha256(P)`, hex — the quote's `payment_hash`. */
-    paymentHash: string;
-}): Promise<LockupFate>;
-/**
- * Build, sign, and push the `refundWithoutReceiver` spend: return every funded
- * output at the lockup to the trader's refund address.
- *
- * The leaf is `CLTV(refundLocktime) + <sender> + <server>` — the trader's own
- * VHTLC `sender` key and the Arkade server, and NOBODY else. In particular the
- * emulator is not involved: it co-signs only the two covenant leaves
- * (`nonInteractiveClaim` / `nonInteractiveRefund`), which is why the solver's
- * own escape hatch has to go through it and this one does not. So unlike that
- * push, this transaction is submitted SIGNED, and the only counterparty is the
- * Arkade server doing what it does for any collaborative spend.
- *
- * One aggregate output, not one per input — again unlike the solver's covenant
- * refund, which needs index-aligned outputs because its ArkadeScript inspects
- * the output at the current input's index. This leaf carries no covenant, so a
- * single output paying the whole balance is both valid and cheaper.
- *
- * `refundPkScript` defaults to the destination the contract itself commits to
- * (`nonInteractiveRefund`'s `senderPkScript`, i.e. the address the trader gave
- * at quote time), so the ordinary call cannot send the refund somewhere the
- * trader did not intend. It is overridable because this leaf, having no
- * covenant, genuinely does permit any destination.
- *
- * **Consensus, not wall clock, decides when this is spendable.** A seconds
- * locktime matures against median-time-past, which trails real time by roughly
- * an hour, so a push issued the moment `refundLocktime` passes can be rejected
- * until enough blocks land. That is expected, not a failure — see
- * {@link refundIfUnresolved}, which retries.
- *
- * **Swept outputs are refused, not attempted.** This is an OFFCHAIN spend, and
- * a swept output is no longer a live leaf: `canSpendOffchain` and
- * `canRecoverOnchain` are mutually exclusive by construction, so a recoverable
- * input cannot be spent this way whatever key signs it (see
- * {@link LockupVtxo.recoverable}). Because every input lands in ONE aggregate
- * transaction, a single swept output would take the live ones down with it —
- * so the whole push is refused with {@link LockupNeedsRecoveryError} naming the
- * outpoints, rather than submitted and rejected. Filtering them out silently
- * would be worse still: it would report success over money that never moved.
- */
-declare function pushRefundWithoutReceiver(ark: RefundArkProvider, input: {
-    script: InstanceType<typeof VHTLC.ScriptV2>;
-    /** The `sender` signer. Build it from the swap record with
-     * {@link senderIdentityForSwapRecord} — on an HD wallet that resolves
-     * from the seed, with no stored key bytes anywhere, and every way the
-     * wallet can fail to produce it arrives as one typed
-     * {@link RefundNotLocallyPossibleError} the manager reads as permanent
-     * rather than retrying for the rest of the refund window. */
-    sender: Identity;
-    vtxos: readonly LockupVtxo[];
-    /** Defaults to the contract's own committed refund destination. */
-    refundPkScript?: Uint8Array;
-}): Promise<{
-    arkTxid: string;
-    amount: number;
-}>;
-/**
- * How long past `refundLocktime` to keep retrying the push before giving up
- * and surfacing the server's refusal.
- *
- * Two hours because the CLTV matures against median-time-past (BIP-113), which
- * lags wall clock by about an hour, plus room for a slow block. This is the
- * mirror of `MIN_HEADROOM_SECONDS`, which refuses to FUND without 90 minutes
- * of the same margin.
- */
-declare const REFUND_MTP_LAG_SECONDS: number;
-type RefundOutcome = 
-/** The solver resolved it — claimed (`settled`) or returned it (`refunded`). */
-{
-    outcome: "resolved";
-    status: RfqStatus;
-}
-/** The trader took it back via `refundWithoutReceiver`. */
- | {
-    outcome: "refunded";
-    arkTxid: string;
-    amount: number;
-    status: RfqStatus | null;
-}
-/** The refund window opened but the lockup holds nothing to return. */
- | {
-    outcome: "nothing_to_refund";
-    status: RfqStatus | null;
-}
-/**
- * The money is still at the lockup, but its batch was swept, so no offchain
- * spend can take it back until it is recovered into a fresh batch. Returned
- * rather than retried: unlike a median-time-past refusal, no amount of
- * waiting fixes this — see {@link LockupNeedsRecoveryError}. Recover the
- * named outpoints, then call this again.
- */
- | {
-    outcome: "needs_recovery";
-    outpoints: string[];
-    vtxos: LockupVtxo[];
-    status: RfqStatus | null;
-};
-/**
- * Ask first, then fall back: watch the swap for the solver to resolve it, and
- * if `refundLocktime` matures without that happening, take the lockup back
- * with `refundWithoutReceiver`.
- *
- * This is the whole trader-side failure story in one call. It polls `status()`
- * — the only "asking" this protocol has (see the module doc) — and returns as
- * soon as the solver reports `settled` or `refunded`. Otherwise, once the
- * quote's `refund_locktime` passes, it looks up what is actually at the lockup
- * and pushes the refund.
- *
- * Two behaviours worth knowing:
- *
- * - **A dead negotiation is not a reason to stop.** `refused`, `expired` and
- *   `stuck` are terminal states, but a trader can be holding a funded lockup in
- *   every one of them, so they do not end the wait — only `settled`/`refunded`
- *   do (see {@link RFQ_RESOLVED_STATES}). What ends it otherwise is the
- *   timelock.
- * - **The first push after the deadline may legitimately fail.** Median-time-
- *   past trails wall clock, so the server can still consider the leaf locked
- *   for a while after `refundLocktime` passes in real time. Failures are
- *   retried at the poll interval until `attemptDeadline`, after which the last
- *   error is rethrown rather than swallowed.
- * - **A swept lockup ends the wait instead of consuming it.** Once the batch
- *   is gone the CLTV refund is not "not yet" but "not this way", so it returns
- *   `needs_recovery` naming the outpoints rather than retrying until the
- *   deadline. Recover them and call again.
- *
- * Safe to call late, and safe to call again: a caller recovering from a crash
- * well past the deadline skips straight to the push, and a lockup that is
- * already empty comes back as `nothing_to_refund` instead of an error.
- */
-declare function refundIfUnresolved(transport: RfqTransport, ark: RefundArkProvider, indexer: RefundIndexer, input: {
-    rfqId: string;
-    script: InstanceType<typeof VHTLC.ScriptV2>;
-    /** @see pushRefundWithoutReceiver */
-    sender: Identity;
-    /** `refund_locktime` from the quote, unix seconds. */
-    refundLocktime: number;
-    /** Defaults to the contract's own committed refund destination. */
-    refundPkScript?: Uint8Array;
-    pollMs?: number;
-    /** Stop retrying the push at this unix time, rethrowing the last
-     * error. Defaults to `refundLocktime + REFUND_MTP_LAG_SECONDS`. */
-    attemptDeadline?: number;
-    /** Injected for tests; defaults to wall clock, in unix seconds. */
-    now?: () => number;
-}): Promise<RefundOutcome>;
-
 /** The Ark surface the claim push needs — the same seam the refund push uses. */
 type ClaimArkProvider = RefundArkProvider;
 /**
@@ -991,6 +791,47 @@ declare function senderIdentityForSwapRecord(wallet: IWallet, record: {
     signingDescriptor?: string;
 }): Promise<Identity>;
 
+/**
+ * The `refundArkade` callback, assembled.
+ *
+ * The wiring this replaces was prose in two places — `swapManager.ts`'s
+ * callback doc and the README — because it is the one callback whose obvious
+ * implementation is wrong: `refundIfUnresolved` is the single-swap version of
+ * `RfqSwapManager` itself and brings its own status polling and MTP retry loop,
+ * which would nest inside the manager's. Composing the atomic push here makes
+ * that mistake something a consumer has to go out of their way to make.
+ *
+ * The three semantic rules the manager relies on are structural rather than
+ * documented: an empty lockup returns `null`, and both
+ * {@link RefundNotLocallyPossibleError} and {@link LockupNeedsRecoveryError}
+ * propagate untouched — the manager reads the first as permanent and surfaces
+ * the second as `needs_recovery`, and catching either here would turn a state
+ * the trader must act on into a retry that grinds the window away.
+ */
+
+interface ArkadeRefunderDeps {
+    ark: RefundArkProvider;
+    indexer: RefundIndexer;
+    /** Asked for the descriptor's signer; never asked to mint a key. */
+    wallet: IWallet;
+    /**
+     * The record store. The live `RfqSwap` the manager passes carries no
+     * `signingDescriptor` — that lives in the record's `profile.signer` — so
+     * the refund key is resolved by key, which is what `getRfqSwap` is for.
+     */
+    repository: Pick<AssetSwapRepository, "getRfqSwap">;
+}
+/**
+ * Build the `refundArkade` callback for `RfqSwapManager.setCallbacks`.
+ *
+ * @example
+ * manager.setCallbacks({
+ *     refundArkade: arkadeRefunder({ ark, indexer, wallet, repository }),
+ *     saveSwap,
+ * });
+ */
+declare function arkadeRefunder(deps: ArkadeRefunderDeps): (swap: RfqSwap) => Promise<ArkadeRefundResult>;
+
 /** The contract type a swap lockup registers under. `@arkade-os/sdk`'s handler
  * for `VHTLC.ScriptV2` — the covenant script this corridor builds. */
 declare const SWAP_LOCKUP_CONTRACT_TYPE = "vhtlc-v2";
@@ -1000,6 +841,25 @@ declare const SWAP_LOCKUP_CONTRACT_KIND = "rfq-swap-lockup";
  * injection style as `SwapContractRegistry`, and satisfied by a real
  * `ContractManager` (`await wallet.getContractManager()`). */
 type LockupContractWriter = Pick<IContractManager, "createContract">;
+/** The read seam {@link lockupContractParams} needs. Same narrowing, same
+ * `ContractManager` satisfies it. */
+type LockupContractReader = Pick<IContractManager, "getContracts">;
+/**
+ * No row for a lockup a record claims was funded.
+ *
+ * Separate from a rebuild failure on purpose: the record is fine and its money
+ * may well be at the address — what is missing is the wallet's copy of the
+ * covenant, which registration writes before the address can be funded. So this
+ * means the contract store was cleared or was never the one that registered
+ * this swap, and the remedy is a store, not a re-quote.
+ */
+declare class LockupContractMissing extends Error {
+    /** The lockup whose row is absent. */
+    readonly address: string;
+    /** Its pkScript hex — the key the row would have been under. */
+    readonly script: string;
+    constructor(address: string, script: string);
+}
 /**
  * The lockup could not be written locally.
  *
@@ -1040,769 +900,35 @@ declare class LockupRegistrationFailed extends Error {
  * storage problem from a reason to walk away from the quote.
  */
 declare function registerLockupContract(contracts: LockupContractWriter, script: InstanceType<typeof VHTLC.ScriptV2>, address: string): Promise<void>;
-
 /**
- * Where a monitored swap stands.
+ * The stored covenant parameters of a funded lockup — the other half of
+ * `rebuildRfqSwap`.
  *
- * `claimable` and `claimed` are the states of a swap the TRADER has something
- * to claim on: the L1 fill on an onchain send, and the solver-funded lockup on
- * a receive. Only `lightning_send` has neither — there the solver claims the
- * lockup, and the trader's only move is the refund.
- */
-type RfqSwapState = 
-/** Live; nothing actionable yet. On a receive leg this covers the whole
- * stretch before the solver funds anything. */
-"pending"
-/** There is something for the trader to take, and the window to take it is
- * open: the confirmed L1 fill on an onchain send, or a lockup funded for at
- * least `expectedAmount` on a receive. */
- | "claimable"
-/**
- * The trader's claim has been made — its L1 broadcast on an onchain send,
- * its Arkade submission on a receive.
+ * The row is the wallet's own copy of the tree, written from the covenant
+ * before the address could be funded and keyed by the script it derives, which
+ * `createContract` refuses to write unless the params reproduce it. That is why
+ * an RFQ swap record stores no tree parameters of its own.
  *
- * **On a receive this is a local belief and not a chain fact**, which is
- * why it is not terminal: `settled` is the chain's answer, and `refunded`
- * is still reachable from here if the claim never lands and the solver
- * takes the lockup back.
- */
- | "claimed"
-/**
- * This wallet will not act, and only the counterparty can change that.
- *
- * On a send leg: the Arkade refund cannot be pushed from here — no secrets
- * on the record, a descriptor from another seed, or nothing wired to act —
- * so the lockup comes back only if the counterparty claims it or the wallet
- * that can sign it is restored. On a receive leg: the trader holds no
- * refund at all, so this is a lockup that cannot be claimed — funded for
- * less than the swap agreed (publishing `P` for it is the whole attack
- * `LockupAmountMismatchError` exists to refuse), or one whose claim window
- * shut unclaimed. {@link RfqSwapCommon.blockedReason} says which.
- *
- * **Not terminal, and not a dead end.** The money is still at the lockup,
- * so the counterparty's move is still observable and still ends the swap;
- * and the refusal is re-checked every pass, so restoring the right wallet,
- * wiring the callbacks, or the solver topping the lockup up returns the
- * swap to `pending` and resumes the normal drive. For an onchain-send swap
- * it says nothing about the L1 half, which keeps being driven and claimed.
- */
- | "needs_counterparty"
-/**
- * Terminal: the lockup was spent by a hash-verified claim. Read off chain,
- * never reported.
+ * Looked up by script rather than address: the script is the row's key, and
+ * decoding it here means a record whose address does not decode fails as a bad
+ * address instead of as a missing row.
  *
- * On a send leg that claim is the counterparty's, and it is proof the
- * counterparty completed its side. On a receive leg it is the TRADER's own
- * — matched by the hash and not by our txid, so a claim that lands without
- * us still counts (see {@link RfqSwapManager}).
- */
- | "settled"
-/**
- * Terminal: the lockup was spent by something other than a claim.
- *
- * On a send leg that is the money coming back, by the solver's hand or the
- * trader's. **On a receive leg it is a LOSS**: the lockup was the solver's
- * money, every non-claim leaf is the solver's, and a swap that ends here
- * ended with the trader's incoming payment never arriving. It is also where
- * a receive swap ends when its window closes with nothing left to observe —
- * see {@link RfqSwapManager}.
- */
- | "refunded"
-/** Terminal: an action failed and its window closed. */
- | "failed";
-/** The states after which the manager stops monitoring a swap. Deliberately
- * without `needs_counterparty`: retiring on it would unwatch a funded lockup
- * whose claim is still the thing that ends the swap. */
-declare const RFQ_SWAP_TERMINAL_STATES: readonly ["settled", "refunded", "failed"];
-declare const isRfqSwapTerminal: (state: RfqSwapState) => boolean;
-/**
- * What the manager needs to register a swap's lockup with the wallet, so the
- * indexer pushes its funding and its spend instead of being asked every few
- * seconds.
- *
- * Both fields are things the caller already holds. `script` is the very object
- * `pushRefundWithoutReceiver` and `pushClaim` take, so a caller wired to act has
- * it in hand; `address` is the request entrypoint's own return value. The
- * address is taken rather than re-derived on purpose — the row's address must be
- * the one that was actually funded, and a local re-derivation would silently use
- * the SDK's default network, which is the exact bug `registerOfferContract`
- * guards against.
- */
-interface RfqSwapLockup {
-    /** The covenant. Its `pkScript` MUST equal the record's `lockupPkScript`. */
-    script: InstanceType<typeof VHTLC.ScriptV2>;
-    /** The Arkade address that was funded. */
-    address: string;
-}
-interface RfqSwapCommon {
-    /** The negotiation id — this record's identity. */
-    rfqId: string;
-    state: RfqSwapState;
-    /** The Arkade lockup's scriptPubKey — `swapPkScript` from any of the four
-     * request entrypoints. This is what the manager watches to decide the swap:
-     * it is the only handle on the covenant whose spend witness says whether
-     * the swap settled or came back. */
-    lockupPkScript: Uint8Array;
-    /** The covenant behind {@link lockupPkScript}, when the caller wants the
-     * lockup registered with a contract manager. Optional: without it the
-     * manager still watches the swap on its timer, it just cannot subscribe.
-     * See {@link RfqSwapManagerDeps.contracts}. */
-    lockup?: RfqSwapLockup;
-    /** `sha256(P)`, hex — the quote's `payment_hash`. The claim leaf can only
-     * be spent by revealing a value that hashes to this, which is what makes a
-     * settlement provable rather than reported. For an onchain send this is
-     * the SAME hash the L1 `htlc` carries: one `P` unlocks both legs. */
-    paymentHash: string;
-    /**
-     * `refund_locktime` from the quote, unix seconds.
-     *
-     * Whose deadline it is inverts with the direction, and so does what to do
-     * about it. On a send leg it is the TRADER's: the lockup is the trader's
-     * money and this gates the refund that takes it back, so it is a moment to
-     * act AFTER. On a receive leg it is the SOLVER's: the trader has no refund
-     * leaf at all, and this is the moment to have claimed BEFORE.
-     */
-    refundLocktime: number;
-    createdAt: number;
-    updatedAt: number;
-    /** Set once the trader's own `refundWithoutReceiver` push landed. */
-    refundArkTxid?: string;
-    /** Why `state` is `failed`. */
-    failure?: string;
-    /** Why `state` is `needs_counterparty`. Distinct from {@link failure},
-     * which means an action was attempted and did not work. */
-    blockedReason?: string;
-}
-/** `arkade:BTC->lightning:BTC`. Nothing for the trader to claim: the solver
- * claims the lockup with the preimage it learns by paying the invoice — which
- * is exactly why that spend's witness is proof the payment landed. */
-interface LightningSendSwap extends RfqSwapCommon {
-    kind: "lightning_send";
-}
-/** `arkade:BTC->onchain:BTC`. Carries the L1 half the trader must claim. */
-interface OnchainSendSwap extends RfqSwapCommon {
-    kind: "onchain_send";
-    /** The locally derived HTLC from `requestOnchainSend` — the manager reads
-     * `pkScript`, `paymentHash` and `refundLocktime` off it to classify. */
-    htlc: OnchainHtlc;
-    /** `profile.min_confirmations` from the quote. */
-    minConfirmations: number;
-    /** The fill's outpoint, learned on first sighting. Without it a SPENT
-     * HTLC reads as never funded — see {@link classifyOnchainHtlc}. */
-    funding?: {
-        txid: string;
-        vout: number;
-    };
-    /** Our L1 claim's txid. */
-    claimTxid?: string;
-}
-/**
- * `lightning:BTC->arkade:BTC`. The inverted leg: the SOLVER funds the lockup
- * and the TRADER claims it, and that claim is what publishes `P` and lets the
- * solver settle the payer's held Lightning HTLC.
- *
- * Two consequences shape how this record is driven, both of them absent from
- * the send legs:
- *
- * - **There is no trader-side refund.** Every non-claim leaf of this covenant
- *   is the solver's, so the manager never calls
- *   {@link RfqSwapManagerCallbacks.refundArkade} for one of these. A swap that
- *   is not claimed is simply lost — the solver reclaims at
- *   {@link RfqSwapCommon.refundLocktime} and the payer is refunded when the
- *   held HTLC lapses.
- * - **The claim is the whole swap, and it is on a deadline.** The trader must
- *   be online for it: covclaimd cannot claim this covenant today, so the claim
- *   packet's offline path does not run.
- */
-interface LightningReceiveSwap extends RfqSwapCommon {
-    kind: "lightning_receive";
-    /**
-     * What the lockup must carry — the quote's `to_amount`, captured at REQUEST
-     * time and persisted with the record.
-     *
-     * **Not re-derivable, and not optional.** Captured at claim time it would
-     * be whatever the solver funded, which is the dust-funding attack rather
-     * than a check on it. A record that reaches the manager without a finite
-     * value here is reported `needs_counterparty` and never claimed: a
-     * comparison against `undefined` or `NaN` is false, so an unusable
-     * comparand does not fail the value gate, it deletes it.
-     */
-    expectedAmount: number;
-    /** Our Arkade claim's txid, once submitted. Set from the callback's return
-     * and never from a chain read — the chain's answer is `settled`. */
-    claimArkTxid?: string;
-}
-/**
- * A monitored swap.
- *
- * This is a live record, not a serialization format: `lockupPkScript` and
- * `htlc` hold derived `Uint8Array`s, and
- * {@link RfqSwapManagerCallbacks.saveSwap} is where a caller projects it into
- * whatever it stores. Rebuild it on restart the way it was made —
- * `lightningSendVtxoScript` / `receiveVtxoScript` / `onchainHtlcScript` over
- * the quote's binding fields — and hand the result to
- * {@link RfqSwapManager.start}.
- *
- * **`onchain:BTC->arkade:BTC` is deliberately not a member yet.** Its Arkade
- * half is the same solver-funded lockup as {@link LightningReceiveSwap}'s, but
- * it also has an L1 half the trader funds and must take back itself
- * (`buildHtlcRefund` at the HTLC's own `htlc_locktime`), which is a second
- * deadline, a second observation seam and a second action callback. Adding the
- * lockup half alone would produce a manager that silently lets that L1 refund
- * window pass — the one failure mode {@link RfqSwapManager} refuses elsewhere
- * by name (see `driveOnchain`'s missing-`ChainSource` check). Until the L1
- * refund is driven too, that corridor is better served by the request and claim
- * functions directly than by a monitor that covers half of it.
- */
-type RfqSwap = LightningSendSwap | OnchainSendSwap | LightningReceiveSwap;
-/** What the manager should do next about an onchain-send swap's L1 half. */
-type OnchainSendAction = 
-/** Not funded yet, or not confirmed deep enough. */
-"wait"
-/** Funded, confirmed, and far enough from the refund leaf to claim safely. */
- | "claim"
-/** The claim is off the table for good; the money comes back through the
- * Arkade lockup instead. */
- | "claim_window_closed"
-/** Our claim already landed (only the trader holds P). */
- | "claimed"
-/** The solver took its L1 refund — the fill is gone. */
- | "swept";
-/**
- * The decision a "poll status, refund on timeout" loop gets wrong.
- *
- * {@link OnchainHtlcPhase} runs `unfunded -> awaiting_confirmations ->
- * claimable -> (refundable | claimed | swept)`, and `refundable` does NOT mean
- * "time to refund the L1 HTLC" — the trader has no key on that leaf; it is the
- * SOLVER's refund, and reaching it means the trader's claim was missed. So the
- * L1 claim has to be driven before it, and from it the only remaining move is
- * the Arkade-side refund.
- *
- * There is a second, quieter trap between those two functions:
- * `classifyOnchainHtlc` reports `claimable` right up until median-time-past
- * reaches `refundLocktime`, while `claimOnchainFill` refuses from
- * {@link ONCHAIN_CLAIM_MARGIN_SECONDS} before it — because broadcasting
- * publishes P, and doing that into the counterparty's live refund window risks
- * losing the race AND giving away the preimage. Driving straight off the phase
- * would therefore spend that whole margin throwing `claim_window_closed` at
- * every poll and never fall back. This function applies the margin, so
- * "claimable" here means claimable by `claimOnchainFill` too.
- */
-declare function nextOnchainAction(input: {
-    phase: OnchainHtlcPhase;
-    /** `htlc.refundLocktime` — when the solver's L1 refund leaf opens. */
-    htlcLocktime: number;
-    /** Unix seconds. */
-    now: number;
-}): OnchainSendAction;
-/** What the trader's own `refundWithoutReceiver` push returned, or `null` when
- * the lockup held nothing to return. */
-type ArkadeRefundResult = {
-    arkTxid: string;
-    amount: number;
-} | null;
-/**
- * The money-moving half, injected. The manager decides when; these do it.
- *
- * Neither action gets a retry loop of its own here — see the module doc. Do
- * NOT wire `refundArkade` to `refundIfUnresolved`: that function is the
- * single-swap version of this whole class and brings its own status polling
- * and its own MTP retry loop, which would nest inside the manager's. Wire it
- * to `findLockupVtxos` + `pushRefundWithoutReceiver`, which is the atomic push
- * `refundIfUnresolved` itself calls.
- *
- * Resolve the sender key through `senderIdentityForSwapRecord`: it is
- * what turns "this wallet cannot sign this swap" into
- * {@link RefundNotLocallyPossibleError}, which the manager reports as
- * `needs_counterparty` instead of retrying for the whole refund window.
- */
-interface RfqSwapManagerCallbacks {
-    /** Build and broadcast the L1 claim. See `claimOnchainFill`. */
-    claimOnchain: (swap: OnchainSendSwap, utxo: ChainUtxo) => Promise<{
-        txid: string;
-    }>;
-    /**
-     * Claim the solver-funded lockup on a receive leg, revealing `P`. Wire it
-     * to `pushClaim` — the outputs are supplied, so `findLockupVtxos` has
-     * already been called and `claimReceiveLockup`'s wait would only sit on a
-     * lockup the manager has just seen.
-     *
-     * **Pass `expectedAmount` and `partiallyClaimed` straight through.** The
-     * manager checks the funded value before calling this, but that check
-     * decides WHEN to act; `pushClaim`'s decides whether `P` is published, and
-     * it is the one that runs with nothing between it and the signature. Two
-     * checks, one of which is load-bearing — do not drop the inner one because
-     * the outer one exists.
-     *
-     * Required rather than optional, like {@link claimOnchain}: a receive swap
-     * monitored with nothing wired to claim it is a swap that quietly expires,
-     * and a compile error is the right way to learn that.
-     */
-    claimLockup: (swap: LightningReceiveSwap, vtxos: readonly LockupVtxo[], options: {
-        /** A claim of ours is already out, so `P` is public and the value
-         * gate has nothing left to protect — pass this to `pushClaim` so a
-         * funding that arrived piecemeal can still be swept. */
-        partiallyClaimed: boolean;
-    }) => Promise<{
-        arkTxid: string;
-        amount: number;
-    }>;
-    /** Push `refundWithoutReceiver` for every output at the lockup. See
-     * `pushRefundWithoutReceiver`; return `null` for an empty lockup. Never
-     * called for a {@link LightningReceiveSwap} — that leg's refund leaf is the
-     * solver's. */
-    refundArkade: (swap: RfqSwap) => Promise<ArkadeRefundResult>;
-    /**
-     * Whether a local refund is possible at all — the record's secrets, against
-     * this wallet. Called every pass, including *before* the refund window
-     * opens, so a swap nobody can refund says so while the solver can still
-     * act, instead of at the deadline; and so restoring the right wallet lifts
-     * the state again. Never called for a receive swap: there is no local
-     * refund there to probe for.
-     *
-     * Optional: omit to answer "yes" and learn at push time, from
-     * {@link RefundNotLocallyPossibleError}. Local by contract — no network
-     * call belongs here.
-     */
-    canRefundArkade?: (swap: RfqSwap) => Promise<{
-        ok: true;
-    } | {
-        ok: false;
-        reason: string;
-    }>;
-    /** Persist the record. Called after any pass that changed it. */
-    saveSwap: (swap: RfqSwap) => Promise<void>;
-}
-/** The actions the manager executes on a caller's behalf. */
-type RfqSwapActionName = "claimOnchain" | "claimLockup" | "refundArkade";
-interface RfqSwapManagerEvents {
-    /** Every state change, including ones that read as going backwards.
-     * `claimed -> claimable` is legal and expected on a receive swap the solver
-     * funds piecemeal: a lockup topped up after a claim is a new claimable
-     * event, and the label says so before the sweep goes out. Treat these
-     * states as a description of what to do next, not as a progress bar. */
-    onSwapUpdate?: (swap: RfqSwap, previous: RfqSwapState) => void;
-    /** Fired once, when a swap leaves monitoring `settled` or `refunded`.
-     * A swap that ends `failed` reports through `onSwapFailed` instead — the
-     * two are mutually exclusive. */
-    onSwapCompleted?: (swap: RfqSwap) => void;
-    /** Fired for any action that threw — including ones the manager will retry
-     * on the next pass — and once more when the swap finally ends `failed`. */
-    onSwapFailed?: (swap: RfqSwap, error: Error) => void;
-    onActionExecuted?: (swap: RfqSwap, action: RfqSwapActionName) => void;
-}
-type SwapUpdateListener = NonNullable<RfqSwapManagerEvents["onSwapUpdate"]>;
-type SwapCompletedListener = NonNullable<RfqSwapManagerEvents["onSwapCompleted"]>;
-type SwapFailedListener = NonNullable<RfqSwapManagerEvents["onSwapFailed"]>;
-type ActionExecutedListener = NonNullable<RfqSwapManagerEvents["onActionExecuted"]>;
-interface RfqSwapManagerConfig {
-    /** Drive claims and refunds automatically (default: true). With this off
-     * the manager still watches and reports, so a caller can act by hand off
-     * `claimable`. */
-    enableAutoActions?: boolean;
-    /** How often to run a pass, ms. Default 5000 — the same interval
-     * `awaitOnchainFill` and `refundIfUnresolved` poll at. */
-    pollIntervalMs?: number;
-    /** Injected for tests; defaults to wall clock, in unix seconds — the same
-     * convention `refundIfUnresolved` uses. */
-    now?: () => number;
-    events?: RfqSwapManagerEvents;
-}
-/** The contract-manager surface this needs, narrowed for injection — the same
- * seam style as {@link LockupSpendIndexer} and `refund.ts`'s
- * {@link RefundArkProvider}, and satisfied structurally by a real
- * `ContractManager` (`await wallet.getContractManager()`). */
-type SwapContractRegistry = Pick<IContractManager, "createContract" | "getContracts" | "onContractEvent" | "setContractWatchState">;
-/** The observation seams. None is owned by the manager, and none holds keys —
- * same philosophy as `onchainHtlc.ts`'s `ChainSource`. There is no
- * `RfqTransport` here on purpose: nothing this manager decides depends on the
- * solver answering (see the module doc). */
-interface RfqSwapManagerDeps {
-    /** Arkade access. Required: this is how a swap's resolution is determined,
-     * for both legs. */
-    indexer: LockupSpendIndexer;
-    /** L1 access. Required to monitor onchain-send swaps; a lightning-only
-     * caller can leave it out. */
-    chain?: ChainSource;
-    /**
-     * The wallet's contract manager, when there is one. Optional in the same
-     * way {@link chain} is: a caller with no wallet, or one that only wants the
-     * timer, still gets a fully working manager — the subscription is a
-     * LATENCY optimization and nothing depends on it.
-     *
-     * Supplying it buys two things. The lockup gets REGISTERED, which is what
-     * puts it in the wallet's own contract set at all — a prerequisite for
-     * anything that has to act on the lockup before its batch expires, since an
-     * expired lockup is swept and loses every cooperative path. And the indexer
-     * PUSHES its funding and its spend, so a settlement is noticed when it
-     * happens rather than up to `pollIntervalMs` later.
-     *
-     * Prefer `await wallet.getContractManager()` over constructing one, the way
-     * `createOffer` does.
-     */
-    contracts?: SwapContractRegistry;
-}
-/**
- * Watches a set of live RFQ swaps and drives each to its end.
- *
- * One pass per swap, in this order, every
- * {@link RfqSwapManagerConfig.pollIntervalMs} — and additionally the moment a
- * contract event names that swap's lockup, which changes only WHEN a pass runs,
- * never what it concludes (see {@link subscribe}):
- *
- * 0. **Register the lockup**, if a contract manager was supplied and it is not
- *    registered yet. Best-effort; never blocks the steps below.
- * 1. **Ask the chain what became of the lockup** — {@link readLockupFate}. A
- *    spend whose witness HASHES to the quote's `payment_hash` ends the swap
- *    `settled`; a lockup fully spent by anything else ends it `refunded`.
- *    Anything the indexer could not answer is `unknown`, which is NOT an
- *    answer: the pass carries on to the steps below, whose deadlines an indexer
- *    outage has no bearing on.
- * 2. **Drive the trader's claim.** On an onchain send that is the L1 fill — see
- *    {@link nextOnchainAction}. On a receive it is the lockup itself, and it
- *    ends the pass: that leg has no step 3.
- * 3. **Take the lockup back**, send legs only, once `refundLocktime` has passed
- *    and step 1 has not ended the swap. This runs for onchain-send too,
- *    including after a successful claim: the trader's lockup is still funded and
- *    still theirs to recover if the solver never comes for it. When no local
- *    refund is possible at all — no secrets, another wallet's descriptor,
- *    nothing wired — the swap reports `needs_counterparty` instead of retrying
- *    a push that cannot work.
- *
- * **What step 1 proves depends on the direction.** On a send leg every non-claim
- * leaf pays the trader's own committed address or needs the trader's own
- * signature, so "spent, but not by a hash-verified claim" means the money came
- * back. On a receive leg those leaves are the SOLVER's and the claim leaf is the
- * trader's, so the same two readings mean the opposite things — `settled` is the
- * trader's own claim landing, `refunded` is the solver taking back a lockup the
- * trader failed to claim. The read is identical; only the state docs differ.
- *
- * Two things about the receive arm that are easy to get wrong, and are asserted
- * in the tests rather than left to be inferred:
- *
- * - **A claim is matched by its preimage, never by our txid.** The covenant's
- *   `nonInteractiveClaim` leaf is pinned to the trader's own payout script, so a
- *   claim that lands without us — covclaimd, the day it works — still pays the
- *   trader and is still `settled`. Matching on the txid we submitted would turn
- *   that success into an anomaly.
- * - **`LockupFate.fate === "claimed"` maps to the state `settled`, never to the
- *   state `claimed`.** The two words live one layer apart: the fate is the
- *   chain's, the state is ours, and the state `claimed` means only that we
- *   submitted something.
+ * Throws {@link LockupContractMissing} when there is no row.
  */
-declare class RfqSwapManager {
-    private readonly deps;
-    private readonly config;
-    private callbacks;
-    private readonly swapUpdateListeners;
-    private readonly swapCompletedListeners;
-    private readonly swapFailedListeners;
-    private readonly actionExecutedListeners;
-    private readonly monitored;
-    /** Monitored swaps by lockup script hex, so a contract event — which names
-     * a script and nothing else — can find the swap it belongs to. */
-    private readonly byLockupScript;
-    /**
-     * Swaps whose lockup registration has been SETTLED one way or another,
-     * mapped to whether a contract row actually resulted. Membership is what
-     * stops a per-pass retry from becoming a per-pass round trip; the value is
-     * what keeps a swap that could never be registered from later trying to
-     * retire a row that does not exist, which would report a spurious failure
-     * on a swap that in fact succeeded.
-     */
-    private readonly registered;
-    /**
-     * Swaps whose `refundArkade` answered {@link RefundNotLocallyPossibleError}
-     * in this process. Membership stops the push from being re-issued every
-     * pass — it cannot start working on its own, and re-issuing it is the
-     * grind `needs_counterparty` exists to remove. Only
-     * {@link RfqSwapManagerCallbacks.canRefundArkade} clears it, so a caller
-     * with no probe learns again on the next start, when the wallet that can
-     * sign may well have been restored.
-     */
-    private readonly refundRefused;
-    /**
-     * The last error a receive swap's claim callback threw, by rfqId.
-     *
-     * Kept only to tell two terminal outcomes apart once the claim window
-     * shuts: a swap whose claim was attempted and kept failing ends `failed`
-     * with that reason, while one that simply never became claimable ends
-     * `refunded`. Without it a broken claim callback would resolve a caller's
-     * {@link waitForSwapCompletion} as an ordinary unwind.
-     *
-     * Process-local, like {@link refundRefused}: after a restart the same swap
-     * ends `refunded` instead, which costs the caller a reason and nothing else
-     * — every throw was already reported through `onSwapFailed` as it happened.
-     */
-    private readonly lastClaimError;
-    /**
-     * The lockup outpoints a receive swap's claim callback has already been
-     * handed, by rfqId.
-     *
-     * What this exists to prevent: a claim SUCCEEDS, and for the next few
-     * passes the indexer still lists those outputs as unspent. Without a
-     * record of what was already claimed, every one of those passes would
-     * re-submit the same spend, fail against the server, and report a swap
-     * that in fact worked as failing. With one, a re-claim happens only when
-     * an outpoint appears that was never claimed — a lockup funded piecemeal,
-     * which is legitimate and which `partiallyClaimed` exists for.
-     *
-     * Process-local: after a restart a swap with a live claim tries once more.
-     * That is the recovery case rather than the spam one — a claim that never
-     * landed leaves its outputs unspent, and one that did leaves a single
-     * rejection.
-     */
-    private readonly claimedOutpoints;
-    /** Live `onContractEvent` subscription, held so `stop()` can drop it. */
-    private unsubscribeContracts;
-    /** Terminal records, kept so a late {@link waitForSwapCompletion} still
-     * answers instead of throwing "not found". Cleared by {@link removeSwap}. */
-    private readonly finished;
-    private readonly waiters;
-    /** Records changed during the current pass, flushed through `saveSwap`. */
-    private readonly dirty;
-    /** Race guard: one action at a time per swap. */
-    private readonly inProgress;
-    private timer;
-    private running;
-    constructor(deps: RfqSwapManagerDeps, config?: RfqSwapManagerConfig);
-    /** Wire the money-moving half. Without it the manager only watches. */
-    setCallbacks(callbacks: RfqSwapManagerCallbacks): void;
-    onSwapUpdate(listener: SwapUpdateListener): () => void;
-    onSwapCompleted(listener: SwapCompletedListener): () => void;
-    onSwapFailed(listener: SwapFailedListener): () => void;
-    onActionExecuted(listener: ActionExecutedListener): () => void;
-    /**
-     * Load records and begin monitoring. Runs one pass immediately — a caller
-     * resuming after a restart may be well past a deadline already — then
-     * every `pollIntervalMs`. Records that are already terminal are kept only
-     * so {@link waitForSwapCompletion} can answer for them.
-     *
-     * Calling it again while running loads the records and returns rather than
-     * re-arming — dropping them silently would strand a funded swap on a
-     * caller's harmless double-start.
-     */
-    start(swaps?: readonly RfqSwap[]): Promise<void>;
-    /**
-     * Stop monitoring and clear the timer. In-flight actions are not
-     * cancellable and run to completion; outstanding
-     * {@link waitForSwapCompletion} promises are left pending, since
-     * stop/start is a pause rather than a cancellation.
-     *
-     * The contract subscription is dropped too — an open stream with nothing
-     * reacting to it is a leak, and {@link start} puts it back. What is NOT
-     * undone is the contract registration: those rows are the wallet's, they
-     * outlive this manager's lifecycle, and dropping them would unwatch a
-     * lockup that is still funded.
-     */
-    stop(): Promise<void>;
-    /** Begin monitoring a swap. Polled immediately when the manager is running,
-     * so a just-funded swap does not wait out a whole interval. */
-    addSwap(swap: RfqSwap): Promise<void>;
-    /** Forget a swap entirely, monitored or finished.
-     *
-     * Its contract row is left alone: registration is a wallet-level fact about
-     * a script that may still hold money, and this call says only that THIS
-     * manager stops driving the swap. Retiring the row is reserved for a swap
-     * that reached a terminal state, where the lockup is provably done. */
-    removeSwap(rfqId: string): Promise<void>;
-    /** Every swap still being monitored. */
-    getPendingSwaps(): Promise<RfqSwap[]>;
-    hasSwap(rfqId: string): Promise<boolean>;
-    /** True while an action for this swap holds the per-swap lock. */
-    isProcessing(rfqId: string): Promise<boolean>;
-    getStats(): Promise<{
-        isRunning: boolean;
-        monitoredSwaps: number;
-        finishedSwaps: number;
-        inProgress: number;
-        pollIntervalMs: number;
-    }>;
-    /**
-     * Run one monitoring pass over every swap now.
-     *
-     * {@link start} calls this on an interval, but it is public on purpose: a
-     * caller that sleeps its process (a mobile app resuming, a service worker
-     * waking) wants a pass on that event rather than at the next tick. Passes
-     * do not overlap per swap — the in-progress lock makes a concurrent call a
-     * no-op for any swap already being worked on.
-     */
-    poll(): Promise<void>;
-    /**
-     * Resolve once this swap's PAYOUT is decided — which for onchain-send is
-     * the L1 claim, not the end of the record's life: once `claimTxid` is set
-     * the trader has the coins it swapped for, and what remains is the manager
-     * watching the Arkade lockup close. That holds however the record is
-     * labelled afterwards, `needs_counterparty` included. Lightning-send has no
-     * such split and resolves at `settled`/`refunded`, and so does lightning
-     * receive — see {@link isPayoutDecided} for why its own claim txid does not
-     * decide it.
-     *
-     * Rejects only on `failed`. `refunded` resolves: on a send leg a refund is
-     * an outcome the caller asked this manager to drive, not an exception. On a
-     * receive leg it is the swap being lost, which is still an answer and not
-     * an error — read `state`, do not infer success from resolution.
-     */
-    waitForSwapCompletion(rfqId: string): Promise<RfqSwapOutcome>;
-    private track;
-    /** Drops the swap from BOTH indexes. The event index is the one that stops
-     * a late event finding a swap that is gone; `pollSwap`'s own
-     * `monitored` check would also catch it, and deliberately still does —
-     * either alone is sufficient, which is what keeps a future change to one of
-     * them from silently re-driving a cancelled swap. */
-    private untrack;
-    /**
-     * Turn the indexer's push into an extra reason to run a pass — and nothing
-     * more.
-     *
-     * **This is deliberately not a source of truth.** An event names a script;
-     * the reaction is to run the ordinary pass for the swap at that script, and
-     * that pass re-reads the lockup through {@link readLockupFate} exactly as
-     * the timer's pass does. So an event that is missed, duplicated, reordered
-     * or outright FORGED can only cost or save latency — it can never change
-     * what this manager believes about a swap, and it can never on its own
-     * cause a claim or a refund. That property is what makes it safe to bolt a
-     * best-effort stream onto a money path, and it must survive any future
-     * change here: the moment an event is BELIEVED rather than merely acted on,
-     * a relay outage becomes a correctness problem instead of a latency one.
-     *
-     * The timer stays armed regardless, and is the failsafe. Every deadline
-     * that moves money — `refundLocktime`, the L1 claim window — is an absolute
-     * timelock that passes whether or not a single event ever arrives.
-     */
-    private subscribe;
-    /**
-     * Register this swap's lockup with the wallet's contract manager, once.
-     *
-     * The backstop, not the primary site: `requestLightningSend` /
-     * `requestOnchainSend` register before the caller can fund, so this covers
-     * swaps whose records predate that — and costs nothing when it does not,
-     * since `createContract` is first-writer-wins.
-     *
-     * Best-effort by design: a failure here is reported and retried on the next
-     * pass, and never aborts the pass it is part of. Registration buys latency
-     * and puts the lockup in the wallet's contract set; it decides nothing. The
-     * money path below it reads the indexer directly and is gated on timelocks
-     * that a missing contract row has no bearing on, so failing the pass over
-     * this would trade a real deadline for a bookkeeping one.
-     */
-    private ensureRegistered;
-    /** Stop watching a finished swap's lockup. Retained, not deleted: the row
-     * is what keeps the lockup's own VTXOs annotatable and its history
-     * readable, while `retained` is what drops it from the subscription and
-     * the poll — a settled swap that stayed watched would cost the wallet a
-     * script for its whole life. Best-effort — the swap is over either way. */
-    private retireContract;
-    private arm;
-    private pollSwap;
-    private runPass;
-    /**
-     * The receive leg's whole state machine: claim the solver-funded lockup
-     * while the window is open, and recognise the shapes in which it can be
-     * lost.
-     *
-     * **The window closes at `refundLocktime`, on wall clock, with no margin.**
-     * Both halves of that are deliberate. It closes there because publishing
-     * `P` into the solver's live refund window risks losing the race and
-     * handing over the preimage anyway — the hazard `ONCHAIN_CLAIM_MARGIN_SECONDS`
-     * guards on the L1 side. It takes no margin because the two situations are
-     * not alike: that one budgets for confirmation depth, while this claim is an
-     * offchain spend that lands in seconds. Wall clock is already the
-     * conservative reading — the solver's leaf is a CLTV, which matures against
-     * median-time-past, and MTP trails wall clock — so the real window extends
-     * PAST this deadline rather than ending before it. Every second of margin
-     * subtracted here is a second of live claim window given away for nothing.
-     *
-     * **The trader has no move after it.** Nothing here can take the lockup
-     * back, so once the window shuts the swap is the solver's to resolve and
-     * this manager's job is to watch it happen and then stop.
-     */
-    private driveReceiveClaim;
-    /**
-     * Claim what the solver funded, once it is enough.
-     *
-     * The value gate here decides WHEN to act. `pushClaim`'s decides whether
-     * `P` is published, and runs with nothing between it and the signature —
-     * the check that matters is the inner one, and this is not a reason to
-     * relax it.
-     */
-    private claimIfFunded;
-    /** `handled` ends the pass; `continue` falls through to the refund gate. */
-    private driveOnchain;
-    private driveArkadeRefund;
-    /** Whether any of these outputs has never been handed to the claim
-     * callback — the only reason to claim a lockup a second time. */
-    private hasUnclaimedOutpoint;
-    private rememberClaimed;
-    /**
-     * L1 progress, which past the refund window must not overwrite a refusal.
-     * The two halves are independent — a claimed fill says nothing about
-     * whether this wallet can take the Arkade lockup back — and `claimed` is
-     * re-asserted from chain on every pass, so without this a blocked swap
-     * would flip between the two states forever. The claim itself always runs;
-     * only the label defers, and only once the refund is the live half.
-     */
-    private setOnchainState;
-    /** The probe's refusal reason, or `undefined` when a local refund is
-     * possible as far as anyone here can tell. A probe that throws is treated
-     * as a refusal: a capability check that cannot answer is not a yes. */
-    private probeRefusal;
-    /** Report that no local refund will happen, without ending the swap. */
-    private block;
-    /** The way back out, taken as soon as the swap becomes actionable again.
-     * Back to what the record can prove, not to `pending` unconditionally: a
-     * swap that already made its claim has a txid for it, and reporting that
-     * swap as `pending` would un-say something true. */
-    private unblock;
-    private touch;
-    private setState;
-    /** Terminal failure. The `onSwapFailed` emission is left to
-     * {@link finalize}, so this does not double-report. */
-    private fail;
-    private emitFailed;
-    private emitAction;
-    /** Whether the record is now persisted — false only when `saveSwap` threw. */
-    private save;
-    /**
-     * Drop a terminal swap from monitoring and report it exactly once.
-     *
-     * `onSwapCompleted` and `onSwapFailed` are mutually exclusive here, unlike
-     * Boltz's manager, which fires completion for every swap that leaves
-     * monitoring including the failed ones — a listener named "completed" that
-     * also fires on failure is a trap worth not inheriting.
-     */
-    private finalize;
-    private settleWaiters;
-}
-/** What {@link RfqSwapManager.waitForSwapCompletion} reports. `txid` is the
- * trader's own claim — L1 for a claimed onchain send, Arkade for a claimed
- * receive — or the ark txid for a refund the trader pushed; a solver-side
- * settlement or refund carries none, and a receive swap that ended `refunded`
- * carries none either, however far its claim got (see {@link outcomeOf}). So
- * a `txid` here always names something that happened, and `state` remains the
- * only thing to read for whether the swap paid out. */
-interface RfqSwapOutcome {
-    state: RfqSwapState;
-    txid?: string;
-}
+declare function lockupContractParams(contracts: LockupContractReader, lockupAddress: string): Promise<Record<string, string>>;
 
 /**
  * One swap, flattened to what grouping needs: an identity, a corridor, an
  * outcome, and every Arkade transaction that belongs to it.
  *
  * Deliberately not a stored swap record itself — resolution should stay
- * testable with plain data rather than a repository. A correlation helper
- * that derives these from the record store and the funding lockup's VTXOs
- * lands separately.
+ * testable with plain data rather than a repository. {@link rfqSwapActivityInputs}
+ * derives these from the record store and, where a record cannot answer, the
+ * funding lockup's VTXOs.
  */
 interface SwapActivityInput {
     rfqId: string;
-    /**
-     * Literal union rather than `RfqSwapRecord["kind"]` — `RfqSwapRecord` lives
-     * only on the unmerged rfq-persistence branch, not on master. Reconcile
-     * with `RfqSwapRecord["kind"]` once that branch lands.
-     */
-    kind: "lightning_send" | "lightning_receive" | "onchain_send";
+    kind: RfqSwapRecord["kind"];
     state: RfqSwapState;
     /** Funding, claim and refund txids, in whatever order. */
     txids: readonly string[];
@@ -1824,5 +950,32 @@ interface SwapActivityInput {
 declare function swapActivityResolver(deps: {
     listSwaps(): Promise<readonly SwapActivityInput[]>;
 }): ActivityResolver;
+interface RfqSwapActivityDeps {
+    repository: Pick<AssetSwapRepository, "getAllRfqSwaps">;
+    /**
+     * Consulted only for what a record cannot answer: a record written before
+     * `fundingArkTxid` existed, and the counterparty's spend on a swap that
+     * ended without a refund of ours.
+     *
+     * Optional because the stored fields are the primary source — cheaper, and
+     * they work offline, which is the resolver's whole posture. An indexer that
+     * throws costs that record its extra txids and nothing else.
+     */
+    indexer?: LockupSpendIndexer;
+}
+/**
+ * Every stored RFQ swap, flattened into what {@link swapActivityResolver}
+ * groups on.
+ *
+ * The txids come from four places, in order of preference: the record's own
+ * `fundingArkTxid` and `refundArkTxid`, the corridor's `activityTxids` (the
+ * receive leg's Arkade claim, the onchain leg's L1 one), and — only when the
+ * first two cannot answer — one read of the lockup's VTXOs.
+ *
+ * A missing txid costs an activity a row, never a wrong one: a swap that
+ * contributes fewer txids simply leaves those transactions ungrouped, which is
+ * what they already are.
+ */
+declare function rfqSwapActivityInputs(deps: RfqSwapActivityDeps): Promise<SwapActivityInput[]>;
 
-export { type ArkadeRefundResult, AssetSwap, AssetSwapRepository, ChainSource, ChainUtxo, type ClaimArkProvider, type ClaimPacketInput, type DiscoverMarketsOptions, IndexedDbAssetSwapRepository, type LightningReceiveSwap, type LightningSendSwap, LockupAmountMismatchError, type LockupContractWriter, type LockupFate, LockupNeedsRecoveryError, LockupRegistrationFailed, type LockupSpendIndexer, type LockupVtxo, MarketsCacheEntry, OFFER_PACKET_TYPE, type Offer, type OfferContractRetirer, type OfferSwapWatcher, OnchainHtlc, OnchainHtlcPhase, type OnchainSendAction, type OnchainSendSwap, type PlanError, QUOTE_OPTIONS, REFUND_MTP_LAG_SECONDS, RFQ_RESOLVED_STATES, RFQ_SWAP_TERMINAL_STATES, type RefundArkProvider, type RefundBlockedReason, type RefundIndexer, RefundNotLocallyPossibleError, type RefundOutcome, type RestoreIndexer, RfqStatus, type RfqSwap, type RfqSwapActionName, type RfqSwapLockup, RfqSwapManager, type RfqSwapManagerCallbacks, type RfqSwapManagerConfig, type RfqSwapManagerDeps, type RfqSwapManagerEvents, type RfqSwapOutcome, type RfqSwapState, RfqTransport, SWAP_LOCKUP_CONTRACT_KIND, SWAP_LOCKUP_CONTRACT_LABEL, SWAP_LOCKUP_CONTRACT_TYPE, type SealedClaimPacket, type SpendKind, type SwapActivityInput, type SwapContractRegistry, type Tx, type WatchOfferSwapsParams, awaitLockupFunding, awaitRfqResolution, cancelOffer, claimReceiveLockup, classifyDepositSpend, classifySpend, createOffer, decodeOffer, discoverMarkets, encodeOffer, findLockupVtxos, findMarket, isRfqSwapTerminal, isRfqTerminal, makeCachedFeedFetch, nextOnchainAction, offerVtxoScript, pushClaim, pushRefundWithoutReceiver, readLockupFate, refundIfUnresolved, registerLockupContract, restoreAssetSwaps, retireSettledOfferContracts, sealClaimPacket, senderIdentityForSwapRecord, spendTxidsOf, spendUpdate, swapActivityResolver, swapPrograms, validatePlan, watchOfferSwaps };
+export { ArkadeRefundResult, type ArkadeRefunderDeps, AssetSwap, AssetSwapRepository, type ClaimArkProvider, type ClaimPacketInput, type DiscoverMarketsOptions, IndexedDbAssetSwapRepository, type LightningReceiveProfile, type LightningSendProfile, LockupAmountMismatchError, LockupContractMissing, type LockupContractReader, type LockupContractWriter, LockupRegistrationFailed, LockupSpendIndexer, LockupVtxo, MarketsCacheEntry, OFFER_PACKET_TYPE, type Offer, type OfferContractRetirer, type OfferSwapWatcher, OnchainHtlc, OnchainHtlcParams, OnchainNetwork, type OnchainSendProfile, type PlanError, QUOTE_OPTIONS, RefundArkProvider, type RefundBlockedReason, RefundIndexer, RefundNotLocallyPossibleError, type RestoreIndexer, type RfqClaimSecretProjection, type RfqHashlockProjection, type RfqSignerProjection, RfqSwap, type RfqSwapActivityDeps, RfqSwapRecord, RfqSwapState, SWAP_LOCKUP_CONTRACT_KIND, SWAP_LOCKUP_CONTRACT_LABEL, SWAP_LOCKUP_CONTRACT_TYPE, type SealedClaimPacket, type SpendKind, type SwapActivityInput, SwapSecretsProjection, type Tx, type WatchOfferSwapsParams, arkadeRefunder, awaitLockupFunding, cancelOffer, claimReceiveLockup, classifyDepositSpend, classifySpend, createOffer, decodeOffer, discoverMarkets, encodeOffer, findMarket, lockupContractParams, makeCachedFeedFetch, offerVtxoScript, onchainSendProfile, pushClaim, registerLockupContract, restoreAssetSwaps, retireSettledOfferContracts, rfqClaimSecretOf, rfqSecretsProfile, rfqSignerOf, rfqSwapActivityInputs, sealClaimPacket, senderIdentityForSwapRecord, spendTxidsOf, spendUpdate, swapActivityResolver, swapPrograms, validatePlan, watchOfferSwaps };