Privacy

Everything that happens on InVeil happens on Arbitrum. That doesn't mean everything is publicly readable. Sensitive fields — payment instructions, dispute evidence, in-trade chat — are encrypted before they touch the chain, and only the parties who need them can decrypt. This page is the full breakdown of what's public, what's private, and who holds the keys.

Public vs encrypted — the line

The rule of thumb: protocol state is public; user content is encrypted.

Public, plaintext on-chain:

• Which wallet addresses are involved in an order, and on which side.
• The order's status — open, taken, paid, disputed, settled.
• The trade amount, the security stake, the price.
• The list of accepted payment methods (e.g. "PayNow," "SEPA," "AliPay") — the category, not the credentials.
• Timestamps for every state transition.
• Reputation aggregates — win-rate, volume, first-active date — derived from on-chain history.
• Panel composition (committee members are addresses, not identities) and vote tallies.

Encrypted, unreadable on-chain except to specific recipients:

• Payment instructions — bank account number, phone number for QR-based methods, IBAN, etc.
• The shipping address or wallet address the seller commits to for the goods.
• The free-form terms text on offers, if the maker chose to encrypt it (some makers leave terms plaintext intentionally to attract takers; the choice is theirs).
• In-trade chat between buyer and seller.
• Dispute evidence — every screenshot, every PDF, every receipt.

How the encryption works

Every wallet on InVeil publishes an x25519 public key to the on-chain EncPubkeyRegistry the first time it acts. The corresponding private key never leaves the user's device — it's derived from the session key inside the smart account on first sign-in and cached in the browser's local storage, encrypted by the session.

When something sensitive needs to be sent on-chain, the sender pulls the recipient's public key from the registry, encrypts the payload locally, and writes only the ciphertext on-chain (via IPFS pinning — the CID, not the bytes, lives in the contract). The recipient pulls the ciphertext from IPFS and decrypts it locally using their derived private key.

For disputes, the same primitive runs N-to-M: the parties wrap the evidence to every committee member on the panel at once, using each member's published pubkey. The contract enforces who's on the panel; the parties trust the keys, not us.

What InVeil's operator can and can't see

We cannot read your payment instructions, your address, your chat, or your dispute evidence. The encryption uses keys we never had access to — the recipient's x25519 public key is the only thing on-chain, and the corresponding private key derives from material we never see.

Concretely, here's what we operate:

• A frontend bundle served via Cloudflare Pages. The bundle is what you load when you open inveil.io. It connects directly to chain RPC and to IPFS gateways for ciphertexts; we don't see the data passing through it.
• An IPFS pinning account at Filebase, where the encrypted blobs are stored. Filebase sees encrypted bytes and a CID. We see the same — no per-blob metadata is held by us beyond the CID, because filename, mime type, and size are encrypted inside the envelope.
• A Telegram bot for notifications. The bot sees "wallet 0xABC has a new order event" and pushes a message to the @handle that's currently bound. It doesn't see payment data; that data isn't in the notification.
• A small notification worker that polls chain logs every 30 seconds for events worth pushing to Telegram. It reads public on-chain state, nothing else.

That's the entire surface. We have no user database. We don't store an email, a password, a phone number, a name, or a payment method. We don't log IP addresses; we don't fingerprint browsers; we don't run analytics on user behavior.

What other parties can see

Your counterparty sees what you sent them, end of list. Payment instructions, shipping address, chat — only the active counterparty can decrypt these for a given order. Once the trade settles, the data is still on-chain but only the keys you both already hold can unlock it.

The dispute panel sees the evidence both sides upload — and nothing else. They see the order's public state (amounts, status, timestamps) and the encrypted evidence, but not the trade chat, not the original payment instructions, not anything the parties chose not to put into evidence.

The public sees what's on-chain in plaintext. That includes your wallet address and your trading history — InVeil is pseudonymous, not anonymous. If you want to keep your trades separated from a public-facing wallet, use a different address.

What lives on IPFS vs on Arbitrum

Both are public networks. The split is about size and cost:

• Arbitrum holds protocol state and the CID pointing at any ciphertext. CIDs are tiny (32–46 bytes); writing them on-chain is cheap.
• IPFS (via Filebase) holds the actual encrypted blobs — payment instructions, chat payloads, evidence files. Storing a JPEG screenshot on Arbitrum directly would cost more than the trade itself; IPFS handles it for fractions of a cent.

Both are public networks in the sense that anyone can download the blob from IPFS once they know the CID. The CID is on-chain, so anyone can find it. The blob is encrypted, so nobody can read it without the key. The combination — public pointer, encrypted content — is the same shape the rest of the web uses for end-to-end encrypted messaging.

"Public on-chain" is not "publicly readable"

This is the core distinction. If you've encountered blockchain projects where "decentralized" came with "everything you do is on a billboard," InVeil's design rejects that trade-off explicitly. The protocol uses the chain for what it's good at (auditable state, no central operator) and uses encryption for what the chain is bad at (revealing the wrong things to the wrong people).

The cost of this is engineering complexity, not user experience. From the trader's side, you click "send payment instructions," the app encrypts and uploads in one step, and the counterparty gets a notification. Whether the bytes live in a database or on IPFS, whether they're encrypted to one key or three, is the app's job to handle. You see your payment instructions; your counterparty sees them; nobody else does.

What InVeil's UI does and doesn't surface

Even though the chain remembers every order forever, our own indexer and UI deliberately don't surface stale activity:

• Active and recent orders appear in the Market feed and in your history.
• Seven days after an order settles, the InVeil UI stops surfacing it in your history, in search, in any feed we render. The on-chain record is unchanged; it's still readable from any block explorer or RPC. We just don't think it should clutter the app's view.
• Reputation aggregates are computed across all history (not just recent), so a senior trader's win-rate still reflects three years of activity even though no individual line item is rendered.

We can't promise to delete on-chain records — we can't, nobody can. What we can promise is to be honest about what's there and to render our own product the way we'd want it rendered if it were our trade history.

Things you can do to make yourself harder to fingerprint

• Use a fresh address per identity. If your day-job wallet is doxxed and you want a trading identity that isn't, generate a new wallet — the passkey model makes spinning up a new account a 30-second action with no email or phone.
• Don't reuse Telegram handles across identities. The bot binds whatever @handle you give it. If you want unlinkable trading personas, use separate Telegram accounts. We don't store the handle, but your counterparty can write it down.
• Pick payment methods carefully. A bank account in your legal name reveals your legal name. If counterparty-level anonymity matters, prefer methods that don't require legal identity (cash drop, crypto-to-crypto, etc.).
• Use a VPN or Tor for the bundle. Cloudflare Pages sees your IP every time you load inveil.io, the same as any website. A VPN or Tor breaks that link. The product works fine over either.

What would change if InVeil disappeared

The Cloudflare-hosted frontend would go down. Your funds would stay where they are — in the audited Arbitrum contracts your passkey controls. Your encrypted evidence and chat would stay on IPFS as long as Filebase keeps it pinned; if we stopped paying the pinning bill, anyone could re-pin the CIDs from their own pinning account (they're public). A new frontend, served from anyone's machine, would read the same chain state and decrypt the same blobs you can decrypt today.

Privacy doesn't depend on us being here. It depends on the keys staying on your device and the ciphertexts staying on a network we don't control. That's the design.