FAQ
Running list of the questions we get most often. If you have something you think should be here, let us know and we will add it.
Is it safe?
How does InVeil sign me in?
With a passkey — the same biometric you use to unlock your phone. Face ID, Touch ID, Windows Hello, your Android fingerprint. The key material itself is generated by your device, lives in its secure enclave, and never leaves. There is no email-and-password to phish, no seed phrase to copy down, no browser extension to install. We never see your key, never store it, never generate one for you.
On Apple devices your passkey rides on iCloud Keychain; on Android and Chrome it rides on Google Password Manager. Sign up on your phone, your laptop sees the same account when you sign in there — no QR-scan dance, no manual copy step. Cross-device just works.
Does InVeil see my face when I use Face ID?
No. Face ID happens entirely on your device — InVeil has no way to read your biometric data, and the standards your phone uses for this (WebAuthn / FIDO2, backed by Apple, Google, Microsoft, and every major browser) are designed specifically so that we couldn't, even if we tried.
Mechanically: your device has a dedicated security chip (Secure Enclave on iPhone and Mac, Titan / StrongBox on Android, TPM on Windows). When you sign up, that chip generates a cryptographic keypair and keeps the private half inside itself — it physically cannot be exported. Face ID's only job is to ask your device "is the owner present?" If yes, the chip uses that private key to sign one message for InVeil. We receive the signature. We do not receive your face, your fingerprint, the raw biometric template, or the private key.
It's the same model your banking app, Apple Pay, and password managers like 1Password use to unlock with Face ID. We didn't invent this; we use the industry standard. Compared to "email and password" or "12-word seed phrase," passkeys are strictly safer for you: there's no password to phish, no seed phrase to photograph, and our database being breached tomorrow would give an attacker nothing useful — because no key material was ever stored on our side to begin with.
What's a session key — does InVeil have a key to my account?
No. Your passkey is the master — it's the only key that can authorize moving funds out, changing your account, or doing anything sensitive. The "session key" is a separate, short-lived helper key registered inside your account on-chain, scoped to a small whitelist of InVeil contracts (escrow, dispute committee, juror registry). It exists so normal trading actions can settle in one tap without prompting Face ID for every signature.
The whitelist is enforced by the account contract itself, not by us. The session key cannot move USDT to an outside address, transfer your ETH, approve tokens to third parties, or call anything outside InVeil. Each session lasts 24 hours, then expires; the next time you act, your passkey signs a fresh one.
If you ever suspect a device is compromised, sign out — the active session is wiped locally and stops being usable. Anything truly dangerous still requires a fresh passkey signature, which only happens on a device that holds your passkey.
Who holds the keys to my funds?
Your device does — and through Apple's iCloud Keychain or Google's Password Manager, your other signed-in devices do too. InVeil never had access to your passkey's private material in the first place, so there is nothing for us to hold or lose. Concretely: InVeil cannot sign a transaction for you outside the session-key whitelist. InVeil cannot freeze or seize your account. InVeil cannot recover your passkey if you lose access. If InVeil disappeared tomorrow, your funds stay yours — the custody contracts are on Arbitrum, you still hold the passkey, and the contracts have always-callable withdraw paths your account can invoke directly.
The flip side, said plainly: if you lose every device that holds your passkey AND your iCloud / Google account that syncs it, the account is gone. This is the same recovery model as Apple Pay, iCloud Keychain, and any other passkey-based product — recovery flows through your platform account (Apple ID, Google Account), not through us. Treat that account the way you'd treat a hardware wallet's seed phrase: keep its recovery options up to date.
Can InVeil's creators move your funds?
No. The vault that holds user balances (TradingVault) has no admin-withdraw function, no "emergency drain," no privileged transfer path. The only movements of your USDT are the ones the protocol rules allow: an escrow release after you confirm receipt, a refund on a cancelled or timed-out order, a dispute settlement payout when a case resolves. Thewithdraw()function is always callable by you, and is not gated by the owner's pause switch — even if InVeil paused new deposits tomorrow, you could still pull every cent of your balance out on the next block.
What can the owner do? Narrow, capped knobs: adjust the commission (hard-capped at 10% in the contract), point the treasury address at a different wallet, upgrade the logic contract that the vault listens to, pause new deposits. None of those let the owner reach into a user balance and take it. The contracts are deployed on Arbitrum and verified on Arbiscan — you can read the source yourself before trusting us on this.
What happens to my funds if InVeil's servers are attacked or go down?
Your funds are unaffected. They don't live on our servers — they live in non-custodial smart contracts on Arbitrum, controlled by your passkey. Our servers can be down, breached, or seized; the contracts keep running, and your access to them is unchanged.
Concretely, with just a wallet and any public Arbitrum RPC, you can still: browse the market, post or cancel offers, mark shipped, confirm receipt, file or escalate a dispute, and call withdraw(). None of those paths route through our backend. The frontend itself is plain static files — if inveil.io is blocked, the same bundle can be served from any IPFS gateway, and we're working toward making that the default serving path so the product stays reachable even if the domain is taken down.
What our server actually does is narrow and optional: Telegram push notifications, social-share preview pages, and signing short-lived upload tokens so your browser can put encrypted attachments directly into storage (the server never sees the bytes). If our server vanishes overnight, you lose notifications and preview cards. You do not lose access to any money, any open order, or any dispute in flight.
The deeper guarantee is structural: TradingVault has no admin-withdraw, no emergency drain, no privileged transfer path. withdraw() is always callable by you and is not gated by any pause switch. Even if InVeil's entire team disappeared tomorrow, you could pull your full balance out from the contract directly, using any wallet that holds your passkey.
Is my Trading balance safe while it's earning yield?
InVeil doesn't run its own lending or staking — we stay focused on P2P. Your idle USDT is supplied to Aave on Arbitrum — widely regarded as the most battle-tested lending protocol in DeFi. Aave's core lending contracts have stood up across multiple market cycles without a protocol-level exploit, and it has been the de facto safety benchmark for on-chain lending for years.
Concretely: your idle USDT lives in your own smart account, and that account supplies it to Aave directly — the aUSDT receipt token sits in the same smart account, under your passkey. When you take an offer, the exact amount needed is withdrawn from Aave and locked into the escrow contract in a single transaction; when you cancel or settle a trade, the released funds go straight back. InVeil never custodies the assets, never pools them with other users' funds, and never rehypothecates. Your exposure on the yield-earning portion is essentially "Aave on Arbitrum" — the same risk surface as supplying USDT to Aave directly.
You keep 100% of the Aave yield. InVeil takes no cut on interest — our only revenue is the 0.2% successful-trade commission. The "APY" number shown on the Fund page is the live Aave USDT supply rate, read straight off the pool, with no platform deduction.
The remaining risk is the standard one for any smart-contract product: a bug in Aave itself or in the small wrapper functions on your smart account that route funds in and out of the pool. We don't claim DeFi yield is risk-free; we do think Aave is the safest underlying available, which is why it's the only protocol we integrate.
Funds currently locked in an active trade — escrowed principal, the buyer's anti-fraud stake, in-flight refunds — do not earn yield. They sit as plain USDT inside TradingVault, 1:1 backed and untouched by Aave. The split between earning and locked happens transparently across your smart account (idle, in Aave) and the vault (locked, plain USDT); you see one combined Trading balance.
How does it work?
How does InVeil make money?
One stream: a single trading commission. 0.2% of the trade amount (20 basis points), charged only when a trade actually settles in the buyer's favor — confirmed receipt, agreed partial settlement, or a buyer-wins dispute. Cancels, timeouts, and seller-wins disputes pay nothing. The fee comes off the buyer's side: it is deducted from the seller's escrowed principal before the remainder credits to the buyer, so the buyer nets received − commission. "Trade amount" is the USDT principal in escrow — not security stakes, not dispute fees, not gas. No spread, no withdrawal fee, no subscription, no data sales.
That's it. We take no cut on Aave yield — the idle portion of your Trading balance is supplied to Aave directly from your own smart account and you keep 100% of the interest. If a trade doesn't settle, we don't earn.
Carrying an idle Trading balance also gives serious traders a way to signal capital strength: your unlocked Trading balance is surfaced on the Market page next to your listings (the "X USDT available" line on each card), so counterparties can see the size of your reserve before they engage.
How do you ensure arbitration is fair?
Today, every dispute is reviewed by the Senior Arbitration Committee — a fixed panel of three vetted arbitrators. They read both parties' encrypted evidence inside a 48-hour evidence window, then vote during an 18-hour deliberation. The ruling is binding on-chain. There is no off-platform back channel, no extension button, and no path for a panel member to "settle this offline" — the only way to release escrow is through the on-chain vote.
We're upfront that a committee is a centralized mechanism. The reason we chose it over a small "decentralized" pool is that random-draw arbitration is only fair when the pool is large and diverse enough for the draw to actually be random — and InVeil isn't there yet. A small staked pool is worse than an accountable committee, because in a small pool a single juror can learn who the parties are just from the pattern of cases they're drawn into. So the trade we made was: pick the most accountable centralized arrangement available — a three-seat panel composed of the founding team, on the hook for every ruling — rather than ship something we'd have to call decentralized while knowing it wasn't.
If the platform reaches the volume where a real staked pool can sustain random draws, the plan is Inveil v2 — a rebuild in Arbitrum Stylus introducing L1–L3 decentralized arbitration on top of Schelling-point commit-reveal voting, with the Senior Committee retained as the final-appeal seat. Full writeup on the Arbitration page; gating conditions on the Roadmap.
Why is an arbitration ruling all-or-nothing — no 70/30 split?
In the overwhelming majority of trades — about nine out of ten — nothing goes wrong: the buyer receives what they expected, confirms receipt, and escrow releases. That is the case the product is optimized for. When something does go sideways — a damaged item, a partial defect, the wrong amount — we believe the best handling is for the two people who actually ran the trade to negotiate the split themselves. Partial settlement is built for exactly that: either side proposes "release X USDT to the buyer, refund the rest to the seller," and the other side accepts. Any number from 1 USDT up to the full trade amount works, and no arbitrator ever enters the picture.
The alternative — both parties step onto the stage and ask InVeil to be the negotiator — isn't the model we set out to build. It doesn't fit our philosophy, and structurally we couldn't do it anyway. Philosophy first. InVeil's arbitration mechanism — today's committee, and the staked-pool design in v2 — is anchored in the Schelling point, a concept from Nobel laureate Thomas Schelling describing the default choice that independent actors converge on without communicating. For arbitrators reading evidence in isolation, who is in the right is a Schelling point: the honest read of the facts is the obvious answer they all gravitate toward. What percentage is fair has no focal point — there is nothing for independent jurors to coordinate on.
The mechanics follow the philosophy. The three Senior Committee members don't know one another and don't communicate during deliberation. If their votes were "what percentage should the buyer receive," it would be statistically near-impossible for all three to land on the same number — one might say 60%, another 65%, the third 75%. There is no rule that turns three uncoordinated percentages into a single on-chain outcome both parties would accept as fair. Only a binary vote — buyer or seller — produces a tallyable, enforceable ruling.
The binary shape is the point: arbitration's job is to name a real winner, not to grade the margin. Whichever side the majority of the panel sides with takes the whole pot — their own principal back, plus the loser's forfeited security stake (net of the 0.2% commission). A 2-1 ruling settles the same way as a 3-0. If the truth is genuinely somewhere in the middle, settle in the middle yourself — partial settlement is open right up until the moment a dispute is filed. Arbitration is the path for the cases where no middle number would be honest.
How does InVeil handle your data?
We don't run a backend database. Every piece of order state — who posted what, who funded, who confirmed, who disputed — lives on Arbitrum. The sensitive fields (payment instructions, dispute evidence, chat payloads) areencrypted before they touch the chain, using keys only the counterparty and, where needed, assigned jurors can derive. "Public on-chain" does not mean "publicly readable" for anything that would identify you.
For finished orders: the data is still on-chain forever — we can't delete it and wouldn't claim to. What we do control is our own order book. Seven days after an order settles, InVeil's indexer and UI stop surfacing it; it won't appear in your history, in search, or in any feed we render. If you genuinely need to look it up, the raw encrypted record is still queryable directly from the contract. We don't think most users want a pile of stale history cluttering the app, and we don't think InVeil should be the party keeping that index alive.
I only have USDT on Tron — how do I get USDT on Arbitrum?
Use a multi-chain wallet's built-in swap. Wallets like OKX Wallet, Trust Wallet, Bitget Wallet, and TokenPocket all support both Tron and Arbitrum side by side, with a Swap page that handles the cross-chain step for you. Pick USDT on Tron as the source, USDT on Arbitrum as the destination, confirm. Then send the Arbitrum USDT to your InVeil wallet address.
Triple-check the destination network before you confirm. USDT lives on a dozen different chains and they don't talk to each other — sending USDT on the wrong network is the single most common way to lose funds, and no one can reverse it. The wallet will name both networks explicitly; make sure the output side says Arbitrum (sometimes shown as Arbitrum One) before you tap confirm.
How do I get ETH for gas?
Quick context first: ETH on Arbitrum is the same asset as ETH on Ethereum mainnet, but any given unit of ETH lives on one chain at a time. InVeil runs on Arbitrum, so the ETH you need for gas has to be ETH that's already on Arbitrum — mainnet ETH alone won't pay for an InVeil transaction.
Easiest way to get some: the same multi-chain wallet swap from the previous question. Pick USDT on Tron (or whatever you happen to hold) as the source, ETH on Arbitrum as the destination, swap a small amount. A few dollars' worth is plenty — gas on Arbitrum runs in fractions of a cent, so a five-dollar top-up will cover hundreds of trades.
I sent USDT (or ETH) on the wrong network — can InVeil recover it?
No, and we'd rather be straight with you about this than leave you waiting on a fix that isn't coming. Your InVeil deposit address is a smart account we created specifically on Arbitrum — its contract code is deployed at that address on Arbitrum, and nowhere else. On Ethereum mainnet, BSC, Polygon, Tron, or any other chain, the same string of characters is either a totally unrelated contract or an address no one controls. Your passkey proves ownership of the account on Arbitrum; it has no power on any other chain, and neither do we.
This is the flip side of the property that makes InVeil safe. Nobody — not us, not a court, not a hacker who breached our servers — has an admin backdoor into your funds. The same wall that keeps your Arbitrum balance safe is the wall that makes mis-sent funds on the wrong chain unreachable. We're sorry; there is no path we can offer here.
Before you confirm any transfer to your InVeil address, the sending wallet must explicitly show the destination network as Arbitrum (sometimes labelled Arbitrum One). If it shows Ethereum, BNB Chain, Polygon, Tron, Optimism, Base, or anything else, stop and switch the network before tapping send.
I sent funds to the wrong address — can InVeil recover them?
No. Blockchain transactions are final by design — there is no "cancel" button, no chargeback, no central operator who can reverse a transfer. The address you sent to belongs to whoever holds the keys for it, or to no one at all if you mistyped a string that doesn't correspond to a real account. InVeil has no special privilege over arbitrary Arbitrum addresses; we can't pull funds out of someone else's wallet on your behalf, the same way no one can reach into yours.
If the destination happens to be a person or platform you can identify — a friend, an exchange's deposit address you confused with this one — your only path is to contact them directly and ask. Often that goes nowhere, because the recipient has no obligation to return anything, but it's the only door that exists.
Two habits prevent almost every typo: before sending, check the first four characters and the last four characters of the destination against what's shown on the receive screen, not just one end. And whenever you can, scan the QR code instead of pasting an address — it eliminates the typo class entirely.
Why is it built this way?
Why does InVeil split your money into Wallet and Trading?
Two pools, one owner — you. The split isn't about custody (both are non-custodial); it's about what the money is doing right now. Wallet is idle on-chain assets you brought with you. Trading is USDT you've explicitly chosen to put to work — earning Aave yield while it waits, and ready to move into escrow the moment you take an offer. You can move money between them whenever you want.
Wallet is your smart account's raw USDT and native ETH — assets your passkey directly controls. This is the universal inbound landing zone: external transfers (CEX withdrawals, peer-to-peer sends, the receive QR) and trade proceeds from counterparty-initiated releases (settlements, dispute payouts) all land here. It's also where you keep a small amount of ETH for gas; the contract enforces a live minimum (shown on the Fund page) and any escrow action reverts below that threshold.
Trading is your deposited USDT, in two parts. Available is the unlocked portion — held as aUSDT in your own smart account, earning Aave yield 24/7. Locked is the portion currently held by the TradingVault contract as collateral on an open offer or active trade. Every escrow movement — seller locking principal, buyer posting a security stake, refunds, releases, commission — happens inside this vault. When you take an offer, the exact amount needed is withdrawn from Aave and locked into the vault in a single transaction; when the trade settles or cancels, funds flow back. Withdraw is always callable on the available portion — no cooldown, no owner approval.
On top of that, the available portion isn't sitting idle — your own smart account supplies it to Aave on Arbitrum so it earns the standard USDT lending yield, with 100% of the interest credited to you. Locked funds stay as plain USDT inside the vault, 1:1 backed and untouched by Aave; only the unlocked share earns. The move into and out of Aave happens transparently on every action, so taking an offer still settles in a single transaction. There is no separate "funding" pool to manage: idle money is already earning by default.
Does InVeil have competitors?
Not a close one that we're aware of. The mainstream P2P surface is still centralized exchanges with KYC and custodial balances — a different product category, even if the UX overlaps. We haven't found another platform that combines non-custodial escrow, no-KYC onboarding, and encrypted on-chain payment details the way InVeil does.
That won't stay true forever, and we don't want it to. The "hand your ID and your coins to a central party" model is winding down; more non-custodial P2P platforms will show up, and that's healthy for the space. We'd rather compete on execution than on being the only option.
FAQ