Connect, share wins, swap ideas, and chill with fellow community members

Member Lounge

Building financial infrastructure on a public blockchain creates a fundamental tension. Every transaction, every state change, every balance transfer is visible to anyone watching the mempool. For payroll, lending markets, asset issuance, and intraday repo, that transparency is a dealbreaker. The institutions and builders who need onchain settlement the most are the ones who cannot tolerate full transaction exposure. Arc Privacy Sector solves this by running a private EVM alongside Arc's public EVM inside the same block, giving builders confidential execution without abandoning the tooling, composability, or finality guarantees they already depend on.

The core architecture is straightforward to describe but deeply considered in its engineering. Arc Privacy Sector runs two execution environments - the standard public Arc EVM and a private EVM (pEVM) - both operating inside the same validator infrastructure and both committing state roots to the same block header. There is no separate chain, no bridge to a different consensus layer, no asynchronous message passing between two independent networks. A single block on Arc contains both the public state root and the encrypted private state root. They finalize together, atomically, in the same 500ms block time. If the block finalizes, both environments have advanced. If it does not, neither has.

This synchronous dual-commit matters more than it might seem at first glance. Other approaches to onchain privacy - Aztec, Secret Network, various ZK rollups - all introduce some form of finality delay or cross-chain synchronization overhead. Arc Privacy Sector avoids that entirely by keeping both environments inside the same BFT consensus round. Validators run both execution paths in parallel, and the block proposal includes both roots. The result is that private state transitions and public state transitions have identical finality guarantees. A private transfer and a public transfer submitted in the same block finalize at the exact same moment.

For builders deploying on APS, the practical implication is significant. You write Solidity. You compile with your existing toolchain. You deploy with minimal modifications - the whitepaper specifies that existing contracts work with minimal changes, because the pEVM is a full EVM runtime, not a subset or a DSL. The privacy layer sits beneath the execution layer, not beside it. Your contract logic does not change. What changes is how transactions reach the enclave and how state is committed, both of which are handled by protocol-level infrastructure that your contract never needs to address directly.

The transaction flow for a private operation is worth understanding in detail, because it reveals where the actual privacy guarantees come from. A user constructing a private transaction first signs it using EIP-712 typed data. This gives structured, domain-separated signatures that prevent replay attacks across different contexts. The signed transaction is then encrypted using HPKE - Hybrid Public Key Encryption - with the X-Wing KEM as the key encapsulation mechanism. X-Wing is a hybrid construction combining X25519 (classical Diffie-Hellman) with ML-KEM768 (the NIST FIPS 203 lattice-based KEM), so the encryption envelope is simultaneously resistant to classical and quantum adversaries. The shared secret derived from KEM is fed through HKDF-SHA256, and the actual payload is encrypted with AES-256-GCM.

The encrypted blob is submitted as calldata to an Arc privacy precompile address. This is the only point where the transaction touches the public mempool, and it is also where the privacy guarantee becomes concrete. The mempool sees a ciphertext. It does not see the sender, the recipient, the amount, the contract address, or the function being called. The precompile validates only the fixed gas fee and the format of the ciphertext - nothing about the transaction's semantic content. The proposer picks the encrypted transaction from the mempool and dispatches it to the pEVM enclave, which runs inside a hardware TEE (SGX or AWS Nitro Enclave depending on deployment). Inside the enclave, the network private key decrypts the ciphertext, the EIP-712 signature is verified, and the transaction executes against the private state tree. The enclave returns only the fixed gas cost to the proposer. No execution results, no status codes, no revert reasons - nothing that could leak information about what happened inside. The proposer learns that gas was consumed. That is all.

The enclave then produces an encrypted private state root and a zero-knowledge proof, both of which are included in the block proposal. Validators in the BFT consensus round verify the enclave attestation before voting on the block. Once sufficient validators have signed - reaching the BFT commit threshold - the block is finalized with both state roots, and a light client can verify the commit certificate before making private state queryable.

Query access itself operates through three distinct modes, each serving a different privacy profile. The first, ethCall, is anonymous - anyone can query without revealing identity. The second, ethCallEncrypted, is both anonymous and encrypted, adding a transport-layer protection to the query channel. The third, ethCallAuthorized, requires an EIP-712 verified caller identity, which lets contract developers gate state access to specific addresses. These three modes give builders fine-grained control over who can read private state and under what authentication context, without forcing a one-size-fits-all disclosure model.

Now, the sandbox model is where APS distinguishes itself from enclave-based privacy designs that assume a single trusted execution context. The pEVM enforces a deny-by-default isolation policy across all contracts. No implicit trust exists between any two contracts in the private environment. Every function and storage slot starts as DENY. Access must be explicitly granted by the contract's deployer or admin. This is not a capability system layered on top of the EVM - it is a fundamental property of how the pEVM handles cross-contract calls.

The access control operates through trust domains with per-function-selector access policies. Each function selector on a contract has one of three policy levels: Open, Restricted, or Locked. Open means any caller can invoke. Restricted means the system checks a trust bitmask that maps (caller, target) pairs to specific function selectors. Locked means the function is unconditionally denied to external callers regardless of trust relationships. The bitmask itself is a compact representation - each bit corresponds to one function selector, where 1 means trust is granted and 0 means denied. Only the deployer or admin of a contract can set or revoke trust bits. A calling contract cannot self-grant access. Trust is granular, revocable, and fully auditable onchain.

The deny-by-default model matters for institutional adoption because it eliminates an entire class of side-channel concerns. In a privacy system where any contract can observe any other contract's state by default, the privacy guarantee degrades with every new deployment. A malicious or compromised contract in the same enclave could extract private state from neighboring contracts. APS prevents this structurally - Contract B cannot read Contract A's state unless Contract A's admin has explicitly granted a trust bit for the specific function selector B is calling. This is consent-based disclosure at the function level, and it is enforced by the runtime, not by convention.

Cross-environment composability - moving assets and state between the public Arc EVM and the private pEVM - is handled through the shield and unshield bridge operations. These are not cross-chain bridges in the traditional sense. There is no separate validator set, no multisig, no external relayer. Both environments share the same consensus and the same block finality.

The shield operation moves assets from public Arc to APS. Public ERC20 tokens are burned or locked in the public EVM, and an equivalent amount of Private ERC20 tokens is minted in the pEVM. The unshield operation reverses this - Private ERC20 tokens are burned in the pEVM, and the corresponding public ERC20 tokens are released in the public EVM after block finalization. The "after block finalization" detail is important. Private state must be committed to a finalized block before the corresponding public tokens are released. This prevents a scenario where a private burn could be reversed after public tokens have already been unlocked - a subtle but critical consistency guarantee that arises naturally from the synchronous dual-commit architecture.

For builders thinking about deployment patterns, the shield/unshield model enables a clean separation of concerns. Public-facing operations - AMM swaps, liquidity provision, governance - can remain on the transparent Arc EVM where they benefit from full composability with existing DeFi infrastructure. Private operations - payroll disbursement, confidential lending positions, institutional asset issuance - run on the pEVM where transaction details and state are encrypted. Assets flow between the two environments through the bridge, and the bridge's consistency guarantees come from the shared consensus layer rather than from economic security or external verification.

The performance numbers from the AWS Nitro Enclave deployment are concrete and worth citing directly. APS processes 1070 TPS for private transfers. End-to-end batch execution latency for 535 private transfers is 50ms. The block time is 500ms. For comparison, the public Arc EVM baseline in the same deployment setting is 2800 TPS. The private execution path carries a throughput cost relative to transparent execution - roughly 38% of the public baseline - but the latency profile is aggressive enough for real-time financial applications. A 50ms batch execution time for over 500 private transfers means that the pEVM is not the bottleneck in any practical deployment. The block time and consensus round dominate the latency budget, not the enclave execution.

These numbers matter for the specific use cases APS targets. Intraday repo markets require sub-second settlement and cannot tolerate transaction exposure that reveals positions. Payroll systems need to process hundreds of disbursements per block without leaking compensation data. Lending markets with confidential collateral positions need to update state atomically with the public chain's interest rate feeds. All of these patterns fit comfortably within the 1070 TPS / 50ms envelope.

The cryptographic design deserves separate attention because it reflects a specific threat model that most onchain privacy systems have not yet addressed. APS uses post-quantum hybrid cryptography throughout the transaction encryption path. The X-Wing KEM combines X25519 (classical elliptic curve) with ML-KEM768 (Module-Lattice-Based KEM, standardized as FIPS 203). This is a hybrid construction - the ciphertext is secure as long as at least one of the two underlying problems remains computationally hard. If a sufficiently powerful quantum computer breaks X25519's discrete log assumption, ML-KEM768 still holds. If a future cryptanalytic advance breaks ML-KEM768, X25519 still holds. The symmetric layer uses AES-256-GCM-SIV, which provides nonce-misuse resistance - a practical consideration for high-throughput systems where nonce management under concurrent access can be non-trivial.

The master secret key that the enclave uses for decryption is never stored in a single location. It is distributed across the validator set using Shamir threshold sharing, with a reconstruction threshold of T_Recon = 2t+1, where t is the maximum number of compromised validators the system can tolerate. This means that no subset of validators below the threshold can reconstruct the master key, and the key material is never present in full on any single machine - not even inside an enclave during normal operation. The threshold sharing interacts with the BFT consensus to create a dual guarantee: the key cannot be extracted by compromising fewer than T_Recon validators, and the consensus cannot finalize a block without participation from at least T_Recon honest validators. These two thresholds are aligned so that the privacy guarantee and the liveness guarantee derive from the same trust assumption.

For builders deploying today, the practical takeaway is this. Arc Privacy Sector gives you a full EVM with confidential state, synchronous finality with the public chain, deny-by-default cross-contract isolation, post-quantum transaction encryption, and performance that supports real financial workloads - all without requiring you to learn a new language, a new virtual machine, or a new deployment model. You write Solidity. You compile with Solc. You deploy with your existing pipeline. The privacy is a property of the execution environment, not a property of your contract code.

The use cases that open up are the ones that have been structurally locked out of public blockchain infrastructure. Payroll on Arc means compensation data stays private while settlement happens onchain. Confidential lending markets mean collateral positions do not leak to MEV extractors or competing protocols. Institutional asset issuance means subscription amounts and allocation details remain between the issuer and the subscriber. Intraday repo means settlement finality in 500ms with no transaction exposure. These are not speculative possibilities - they are direct consequences of the architectural decisions APS makes: dual execution in a single block, deny-by-default isolation, post-quantum encryption, and synchronous finality.

The internet capital markets thesis depends on institutional capital moving onchain. That capital will not move to infrastructure where every position is publicly observable, every transfer is front-runnable, and every state change is visible in the mempool. Arc Privacy Sector addresses this constraint directly - not by adding a privacy layer on top of a transparent chain, but by embedding confidential execution into the consensus itself. Same block. Same finality. Same tooling. Private state.

How Arc Privacy Sector Brings Confidential Execution to the EVM Without Breaking Composability

Home

Forum

Events

Content

Courses

Collections

People

Contributors

Albums

Groups

Chat

Channels

Not being used

Help

Join the global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make the economy work for everyone.

Arc House

What is your job title

Join a global network of builders developing the Economic OS for the internet. We’re reimagining how value moves, creating the tools that make that economy work for everyone. 

Arc House | Build the economic OS for the internet with us

Copyright

Terms of Service

Privacy

Code of Conduct

Your Privacy Choices

It looks like there is no account associated with the email you provided. The event is for members only. Please complete the application to join our community first.

Thank you for your interest in joining us

Thanks for your interest in joining the event. However, your account is still pending. Once it's approved, you'll be able to register for the event. Please contact us via noreply@arc.network if you need support.

Pending Approval

Login to the The Arc Community Hub community to connect with others, attend community events, and more!

Login or Sign Up for even more

To unlock all parts of the community complete your profile using verifiable and real information.

Hey, complete your profile

It looks like there is no account associated with the email you provided. Please complete the application to join our community.

Thank you for your interest in joining Arc House.

Thanks for your interest in joining Arc House. We will review your request shortly and email you once it's approved. Meanwhile, please feel free to contact us via noreply@arc.network for any questions.

Accounts are unapproved when profile information cannot be verified or when activity patterns indicate spam, inorganic participation, or behavior that undermines trust in the program.

To strengthen your profile for future consideration, sign in with a verified LinkedIn account, use real and current profile information, and participate constructively in other community spaces.

Commercial customers should raise concerns through their support channel.

https://www.arc.network/community-guidelines