Developer resources
Small surface.
Clear contracts.
Public APIs, local tools and clear contracts for Bitcoin data and calculations.
What exists today
The API provides liveness, dependency readiness, and read-only Bitcoin mainnet explorer endpoints. Wallet creation runs locally on the dedicated generator pages; wallet transaction signing is not provided. The separate tools API catalog documents the current tool contracts.
GET /api/v1/health
HTTP 200 · {"status":"ok"}
Liveness of the API process.
GET /api/v1/ready
HTTP 200 · {"status":"ready"}
HTTP 503 · {"status":"unavailable"}
PostgreSQL and Redis readiness.
A deliberate architecture
Marketing pages use plain HTML and CSS. The explorer uses a page-specific native JavaScript module at its existing public URL. The backend is a Rust modular monolith; PostgreSQL stores durable application data and Redis handles temporary cache data.
Tools backend integration
The separate tools backend publishes its contracts at GET /api/v1/tools. Secret-handling tools are local-only. Tool forms run Rust/WASM locally or call public mainnet APIs. Signed transaction submission requires a separate review and explicit confirmation; brain wallets are education only.
One origin for the application
The local development stack serves the site and proxies API requests through the frontend origin. API credentials stay server-side. The browser must never receive database connection secrets.
Read-only explorer API
GET /api/v1/explorer/overviewGET /api/v1/explorer/marketGET /api/v1/explorer/search?q=…GET /api/v1/explorer/blocks/{id}?offset=0GET /api/v1/explorer/transactions/{id}GET /api/v1/explorer/addresses/{id}GET /api/v1/explorer/addresses/{id}/transactions?after=…
Mainnet snapshots carry source and update time. Amounts are exact decimal satoshi strings. Lists are bounded to 25 entries per page. Requests have timeouts and rate limits; unavailable or malformed upstream data returns an explicit error.