On June 10, Arc published its privacy whitepaper, formally titled Arc Privacy Sector. It's a proposed design, not shipped code.
We've been building on Arc since testnet, alongside Tempo, Ethereum, Canton, Avalanche, and Base. Privacy is the question every serious institutional programme we run hits, usually within the first two meetings. So when Circle ships a whitepaper this material on a chain we already build on, it earns a careful read.
These are our notes.
The problem the paper starts from
Most blockchains expose transaction data and contract state by default. That's the property that lets a stranger trust a ledger without trusting the operator. It's also the property that breaks the moment a workflow looks like real finance.
The paper's framing is direct. A payroll contract can't broadcast compensation, identities, and schedules to the market. A lending protocol can't ask borrowers to publish collateral and liquidation risk in real time. An issuer needs to enforce transfer rules and vesting without making its cap table globally readable. Intraday repo is more sensitive still: collateral, counterparties, and funding needs can reveal a firm's liquidity position before a trade settles.
This matches what we see on the buyer side. The rails work. Settlement is fast, fees are low, the compliance hooks exist. Then a treasury or risk lead asks whether competitors can see payroll, vendor flows, or position changes on a block explorer, and the programme stalls until there's a credible answer.
The unlock the paper argues for isn't privacy. It's confidentiality with an access model. Regulated finance can't use a black box any more than it can use a glass box. Compliance teams, auditors, and sometimes regulators need defined visibility. The public may not. Privacy with governed visibility, not anonymity.
Why earlier privacy designs didn't take
The whitepaper's central claim, one line in the intro: "The primary obstacle is no longer pure cryptography."
That's a sharper statement than it sounds. The industry has had privacy primitives for years. The reason none of them became the default for onchain finance is that they each change too much about how you build.
Zero-knowledge proofs fit narrow flows better than arbitrary composable contracts. Build a confidential transfer with them, fine. Build a programmable lending protocol with full composability and identity-gated visibility, much harder. FHE runs orders of magnitude too slow for general transaction processing. MPC makes you reason about state in secret shares instead of ordinary contracts. Enclave-based systems get closest to ordinary execution but typically live as standalone chains, which turns private state into somewhere you bridge into and out of.
Each path solves cryptography. None of them solved adoption.
We've evaluated most of these for clients at this point. The verdict tracks the paper's argument: the gating factor on every programme has been how much the team has to bend their existing stack to fit the privacy primitive. Arc's bet is that the right move is to keep the developer environment ordinary. Keep the EVM. Keep Solidity close to untouched. Keep public and private execution under one consensus process. Let builders pick where confidentiality belongs in their application instead of rebuilding the whole app around a separate privacy universe.
That's the right framing.
The proposed design: one chain, two execution environments
Public activity runs on Arc in the clear, on the normal EVM. Private activity runs in a private EVM inside hardware enclaves. You sign with a normal EVM key, encrypt the payload to the network's public key, and submit through an Arc precompile.
The public chain sees a precompile call and opaque ciphertext. The enclave decrypts, executes, and commits an encrypted private state root into the same Arc block. Both halves finalize together, in the same consensus round.
The paper calls this synchronous execution and treats it as the core distinction from every prior privacy design. Most existing privacy systems are standalone chains or asynchronous L2s, which means a private contract has to bridge back to the public world and wait. Here, a private contract and a public one coordinate inside a single block. No separate chain, no delayed bridge.
That synchronous property is what actually changes the design space. A confidential lending position can read a public oracle and clear against a public DEX in the same transaction. A private payroll batch can settle against a public stablecoin balance atomically. Privacy stops being a side room.
Crossing the boundary
Value moves through a controlled shield/unshield bridge. To go private, you shield: the token on the Arc side is locked or burned and a private mirror is minted on the private side. To go public, you unshield: the private mirror burns and the public side releases. Supply stays in parity, so a wrapped private balance can't mint tokens that don't exist on Arc.
The supply-parity invariant being enforced at the protocol level (rather than via off-chain attestation) is the kind of design choice that makes regulator conversations shorter. Inflows and outflows are observable on the public side even when the private state isn't. From the integration work we do, this matters a lot: it means our reserve attestation and travel-rule pipelines don't have to treat the private side as a separate balance sheet.
The query model
This is the section of the paper that should matter most to anyone building for institutions. There are three ways to read private state.
An unauthenticated plaintext query, for things that are safe to read in the clear. An unauthenticated encrypted query that protects the request on the wire while the caller stays anonymous. And an authorized query, where the caller proves identity through an EIP-712 signature and the contract decides what to return based on who's asking.
The authorized query is the real institutional primitive. It isn't anonymity. It's access control over private state, expressed inside contract logic. A compliance team gets the view it needs, an auditor gets the access scoped to an audit, a counterparty sees the slice relevant to its trade, everyone else gets nothing.
This is exactly the shape every regulated client we work with describes when we ask what they actually need. Not privacy from regulators. Privacy from the market, with scoped visibility for compliance, auditors, and counterparties. Most privacy systems put privacy in the protocol and then bolt disclosure on as a sidecar. Here, governed visibility is a first-class read primitive in the contract. The disclosure logic lives with the asset.
For the programmes we run, that's the difference between "we built a privacy chain and added a disclosure tool" and "the privacy primitive itself supports identity-gated reads." The second one is what you can actually run a programme on.
The trust model
Most enclave-based privacy systems run into the same question from a serious risk team. Who holds the keys.
Arc's answer: nobody, in the singular sense. The master secret is split across validators and only reconstructed inside an attested enclave, at a threshold tied to Arc's BFT safety bound. A colluding minority can't decrypt private state. Wire encryption is hybrid post-quantum, classical paired with post-quantum primitives, to blunt harvest-now-decrypt-later attacks.
This is a reasonable model on paper. The questions that decide whether it holds up in production are familiar enclave-system questions: how attestation chains rotate, how enclave compromises are handled, what happens on validator exits, how key shares are re-shared when the validator set changes. None of these are unsolved problems, but they're the ones where details matter, and they're where any institution's risk team will spend time. Ours included.
The post-quantum hybrid choice is worth calling out separately. It's the right call for a chain selling to regulated counterparties with multi-decade audit horizons. Confidential financial data encrypted today will still be sensitive in twenty years. Building post-quantum into the wire format from the start is cheaper than retrofitting it later, and it gets us past one of the questions that's been coming up in every serious institutional review we've done this year.
What the benchmark actually says
The paper publishes a three-node enclave benchmark. Public throughput holds near 2,800 TPS, private transfers land around 1,070. The two paths run side by side without one starving the other.
This isn't a load test. It's an architectural signal. The point isn't the headline number, it's that the public chain doesn't slow down when private execution is active. Privacy isn't free here, but it doesn't collapse public throughput either.
For the institutional workloads we build for (payroll, settlement, repo) what matters isn't peak TPS, it's consistent latency under contention, especially on the authorized-query path where compliance reads will queue up. That's a number that only shows up under real traffic. We'll be among the first to test it.
What it unlocks
The paper reaches for four workloads where this architecture is the unlock, not just an improvement. These map almost one-to-one onto the programmes our clients are quietly trying to ship.
Payroll. Compensation logic runs onchain, but amounts, recipients, and schedules stay sealed. Audit access is preserved. The reason this hasn't moved onchain at scale isn't payment rails. It's that no finance team will publish salaries to a public ledger. We've built payroll workflows for clients with employee allowlists, batch scheduling, and FATF travel-rule data attached per payment; Arc Privacy Sector gives the same property to teams that want a single public chain underneath.
Lending. Borrower collateral and liquidation risk stay hidden through the position's lifecycle, not just at origination. Every public-chain credit desk is currently a target map for anyone running strategies against it. Synchronous execution matters here because lending touches oracle reads, liquidations, and DEX paths that need to stay composable across the privacy boundary.
Asset issuance. Transfer rules, vesting, holder activity managed without publishing the cap table. Issuers enforce policy without making it globally readable. This is the workflow that moves tokenised credit and equity from interesting pilots to production scale, and it's most of what we build on the RWA side today.
Intraday repo. The sharpest example in the paper, and probably the workflow most likely to drive serious adoption. Collateral, counterparties, and funding needs reveal a firm's liquidity position before a trade settles. Programmable repo with confidential terms and identity-gated visibility is the kind of primitive that brings real treasury flows onchain. Public-chain repo isn't a near-term product. Confidential repo with governed disclosure could be.
The common thread across all four is that the workflows aren't gated on settlement speed or fees. They're gated on whether the rail can keep sensitive state confidential while still letting compliance see what it needs to see. That's the gap Arc Privacy Sector is built to close, and the gap we spend most of our time on.
What's still open
It's a proposed design. The honest reading is that the architecture is well-argued and the primitives line up with what regulated programmes need, but the production questions are still ahead.
Enclave attestation and operational hardening. Enclaves have a history of side-channel issues. The whole design rests on attestation being trustworthy in practice, not just in the threat model.
Throughput under realistic contention, especially on the authorized-query path. The bench number is clean. Production traffic doesn't look like the bench.
Compliance composability. How identity-gated reads interact with travel-rule data, issuer policies, and existing KYT pipelines decides how cleanly this slots into existing institutional compliance stacks. Our own compliance stack is built to be portable across chains, so this is one of the first things we'll be testing on Arc.
Mainnet timing. Institutional buyers don't commit programmes on roadmap decks. The whitepaper is a strong design document. The shape of the rollout decides whether it actually gets used.
Where this sits in the stack
Arc Privacy Sector is a more thoughtful design than most onchain privacy work to date. The synchronous public/private execution model is a real architectural contribution. The EIP-712 authorized query is the right primitive for institutional disclosure. The threshold-key trust model is defensible. The post-quantum hybrid choice is correct.
It's also still a paper. The interesting work starts when this lands on mainnet and real workloads hit it.
For the institutions we work with, this is the most credible institutional-privacy design currently in play on a public chain. We don't think any single chain wins the institutional privacy story outright. The serious programmes we build will use a combination of rails picked per workflow, with a common compliance and clearing layer on top. Arc Privacy Sector, if it lands as written, moves Arc into the small group of public chains we'd actually recommend for regulated, privacy-sensitive flows. That changes the shortlist.
If you're building a stablecoin or tokenisation programme and trying to figure out where Arc fits, what to ship on it, and how it slots into the rest of your stack, drop us a line at hi@rem.money or book a call. We've already mapped most of the trade-offs.
Sources
Tim Baker, "Built for the Money That Was Never Going to Move in Public", Arc, June 10, 2026.