Gm CKB community,
In my earlier FiberNuts post, I said the next step should be more than improving the wallet. It should be a high-level application that shows why Cashu + Fiber could be useful in an everyday setting.
That application is now built: FiberNuts Community Market.
The idea is a small community event where attendees can buy items or tip contributors with RUSD ecash, while vendors receive and secure those payments before cashing out through Fiber.
Fiber moves RUSD into and out of the system. Cashu handles the many lightweight payments in between.
What the demo looks like
The application has two separate experiences:
- Attendee: market.fibernuts.xyz
- Vendor terminal: market.fibernuts.xyz/vendor
A complete payment works like this:
- The attendee adds RUSD ecash by paying a Fiber invoice.
- The vendor selects an item, such as a 2.50 RUSD coffee, and creates a payment request.
- The attendee scans one QR code and reviews the amount, mint, fee, and remaining balance before paying.
- The attendee wallet creates a Cashu payment locked to the vendor’s key and delivers it through the payment relay.
- The vendor stores the received payment, checks it with the issuing mint, and swaps it for fresh proofs.
- The order becomes Paid only after those fresh proofs are stored in the vendor balance.
- The vendor can later cash out by asking the mint to pay an external RUSD Fiber invoice.
The distinction in step 6 is important. Delivered means the payment reached the vendor flow; it does not mean settlement is complete. The vendor sees Paid only after the issuing mint accepts the proofs and returns fresh ones.
What was added beyond the wallet
This is a focused event-payment application rather than another general wallet dashboard. It includes:
- A vendor catalog, order builder, QR checkout, current order, and order history.
- A one-scan NUT-18 payment flow with an exact review screen before value moves.
- Vendor-key locking so the delivery relay cannot redeem the payment itself.
- Separate attendee and vendor balances and operation histories.
- Add-cash and cash-out flows that use Fiber at the boundaries.
- Recovery states for interrupted delivery, settlement, issuance, and cash-out operations.
- Persistent network, asset, mint, and testnet identification throughout the interface.
The trust boundary is still visible
This demo does not change the underlying Cashu trust model. The mint remains custodial and controls issuance, swaps, and redemption. Browser storage is not a secure backup, mint availability does not prove solvency, and a user still needs a funded RUSD Fiber route to add cash or cash out.
The current vendor-locked payment also has no attendee refund path after confirmation. That makes the relay unable to spend the payment, but it means this version should be used only with small testnet values while refund semantics are designed and tested properly.
The goal is not to hide these boundaries. It is to show a practical application while making the exact moment of settlement and the remaining custodial risk understandable.
What I would like feedback on
- Does the attendee-and-vendor flow make the role of Cashu + Fiber clearer than the standalone wallet?
- Would a community event or meetup be a useful place to test this with several attendees and vendors?
- What information should a user see before accepting ecash from a mint?
- What recovery or refund behavior would you require before using this beyond a controlled testnet demo?
The source is available at github.com/code3ks/fibernuts. The application, mint, and payment relay are deployed for use with CKB testnet, but please treat them as experimental infrastructure and use test value only.