Why Arcium for Privacy

The Core Insight

For a billing protocol, the data that matters most isn't the payment amount — it's the business intelligence around the payment.

Confidential Balances (Token-2022) encrypts how much you paid. Arcium MPC encrypts how much you used, your billing logic, your revenue, your churn, your credit score. This distinction is the entire strategic case for Arcium.

Why Arcium over Confidential Balances

Detailed Comparison

Dimension	Confidential Balances (Token-2022)	Arcium MPC
Scope	Narrow: encrypts token balances and transfer amounts only	Broad: runs arbitrary computation on encrypted data
What it hides	How much you paid	How much you used, billing logic, revenue, churn, credit score, tier evaluation
Where it runs	On-chain (Solana validators)	Off-chain (Arx node clusters), results settle on-chain
Maturity	Live but had a ZK ElGamal proof bug (Jun 2025 post-mortem)	Mainnet Alpha (Feb 2026)
Dependency	Native Solana — no external network	External network (Arx nodes) — introduces availability dependency
Wallet UX	Requires wallet support for confidential transfers (still rough)	Backend-only — wallets don't need to change
Billing logic	Can't hide tier evaluation, proration, usage aggregation — all remain visible	Can run any billing computation on ciphertext
Analytics	Can't compute aggregate analytics on encrypted data	MRR, churn, credit scoring all computed on ciphertext
Composability	Only works with other Confidential Balance accounts	Works with any data — can combine on-chain + off-chain inputs

The Fundamental Gap

Confidential Balances encrypts the output of a billing decision (the transfer amount). Arcium encrypts the computation that produces that output. For a billing protocol, hiding the computation is what matters:

• A competitor watching on-chain can't see that a merchant is running tiered pricing with usage metering.
• A chain analyst can't determine which subscribers are on premium plans vs. basic.
• A lender can verify MRR exceeds a threshold without seeing individual merchant revenues.

Partnership Strategy

Arcium launched Mainnet Alpha in February 2026. They need flagship applications to prove MXE (Multiparty Computation eXecution Environment) has commercial value beyond academic demonstrations.

This is a mutual dependency:

• VelaPay becomes Arcium's flagship commercial application. Billing is one of the most compelling use cases for encrypted compute — it touches every business metric that matters.
• Arcium provides the privacy infrastructure VelaPay needs. Without encrypted compute, VelaPay is just another transparent on-chain billing system where competitors can read your entire customer base.

The partnership gives VelaPay early access to Arcium's MXE capabilities and gives Arcium a real-world commercial validation case. Both sides benefit from the other's success.

Arcium Mainnet Alpha Timeline

Phase	Timeline	What it means for VelaPay
Devnet	Available since late 2025	Integration testing, circuit development
Mainnet Alpha	Feb 2026	First production MXE environments — limited availability
Mainnet General	H2 2026 (expected)	Full production MXE with SLAs

VelaPay Phase 1 (Arcium integration) targets Mainnet Alpha. Phase 0 establishes the billing primitive without privacy, which de-risks the Arcium dependency entirely.

Fail-Closed Design and Its Implications

If Arcium is unavailable (network outage, MXE timeout, node failure), billing pulls are blocked, not allowed:

// In vela-transfer-hook validation
if arcium_verification_required && !arcium_verified {
    emit!(ArciumUnavailableEvent { mandate, timestamp });
    return Err(ErrorCode::ArciumUnavailable);
}

Implications of Fail-Closed

Scenario	Behavior	Rationale
Arcium nodes offline	All pulls blocked	Better to miss a payment than execute without validation
Arcium response timeout	Pull fails with typed error	Keepers retry on next cycle
Arcium returns invalid result	Pull fails	Cryptographic verification of MPC output
Arcium network partitions	Some pulls blocked depending on which Arx nodes are reachable	Graceful degradation — partial availability

This is a conscious trade-off: correctness over availability. For a billing protocol handling money, silent overdraft or unauthorized pulls are worse than delayed payments. Merchants can configure retry policies via keepers.

What Happens When Arcium is Down

1. Keeper attempts execute_pull.
2. Arcium MPC round-trip fails or times out.
3. PullApproval is not written.
4. Transfer hook validation fails on the next attempt.
5. ArciumUnavailableEvent emitted for monitoring.
6. Admin dashboard alerts the protocol team.
7. Keeper retries on next cycle (configurable interval).

What Arcium Enables

Full Capability Table

Capability	How Arcium Enables It	Phase	Who Benefits
Usage metering	Usage values flow through encrypted compute — merchants bill on private metrics without exposing usage data to chain observers	Phase 1	Merchants, subscribers
MRR computation	Sum of encrypted revenue values → encrypted total → threshold proof revealed	Phase 3	Lenders, investors
Credit scoring	Arcium evaluates payment history, usage patterns, and billing behavior on ciphertext	Phase 3	Lenders
Churn analytics	Aggregate churn rates computed on encrypted subscription data — no individual subscriber data exposed	Phase 3	Merchants, marketplace
Tiered pricing	Tier evaluation logic runs inside MXE — observers can't determine which tier a subscriber is on	Phase 1	Merchants
Compliance checks	KYC/AML verification via encrypted identity — transfer hook sees allow/deny only	Phase 2+	Regulated merchants
Proration calculations	Mid-cycle plan changes compute exact proration on encrypted billing data	Phase 1	Merchants, subscribers
Revenue-based lending	Verifiable MRR as collateral without exposing individual merchant revenues	Phase 3	Merchants, lenders
Marketplace analytics	Aggregate billing data computed on ciphertext for subscription marketplace	Phase 3	Investors

Encrypted Mandate Validation (Phase 1)

When a pull is requested, Arcium validates all billing constraints on ciphertext:

// All encrypted inputs:
validate_mandate(
    mandate_amount,      // Encrypted — how much to pull
    plan_amount,         // Encrypted — maximum allowed
    subscriber_balance,  // Encrypted — can they pay?
    current_timestamp,   // Encrypted — is it due?
    next_payment_due,    // Encrypted — within billing period?
    expiry,              // Encrypted — mandate still valid?
    pulls_executed,      // Encrypted — over pull limit?
    max_pulls,           // Encrypted — what is the limit?
) -> bool  // Only the boolean result is revealed

No plaintext balance or amount is ever exposed to validators, competitors, or chain analysts.

Encrypted Billing Records

record_billing_event(
    amount_charged,
    timestamp,
    pulls_executed,
    billing_period,
    payment_method,
) -> EncryptedBlob  // Only merchant can decrypt

Billing records are encrypted with merchant-specific keys. Only the merchant who owns the billing relationship can decrypt individual records. Aggregate analytics use MPC to compute on ciphertext without decryption.

MRR Oracle (Phase 3)

Arcium computes aggregate MRR without exposing individual merchant revenues:

Sum(encrypted_mrr_1 + encrypted_mrr_2 + ...) → encrypted_total
encrypted_total > $50,000 → true/false (revealed only as threshold proof)

Lenders see that a merchant's MRR exceeds a threshold. They never see the actual MRR number, individual subscriber revenues, or churn rates.

Phase 0 Constraint Rationale

No Arcium in Phase 0. The billing primitive must work standalone first.

This is not just a sequencing choice — it's a de-risking strategy:

1. Prove the mandate/transfer hook model works before adding privacy. If the billing primitive doesn't work, privacy doesn't matter.
2. De-risk the Arcium dependency. If Arcium is delayed, VelaPay still works. If Arcium has bugs, VelaPay still works. Privacy is additive, not foundational.
3. Validate the security model. The transfer hook enforcement path is identical in both Phase 0 and Phase 1+. Arcium only changes how the PullApproval is computed, not how it's enforced. This means the core security property survives the privacy layer addition.
4. Enable incremental testing. Phase 0 runs on public data, which makes debugging, testing, and verification straightforward. Privacy adds complexity — it should be layered on top of a proven foundation.

Why Not Start with Arcium

Starting with Arcium would mean:

• Two unknowns shipping simultaneously (billing primitive + encrypted compute).
• Debugging opaque failures (is it the billing logic or the MPC circuit?).
• Dependency on an external network for basic functionality.
• Harder to demonstrate value to early users (privacy is hard to demo).

Privacy Architecture Summary

Who Sees What

Data Type	Protection	Who Sees It	Who Doesn't
Payment amounts (Phase 0)	Standard Token-2022 (visible)	Everyone on-chain	—
Payment amounts (Phase 1+)	Encrypted in Arcium MPC	Nobody except settlement	Validators, competitors, analysts
Subscriber balance	Encrypted in Arcium MPC	Nobody	Validators, merchants (unless pull), subscribers (only own)
Billing logic	Runs inside Arcium MPC	Nobody	Everyone — not even the protocol team
Billing records	Encrypted in Arcium MXE	Merchant only (via decryption key)	Competitors, analysts, protocol team
MRR aggregate	Arcium MPC output (threshold proof)	Lenders see threshold pass/fail only	Individual merchant numbers
Credit score	Arcium MPC output	Lenders see score only	Subscriber details, merchant details
KYC/compliance	Arcium MPC on encrypted identity	Transfer hook sees allow/deny only	Identity details, personal data
Subscription status	Vela Credential on-chain (public)	Everyone	— (intentionally public)
Protocol actions (subscribe, pull, cancel)	On-chain events (public)	Everyone	— (intentionally public)
Token mint involved	On-chain (public)	Everyone	— (intentionally public)

What Observers CAN Infer (Even with Arcium)

On-chain data alone, a chain analyst can still determine:

• That a transfer happened between two addresses.
• That addresses interacted with the Vela program.
• That credential and token artifacts exist.
• That protocol actions were executed (subscribe, pull, cancel, stream settle).
• The token mint involved (USDC, PYUSD, etc.).

What Observers CANNOT Determine (With Arcium)

• Billing logic inputs (encrypted mandate terms, usage values, pricing calculations).
• Merchant-private billing records (individual transaction amounts in context, customer-level revenue).
• Full business meaning (which plan tier, what usage threshold triggered it, whether it was a retry).
• Aggregate analytics (total MRR, customer churn rates, revenue concentration).

Why Not Just Confidential Balances

1. Scope too narrow — Encrypting payment amounts is necessary but not sufficient for billing privacy. The real competitive intelligence is in the billing logic, not the payment amount.
2. UX problems — Requires wallet support for confidential transfers, still rough in early 2026. Arcium is backend-only.
3. ZK proof bugs — Had a significant bug in June 2025 post-mortem. This erodes confidence for a protocol handling money.
4. Can't hide business logic — Tier evaluation, proration, usage aggregation all remain visible. Competitors can reverse-engineer pricing models from on-chain data.
5. No analytics capability — Can't compute MRR, churn, or credit scores on encrypted data. These are the high-value features for VelaPay's Layer 3 vision.

Strategic Positioning

VelaPay is positioned as Arcium's first commercial application that demonstrates real economic value from encrypted compute. This gives VelaPay:

• Early access to Arcium's MXE capabilities and roadmap.
• Co-marketing opportunities (Arcium case studies, conference talks).
• Technical partnership (direct channel to Arcium engineering for circuit optimization).
• Network effects (other Arcium-powered apps may use VelaPay for billing).

The partnership is a competitive moat. Competitors who want to replicate VelaPay's privacy features need to either build their own MPC network or wait for Arcium to support them.