Whitepaper · 01
Observation without custody.
A simple, inspectable view of native Bitcoin activity. No pooled funds, delegated spending or automated exits.
01. Abstract
Satquay is a browser application for observing Bitcoin mainnet addresses. It combines a selected address's confirmed balance, pending activity, recent transaction history and unspent outputs with a current view of network fees and block height.
The product separates three things that are often presented together: what is recorded in the blockchain, what a public node currently sees in its mempool, and what the user has chosen to watch. It makes each layer visible without acquiring authority over funds.
The name combines sat, the smallest unit of bitcoin, with quay, a place to observe before a journey. That is the product boundary: information for a user's decision, with execution remaining in their wallet.
02. Product scope
The unit of observation is a public Bitcoin address. A wallet connection is an optional address-sharing convenience, not an account system or a spending integration. A watchlist stores addresses locally and lets the user move between them.
Satquay does not infer all addresses controlled by a person, discover a wallet's derivation paths, track Lightning balances, provide yield or hold a claim on bitcoin. Only the selected address is refreshed during an active, visible browser session.
A native Bitcoin model
Bitcoin is observed through transactions and unspent outputs. There are no ERC-4626 vault shares, token approvals, redemption adapters or keeper exits in this implementation. Rules create notifications; they do not create transactions.
03. Architecture
The interface has four views: Overview, Activity, Plan & controls, and Network. They share an address selection and a latest successful observation. Network data can be useful before an address has been selected.
| Layer | Responsibility |
|---|---|
| Address input | Accept a pasted mainnet address or a public account shared by a supported wallet. Gate the format and validate the checksum through the provider. |
| Public data | Request address statistics, transaction pages, unspent outputs, fee recommendations, mempool statistics and current block height. |
| Observation state | Keep the last loaded snapshot, its timestamp and the current request status. Distinguish loading, unavailable and empty results. |
| Local preferences | Persist a watchlist, labels, settings and alert preferences in browser storage. |
| Presentation & export | Display the selected scope and download JSON or CSV snapshots without requiring a cloud account. |
Data follows the public mempool.space API and Esplora-style response formats. The application treats this data as a provider's observation. It does not run a Bitcoin full node or independently verify the chain.
04. Accounting model
Values are represented in satoshis before presentation in bitcoin. For the selected address, the model uses the provider's funded and spent output totals:
confirmed = chain.funded_txo_sum − chain.spent_txo_sum
pending change = mempool.funded_txo_sum − mempool.spent_txo_sum
estimated total = confirmed + pending changePending change is a signed value. It captures unconfirmed outflows as well as inflows. Treating only pending receipts as an additional balance would hide unconfirmed spending.
Transaction net change is the total value of outputs to the selected address minus the value of inputs from that address. It describes that address's participation, not necessarily the intent of a wallet or a payment between two people. Multi-input transactions and change outputs make those interpretations unreliable.
The displayed network fee is the fee for the entire transaction. A fee rate can be derived from that fee and virtual size. Neither value should automatically be assigned in full to a participant in a transaction with multiple owners.
The recent-history endpoint is paginated. The initial view is limited to up to 25 confirmed transactions and up to 50 unconfirmed transactions; older confirmed pages are loaded on request. Exports preserve the loaded scope rather than claiming a complete lifetime history.
05. Observation and alerts
Alert rules compare successive observations made while the page is open and visible. The user can enable incoming-activity, outgoing-activity and first-confirmation alerts, and choose a network-fee target.
The first observation establishes context. Subsequent observations can identify newly seen activity or a change in confirmation state. A fee rule becomes relevant when the provider's current high-priority recommendation is at or below the chosen threshold.
These checks are conditional on the browser, network and provider being available. They are not a complete event stream: activity may occur between observations, a transaction may be replaced, or the device may be asleep. Local notices and optional browser notifications communicate observations without triggering a transfer.
06. Trust boundaries
The wallet
The wallet remains the authority for keys and transactions. Satquay's supported extension flow requests an address and checks its network. It does not request signatures or broadcast a payment.
The provider
The public data service can be delayed, unavailable or wrong. Different nodes may observe different mempools. Fee recommendations are estimates, and confirmations can change during a chain reorganization.
The browser
Local storage is a convenience, not an encrypted vault or a durable backup. It can be cleared, unavailable or read by software with access to the browser profile. Exported files contain public addresses and potentially identifying labels.
The query
Public blockchain data does not make a lookup private. A service receiving the query may associate an address with connection metadata. Satquay makes no anonymity claim.
Visibility is the outcome. The product does not promise theft prevention, loss protection, transaction finality, continuous alert delivery or recovery of funds. The limits page is part of this product specification.
07. References
- Mempool REST API — public address, transaction, network and fee data.
- Esplora HTTP API — address statistics, transaction formats, UTXO records and history pagination.
This paper describes the current application. It is not a token offering, an audit report or a promise of future functionality. Satquay is independent of the services named here.
For the practical workflow, start with the documentation.
Read the guide