Hi folks, Danny (on the TrelisDev email) and I have built out an MVP for an invoicing tool that issues an LN invoice and then pays it out to a merchant's BTC account.
A few things I'm looking to get input on right now. Your assistance - or tips on people to talk to - would be greatly appreciated: *1. Lightning to Bitcoin Cash-out* The reason for taking this approach is that it was difficult to find a way to support lightning to lightning payments in a non-custodial way. The options we saw were: 1. Trampoline node (like Phoenix) - requiring management of liquidity for our node, which is a pain (and may or may not be custodial?) 2. LN bits approach - which is custodial. Obviously cashing LN out to BTC isn't ideal (due to LN fees + Boltz 0.5% swap fee + Bitcoin on-chain fee), particularly because of the on-chain fee, but at least we can do it more non-custodially. I am interested in better technical approaches. Ideally, we'd like to non-custodially facilitate lightning invoice generation (without the merchant having to set up a node with a BTC pay server type approach = too complicated for most merchants imo). *3. Bitcoin Price Volatility* Generally, I'm skeptical a tool like this can get a lot of adoption because Bitcoin price right now is too volatile to be useful to customers and merchants. I guess there is a bounty for building contracts for difference (illegal in the US) that would support a dollar-pegged asset in lightning channels, but I'm guessing that's 6-12 months away from being usable. Ideas on approaches for addressing this would be appreciated. Cheers, Ronan ~~~ P.S. I have two less technical things I'm thinking about. I know this is a dev thread, but if anyone has reccs or folks to talk to that would be much appreciated. *a. Regulatory Status* I would like to understand whether merchants making use of Trelis software to build a payments page brings Trelis under regulation, and what options there are for handling this in the case of: a) just for providing the software b) specifically with our current implementation, where the merchant uses our api to have Boltz.exchange create a bitcoin lightning invoice that swaps to a bitcoin payment to the merchant's wallet. *b. Mitigating Fraud* I am concerned both about fraudulent merchants creating payment links *and* about the image/brand of Trelis vis-a-vis the merchants that it serves. Broadly, I see two extremes for the approach Trelis could take: 1) No Verification ~ in which case there is probably an adverse selection problem for the types of merchant that would use Trelis. 2) Use Verification: ~ in which case Trelis needs to make moral judgements around what types of businesses to support. To a degree, we already have a layer of this by requiring login with gmail, and could progressively build on this.
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
