Architecture
VaultKeepR is split into an open-source core and private clients. The vaultkeepr-public repository holds the cryptographic SDK packages (MIT licensed, published to npm under the @vaultkeepr scope) and the Solidity contracts. The web app, browser extension, and iOS/Android apps live in a private repository.
The packages
Section titled “The packages”| Package | Role |
|---|---|
@vaultkeepr/core | Vault crypto: XChaCha20-Poly1305, Argon2id, ECIES envelopes, TOTP, passkeys, BIP-39, import/export for 10+ manager formats |
@vaultkeepr/sync | Cross-device synchronization built on Automerge CRDTs |
@vaultkeepr/ipfs | Content-addressed vault storage: CID handling and multi-gateway fetching with failover |
@vaultkeepr/recovery | Fragmented recovery with on-chain contract reads on Base |
@vaultkeepr/smart-account | ERC-4337 account abstraction: identity derivation and on-chain sync |
@vaultkeepr/wallet-messages | EIP-4361 and delegation message schemas for signed sessions |
@vaultkeepr/cloud | Zero-knowledge encrypted cloud storage (S3-compatible) |
@vaultkeepr/logger | Structured logging that redacts keys, CIDs, and addresses |
@vaultkeepr/legacy | Digital inheritance types and beneficiary management |
Other packages cover premium license validation, email aliases, i18n (English and French), shared UI components, Sentry adapters, and native OCR (VisionKit on iOS, ML Kit on Android). Install the core with npm install @vaultkeepr/core.
The contracts
Section titled “The contracts”Three Solidity contracts are deployed on Base L2 and covered by Foundry tests:
| Contract | Purpose |
|---|---|
VaultKeeperCidRegistry | On-chain registry of vault location pointers |
VaultKeeperFragments | On-chain storage for recovery fragments |
VaultKeeperLegacy | Time-locked inheritance to named beneficiaries |
The contracts hold public pointers and encrypted payloads only. They never hold keys or funds.
Where data lives
Section titled “Where data lives”| Data | Where |
|---|---|
| Vault plaintext | Device memory only, while unlocked |
| Derived keys | Device memory (SessionKeyStore holds session copies) |
| Master password | User’s memory only; never transmitted or stored |
| Encrypted vault snapshots | IPFS and S3-compatible storage, addressed by CID |
| Recovery fragments | IPFS, plus pointers in the VaultKeeperFragments contract |
| Vault location pointers | VaultKeeperCidRegistry on Base L2 |
| Legacy instructions | VaultKeeperLegacy, time-locked, encrypted payloads |
Servers and APIs
Section titled “Servers and APIs”Hosted APIs support the client workflows without replacing end-to-end encryption. They accept already-encrypted vault payloads for pinning or relay, verify wallet signatures, and record the current CID for an address. Other endpoints can serve non-secret metadata, such as fragmented-recovery manifests keyed by a hash of a recovery identifier. Nothing in this design assumes a server can decrypt your vault. Exact routes and deployments may change; the open-source packages remain the reference for implementers.
Source files
Section titled “Source files”- README.md — package and contract tables
- docs/THREAT_MODEL.md — asset table used above