Replying to Avatar jb55

nostr:npub1mhcr4j594hsrnen594d7700n2t03n8gdx83zhxzculk6sh9nhwlq7uc226 described an elegant solution to this: with cashu payment requests, the merchant itself specifies which mint the merchant is willing to accept.

At that point the wallet can do a swap between mints.

This actually makes accepting these things viable imo. If the merchant has a trust relation with a specific mint, and the ecash wallet has the ability to auto-swap, then it actually starts to make sense.

nostr:note1y8rx9ymusd39ufgrvy5hqg4vr78kncthny0rzd6t6qhqar9l9skqly92aj

With fedimint, something similar is achieved by having a lightning gateway serve multiple federations. A lightning gateway is a server that can offer to perform ecash-lightning atomic swaps as a service to federations that it trusts, typically maintaining an ecash balance for all federations it serves so it has liquidity to fulfill swap requests. Under the hood, if a user of Federation A pays an invoice to a user in Federation B, the gateway short-circuits and never even uses lightning. Instead it simply takes the Federation A ecash and pays out Federation B ecash. All of the complexity you’re describing is tucked away into the gateway, eliminating the need for every user to be a part of multiple federations in order to find overlap with counterparties. Instead, the gateway is the only party that needs to trust multiple federations, which it wants to do anyway, since that will lead to more tx volume and therefore more fees.

Reply to this note

Please Login to reply.

Discussion

No replies yet.