Confidential transfers on Arc: what is hidden and what is not

Arc supports opt-in confidential transfers in which the amount moved is shielded while the sending and receiving addresses stay visible on the public ledger, and view keys let a designated party such as an auditor read the shielded values. That combination is easy to describe wrongly in either direction. It is not anonymity and it does not hide your counterparties. It stops the entire internet from reading the size of your payments.

This page covers Arc in its first weeks of mainnet. The model below — shielded amounts, visible addresses, view keys for disclosure — is Arc's published design and is settled; the interface details a developer integrates against are still landing, and where that is the case we say so rather than guess. Last reviewed: September 2026.

What are confidential transfers on Arc?

Confidential transfers on Arc are an opt-in transaction type where the transferred amount is cryptographically shielded from public view while the sender and recipient addresses remain visible on the chain, and where view keys can be issued so that auditors, counterparties or regulators can decrypt the amounts they are entitled to see. Arc is Circle's Layer-1, live on mainnet since September 16, 2026.

Each clause carries weight. Amounts: shielded. Addresses: visible. Auditability: preserved through view keys. Every serious misunderstanding of this feature comes from dropping one of the three.

What does it deliberately not do?

It does not hide who you transacted with. The graph of addresses, and therefore the pattern of who paid whom and when, remains public and analysable exactly as it is on any transparent chain. It is not a mixer: there is no pooling of funds to break the link between source and destination. And it does not defeat sanctions screening, because screening operates on addresses and counterparties, which stay in the clear.

It also does not make you anonymous. An address ever associated with an identity stays associated with it, and confidential transfers do nothing to sever that. If your compliance question is "can a sanctioned party use this to move value undetected," the honest answer is that the information screening tools rely on is precisely what this feature leaves visible.

Nor is it on by default. It is opt-in per transfer, so the ordinary state of an Arc transaction is fully transparent, amount included. /arc/what-is-arc covers the chain's baseline design; /arc/arcscan-guide covers reading ordinary transactions on the explorer.

Why would a business want shielded amounts?

Because on a transparent chain, the amount is the leak. Three cases make it concrete. Payroll: if you pay a team onchain, every employee can compute every colleague's salary from the block explorer, and so can a recruiter. Supplier pricing: if you settle invoices onchain, your competitor learns your input costs and your supplier learns what you pay their rivals. Treasury: a visible balance and visible flows tell counterparties your position before you negotiate.

None of those are solved by hiding who you paid. A payroll provider's address being linked to your company is unremarkable; the per-employee amounts are the sensitive part. That is the shape of the problem confidential transfers address, and the reason the design shields amounts rather than addresses.

The finance-team framing is at /arc/treasury-operations and /arc/pay-contractors, which cover the operational side without the cryptography.

How do view keys change the compliance picture?

A view key lets a holder decrypt shielded amounts for the transactions it covers, which means confidentiality on Arc is selective rather than absolute. An auditor with a view key sees what an auditor needs to see. Nobody else does. That is the inversion of the usual privacy-coin bargain, where opacity is uniform and proving your own compliance is the user's problem.

This matters more than it sounds. Most regulated institutions could not use privacy-preserving transfers before, not because they object to privacy but because they cannot use a system in which they are unable to demonstrate to an examiner what happened. A design where the enterprise grants read access to its own history is a design an audit committee can approve.

The operational questions that follow are yours, not the chain's: who issues view keys, who holds them, how they rotate, what happens when an employee with a key leaves, and how disclosure is logged. Treat a view key as a credential with the same handling standard as a database replica containing salary data, because functionally that is what it is.

Establish two things before you design a disclosure process around it: how narrowly a view key can be scoped on Arc, and whether it can be revoked. Those decide whether granting an auditor read access is a targeted disclosure or a permanent handover of your whole payment history, and "we can withdraw the key later" is only true if revocation exists as a mechanism rather than a promise. Arc mainnet is weeks old and this tooling is still being documented, so take the scoping and revocation semantics from Arc's own opt-in privacy documentation before you write them into a policy. If they are not written down there yet, treat any key you issue as irrevocable and scope issuance accordingly — the conservative assumption costs you nothing if the answer turns out to be better.

How do you actually use confidential transfers?

We are not publishing a code sample for this one, and the reason is worth stating plainly. Arc mainnet went live on September 16, 2026, and the surface a developer calls to send a confidential transfer — a distinct transaction type, a precompile, a contract interface, or something reached only through particular wallets and SDKs — is exactly the detail still being documented in a chain's first weeks. A plausible-looking snippet that turns out to be wrong causes real harm here rather than a failed build: a developer who believes a transfer was shielded when it was not has published precisely the data they meant to protect. Take the calling convention, and the list of wallets and libraries that support it, from Circle's and Arc's own developer documentation on the day you integrate, then test on testnet and confirm the amount is genuinely unreadable before sending anything sensitive on mainnet.

What you can plan for in the meantime is the shape of the integration. Assume confidentiality is a property of a transfer rather than an account, so your systems decide per payment. Assume your own records, not the chain, are the source of truth for shielded amounts, since you cannot read them back from a public explorer without a key. And assume your reconciliation tooling needs a code path for transactions whose amount your indexer cannot see.

The verification step is the same one an auditor will ask you to demonstrate. Open the transaction on the explorer and check the value field specifically: on a confidential transfer the from and to addresses, the timestamp and the fee read exactly as they do on an ordinary transfer, and the amount does not resolve to a number. If the explorer shows a value, the transfer was not shielded, whatever your wallet told you.

What should you check before relying on it?

Confirm what your indexing and accounting stack does with a transfer whose value it cannot read, because a naive indexer may record zero. Confirm your auditors accept view-key disclosure as evidence before you commit to onchain settlement for anything they sign off on. And confirm that shielding the amount actually removes the leak in your threat model, given that timing and counterparties stay public.

That last one is the check people skip. If you pay one supplier once a month and nobody else, hiding the amount tells an observer less than you think, because the existence, timing and destination remain legible. Confidentiality of amounts is a strong control against wholesale surveillance of your finances and a weak one against an observer who already knows your business. Size the claim honestly internally.

Is this the same as a privacy coin?

No. Privacy coins typically obscure sender, recipient and amount together, and offer no built-in way to grant selective read access. Arc shields the amount only, leaves the address graph public, and provides view keys for disclosure. Those are different products for different users, and conflating them is how this feature gets described badly.

Can law enforcement or a regulator see confidential transfers?

They see the sender, the recipient, the timing and the fact that a shielded transfer occurred, as anyone can. Seeing the amount requires a view key, obtained through whatever legal or contractual process would ordinarily compel disclosure of financial records. The chain does not put the amount beyond reach; it puts it behind a permission.

Does using it cost more gas?

Shielded transactions involve more computation than a plain transfer, so expect a higher fee than the baseline. Arc's testnet averaged about $0.004 per transaction as of August 2026, so even several times that is a fraction of a cent, and for the payroll and supplier cases this feature exists to serve the fee is not the deciding variable. Measure it on your own transaction shapes rather than budgeting from a published average, since the overhead scales with the proof work rather than sitting at a flat multiple.

Is it available for any token or only USDC?

Whether shielding extends to arbitrary ERC-20 tokens on Arc or covers the native USDC settlement asset only is a question for Arc's own opt-in privacy documentation rather than this page: Arc is weeks into mainnet and asset coverage widens over time. Plan on the narrower answer, and if your use case depends on shielding a token you deployed yourself, confirm it before building the product around it — designing for confidentiality you do not have is worse than designing without it.

Should we default to confidential transfers for everything?

Probably not. Transparency has operational value: public amounts are easy to reconcile, easy to prove to a counterparty, and readable by any tool without key management. Use shielding where the amount is genuinely sensitive, and accept the key-handling burden only where it buys you something.