Challenges of Building a Non Custodial Lightning App
summary
A custodial to noncustodial migration over 18 months makes every zap a Lightning payment so the site now wraps invoices LMProxy-style and forwards payments with a JavaScript forwarding layer. Payments are optimistic in the UI with three background retries before canceling, and sending invoices use a lower amount so only about 70% forwards while 30% becomes 21% territory + 9% rewards credits. Wallet creds are split encrypted for send/receive across devices, node uptime and liquidity remain frequent failure points.
AI-written summary · about
chapters (10)
- 0:00Why non-custodial
- 4:00Custodial vs non-custodial
- 7:55LM Proxy for payments
- 9:42Seamless background payments
- 17:38Lightning payment failures
- 20:07Small payment challenges
- 21:12Wallet confusion issues
- 23:39Node downtime handling
- 25:03Credits for non-users
- 27:11Credits and fees
related talks
50mSecurity Aspects of Lightning Network Routing
01h 21mGating APIs with Lightning: A Hands-On L402 Workshop Using Aperture
25mDon't Trust Your Node: Policy-Based Signing for Secure Lightning Infrastructure
46mLightning Security Panel
14mInsecure Lightning Node? VLS Fixes This
42mCustodial vs Non-Custodial Wallets
12mSelf-Custody Solutions for Salvadoran Companies
35mCustomer Panel