Three Nostr identities, a working zap-attribution pipeline, 44 articles live, and after 30 days exactly zero zaps. What I learned about V4V on a small technical blog.

Building Per-Article Zap Tracking on Nostr, and Then Getting Zero Zaps

8 min read
strategysovereign-ai

Coming from outside the stack? The Self-Hosted AI: Start Here hub article maps where strategy decisions like this one land in the actual deploy: hardware tree, inference engine, what hurts most. Useful as the operational anchor for the framing here.

Thirty days, three Nostr identities, 44 articles live, zero zaps received. That is the actual data this post reports on. The infrastructure to attribute zaps per article is built, tested end-to-end, and currently routing no traffic. Whether that result kills the V4V hypothesis on a small technical blog or just delays it is the harder question this post tries to answer honestly.

Quick Take

  • Three Nostr identities (cipherfox, blog, hexabella) shipped, each with NIP-05 verification and Lightning routing
  • Per-article zap aggregator designed on top of the existing NIP-22 comment infrastructure, ~30 minutes of additional work
  • 30-day result: zero zaps across all three identities, all 44 articles
  • Test zap from my own Alby ↗ account registers correctly, so the pipeline is not broken
  • Honest read: V4V on a small technical blog is a distribution problem, not a plumbing problem
  • 60-day decision tree at the end: keep, pivot, or retire the infrastructure

What I expected versus what happened

I built the attribution pipeline before I had any zap data, on the assumption that once a few zaps started arriving I would want to know which articles drove them. The Lightning Address feed shows aggregate sats to cipherfox@sovgrid.org with no per-article split, which I treated as the bottleneck I needed to solve. That assumption turned out to be wrong by an order of magnitude. The bottleneck is not attribution. The bottleneck is that the upstream signal, reader engagement strong enough to produce a Lightning send, has not happened yet on this blog at all.

The 30-day window covers the period from going live with the three-identity setup through the first month of publishing under the new structure. Across all 44 articles live at the end of that window, across the three Nostr identities, across the full Lightning Address infrastructure, the zap count is zero. Not low. Not noisy. Zero.

I am reporting this because shipping a piece of infrastructure and getting a null result is exactly the kind of thing that gets quietly memory-holed on most engineering blogs, replaced with a “future work” hand-wave or a fresh post on the next initiative. The honest data point is more useful than another aspirational one, especially for anyone considering the same V4V experiment on the same scale.

Three Identities, One Clear Signal

The infrastructure ships and works. Three Nostr identities, all verified via https://sovgrid.org/.well-known/nostr.json and backed by local nsec files under /data/secrets/nostr/ with strict permissions. Amber holds the primary signer on a phone for day-to-day use.

Identity 1: cipherfox@sovgrid.org (personal, Stef). This npub publishes journey posts, replies, discussions, introductions. Aliased as _@sovgrid.org for catch-all routing. Tied to my personal identity, kept offline except for curated interactions.

Identity 2: blog@sovgrid.org (dedicated to per-article zap anchoring). This npub exists solely to anchor zaps to specific articles. Each post announces one article and serves as the zap target, so every satoshi sent to this npub lands on the corresponding event. The npub is npub1ymraq90rhan0ep4688j4ygcuh6cnf2f5ca3gl6r2y6kvqfhyn6rsennzhn and its hex is 26c7d015e3bf66fc86ba39e552231cbeb134a934c7628fe86a26acc026e49e87.

Identity 3: hexabella@sovgrid.org (agent persona, planned for live use once NIP-46 Bunker signing matures). Already registered under sovgrid’s NIP-05 to signal it’s an authorized agent, not yet active because the OpenClaw-on-Nostr stack is not production-ready.

Separating identities solves real problems even before zaps appear. With a single account, replies to articles mix with personal updates, so followers see blog spam in their feed and have no way to mute article discussions without muting the whole account. With separate accounts, followers can subscribe to blog@sovgrid.org for curated content and mute the personal feed entirely. If the blog key is compromised, the personal key stays safe, and vice versa.

Aggregation Pipeline: Reuse What Works

The aggregator pattern is already proven in the NIP-22 comment system, so extending it to zaps costs about 30 minutes of extra work. Publish the article, create a dedicated Nostr post under blog@sovgrid.org that announces the article. That post’s event ID becomes the zap anchor. Add the event ID to the article’s frontmatter under nostr_anchor. A cron job on the Floki VPS subscribes to kind 9735 events from the blog npub, aggregates sats per event ID, joins the results with the frontmatter mapping, and outputs /api/zaps.json. The /insights/ page would then fetch that JSON and render a “Most zapped” sorted column.

The aggregator goes live the moment there is non-zero traffic to attribute. Until then it sits in the queue behind work that has more leverage on the actual bottleneck.

What I Chose Not to Build

Client-side zap counters were rejected because nostr-tools adds about 50 KB to the bundle, dropping mobile PageSpeed from 96 to 92. Not worth the marginal benefit at zero traffic.

A “top-3 zapped articles” podium was rejected too, on the rule that podiums with fewer than 10 articles holding non-zero zaps feel demotivating rather than motivating. With the current zero baseline that threshold is not even on the horizon.

Lightning Address zaps are not tracked because they lack article-level attribution and would only add aggregate noise. Gamification (streaks, trophies) was rejected because it does not fit the V4V ethos. Auto-posting article announcements via the pipeline using the nsec key was rejected as a security risk; the announcements get posted manually and the event ID gets inserted afterward, which keeps the private key off the server entirely.

Why the plumbing is not the problem

A test zap from a fresh Alby account to blog@sovgrid.org registers correctly on the relays, lands in the expected event, and would aggregate cleanly if there were others to aggregate. The NIP-05 verifications resolve. The Lightning routing works. The end-to-end signal path is intact.

What is missing is the upstream half of that path. Reader visits the article, finds it valuable enough to act on, opens a Nostr client, and sends a few sats. Each step in that chain has its own conversion rate, and on a small technical blog the cumulative product of those rates is small. With current traffic it rounds to zero in a 30-day window.

The Sovereign Sessions YouTube channel covers similar territory for a similar audience and gets visible Lightning support per video. The difference is not the V4V plumbing on either end. The difference is audience size and active outreach. Sovereign Sessions has a multi-year audience-building head start; this blog is in its first months under the current structure with effectively no outbound distribution effort.

That makes V4V a downstream symptom of an upstream distribution gap, not an independent problem to optimize against. Attribution infrastructure designed for a multi-zap reality is not the bottleneck when reality is zero zaps.

The 60-day decision tree

If after another 60 days of distribution effort (Sovereign Sessions outreach, Nostr cross-posting, Hacker News submissions of the strongest posts) there are still zero zaps across all three identities, the conclusion is that Lightning V4V is not the right monetization shape for this audience and the stack should be quietly retired in favor of either L402 paid-tier MCP calls or the existing affiliate revenue (Floki, Alby, BitBox), which is the only meaningful monetization currently active.

If there is signal in that window, even a handful of zaps from named identities, the infrastructure justifies its operational cost and earns continued attention. The aggregator goes live, the /insights/ page gets the “Most zapped” column, the design decisions in this post hold.

The data window matters more than the design did. Reporting the null result honestly is part of running this stack openly. Pretending V4V is working when it is not would be the kind of silent fabrication that quietly erodes a blog’s credibility, and credibility is the whole product on a self-hosted-AI engineering log.

What I Actually Use

  • Three Nostr identities live with NIP-05 verification, Lightning routing, separate nsec files
  • NIP-22 comment aggregator running, ready to extend to zaps the day there is traffic to attribute
  • Alby ↗ as the test-zap source for verifying the end-to-end pipeline
  • Manual article-announcement posting (no nsec on the server) to keep the private-key surface small
  • 60-day decision window before reconsidering the entire V4V stack

Where to next

If you want the operational stack this experiment runs on top of, the Self-Hosted AI: Start Here hub covers the hardware, the inference engine, and the deploy path that makes any of this possible.

If you came from a Bitcoin context, the Alby Nostr wallet setup is the wallet I use to test-zap into the pipeline. Same wallet I use for receiving on the personal cipherfox@sovgrid.org Lightning Address.

If you want to see how the test-zap signal actually gets visible publicly when the audience side works, the Sovereign Sessions YouTube channel is the outbound benchmark this blog is being compared against. For the Bitcoin-context bridge that fed into this V4V experiment originally, BTCSessions is the tutorial channel that introduced me to Lightning self-custody before any of this stack existed.

If you want the broader pivot context behind this experiment (why V4V plus affiliate is the current monetization shape, what L402 looks like as the fallback if the 60-day decision tree above triggers retirement), the agentic-economy pivot post is the strategic backdrop.