I wrote a post to @calle on nostr about an idea. Can anyone chime in if my idea is possible?
Post below:
I would be willing to pay for a bounty for cashu to support a arbitrary assets (in addition to LN/BTC)....basically "token" support.
(maybe others would like to pitch in on this development also? - thats why I'm publishing this on nostr....hoping to entice others).
I do tech work for a medium sized music festival promotion company. I've been a long-time bitcoin user and trying to find ways to utilize it for our patrons, but hasn't had a good fit until cashu arrived (specifically, its the true 'cash' nature that makes it fit).
An example use-case:
Scenario: A large music festival. This festival has 10 different food trucks + 5 different beer trucks + a host of other merch vendors.
  1. Patron arrives at music fest. Is told to "buy tickets" if they want food / beer / etc.
  2. Patron puts down $100 cash and teller collects money then puts this in cashu and mints 100 "usd-cashu" tokens.
  3. A QR code is displayed next to teller and they instruct patron to scan with phone. Patron scans QR code and opens web-wallet on phone showing these "usd-cashu" tokens funded into wallet.
  4. Patron enjoys music festival and goes around buying beer / food / tshirts / etc. There is no other form of payment accepted. All vendors have QR codes with price for various things....Patron simply scans and pays for things using phone.
  5. At end of festival Patron can either cashout and redeem unused "usd-cashu" for USD cash - or better - can use a kiosk to cashout to LN / BTC.
  6. At end of festival, Vendors cash-in their 'usd-cashu' at back office and again either receive cash or LN / BTC (or some combination thereof).
This would solve a major issue that is very very common in these festival environments. Specifically the "festival organizer" (us) leases the festival space and the vendors pay a fee + percentage of sales. Allowing vendors to accept money independently makes for balancing headaches at show end....likewise using something like printed tickets is prone to all sorts of problems and generally insecure (ie. counterfeit tickets, etc).
Thus, cashu would be a drop in replacement!
reply
Applaud your brainstorming about Cashu and its potential. Its a great project.
To me this sounds more like you should fork and work on this for your use case if you're truly passionate on this topic. For Cashu proper, I would argue similar to what Odell argues about taproot assets (taro), this is a distraction/diversion away from the core Cashu mission and focus on advancing Bitcoin. I don't want to speak for him, but I am guessing @calle would tell you the same based on everything I've read/heard him say about Cashu. I could be totally off and I'm open to being corrected here. There will never be enough dev time or resources especially for open source projects where devs are largely unpaid or minimally paid, and thus time dedicated to bringing USD or other assets to Cashu is time taken directly away from working on advancing Bitcoin on Cashu. This is not a good tradeoff imho.
What you are describing is already a key use case used for Fedimints, and at several conferences they have done exactly this with Alpha Fedimint Federations. I don't see a big value add to pulling away Cashu dev time and resources on Cashu to address a use case already largely addressed with ecash on Fedimints. For examples of where this has been successfully done on Fedimints please see articles like this: https://www.fedi.xyz/blog/announcing-the-first-ever-pop-up-federation-in-btc-prague
Appreciate your interest and passion. If you find this use case valuable for you and your company would encourage you to fork and work on yourself or try to convince your company to push for dev resources.
reply
To be clear: I don't see this as distracting from @calle focus, as I would still think the initial minting could require LN-BTC. Its just that instead of minting 1:1 cashu to sat, there would instead be a configurable setting. So, you could mint say 10,000 usd-cashu per sat (or whatever). Further, it should handle multiple of these "asset types" - with different descriptive labels and conversion parameters (ie. USD Token 10:1 to sat, etc)
I honestly appreciate the feedback though! I have a different view - that I think it born out of the real world: No one actually wants to spend their bitcoin - and this is actually the fundamental problem LN / etc has. As price (and fees) goes higher, this will exasperate the issue. Why spend $3.51 on a coffee that will cost you $35 in 4 years. Same reason why no one in Argentina buys coffee with gold.
Bitcoiners need to accept that Greshams Law is real (spend bad money before good money)...and fighting this fact is counter-productive for bitcoin as a whole. I'm not advocating shitcoins per se...but "tokens" are used ALL OVER the business world. Why shouldn't United Airlines base its air-miles program using eCash tokens?
reply
Definitely a reasonable idea and perspective. I share your frustration with Bitcoiners' unwillingness to ever spend sats, even if they just pay with Bitcoin by directly from converting from fiat (you spend fiat but someone receives BTC, great compromise imho - but everything has tradeoffs). To clarify I actually like your idea, I think its just better suited to either a Cashu fork (a corporate oriented Ubuntu versus the community project Debian) or Fedimint. The core idea/use case is cool imho. I think say a United is not going to want to use a privacy oriented anonymous freedom at all costs app that "terrorists" may be using (not my opinion, I love Cashu, I'm just imagining the boomer conversation inside of a big company board room). The regulatory/compliance/lawyer crowd at a big company would burn the place down before they let them use Cashu. A Cashu fork or Fedimints I'm guessing would be more palatable. All my guess, the free markets will decide. I don't seek to stop anyone. I truly love your enthusiasm. I wish your idea was more widespread-ly acceptable but companies using Cashu as is seems like a stretch to me for all but the most hardcore freedom oriented Bitcoiner founded and led startups.
reply
Yes! No worries friend. I agree that "United" itself wasn't going to launch lnbits and install a cashu extension...haha....simply making the point that I would rather them use "our" tech (even if its the eventual Ubuntu version of Cashu)
For reference, the people who run the festivals I work for are old hippies and they would pretty much agree to whatever I suggested. The actual problem I have with "fedi.xyz" is that its probably a little overkill for lots of grassroots usecases ( things like kids book fair at school, carnivals, farmers markets, etc).
There are lots of little ad-hoc usecases where there is too much friction in making people download apps and jump thru sign-up hoops. They just need a quick to use eCash solution. It really needs to be a "scan this QR code on your phone" solution.
Anyway thanks for your comments, I appreciate it
reply
Has it occurred to you that you can just sell the festival visitor bitcoin, but call it “festival tokens” and then they just pay with the bitcoins in their Cashu wallets 😂 ?
reply
Yes it has. Someone has to "front" those bitcoins to sell. A big festival can churn $300,000 in sales...whoever fronts that is now on the hook for exchange rate fluctuation.
These festivals can span 2 or 3 days. No vendor is going to agree to be exposed to exchange fluctuations. I'm not even talking about the risk of a massive dump during the 3 days, I'm saying that just normal 3% fluctuation (which could cost a big beer truck say $3000 over 3 days) is going to be a non-starter.
This is why it needs to be either (a) a dollar backed Cashu token, and/or a workaround is (b) Allowing admin of mint to modify 1:1 issuance ratio....so for instance you issue 10,000 Cashu tokens for 1 sat -- in this way the exchange rate issue is still a thing, but its negligible.
Makes sense?
reply
Seems like lightning prisms would be the perfect solution here. These are effectively payment splitters that split a payment into a number of parts, and route them in different directions. I think these are starting to be used in the music scene where, payments for a track get split between the artist and the songwriter (for example).
This same approach could be used for your example, splitting the payment for the food trucks (or whatever) between the vendor and the festival organiser
Certainly doesn't need a token introduced to solve the problem of sharing payment revenue.
reply
whenever you drop a github link, that's where you loss me as I know nothing by forking or pulling request
reply
Excellent! Thanks!
reply