Appearance
v1.1 Arcium Privacy Layer
Shipped: 2026-04-02 | Phases: 8 (6–13) | Plans: 26 | Audit: 28/28 requirements, tech_debt (Nyquist partial)
v1.1 layered Arcium's encrypted compute on top of the billing primitive. The key insight: billing logic can run on encrypted data so that no one — not validators, not competitors, not chain analysts — can see business metrics.
What Shipped
Phase 6: Arcium Foundation
The encrypted compute foundation that makes private billing possible.
- Encrypted mandate validation via Arcium MXE (Multiparty Computation Execution Environment) — Billing amounts and schedules validated without decryption
- Two-phase billing — Arcium validates asynchronously, produces a PullApproval PDA, then the transfer hook consumes it
- Fail-closed design — If Arcium is down, pulls are blocked. No fallback to unencrypted validation
Phase 7: Wrapped USDC + Transfer Hook
Token-2022 wrapped mint with a transfer hook that reads PullApproval on every transfer.
- Wrapped USDC mint — Token-2022 mint wrapping standard USDC for transfer hook compatibility
- Transfer hook reads PullApproval — Every transfer of wrapped USDC checks for a valid PullApproval PDA
- Hook validates pull parameters — Amount, recipient, timing all checked at the token-transfer boundary
Phase 8: Keeper Automation
Cloudflare Worker cron that drives the recurring billing cycle.
- Arcium billing pipeline — Keeper submits encrypted billing requests, Arcium validates, PullApproval is written on-chain
- Grace window retry — Failed pulls retry within a configurable grace window before marking as failed
- Cloudflare Workers deployment — Cron trigger for automated pull scheduling
Phase 9: Checkout Widget + Usage Billing
The embeddable checkout experience and usage-based pricing support.
- 2.6KB embeddable widget — Lightweight checkout widget loaded via
<script>tag - Encrypted usage metering — Usage counts submitted encrypted, validated by Arcium
- Tiered pricing — Support for tiered and per-unit pricing models with encrypted usage counts
Phase 10: Dashboard Analytics
Merchant analytics powered by Arcium-sealed data.
- Arcium-sealed analytics — Billing metrics stored encrypted, only decryptable by the merchant
- Client-side decryption — Merchants decrypt their own analytics in the browser using their key
Phases 11–13: Billing Record Pipeline, Usage D1 Bridge, Private Analytics Pipeline
The data infrastructure connecting on-chain events to the merchant dashboard.
- Phase 11: Billing record pipeline — On-chain billing events indexed and stored
- Phase 12: Usage pipeline D1 bridge — Usage reports from the SDK bridge to D1 with retry/backoff
- Phase 13: Private analytics pipeline — End-to-end sealed compute → fetch → decrypt → render flow
Key Decisions
Arcium over Confidential Balances
Arcium was chosen over Solana's native Confidential Balances extension because:
- Broader scope — Arcium can encrypt billing logic (schedules, proration, usage counting), not just amounts
- MPC-based — Multi-party computation means no single party can decrypt billing data
- Programmable — Custom validation rules run inside the encrypted compute environment
Confidential Balances only hide transfer amounts. Arcium hides the entire billing decision.
Fail-Closed Security
If Arcium is unavailable, pulls are blocked. This is the correct security posture for a billing system:
- No silent fallback to unencrypted validation — Merchants and subscribers rely on the privacy guarantee
- Temporary outage is acceptable — Pulls retry within the grace window once Arcium recovers
- Design principle — Privacy is not optional; it's the product
Two-Phase Billing
The billing flow separates validation from execution:
- Phase 1 (async): Keeper submits billing request → Arcium validates encrypted mandate terms → writes PullApproval PDA
- Phase 2 (synchronous): Transfer hook reads PullApproval → validates pull against approval → executes transfer
This separation means the transfer hook doesn't need to understand encrypted data — it only needs to verify a valid PullApproval exists.
Wrapped USDC Mint
Standard USDC (SPL Token) doesn't support transfer hooks. The solution: wrap USDC in a Token-2022 mint that does support transfer hooks. This gives:
- Transfer hook validation on every transfer
- PullApproval consumption at the token level
- Compatibility with existing USDC liquidity (wrap/unwrap flow)
Validation
The v1.1 audit confirmed:
- 28/28 requirements satisfied
- 8/8 phases verified
- 4/4 cross-phase integrations wired
- 4/4 E2E flows complete (flat billing, usage billing, analytics pipeline, widget subscribe)
The audit status was tech_debt due to Nyquist validation drift on several phases and missing validation artifacts for Phases 11 and 12. These were non-blocking cleanup items.
What Worked
- Two-phase billing — Clean separation between encrypted validation and on-chain execution
- Arcium MXE — Encrypted compute worked as advertised for billing logic
- Widget size — 2.6KB was achievable with careful tree-shaking and lazy loading
- Fail-closed design — No surprises when Arcium had intermittent issues during testing
What Was Inefficient
- Nyquist validation drift — Several phases had draft validation artifacts that were never finalized
- Missing validation artifacts — Phases 11 and 12 had no
VALIDATION.mdfiles, flagged by the audit - Widget subscribe flow — Uses webhook-driven schedule creation instead of direct browser registration. An architectural choice, not a bug, but adds latency.
Technical Debt Created
- Validation artifacts — Phases 7–10 had draft validation files, Phases 11–12 had none
- Arcium deploy runbook — Live devnet verification of
arcium deploy --resumestill requires human execution - Webhook-driven scheduling — Widget-originated subscriptions rely on webhook-driven schedule creation