Every app says it encrypts your data. Saying it costs nothing. This page is the opposite: for each promise we make, you get the mechanism, the exact source code that implements it, and a test you can run yourself — right here, without an account.
It also lists the things we refuse to claim. That part matters more than the green ticks. Anyone can build a page of green ticks.
Loading live results…
Loaded from this server the moment you opened the page — not a screenshot, not a report from last quarter. Several of these are falsifiable counts: queries that would expose us if the claim were false. If one ever goes red, it stays red. Tap any row to open it.
The strongest claim we make is that end-to-end messages are encrypted on your device, so our server only ever holds scrambled bytes. You don't have to believe that. The button below loads the real encryption file this site uses — /e2e.js, the same one that runs when you send a message — generates two keypairs, encrypts a message between them, and shows you exactly what our server would receive.
Nothing is sent anywhere. Open your browser's network tab and watch: this runs entirely on your machine.
Why this is real proof: the ciphertext you see is byte-for-byte what our database stores. The decryption at the end succeeds only because your browser holds the private key. Our server never has it — there is no code path in /e2e.js that transmits one, and you can read all 126 lines of it in under a minute.
The single most useful question about any service is not "is it encrypted" — almost everything is. It's who holds the key. Here is every category of thing you can put into XSCN, and the honest answer for each.
| What | Protection | Where the key lives | Can XSCN read it? |
|---|---|---|---|
| Vault items passwords, card numbers, private notes | AES-256-GCM, encrypted in your browser | Derived from your passphrase (PBKDF2, 150k iterations). Never transmitted. | No. Structurally impossible — there is no column it could be in. Lose the passphrase and it is gone for good. |
| End-to-end messages | ECDH P-256 → AES-256-GCM | Your private key, wrapped with your PIN before upload. We store a blob we can't open. | No. We hold ciphertext. Metadata (who, when) — yes, always. |
| XSeed Cloud files | AES-256-GCM in your browser, then split into shards | Derived from your storage passphrase. Never transmitted. | No. Each shard is a fragment of ciphertext. |
| Notes, health records, asset photos, deal notes | AES-256-GCM at rest | Our server environment | Yes, technically. This stops a stolen database file or a database console. It does not stop the operator. We are not going to imply otherwise. |
| ID photo for age verification | AES-256-GCM at rest, then deleted | Our server environment | Yes — briefly, on purpose. A human has to look at it to verify you. The row is destroyed the moment it's approved or rejected. |
| Readable-mode messages | At rest only | Our server environment | Yes. That's the point of the mode — it lets the AI help. It's labelled in the chat every single time. |
| Password / PIN | bcrypt hash | Nowhere — a hash isn't a key | No. We can reset it, never reveal it. |
| Listings, profile, balances, orders, reviews | Transport encryption only (HTTPS) | — | Yes. Operational data. Running a marketplace requires reading it. |
| Who you messaged, when, how much you sent | None | — | Yes. Encryption hides contents, never metadata. This is true of Signal too. |
| Camera footage | At rest | Our server environment | Yes. Face Watch is off unless you enable it on your own cameras, and it only matches against faces your own cameras have seen — never an outside database. |
XSCN is not open source and we're not going to pretend it is — the product is how we intend to make a living. But the cryptography has no business value in secrecy, and a security claim you can't inspect is just a slogan. So the files that implement every encryption and privacy claim on this page are published in full, served straight from the running server, with a SHA-256 of the exact bytes.
Fetch a file, hash it yourself, and compare. If they differ, something is wrong and you should say so loudly.
The last one is worth doing. privacy.js contains a self-test that empirically demonstrates the differential-privacy guarantee holds — it runs 400,000 trials on two datasets differing by exactly one person and shows you can't tell them apart. It exits non-zero if the maths fails. It's our claim, proven on your computer, not ours.
Proof surfaces that already run elsewhere in XSCN, collected here so they're reachable from one place instead of scattered.
privacy.js and run node privacy.js. It runs 400,000 trials on two datasets differing by exactly one person and demonstrates you can't tell them apart. It exits non-zero if the maths fails.This is the section that should decide whether you trust the rest of the page. It costs us something to write, which is exactly why it's here.
Written to be answered honestly, not to close a sale.
Depends which files, and I'm not going to blur it.
Vault items, end-to-end messages and XSeed Cloud uploads: no. Those are encrypted on your device with a key derived from a passphrase that never reaches my server. There's nowhere for me to store it and no code path that sends it. That's why losing the passphrase means losing the data permanently — including for me.
Everything else — your listings, your notes, your asset photos, your ordinary chats — yes, technically I can. They're encrypted at rest, which protects you if the database is ever stolen, but I hold that key because the app has to decrypt them to work. Anyone claiming otherwise about equivalent data is lying to you or doesn't understand their own system.
Do I? No. But "no" from me is a promise, not a proof, and I want you to know which of the two you're getting in each case.
Blunt answer, because it's a fair question about a one-person company: the site keeps running until the hosting bill goes unpaid, and then it stops. That's weeks, not years.
What that means for you, concretely: anything you can export, export. Your Vault contents are encrypted with your passphrase — if you've written it down somewhere your family can find, those items survive anywhere the ciphertext survives; if you haven't, they're unreadable to everyone forever, including whoever ends up with the servers.
Formal continuity — an escrow arrangement, a named successor operator, an automated export-and-notify — is on the roadmap and is not built. Until it is, don't make XSCN the only place a thing exists. That's true of any service, but it's more true of this one, and pretending otherwise would be exactly the kind of thing this page exists to stop.
Run the features you asked for. That's the whole list.
The business model is deliberately not built on you: a small cut on optional transactions, a margin on AI usage you choose to spend. Not attention, not resale, not a data-broker back door. That's not a policy I could quietly reverse — it's why nothing here is designed to profile you.
There's exactly one exception, and it's opt-in and off by default: the Fair Data program. If you switch it on, aggregate counts about your region can be sold — with random noise added, never released unless at least 5 real people are behind the number, and with a daily query budget so no buyer can average the noise away. You get paid a share when it sells. The maths is published and ships with a test that proves it on your own machine.
What I can't control is what a buyer does with an aggregate afterwards. So instead of promising to police them, the release itself is built to be incapable of pointing at you.
Honestly? Partly you shouldn't, and you should size your exposure accordingly. One person is one point of failure — no second pair of eyes on a deploy, no security team, no one to take over on a bad week. That's a real risk and it doesn't go away because I'm careful.
What one person does give you is that there's no committee between a problem and the person who can fix it, no growth target that makes selling your data suddenly attractive, and no plausible deniability. If something on this page turns out to be false, it's not a miscommunication between departments. It's me.
Which is why this page is built the way it is: mechanisms you can read, source you can hash, counts that would expose me if I were lying, and a list of things I won't claim. That's the most trust one person can honestly ask for. Anything above that, don't give me.
XCash is closed-loop in-app credit — you buy it, you spend it inside XSCN. There's deliberately no cash-out, so don't treat it as savings.
On whether it can vanish or be conjured: the books reconcile in public, continuously. Seven invariants get re-checked on a schedule — every balance against its own ledger rows, dollars received against credits issued, an append-only hash chain that catches any retroactive edit. If they ever disagree, the system says so in public and freezes minting and spending itself rather than trading on books it can't prove.
The honest limit, which that page states itself: it's a reconciliation the system attests to, not a cryptographic guarantee against an operator with database access. It catches bugs, corruption and accidents. It doesn't make me honest. Also: no loss-of-funds insurance, no third-party audit. Don't hold more than you'd be comfortable carrying as cash.
Not unless you switch it on. AI access to your personal data is consent-gated and off by default (Profile → Trust Center).
It cannot read end-to-end messages or your Vault at all — there's no key to read them with. There is one deliberate exception you trigger yourself: you can decrypt a single vault entry in your browser and hand that one item to the assistant for one reply. It isn't stored and isn't logged. Nothing else in the Vault is reachable.
When you use an AI feature, that text does go to a model provider to generate the answer — it has to. Under their API terms it isn't used to train their models, and I don't train anything on your content either. What I can't do is audit them for you, so treat that as a supplier dependency rather than a guarantee from me.
For end-to-end chats: I can hand over what I have, and what I have is scrambled bytes. Not a stance — an architecture. I don't hold the key.
But be precise about what that protects. Metadata is not encrypted and never will be. Who you messaged, when, how often, and how much money moved is all visible to me and is producible under a valid legal order. In many investigations that's the more useful half. Encryption protects contents; it does not make you invisible.
Everything else — listings, deals, ordinary chats, camera clips — I can read and can be compelled to produce.
Ask through Support and I delete it by hand, usually within a few days. There is no self-serve delete button yet — that's the truth, and it's why the app now says so rather than implying one exists.
Some records survive deletion because they legally have to: transaction records for tax and accounting, and anything under an active fraud or safety investigation. Anyone promising you a truly complete wipe while also running a payments ledger is either mistaken or not telling you about their tax obligations.
Tell me, through Support or any channel you can reach me on, and I'll either fix the code or fix the sentence — and I'll fix it publicly.
That's not a courtesy. For a company whose entire pitch is doing this legally and transparently, an overclaim is worse than a bug: a bug breaks a feature, an overclaim breaks the only thing that makes the rest of it worth anything. Every claim on this page was written by checking the code first and the marketing second, and several sentences elsewhere in the app were corrected downward to build it. That's the process working, and I'd rather it kept working with your help than not.
Independent references, so you're not only reading our word for the concepts above: MDN Web Crypto · OWASP password storage · EFF on metadata · Differential privacy