Low-level: raw JSON-RPC call. Exposed for forward compatibility.
Honors BtxClientOpts.methodTimeouts (per-method override, audit D-4) and BtxClientOpts.retry (exponential backoff on transient failures, audit D-3). Both are opt-in via constructor options; default behavior is unchanged from 0.0.4 (30s single-attempt).
Optionalopts: RpcCallOptsIssue a fresh challenge bound to (purpose, resource, subject).
opts.signal (added 0.2.0) cancels the request if the caller aborts.
Optionalopts: RpcCallOptsVerify-and-consume atomically. THIS is the admission control entry point. On success, the challenge is marked redeemed and cannot be replayed.
opts.signal (added 0.2.0) cancels the request if the caller aborts —
but note: if the abort fires AFTER btxd has consumed the challenge,
the redemption stands (atomic) even though the local promise rejects.
Callers handling cancellation must treat post-abort state as "may have
been consumed" and verify via a separate verify() call if needed.
Optionalopts: RpcCallOptsBatch verify + consume. Sequential per-entry. Spec range 1–256 (audit M2).
opts.signal (added 0.2.0) cancels the request if the caller aborts.
Same post-abort caveat as redeem — partial batch may have been
consumed by btxd before the abort propagated.
Optionalopts: RpcCallOptsServer-side local solver. Useful when generating fixtures or pre-computing for tests. For production browser-side solving, ship the WASM solver — RPC-based solving puts compute load on YOUR node, defeating the point.
opts.signal (added 0.2.0) cancels the request if the caller aborts.
Optionalopts: RpcCallOptsVerify a proof statelessly. Does NOT consume the challenge. Use this for diagnostic / monitoring paths. For admission control, use redeem instead — verification alone does not prevent replay.
opts.signal (added 0.2.0) cancels the request if the caller aborts.
Optionalopts: RpcCallOptsBatch verify. Spec range 1–256 (audit M2). No consumption.
opts.signal (added 0.2.0) cancels the request if the caller aborts.
Optionalopts: RpcCallOpts
JSON-RPC client for BTX service-challenges.
Prerequisite — this points at a reachable BTX node (
btxd). There is no default or hosted endpoint;rpcUrlis abtxdyou (or a shared operator) run. Who needs a node:issue/verify/redeem. These are lightweight; any synced btxd serves them fast.solvevia'rpc'mode, that node must be non-mining (a mining node queues the solver behind block work, 10+ min). The caller can instead solve in-process with the pure-JS Solver (no node, but minutes-to-hours at production difficulty). In short: the server always needs node access; callers need it too only for fast solving — which is why the strongest fit is server-to-server / agent gating, where both ends are infrastructure. See Solver.Wraps the 5 core RPCs:
Plus helper RPCs:
RPC reference: https://btx.dev/docs/rpc/service-challenges
Error model:
timeoutMs