Metrics / zapstore / zapped_msats
zapped_msats
Sums the amount of kind-9735 (zap-receipts) zap receipts attributed to a Zapstore app per UTC day, in MILLI-satoshis (msats) - divide by 1000 for sats. Counts amounts, not zaps: for the number of receipts behind these amounts use zapstore.zap_count over the same population.
unit
msats
grain
day (UTC)
series
sparse, full history
key
zapstore.zapped_msats@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": "zapped_msats",
"domain": "zapstore",
"grain": "day"
}
} Windowed (inclusive UTC days; both optional):
{
"name": "nostrology_query_metric",
"arguments": {
"metric": "zapped_msats",
"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) |
| zapped_msats | integer | Milli-satoshis zapped to Zapstore apps that day (divide by 1000 for sats) |
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
- The unit is msats, NOT sats. When aggregating, SUM the msats first and convert once at the end - never round per day and then add. Every amount in the table is currently a whole number of sats (916 of 916, measured 2026-07-30), so today either order gives the same answer, but Lightning permits sub-satoshi amounts and per-day rounding would then drift from the true total.
- Amounts are bolt11-derived from the receipt itself. The column is nullable and a NULL is counted as 0 rather than dropped, matching the chart this reproduces (measured 2026-07-30: no NULLs present).
- 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). That single receipt is 100,000,000 msats, which distorts this series far more than it distorts zap_count: it is one row there, but several percent of the all-time sum here.
- 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 (there is no day with receipts but a zero amount today, but such a day would appear here with a 0).
Freshness in every response is data-derived: latest kind-9735 (zap-receipts) Zapstore-attributed event time.