@exodus/bitcoin-api

Transaction monitors, fee monitors, RPC with the blockchain node, and other networking code for Bitcoin and Bitcoin-like assets (e.g. dogecoin, litecoin, zcash). See Asset Packages for more detail on this package's role.

Mempool WebSocket-assisted confirmation checks

Confirmation-only scans reuse WebSocket transaction statuses and block heights for ten seconds, with at most 1,000 statuses per client. Missing or expired hints fall back to /api/tx/:txid/status instead of full transaction/outspend reads. New or replacement blocks, disconnect, stop, and backend changes invalidate the caches; standalone confirmations require a fresh tip lookup. Full history, UTXO, address-event, and reconnect reconciliation remain unchanged, as do Insight-backed monitors.

Confirmation checks recheck their inputs if a WebSocket update, disconnect, or backend change arrives during a lookup. They retry once, then fail rather than return obsolete confirmations if invalidated again.

Mempool Retry-After

Every HTTP 429 starts a process-local cooldown shared across clients and endpoints on the same origin. Valid Retry-After seconds or HTTP dates take precedence, using the server's Date header for clock skew when available, and are capped at five minutes. Missing or invalid values use a ten-second fallback; failed recovery doubles it with 0–20% positive jitter, also capped at five minutes. Concurrent responses from the original burst do not multiply backoff, but longer server deadlines are preserved.

Reads receiving HTTP 429 rejoin the end of the queue instead of immediately failing the monitor scan. Each read permits at most two retries, sharing its original 30-second queue deadline; cancellation, overflow, or expiry still fail finally. Exhausted retries fail with code 429, finalError, bounded retryAt/retryAfterMs, and hint mempoolRateLimited; generic retries stop. Queued reads wait until one recovery read can run, with a ten-second timeout including its body. Success or an ordinary 404 releases the cooldown; other HTTP, transport, or body failures renew it. No recovery request is generated when the queue is empty.

Mempool request scheduling

At most two REST requests run concurrently, including body consumption, with at least 200 ms between starts. Reads queue FIFO, bounded to 100 entries and a 30-second wait including cooldown. Abort signals remove queued reads; expired or cancelled entries never dispatch later. Normal requests have a 30-second dispatch-time timeout including the body, respecting shorter caller timeouts. History scans submit two address batches at a time while retaining full address coverage; Insight concurrency is unchanged.

Broadcasts wait only for a short pacing interval (at most one second) when capacity is available and no request is queued. Busy, cooling, or recovering origins reject sends rather than retaining them for later broadcast. Queue overflow/expiry use MEMPOOL_REQUEST_BUSY/MEMPOOL_REQUEST_QUEUE_TIMEOUT with finalError. Broadcasts are never recovery probes, and dispatched broadcasts receiving 429 are not automatically replayed.

Recovery resumes paced traffic rather than a burst. This client budget is not a vendor quota and cannot guarantee freedom from rate limits or bans. The five-minute cap may permit requests earlier than the server requested; queues and cooldowns are not persisted or coordinated across processes.