I’m working on BitVault, a security layer that sits on top of existing Bitcoin wallets or exchange accounts. It’s solving a simple problem: if someone compromises your device, seed, or session, withdrawals shouldn’t be instant. You should have a window to react.
What BitVault does:
2-of-3 multisig where the user holds two keys, and a “convenience signer” co-signs after a time delay.
Time-locked withdrawals (CSV) you can configure from 2 hours to ~15 days.
A fallback path: if the co-signer refuses or disappears, funds move via a pre-authorised route after the delay.
No custody. No pooled funds. No API dependency for signing.
Works with Keystone, Jade, Jade+ (QR flow). Rust SDK for integration.
What this is not:
Not a custodial service.
Not magic bullet security. If your device is compromised , you don't see the secret notification, and the attacker waits out the delay, you lose. The point is to shift the attack surface from “instant theft” to “theft that has to survive for days under scrutiny.”
Not a marketing play. The beta exists; we’re testing with 300+ users.
Why we built it:
Multisig is good, but it still signs instantly once keys are compromised. Hardware wallets help, until someone gets physical access. Adding mandatory time between click and broadcast gives users a last line of defense: panic window, device recovery, rotating to a safe wallet, or nuking the keys.
Architecture at a glance:
Key A: user (primary)
Key B: user (offline device or hardware wallet)
Key C: convenience signer (self-hosted or BitVault-hosted)
Time lock enforced at policy level; delays can’t be bypassed without waiting the same period.
Optional Telegram / email alert before the broadcast (not required for wallet function).
Asking the HN crowd:
Is time-delayed multisig actually useful for you, or is this a niche? Where does it break?
Would you self-host the third signer, or outsource it?
Is the trust model understandable as written, or does it need to be simplified?
If you’re building a wallet/exchange, would you integrate a Rust SDK for this?
Links:
Background + beta info: https://www.bitvault.sv/
Docs + SDK draft (still rough): available if anyone wants to review, DM me
Happy to answer technical questions, threat models, or “this is dumb because…” replies. The most useful thing right now is blunt feedback from people who’ve actually built wallets or handled security incidents.
If this sounds interesting, I’m here. If it sounds flawed, point to the exact flaw. Thanks
bitvaulty•2h ago
What BitVault does:
2-of-3 multisig where the user holds two keys, and a “convenience signer” co-signs after a time delay. Time-locked withdrawals (CSV) you can configure from 2 hours to ~15 days. A fallback path: if the co-signer refuses or disappears, funds move via a pre-authorised route after the delay. No custody. No pooled funds. No API dependency for signing. Works with Keystone, Jade, Jade+ (QR flow). Rust SDK for integration.
What this is not:
Not a custodial service. Not magic bullet security. If your device is compromised , you don't see the secret notification, and the attacker waits out the delay, you lose. The point is to shift the attack surface from “instant theft” to “theft that has to survive for days under scrutiny.” Not a marketing play. The beta exists; we’re testing with 300+ users.
Why we built it: Multisig is good, but it still signs instantly once keys are compromised. Hardware wallets help, until someone gets physical access. Adding mandatory time between click and broadcast gives users a last line of defense: panic window, device recovery, rotating to a safe wallet, or nuking the keys.
Architecture at a glance:
Key A: user (primary) Key B: user (offline device or hardware wallet) Key C: convenience signer (self-hosted or BitVault-hosted) Time lock enforced at policy level; delays can’t be bypassed without waiting the same period. Optional Telegram / email alert before the broadcast (not required for wallet function).
Asking the HN crowd: Is time-delayed multisig actually useful for you, or is this a niche? Where does it break? Would you self-host the third signer, or outsource it? Is the trust model understandable as written, or does it need to be simplified? If you’re building a wallet/exchange, would you integrate a Rust SDK for this?
Links:
Background + beta info: https://www.bitvault.sv/ Docs + SDK draft (still rough): available if anyone wants to review, DM me
Happy to answer technical questions, threat models, or “this is dumb because…” replies. The most useful thing right now is blunt feedback from people who’ve actually built wallets or handled security incidents.
If this sounds interesting, I’m here. If it sounds flawed, point to the exact flaw. Thanks