Crays$prism API
$prism API sits at the strange but useful edge where a Nostr event can gather people, a Lightning address can make them payable, and a payment API can turn that crowd into a split-zap product surface.
The payment tool hiding behind a small logo
$prism API is one of those entries that looks tiny on an ecosystem map and then opens into a much more interesting question. The label sits in the Developer Tools and Libraries row, but the visible product is not only an API page. MakePrisms also runs a Nostr Zap App and a Discord Zap Bot. Together, those surfaces point at the same idea: use Bitcoin payments as programmable social infrastructure, not only as one invoice at a time.
The public API page says the pitch plainly: apply for API access and offer one-click, instant global payments with a few lines of code. The Apps page says the Discord Zap Bot enables one-click Bitcoin payments inside a Discord server. The Nostr Zap App says it can create multiparty prisms and zap hundreds of Nostr users instantly. Those claims are short, but they are enough to classify the project. This is not a social feed. It is a payment and developer tool with a Nostr-facing app.
The word prism is doing real product work. A prism is a split: one payment surface, many recipients. In Nostr terms, that means a post, list or interaction can become a payment set. In Bitcoin terms, it means the sender needs a way to pay many Lightning addresses without manually building a spreadsheet of invoices. In developer terms, it means an API can package that behavior for other products.
What the public app actually does
The live app at app.makeprisms.com gives the clearest public description. It lists four $prism tags: `$boost`, `$comment`, `$like` and `$list`. A user can type a $prism tag in any kind 1 Nostr event on any client to initiate a prism. The app says the prism is created from the first mention of the tag, and that only users with a Lightning address are included. That is a very specific mechanism, and it keeps this project anchored in normal Nostr behavior rather than a private social graph.
The create screen offers the manual version: create a prism with any Nostr Event ID, choose a prism type, optionally add a listr, choose how many users to include, and submit a zap split. The zap screen offers the other side: zap a note with a Nostr Event ID. The home screen says the prism posts once it is full or after 12 hours, and it names clients that support paying zap splits, including Snort, Amethyst and Zapper.
That means the core user journey is not complicated to explain. A Nostr event gathers a set of people: people who repost, comment, like, or appear on a list. The prism turns that set into recipients, filters for Lightning-address availability, and creates a split-zap target. A payer can then send value to the set rather than to one account. The simplicity is the appeal. The risk is that every step depends on correct event lookup, correct list interpretation, correct Lightning address discovery and correct payment splitting.
Why kind 1 events matter here
The app explicitly references kind 1 events. In Nostr, kind 1 is the ordinary short text note defined by NIP-01's basic event model and used by most social clients. That is a clever choice because it does not ask the user to enter a special MakePrisms-only publishing environment. A user can write a normal public note in a normal client, include the $prism trigger, and let MakePrisms watch for or resolve the event.
That choice also creates product ambiguity. A normal kind 1 note is public, relay-dependent and client-rendered. If a user edits their intent only by posting another note, the original event still exists. If a relay misses the event, a watcher may not see it. If people interact across different relay sets, the participant set may differ depending on where the service reads. These are not reasons to dismiss $prism. They are reasons to explain why event sourcing matters.
The safest reading is that MakePrisms treats Nostr as a public coordination layer. It does not need to own the feed. It needs to observe a note, understand a tag, fetch reactions or comments, resolve Lightning addresses and then produce a payment object. That is a real Nostr-native pattern: social state becomes payment routing input.
Lightning addresses are the gate
The live app says only users with a Lightning address will be included in a prism. That sentence is small but decisive. $prism does not magically pay every Nostr pubkey. It needs a payment endpoint. In the current public model, that endpoint is a Lightning address. The Lightning Address site describes the idea as sending money in a familiar email-like form, backed by LNURL-pay behavior.
For a split-zap product, this is practical. Nostr profiles commonly include `lud16` or `lud06` payment fields, and NIP-57 zap flow starts by resolving a recipient's LNURL-pay endpoint or Lightning address. But it also means inclusion is not only about social participation. A person may like or repost the note and still be excluded if the service cannot find a usable address. That is fair if disclosed; it would be unfair if hidden.
There is also a privacy and identity angle. A Lightning address is more human-readable than a node invoice, but it can reveal a payment provider, a username, a domain or a stable public identity. A tool that collects many addresses from Nostr interactions should be judged by how it handles failed lookups, duplicate recipients, address changes, blocked wallets and error reporting. The public app does not expose much of that detail, so the article should name it as a place to test.
The API page is intentionally gated
The MakePrisms API page is not an open cookbook. It says Apply for API Access, links to API Docs, gives an api@makeprisms.com contact and frames the product as superior Bitcoin payments. The docs page itself requires JavaScript to run, which means a plain crawler or reader does not see the method list. That is not automatically bad. Payment APIs often gate access because abuse, liquidity, fraud, compliance and support load are real. But it changes how a researcher should write about it.
A long article should not invent endpoints. It should say what can be verified: there is an API application page, official docs exist at docs.makeprisms.com, MakePrisms presents the API as a way to offer one-click instant global payments, and the public apps demonstrate a split-zap use case. Anything beyond that should be treated as implementation detail to verify with current documentation or direct access.
This makes $prism API different from open libraries such as Alby SDK, NDK or rust-nostr. With those projects, the repository and package documentation carry the article. With $prism API, the public service surface and terms matter more. The reader should understand that they are evaluating an operated payment API, not only a reusable open-source component.
Zap splits are where Nostr payments become social
NIP-57 defines zaps as Lightning payment requests and receipts that can be associated with Nostr users and events. It introduces kind 9734 zap requests and kind 9735 zap receipts, and it tells clients how to request invoices, validate zap metadata and display receipts. That is the foundation $prism builds near. A normal zap points at one recipient or one event. A prism asks what happens when a post or interaction set becomes the recipient group.
The public app names clients that support paying zap splits. This is important because $prism does not need every Nostr client to understand a new event kind before the payment can happen. It needs a compatible payment client at the moment of payment. That is why Snort, Amethyst and Zapper are named in the app. They are not only social clients in this context; they are payment interfaces.
The design is attractive for community rewards. You could reward the first people who boost a launch note, split a tip across contributors on a list, send a small thank-you to commenters, or create a contest around a public post. The caution is just as obvious: any system that pays people for liking, commenting or reposting can create incentive games. If the money is meaningful, people will optimize for inclusion.
Discord Zap Bot is not a side note
The Apps page places Discord Zap Bot above the Nostr Zap App. It says the bot can be added to a Discord server to enable one-click Bitcoin payments. That matters because MakePrisms is not only building for Nostr-native users. It is taking a Bitcoin payment primitive into an existing community platform where many creators, projects and support groups already live.
The tradeoff is different inside Discord. A Discord bot needs server permissions. It may see users, messages, commands or channel context depending on how it is installed. It can give a community an easy payment surface, but it also adds an operated bot and Discord's platform policies into the trust chain. For a Nostr-first reader, that is a useful reminder: open payments often move through very closed rooms.
The best interpretation is that MakePrisms is trying to make payment distribution feel native where people already gather. In Nostr, that means event IDs, tags, zaps and Lightning addresses. In Discord, that means bot-driven actions. The API then sits above both, offering a developer-facing way to build similar payment surfaces.
What MakePrisms appears to operate
The public footer names MakePrisms, Inc. and the API page lists api@makeprisms.com. The site has Terms of Service and Privacy Policy links, and the API page has API Terms. The visible product is therefore not a loose hobby script. It is operated by a company with public web properties, a docs domain, an application domain, a Discord app link and a contact path for API access.
That is useful for adoption and important for risk. Payment products are not only code. They involve uptime, support, abuse handling, policy, terms, wallet integration, logs and dispute handling. When an app says it can zap hundreds of Nostr users, the operator's reliability becomes part of the experience. When an API says one-click global payments, the developer should read the terms before building a business dependency on it.
A good Crays article should make that visible without being unfair. MakePrisms is not claiming to be a decentralized protocol by itself. It appears to be an operated payment product using Nostr and Lightning primitives. That can be exactly what the market needs in some places, as long as the operated boundary is clear.
Where NWC fits and where it does not
The $prism API entry appears on the NWC ecosystem map, and NWC matters to the broader payment story. NWC lets apps connect to wallets, request payments through relays and avoid taking custody of user funds. If a future or private $prism integration lets a user connect a wallet through NWC, that would fit the map's theme perfectly. The current public $prism pages, however, are more explicit about Lightning addresses, zap splits and API access than about a direct NWC implementation.
That distinction is important because the user warned not to dump everything into NIP-47. $prism API should not be described as "just NWC." Its real public face is split zaps and one-click payments. NWC is the ecosystem neighborhood, not the whole identity. The same caution applies to many projects on the map: a wallet-connect relationship does not erase the product's actual function.
The right routing is therefore Developer Tools, with links back to Wallets and NIP-57. A builder deciding whether to use $prism API cares about API access, terms, payment flow, supported wallets, recipient discovery and app integration. A NIP-47 explainer alone would not answer those questions.
Risk one: beta money should stay small
The live app says plainly that $prism is still beta software and users should stick to smaller zaps. That warning belongs near the top of any serious article. It is not a tiny disclaimer. It is the operator telling users not to treat the app like a settled payment rail for large distributions.
Beta risk in this context has several layers. A recipient set may be wrong. A Lightning address may fail. A split may be malformed. A client may misunderstand the payment object. A payer may believe a payment is going to one set of people when the actual recipient list differs. A relay may miss an event. A person may be excluded because they lack a Lightning address. None of that has to be catastrophic if the sats are small. It becomes serious when the amount grows.
The healthy user behavior is simple: test with tiny payments, inspect the recipient list, use clients that clearly show the split, and do not treat $prism as proof that everyone in a public interaction was paid. Treat it as a useful payment experiment with explicit beta limits.
Risk two: engagement incentives can get weird fast
A tool that pays the first people who repost, comment or like a note can be fun. It can also train the room to chase payments. The $boost, $comment and $like patterns reward public interactions. In a small trusted group, that might be a charming way to thank people. In a large public feed, it can attract bots, low-quality engagement and people optimizing for eligibility rather than meaning.
This is not a MakePrisms-specific problem. It is the general problem of money entering social metrics. Nostr makes it easier to tie identity, events and Lightning together. That power needs taste. A creator can use $prism to reward useful early supporters. A spammer can use the same idea to buy engagement. The tool does not decide the culture by itself.
For Crays, the right recommendation is to frame $prism as a community payment instrument, not a growth-hacking toy. Use it where the recipient set has meaning: contributors, event participants, early testers, a known list, or a carefully bounded public prompt. The product gets weaker when it turns every like into a lottery ticket.
Risk three: docs and code visibility
The public MakePrisms pages are compact. The docs app requires JavaScript. A public GitHub repository did not appear in the immediate research trail. That does not mean the service is unsafe. It means the trust model is different from open-source Nostr tools where the code, releases and issue history are central evidence.
A developer considering $prism API should ask for current API docs, pricing, rate limits, custody model, supported wallets, error semantics, logging policy, refund behavior, abuse controls and terms. If the product is used only for small community zaps, a lightweight review may be enough. If it is used in a commercial workflow, the review should be stricter.
The same applies to the Discord bot. Server administrators should check what permissions the bot asks for, which channels it can read, what commands it exposes and how payment actions are authorized. A one-click payment bot is useful only when the click is understandable.
How to test it responsibly
Start with the public Nostr Zap App, not the API. Create a test note from a low-stakes Nostr account, use a $prism tag, keep the recipient limit small and make sure the people involved have Lightning addresses. Then inspect the created prism and pay only a tiny amount with a client that clearly displays the split. The goal is to understand the flow, not to impress anyone with the amount.
Next, test edge cases. What happens if a participant lacks a Lightning address? What if a list contains a duplicate? What if the event ID is wrong? What if reactions come from relays the app does not see? What if the prism fills after several hours? Does the app explain the final recipient set before money moves? These are the questions that separate a fun demo from a reliable payment tool.
If you are evaluating the API, do not skip the boring questions. Ask for current docs and terms, then build a tiny internal prototype that logs every step. Confirm how errors are returned. Confirm whether payments are pushed directly, routed through a connected wallet, or mediated by MakePrisms infrastructure. Confirm who pays fees and how failed recipients are handled. A payment API earns trust through boring answers.
Why it belongs on the app hub
$prism API belongs on the Apps hub because it shows one of the most important Nostr product patterns: a public social event can become input for a payment workflow. That is bigger than tipping. It turns participation, lists and replies into programmable recipient sets. Used well, that can reward communities, contributors, creators and small campaigns in ways that ordinary social platforms do not support.
It also belongs in Developer Tools because the public API page is aimed at builders. The right reader is not only the person clicking a zap button. It is the developer asking whether they can add one-click Bitcoin payments to a product, the community organizer asking whether a Discord server can pay contributors, and the Nostr creator asking whether public engagement can be rewarded without exporting usernames to a spreadsheet.
The honest conclusion is balanced. $prism is promising, narrow, and still beta at the public app layer. Its public docs are not as inspectable as major open-source libraries. Its payment behavior depends on Lightning addresses, clients and server-side operation. But the idea is strong enough to deserve a real page: split-zap infrastructure is one of the places where Nostr stops being only speech and starts becoming a programmable value network.
Sources worth opening
The public paper trail is smaller than for major open-source clients, so this article stays close to official MakePrisms pages, the live Zap App, Nostr zap specifications, Lightning Address/LNURL material and the client surfaces the app itself names.
- MakePrisms API page
- MakePrisms Apps page
- $prism Nostr Zap App
- $prism create screen
- $prism zap screen
- $prism API docs app
- Nostr Wallet Connect ecosystem page
- NWC developer documentation
- NIP-47 Nostr Wallet Connect
- NIP-57 Lightning Zaps
- NIP-01 basic event model
- NIP-19 encoded Nostr entities
- NIP-51 lists
- Lightning Address site
- LNURL LUD-06 pay request
- LNURL LUD-16 Lightning Address identifier
- Snort
- Amethyst
- Zapper
- Zapper Nostr app
- nostr-protocol/nips repository
- Nostr protocol site
- Nostr.com overview
- NostrApps directory
- LNURL specifications repository
