Arc Privacy Sector: What Private EVM Changes for Blockchain Applications and Distribution
Arc Privacy Sector: What Private EVM Changes for Blockchain Applications and Distribution
Based on: Arc Privacy Sector: Keeping Blockchain State, Transactions, and Accounts Private and Quantum Safe, Mira Belenkiy et al., June 8, 2026.
Executive Summary
The paper on Arc Privacy Sector does not describe merely another “private token.” It proposes a way to embed confidential smart-contract execution into the familiar EVM model so that private and public state are finalized in the same block. This matters because many earlier approaches to blockchain privacy either required a new programming language and execution model, worked only for narrow classes of operations, or weakened composability between public and private contracts.
The core idea of APS is that the public Arc EVM and the private pEVM operate as two execution environments under one consensus system. A public block contains the normal public state root and an encrypted private state-root commitment, while private transactions enter the block as ciphertext submitted through a precompile. Inside validators, private execution takes place in a trusted execution environment, such as AWS Nitro Enclave. Data is decrypted and executed only inside the enclave, and the outside world receives only an encrypted commitment to the private state.
The practical meaning of this architecture is that developers can port existing Solidity contracts with minimal changes, while product teams can build applications in which public settlement infrastructure coexists with private business logic, private balances, private positions, and controlled disclosure. The most immediate application categories are payroll, private lending, private asset issuance, intraday repo, B2B settlement, confidential treasury workflows, and enterprise DeFi.
1. The Problem APS Addresses
The basic problem with public blockchains is that they make almost everything visible: calldata, events, balances, contract state, address relationships, and user behavior. For DeFi, this transparency has enabled verifiability. For regulated markets and corporate workflows, however, it is also a barrier. Salaries, credit limits, collateral, liabilities, allocations, trading intentions, and intraday liquidity needs cannot be fully public without damaging commercial confidentiality, employee privacy, market positioning, or regulatory secrecy.
The APS authors frame the problem not only as a cryptographic challenge but also as a developer-adoption challenge. In the abstract and introduction, they emphasize that previous privacy-preserving systems often required developers to learn new languages, new execution models, major contract rewrites, and non-standard tooling. In other words, the real bottleneck for private blockchain applications has not only been how to hide data, but also how to avoid breaking the existing EVM ecosystem.
“Developers can deploy existing Solidity contracts to APS with minimal modifications.” This statement from the paper’s introduction is one of its central product promises: privacy should be embedded into a familiar development model rather than require migration to an entirely new stack.
APS offers a pragmatic compromise. It does not hide contract bytecode itself and does not claim protection against every side-channel attack. Instead, it hides state, transaction payloads, intermediate execution, and persisted artifacts. This does not turn the blockchain into a fully opaque system, but it moves privacy to the places where applications most often need it: data, amounts, states, and computational results.
2. Architecture: One Blockchain, Two Execution Environments
Section 2 presents APS as a “one blockchain, two execution environments” system. The public environment L maintains ordinary visible state, while the private environment Lp maintains state that is accessible only inside the enclave. Both environments produce state roots that are included within a single consensus path. This is materially different from an asynchronous L2 bridge or a separate privacy chain, where the public and private domains have different finality schedules.
A private transaction appears to the public layer as a normal precompile call with a bytes parameter. The user signs a PrivateTx under EIP-712, encrypts the payload to the global APS public key, and submits the ciphertext through executePrivateTx. The validator-proposer executes public transactions in the Arc EVM and passes private payloads into the pEVM. The enclave decrypts the transaction, verifies the signature, executes the EVM call, and returns only an acknowledgement with a predetermined public gas cost.
The use of constant public gas is an important detail. If the public layer could observe different gas costs depending on private execution branches, gas would become a side channel. APS addresses this at the level of public observability: external observers see a fixed cost for the call, while actual resource accounting is handled within the confidential boundary.
A strong feature of the design is that private state is bound to public-block finality. After finalization, the pEVM light client inside the enclave verifies the commit certificate, checks the encrypted state root, and only then makes state available for queries. This protects against a malicious host attempting to feed the enclave stale, partial, or fabricated data and use it as an oracle.
3. Why Synchronous Finality Is the Main Technological Contribution
The most important architectural claim of the paper is not that execution happens inside an enclave. Enclave-based privacy has already been used by Secret Network, Oasis Sapphire, Phala, Ten, and other systems, which the authors discuss in Section 1.5. The distinctive contribution of APS is that private and public execution environments finalize in the same block under the same validator set.
This changes the application model. In an asynchronous architecture, developers must reason about bridges, delays, intermediate states, and possible divergence between domains. In APS, the public and private layers share a single rhythm of finality. This makes it possible to build operations in which public asset movement and private logic are linked atomically, or nearly atomically, rather than through a separate cross-chain procedure.
A useful example is shield and unshield. During shield, a public ERC-20 token is burned or locked, and a private mirror token is minted in APS. Since the public burn or lock is already visible, the corresponding private mint does not reveal additional information and can complete in the same block. During unshield, the private burn occurs in block N, while the public release occurs in block N+1, so that block N is already finalized and the host cannot extract information through replay or reordering scenarios.
This design makes APS not merely a privacy layer, but a dual-mode compute environment. The public part is useful for open liquidity, settlement, public collateral, governance, and shared signals. The private part is useful for commercial logic, positions, limits, personal data, and closed settlement. Between them sits a precompile-mediated bridge with explicit disclosure rules.
4. Key Management: Why the MSK Is Both a Strength and a Risk
APS uses a single master secret key, MSK, from which other keys are derived: the network public key for encrypting user transactions, per-block keys for state-root commitments, and keys for encrypted snapshots and write-ahead logs. To avoid keeping MSK as one centralized secret, it is distributed through Shamir secret sharing among validator organizations. Reconstruction requires TRecon = 2t + 1 shares, a threshold aligned with the BFT safety threshold.
This is a strong engineering structure because it combines several layers of control. A dealer enclave generates the MSK; organizations protect their shares through KMS and attestation policies; seed enclaves reconstruct the key only when enough shares are available; and pEVM enclaves receive the MSK over attested TLS. As a result, compromise of a single validator host or one share should not expose the entire private state.
However, this is also a major trust boundary. APS is not trustless privacy in the same sense as some zero-knowledge systems that try to minimize hardware trust. The user trusts the correctness of the TEE, attestation, KMS policy, threshold governance, and rotation/recovery procedures. The authors state this explicitly: the system inherits the trust assumptions underlying TEEs and does not protect against hardware-level side channels, timing, traffic analysis, or access-pattern leakage.
From the perspective of application developers and operators, APS should therefore be treated as a confidential-computing blockchain, not as a purely cryptographic privacy protocol. For enterprise applications, this may be acceptable because many organizations already use cloud KMS, HSMs, confidential computing, and compliance processes. For cypherpunk scenarios in which any hardware trust is undesirable, the compromise will be more controversial.
5. Sandbox and Access Policies: Privacy Does Not Happen Automatically
One of the strongest parts of the paper is its recognition that simply moving a contract into an enclave does not make the contract private. If a function such as balanceOf(account) remains publicly callable, it can reveal a balance even when storage itself is private. APS therefore introduces a sandbox execution environment in which contracts are isolated by default, and function exposure and interactions are configured explicitly.
Section 4 describes several mechanisms. First, cross-contract access is denied by default. Second, Solidity visibility is enforced at runtime: the pEVM Inspector intercepts CALL-family opcodes and checks whether the call complies with visibility rules. Third, trust domains define which contracts may see which other contracts and which selectors are available to them. Fourth, logging is disabled by default, and introspection opcodes such as EXTCODESIZE, EXTCODEHASH, and BALANCE are masked across trust-domain boundaries.
For product development, this implies a new discipline: privacy interface design. A contract may be Solidity-compatible, but its public surface must be designed differently. Teams must reason separately about view functions, event logs, revert reasons, access policies, query modes, and the possibility that even a correct business function may indirectly disclose state. The authors give the example of an AMM: if a user can learn slippage, the user can infer information about pool depth.
ethCallAuthorized is especially important. In this model, a query is signed through EIP-712, the pEVM verifies caller identity, and the view call executes with msg.sender set to the verified address. This enables applications where the same contract gives different answers to different users: an employee sees their own payroll, a treasurer sees aggregates, an auditor sees a regulated slice, and the public market sees nothing unnecessary.
6. Cryptography and Post-Quantum Positioning
APS is positioned as a system protected against harvest-now-decrypt-later attacks. To do this, the authors use hybrid constructions in which post-quantum components are combined with classical algorithms. On the wire, APS uses TLS 1.3 with X25519MLKEM768 wherever supported, while HPKE-like private-execution flows mention X-Wing KEM, HKDF-SHA256, and AES-256-GCM.
It is important to note that the post-quantum status is not absolute. Transaction signatures remain Ethereum ECDSA, consensus signatures use Ed25519 with a planned migration path, and AWS Nitro Enclave attestation at the time of the paper supports only elliptic-curve-based attestation. The authors explicitly acknowledge that full migration of signatures and the consensus layer to post-quantum signature schemes is postponed because of performance and maturity constraints.
This makes the APS claim more precise: the technology protects the confidentiality of transmitted and stored private data against future decryption scenarios, but it does not claim that the entire stack is already quantum-safe across every cryptographic primitive. For applications, this still matters. If a company sends encrypted payroll data or repo terms today, it may be critical that recorded ciphertext cannot be decrypted cheaply ten years later.
7. Performance: Why 1,070 TPS Is an Important Signal
In Section 6, the authors report that on an AWS Nitro Enclave deployment APS reaches approximately 1,070 TPS for private transfers. With a 500 ms block time, the system executes a batch of 535 private transfers with p99 batch execution latency of roughly 50 ms. For comparison, the public Arc network under the same configuration reaches 2,800 TPS.
The most interesting latency-breakdown finding is that HPKE/X-Wing decryption and ECDSA verification are parallelized, while sequential EVM execution becomes the steady-state bottleneck. This means that confidential-computing overhead does not destroy throughput completely. Instead, APS remains close enough to the public baseline to be considered for real payment, lending, and settlement workflows.
For product strategy, this means APS can support not only low-frequency enterprise settlement but also more interactive scenarios, provided that contract logic is not too complex and the query UX respects the finality boundary. At the same time, AMMs, order books, complex lending liquidation, and privacy-preserving analytics will require careful design because computational complexity and output leakage may become limiting factors before raw TPS does.
8. What Applications Can Be Built Now
The paper identifies four representative use cases: payroll, lending markets, asset issuance, and intraday repo markets. However, if APS is viewed as an infrastructure technology, the list is broader. The important question is not simply “which contract can be hidden,” but which business process benefits from combining public finality with private state.
8.1 Confidential Payroll
Payroll is one of the clearest scenarios. Salaries, bonuses, payment schedules, and employee identities should not become public. APS allows salary schedules and balances to remain inside a private contract while still using deterministic settlement and on-chain funding. For companies, this could mean programmable payments in stablecoins or tokenized cash without exposing the compensation structure.
The likely distribution model is not a “DeFi dApp for everyone,” but a B2B SaaS product. A payroll provider integrates with HRIS systems, custody providers, accounting software, and the wallet layer. The APS contract becomes the settlement backend, while users see a familiar interface: payslip, tax report, and self-service withdrawal.
8.2 Private Lending and Vaults
In public DeFi, the visibility of collateral, debt, and liquidation thresholds creates behavioral and market risks: strategies can be copied, stressed positions can be monitored, and liquidations can be attacked. APS allows vault composition and risk profiles to remain private while protocol rules still execute deterministically.
Such an application could be distributed as a private credit protocol for institutional clients. The public part would handle funding pools, price references, and settlement, while the private part would handle borrower positions, covenant checks, and collateral composition. The main UX challenge is to prove to lenders that the risk model is executing correctly without disclosing all borrower-level data. This requires selective disclosure, auditor access, and role-based encrypted queries.
8.3 Confidential Asset Issuance
Asset issuance in APS can hide holder identities, allocation amounts, transfer restrictions, and vesting schedules. This is especially important for tokenized securities, private funds, structured products, employee equity, and bilateral instruments. In a public EVM, such data is either exposed or pushed off-chain, which reduces the value of on-chain settlement.
Distribution would likely occur through issuer platforms and regulated transfer agents. An APS contract can enforce transfer restrictions and allowlist logic, while the public layer records only the necessary commitments and bridge events. Investors receive a private ownership record, issuers receive programmable lifecycle management, and auditors or regulators receive access through an authorized query path.
8.4 Intraday Repo and Treasury Markets
Intraday repo is particularly sensitive to disclosure: terms, collateral composition, funding needs, and counterparties can reveal a firm’s liquidity position. APS allows settlement, margining, and repayment logic to move on-chain while hiding deal details and participant balances.
A plausible distribution model is a permissioned marketplace built on top of a public-private settlement layer. Participants connect through institutional wallets and custody providers, while the market gains programmable settlement without exposing financing stress. This is one of the scenarios where synchronous finality is especially important: a repo transaction may depend atomically on public prices, collateral movements, and private deal terms.
8.5 Private B2B Workflows and Supply-Chain Finance
Beyond the paper’s own examples, APS is well-suited to B2B workflows where parties need provable execution without exposing commercial terms. Examples include invoice financing, supplier rebates, factoring, usage-based billing, embedded insurance, royalty distribution, and revenue-sharing agreements. In all of these scenarios, public transparency damages commercial confidentiality, while fully off-chain execution weakens auditability.
Here, APS can become the backend for “confidential workflow contracts.” Customers do not necessarily need to know that pEVM is being used internally. They will buy a finished product: private settlement logic with on-chain finality and an audit trail.
9. How These Applications Can Be Distributed
The main change APS introduces is the ability to sell not “a private blockchain,” but private functions inside a publicly composable network. This affects go-to-market strategy. A developer can use Solidity, familiar wallets, EIP-712 signatures, and precompile calls. A user can interact through a dApp or enterprise interface. An operator can offer hosted enclave RPC and compliance access.
9.1 Wallet-First Distribution
Because APS preserves the ECDSA/EIP-712 user-signature model, applications can be distributed through normal wallets and embedded wallets. The user signs structured data, the wallet encrypts the payload to the network public key, and the UI displays status after finality. For consumer-facing scenarios, this is the most natural path: privacy becomes a feature of the wallet SDK, not a separate application.
9.2 SDKs and Confidential dApp Templates
For developers, APS can be packaged as an SDK: obtaining globalPublicKey, wrapping PrivateTx, EIP-712 signing, HPKE/X-Wing encryption, calling executePrivateTx, querying results(txHash, sig), and decrypting the response. At this distribution layer, templates matter: private ERC-20, access facade, authorized query facade, payroll module, vault module, and bridge wrappers.
9.3 Enterprise SaaS on Top of APS
The most willing early adopters are likely not retail users, but enterprise teams: treasury, HR, capital markets, asset servicing, compliance, and private credit. For them, the technology will be sold as SaaS or managed service, with APS acting as the settlement and confidentiality substrate. The product should hide pEVM complexity and expose business objects: employee, pay cycle, collateral, facility, asset class, investor, and covenant.
9.4 Hosted Enclave RPC and Attested Infrastructure
Because private results are returned through an enclaved RPC node after finality, a new infrastructure layer can emerge: attested RPC providers, query gateways, compliance gateways, auditor nodes, and archive services for encrypted state. This layer will resemble ordinary RPC infrastructure, but with an additional responsibility: proving that requests are served from the correct enclave profile and committed private state.
9.5 Modules for Composable Private Contracts
A separate channel is libraries and modules. The APS sandbox makes per-function policies and trust domains central to development. This creates demand for audited modules: private token, private balance query, private transfer facade, confidential role-based reporting, compliance disclosure adapter, and shield/unshield wrapper. This could resemble OpenZeppelin, but for privacy-aware contract surfaces.
10. What the Technology Gives the Ecosystem
APS gives the ecosystem four practical advantages. First, it lowers the development barrier: teams can use EVM bytecode, Solidity, and familiar SDKs instead of relearning a separate privacy VM. Second, it enables synchronous composability: public and private state advance in lockstep, so applications can connect public assets and private logic without an asynchronous-bridge mental model. Third, it offers practical performance: 1,070 TPS for private transfers on an enclave deployment makes the technology plausible for non-toy scenarios. Fourth, it provides post-quantum-oriented confidentiality: private payloads are protected with hybrid cryptography on the wire, reducing future-decryption risk.
APS also introduces new responsibilities. Developers must design the disclosure surface, because a private environment cannot save a function that reveals state by design. Operators must manage TEE profiles, KMS policies, MSK rotation, and RPC attestation. Product teams must explain which data is hidden, which data is disclosed through the bridge, which data is available to auditors or regulators, and under what conditions.
11. Limitations and Open Questions
The first limitation is side-channel leakage. The paper explicitly states that APS does not protect against timing, traffic analysis, memory access patterns, or hardware-level resource leakage. For some applications this is acceptable, but for high-frequency trading or sensitive strategy execution, even metadata leakage may be critical.
The second limitation is bytecode visibility. APS hides state and execution, but not contract logic. In enterprise contexts, this may be acceptable if the secret lies in the data rather than the algorithm. For proprietary trading logic or complex pricing models, however, additional architecture may be required.
The third limitation is application-level leakage. The AMM slippage example shows that ordinary functionality can reveal private state. This means APS needs a new set of patterns: privacy-preserving UX, bounded disclosure, delayed reveals, aggregate views, auditor-only queries, and access policies by role and selector.
The fourth limitation is governance of trust. Who approves enclave profiles? Who manages KMS policy? How does emergency rotation work? How can users verify that a hosted RPC endpoint is actually enclaved? These questions can be answered through infrastructure, but they become part of the product trust model.
12. A Practical Development Strategy for APS
If a team wants to build on APS, the correct process differs from ordinary dApp development. The work should begin not with the contract, but with a data map: which fields must be public, which must be private, which are selectively disclosed, which are available to auditors, and which must never leave the enclave. Then the team should design function-level access policies and query modes.
The next step is to choose a distribution model. A retail dApp needs wallet SDKs and a simple encrypted-signing flow. Enterprise SaaS needs integrations, admin consoles, compliance reporting, and key/access governance. Protocol modules need audited contracts, formal policy templates, and developer documentation. Only after that does it make sense to port Solidity business logic.
Conclusion
Arc Privacy Sector matters not because it is the first proposal for blockchain privacy, but because it tries to make privacy compatible with EVM development, public finality, and practical performance. Its architecture combines pEVM inside an enclave, encrypted state-root commitments in each public block, a precompile-mediated transaction path, trust domains, per-selector access policies, and hybrid post-quantum encryption.
If the technology is implemented and adopted by the ecosystem, it could expand the on-chain market beyond public DeFi. Payroll, institutional lending, tokenized assets, repo, treasury workflows, and B2B settlements could use programmable finality without total data disclosure. Yet success will depend not only on cryptography and TPS. The central challenge is to create developer patterns and distribution channels in which privacy is treated as an interface and operations discipline, not as a magical property of an enclave.
References
-
Arc_Privacy_Sector(5).pdf — Mira Belenkiy et al., Arc Privacy Sector: Keeping Blockchain State, Transactions, and Accounts Private and Quantum Safe, June 8, 2026. Key sections: Abstract, §1.1–1.5, §2.1–2.4, §3.1–3.4, §4.1–4.9, §5.1–5.3, §6–7. n ecosystems, builders, and infrastructure-heavy applications to help teams launch and scale production-ready systems.
-
Twitter: https://x.com/stable_vault
-
Telegram: https://t.me/htwtech_connect_bot
-
Medium: https://medium.com/@htwtech
