Arcium: Privacy 2.0 for Solana

The Privacy Paradox

The story of crypto privacy has evolved from simple private state and single-user anonymity tools to a new generation of privacy powered by advanced cryptographic primitives and privacy-enhancing technologies that enable shared private state and multi-user privacy—Privacy 2.0.

Elusiv, a privacy application created by the same team behind Arcium, laid the groundwork for Privacy 1.0 with shielded transactions on Solana, while Arcium signifies the next phase: a modular private compute network designed for shared private state.

Privacy is the biggest unresolved issue in crypto.

Transparency has restricted the functionality of the most commonly used blockchains, hindering real-world adoption. Arcium seeks to change this by enabling private computation, allowing Solana developers to create applications where data remains confidential yet computable.

What is Arcium?

Arcium is an encrypted supercomputer—a decentralized private compute network that leverages Multi-Party Computation (MPC) to enable secure and efficient computation over encrypted data.

Unlike alternative solutions—Fully Homomorphic Encryption (FHE), Trusted Execution Environments (TEEs), and Zero-Knowledge Proofs (ZKPs)—which face challenges like inefficiency, security vulnerabilities, and limited usability, Arcium offers a high-performance, decentralized alternative.

Arcium’s architecture is built on Multi-Party eXecution Environments (MXEs), allowing independent clusters of nodes to process encrypted computations in parallel, significantly improving speed and scalability. It requires only one honest participant to guarantee privacy while using cryptographic proofs and economic incentives (staking/slashing) to ensure honest execution.

The Evolution of Privacy

Before we get into the details, let’s examine how we have gotten to where we are today. In general, crypto’s journey with privacy has been fragmented:

Phase 1: Special-Purpose Privacy

Anonymous cryptocurrencies (e.g., Monero, Zcash) provided early financial privacy, while tools like TornadoCash and Railgun introduced more programmable privacy to the EVM ecosystem through mixers and shielded pools. However, these solutions remain isolated with limited functionality and lack broader ecosystem integration.

Phase 2: Private State

Zero-Knowledge Proofs (ZKPs) enable private transactions and smart contracts on privacy-focused Layer 1s and Layer 2s (e.g., Aztec, DarkFi, Aleo). However, privacy remains siloed within individual blockchains or applications. Functionality and use cases are also limited because these systems support private state rather than shared private state.

Phase 3: Shared Private State

A major leap in crypto privacy, often referred to as “Privacy 2.0.” It enables multi-party, collaborative computation while preserving confidentiality, expanding privacy beyond financial transactions into broader, general-purpose data privacy use cases. This shift unlocks previously unattainable applications, such as private AI, dark pools on public blockchains in DeFi, and private data monetization.

Single Private State vs. Shared Private State

Blockchain’s transparency is both its strength and its Achilles’ heel. While open ledgers provide verifiability, they hinder many industries from adopting crypto rails. Current privacy solutions have limited functionality—ZKPs allow for verifiable computations while keeping inputs private, but they do not support shared privacy across applications or users. As a result, AI companies cannot train models on sensitive data, DeFi traders cannot protect their strategies, and enterprises cannot leverage blockchains for private business logic.

The Limits of Pure ZK for Privacy

ZKPs allow verification without revealing inputs but have limitations:

• No Collaborative Privacy: ZKPs prove computations but don’t allow multiple parties to compute on shared encrypted data.
• Performance Bottlenecks: Proving correctness is computationally expensive, making ZK unsuitable for large-scale, dynamic computations.
• Limited Functionality: ZKPs protect inputs and outputs but do not maintain encrypted state across multiple transactions or parties.

For full-scale privacy in crypto, we need shared private state—a system where multiple parties can compute on private data while preserving confidentiality. This is essential to unlock new applications and use cases beyond single-user privacy solutions.

Core Use Cases That Need Shared Private State:

• Dark Pools / Central Limit Order Books (CLOBs) - allow traders to place orders without seeing the order book, ensuring privacy in order matching.
• Private AI Inference - process proprietary models without exposing model weights, enabling applications like DeFi strategy automation and personalized AI.
• Private AI Training - enables models to learn from private datasets, such as medical records, without exposing sensitive information. This allows collaboration between data owners and model creators while maintaining privacy.
• DeFAI - Threshold decryption AI agents to enhance user experience by securely managing transactions. Using MPC, a wallet’s private key is split across multiple parties, processing transactions without ever reconstructing or exposing the key in plaintext.
• Private Gaming - For games requiring a hidden state to ensure fair gameplay, think of casino games (e.g. blackjack, poker) and games like Doom, where the location of other plates must be hidden. 

Privacy 1.0 vs Privacy 2.0

Enabling Shared Private State 

Privacy in crypto is evolving beyond transactional anonymity into a more expansive concept: shared private state (SPS). Unlike personal private state (PPS), where data is controlled and viewed by a single entity, SPS enables multiple participants to interact with, compute on, and update private data without compromising confidentiality.

SPS is critical for unlocking new economic models and applications that require multi-party collaboration on private data.

This includes dark pools, private lending pools, confidential multiplayer games, and on-chain AI models that process private inputs.

The challenge lies in maintaining privacy while allowing computation—ensuring that updating or interacting with SPS does not inadvertently reveal sensitive information.

Core primitives: MPC, FHE, TEEs

Multi-Party Computation (MPC)

MPC enables multiple parties to compute a function without revealing their private inputs. Distributing computation across participants removes the need to trust a single entity, making it ideal for key management, collaborative AI training, and private auctions. While MPC is flexible, it comes with computational and communication overhead, and its security depends on protocol design and participant behavior.

Fully Homomorphic Encryption (FHE) 

FHE allows computations on encrypted data without decryption, ensuring privacy throughout the process. This makes it valuable for privacy-preserving smart contracts, encrypted AI inference, and regulatory-compliant data processing. However, FHE is significantly slower than traditional computation, with high resource costs and challenges verifying computation integrity.

Trusted Execution Environments (TEEs) 

TEEs create isolated hardware-secured zones for computation, shielding data from external access. They are used for confidential DeFi applications, AI privacy, and hybrid security models that combine cryptography with hardware protections. While TEEs offer high performance, they rely on hardware vendors for security and are vulnerable to side-channel attacks.

Defining the Privacy Space

Crypto is full of complex jargon and narratives. The field of privacy is no different, and over the years, several definitions have been developed to explain various aspects related to this vertical. As shared private state becomes the canonical technical standard for enabling privacy-preserving applications, there is an emergence of terms and definitions for packaging this vertical on a high level. Here are some of the terms you may come across for defining shared private state:

• Privacy 2.0: The evolution from isolated personal private state to shared private state, enabling collaborative, confidential computation among multiple parties.
• Decentralized Confidential Computing (DeCC): Privacy-preserving computation frameworks that operate in decentralized environments without exposing sensitive data.
• Private Compute(ing) Networks: A Private Compute Network enables secure, privacy-preserving computation using cryptographic techniques or hardware-isolated environments to process data without exposing raw inputs.

Shared Private State: Crypto’s New Whitespace

Arcium is driving the shift from Privacy 1.0—where private state was isolated—to Privacy 2.0, enabling shared private state for confidential multi-party computation on Solana.

By removing blockchain’s transparency constraints it unlocks new economic models and applications that were previously impossible. This transition moves privacy from a special-purpose feature to a general-purpose framework, extending its impact beyond financial transactions.

As privacy becomes essential for real-world adoption, shared private state emerges as crypto’s new whitespace—unlocking entirely new applications, expanding blockchain functionality, and delivering the privacy needed for decentralized systems to scale.

Arcium’s Architecture 

Arcium is engineered for private, decentralized, and efficient computing, enabling shared private state for any application. Leveraging advanced cryptographic techniques like Multi-Party Computation (MPC) it enables trustless, verifiable computations over encrypted data without relying on a central authority.

To package the capabilities and functions of Arcium, we describe the network as an ‘encrypted supercomputer.’ Analogous to a traditional computing stack, each node acts as a single processor contributing to the encrypted supercomputer. Through the assembly and unification of all these processors, the supercomputer materializes with its unique features.

arxOS is a distributed, encrypted operating system (Arcium’s network of Nodes) that executes computations. MXEs (Multiparty eXecution Environments) are the supercomputer’s virtual machines — highly configurable environments where computations are defined and securely executed. Lastly, Arcis is a Rust-based programming language and Arcium’s developer framework.

Arcis

Arcis is a Rust-centric framework for developing secure multi-party computation (MPC) circuits on the Arcium network, enabling privacy-preserving computations over encrypted data. Providing a powerful and intuitive interface, Arcis makes it easy to design and implement MPC circuits.

Built on Rust’s safety guarantees, Arcis overrides the standard types (e.g., u8, bool, f64, etc.) with masked variations. It also supports fixed-size arrays and structs, allowing developers to model complex data structures while preserving confidentiality. The framework supports arithmetic, logical, and comparison operations across encrypted and plaintext types (types may be revealed mid-way through circuits to improve speed). Notably, conditional logic using masked values requires both branches to execute to prevent side-channel leaks, ensuring data-independent execution paths. For numerical precision, the mask f64 variation employs a fixed-point representation with 52 fractional and 75 integer bits (in the future, this will be relaxed to support a more dynamic range), enabling rational number handling within finite fields.

Arcis handles circuit inputs and outputs that are either plaintext or ciphertext (encrypted with the symmetric Rescue cipher). Performance optimizations are critical: secret-shared multiplications incur high overhead, while additive operations and plaintext interactions are efficient. Comparisons requiring bitwise decomposition are costly, and control flow cannot depend on secret values (e.g., no early returns based on encrypted conditions).

Multi-Party eXecution Environments (MXEs)

MXEs are isolated, dedicated virtual environments for secure computation execution. They are highly configurable, enabling fine-tuning of data provisioning and handling, encryption schemes, and more. Created by ‘computation customers’, MXEs are MPC protocol-agnostic and run on top of clusters—either a particular chosen cluster or rotating between multiple pre-selected clusters based on availability. MXEs are defined as either “persistent,” meaning that they can be reused indefinitely into the future, or “single-use,” indicating that the MXE may only be used for one computation and then automatically discarded.

MXEs handle encryption through customer-defined encryption schemes, which use specific encryption keys to secure data within the MXE's computations. For efficiency, these encryption schemes can be shared across multiple MXEs belonging to the same computation customer.

However, encryption can also be optionally disabled if not required for a particular use case. When an MXE joins a new cluster, it triggers a distributed key generation (DKG) system computation, during which each node in the cluster receives a fragment of the overall cryptographic key (keyshare).

The security guarantees of an MXE depend on its chosen MPC protocol. With Cerberus, Arcium’s initial primary MPC protocol, computation integrity is guaranteed as long as at least one node in the cluster remains honest. However, alternative protocols like Manticore (also supported at launch) operate under different security assumptions, trading stronger security guarantees for improved performance in specific use cases (e.g., resource-intensive tasks like model training for AI).

ArxOS

ArxOS is Arcium's distributed operating system, consisting of the distributed network of Arx nodes, the clusters they form, and the MXEs that execute within those clusters.

Like cores and processes in a traditional operating system, arxOS coordinates how Arx nodes work together in clusters to execute MPC computations, manages the distribution of keyshares between nodes, and enables parallel processing through configurable MXE environments.

The system supports multiple MPC protocols like Cerberus and Manticore, allowing different security and performance tradeoffs depending on computational needs. While the Solana blockchain handles orchestration, arxOS provides the distributed computational fabric where confidential computing occurs.

Supported MPC Protocols

While existing solutions for secure computation, such as Trusted Execution Environments (TEEs), require the trust of both hardware manufacturers and third-party attestation services, Arcium's disintermediated architecture means that no single entity controls a given computation. It is based on multiparty computations, which afford information-theoretic security. It works by splitting data across clusters of nodes, ensuring no single party ever accesses plaintext. 

Within this operational paradigm, many different levers can be activated depending on the application's security requirements. The computation is typically divided into two phases: a first preprocessing phase that can be executed before any data is inputted into the system and an online phase where the preprocessed data is consumed to execute the program securely on the private data. 

The Network's security guarantees are protocol-dependent, offering flexibility to match different use cases' trust requirements.

Cerberus

Cerberus is Arcium's main backend for MPC computations. Each share is authenticated with a Message Authentication Code (MAC), allowing honest nodes to verify integrity and detect tampering, ensuring that computations are aborted if malicious behavior is detected.

Under the assumption that at least one node in the given cluster is honest, the computation's result is guaranteed to be correct. The preprocessing data is generated by the nodes in a pairwise fashion. Cerberus provides the strongest security guarantees of Arcium’s two initially supported MPC protocols. 

Manticore

Manticore operates in the “honest but curious” setting, where it is assumed that the nodes do not deviate from the protocol instructions or tamper with data. It also relies on a “trusted dealer,” a node that generates the preprocessing data needed for the online phase and then goes offline. This leads to faster execution time.

Furthermore, it uses matrices (instead of single values) as a fundamental building block, making it better suited for more complex operations typical of Machine Learning and AI applications. However, this speed comes at the expense of weaker security guarantees, as explained above. Manticore is designed to be deployed in settings where the nodes in the given cluster are trusted operators and, therefore, are incentivized to behave honestly (e.g., in permissioned or partially permissioned clusters).

Economic Incentives

The Network's trust model is further strengthened through its economic design. Nodes must stake tokens to their own Arx nodes, providing "skin in the game" and making malicious behavior economically irrational. Both node operators and third-party delegators face slashing penalties for misbehavior, creating aligned incentives for honest operation.

Additionally, a cluster can optionally require TEE support (from the Arx nodes within the cluster) for enhanced keyshare protection. However, this remains supplementary to the core cryptographic guarantees provided by the MPC protocols themselves.

Building Encrypted Solana Programs

Traditional CLOB DEX trading is straightforward - you execute a transaction with public parameters like bid amount, size, and your public key. However, dark pool trading requires encrypted on-chain order books, adding complexity to protect trade privacy. Let's explore how Arcium enables this through computation on encrypted trade data.

Understanding Computation Lifecycle

When trading on a dark pool (or performing any encrypted computation with Arcium), the process follows these steps:

1. Client Encryption

• The client encrypts the order parameters
• Invokes computation through the MXE (MPC eXecution Environment) program

2. Program Interaction

• MXE program formats parameters and performs a CPI call to the Arcium Program
• Arcium Program adds the computation to the MXE's on-chain mempool

3. MPC Processing

• MPC cluster retrieves computations from the mempool
• Executes computation using secure multi-party computation (MPC) 

4. Result Handling

• For small outputs: MPC cluster directly calls the finalize computation instruction
• For larger outputs, data is sent to the callback server for state updates and finalization

5. Completion

• Arcium Program verifies results
• Triggers callback function in MXE program
• MXE program notifies the user of the completed computation

Project Structure and Setup

With this understanding of the basic flow, we can explore building an encrypted on-chain order book. This example demonstrates how Arcium's components work together to enable confidential trading.

Arcium's development toolkit is built as an extension of Anchor, making it familiar to Solana developers. The main difference is using the arcium CLI instead of the anchor CLI. This foundation makes it easier for developers to transition from building regular Solana programs to creating encrypted applications.

There are two main components to building with Arcium:

1. Onchain program: This comprises your Solana Anchor program, with added Arcium annotations for confidential computations.
2. Confidential Computing instructions: These are the instructions that you want to execute confidentially. Using Arcium's Arcis compiler, you can define these instructions in Rust and compile them to a format that can be executed on the Arcium Network.

To build a dark pool, we simply need an on-chain encrypted order book. This book contains a list of orders, each with specific fields, bid, size, and owner specifying the order's details.

The above image shows the structure of a project initialized with arcium init command.

Note that there is a new folder called confidential-ixs aside from the usual structure of an Anchor project.

Defining Encrypted Data Structures

Within confidential-ixs/src/lib.rs, we can define the Order and OrderBook structs, which have encrypted fields.

const ORDER_BOOK_SIZE: usize = 10;

#[derive(ArcisType, Copy, Clone, ArcisEncryptable)]
pub struct OrderBook {
    orders: ArcisArray<Order, ORDER_BOOK_SIZE>,
}

#[derive(ArcisType, Copy, Clone, ArcisEncryptable)]
struct Order {
    size: mu64,
    bid: mbool,
    owner: mu128,
}

Here, we define the Order and OrderBook structs, with OrderBook containing an array of Order structs. Each Order struct has three fields: size, bid, and owner.

You might have noticed that the field types are prefixed with m, which stands for masked. This indicates the field is encrypted and not stored as normal plaintext on-chain.

We also derive the ArcisType trait for Order struct, a helper trait that allows the Arcis compiler to use the given data as input/output for confidential computations. 

Computing on Encrypted Data

Now that we have our data structures defined, we can define the instructions we want to execute on them. For instance, we can define an instruction to add an order to the order book.

#[confidential]
fn add_order(
    order: [Ciphertext; 3],
    order_public_key: PublicKey,
    order_nonce: u128,
    ob: &[Ciphertext; 30],
    ob_nonce: u128,
) -> [Ciphertext; 30] {
    let order_cipher = RescueCipher::new_with_client(order_public_key);
    let order = order_cipher.decrypt::<3, Order>(order, order_nonce);
    let ob_cipher = RescueCipher::new_for_mxe();
    let mut ob = ob_cipher.decrypt::<30, OrderBook>(ob, ob_nonce);

    let mut found: mbool = false.into();
    for i in 0..ORDER_BOOK_SIZE {
        let overwrite = ob.orders[i].size.eq(0).bitand(!found);
        ob.orders[i] = overwrite.select(order, ob.orders[i]);
        found = overwrite | found;
    }

    let enc_ob = ob_cipher.encrypt::<30, OrderBook>(ob, ob_nonce);
    enc_ob
}

Here, we are trying to add an order to an existing order book. The order parameter is passed by value, with its corresponding encryption public key and nonce. The order_book parameter is passed by reference so that the nodes will fetch the data from the on-chain account on Solana. Again, we also need the nonce for the order book, even though it is passed by reference. We don’t need to pass the public key for its encryption as it is encrypted using the global public key of the cluster.

To use these parameters for computation, we need to decrypt them to corresponding secret shares for the nodes to compute in MPC. We first instantiate a RescueCipher for each parameter and then decrypt them using the decrypt method. This generates secret shares for each node to use for computation. This does not reveal the plaintext data underneath to the nodes during the process.

Here, the order parameter disappears after processing the confidential instruction (as expected in regular Rust).

To output the new order book, we encrypt it back using Rescue to get the Ciphertext type again and return it.

Integrating with Solana Programs

Now we know how to compute on encrypted state, but how does this fit into our on-chain Solana program?

Inside our Solana program, there are three steps for each computation - one of which is a one-time setup when deploying our program, and the other two are relevant for each time a computation is called.

First, we need to initialize each of the confidential computing instructions for our MXE. The arcium cli with Arcis compiles our confidential instructions to their respective MPC bytecodes which Arx nodes can execute. Then, within our program, we use the init_comp_def helper function from the Arcium SDK, essentially a wrapper over a CPI call to the Arcium program.

pub fn init_add_order_comp_def(ctx : Context<InitAOCompDef>, finalize_auth : Pubkey) -> Result<()>{
        init_comp_def(ctx.accounts, true, None, Some(finalize_auth))?;
        Ok(())
    }

Again, we specify a macro defined in the arcium_macros crate for the context struct. It verifies the accounts being passed and the existence of the add_order confidential instruction. 

#[init_computation_definition_accounts("add_order", payer)]
#[derive(Accounts)]
pub struct InitAOCompDef<'info> {
    #[account(mut)]
    pub payer: Signer<'info>,
    #[account(
        mut,
        seeds = [MXE_PDA_SEED, &ID_CONST.to_bytes()],
        seeds::program = ARCIUM_PROG_ID,
        bump = mxe_account.bump
    )]
    pub mxe_account: Box<Account<'info, PersistentMXEAccount>>,
    #[account(mut)]
    /// CHECK: comp_def_account, checked by arcium program. 
    /// Can't check it here as it's not initialized yet.
    pub comp_def_account: UncheckedAccount<'info>,
    pub arcium_program: Program<'info, Arcium>,
    pub system_program: Program<'info, System>,
}

Now, whenever we want to add an order to the order book, we just use the queue_computation CPI wrapper function.

pub fn add_order(ctx: Context<AddOrder>, bid: [u8;32], owner: [u8;32], size: [u8;32], encryption_pubkey: [u8;32], nonce: u128) -> Result<()> {
        let args = vec![
            Argument::EncryptedBool(bid),
            Argument::EncryptedU128(owner),
            Argument::EncryptedU16(size),
            Argument::PublicKey(encryption_pubkey),
            Argument::PlaintextU128(nonce),
            // Offset of 8 (discriminator) + 1 (bump) + 2 (update_count) + 16 (nonce) + 32 (encryption pubkey)
            Argument::Account(ctx.accounts.ob.key(), 8 + 1 + 2 + 16),
            Argument::PlaintextU128(ctx.accounts.ob.nonce),
        ];

        // Call the Arcium program to queue the computation
        queue_computation(
            ctx.accounts,
            args,
            vec![CallbackAccount{
                pubkey: ctx.accounts.ob.key(),
                is_writable: true,
            }],
            Some(“callback-server-url”), // None if you can fit the output data within a single transaction
        )?;
        Ok(())
    }

Inside our program's add_order function, we just format the arguments for the confidential instruction before passing them within queue_computation. We pass the required accounts for the CPI, the arguments, accounts that we need to be passed for the corresponding callback function for the transaction when we get back the result for the computation, and an optional link to a callback server which might be required in case the output of the computation is larger than the size limits of a transaction (more than what can fit inside the callback transaction). 

#[arcium_callback(confidential_ix = "add_order")]
    pub fn add_order_callback(ctx: Context<AddOrderCallback>, output: Vec<u8>) -> Result<()> {
        let ob_updates : [[u8;32]; 20] = output.chunks_exact(32).map(|c| c.try_into().unwrap()).collect::<Vec<_>>().try_into().unwrap();
        ctx.accounts.ob.orders[0..20].copy_from_slice(&ob_updates);

        emit!(OrderPlaced{timestamp: Clock::get()?.unix_timestamp});
        Ok(())
    }

The callback function for each confidential computation execution has to follow the naming convention <confidential-ix-name>_callback and should only take in a Vec<u8> named output.

Inside this callback function, we map the output bytes to the order book account and emit an event specifying that an order has been placed at the current timestamp. 

Testing on Client Side

And now finally, to test this out on the client side.

const privateKey = x25519RandomPrivateKey();
const publicKey = x25519GetPublicKey(privateKey);
const mxePublicKey = [new Uint8Array(/* MXE public key here */)];

const rescueKey = x25519GetSharedSecretWithMXE(privateKey, mxePublicKey);
const cipher = new RescueCipher(rescueKey);

const orderSize = BigInt(1);
const orderBid = BigInt(true);
const orderOwner = BigInt(3);

const plaintext = [orderSize, orderBid, orderOwner];
const nonce = randomBytes(16);
const ciphertext = cipher.encrypt(plaintext, nonce);

// Add an order to the orderbook
const addOrderSig = await program.methods.addOrder(
      ciphertext[0],
      ciphertext[1],
      ciphertext[2],
      Array.from(publicKey),
      new anchor.BN(deserializeLE(nonce).toString())
    ).accountsPartial({
      payer: owner.publicKey,
      clusterAccount: arciumEnv.arciumClusterPubkey,
    }).rpc({
      skipPreflight: true,
      commitment: 'confirmed',
});
console.log("Add order sig is ", addOrderSig);

const finalizeAddOrderSig = await awaitComputationFinalization(
      provider as anchor.AnchorProvider,
      addOrderSig,
      program.programId,
      "confirmed"
);
console.log("Finalize add order sig is ", finalizeAddOrderSig);

Here, we simply generate a random private key for the x25519 ECDH with MXE publickey to see the Rescue cipher. Then, we can use it to encrypt the order inputs locally, and then call the add_order function on the program with the required parameters. Arcium TS SDK provides awaitComputationFinalization function which returns the signature of the callback transaction allowing you to track progress of the computation.

These are the basics of how we can build with Arcium. Up to 40% of US stock trading volume happens in dark pools, where major investors benefit from confidentiality, price stability, and efficient execution. However, these dark pools require trust in a centralized intermediary to execute, resulting in multiple firms being fined for exploitation. On-chain dark pools could mitigate these risks and provide a new, secure substrate for DeFi to expand significantly.

Conclusion

Privacy has long been overlooked in application development. Privacy 1.0 struggled with poor UX and limited functionality. Now, Privacy 2.0 introduces a new paradigm—where shared private state unlocks an entirely new whitespace for on-chain applications. Arcium powers the next generation of DeFi, DePIN, and AI while also advancing existing use cases on Solana.

Solana builders can now apply to Cohort 2 of our Private Testnet—the final phase before our Public Testnet launch.

Additional Resources

• Arcium Documentation
• Arcium Deep Dive
• Arcium Blog
• Arcium Whiteboard Series