Transfer Amount Privacy: Research & Alternatives

Date: April 2026 Status: Decision pending C-SPL ship date

---

The Privacy Gap

VelaPay uses Arcium MPC to encrypt billing validation inputs — the amount, balance, timestamp, and usage metrics passed to validate_mandate are never seen in plaintext by any node. The MPC circuit returns only a boolean approval.

However, when execute_pull fires, it executes a standard SPL Token-2022 transfer from the subscriber's token account to the merchant's. That transfer — including the exact amount — is recorded publicly on-chain and visible in transaction logs. Chain analysts can observe: subscriber wallet → merchant wallet, X USDC, at timestamp T.

What is private today:

• Billing validation inputs (amount, balance, usage metrics) — encrypted via Arcium MPC
• Billing event records — BillingEvent.encrypted_blob (320 bytes, merchant-decryptable only)
• Usage reports — encrypted_usage (128 bytes)

What is public today:

• The token transfer amount at execute_pull (Token-2022 transfer log)
• Subscriber/merchant wallet addresses
• Timing of each pull, pull count, mandate status

---

Option 1: Solana Native Confidential Transfer (Token-2022)

What it is: A Token-2022 extension using ElGamal encryption and ZK proofs to hide transfer amounts on-chain.

Bug history: A ZK ElGamal proof program vulnerability was discovered April 16, 2025 — missing algebraic components in the Fiat-Shamir transformation allowed manipulation of ZK proofs, potentially enabling unauthorized minting or theft. Patches were distributed privately to validators April 17, 2025; supermajority adopted within 24 hours. No exploit occurred.

Why it doesn't work for VelaPay: Even with the bug fixed, Token-2022 confidential transfers have a fundamental constraint — smart contracts and PDAs cannot interact with confidential token balances. VelaPay's execute_pull fires through a Transfer Hook, which is a program CPI. The transfer hook mandate enforcement is incompatible with Token-2022 confidential transfers entirely. Ruled out.

---

Option 2: C-SPL (Arcium Confidential SPL)

What it is: Arcium's own confidential token standard, announced at Breakpoint 2025. Extends SPL Token model with MPC-backed encrypted balances and transfer amounts.

Key innovation: Introduces "confidential smart token accounts" — PDAs can own and operate confidential token accounts, and programs can initiate confidential transfers through Arcium's MXE. This directly solves the PDA incompatibility that blocks Token-2022 confidential transfers.

How it would work for VelaPay:

• Subscriber holds USDC in a C-SPL confidential account
• execute_pull instructs Arcium MXE to transfer from subscriber's confidential account to merchant's
• On-chain: only a proof of valid execution, no amount visible
• Trust model: same Arcium MPC already used for billing validation — no new trust assumption

Current status (April 2026):

• Arcium Mainnet Alpha: live (February 4, 2026)
• C-SPL: "approaching final stages" as of February 2026, not yet confirmed shipped
• Target was Q1 2026 mainnet — no public launch announcement found as of April 21, 2026

Verdict: Best long-term fit. Same trust model as existing Arcium integration. Watch @ArciumHQ and Arcium's Substack for devnet launch announcement.

---

Option 3: Umbra SDK

What it is: A TypeScript SDK (Node.js/browser) built on Arcium's MXE. Provides Encrypted Token Accounts (ETAs) using Rescue cipher + X25519 keypairs, and a UTXO mixer pool for anonymous transfers.

ETA architecture:

• Balances stored as ciphertext on-chain (nonce + encrypted amount)
• Ownership via Ed25519 (L1 Interaction Key), decryption via X25519 keypair
• PDAs can own ETAs with custom decryption schemes

Why it doesn't fit VelaPay's pull model:

The Umbra transfer model is a push model — sender creates a receiver-claimable UTXO, recipient scans the off-chain indexer and claims it. For VelaPay, the merchant initiates the pull without any subscriber action after initial authorization. To use Umbra, the flow would have to invert:

Today:   Merchant → execute_pull → Transfer Hook → subscriber ATA (trustless)
Umbra:   Subscriber → create UTXO → Merchant scans → claims UTXO (push)

The fundamental blocker: for a program to autonomously debit a PDA-owned ETA, it needs the X25519 private key for that ETA. On-chain programs are fully transparent — there's no way to hold a private key secretly in an Anchor program. This is the exact problem C-SPL solves via MPC.

Limited use: Merchant can deposit received USDC into their own ETA after a pull to hide accumulated revenue. Doesn't solve the pull amount visibility problem.

---

Option 4: Umbra ETA Workaround (Pre-Signed UTXOs)

What it is: A workaround that keeps amount privacy while approximating the pull model, at the cost of architectural compromises.

How it works:

1. At subscription creation, subscriber deposits N × billing_amount USDC into their Umbra ETA
2. Subscriber pre-signs N UTXO creation transactions off-chain — one per billing period, each time-locked to next_payment_due
3. VelaPay keeper stores these pre-signed transactions (encrypted, off-chain)
4. Each period: keeper submits next pre-signed tx → Arcium creates receiver-claimable UTXO for merchant → merchant keeper scans and claims
5. On-chain: only ZK proof of UTXO creation + claim, no amount visible

Works with few users: cryptographic privacy, not statistical — amount hidden regardless of cohort size.

Trade-offs:

Property	Status
Transfer amounts hidden	Yes
Works with few users	Yes
Trustless pulls	No — keeper holds pre-signed txs (custody risk)
Subscriber must act each period	No — pre-signed at setup
Capital lockup	Yes — N periods pre-funded upfront
Transfer hook mandate enforcement	No — bypassed entirely
Dynamic/usage-based billing	No — amount fixed at signing time

Verdict: Viable for a private beta or demo showing amount privacy end-to-end. Not suitable as the production primitive — loses trustless mandate enforcement and usage billing.

---

Option 5: MagicBlock Private Ephemeral Rollups (PERs)

What it is: An Intel TDX TEE-backed ephemeral rollup. Standard Solana programs (including Anchor) run unchanged inside TEE validators. Transactions inside the rollup are not publicly broadcast. Settlement pushes final balance states back to Solana mainnet.

Privacy flow:

Subscriber deposits USDC → private PER balance  (deposit is public)
  VelaPay keeper triggers pull inside TEE        (transfer not broadcast)
  Settlement → mainnet sees updated balances     (individual tx hidden)

Why more promising than Umbra for VelaPay: Programs run natively inside the TEE without modification. The pull model might work if keeper delegation (third-party signing on subscriber's behalf) is supported by the permission group system — this is the key open question to verify with MagicBlock directly.

Two hard blockers:

1. Balance delta leaks at settlement: Mainnet sees subscriber balance −X, merchant balance +X after settlement. The amount is inferable from the balance change, even though the individual transfer instruction is hidden. This is a meaningful but partial improvement.

2. Compliance framework conflicts with permissionless design: OFAC screening, IP geofencing, and licensed deployments are baked into the infra layer at ingress — before any transaction is accepted. This conflicts with VelaPay's permissionless subscription primitive.

Open question for MagicBlock: "Can a keeper (authorized third party) sign transfer transactions from a subscriber's private PER balance without the subscriber being online?" — determines pull model viability.

Verdict: More promising than Umbra, blocked by settlement leak and compliance overhead. Revisit if C-SPL is delayed beyond Q2 2026 and MagicBlock confirms keeper delegation.

---

Option 6: NEAR Intents

What it is: NEAR Protocol's intent-based execution system — users sign intents, solvers compete to fulfill them optimally across chains.

Why it doesn't work: NEAR Intents is an execution optimization layer, not a privacy primitive. The final settlement leg on Solana is still a public Token-2022 transfer. Solver batching provides no privacy guarantee (solvers are profit-motivated, not privacy-motivated). Routing through NEAR breaks VelaPay's transfer hook mandate enforcement — the mandate is Solana-local and requires the SPL transfer to fire the hook atomically. Ruled out.

---

Comparison Table

Approach	Amount hidden	Works with few users	Trustless pulls	Trust model	Status
Today (Token-2022)	No	—	Yes	None	Shipped
Solana Confidential Transfer	Yes	Yes	No (no PDA support)	ZK proofs	Bug fixed, PDA gap remains
C-SPL (Arcium)	Yes	Yes	Yes (PDA-owned ETA)	Arcium MPC	Not yet shipped (Apr 2026)
Umbra ETA workaround	Yes	Yes	No (pre-signed, keeper custody)	Arcium MPC	SDK shipped
MagicBlock PERs	Partial (balance delta leaks)	Yes	Unclear	Intel TDX + MagicBlock	Shipped
NEAR Intents	No	—	No	Solver trust	Shipped

---

Decision

Long term: Wait for C-SPL. It is the only option that provides cryptographic amount privacy with trustless program-initiated pulls under the same trust model VelaPay already uses. Monitor Arcium's Substack and @ArciumHQ for devnet announcement.

Interim: Do not ship amount normalization — ineffective with few users (small cohort makes correlation trivial). No interim mitigation until user count grows to a level where statistical obfuscation is meaningful.

Fallback (if C-SPL delayed past Q2 2026): Evaluate MagicBlock PERs only after confirming keeper delegation support with MagicBlock team directly. Accept the balance delta leak as a known limitation.