Encrypted Trade Evidence — Why the Platform Can't Read Your Messages or Files

By Inveil Research · Updated May 30, 2026

On a well-designed P2P platform, the operator can store your trade evidence and still be unable to read a byte of it. The trick is end-to-end encryption: files and messages are sealed in your browser to the specific people in the trade before they ever leave your device, so the platform handles only ciphertext it has no key to open. On Inveil, every payment proof, delivery address, trade rule, and piece of dispute evidence is encrypted this way — the operator never sees the contents, and on a public chain like Arbitrum, neither does anyone scrolling the ledger. Here's how that works and why it matters.

The problem: P2P trades expose real-world details

A P2P trade is more revealing than an on-chain swap. To complete it, you and your counterparty exchange things a blockchain transfer never touches: a payment screenshot, a bank reference, sometimes a delivery address, the back-and-forth of a chat, and — if a trade goes wrong — evidence submitted to arbitration. On a custodial platform, all of that sits in plaintext on the company's servers, where it can be read by staff, leaked in a breach, or handed over under pressure. The escrow might be safe; the information isn't.

The fix isn't to stop storing this data — disputes need evidence, and both sides need a record. The fix is to make the storage blind: encrypt everything so that only the trade's participants hold the keys.

Multi-recipient envelope encryption, in plain terms

Inveil seals each piece of sensitive data in what's called a multi-recipient envelope. The idea is simple:

• Every user publishes an encryption public key on chain when they first need one. Anyone can encrypt to them; only they can decrypt.
• When you upload, say, a payment proof, your browser encrypts the file to the public keys of exactly the people who should see it — you and your counterparty, plus the arbitration committee if a dispute is open.
• The result is a single sealed blob that each intended recipient can open with their own private key, and nobody else can — not the operator, not another user, not someone reading the storage bucket.

The encryption happens in your browser, before upload. The platform receives a blob it physically cannot decrypt, because it was never a recipient. This is the same principle behind end-to-end encrypted messaging, applied to trade artifacts.

The operator is never in the byte stream

A subtle but important property: on Inveil the worker (the platform's small server component) doesn't even act as a pipe for the encrypted bytes. When you upload, it issues a short-lived, single-use upload URL and your browser sends the sealed blob directly to the storage provider. The operator's server never holds the ciphertext, keeps no per-file record, and isn't a place where the bytes can be intercepted. Its only job is to check you're allowed to upload for that trade and then step out of the way.

Even the file's metadata is hidden. The filename, file type, and size are wrapped inside the encrypted payload rather than attached to it, so the operator can't even see that you uploaded "passport.jpg" or how big it was — it sees an opaque blob and nothing else. The design deliberately keeps the operator's knowledge as close to zero as possible, which is the whole point of what non-custodial should mean: minimal trust in the operator, by construction.

What lives on chain vs in the encrypted blob

You might wonder how a public blockchain fits with private evidence. The split is clean:

• On chain (public, permanent): only a pointer and a fingerprint — the storage address (CID) of the sealed blob and a cryptographic hash of it. The hash lets anyone later prove the evidence wasn't swapped or altered, without revealing what's inside.
• In the encrypted blob (off chain, private): the actual content — the image, the address, the chat, the proof.

So the chain gives you tamper-evidence and a timestamp; the encryption gives you confidentiality. You get a verifiable record that a specific sealed item existed at a specific time, while its contents stay readable only to the trade's participants. This is what makes encrypted evidence inside a transparent dispute process possible — the arbitrators can be added as recipients and read the evidence, while the public ledger shows only that a hash-anchored item was filed.

How it compares

	Custodial P2P desk	Inveil
Who can read your chat / proofs	Platform staff (plaintext)	Only trade participants
Where files are stored	Company servers, readable	Encrypted blob, operator has no key
Operator in the data path	Yes — holds the bytes	No — browser uploads direct
File metadata (name/type/size)	Visible to platform	Sealed inside the ciphertext
On-chain footprint	None / or full data exposed	Pointer + hash only, no content
Breach exposure	Plaintext PII at risk	Ciphertext only — useless without keys

Why this is the right default

Encryption like this costs the user nothing — it happens automatically in the browser — and removes a whole category of risk. There's no plaintext evidence pile for an attacker to steal, no staff member who can browse your trade history, and nothing meaningful to hand over in response to a demand, because the operator genuinely cannot read it. Combined with no KYC and no custodian, it means the platform learns the absolute minimum required to match two traders and enforce an escrow. You can see the model in practice by browsing live offers — the trade flow is built around keeping the operator blind.

FAQ

Can the platform read my trade chat and payment proofs?

On Inveil, no. Everything sensitive — chat, payment proofs, delivery addresses, dispute evidence — is encrypted in your browser to the trade participants' keys before upload, so the operator stores only ciphertext it has no key to open. On a typical custodial desk, by contrast, staff can read this data in plaintext.

If evidence is encrypted, how do arbitrators see it in a dispute?

When a dispute opens, the arbitration committee members are included as recipients of the encrypted evidence, so they can decrypt and review it — while the public chain shows only a hash-anchored pointer, not the contents. The encryption restricts who can read the evidence; it doesn't prevent the people who must read it from doing so.

Is anything stored on the public blockchain where everyone can see it?

Only a pointer (the storage address) and a cryptographic hash of each sealed item — never the content itself. The hash provides tamper-evidence and a timestamp; the actual file or message stays in an encrypted blob readable only by the trade's participants. So the ledger proves that evidence existed without revealing what it was.

Does the operator at least see file names or sizes?

No. The filename, type, and size are wrapped inside the encrypted payload, so the operator sees an opaque blob with no metadata. It also never holds the bytes — your browser uploads them directly to storage via a single-use URL — so there's no point at which the operator can inspect what you sent.