pull down to refresh

You have also another scenarios:
  • Greenlight - user have the keys on his device, but the LN node and funds are on a remote custodial server. The service provider cannot touch the funds, but still the user, if the service provider close the access to the server, will not be able to recover the funds.
  • Breez - user have the keys to the funds, and run the node in the device, but if the central node of Breez shuts down, is not so easy to recover the funds.
  • Mutiny - user have the keys on his device, but many users still use the default domain app (mutinywallet.com). Service provider manage the node infrastructure, but user still have full control of the keys. but if that domain get busted user can't recover his funds.
  • LNBits - service provider offer lndhub accounts and have full control of the funds. The user have only a simple key to access that account, no option to recover them in any way.
  • Hosted channels - user have the keys to his funds but service provider still can close the access to the funds.
I will name "self-custodial" a wallet that the user:
  • have full control over the keys
  • have full control of the app hosting (his own server or mobile device)
  • have option to recover his funds easily into another wallet
  • can control all the access to his funds and manage it by himself
All the rest that do not comply these aspects will be in the custody of somebody else. You, the user are just their slave.
Yes, I know that if you include Lightning you have multiple possible scenarios. I am particularly talking about onchain, I forgot to clarify that.
reply
LOL but who in the right mind will use nowadays a custodial only onchain wallet? That is stupid.
Onchain should be always only self-custodial. PERIOD. Because onchain are ONLY for holding, long term, cold wallets. PERIOD.
reply
You would categorize as "custodial" the scenario I presented? Where condition 1 is satisfied, but condition 2 is not.
reply