NIP-75: Zap Goals
Zaps can fund a target, not only reward a post
A zap is a payment action. A goal gives that action a destination with progress. NIP-75 creates a fundraising object so people can zap toward a target amount and clients can display progress.
The standard fits open-source funding, event travel, creator support, live-stream goals, article bounties and community campaigns. It is deliberately simple: describe the goal, name the target amount, list the relays where zap receipts needs to be counted.
That simplicity matters because fundraising clients can build richer UI without every campaign inventing its own event format.
Kind 9041 with amount and tally relays
A zap goal is kind 9041. The content field is the human-readable description. Required tags are amount, expressed in millisats, and relays, listing where zaps to the goal are sent and tallied.
Optional tags include closed_at, image and summary. A goal may include URL or addressable-event references, and multiple beneficiaries can be represented with NIP-57 zap tags.
Addressable events can point at a goal with a goal tag. That lets a long-form article, live stream or project page show a related funding target.
A compact NIP born from the zap era
Alejandro added the visible Zap Goals NIP in September 2023. In November 2023, optional image and summary tags were added. Later changes were mostly terminology and formatting cleanup as the repo moved to addressable-event language.
The NIP has stayed small because it delegates payment verification to NIP-57. A goal is not a payment rail. It is the public object that tells clients which zaps to count.
That is the correct separation of concerns, but it means bad zap verification will also damage goal progress.
The progress bar is a verification problem
A client needs to tally only valid NIP-57 zap receipts and needs to use the relays declared by the goal when constructing zap requests. It needs to also respect closed_at so late receipts do not keep changing a finished campaign.
Funding products such as Geyser-style pages, community goal widgets and creator profiles are the natural use cases. A clean UI shows target, received amount, remaining amount, close time, beneficiaries and the receipts used for the tally.
The most important implementation detail is honesty: if the client could not query all tally relays, the progress number may be incomplete.
Fundraising needs trust cues
A public funding goal can be misleading if the beneficiary is unclear, zaps are miscounted or old receipts remain in progress after closure.
Clients need to show who created the goal, who benefits and which receipts were counted. Otherwise a goal becomes a polished donation button with weak accountability.
Read NIP-75 in the wild
NIP-75 makes zap goals visible. A fundraiser, creator project or public-good campaign can describe a target and connect value signals around it.
A progress bar can look more authoritative than it is. Show what counts, which receipts are included, whether payments settled and whether the goal is a social signal or an accounting record.
What changes when you actually use it
For you, NIP-75: Zap Goals is felt at the moment value moves or appears to move. The interface may show a zap, offer, wallet connection, token, invoice or result, but the source terms kind 9041, draft, kind:9041, .content, amount, relays decide what can actually be proven. Read the money path before the visual reward path.
What changes for builders and operators
For builders, NIP-75: Zap Goals means separating money truth from social display. Budgets, invoices, mints, wallet services, receipts and settlement need their own status language. A delightful payment animation is harmless only after custody, limits and revocation are legible.
What the official file makes concrete
The official file is organized around Nostr Event, Client behavior, Use cases. Inspect kind 9041, draft, kind:9041, .content, amount, relays, closed_at, image because these are the pieces most likely to surface as product behavior.
NIP-75: Zap Goals needs sharper warnings than a normal social feature. Custody, invoices, receipts, budgets, mints and settlement determine whether money really moved.
Where it breaks
The failure mode in NIP-75: Zap Goals is believing the social signal more than the payment proof. A zap can be visible while settlement is incomplete, a wallet connection can outlive trust, a mint can fail, and a listing can look professional without escrow or reputation.
Where this appears outside the markdown
In the ecosystem, NIP-75: Zap Goals sits near wallets, Lightning, Cashu, offers, receipts, jobs, goals or marketplaces. These features are exciting because value becomes visible inside social context, but they are also unforgiving. A page about value has to separate the social object from the financial fact before the design turns trust into decoration.
The nearby-standard trap
The nearby-standard trap in NIP-75: Zap Goals is calling every money-adjacent event a payment. Zaps, wallet connections, Cashu proofs, nutzaps, offers, orders, goals and data jobs each prove different things. Read NIP-01 and the adjacent source links before a UI turns a signal into an accounting claim.
Language that keeps the feature honest
Good product copy for NIP-75: Zap Goals names the money state. It separates request, invoice, payment, receipt, token, mint, budget, listing, order and settlement. That is how a delightful wallet or marketplace surface stays honest.
What this page does not promise
NIP-75: Zap Goals does not turn a social signal into settled money by itself. A zap, wallet connection, listing, token, receipt or job request can be displayed beautifully while custody, settlement, refund, invoice expiry or mint risk remain unresolved. Read NIP-01 and the adjacent source links before trusting any value flow that hides who controls funds or which proof actually exists.
Read it as a field test
Start NIP-75: Zap Goals with the money state, not the animation. Identify whether kind 9041, draft, kind:9041, .content, amount, relays represent a request, permission, invoice, token, receipt or listing. Then read the nearby standards and source links so custody, settlement, budget and proof are not collapsed into one cheerful payment label.
Where the standard earns trust
The source links give you places to test the interpretation in public: nips.nostr.com NIP-75, NIP-57 Lightning Zaps, Geyser, Nostr.how zaps guide. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-75 source is the anchor for exact wording, and NIP-75 commit history shows how that wording moved over time. The strongest secondary clues here are nips.nostr.com NIP-75, NIP-57 Lightning Zaps, Geyser. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-75: Zap Goals: first the human promise, then kind 9041, draft, kind:9041, .content, amount, relays, then the implementation record, then the real-world failure case. That order keeps NIP-75 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- What is being proven: a request, invoice, payment, receipt, token, listing, wallet permission, mint promise or job result?
- Who can spend, revoke, refund, censor or lose the funds if the service disappears?
- Does the product separate social visibility from financial settlement before you trust the flow?
What to verify before you rely on it
- Find
kind 9041,draft,kind:9041,.content,amountin the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-75 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-75: Zap Goals in that order: Official NIP-75 source for the current wording; NIP-75 commit history for the change record; nips.nostr.com NIP-75, NIP-57 Lightning Zaps, Geyser for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
