No account
Local use needs no QuanCard sign-up or sign-in. We do not have your email, or your vault.
Security
Sensitive things
deserve plain answers.
QuanCard holds card and bank account details, so you have every reason to be skeptical. This page describes the shipping code: how data is encrypted, where the keys live, what the app connects to, who can see what, and what we have not done yet.
Applies to: public beta 1.0 (6) · Updated 2026-10-08
Offline by default
Until you turn on sync, the app makes no network requests. In local mode, everything works in Airplane Mode.
No QuanCard data servers
Sync goes only to your own iCloud or a server you run. The QuanCard team never receives your cards.
How it differs from Apple Wallet
Wallet is great, and QuanCard is not a replacement. Keep using Wallet to pay; the two work side by side.
| Need | Apple Wallet |  QuanCard |
|---|---|---|
| Payments | Yes (supported issuers) | No, and it never will |
| Cards without Apple Pay, closed cards, collectibles | Can store numbers for AutoFill, but cannot pay with or showcase them | Its main purpose: artwork, status, and notes together |
| Bank accounts, IBAN, SWIFT / BIC | Not what Wallet is designed for | Separate accounts with many routing identifier types |
| Custom artwork, tags, ordering, regions | Limited | Yes |
| Where data lives | Apple devices and iCloud | This phone; optionally your iCloud or your own server |
| Export and migration | No export file; moves with Apple devices and iCloud | Password-encrypted .qvault backups with public test vectors |
Where your data comes from and goes.
Plaintext exists only in the app’s memory while you are unlocked. Before anything is written to disk or leaves the phone, it is already ciphertext.
QuanCard on iPhoneReadable in memory while unlocked
Cleared on lock; in the background, plaintext caches clear
and the root key is kept at most 60 seconds for a quick return
- On this iPhoneDefaultSQLite holds per-record ciphertext; card photos are encrypted as separate files.
- Your iCloudOptionalThe CloudKit private database holds only records the app has already encrypted.
- Your serverOptionalA QuanCard Server you deploy keeps only opaque, encrypted revisions.
QuanCard team serversThere are none. No analytics, advertising, or crash-reporting SDKs, and no channel that sends your vault data to us.
Each key locks the next.
No home-made cryptography. Everything uses standard implementations from Apple CryptoKit, the Secure Enclave, and libsodium.
- 01Secure Enclave device key
P-256, created inside the phone’s security chip and never exportable. Using it requires Face ID / Touch ID or the device passcode, and only works on this device with a passcode set.
- 02Vault root key (VRK)
A random 256-bit key that stays on this phone. It is not synced, not in iCloud Keychain, and never derived from a device ID or card number.
- 03Per-record data keys (DEK)
Every card and account gets its own random 256-bit key. Keys are never reused.
- 04Encrypted cards, accounts, notes, and photos
Encryption is bound to each record’s ID and type. Tampering, a wrong key, or moving one record onto another is rejected.
.qvault encrypted backup
Your backup password goes through Argon2id (256 MiB memory, 3 passes) and the result encrypts with AES-256-GCM. Longer passwords resist offline guessing.
iCloud sync key
A separate random 256-bit key travels to your other devices through Apple’s end-to-end encrypted iCloud Keychain. The VRK does not. Recovery depends on Apple’s keychain recovery; losing every trusted device may make it unrecoverable.
Self-hosted pairing
Scan a QR code from the web vault to pair. It carries the vault’s long-term key, generated locally in the browser; a server running normally never sees it.
Algorithms in use
- Records and attachments
- AES-256-GCM (CryptoKit)
- Device key wrapping
- Secure Enclave P-256 + Apple ECIES
- Backup password
- Argon2id 256 MiB / 3 passes / p=1 (swift-sodium)
- Keychain policy for device key and VRK
- This device only, passcode required, user presence
Who can read your data
Each cell says what that party can actually get. Green means they cannot read the contents; amber means they can see something, but only counts and times, not your cards.
- Cannot read contents
- Can see metadata (not card contents)
- You
| Data | You (unlocked) | Someone holding your locked phone | Apple (with iCloud) | Your server (self-hosted) | QuanCard team |
|---|---|---|---|---|---|
| Card numbers, expiry, CVC, account numbers | Can view | Can’t unlock | Ciphertext only | Ciphertext only | No access |
| Notes, tags, card photos | Can view | Can’t unlock | Ciphertext only | Ciphertext only | No access |
| Item count, data size, modification times | Can view | Possibly, forensically | Can see | Can see | No access |
| Account identity (Apple Account / server username, device names) | Can view | Can’t unlock | Can see | Can see | No access |
- Anyone who knows your device passcode can unlock the vault as you. Use a strong passcode.
- The “your server” column covers the iPhone app. The web vault’s code is served by the server, so a compromised server could swap that code and capture your password or pairing QR code the next time you use them. It can also withhold updates or serve an older state, which the iPhone can only partly detect. On hosts you do not trust, use only the iPhone app.
- The QuanCard team column says “no access” because your data never passes through us, not because we promise not to look.
What the app connects to
This is the complete list of network requests the app itself makes. Anything else is a bug, and we want to hear about it.
Local mode (default)
Nothing.
After you turn on iCloud sync
Apple CloudKit, the private database in your own Apple Account.
After you connect a self-hosted server
The HTTPS address you entered. You confirm it first, and redirects elsewhere are refused.
During TestFlight testing
Crash logs and feedback you choose to send (including screenshots) are collected by Apple and passed to us. Keep real details out of feedback screenshots.
There are exactly two third-party libraries, both pinned: GRDB (encrypted database access) and swift-sodium (Argon2id for backups). The app’s privacy manifest declares no data collection and no tracking.
Card security codes (CVC): how we handle them.
This is the question we hear most. We follow the same approach as 1Password and Bitwarden: you can save it, it is encrypted like the card number, and it travels with sync and backups. The difference is that we run no servers that store your data.
| Product | Saves CVC? | Protection | Where it lives |
|---|---|---|---|
| 1Password | Yes, Credit Card items have a “verification number” field | End-to-end encrypted with the rest of the item | Synced to 1Password servers with the vault (ciphertext) |
| Bitwarden | Yes, the Card item “security code” field | Encrypted like the card number; visible in the open-source client | Synced to Bitwarden or a self-hosted server (ciphertext) |
| Google Chrome | Yes, asks at checkout | “Save security codes” can be turned off separately, and codes deleted at once | On the device or in Google Wallet |
| Apple Safari AutoFill / iCloud Keychain | No | You type it for each purchase | — |
| QuanCard | Yes, optional; fully hidden by default, authorization to view | Like the card number: per-record AES-256-GCM | This phone; with sync, your own iCloud or your server (ciphertext). The QuanCard team never handles it |
Not needed for collecting
Closed and collectible cards don’t need a CVC. Fill it in only if you plan to pay online with the card.
Fully hidden by default
Unlike card numbers, no digits are shown. Viewing or copying requires Face ID or your passcode.
Included in sync and backups
It is included when you sync or export an encrypted backup, so a new phone won’t lose it. If you prefer Apple’s approach, leave it empty.
Delete any time
Clear the field to delete it. Older encrypted revisions in sync history remain; see Known limits.
If you’re concerned
Just leave it empty. Collecting, organizing, and viewing cards never need it; check the physical card when you pay.
Other products’ behavior is based on their official documentation or open-source code, checked 2026-10-08, and may change: 1PasswordBitwardenGoogle ChromeApple Safari
Product names and marks belong to their owners and are used only for identification; no partnership or endorsement is implied.
Don’t trust us. Check for yourself.
None of this needs special tools. Test with made-up details, never with a real card.
- 01
Turn on Airplane Mode
In local mode, adding, viewing, searching, reordering, and exporting backups all keep working. Only sync, which you turn on yourself, needs a network.
- 02
Check the App Privacy Report
Settings › Privacy & Security › App Privacy Report. Use the app for a while: with sync off, there should be no connections initiated by QuanCard. If you see one, tell us.
- 03
Check the backup and sync formats
Test vectors for encrypted backups and the sync protocol are public on GitHub, so you can verify the formats with your own code.
- 04
Read the server source
The sync service and web vault are open source under AGPL-3.0, with a threat model. Run it yourself, or audit exactly what the server stores.
What we have not done yet
These are not disclaimers that will fix themselves. They are facts you should know before deciding.
No third-party audit yet
The iOS app has over 400 automated tests and the server repository ships its own, but tests are not an audit and cannot prove the absence of bugs.
The iPhone app is closed source
The server and web vault are open source. For the app itself, you currently rely on this page, the public test vectors, and your own observations.
Hardware paths still need device sign-off
Secure Enclave, Face ID, and snapshot covering are tested with software stand-ins in the simulator; on-device acceptance is in progress.
An unlocked app can read your details
That is what a vault is. A jailbroken or otherwise compromised device can read memory while the vault is unlocked.
Screenshots cannot be fully blocked
The app covers itself and clears revealed fields in the background, but iOS does not let apps fully prevent screenshots or recording.
The pairing QR code is a long-term secret
It contains the vault’s long-term key; the 10-minute limit applies only to the pairing code. Never screenshot or photograph it. If it leaks, revoking the device does not help: create a new vault and migrate.
The clipboard has a window
Copies are local to this device and expire after 45 seconds; until then, other apps may still read them.
Deletion relies on destroying keys
Deleting destroys keys so the ciphertext becomes unreadable. It cannot guarantee immediate flash erasure or recall backups you already exported. Sync history is not compacted: after deletion, older encrypted revisions remain in iCloud or on the server, and devices holding the sync key can still decrypt them.
“It passed Apple review, so it’s safe?”
No. We will not use App Store or TestFlight review as proof of security.
What Apple review does
- Scans for known malware
- Checks descriptions, screenshots, and permissions by hand
- Requires a privacy policy and appropriate data safeguards
What Apple review does not do
- Audit whether encryption is implemented correctly
- Prove an app has no vulnerabilities
- Verify the privacy labels developers declare
Compliance boundaries
- QuanCard does not issue cards, connect to banks, handle funds, or provide payments, and it does not help bypass KYC or regional restrictions.
- Apps that use encryption require export compliance filings, which are the responsibility of the publisher, ZOOL LLC.
Transparency roadmap
Trust comes from a record you can check over time, not a single statement. Each item gets a date and evidence when it is done.
- DoneServer and web vault open source (AGPL-3.0)
- DoneBackup and sync protocol test vectors published (Apache-2.0)
- DonePublic security page (this one), including limits and unverified items
- In progressOn-device acceptance: Secure Enclave, Face ID, lock screen, background snapshots
- In progressTwo-device iCloud sync and recovery acceptance
- PlannedPublish the source commit and test summary for each release
- PlannedIndependent third-party security audit, with firm, scope, version, and open findings published
Questions
Was QuanCard written with AI? Is that safe?
AI-assisted coding was used during development. How code is written proves nothing about security either way: hand-written is not automatically safe, and AI-assisted is not automatically unsafe. What matters is whether the design is public and the implementation holds up to scrutiny. That is why this page lists the data flow, key scheme, network destinations, and checks you can run, and states that there is no third-party audit yet.
Can you see my cards?
No, and not because we promise not to look: your data never passes through QuanCard servers, and we do not run any. With iCloud, it sits encrypted in your own Apple Account; self-hosted, on your server.
Why isn’t the iPhone app open source?
The app is a commercial product. We open-sourced the server, web vault, sync protocol, and test vectors so that what the server stores can be fully audited. For the app internals, this page and a planned third-party audit fill the gap.
What if I lose my phone?
Unless iOS itself is compromised, nobody can unlock the vault without your Face ID or passcode, and record contents in the database are ciphertext (apart from metadata such as item counts and versions). To restore on a new phone, you need an encrypted backup (and its password) or iCloud sync already turned on.
What if I forget my backup password?
It cannot be recovered. We do not know it, and there is no back door. That is the cost of zero knowledge, so keep it somewhere safe.
Is the CVC stored and synced too?
Yes, the same way as 1Password and Bitwarden: the CVC is fully hidden by default, needs authorization to view, and is encrypted like the card number. It is included when you sync or export a backup. Collectors don’t need to fill it in, and if you prefer Apple’s approach of not storing security codes, leave it empty. See the CVC section above.
What does this website collect?
The website uses Google Analytics for page-view statistics without personal identity (it sets cookies; advertising features off, Global Privacy Control respected) and stores the email you submit to the waitlist. It has no card entry or vault decryption, and it is unrelated to the data in the app.
How do I report a vulnerability?
For the server and web vault, use GitHub’s private vulnerability reporting. For the app, email support@quancard.app with “Security” in the subject. Use made-up data only; never attach real card numbers, passwords, or backup files.
Still have questions?
Security skepticism is reasonable. Ask us directly, or read the code on GitHub.