Privacy & Confidentiality FAQ

Modified on Tue, 23 Jun at 3:17 PM

Wirex One is built on next-generation infrastructure that keeps your money truly yours and your financial activity private — without giving up the speed and convenience you expect from a modern banking app. This FAQ explains how, in plain language first, then in technical depth for those who want it.

The privacy capabilities below come from Circle Arc, the payments-grade blockchain Wirex One runs on, and specifically its built-in privacy layer, the Arc Privacy Sector (APS). Wirex builds on this infrastructure through its partnership with Circle.

Part 1 — The basics

Is Wirex One private?

Yes. Unlike most crypto and "stablecoin" apps where every balance and transfer is visible to anyone on a public blockchain, Wirex One runs on infrastructure with a built-in privacy layer. Your balances, transactions, and account details are encrypted by default — they are not broadcast to the world.

Who can see my balances and transactions?

Only you, and parties you explicitly authorise. On the underlying network, your financial state is encrypted and shielded. Outside observers — other users, analytics firms, the public — cannot read your balances or trace your payments the way they can on an ordinary public blockchain.

Can Wirex see everything I do?

Wirex One uses a non-custodial model: you truly own your assets and control them directly, rather than handing them to Wirex to hold. As a regulated financial institution, Wirex still performs the identity and compliance checks the law requires, but the architecture is designed so your day-to-day balances and transactions stay private by default rather than sitting in a database anyone can mine.

Do I really own my money?

Yes — this is what we mean by true ownership. Your assets are held in a non-custodial wallet that only you control, created through Wirex's partnership with Privy. You get this with the simplicity of a normal app: no complicated setup, no codes to write down and lose. Your assets, your control.

Blockchains are supposed to be public — how can this be private?

That is exactly the problem Wirex One's infrastructure was designed to solve. Traditional public blockchains expose every balance and transfer to everyone, which is a non-starter for real banking. Circle Arc adds a privacy layer that keeps your financial state encrypted while still settling on-chain, so you get the integrity and finality of a blockchain and the confidentiality of a private account.

What is the "privacy layer"?

It is a confidential environment that sits alongside the public ledger. Your private transactions are encrypted before they ever leave your device and are only ever decrypted inside secure, tamper-proof hardware. The public ledger records that a private transaction happened, but its contents stay sealed.

Is Wirex One anonymous? Can I use it to hide from authorities?

No, and that is not its purpose. Wirex One is a regulated product and meets its legal and compliance obligations, including identity verification. Privacy here means your financial life is not exposed to the general public, competitors, advertisers, or data scrapers — it does not mean evading lawful obligations.

I've heard Wirex One isn't subject to DAC8 reporting — what does that mean?

DAC8 is an EU directive (effective 1 January 2026) requiring custodial crypto platforms to report customer transaction data to tax authorities. Because Wirex One is non-custodial — you hold your own assets rather than Wirex holding them for you — it falls outside that reporting scope. This is a matter of financial privacy by architecture: it reflects how the product is built, not a way to avoid tax. You remain responsible for your own tax obligations as always.

If something happened to Wirex, could I still access my funds?

Because the model is non-custodial, your assets live on-chain under your control rather than on Wirex's balance sheet. True ownership means you are not dependent on Wirex continuing to hold your money for you.

Part 2 — How the privacy actually works

If the blockchain is public, how can my transaction be private?

Your transaction is encrypted on your device before submission. What gets posted publicly is only opaque ciphertext plus a fixed, predictable fee — no amounts, no balances, no recipient logic. The transaction is decrypted and processed only inside secure hardware, and what comes back onto the public record is an encrypted summary of the new state. Observers can see that activity occurred; they cannot see what it was.

What exactly is hidden, and what stays visible?

Hidden: your balances, transfer amounts, account state, and the internal logic of private transactions. Visible: the fact that a private transaction was included in a block, and the smart-contract code itself (more on that in the limitations section). The privacy protects your state and activity, not the existence of the network.

What are "hardware enclaves" and why do they matter?

An enclave (Arc uses AWS Nitro Enclaves) is a hardware-isolated, tamper-proof area of a computer where even the machine's owner or operator cannot read the memory or alter the code running inside. Your private transactions are only ever decrypted and processed inside these enclaves, so the companies running the network's computers cannot peek at your data.

Who holds the encryption keys?

No single party. The master key that protects the system never exists in readable form outside an enclave, and it is mathematically split into shares distributed across multiple independent validator organisations. Reconstructing it requires a large supermajority of them to cooperate inside attested enclaves. To compromise it, an attacker would have to break into the key custody of many independent organisations at once — not a single company, server, or cloud account.

Is my data encrypted? With what?

Yes, end to end across the system. Transactions are encrypted to the network using modern hybrid encryption, stored data is encrypted with fresh keys, and even the summaries written to the public ledger are encrypted. Identical activity produces unrelated-looking ciphertext, so observers learn nothing from patterns or repetition.

Are these protections future-proof against quantum computers?

Yes — the design specifically guards against "harvest-now, decrypt-later" attacks, where an adversary records encrypted traffic today hoping to crack it with a future quantum computer. The encryption pairs a battle-tested classical algorithm with a post-quantum one, so an attacker would have to break both. Today's recorded traffic is built to stay sealed.

Part 3 — For the technically minded

How does the privacy layer work architecturally?

Arc runs two execution environments on every validator: a normal public EVM, and a private EVM (the pEVM) running inside a hardware enclave. Both produce a state root every block, and both roots are committed in the same block header by the same validator set. Public transactions run in plaintext as usual; private transactions are decrypted and executed only inside the enclave, where state exists in the clear only in protected memory.

What makes this different from other privacy chains?

Most approaches force a trade-off. ZK systems are mostly limited to transfers; FHE is orders of magnitude slower; MPC adds coordination latency and a foreign programming model; and standalone TEE chains run separate consensus or asynchronous bridges that break composability with public state. APS binds the private ledger into the same consensus round as the public one — so public and private contracts can interact atomically within a single block, using standard Solidity and tooling.

What does the private transaction lifecycle look like?

In short: (1) you sign a standard EIP-712 transaction with your ordinary key; (2) it is wrapped to target a privacy precompile; (3) it is sealed with hybrid post-quantum HPKE encryption; (4) the ciphertext is submitted on-chain as calldata to executePrivateTx — anyone can submit and pay gas, which aids unlinkability; (5) the proposer's enclave decrypts, verifies the signature, recovers msg.sender, and executes, returning only a constant gas cost to the public layer; (6) every enclave validator re-executes and checks its encrypted state root matches; (7) a single BFT vote (>2/3) finalises both public and private state; (8) a light client inside each enclave verifies the commit before private state becomes queryable.

How are keys managed?

Every key derives from a single 32-byte master secret key (MSK) that exists in plaintext only inside attested enclaves. It is Shamir secret-shared across validator organisations with a threshold of 2t+1 — the same supermajority as BFT safety — so fewer shares reveal nothing. The MSK can be rotated (forward security: holders of the old key can decrypt nothing produced after a rotation) and old keys are destroyed once the data they protected ages out (backward security).

What stops a contract from leaking its own state?

A deny-by-default sandbox. Every function of every private contract starts as Restricted with no grantees; logs are disabled; and introspection opcodes (BALANCE, EXTCODE*) return zero across trust boundaries. Access is granted per 4-byte function selector — not per contract — and is unidirectional and revocable by the contract's admin. So a contract can, for example, expose transfer publicly while keeping balanceOf confidential.

How is gas-based side-channel leakage prevented?

Callers and observers see a fixed gas figure per invocation regardless of which branch executed, so private control flow can't be inferred from gas. Internally the EVM still meters real consumption and reverts if the deployer's allowance is exceeded. Private transactions also cannot be simulated, and results are retrievable only after finality.

How can private state be read?

Three query modes: ethCall (anonymous, plaintext — for genuinely public views; caller is address(0)); ethCallEncrypted (anonymous, but request and response encrypted on the wire); and ethCallAuthorized (authenticated via EIP-712 signature so the contract sees the real msg.sender and can enforce caller-based read access — with chain-ID, block-range, target-binding, and ECDSA-recovery checks against replay).

How does value move in and out of the private layer?

Through a single shield / unshield bridge precompile. Shield (public → private) locks/burns the public token and mints a private mirror in the same block — safe because the public leg is already visible. Unshield (private → public) burns the mirror in block N but deliberately delays the public release until N is finalised (N+1), preventing a malicious host from reordering/replaying to probe private activity. Only the bridge can mint the private mirror, so private circulation stays exactly tied to public locks.

What is the cryptography stack?

Transaction encryption uses HPKE (RFC 9180) with the X-Wing KEM (hybrid X25519 + MLKEM) + HKDF-SHA256 + AES-256-GCM. Persisted state and the in-header state root use AES-256-GCM-SIV with fresh per-emission/per-block keys. Inter-component traffic uses TLS 1.3 with the X25519MLKEM768 post-quantum hybrid. Signatures are Ethereum ECDSA today, with post-quantum verification (SLH-DSA) already exposed on-chain and migration planned.

What's the performance cost of privacy?

On AWS Nitro Enclaves (32 vCPUs/validator, 500 ms blocks): about 1,070 TPS for private transfers versus ~2,800 TPS public — roughly 38%, i.e. the same order of magnitude, not the orders-of-magnitude penalty of FHE. End-to-end batch latency is ~51 ms for 535 private transfers per block, dominated by (parallelisable) decryption and signature verification; sequential EVM execution is only ~4 ms.

What is the trust model?

Safety holds while fewer than one-third of validators are Byzantine (standard BFT). Enclaves are trusted to protect their contents (AWS Nitro today; the design is TEE-agnostic). The host machine is treated as fully untrusted — it may replay blocks, forge data, inject transactions, or kill the enclave, and the design tolerates all of it. The master key requires a supermajority of independent organisations to reconstruct.

Part 4 — Honest limitations

We think it's important to be clear about what this privacy does not cover.

Contract code is public. The privacy layer protects state and execution, not the logic itself — smart-contract bytecode and deployment transactions are visible on the public ledger.
Hardware side channels are out of scope. Constant gas eliminates gas-based inference, but memory-access patterns and timing observable by the enclave host are not addressed at the protocol level. This is treated as a bounded operational risk, with deeper mitigations left to future work.
It relies on enclave (TEE) security. Like all enclave-based systems, the design trusts the hardware vendor's isolation guarantees. The architecture mitigates this by distributing trust across many independent organisations rather than any single one.
Applications can still leak through normal behaviour. A poorly designed application can reveal information through its own functionality (the classic example: an automated market maker that quotes slippage inherently reveals pool depth). Building leak-free private applications remains an active engineering discipline.

The privacy capabilities described in this FAQ are subject to the availability of Arc Privacy (the Arc Privacy Sector). These capabilities depend on the underlying Circle Arc infrastructure and may vary, be delayed, or change over time accordingly. This FAQ is for customer education and is not legal, tax, or financial advice.

Still have questions?

Our support team is here to help

Contact support