Experimental. Unaudited. No real-fund custody.
The implementation has automated tests, but no completed independent cryptographic review or program audit. Mainnet creation, deposits, and withdrawals are disabled in this release. No security certification or quantum-resistance level is claimed.
The intended security boundary
A connected Solana wallet funds a program-derived vault. The program verifies a separate Winternitz one-time signature before a withdrawal and atomically replaces the authorization commitment. Possession of the original wallet signing key alone is not sufficient to satisfy that check.
This is a design objective supported by local tests, not an external assessment of the complete product. The website, recovery workflow, deployment process, and dependencies remain part of the attack surface.
Documented prior art. Unreviewed integration.
The Rust verifier is vendored from Blueshift’s Winterwallet, which explicitly states that it is not formally audited. Bunker uses its full 32-byte message digest, 34 SHA-256 chains, checksum, and tagged Merkle commitment. A browser port is checked against upstream Rust vectors.
This construction is not WOTS+, XMSS, LMS, or a NIST-approved Bunker scheme. We do not equate use of SHA-256 with review of the whole signature construction.
What Bunker does not protect
- A compromised browser or device. Malware, malicious extensions, injected scripts, or a compromised build can steal a recovery key or alter a destination.
- Recovery-file loss or password loss. There is no reset, administrator recovery, or wallet-key fallback.
- One-time-key reuse. Old backups, multiple devices, forks, or separate origins can bypass a browser’s local safeguards. Two different messages signed with the same key may weaken security.
- Solana as a whole. Consensus, transaction fee signatures, validator identities, RPC availability, and network cryptography remain outside this vault’s protection.
- Token issuers and authorities. Minting, freezing, or issuer controls are unchanged. A token can be frozen or lose value while held in a vault.
- Upgrade authority or deployment compromise. An upgradeable program can change its rules. The current authority must be inspected for each deployment.
One-time signatures require careful recovery
The app reserves an exact withdrawal before signing and saves an encrypted pending recovery file before uploading the signature. If submission is interrupted, only that exact withdrawal can be resumed. A successful withdrawal advances the on-chain nonce and changes the authorization root in the same transaction.
A pending transfer cannot simply be changed or cancelled. If its destination or token becomes unusable, funds may be stuck. Do not erase local signing history or restore an older backup to make a different transfer. Browser locks cannot coordinate different devices.
Intentionally narrow asset support
SOL and ordinary accounts under the classic SPL Token program are supported in the test implementation. Token-2022 extensions, programmable NFTs, confidential transfers, swaps, bridges, arbitrary program execution, staking, and fee relayers are excluded. Vault account rent remains reserved.
Privacy and incident response
There is no advertising or analytics code in the app. Public wallet addresses and transactions go to the configured Solana RPC provider. Recovery secrets are handled in browser memory; only password-encrypted pending files may be stored in local browser storage. JavaScript cannot guarantee erasure of all copies from memory.
No security contact or bounty program has been commissioned. Before release, the project owner must appoint a private reporting channel, reviewers, and incident responders. See the release requirements.