There are definitely security tradeoffs here -- I'm somewhat more confident

• The user nodes are never exposed to the public internet, which removes a huge class of attack vectors. All inbound connections are either from our LSP (inside the same VPC) or our gateway proxy, which authenticates the user connections. Standard hot wallets are notoriously problematic here.
• All communication user app <-> node enclave are e2e encrypted+authenticated. Provisioned seeds/keys are never exposed to Lexe.
• User nodes won't provision secrets unless it's to Lexe-signed enclaves running on our infra (among other things)

As far as features this enables:

• I think there are some cool additional payment products we can enable, like subscriptions, automatic weekly remittance payments, etc... That'll always work even if you're on vacation or you lose your phone :)

In terms of there being a "honeypot" due to keys being centralized in one place, SGX makes things more secure, not less. If someone wants to hack a centralized custodian like Coinbase or Binance all the attacker has to do is get into their infrastructure to get access to their funds. If someone wants to hack us, they have to first get into our infra, and then also break SGX.

We believe that despite expected protocol advancements in handling async payments / offline receives (e.g. PTLCs), the problem is fundamental - someone has to come online in order to settle the payment. Our approach is simple - just keep the user online.

Self-custodial w/o compromises is absolutely what we're aiming for.

As far as SGX security, Intel has been pretty good about releasing mitigations and TCB recoveries in a timely manner. Usually that means we need to change a few compiler flags in exchange for reduced performance or update some certs. Running on the most recent Intel CPUs also helps a lot here. When the Lexe app wants to provision keys to the node, it can check that nodes have mitigations applied, are running on recent hardware, etc...

At the end of the day, security isn't all-or-nothing and I think SGX gets us to a good middle ground.

Adding on to what Philip said, we've also tried to be practical and architect things in a way where we aren't solely depending on SGX for security. User nodes aren't exposed to the public internet, for example, which would allow attackers to attempt exploits by sending crafted network messages. If a 3rd party wants to attempt an SGX exploit, they'd have to get into our infrastructure first, or find a vulnerability in our reverse proxy.

1. We do intend on supporting a subset of the LNURL protocols - our current priority is launching our product. It's been a while since I read over the specs, but last I looked there were only a handful of protocols that met our security requirements - we don't want Lexe to accidentally become a 3rd party that can steal payments, for example.
2. LDK was the obvious choice for us because it's the only implementation where the Lightning logic is fully separated out from I/O. This is a hard requirement for running in SGX, where you don't have access to things like disk / network / syscalls. We're very grateful for LDK and the Spiral team.
3. Users can toggle between USD/BTC/sats display :)
4. The fund button is for if we eventually want to add an exchange integration in the future. We'll probably end up removing it, the screenshot on the website is a preview of our very much WIP mobile app.
5. Good catch - yes, the 0.5% fee is both for sending and receiving. We thought that this business model was the most fair because users don't have to keep paying for a node that they don't actually use (which sometimes happens in a subscription model). To make this possible, however, Lexe has to be the only LSP. So we'd see the amount and directionality of payments, and know your channel balance (not your on-chain wallet balance), but we don't know (1) who you're sending to or (2) who you received from.

lek-see :)

I'd estimate in about 6 months. There's a lot of work and it's just the two of us! It also depends if / when we scale up the size of our company.

Backups are stored using the Google Drive v3 API so that it is interoperable with our current E2EE persistence system (we call it our "vfs"). We don't have access to users' GDrive API credentials though, since these are provisioned into the enclave and hidden from Lexe.

funny story, myself and 3 other ppl pitched David Marcus on integrating lightning into Messenger/WhatsApp in like October 2018, rather than building our own blockchain (DIem/Libra). in hindsight, I don't think LN was ready at the time. but pretty funny how things ended up w/ Lightspark and all

We expect to give users a small amount of free liquidity when they receive their first payment over a JIT channel initiated by our LSP. The user pays for the on-chain fees of opening the channel but there are no liquidity fees for now. It's possible that we'll add a "premium liquidity" service in the future to supply extra inbound liquidity for high-volume users that want it. Paid for using Lightning, of course.

Yes, there are a number of similarities. Both of us run an LSP and user nodes only connect to the LSP(s). But with Phoenix, the Lightning node runs on the mobile device, while with Lexe, the Lightning node runs inside an SGX enclave in the cloud; the mobile app is mostly used to remotely control the node (after the node and mobile app mutually authenticate each other of course). This difference in architecture allows us to help users receive payments when they're away from their phone.

Phoenix releases for Android first and iPhone second though, whereas this doesn't even have an Android option on the site ;_;

Also, Phoenix is based on Eclair (both written by the same company) whereas this is using LDK (could be relevant to what gets supported in the future)

I would also point out, that Phoenix's model is the LSP model which is also used by Breez and Mutiny. Its a good model imo, I like it.

yeah i know Kostas came from Corda -- great guy. think he's now chief cryptographer @ Sui, working on (more) interesting zk stuff :P

Alright: Intel SGX is important because it allows someone to run a computer program for someone else without having access to any of their sensitive information. This is useful because not all people want to run the programs they use themselves, so they can let someone else do it for them without sacrificing their privacy.

Lightning -> onchain will be handled by splicing out of the channel - no need for a swap.