> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arc.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Opt-in privacy

> ArcaneVM is Arc's confidential execution environment for Solidity contracts, running alongside the public EVM with synchronous composability and default-deny contract isolation.

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.

<Info>Privacy features are on the roadmap and not yet available on Arc.</Info>

## 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](/arc/concepts/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.