@btx-tools SDK — BTX service-challenge admission control
    Preparing search index...
    SolverMode: "rpc" | "pure-js" | "wasm" | "auto"

    How a challenge should be solved.

    Solving is the costly half of the protocol — it needs either a reachable btxd node ('rpc'), the optional WASM kernel ('wasm'), or a lot of local CPU time ('pure-js'). See Solver.solve for the node prerequisite and who runs what.

    • 'rpc' — delegate to btxd's solvematmulservicechallenge. Requires opts.rpcClient pointed at a non-mining btxd. Server-side / Node-only. Fast (~1–4 s) — the production path.

    • 'wasm' — solve locally with the optional @btx-tools/matmul-wasm kernel (byte-identical proof to 'pure-js', ~24× faster). No node required. The published build targets browsers/bundlers (Vite, Next, Workers); in plain Node, build the package's nodejs target from source or solve via 'rpc'. Throws a clear, distinct error if the package isn't installed vs installed-but-uninitializable-here. Still far slower than native at the production n=512 (a browser pool floor is ~16 s) — great for browser/edge solving without a btxd, not a casual per-request browser captcha.

    • 'pure-js' — solve locally with a pure-TypeScript MatMul implementation. No node and no optional package required, browser-compatible. Slow: bounded by BigInt-based M31 multiplication. Prefer 'wasm' when the kernel is installed; solve server-side via 'rpc' at production difficulty.

    • 'auto' — pick automatically: 'rpc' if opts.rpcClient is provided, else 'wasm' if @btx-tools/matmul-wasm is installed, else 'pure-js'.