FiberNuts After the Hackathon: What Could Cashu + Fiber Enable on CKB?

Applications & Ecosystem
, ,
1

Gm CKB community,

FiberNuts recently placed first in Category 3 of the “Gone in 60ms” Fiber Network Infrastructure Hackathon, receiving a final score of 28/30. The project demonstrated RUSD-backed Cashu ecash being minted over Fiber, transferred between browser wallets, and redeemed through Fiber again.

Since the hackathon, I have been discussing what should come next. I received valuable input from @RetricSu and also had a useful pushback session with Hanssen, one of the developers.

Those conversations changed how I think FiberNuts should be presented and developed.

What is FiberNuts?

FiberNuts connects three components:

CKB and RUSD
      |
Fiber payment channels
      |
Cashu mint and bearer ecash

An operator runs a Cashu mint backed by RUSD liquidity on Fiber. A user can:

  1. Pay an RUSD Fiber invoice to mint ecash.
  2. Hold the resulting Cashu proofs in a wallet.
  3. Send those proofs directly through a QR code, message, or another communication channel.
  4. Redeem the proofs by having the mint pay an RUSD Fiber invoice.

The transfer between users does not require a new CKB transaction or Fiber payment. It resembles handing someone a digital cash note. Fiber is used when value enters or leaves the mint.

This could make small RUSD payments useful in communities, games, events, merchant applications, and other situations where users want fast bearer payments without publishing a transaction graph.

What Privacy Does Cashu Actually Provide?

My original description was that Cashu transfers are private and unlinkable because the mint sees issuance and redemption as separate events.

That is directionally correct, but incomplete.

Cashu uses blind signatures, which prevent the mint from directly linking the proofs it signs during issuance with the proofs later presented for spending or redemption. This removes the obvious public payment graph found in transparent ledgers.

However, it does not mean that Cashu is anonymous against every observer. Amounts, timing, IP addresses, wallet behaviour, and other metadata may still allow correlation.

More importantly, Cashu is custodial.

The mint holds the underlying RUSD, validates proofs, prevents double-spending, and controls access to swaps and redemptions. When someone receives a Cashu token, their wallet will normally swap the received proofs for fresh proofs. This prevents the sender from spending another copy of the same token. Cashu’s NUT-03 considers the transfer settled only after the receiver has obtained those new proofs.

That swap still requires cooperation from the mint.

If the mint is unavailable, insolvent, or requires KYC from the receiver, the receiver may hold a valid-looking token that they cannot safely swap or redeem. This is not specific to FiberNuts; it follows from the architecture of custodial Chaumian ecash.

The correct description is therefore:

FiberNuts provides private bearer payments with bounded custodial trust. It is not a trustless or self-custodial payment system.

Users should only hold an amount appropriate for everyday spending and understand which mint issued their ecash. Even an advertised exit back to RUSD remains subject to the mint cooperating and having sufficient Fiber liquidity.

Why Cashu Still Fits Fiber

This limitation does not remove the value of the design. It clarifies where that value exists.

Fiber is good at moving real CKB assets and UDTs through payment channels. Cashu is good at creating simple bearer balances that can move between users without requiring a network payment for every exchange.

Together, they separate two concerns:

  • Fiber handles deposits, withdrawals, liquidity, and settlement.
  • Cashu handles private, lightweight transfers between users.
  • CKB remains the foundation for the underlying asset.

This is especially interesting for stablecoins such as RUSD, because users can think in familiar currency amounts while retaining an exit into an actual CKB asset.

The Application Demo I Want to Build Next

@RetricSu made an important observation: before trying to perfect every technical component, it may be more valuable to show the CKB community why Cashu + Fiber is useful in an application people can immediately understand.

I agree.

The next demo should feel like a small RUSD cash wallet rather than an infrastructure test console:

  1. A user selects a mint they trust and sees its operator, asset, network, availability, and redemption policy.
  2. They load RUSD into the wallet through a Fiber payment.
  3. A recipient creates a payment request identifying the mints they are willing to accept.
  4. The sender pays by scanning a QR code or sharing a bearer token.
  5. The recipient’s wallet asks the issuing mint to swap the received proofs into fresh proofs and only marks the payment as settled after that succeeds.
  6. If the mint refuses or is unavailable, the wallet reports that clearly instead of presenting the token as a completed payment.
  7. After a successful swap, the recipient can keep spending the proofs or redeem them back to RUSD through Fiber.

The trust boundary should remain visible throughout the experience. The wallet should never present ecash from an unknown mint as equivalent to self-custodied RUSD.

A particularly useful demo could involve a community event, merchant, game, or online group operating a known mint. Participants could make small RUSD payments while limiting their exposure to that operator.

Open Questions Raised by This Feedback

@Hanssen compared the mint’s security model to a centralized exchange and asked whether funds can move between independent mints without passing through Fiber. Hanssen’s feedback also raised a deeper question: could CKB’s programmable scripts reduce some of the authority that a Cashu mint holds today?

Some boundaries are already clear. Cashu proofs are specific to the mint that signed them, ordinary receive-side finality depends on that mint accepting a swap, and the current FiberNuts design does not use a CKB script to govern Cashu’s off-chain spent-proof database.

However, the feedback opens several questions that I think are worth exploring with the CKB community:

  1. Can a CKB script control or constrain the RUSD reserves behind a mint while preserving private bearer transfers?
  2. Could users receive a verifiable exit right that does not depend entirely on the mint remaining willing and available?
  3. Would a threshold or federated mint provide a useful reduction in trust, or merely distribute the same custodial authority among more operators?
  4. When moving value between independent mints, should Fiber be the common settlement rail, or could atomic ecash swaps or an inter-mint clearing design provide a better route?
  5. What security can an offline receiver reasonably verify before reconnecting to the issuing mint?
  6. What would make private bearer movement sufficiently valuable for users to accept this bounded custodial risk instead of using an exchange or ordinary wallet?

I do not want to claim that FiberNuts has already answered these questions. They are possible design directions, and the answers may involve significant tradeoffs between privacy, custody, latency, liquidity, and on-chain complexity.

How This Changes the Roadmap

The roadmap is now taking shape around three goals:

  • Build an understandable application-style demonstration around a concrete daily-use scenario.
  • Make mint identity, accepted mints, redemption policy, liquidity, and custodial risk visible to users.
  • Harden settlement and recovery before positioning FiberNuts as production infrastructure.

A later phase can test transfers between independent RUSD mints using Fiber as the settlement rail. That would improve operator choice and portability, although each mint would still retain its own custodial trust boundary. Whether Fiber should be the only route between mints remains an open design question rather than an assumption.

Questions for the Community

For the immediate application demo, I would appreciate concrete feedback on three points:

  1. Which application would best demonstrate the value: everyday P2P payments, merchant payments, community credits, gaming balances, or event payments?
  2. What information would you need before accepting ecash from a particular mint?
  3. Are any community members, wallet developers, merchants, or Fiber operators interested in testing an independent RUSD mint?

The hackathon demonstrated that the underlying integration works. The next step is to demonstrate why people would want to use it, while being precise about what it can and cannot guarantee.

Thanks again to @RetricSu, @Hanssen, and everyone who has challenged or supported the idea so far.

6 Likes