Plain SQLite with no at-rest encryption is concerning. Good to know before we make the move.
You're right that delegating to Speed is functionally metadata custody. We're aware of that tradeoff. For our current stage — early beta, small trades, LATAM users whose immediate problem is losing 30-100% annually to inflation — the practical risk of metadata leakage is lower than the risk of not having a working product at all.
But it's not where we want to stay.
The plan is to run local tapd once we upgrade to LND v0.21. The SDK lowers the barrier enough to make that realistic. When we do, proof storage encryption at rest becomes our problem to solve — probably encrypted SQLite or moving proofs to a separate encrypted store.
The real question is whether tapd's proof model matures faster than our need to move off the edge provider. Right now Speed gives us instant liquidity, Taproot Asset channel management, and a wallet that our LATAM users already have on their phones. Rebuilding all of that locally is months of work.
So honestly — sticking with Speed for now, running local tapd as the next major infrastructure milestone. The metadata tradeoff is the cost of shipping early.
If you dig into the SQLite proof storage further, I'd be interested in what you find on the encryption side. This feels like a gap that needs filling before any serious deployment.
SLEdex / Dean SLE DEX
npub1fu…pxkwr
2026-09-04 01:29:15 UTC
in reply to nevent1q…xtsq
Author Public Key
npub1fusdd38d572mk9jgge76q3tt4ae9agsfxer2s0zyldulp0wscshs0pxkwrPublished at
2026-09-04 01:29:15 UTCEvent JSON
{
"id": "ace87e1e238f2f55560d271d31c9b44abb0cdfdec0111f123af15f2626eb8496",
"pubkey": "4f20d6c4eda795bb1648467da0456baf725ea2093646a83c44fb79f0bdd0c42f",
"created_at": 1788485355,
"kind": 1,
"tags": [
[
"e",
"894268405bdc9afb136fe72dde0f19aa728227015f8072f0058f0854514dfde9",
"",
"root"
],
[
"p",
"27505421c268f363078bf5400d68273b9871e8e35263fdc4532600025eaf3f13",
"",
"mention"
],
[
"client",
"Primal iOS"
]
],
"content": "Plain SQLite with no at-rest encryption is concerning. Good to know before we make the move.\n\nYou're right that delegating to Speed is functionally metadata custody. We're aware of that tradeoff. For our current stage — early beta, small trades, LATAM users whose immediate problem is losing 30-100% annually to inflation — the practical risk of metadata leakage is lower than the risk of not having a working product at all.\n\nBut it's not where we want to stay.\n\nThe plan is to run local tapd once we upgrade to LND v0.21. The SDK lowers the barrier enough to make that realistic. When we do, proof storage encryption at rest becomes our problem to solve — probably encrypted SQLite or moving proofs to a separate encrypted store.\n\nThe real question is whether tapd's proof model matures faster than our need to move off the edge provider. Right now Speed gives us instant liquidity, Taproot Asset channel management, and a wallet that our LATAM users already have on their phones. Rebuilding all of that locally is months of work.\n\nSo honestly — sticking with Speed for now, running local tapd as the next major infrastructure milestone. The metadata tradeoff is the cost of shipping early.\n\nIf you dig into the SQLite proof storage further, I'd be interested in what you find on the encryption side. This feels like a gap that needs filling before any serious deployment.",
"sig": "cfbd97d1951e8285328944403b0cc9b7c6d1641327bdc76d07d3ffc45e8a62360b4695826d0cc5a4ff7c2e734f8302f6d3d322551f4a41a373f42f37cd6f1f88"
}