Skip to main content
Arc provides opt-in privacy through ArcaneVM, a confidential execution environment for Solidity contracts that runs alongside Arc’s public EVM. Deploy existing Solidity contracts into ArcaneVM with minimal modifications to keep contract state and transaction data confidential while preserving atomicity and consensus consistency with the public ledger. Privacy is opt-in: applications choose when business or regulatory requirements warrant keeping data off the public ledger.
Privacy features are on the roadmap and not yet available on Arc.

​
How ArcaneVM works

Arc runs one blockchain with two execution environments: Arc for public state and ArcaneVM for private state. Both environments produce state roots that are committed together in each block, advancing in lockstep within the same consensus rounds. To submit a private transaction, encrypt a standard EVM transaction using the ArcaneVM network public key and send the ciphertext as calldata to an Arc precompile. From the public ledger’s perspective, this looks like an ordinary precompile call — the encrypted payload is opaque. Validators running ArcaneVM inside hardware enclaves decrypt, verify, and execute the transaction against private state using standard EVM rules. The privacy precompile returns only an acknowledgement and a predefined gas cost. No execution results, return values, or event logs are exposed to the public ledger. After consensus finalizes the block, a light client inside each enclave verifies the block’s commit certificate before making private state queryable. Retrieve transaction results from an RPC node by providing the transaction hash and proving authorization.

​
Synchronous composability

ArcaneVM finalizes private and public state in the same block by the same validator set. Private and public contracts compose atomically without cross-chain bridges or asynchronous messaging. Bridge assets between public and private contracts through controlled precompile operations that execute within a single block. Both sides of the bridge see consistent state at each block height.

​
Contract isolation by default

ArcaneVM enforces a default-deny isolation model. When you deploy a contract, every function and storage slot is inaccessible to external callers and other contracts by default. Privacy holds even if you forget to add explicit protections. Exposure is opt-in through three mechanisms:
  • Function-level access policies. Each function selector carries an access policy: Open, Restricted, or Locked. Restricted functions require the caller to have an explicit grant. Locked functions revert unconditionally.
  • Trust domains. A contract’s admin can grant trust to specific contracts via addTrustee. Without an active trust relationship, introspection opcodes like EXTCODESIZE, EXTCODEHASH, and BALANCE return zero. Trust is unidirectional and revocable.
  • Runtime visibility enforcement. Solidity visibility modifiers (public, external, internal, private) are enforced at runtime on every CALL and DELEGATECALL, preventing crafted calldata from reaching unintended entrypoints.
Additional isolation behavior: event logging is disabled by default (events require an explicit precompile), cross-boundary probes are masked, revert reasons are sanitized, and gas reporting to external observers is constant-time.

​
Deploying existing Solidity contracts

ArcaneVM reuses standard EVM bytecode and tooling. Core business rules, state management, and function implementations carry over unchanged. The primary adaptation is how contracts expose their interfaces to external callers, through access policy and trust domain configuration. For example, deploy a standard OpenZeppelin ERC-20 token into ArcaneVM without modifying the bytecode, then use the trust domain API to make transfer open to any caller while restricting balanceOf to explicitly trusted contracts — without redeploying.

​
Post-quantum encryption

ArcaneVM uses hybrid post-quantum cryptography to protect against harvest-now, decrypt-later attacks:
  • Public-key encryption uses X-Wing KEM (combining X25519 and ML-KEM-768) with HKDF-SHA256 and AES-256-GCM.
  • Symmetric encryption uses AES-256-GCM-SIV for contract state and AES-256-GCM for state roots.
  • Node-to-node communication uses TLS 1.3 with the X25519MLKEM768 hybrid key agreement.
See Post-quantum security for Arc’s broader quantum-resilience roadmap.

​
Key management

ArcaneVM uses a single master secret key (MSK) distributed across validators through Shamir threshold secret sharing. The MSK can only be reconstructed inside attested enclaves and is never exposed to validator hosts. All derived keys for transaction decryption, per-contract state encryption, and state root encryption come from the MSK. Each validator organization runs an independent KMS with an attestation policy that governs which enclave profiles may access key material. Seed nodes provide fast MSK recovery if a validator restarts. Key rotation is supported when the validator set changes.