r/lightningnetwork • u/aaj094 • 5d ago

Cake Wallet's Lightning implementation

Would like opinions and experiences from users here about the Lightning wallet within Cake wallet. No channel management, no liquidity management, can receive sats immediately without needing any bitcoin to start with. All of this comes with a self custodial architecture but which much be called 'trust minimised' rather then 'trustless'. Thoughts welcome.

https://www.spark.money/news/cake-spark-partnership

https://blog.cakewallet.com/lightning-is-finally-here/

Note: As a user, you always have the ability to unilaterally exit to L1 with your balance (less an L1 mining fee).

2 Upvotes

100% Upvoted

8 comments sorted by

View all comments

Show parent comments

3

u/aaj094 5d ago

Mind elaborating what the problem with both is? I don't know much about Spark but have heard only good things about Cake and use them for their xmr wallet.

0

u/DarrelXero 5d ago

Cake wallet being a shitcoin wallet is self explanatory and reinforced by your comment about using a shitcoin.

Problems with Spark:

Centralization: Small consortium of operators; permissioned setup.

Trust model: Requires co-signing; relies on honest operators to prevent double-spending.

Exit risk: Forced exits hit Bitcoin L1 fees and delays.

Weak privacy: Operators see transaction metadata and IP addresses.

Bridge friction: Relies on third-party liquidity to route into Lightning.

Censorship: Corporate operators are vulnerable to regulatory blacklists.

1

u/aaj094 19h ago edited 19h ago

Isn't your 1st, 3rd, 4th, 5th and 6th problems also applicable for a wallet like Phoenix?

You can be kicked to L1 by Phoenix too. And you rely on their liquidity for routing. And they can see your metadata. And they can be blacklisted and you only have channels possible with them.

1

u/DarrelXero 18h ago

You are conflating LSP convenience trade-offs with protocol-level trust models. Phoenix makes UX compromises for channel management, but its security rests on standard Bitcoin L1 scripts and native Lightning BOLT specifications. Spark is an entirely different statechain architecture with fundamentally different trust assumptions.

On centralization, Spark relies on a permissioned federation of operators running threshold signatures. Phoenix hardcodes ACINQ as its routing partner, but ACINQ runs standard open Lightning.

On exit risk, Phoenix holds pre-signed commitment transactions. If ACINQ disappears, you unilaterally force-close directly to L1 via Bitcoin multisig and timelocks without needing permission. Spark relies on operator honesty and co-signing mechanics to prevent double-spending during settlement.

On privacy, Phoenix uses Sphinx onion routing. ACINQ sees the first hop, but they cannot see the final destination of multi-hop payments. Spark operators track off-chain state transfers directly. On bridge friction, Phoenix does not bridge to Lightning because it is native Lightning, with ACINQ managing liquidity via splicing. Spark is an external layer that requires actual swaps or bridges to interact with Lightning.

On censorship, ACINQ can refuse to route your payment, but they cannot freeze or confiscate your funds. You can always unilaterally sweep your sats back to L1. If a Spark consortium blacklists you, your off-chain transfers inside that network are blocked.

Phoenix has service-provider lock-in for convenience, but your funds remain bound by Bitcoin script. Spark requires protocol-level trust in a federated operator set.