Just the proofs for now. The deposit command polls until the quote is paid. As for the proofs, they are removed immediately after being spent, and I swap all remaining proofs into a single event. To keep the token amount low, I calculate the least power of 2 summand and swap everything into new outputs. For example if I have 1,2,4,8,1 across 3 events, those get swapped into 16 and 1 event. The old events are deleted.
Discussion
What are you considering spent? When the proof is sent from one person to the other. Or when the receiver actually claims it from the mint.
Right now, I have it receiving and sending Lightning payments only. My initial motivation is to first build a persistent back end for my custodial Lightning payment service.
The next step is to receive tokens directly, likely through a DM. Once I get all of the basic mechanics worked out, I will build in the multi-mint capability. I was happy to get all of the swapping and consolidation working. That was a big job.
Have you looked into NIP-60 yet? Your idea sounds more general purpose, but we are working on a cashu-specific one: https://github.com/nostr-protocol/nips/pull/1369
Yep. NIP-60 was my starting point, but I realized I could do more general stuff. My primary motivation is to swap out an internal custodial wallet component I built that relies on a Postgres database. I realized I could use a relay, and with better security (removing my database as a honeypot of data). I implemented the proof storage as per the NIP and added in some lightning capabilities.