Metrics / zapstore / zap_count

zap_count

Counts kind-9735 (zap-receipts) zap receipts attributed to a Zapstore app per UTC day - receipts, not distinct zappers, recipients or apps: one zapper funding ten apps contributes ten rows, and one app recurs across many days.

unit

zaps

grain

day (UTC)

series

sparse, full history

key

zapstore.zap_count@day

Parameters

param	accepted values
grain	day - default day (omit to get the default)
from	optional inclusive ISO UTC calendar day (YYYY-MM-DD); omit for the series start
to	optional inclusive ISO UTC calendar day (YYYY-MM-DD); omit for today UTC (that day still in progress)
format	csv \| markdown

Query it

MCP tool call against https://dev.nostrolo.gy/mcp (connect your agent):

{
  "name": "nostrology_query_metric",
  "arguments": {
    "metric": "zap_count",
    "domain": "zapstore",
    "grain": "day"
  }
}

Windowed (inclusive UTC days; both optional):

{
  "name": "nostrology_query_metric",
  "arguments": {
    "metric": "zap_count",
    "domain": "zapstore",
    "grain": "day",
    "from": "2026-07-01",
    "to": "2026-07-31"
  }
}

Response: a plain-text envelope (window, freshness, column contract, this page's caveats) followed by the data table (csv, or format: "markdown") at day grain.

Response columns

name	type	description
utc_day	date	UTC calendar day (bucketed at UTC, not session TZ)
zap_count	integer	Zapstore-attributed zap receipts on that day

What is counted

'Zapstore-attributed' means the receipt carries a top-level a-tag naming a kind-32267 (zapstore-app-catalog) app entry ('32267:<dev_pubkey>:<app_d_tag>'). This is a derived SUBSET of the full kind-9735 (zap-receipts) corpus, not all zaps reaching app developers: a zap sent to the same developer without that tag is not counted here.

Caveats

For the AMOUNT zapped rather than the number of zaps, use zapstore.zapped_msats over this same set of receipts - the two are the count and the sum of one population, so neither bounds the other.
The series' earliest day is a FABRICATED receipt, not real activity: event 778150ee... (2025-06-06, 100,000 sats) embeds a zap request whose id is the literal string 'demo-zap-request' - so it fails id == sha256(serialized) - carries a demo bolt11 invoice, and has sender == recipient == LNURL signer. It is the ONLY receipt before 2025-09-03, so the series opens with a single unreal point followed by a ~3-month gap; exclude it from any all-time figure (audited 2026-07-27).
Attribution is to the APP, not to a developer's earnings: measured 2026-07-30, 20.9% of this series' all-time sats went to the Zapstore curator/indexer account rather than to independent developers, so 'zapped to Zapstore apps' is accurate while 'zapped to developers' is roughly four fifths of the total. (A 2026-07-27 audit measured ~22% over the trailing-365-day window the chart shows - the share differs by denominator, so state which one you mean.) The placeholder app com.example.empty (2 receipts, 121 sats) is likewise included - this series is defined as what the table holds, not as a curated subset.
Measured acquisition loss is ~0.22% and one-directional (undercount): a 2026-07-27 cross-relay audit found 2 of 904 in-window receipts absent from both Postgres and the S3 archive, and the archive was otherwise a strict superset of relay.zapstore.dev's a-tagged receipts.
To reproduce nostrology-web's 'Zapstore Zaps' chart from this series: keep receipts whose created_at is within the last 365 days - a TIMESTAMP cutoff, not a calendar-day one, so the oldest day the chart shows is PARTIAL and its value is below this series' value for that same day - then densify missing days to zero, and plot zap_count as bars against the running sum of zapped_msats (converted to sats once, at the end) as the cumulative line. A whole-day trim instead of the timestamp cutoff silently over-counts that one boundary day and shifts every point of the cumulative line. The chart's window also excludes the fabricated 2025 receipt above, which is why its totals are lower than this series' all-time sum.
Series is sparse: days with zero Zapstore-attributed zaps are omitted.

Freshness in every response is data-derived: latest kind-9735 (zap-receipts) Zapstore-attributed event time.