Protected by Arcium

The MXE

Enbank's production confidentiality is an Arcium MXE: an MPC execution environment. Arcium defines an MXE as four pieces that ship together.

• A Solana program that receives inputs and queues computations. Arcium programs use the #[arcium_program] macro in place of Anchor's #[program].
• Confidential instructions written in Arcis, Arcium's Rust framework. Functions marked #[instruction] compile to MPC circuits.
• An MXE account on Solana holding metadata: the cluster the MXE is bound to, and the MXE public key clients encrypt to.
• One cluster of Arx nodes. The MXE is bound to a single cluster at a time. arcium migrate-cluster is the documented way to move it.

Nodes run arxOS. Clusters currently execute Cerberus, a dishonest-majority, detect-and-abort protocol. Solana stores configuration, computation accounts, queues, and callbacks. The nodes keep MPC key material offchain and run the circuits offchain.

Encrypted instructions

An Arcis instruction compiles to a circuit. A ComputationDefinitionAccount tells the cluster which circuit to run. Arcium splits that account into an interface (inputs, outputs, required accounts, execution metadata) and, for onchain sources, the circuit bytecode.

The interface account is a PDA. The documented seeds are:

[
  b"ComputationDefinitionAccount",
  mxe_program_id,
  comp_def_offset
]

Bytecode chunks use seeds b"ComputationDefinitionRaw", the computation-definition account, and a chunk index. circuit_hash! embeds a SHA-256 from the build output so Arx nodes can check the circuit they fetch.

Enbank's specified instructions are shield, transfer, allocate, and withdraw. Their private inputs are listed on Architecture. This repository does not contain an encrypted-ixs directory or an Anchor program.

Computation lifecycle

Arcium documents this order. A production Enbank transfer would follow it without skipping the encrypt step.

1. The client encrypts parameters. Arcium's developer docs describe X25519 key exchange and the Rescue cipher for that protection.
2. The client invokes the MXE program with the ciphertext.
3. The MXE program formats the arguments and cross-program invokes the Arcium program.
4. The Arcium program queues the computation in the cluster mempool.
5. The cluster fetches the job and computes it with MPC.
6. The cluster callbacks. The Arcium program verifies the result, then the MXE callback applies it.

Each encrypted instruction generally has three Solana instructions: init_*_comp_def once, the queue instruction per invocation, and *_callback after the cluster finishes. In the hello-world shape, queued arguments include ciphertext bytes, the client public key, and a nonce, for example [u8; 32] ciphertexts and a u128 nonce. That layout is Arcium's example, not an Enbank account.

The lifecycle diagram and the surrounding notes live at docs.arcium.com/developers/computation-lifecycle.

Offsets

Three integers identify where a computation runs. Values below are Arcium's types, not deployed Enbank ids.

Settlement

Solana is the coordinator and the settlement layer. It records the callback outcome the MXE program writes. For Enbank that outcome is the settled bit and the account address. Amount, asset mix, and card destination stay out of those accounts. If a future callback writes them, the privacy claim for that instruction is void. The privacy model is the checklist.

MXE accounts and computation definitions can be closed when unused, reclaiming rent. That lifecycle is Arcium's account-closing flow, separate from a user resetting the preview desk.

This site

Builder references: architecture overview, core concepts, arcium.com/build.