Full Control
Deploy code on customer infrastructure while maintaining cryptographic billing control. Data never leaves customer network. Vendor retains payment enforcement.
The Impossible Contradiction
Enterprise customers demand control. They want:
- On-premises deployment — Code runs on their servers, behind their firewall
- Data sovereignty — Sensitive data never leaves their network
- Air-gapped operation — No mandatory cloud dependencies
- Zero vendor visibility — Vendor cannot see usage, data, or access patterns
But vendors need to charge for usage. Traditional licensing creates an unsolvable conflict:
| Approach | Customer Control | Vendor Control |
|---|---|---|
| License Keys | NONE Customer can crack, patch, bypass validation |
WEAK Enforcement via client-side check (bypassable) |
| Usage Tracking | COMPROMISED Vendor sees all usage → no data sovereignty |
STRONG Vendor bills based on logged usage |
| Cloud-Only | ZERO Code on vendor infrastructure → no control |
TOTAL Vendor sees everything, controls everything |
The contradiction: Giving customers full control means vendor loses billing enforcement. Retaining billing control means vendor must track usage (violates data sovereignty) or host code (violates on-prem requirement).
Healthcare won't use cloud ML models (HIPAA). Financial firms won't send trading data to SaaS (compliance). Defense contractors can't upload classified data (ITAR). Government agencies mandate on-prem (FedRAMP Moderate/High).
Result: Vendors turn down massive contracts because they can't solve this contradiction.
Cryptographic Billing Enforcement
PRIVATE.ME breaks the trade-off with Xpass: billing enforcement embedded in the cryptography itself. Not policy-based. Not tracking-based. Mathematical.
How It Works (Simple)
- Customer gets Share 1 — useless alone (information-theoretic guarantee)
- Vendor holds Share 2 — delivered only if payment current
- Code runs on customer infra — execution, data, everything stays on-prem
- Billing is cryptographic — payment stops → Share 2 delivery stops → code stops
- No usage tracking needed — vendor doesn't see what customer does with it
Key insight: The split IS the billing enforcement. Customer has full control over execution. Vendor has full control over access. Both are cryptographically enforced, not policy-enforced.
Technical Architecture
Xpass uses XorIDA threshold sharing to embed billing inside the cryptography. No separate billing layer. No API keys. No usage tracking. The split itself is the enforcement mechanism.
Vendor splits algorithm via XorIDA (2-of-2). Share 1 deployed to customer infrastructure. Share 2 stays on vendor server. Both shares are cryptographic noise alone — information-theoretically useless without the other.
Customer's on-prem software authenticates with vendor using DID (decentralized identifier). Vendor checks payment status. If current → connection established. Connection ID generated: connectionId = SHA-256(didA + didB + scope). Deterministic and symmetric.
Vendor generates connection secret (256 bits), splits via XorIDA, delivers shares. Share 1 already on customer infra. Share 2 delivered over authenticated connection. Shares include HMAC-SHA256 for tamper detection. Epoch expiry: 24 hours default.
Customer's code calls algorithm. Both shares required to decrypt. Reconstruction happens on customer infra (~75µs overhead). Execute algorithm. Purge shares. All data stays on customer network. Vendor never sees inputs, outputs, or usage.
Shares expire every 24 hours. Customer requests fresh shares. Vendor checks payment status again. If payment current → new shares delivered. If payment failed → Share 2 denied → reconstruction fails → code stops working.
No usage tracking needed. Vendor only tracks: "Is payment current?" Binary check. If yes → deliver shares. If no → deny shares. Customer can't bypass — Share 1 alone is mathematically useless. No keys to crack. No validation to patch.
Code Example
// Vendor: Build and deploy to customer infrastructure import { ghostBuild } from '@private.me/xghost'; import { createConnectionId, splitForConnection } from '@private.me/xpass'; // Step 1: Build ghost (XorIDA split) const mlModel = ` return { predict: (features) => { // Proprietary ML model (never exposed) return trainedModel.infer(features); } }; `; const ghost = await ghostBuild({ source: new TextEncoder().encode(mlModel), exports: ['predict'], n: 2, // 2-of-2 threshold }); // Share 1 → Customer's on-prem Docker container // Share 2 → Vendor server (delivered via Xpass) // Step 2: Create connection ID const connId = await createConnectionId( vendorDID, customerDID, 'ml-inference' ); // Step 3: Generate and split connection secret const secret = generateConnectionSecret(connId.value, 1); const shares = await splitForConnection( secret.value.secret, connId.value, secret.value.epoch ); // Distribute Share 2 (Share 1 already on customer infra)
// Customer: Runs on their infrastructure import { createGhost } from '@private.me/xghost'; // Initialize ghost (Share 1 bundled in deployment) const ghost = await createGhost({ customerShare: share1, // From Docker image manifest, server: vendorServer, // Gets Share 2 if payment current did: customerDID, tier: 2, // Xpass billing enforcement tier2Config: { connectionId: connId, shares: [shares.share1, shares.share2], epoch: shares.epoch, } }); // Call ML model (on customer infrastructure) const patientData = loadFromHIPAADatabase(); // Stays on-prem const prediction = await ghost.call('predict', patientData); // Data never left customer network // Vendor never saw inputs or outputs // Billing still enforced (payment required for Share 2)
Real-World Applications
Problem: Hospital won't send PHI to cloud. Solution: Deploy ML model on hospital's HIPAA-compliant servers. Patient data never leaves hospital network. Vendor still charges monthly ($15K/month). Payment stops → Share 2 denied → model stops.
Problem: Hedge fund won't upload trading data to SaaS. Solution: Deploy algorithm on fund's co-located servers. Trades execute on-prem. Vendor charges per-connection ($25K/month). No usage visibility needed — just payment check every 24 hours.
Problem: DoD requires air-gapped deployment (ITAR). Solution: Deploy on SIPRNET. Share 1 on classified network. Share 2 from NIPRNET vendor server (one-way data diode). Vendor gets payment confirmation, delivers shares. No operational data leaves SIPRNET.
Problem: Factory won't connect PLCs to internet. Solution: Deploy optimization algorithm on air-gapped OT network. Share 1 on OT. Share 2 delivered via IT/OT gateway after payment check. Vendor charges annually ($50K/year). Production data stays air-gapped.
Problem: Agency requires FedRAMP Moderate on-prem. Solution: Deploy in agency's AWS GovCloud. Data sovereignty maintained. Vendor charges per-agency ($100K/year). ATO documentation includes Xpass cryptographic enforcement model (replaces traditional license audit).
Problem: Pharma company won't upload proprietary compound data. Solution: Deploy molecular simulation on pharma's HPC cluster. Compound data stays on-prem. Vendor charges per-CPU-hour via epoch-based share delivery (every 1 hour, $500/hour). No usage tracking — just timer.
What This Enables
For Customers
- True data sovereignty. Data never leaves their network. Vendor has no visibility into usage.
- On-premises deployment. Code runs on their infrastructure. Behind their firewall. Air-gapped if needed.
- Audit-friendly. Cryptographic enforcement documented. No "phone home" usage tracking. FIPS 140-2 compliant cryptography.
- No vendor lock-in. Can switch vendors by changing Share 2 source. Share 1 stays on their infra.
- Compliance-ready. HIPAA, FedRAMP, ITAR, SOX, GDPR all satisfied by on-prem execution + no data exfiltration.
For Vendors
- Cryptographic billing. Payment enforcement is mathematical. No client-side bypass possible.
- No usage tracking needed. Don't need to see what customer does. Just: "Is payment current?"
- Win enterprise deals. On-prem requirement no longer blocks contracts. Close healthcare, finance, gov deals.
- Instant enforcement. Payment fails → deny Share 2 → code stops globally. No software update needed.
- Reduced liability. Never see customer data → no data breach risk. No GDPR data processor obligations.
vs Traditional On-Prem Licensing
| Requirement | Traditional License Key | Xpass Cryptographic |
|---|---|---|
| Runs on customer infra | YES Code deployed on-prem | YES Code + Share 1 on-prem |
| Data stays on-prem | DEPENDS Often phones home for validation | GUARANTEED All data on customer network |
| Vendor billing control | WEAK Client-side check (patch binary → bypass) | CRYPTOGRAPHIC Share 1 alone is useless |
| Air-gapped deployment | FAILS License server unreachable | WORKS Share 2 via data diode |
| Compliance documentation | MANUAL Auditors must review license code | MATHEMATICAL Information-theoretic proof |
| Vendor sees usage | OFTEN Phone-home for analytics | NEVER Only payment status check |
Deployment Models
Three integration tiers based on customer requirements:
| Tier | Architecture | Use Case |
|---|---|---|
| Basic | Docker container on customer VM. Xpass shares via HTTPS (24h epoch). Share 2 cached locally. | Standard enterprise (healthcare SaaS, fintech tools). Customer has on-prem requirement but not air-gapped. |
| Air-Gapped | Share 2 delivered via one-way data diode. Manual import every 24h (or automated sneakernet). | Defense (SIPRNET), high-security manufacturing (OT/ICS), classified research. |
| Plus (MPC) | 3-party MPC for reconstruction. Xcompute-verified. Server cannot see shares or secret. | Financial (trading algos), pharma (drug discovery), regulatory compliance audit trail. |
Economic Impact
Xpass unlocks contract values that were previously impossible:
- Healthcare AI: $15-50K/month per hospital. 500 hospitals = $7.5-25M ARR. Previously: $0 (wouldn't deploy to cloud).
- Trading Algorithms: $25-100K/month per hedge fund. 50 funds = $15-60M ARR. Previously: $0 (wouldn't share trade data).
- Government SaaS: $100-500K/year per agency. 20 agencies = $2-10M ARR. Previously: $0 (FedRAMP on-prem required).
- Industrial OT: $50-200K/year per factory. 100 factories = $5-20M ARR. Previously: $0 (air-gapped PLCs).
Total addressable: Contracts that were impossible to close become standard deployments. No product compromise. No usage visibility sacrifice. Pure cryptographic enforcement.
Performance
| Operation | Latency | Frequency |
|---|---|---|
| Share delivery (first time) | ~50ms | Once per 24h epoch |
| Reconstruction overhead | ~75µs | Per algorithm call |
| Epoch rotation | ~100ms | Every 24 hours |
| Payment status check | ~200ms | Every 24 hours |
| Algorithm execution | Unchanged | — |
Overhead: ~75µs per call (reconstruction). Negligible for ML inference (typically 10-100ms), simulations (seconds), or batch processing (hours). Share delivery amortized over 24-hour epoch.
Implementation
Two integration paths depending on your deployment model:
Self-Hosted (Basic/Air-Gapped)
Package your code with Xghost + Xpass. Build Docker image with Share 1. Deploy to customer infrastructure. Run vendor heartbeat server for Share 2 delivery. Customer authenticates with DID, checks payment, delivers shares.
Timeline: 3-4 days integration, 2 days testing, 1 day customer deployment.
SDK Documentation →Managed (Plus MPC)
PRIVATE.ME hosts your Share 2 delivery infrastructure. You provide customer deployment artifacts (Docker image). We handle epoch rotation, payment checks, compliance logging, and MPC reconstruction verification.
Timeline: 1 day onboarding, same-day production deployment. SLA included.
Contact Sales →Enterprise pilot program: We'll integrate Xpass into your first customer deployment at no charge. You pay standard ACI connection fees ($5-15/month per customer) after successful pilot. Limited to 10 vendors in Q2 2026.