Each named lookup connection has list, spend, transaction, confirmedWhen, pendingWhen, spentWhen, unspentWhen, and delayMs. An optional balance connection checks the verified total when no pending incoming balance is reported.

A request defines an HTTPS url, GET or POST method, headers, and timeoutMs (1000–60000). POST requests also define a JSON body. URL placeholders are {address}, {cursor} and {offset}. Values are URL-encoded. No executable code is supported.

list defines request, rowsPath, txidPath, voutPath, satsPath and pagination. Amounts must be integer satoshis, never decimal BSV. An optional errorPath requires an empty error string. Pagination has mode (cursor, offset or none), pageSize, maxPages, and nextPath for cursor mode. Optional morePath requires an explicit boolean completion field; true requires a continuation cursor. A full page with no cursor or explicit completion is rejected. Offset increases by the returned row count; cursor mode follows the returned token. Repeated rows, repeated tokens and incomplete pagination stop lookup. A non-paginated result at or above pageSize is rejected as potentially truncated.

spend defines a batch request with the exact JSON value "{outputs}", batchSize, itemsPath, txidPath, voutPath, and an item template containing exact values "{txid}" and "{vout}". Every requested output must have exactly one matching response.

Rules use {"path":"status.spent","op":"eq","value":false}. Comparisons are eq (exact type and value), gt (numeric greater than), hash (64 hexadecimal characters), and absent (missing or null). Combine rules with {"all":[...]} or {"any":[...]}. Paths start with coin. for the list row or status. for the separate spend response. A confirmed coin must also satisfy unspentWhen. Unknown states stop lookup. Do not weaken these rules merely to accept a service response.

The optional balance object has request, confirmedPath and unconfirmedPath. Response field paths use dots; an empty path means the complete object or array. Lookup supports at most 100,000 outputs and 20 MB per response; pagination limits are explicit. API capabilities, authentication and browser access may require application changes for fundamentally different future services. Start from the bundled settings as examples. Restore buttons restore historical bundled services, not a live service directory.

The required transaction object defines request with a {txid} placeholder and format: text for raw hex or json with a hexPath. The application hashes and parses these bytes, checks the listed amount and output index, and admits only a plain P2PKH output paying the source address with more than one satoshi. These protections cannot be disabled by provider settings. Inscription envelopes are recognized before or after the address lock; every one-satoshi output is reserved, including possible transferred Ordinals with no envelope. Unsupported scripts are excluded. Unavailable or inconsistent transaction data stops lookup.

For an individual spend-status GET endpoint, use batchSize: 1, URL placeholders {txid} and {vout}, and response identity paths. Omit the batch item. itemsPath then points to one status object. BananaBlocks uses this form because its batch endpoint currently lacks browser preflight permission. Its bundled delay is 1000 ms per request to respect its anonymous rate limits. HTTP 429 stops the lookup; wait before retrying.

The optional balance check uses all returned confirmed unspent holdings before inscription exclusions. Payment-ready balances omit recognized inscriptions, one-satoshi outputs and unsupported scripts. A service may omit holdings entirely; an empty result is not proof that an address has no inscriptions. These checks do not authenticate creators, verify SIGMA signatures, or claim to identify every token protocol.

BananaBlocks uses its native /address/{address}/utxos inventory with items, cursor and hasMore. Its compatibility inventory was observed returning 100 of 125 outputs without a continuation marker; balance reconciliation caught the incomplete result. The native connection follows every cursor and checks completion explicitly.

Each entry defines name, HTTPS url, headers, request, response and timeoutMs. An optional status object defines a replaceable payment-status connection using the format below. Request format is json or text. Use the exact string {rawTx} for the signed transaction. Response format is json, text or json-or-text. txidPath is a dot-separated field path; an empty path means the entire response. For processors that return status information, specify statusPath and non-overlapping accepted, pending and rejected arrays. Unknown statuses remain pending. The returned transaction ID must always match the signed transaction. No executable code is supported.

This is a list of named connections, independent of payment submission. An empty list disables separate status services. A processor may alternatively include one connection as its optional status object. Names shared with this list use this list's current settings.

Each connection defines name, request, txidPath, blockHashPath, and either confirmationsPath or heightPath, plus confirmedWhen, pendingWhen, and rejectedWhen rules. A request has HTTPS url, GET or POST method, headers, timeoutMs, and a JSON body for POST. Use {txid} in its URL or body. The returned TXID must match. Confirmation requires a valid block hash and positive integer confirmation count or block height, even if confirmedWhen matches.

Rules use {"path":"state","op":"eq","value":"mined"}, with eq, gt, hash or absent comparisons, combined using all or any arrays. Paths refer directly to the JSON response. Empty paths mean the complete response. Unknown statuses never count as confirmation; not-found responses do not prove failure. Services must allow browser access. Validation is local and does not prove a provider is available or truthful.