BSV TypeScript Stack Adds Economic Query Client for Paid Data Retrieval

Developer Tools / Payments Infrastructure

In Brief

The BSV TypeScript stack has published @bsv/eqc version 0.1.0, providing client software and host handlers for paid data queries on BSV Blockchain.

The Economic Query Client asks multiple hosts for an answer, checks whether enough agree, and divides payment among selected hosts according to how quickly their responses reach the client.

News Report

Version 0.1.0 was published to npm on October 28 at 01:22 UTC, following the merger of its main contribution on October 26.

The package implements a model described in BRC-178, Race-Settled Collection Markets for Overlay Lookups and Message Boxes. Its supported providers cover overlay lookups, MessageBox message listings and other reads that return bytes. Message listings are restricted to the authenticated recipient.

How Hosts Qualify for Payment

The process begins with signed attestations containing a hash of the proposed answer. The client records when each attestation arrives, using its own timing rather than timestamps supplied by hosts.

By default, three distinct host identity keys must attest to the same content hash before payment proceeds. The client ranks the agreeing hosts and can pay up to five through outputs in one transaction.

Payouts use square-root weighting: faster hosts receive larger shares, while other selected hosts also earn payment. The default fee settings specify a 1,000-satoshi floor and a 2,000-satoshi cap for host payouts. These settings are configurable; the cap is not a limit on total wallet expenditure including transaction fees.

The intended incentive is for hosts to possess matching data and serve it promptly. BRC-178 proposes that this can make sharing data with peers economically useful, because hosts need other agreeing responses for a query to qualify for payment.

Payment Precedes Completed Delivery

After choosing the recipients, the client creates and dispatches the payout transaction, then requests the full answers. It returns a result once one paid host delivers bytes matching the attested hash. Collection from the remaining paid hosts continues in the background.

This ordering matters: payment can already have been sent when delivery fails. If every paid host fails to supply valid bytes, the client reports an undelivered-query error that includes the payout transaction identifier.

Retries reuse the existing payment. Hosts retain delivery records so that a repeated collection request can recover a lost response without charging again.

Agreement also has limits. The threshold counts identity keys, which can belong to the same operator. Matching hashes alone do not establish that an answer is complete or current. For overlay results, the accompanying transaction-proof data still requires normal SPV verification.

A First Package With Further Integration Pending

The published design marks the work as experimental and identifies the package and an overlay-server integration hook as the completed first phase.

Operators must mount the host handlers behind authentication and supply a wallet with storage support that can receive payments. Adding the library therefore requires server integration and operational configuration.

The design assigns broader infrastructure wiring, sender-funded collection grants and host gossip to later phases. Those planned features should not be read as capabilities already delivered by this release.

The final contribution passed its hosted build-and-test, browser-package and artifact checks. BSV TIMES reviewed the published package, implementation and check records; it has not independently run a live paid query.

BSV TIMES Read

EQC brings a proposed service model into published developer tooling: applications can pay hosts for retrieving data, with payment allocation linked to response speed and agreement.

The immediate development is the availability of components that builders can integrate and test. Evidence of participating services, sustained demand and reliable delivery would establish how the model performs beyond the package itself.

For application developers, the useful distinction is between agreement, proof verification and successful delivery. Each addresses a different requirement, and the payment flow does not make those requirements interchangeable.

Developer Context

Darren “Deggen” Kellenschwiler, whose GitHub account is sirdeggen, authored the EQC contribution and is listed as the author of BRC-178.

BSV Association lists his work under Distributed Applications. His other standards contributions include coauthoring BRC-74, the BSV Unified Merkle Path format, with Tone Engel, Ty Everett, Damian Orzepowski and Arkadiusz Osowski.

Source Links

Posted on October 29, 2026 (UTC)