Zaplit
Zaplit takes a familiar group-expense problem and tests a Nostr-native answer: create a group, record a bill, let members connect NWC-compatible wallets, and track who has paid their share.
Zaplit is a group-expense tool
Zaplit is easiest to understand if you begin with a normal travel problem. A group goes to dinner, one person pays the fiat bill, and everyone else owes that person a share. The usual follow-up is awkward: someone saves the receipt, does the math, sends messages, waits for repayment, and keeps checking who has actually settled. Zaplit asks whether that loop can be handled with Nostr coordination and Lightning payments.
That makes Zaplit a finance and payment tool, not a wallet, exchange, social client or relay. It does not try to become your main Bitcoin wallet. It does not publish a public feed. It is closer to a Lightning-native Splitwise experiment: create a group, add bills, calculate shares, and use Nostr Wallet Connect so each member can pay from a wallet they already control.
The current public version should be read as an experimental web app. The live site is reachable, the repository is public, and the project won attention in the NWC hackathon track. At the same time, the code still contains mock bill data, local storage flows and unfinished TODOs. The useful conclusion is balanced: Zaplit is real enough to study, but not mature enough to treat like finished expense-management infrastructure.
The live identity is zaplit.mucu.dev
There are two domains to separate. The current getAlby awesome-nwc list points Zaplit to `zaplit.mucu.dev`, and that site loads a Next.js app with a Zaplit logo, Create Group and Join Group actions. The older Crays card used `zaplit.dev` as its favicon domain, but that hostname does not currently resolve. For a payment-related project, that difference matters because wallet access should follow the working official trail, not an old domain guess.
The Devpost page also links `zaplit.mucu.dev` among the try-it-out targets, alongside GitHub, a Vercel preview and design links. The landing page at `zaplit-landing.vercel.app` repeats the same product idea: split bills with friends and settle instantly through Bitcoin Lightning, with Nostr Wallet Connect as the wallet handoff.
This page therefore treats `zaplit.mucu.dev` as the active public app. If you encounter another Zaplit URL, check it against the GitHub repository, Devpost entry and NWC ecosystem mentions before entering wallet data. A bill-splitting app is allowed to be playful; a wallet-connection prompt is not allowed to be vague.
The public trail comes from Bitcoin++
Zaplit was created for Bitcoin++ Beach Edition in Florianopolis. The Devpost entry names the project as a dead-simple way to split bills using Lightning and Nostr Wallet Connect. It describes the inspiration directly: at events and travel situations, one person often pays locally while others later send sats, which turns into manual math and follow-up messages.
The Bitcoin++ Devpost gallery marks Zaplit as a winner, and Alby's hackathon recap says the event had the first dedicated NWC hackathon track. Alby describes nine projects out of twenty-six integrating NWC, with Zaplit winning 333,000 sats for a Splitwise-like Lightning idea where users can connect their own wallets and automatically split bills.
The NWC Nostr profile repeats that story in public notes, and a separate hackathon winners gist lists Zaplit and Money Badger as best NWC apps. This matters because Zaplit is not just a random one-page demo. It sits in a documented hackathon context where NWC was the point, not an afterthought.
Who is behind it
The repository lives under `lacrypta/zaplit`, and Devpost lists Andrea Diaz Correia, Juan Jose Ramirez, Agustin Kassis and Andres Chapo as creators. Andrea Diaz Correia later wrote publicly about building Zaplit during BTC++, explaining that the idea came from wanting a Splitwise-like experience for Lightning after arriving in Brazil and dealing with local payment friction.
That trail points to a hackathon team rather than a company with a production support desk. You should expect the public artifacts to look like a fast prototype: a real repository, visible commits, a working hosted build, a clear README and some unfinished edges. That is normal for a hackathon project and important for expectations.
A user should not infer ongoing operational guarantees from the prize alone. Prize context tells you the idea and integration were taken seriously at the event. It does not tell you the app has audited security, a maintained help channel, long-term uptime promises or a production privacy policy. The operator question remains part of due diligence if you intend to use it beyond tiny tests.
What the app looks like today
The live home page is intentionally minimal. It shows the Zaplit logo, the line `Split bills using zaps`, and two actions: Create Group and Join Group. The create flow asks for a group name. The join flow opens a QR scanner. The settings page has a user name field, an NWC String input, a QR button and a disabled NWC Proxy switch.
That surface tells you where the product is aimed. Zaplit is meant for a small group standing in the same place or sharing an invite link, not for a merchant dashboard with teams, roles, invoices, tax exports and reconciliation. The interaction is mobile-shaped: create a group, invite friends, scan, connect, split.
The current UI also exposes the prototype state. The settings page validates only that an NWC string starts with `nostr+walletconnect://`. The QR scan path in settings simulates a result. The bill pages use local mock data and local storage. These are not disqualifying for a hackathon artifact, but they are strong signals that you should not treat it like polished financial software.
The README describes a Nostr coordination layer
The README presents Zaplit as a web application for group expenses at conferences and events, using Bitcoin Lightning payments through Nostr Wallet Connect. It describes Nostr as the communication layer and lists event kinds for teams, users, bills and payments. The shape is clear: group state is coordinated through events, while wallet movement is handled through NWC.
The README says team events, user events, bill events and payment events contain encrypted stringified JSON. Team creation generates a team secret, creates a team event and builds a shareable URL containing team information and the secret. A member scans the QR code or uses the URL, connects a NWC wallet, and publishes a user event tied to the group.
That is an attractive design because it avoids a conventional central database as the main shared state. It also creates hard security questions. If a group URL carries enough information to decrypt bill data, that URL is sensitive. If a user event carries an encrypted NWC connection URL, the encryption and key handling need careful implementation, not just a concept diagram.
The code is more modest than the README
The current `main` branch is simpler than the full README protocol. It uses `@nostr-dev-kit/ndk` and creates an NDK instance with explicit relays including `wss://relay.damus.io`, `wss://nos.lol`, `wss://relay.nostr.band` and `wss://relay.hodl.ar`. Creating a group generates a local private key if needed, publishes a kind 30003 event, and stores current group state in React context.
The team context can look up a group by filtering kind 30003 events with a `d` tag like `zaplit:team:
That gap matters for a reader. Zaplit's idea is stronger than its current shipped completeness. The live app demonstrates the user journey and some Nostr coordination mechanics, but the code does not prove a production-ready encrypted group ledger or a fully automatic multi-wallet settlement flow on `main`. It is fair to admire the prototype and still test it like a prototype.
NWC is the payment hinge
Nostr Wallet Connect is the part that makes Zaplit more than a shared calculator. NWC lets an app communicate with a Lightning wallet through Nostr relays. In NIP-47 terms, a wallet service and an app exchange encrypted requests and responses, and the user grants an app-specific connection string rather than giving the app full wallet custody.
For Zaplit, the natural flow is that each participant connects a wallet capable of NWC. When it is time to pay a share, the app can ask the payer wallet to send sats, and the receiver can get paid over Lightning. Earlier repository history and the `nwc` branch show work around Alby's SDK, `NWCClient`, invoice creation and invoice payment, even though the current main branch keeps the live bill flow mocked.
The trust boundary is the NWC string. If you paste a real connection string into a web app, you are giving that app a payment credential whose power depends on wallet-side permissions. Use a dedicated connection with a tiny budget, a clear name and revocation. A bill-splitting app should never receive a broad, unlimited wallet connection just because the bill amount looks small.
The event kinds need careful reading
Zaplit's README lists team, user, bill and payment events with custom labels. It says addressable events sit in the 30000 to 40000 range and regular events sit in the 1000 to 10000 range. The examples include kind 30003 for teams, kind 31013 for users, kind 3003 for bills and kind 3113 for payments. The current code uses kind 30003 for teams and kind 31013 for user joins.
There is a small inconsistency worth noticing. The README's Team Event section shows kind 3003 in one JSON example while the surrounding text and current code use kind 30003 for team creation. This is exactly the kind of detail a developer should verify before building another client around Zaplit's event shape.
Nostr makes custom application data easy to publish, but easy publishing is not the same as a stable protocol. If Zaplit becomes a broader app, it will need a crisp event definition, migration story, encryption story, duplicate handling and a way to prevent clients from interpreting old prototype events as final state.
Group links are sensitive
A normal group invite link lets someone join a room. In Zaplit's README design, the group URL can also contain or derive the team secret used to read encrypted group data. That means the invite is closer to a shared secret than a harmless link. Anyone who receives it may be able to see bill metadata, members and payment state, depending on the final implementation.
For small friend groups, that may be acceptable. The practical rule is to share group links only with people who should participate in the split. Do not post them publicly, do not paste them into public Nostr notes, and avoid sending them through services that preview and store URLs. A restaurant receipt can reveal who met, when, where and what they paid.
If you test Zaplit, create throwaway groups first. Use fake names or limited names. Do not use a group link as a long-term private ledger. When a product relies on shared secrets, the security model is only as strong as the way people copy and forward those secrets.
Local storage is part of the current state
The current code stores user settings in browser local storage, including the `nwcString` value. It also stores bills in local storage. That is convenient for a prototype, but it is not a hardened secret-storage model. Browser storage can be exposed by malware, shared computers, browser profiles, backups, developer tools and sometimes careless screenshots or support workflows.
A cautious user should treat the browser running Zaplit as part of the wallet permission surface. If you paste a real NWC string into a page, assume the browser profile now matters. Use a separate wallet connection that can be revoked and that has a spending limit. Do not paste the same NWC string into multiple experimental apps.
For a future production Zaplit, local storage would need a stronger story: what is stored, how long it remains, whether secrets are encrypted, how users clear them, and whether the app can work with wallet handoff patterns that avoid long-lived secret storage in the page. The current version is useful for demonstrating the flow, not for holding high-value credentials.
Bill math is simple, real life is not
The mock bill helper divides an amount evenly across members with `Math.floor`. That is enough for a clean demo, and it matches the first problem Zaplit wants to solve: a group bill split among several people. But real shared expenses become more complex quickly. People order different items, one person pays the tip, someone leaves early, exchange rates vary, and rounding can leave leftovers.
The Devpost description mentions logging shared expenses and splitting them among members. It also says the team wanted something like Splitwise connected to Lightning. That ambition would eventually require item-level splits, unequal shares, multiple currencies, receipt import, manual adjustments, audit history and dispute handling. The current repository is not there yet.
That is why Zaplit belongs in a practical middle ground. It is very good as a proof that group payment coordination can be Nostr-native and Lightning-settled. It should not yet be used as the source of truth for complicated trips, business reimbursement, taxes or accounting without an external record.
Payment status can be tricky
Zaplit's README says payment status and calculations are handled client-side. A payment event references the original bill and includes payment data. The client then fetches all payment events that reference the bill, sums the total amount paid, calculates remaining balances and tracks individual member contributions.
Client-side status is attractive because it keeps the app lightweight and lets Nostr relays carry the state. It also creates edge cases. What if two events claim the same share? What if a payment event is published before a Lightning payment actually settles? What if a relay misses an event, a member uses a different relay, or someone replays an old event? What if an invoice is paid but the app fails before publishing status?
For tiny friend bills, rough status may be good enough. For money that matters, status needs stronger evidence. Ideally the payment event should be tied to a real Lightning invoice result, and clients should distinguish intent, invoice creation, payment attempt, settlement and failure. A green checkmark should mean more than a successful animation.
The app is not custodial by design
Zaplit's pitch is not that it holds everyone's money. The intended model is peer-to-peer coordination with Lightning payments and NWC-compatible wallets. That is the right direction for a group-expense tool because it avoids turning a bill splitter into a balance custodian. The app can coordinate who owes what while wallets perform the actual payment movement.
Non-custodial intent does not remove all risk. An NWC credential can still authorize actions, and an app that stores or mishandles that credential can create payment risk even if it never holds a balance. The difference is where the risk sits: wallet permission, credential storage, relay transport, user identity and app logic instead of a pooled account.
When testing Zaplit, think in permissions rather than slogans. What can the connected wallet do? Can it pay invoices? Can it make invoices? Does it have a budget? Can you revoke it? Can the app still do anything after revocation? These questions matter more than whether the product page says peer-to-peer.
The current release cadence is quiet
The GitHub repository shows 35 commits on `main`, with the latest visible commit from February 22, 2025. There are no published GitHub releases. The public branches include `main`, `mock-types` and `nwc`, which matches the feeling of a hackathon codebase moving quickly through mock data, Nostr events and NWC payment attempts.
A quiet release cadence does not mean the idea failed. Many hackathon projects pause after the event, especially when they prove a protocol pattern rather than ship a company. But a quiet cadence does change how you should rely on it. Use it as a reference and a small test surface, not as a dependency you assume will receive fixes quickly.
If Zaplit development resumes, look for release notes, a clearer deployment link, documented event kinds, wallet-compatibility tests, issue triage and a short security note around NWC strings. Those would be more meaningful maturity signals than a prettier landing page alone.
Where Zaplit fits in NWC
The current awesome-nwc list places Zaplit among finance, accounting and payment tools with the short description `Split bills using lightning payments`. That placement is sensible. Zaplit is not a wallet that exposes NWC to other apps. It is an app that wants to consume NWC connections so it can help users coordinate payments.
This distinction is important when comparing it to Flash, Flash Wallet, Alby Hub, LNbits or Zeus. Wallets and wallet services grant or process NWC access. Zaplit is on the other side of the relationship: it is an application that asks a wallet for payment capability. The app's success depends on wallet UX, permissions, relay reliability and the user's ability to understand what was granted.
That is why Zaplit is a useful ecosystem example even in prototype form. NWC is not only for zapping posts or building merchant checkouts. It can also support situational money flows: dinner bills, conference groups, travel costs, shared taxis, event tabs and small temporary collectives that need payment coordination without a bank account.
How it differs from Splitr and NostrPix
The same Bitcoin++ event had related projects, and names can blur. Super Testnet's hackathon summary lists Zaplit, NostrPix and Splitr as separate projects. NostrPix was a Brazil Pix-to-Lightning bridge and overall winner. Splitr was another Nostr-and-Lightning bill-splitting app with a different interface. Zaplit was the NWC-focused bill-splitting project connected to the `lacrypta/zaplit` repository.
That distinction prevents accidental duplicate pages and wrong expectations. Zaplit is not the NostrPix bridge, and it is not the separate Splitr repository. Its defining traits are the group expense workflow, Nostr event coordination, NWC wallet connection and the `zaplit.mucu.dev` live app.
If you are researching from old hackathon videos or ecosystem maps, verify the link before judging the project. Several teams were solving adjacent payment problems at the same event. A name in a list is only the starting point; the repository, domain and source trail decide which app you are actually looking at.
What to test before trusting it
Start with no money. Open the live app, create a group, inspect what local storage changes, and understand the create and join flows. Then use a throwaway Nostr identity and a wallet connection with a tiny allowance. If your wallet lets you set a maximum spend, expiration or method scope, set it before pasting the NWC string into Zaplit.
Next, use tiny amounts and your own receiving wallet. Create a simple bill, observe the displayed shares, and verify what actually happens in the wallet. If the flow is mocked or incomplete, do not force it with a main wallet. The right test result may be that the app is not ready for your use case yet.
Finally, revoke the wallet connection. Make sure you can remove Zaplit's authority from the wallet UI and that you understand whether any NWC string remains in browser storage. If revocation is confusing, stop there. The ability to leave a payment app is as important as the ability to join it.
What developers can learn
Zaplit is useful for developers because it compresses many NWC app questions into a small project. It asks how to represent a temporary group on Nostr, how to invite members, how to store a shared secret, how to connect wallets, how to map a bill to shares, how to publish payment status and how to keep the user experience simple enough for a restaurant table.
It also shows the rough edges. Nostr event kinds need consistency. Encryption needs actual implementation. NWC strings need safe handling. Client-side calculations need duplicate and failure rules. Relay choices need thought. Mock payment flows need to be separated from real payment flows so users do not confuse animation with settlement.
If you are building a similar app, treat Zaplit as a sketch and warning list, not just inspiration. Keep the group state small. Make invite links obviously sensitive. Avoid storing broad wallet credentials. Publish a test mode. Document exactly which NWC methods are used. Make revocation obvious before the first sats move.
The practical verdict
Zaplit is one of the more human NWC experiments because the problem is not abstract. Everyone understands the unpaid dinner share, the conference receipt, the friend who paid with local currency, and the little social debt that follows. Lightning can settle the money quickly; Nostr can coordinate shared state; NWC can let each person keep their own wallet.
Its weakness is maturity. The public app is live and the idea is coherent, but the current code still reads like a hackathon prototype. Some of the README protocol is aspirational relative to `main`; some payment behavior is mocked; some secret handling is too simple for serious use. That should shape how you use it.
Use Zaplit as a promising NWC bill-splitting prototype and a useful reference for small group payments. Test with tiny limits. Keep wallet permissions narrow. Do not treat it as accounting software. If the project grows, the most important upgrades will be a stable event model, real encrypted data handling, clear wallet-permission UX and honest payment-state evidence.
Sources worth opening
Open the live app, Devpost page, GitHub repository and Alby hackathon post first. Then compare the NWC, NIP-47 and code-level sources so you can judge what Zaplit actually implements today.
- Zaplit live app
- Zaplit create group page
- Zaplit join group page
- Zaplit settings page
- Zaplit landing page
- Zaplit Devpost project
- Bitcoin++ Beach Edition project gallery
- lacrypta/zaplit GitHub repository
- Zaplit README
- Zaplit package.json
- Zaplit NDK context
- Zaplit team context
- Zaplit NWC context
- Zaplit settings page source
- Zaplit create group source
- Zaplit bill add source
- Zaplit bill details source
- Zaplit mock data source
- Zaplit NWC branch package file
- Zaplit NWC branch bill context
- Alby recap of the Bitcoin++ NWC hackathon track
- getAlby awesome-nwc list
- NWC Nostr profile note on Zaplit winning the hackathon track
- NWC Nostr ecosystem map note mentioning Zaplit
- Super Testnet hackathon winners gist
- Andrea Diaz Correia on building Zaplit
- Nostr Wallet Connect official site
- Nostr Wallet Connect documentation
- NIP-47 Nostr Wallet Connect specification
- NIP-01 basic protocol flow specification
- Nostr Development Kit repository
- Alby SDK repository
