Community

Wallets / Signals

Zap Goals, Leaderboards and Public Money Games

When zaps become goals, rankings and games, money becomes a social signal. That can fund good work, but it also needs careful product language before status swallows context.

Zap Goals, Leaderboards and Public Money Games visual
Wallets Signals Value, permission, custody and proof before the next payment.
Wallets794 wordsSignals

Zap Goals, Leaderboards and Public Money Games

When zaps become goals, rankings and games, money becomes a social signal. That can fund good work, but it also needs careful product language before status swallows context.

Visible support changes behavior

A private tip thanks someone. A public zap changes the room. When a post shows who supported it, how much moved and which comments carried money, attention starts to organize around value. That can be wonderful. It can also become theater.

Zap goals and leaderboards take that effect further. They turn small payments into a campaign, a scoreboard or a community game. A writer can fund a long essay. A developer can raise sats for maintenance. A streamer can unlock a segment. A venue can run a playful contest. A Crays award or voting game can turn fan attention into direct income.

The product challenge is to keep the signal useful. Money is a signal, not the only signal. A page that treats zap totals as absolute truth will mislead people. A page that explains what the total means, where it came from and what it buys can be genuinely useful.

What zap goals are trying to solve

Creators need ways to ask for support without turning every relationship into a subscription. Communities need a way to fund maintenance without heavy governance. Small projects need a public trail that says: this work has people behind it. Zaps are a natural fit because they are lightweight and already tied to Nostr identity.

A goal gives the payment a story. Twenty thousand sats for a new episode. Five hundred thousand sats for a conference livestream. A recurring monthly target for a relay. A bounty for documentation. The amount turns support into a shared object rather than a private receipt.

The trap is ambiguity. Is this a donation, a purchase, a vote, a pre-order, a membership fee or a game entry? Those are different legal and social promises. The page must say which one it is.

Leaderboards need context

Leaderboards are fun because they make invisible support visible. They are also dangerous because humans love rankings too much. A leaderboard can reward generosity. It can also reward flexing, coordinated promotion or status buying.

A serious leaderboard should show the measurement window, the counted event type, the currency unit, the included relays or wallet source, the update cadence and whether refunds, failed payments or suspicious activity are handled. Without that, a leaderboard is decoration with money attached.

For Crays, this matters because awards, community games and creator campaigns may use zap-like signals. If money influences visibility or status, the game rules have to be clearer than the visual excitement.

NIP-75 and the shape of goals

NIP-75 sits in this neighborhood because it gives zap goals a standardized shape. The details can evolve, but the need is stable: clients need a way to understand that a target, amount, beneficiary and context belong together. Otherwise every app invents a private campaign format and the signal becomes trapped again.

A standard goal can be discovered by different clients, displayed in different interfaces and linked back to the same identity. That is the Nostr pattern: the event is public and signed, while products compete on making it useful.

The practical point is not that every campaign must use one NIP forever. The point is that fundraising, goals and visible payment targets need shared grammar before they can become portable.

What can go wrong

Zap games can incentivize spam, shallow content and status chasing. They can also make people feel pressure to pay publicly when private support would be healthier. A creator can misstate what a goal funds. A client can double-count receipts. A relay can miss events. A wallet can produce payment records that the social client never sees.

None of this means zap goals are bad. It means public money needs plain labels. Donation. Tip. Vote. Purchase. Entry. Sponsorship. Bounty. Campaign. If the label is fuzzy, trust erodes fast.

Designing a good money game

A good money game shows the goal, the reason, the beneficiary, the time window, the wallet or receipt source, the rules, the refund stance and the social meaning of a zap. It does not pretend every sat carries the same moral weight. It does not hide the wallet path. It does not turn a payment into a promise the creator never made.

The best version feels light on the surface and exact underneath. People can play, support and cheer without reading a contract. If they do read the details, the details hold up.

How to read zap totals

Treat zap totals as energy, not audited revenue. They show that people engaged with money in public. They do not automatically prove profit, settlement, tax treatment, campaign fulfillment or long-term trust.

When a page uses zap totals to rank, reward or sell, open the details. If the details are clear, enjoy the game. If the details are missing, assume the signal is interesting but incomplete.

Sources worth opening

Open these when you want the specification, product documentation or implementation trail behind the article.

Useful next pages

Back to Wallets
A digital finance dashboard for wallet permissions, invoices and payment state.
People discussing self-custody and wallet decisions in a finance setting.
A team table where payment permissions and custody decisions become concrete.
Digital asset community energy around Bitcoin value movement.
An open doorway through technical diagrams for portable wallet access.

A goal turns a zap into a public promise

A zap can be a small thank you. A zap goal is heavier. The moment a page says this many sats are needed for this outcome, money becomes attached to a promise: a trip, a release, a livestream, a relay bill, a bounty, a repair, a translation, a public experiment. NIP-75 defines that promise as a `kind:9041` event with a human-readable description, target amount in millisats and relays where zaps to the goal will be sent and tallied. It can include a closing timestamp, image, summary, linked URL or addressable event, and multiple beneficiaries through zap tags.

That little structure matters more than it looks. A target amount tells you what success means. A relay list tells clients where to count. A closing time prevents old receipts from endlessly changing the story. A summary helps the goal travel across clients without losing meaning. Multiple beneficiaries let a campaign avoid pretending that one person receives everything. The protocol gives product teams enough structure to make a fundraiser understandable, but not enough to solve trust by itself. The page still has to explain what happens when the goal is reached, missed, overfunded or disputed.

Goals need cleaner language than zaps

Words matter because a goal can look like several things at once. It may be a donation campaign, bounty, pre-order, event ticket, sponsorship, vote, prize pool or community challenge. Those are not interchangeable. A donation does not guarantee delivery. A bounty needs acceptance criteria. A pre-order needs fulfillment. A vote needs rules. A sponsorship needs placement. A prize pool needs custody and payout language. If a Nostr app calls all of those zaps, you will not know what you bought, funded or signaled.

This is where magazine-style wallet writing becomes useful. The article should not just explain the event kind. It should teach you how to read the social contract. Who created the goal? Which event is it tied to? Which relays are used for receipts? Is the amount displayed in sats while the protocol target is in millisats? Who receives the money? Is there a closing timestamp? Is the goal connected to a public work item, stream, product page, GitHub issue, artist release or community decision? If the page cannot answer those questions, treat the goal as social support, not a purchase.

Leaderboards change the room

Zap goals often arrive beside leaderboards. That can be joyful. A live room becomes electric when support is visible. A writer sees that an essay mattered. A developer gets a maintenance bounty without opening a corporate grant process. A musician can test fan demand before a release. But ranking money also changes behavior. Wealth can dominate attention. Friends can inflate each other. A public total can make a weak project look legitimate. A goal can pressure creators into public performance rather than slower work.

The right design is not to hide money. It is to contextualize it. Show totals, but show source and meaning. Let the visitor see whether zaps are direct support, campaign funding, purchase intent, contest ranking or applause. Keep non-monetary signals visible too: identity history, comments, source links, delivery updates, reputation, prior work and moderation context. A good goal page feels alive without making the richest participant the narrator.

Zap goals in Crays-style products

For Crays, zap goals become interesting around creator funding, awards, hospitality events, fan access, venue campaigns and product launches. The temptation will be to make everything feel like a game. Resist the vague version. A high-quality goal says what the money does, which wallet receives it, how the total is counted, which deadline applies, what visitors get back emotionally or practically and where updates will appear. If a goal unlocks access, connect it to a real access record. If it funds work, show progress updates. If it supports a person, keep the language honest: support, not entitlement.

NIP-57 gives the zap request and receipt chain. NIP-75 gives the goal container. NWC can make paying smoother when the visitor has a scoped wallet connection. Together they can build the small-money campaign layer Nostr has been circling for years. The quality bar is not technical novelty. It is whether you can look at the goal and understand the promise before you send sats.