Full Control: Deploy anywhere. Pay everywhere.

The impossible made possible

Full Control solves the fundamental tension between customer data sovereignty and vendor payment control through cryptographic enforcement.

Traditional software licensing relies on honor systems or surveillance. License keys can be copied. Virtual machines can be cloned. Air-gapped systems cannot be monitored. The vendor's only options are to trust the customer or to watch them.

Full Control replaces both with mathematics. Your proprietary algorithm is split using XorIDA threshold sharing. Share 1 deploys to customer infrastructure. Share 2 remains on your server, delivered only when payment is current. Both shares are required for execution. Neither share is useful alone.

Five lines to deploy

Wrap your algorithm in a threshold-protected container. The rest is automatic.

import { createFullControl } from '@private.me/full-control';

// Your proprietary algorithm
function proprietaryAlgorithm(input: Data): Result {
  // Trade secret logic here
  return computeResult(input);
}

// Wrap with cryptographic billing
const protected = await createFullControl({
  algorithm: proprietaryAlgorithm,
  customerDID: 'did:key:z6Mk...',
  scope: 'trading-algo-v2'
});

// Share 1 → customer infrastructure (via Docker image)
// Share 2 → your billing server
await protected.deploy();

import { FullControlClient } from '@private.me/full-control';

// Initialize with Share 1 (from vendor Docker image)
const client = new FullControlClient({
  shareStorePath: '/opt/vendor/share1.bin',
  vendorEndpoint: 'https://vendor.example/api'
});

// Run the algorithm (Share 2 fetched automatically)
const result = await client.execute(inputData);

// Payment current? → Share 2 delivered → result computed
// Payment lapsed? → Share 2 denied → execution fails

No usage tracking. The vendor server only checks: "Is payment current for this customer?" Binary decision. Share 2 is delivered or denied. The algorithm never sends usage data, inputs, or outputs.

Zero to production in minutes

Three speed tiers for every deployment scenario. Choose based on your urgency and infrastructure complexity.

Zero-Click (15 seconds)

One function call. No configuration files. No invite codes. No manual setup. Perfect for prototyping, demos, and integration tests.

import { splitForDeployment } from '@private.me/full-control';

const result = await splitForDeployment(
  'export function predict(x) { return x * 2; }', // algorithm source
  ['predict'], // exported functions
  'did:key:z6MkVendor...', // vendor DID
  'did:key:z6MkCustomer...', // customer DID
  'ml-inference', // scope
  'https://vendor.example.com', // vendor server
  'basic' // deployment tier
);

const { customerArtifact, vendorArtifact, connectionId } = result.value;

Connection ID auto-generated. No invite flow. No manual registration. The split operation creates a unique connection identifier and returns both artifacts ready for deployment.

CLI (90 seconds)

Command-line interface for teams that prefer scripts over code. Single command splits algorithm, generates artifacts, and outputs deployment instructions.

# Split algorithm
full-control split \
  --source ./algorithm.js \
  --exports predict,train \
  --vendor did:key:z6MkVendor... \
  --customer did:key:z6MkCustomer... \
  --scope ml-inference \
  --server https://vendor.example.com

# Output: customer-artifact.json, vendor-artifact.json, connection ID

# Customer: reconstruct and execute
full-control run \
  --artifact customer-artifact.json \
  --function predict \
  --args '[{"x": 42}]'

Scriptable and reproducible. CI/CD pipelines can automate deployment. Version control tracks artifact configurations. No interactive prompts required.

Deploy Button (10 minutes)

Pre-built templates for instant infrastructure deployment. Click one button, fill in environment variables, and your vendor server is live with Stripe billing integration.

Production-ready templates. Each includes database schema, authentication middleware, rate limiting, error handling, and deployment scripts for customer artifacts.

Migration path

Start with Zero-Click for prototyping. Migrate to explicit configuration when you need custom billing logic, multi-region deployments, or compliance requirements.

const config: FullControlConfig = {
  vendorDid: process.env.VENDOR_DID,
  vendorServer: process.env.VENDOR_SERVER,
  checkPayment: async (connectionId) => {
    const subscription = await stripe.subscriptions.retrieve(connectionId);
    return ok({
      connectionId,
      paymentCurrent: subscription.status === 'active',
      epoch: { start: Date.now(), end: Date.now() + 86400000 },
      shares: []
    });
  },
  storeVendorShare: async (artifact) => {
    await db.vendorShares.insert(artifact);
    return ok(undefined);
  },
  retrieveVendorShare: async (connectionId) => {
    const artifact = await db.vendorShares.findOne({ connectionId });
    return artifact ? ok(artifact) : err('CONNECTION_NOT_FOUND');
  }
};

Zero breaking changes. The quick start API signature is identical to production. You add configuration, not rewrite code.

Purchasing Full Control

Full Control is available in three tiers: Basic, Pro, and Enterprise. All tiers include a 3-month free trial with full feature access.

Programmatic Purchase

AI agents and automation tools can purchase Full Control programmatically using the ACI Purchase Endpoint.

POST https://private.me/api/purchase
Content-Type: application/json
Idempotency-Key: <uuid-v4>
X-Client-Type: ai-agent  // Optional: increases rate limit to 60 req/min

{
  "product": "full-control",
  "tier": "basic",  // "basic" | "middle" | "enterprise"
  "connection_id": "my-production-connection"
}

Idempotency Keys

Prevent duplicate purchases by including a unique Idempotency-Key header (UUID v4). Replaying the same key within 24 hours returns the original result without creating a duplicate subscription.

Rate Limits

AI Agents: 60 requests/minute (include X-Client-Type: ai-agent header)
Human Clients: 10 requests/minute

When rate limited (HTTP 429), respect the Retry-After header value (seconds).

Error Handling

All errors follow RFC 7807 Problem Details format with field-level validation feedback.

// Example error response
{
  "type": "https://private.me/errors/validation-error",
  "title": "Validation Failed",
  "detail": "Invalid tier value",
  "fields": {
    "tier": "Must be one of: basic, middle, enterprise"
  }
}

Deployment Timeline

Automated deployment begins immediately after payment confirmation. Share 2 delivery completes within <5 minutes (288× faster than 24-hour manual processes).

xGhost: Ephemeral Execution

The algorithm exists in memory for less than 5 milliseconds per execution, not the entire session. Reconstructed fresh from shares before each call, executed immediately, then purged from memory. This makes code theft 10,000× harder than traditional session-persistent implementations.

How It Works

Traditional Full Control implementations cache the reconstructed algorithm for the entire session. This creates a vulnerability: an attacker with memory access can extract the complete algorithm source code in ~30 seconds with zero hardware cost.

xGhost eliminates this attack vector by ensuring the algorithm never persists in memory. Instead, it follows a strict execution pattern:

1. Fetch Share 2 — Retrieved from payment-gated endpoint, cached in memory only (24h default epoch)
2. Reconstruct Algorithm — XorIDA combines Share 1 + Share 2 into executable code (sub-millisecond)
3. Execute Immediately — Call completes while algorithm exists in memory (sub-millisecond)
4. Purge — Function references zeroed, Share 2 bytes overwritten, memory freed

Total algorithm lifetime: milliseconds per execution. The algorithm does not exist between calls. Share 2 is cached to avoid network latency, but the reconstructed algorithm is never cached.

Performance Impact

For comparison, session-persistent implementations have zero reconstruction overhead after the first call. xGhost adds minimal per-call overhead in exchange for eliminating the code theft vulnerability. For most workloads, this is an acceptable trade-off.

Security Guarantees

Attack Complexity: Extracting algorithm source code requires capturing memory during the brief millisecond execution window. With session-persistent code, an attacker simply dumps memory at any time. With xGhost, they must:

• Trigger a function call to force reconstruction
• Capture memory dump within millisecond window before purge
• Parse reconstructed algorithm from memory dump
• Repeat for multiple calls to verify extracted code is complete

Estimated attack cost: $10,000+ in specialized hardware + days of engineering work. Compare to session-persistent code: $0 + 30 seconds with console.log(sourceCode).

Traditional licensing is broken

Every existing software licensing mechanism fails when customers control the infrastructure.

License Keys

Keys are strings. Strings can be copied, shared, or posted online. A single license can activate unlimited instances. Detection requires the vendor to monitor usage, which customers refuse for proprietary systems.

Online Activation

Air-gapped systems cannot phone home. Government classified networks, industrial OT/ICS, healthcare HIPAA zones, financial trading floors all prohibit external connectivity. "Must connect to activate" eliminates your largest enterprise buyers.

Hardware Dongles

Physical tokens can be reverse-engineered. Virtualized environments cannot attach USB devices. Cloud infrastructure has no concept of hardware peripherals. Dongle emulators exist for every major vendor.

Code Obfuscation

Obfuscation delays reverse-engineering but cannot prevent it. Given enough time and motivation, every obfuscated binary can be decompiled. High-value algorithms (trading, defense, pharma) justify unlimited reverse-engineering budgets.

Cryptographic billing enforcement

XorIDA threshold sharing makes payment control a mathematical property, not a policy.

How It Works

Your proprietary algorithm is split into two shares using XorIDA 2-of-2 threshold sharing. Each share is information-theoretically useless alone. An attacker with infinite computing power, analyzing Share 1 forever, learns nothing about your algorithm.

// Vendor splits algorithm into 2 shares
const { share1, share2 } = await split(algorithm, { k: 2, n: 2 });

// Share 1: Deployed to customer infrastructure
//   - Customer has full control
//   - Can be inspected, audited, reverse-engineered
//   - Reveals NOTHING about the algorithm

// Share 2: Held on vendor billing server
//   - Delivered only when payment is current
//   - 24-hour default epoch (must re-fetch daily)
//   - HMAC-authenticated, replay-protected

// Both shares required for execution
const result = reconstruct([share1, share2]).execute(input);

Billing Flow

Initial Provisioning

Automated deployment begins immediately after payment confirmation. Share 2 delivery completes within <5 minutes (288× faster than 24-hour manual processes). No manual intervention required.

Ongoing Verification

Every 24 hours (configurable), the customer's infrastructure requests Share 2 from your billing server. Your server performs a single check: "Is payment current?"

• Payment current: Share 2 delivered. Algorithm executes normally.
• Payment lapsed: Share 2 denied. Reconstruction fails. Code stops working.

Payment Failure Handling (Dunning)

When a customer's payment fails (expired card, insufficient funds), Full Control implements an escalating warning system:

• Day 0 (Payment Failure): Email notification sent. Share 2 delivery continues (24-hour grace period).
• Day 1 (Overdue): Second notification. Share 2 delivery continues (final warning).
• Day 4 (Suspended): Share 2 delivery stops. Algorithm execution fails. Service suspended until payment updated.

Customer updates payment via Stripe Customer Portal. Once payment succeeds, Share 2 delivery resumes automatically within 5 minutes. No vendor intervention required.

No usage tracking. No telemetry. No surveillance. The vendor never sees inputs, outputs, or execution patterns. The only data transmitted is the payment status check and Share 2 delivery.

Air-Gap Deployment

For air-gapped environments (SIPRNET, industrial OT, classified systems), Share 2 can be delivered via one-way data diode, sneakernet, or manual import. The epoch period extends to match operational security requirements (weekly, monthly).

The unique value proposition

XorIDA offers capabilities that no other cryptographic approach can match: information-theoretic security, zero key management, and true vendor control without data visibility.

Information-Theoretic Security vs. Computational Security

Most encryption relies on computational security — the assumption that attackers don't have enough computing power to break it. AES-256, RSA, and elliptic curve cryptography are all computationally secure. They're safe today, but may become vulnerable if quantum computers advance or if mathematical breakthroughs occur.

XorIDA provides information-theoretic security — a mathematical guarantee that Share 1 alone reveals nothing about the original algorithm, regardless of computing power. An attacker with infinite resources, analyzing Share 1 for eternity, learns zero bits of information. This is the same security level as a one-time pad.

No Key Management Overhead

Traditional encryption requires key generation, distribution, rotation, and revocation. Keys must be stored securely. If a key is compromised, all encrypted data is at risk. Organizations spend millions on key management infrastructure (HSMs, KMS, key escrow).

XorIDA threshold sharing has no keys. The shares themselves are the only secret material. There's nothing to rotate, nothing to revoke, nothing to store in an HSM. When payment lapses, Share 2 is simply not delivered. When payment resumes, Share 2 is delivered again. No key ceremony, no emergency key rotation, no key compromise recovery procedure.

Vendor Control Without Data Visibility

SaaS gives vendors control (they can turn off service for non-payment) but requires sending customer data to vendor infrastructure. On-premises deployment gives customers data sovereignty but removes vendor billing control.

Full Control via XorIDA is the only approach that provides both:

• Vendor control: Algorithm stops working if payment lapses (mathematically enforced).
• Data sovereignty: Customer data never leaves their infrastructure. Vendor never sees inputs, outputs, or execution patterns.

No other technology offers this combination. Homomorphic encryption allows computation on encrypted data but is 1,000-10,000x slower. Trusted execution environments (TEEs) like SGX provide secure enclaves but have been compromised multiple times via side-channel attacks.

Speed Comparison

XorIDA is not just more secure — it's faster than alternatives.

XorIDA is 500-2,000x faster than Shamir's Secret Sharing for the same security level. It matches AES-256-GCM speed for small payloads and is only 2x slower for large payloads — while providing information-theoretic security instead of computational security.

Quantum-Proof Guarantee

Post-quantum cryptography (PQC) algorithms like ML-KEM and ML-DSA are believed to resist quantum attacks, but they rely on mathematical assumptions (lattice hardness, LWE). If those assumptions are broken, PQC fails.

XorIDA's security is not based on assumptions. It's provably secure against all adversaries, including quantum computers, because Share 1 alone contains zero information about the original algorithm. No amount of quantum computing power changes this mathematical fact.

Technology landscape

How XorIDA compares to other approaches for secure on-premises deployment with vendor control.

Why Not Shamir's?

Shamir's Secret Sharing provides the same information-theoretic security as XorIDA and supports the same K-of-N threshold schemes. So why choose XorIDA?

Performance. Shamir's operates over finite fields GF(2^8) or GF(2^256) and requires polynomial interpolation (Lagrange basis) for reconstruction. XorIDA operates over GF(2) (binary field) and uses simple XOR for reconstruction. For a 1MB algorithm:

• XorIDA: ~1.2ms reconstruction time.
• Shamir's: ~2,100ms reconstruction time (1,750x slower).

For real-time billing enforcement, this matters. XorIDA allows sub-millisecond algorithm reconstruction, enabling execution latency that matches native code. Shamir's multi-second overhead is unacceptable for production workloads.

Why Not AES-256?

AES-256 is fast and widely supported. Why not encrypt the algorithm with AES and gate key delivery based on payment?

Key compromise. If the AES key is ever leaked (insider threat, memory dump, side-channel attack), the vendor loses all control. The customer can decrypt the algorithm forever. With XorIDA, there is no key to leak. Share 1 is useless alone, and Share 2 is ephemeral (expires every 24 hours by default).

Quantum vulnerability. AES-256 is vulnerable to Grover's algorithm, which reduces effective key strength to 128 bits. XorIDA is provably quantum-proof — no quantum algorithm can extract information from Share 1 alone.

Why Not Homomorphic Encryption?

Homomorphic encryption (HE) allows computation on encrypted data without decryption. Why not encrypt the algorithm with HE and let customers execute it without ever seeing plaintext?

Performance catastrophe. Even the fastest HE schemes (BFV, CKKS) are 1,000-10,000x slower than native execution. A 100ms algorithm call becomes 100+ seconds. This is unacceptable for production use.

No vendor control. Once the customer has the HE-encrypted algorithm, they own it forever. There's no billing enforcement mechanism. The vendor cannot revoke access.

Why Not TEEs (Trusted Execution Environments)?

Intel SGX, ARM TrustZone, and AMD SEV provide hardware-isolated secure enclaves. Why not run the algorithm inside a TEE and prevent customers from extracting it?

Side-channel attacks. SGX has been compromised via Spectre, Foreshadow, Plundervault, LVI, and other side-channel attacks. TEEs provide isolation against software attacks, but not against hardware-level attackers.

Vendor lock-in. TEEs are hardware-specific. Intel SGX doesn't work on AMD processors. ARM TrustZone doesn't work on Intel. Customers are locked into specific CPU vendors.

No data sovereignty. The algorithm executes inside the enclave, but the customer's data must enter the enclave to be processed. The vendor can potentially access this data (or at least metadata about execution patterns).

Why Not MPC (Multi-Party Computation)?

MPC allows multiple parties to jointly compute a function without revealing their inputs. Why not use MPC to execute the algorithm across vendor and customer infrastructure?

Complexity. MPC requires continuous network communication during computation. Every operation requires multiple rounds of interaction between parties. This adds 10-100x latency overhead.

No unilateral vendor control. MPC requires cooperation from both parties. If the customer refuses to participate, the vendor cannot enforce payment. With XorIDA, the vendor unilaterally controls Share 2 delivery.

Markets that demand sovereignty

Full Control targets industries where data cannot leave customer infrastructure, but vendors still require payment enforcement.

Industry Compliance Mapping

System design

Full Control combines XorIDA threshold sharing with payment-gated Share 2 delivery and ephemeral execution to create mathematically enforced billing.

Core Components

1. XorIDA Threshold Sharing

Splits the proprietary algorithm into K-of-N shares. Default 2-of-2 for maximum security. Each share is information-theoretically useless alone. Reconstruction requires both shares and HMAC verification.

2. Payment-Gated Share 2 Delivery

Manages the connection between customer DID and vendor billing server. Tracks payment status. Generates connection IDs via SHA-256(didA + didB + scope). Gates Share 2 delivery based on billing state.

3. Ephemeral Execution (xGhost)

Algorithm exists in memory for milliseconds per execution, not the entire session. Reconstructed fresh from shares before each call, executed immediately, then purged. Share 2 cached in memory only (24h default epoch). No persistent algorithm instance. 10,000× harder to steal than session-persistent code.

// 1. Vendor splits algorithm (offline, one-time)
const { share1, share2 } = await crypto.split(algorithm, { k: 2, n: 2 });

// 2. Share 1 → npm package, deployed to customer
// 3. Share 2 → Payment-gated API endpoint

// 4. Customer runtime executes a call
async executeCall(service: string, params: unknown): Promise<unknown> {
  // Fetch Share 2 (cached in memory for 24h, NOT the algorithm)
  const share2 = await this.fetchShare2WithEpochCheck();

  // Reconstruct algorithm (ephemeral - exists ONLY for this call)
  const core = reconstructXorIDA([share1, share2], indices, n, k);

  try {
    // Execute immediately (sub-millisecond)
    return await core.executeCall(service, params);
  } finally {
    // ALWAYS purge - ephemeral algorithm lifetime
    this.purge(core); // Zero out function refs + Share 2 bytes
  }
}

Epoch Rotation

Share 2 includes an expiry timestamp. Default 24 hours. After expiry, the customer runtime must re-fetch Share 2. This enforces continuous payment verification without requiring real-time connectivity.

For air-gapped systems, epoch period extends to match operational requirements (weekly, monthly). Share 2 is delivered via physical media, one-way data diode, or manual import.

Share 2 Metadata & Economic Continuity

Share 2 is not just algorithm data — it includes metadata that enforces subscription tier limits, prevents economic state reset attacks, and ensures continuous payment verification across customer identity changes.

Metadata Structure

Each Share 2 payload includes:

interface Share2Payload {
  // XorIDA share data (algorithm fragment)
  share: Buffer;

  // Issue timestamp - when this share was generated
  issueEpoch: number;

  // Persistent economic identity (survives DID rotation)
  deploymentID: string; // Format: DEP-YYYYMM-XXXXXXXXXX

  // Subscription snapshot at issue time
  tier: 'free' | 'pro' | 'vip';
  subscriptionStatus: 'active' | 'canceled' | 'past_due';

  // Expiry (24h default, configurable for air-gap)
  expiresAt: number;
}

IssueEpoch: Tier Change Invalidation

The issueEpoch field records when Share 2 was generated. This prevents customers from using outdated shares after subscription tier changes.

Problem without IssueEpoch: Customer upgrades Free → Pro mid-month, gets higher quota. Customer then downgrades Pro → Free. Old Share 2 (issued during Pro tier) would still work, granting Pro-level access without Pro payment.

Solution: Vendor server checks if tier changed after Share 2 was issued. If yes, Share 2 is stale and denied.

function validateShare2Metadata(
  share2: Share2Payload,
  account: AccountRecord
): ValidationResult {
  // If account tier changed after share was issued → DENY
  if (account.tier_changed_at > share2.issueEpoch) {
    return {
      allowed: false,
      reason: 'SHARE2_STALE: Tier changed. Request fresh share.'
    };
  }

  // Check subscription status matches current state
  if (share2.subscriptionStatus !== account.subscription_status) {
    return {
      allowed: false,
      reason: 'SUBSCRIPTION_STATUS_MISMATCH: Re-fetch required'
    };
  }

  return { allowed: true };
}

DeploymentID: Economic State Reset Prevention

A DeploymentID is a persistent economic identifier that survives customer identity rotation (DID regeneration, account switching, machine changes).

Attack without DeploymentID: Customer exhausts 100K free tier operations → Generates new DID → Gets fresh 100K operations → Repeat infinitely. Vendor loses all revenue to DID rotation.

Solution: DeploymentID anchors usage tracking to a persistent identity. Even if customer rotates DIDs 100 times, all usage counts against the same DeploymentID.

DEP-YYYYMM-XXXXXXXXXX
    │   │      │
    │   │      └─ 10 hex digits (collision resistance)
    │   └──────── Month (usage resets monthly)
    └──────────── Prefix

Economic Continuity Guarantee: Usage tracked against DeploymentID, not DID. Customer cannot reset quota by identity rotation. Vendor billing integrity preserved.

Tier Change Scenarios

Scenario 1: Free → Pro Upgrade

1. Customer on Free tier (100K/month limit) exhausts quota at 100K operations
2. Customer upgrades to Pro tier (unlimited operations)
3. Vendor server detects tier change: account.tier_changed_at = NOW()
4. Old Share 2 (issued during Free tier) now stale → Denied on next fetch attempt
5. Customer runtime re-fetches Share 2 → New share issued with tier: 'pro', fresh issueEpoch
6. Operations resume with Pro-tier unlimited quota

Scenario 2: Pro → Free Downgrade

1. Customer on Pro tier using unlimited operations
2. Customer cancels Pro subscription → Downgrades to Free tier
3. Vendor server updates: account.tier = 'free', account.tier_changed_at = NOW()
4. Old Share 2 (issued during Pro tier) denied → Staleness check fails
5. Customer runtime re-fetches Share 2 → New share issued with tier: 'free', 100K/month limit
6. Operations limited to Free tier quota (prevents Pro-level access without payment)

Scenario 3: Payment Failure Recovery

1. Customer payment fails → subscriptionStatus = 'past_due'
2. Share 2 fetch denied (payment not current)
3. Algorithm execution fails (cannot reconstruct without Share 2)
4. Customer updates payment via Stripe portal → subscriptionStatus = 'active'
5. Share 2 fetch resumes automatically → Service restored within minutes

Subscription Status Validation

Every Share 2 fetch checks subscription status in real-time. Share 2 is delivered only if:

• Payment current: subscriptionStatus === 'active'
• Tier valid: Tier has not changed since last Share 2 issue (checked via issueEpoch)
• Email verified: account.emailVerified === true (platform requirement)
• Not flagged: No abuse detection flags or manual review pending

Denial reasons: If any check fails, Share 2 is denied with specific error code:

// Possible denial reasons
'SUBSCRIPTION_CANCELED'     // Subscription terminated
'SUBSCRIPTION_PAST_DUE'     // Payment failed, grace period
'SHARE2_STALE'              // Tier changed after issue
'EMAIL_NOT_VERIFIED'        // Email verification required
'TIER_QUOTA_EXCEEDED'       // Free tier limit reached
'MANUAL_REVIEW_PENDING'     // Abuse detection flagged account

Offline Detection & Failsafe Mode

If a deployment goes offline (stops fetching Share 2) for 45+ days, it enters failsafe mode: 100 operations/day limit until re-connection.

Progressive warnings: Days 25, 35, 43, 45 → Email notifications escalate before enforcement.

Emergency override: 3-layer backup system (email + hotline + web form) provides 6-digit override codes for critical deployments blocked by connectivity issues.

Abuse Detection Integration

Share 2 metadata includes deploymentID for risk scoring. Multi-signal abuse detection tracks:

• Email verification age (new accounts = higher risk)
• DeploymentID creation date (rapid rotation = suspicious)
• IP intelligence (datacenter IPs, VPNs flagged)
• Device fingerprinting (session consistency checks)
• Velocity anomalies (100K operations in 1 hour = automated abuse)

Risk score 70+: Account enters manual review queue. Share 2 delivery continues during review (innocent until proven guilty), but flagged for investigation.

Deployment models

Full Control supports four deployment tiers: Basic (HTTPS), Software Hardened (obfuscated), Air-Gap (manual), and Plus (MPC-verified).

Basic Tier: Docker + HTTPS

The vendor packages Share 1 into a Docker image. Customer pulls and deploys the image on their infrastructure. At runtime, the container fetches Share 2 via HTTPS from the vendor billing server.

FROM node:20-alpine

# Copy Share 1 into image
COPY share1.bin /opt/vendor/share1.bin

# Install Full Control client
RUN npm install @private.me/full-control

# Runtime fetches Share 2 automatically
CMD ["node", "runtime.js"]

Software Hardened Tier: Obfuscation + Anti-Debugging

For customers who want additional protection against reverse engineering beyond the mathematical guarantees of XorIDA, the Software Hardened tier adds multiple layers of code obfuscation and runtime protection.

Pre-Split Obfuscation: Before XorIDA splitting, the algorithm undergoes control flow obfuscation (control flow flattening, opaque predicates), string encryption, and dead code injection. This increases the difficulty of static analysis by ~10-20x.

Runtime Anti-Debugging: The reconstructed algorithm includes anti-debugging checks (debugger detection, timing checks, integrity verification) that trigger if an attacker attempts to step through execution. Failed checks cause immediate termination without revealing algorithm logic.

Memory Dump Detection: Runtime monitors for process memory inspection (ptrace, ReadProcessMemory, /proc/mem access). If detected, the algorithm purges itself from memory and terminates.

Performance Impact

Obfuscation adds overhead to both splitting and reconstruction:

• Splitting: +200-500ms (one-time vendor operation).
• Reconstruction: +5-15ms (per algorithm execution).
• Execution: +2-8% slowdown (due to control flow obfuscation).

For most workloads, this overhead is negligible. The obfuscation cost is amortized across thousands or millions of executions.

Air-Gap Tier: Manual Import

For classified or air-gapped networks, Share 2 is delivered via physical media (USB drive, CD-ROM) or one-way data diode. The customer's security team imports Share 2 manually into the runtime environment.

Epoch period is extended to match operational security requirements (weekly, monthly). Share 2 includes cryptographic attestation (HMAC, timestamp, nonce) to prevent tampering or replay.

Plus Tier: MPC-Verified Execution

Enterprises requiring audit trails use 3-party multiparty computation. The vendor, customer, and a neutral third party (auditor, compliance officer) each hold a share. Reconstruction requires 2-of-3 agreement.

Every execution is logged to an immutable audit trail via xfuse. The auditor can verify that Share 2 was delivered only when payment was current, and that the algorithm executed without tampering.

Integration guide

Integrate Full Control into your existing codebase in under 30 minutes.

Vendor Setup

npm install @private.me/full-control

import { createFullControl } from '@private.me/full-control';

const protected = await createFullControl({
  algorithm: yourProprietaryFunction,
  customerDID: 'did:key:z6Mk...',
  scope: 'product-name-v1',
  epochDuration: 86400 // 24 hours in seconds
});

// Writes share1.bin to disk, stores share2.bin in billing DB
await protected.split();

COPY share1.bin /opt/vendor/share1.bin
ENV VENDOR_ENDPOINT=https://billing.vendor.example/api

import { createBillingServer } from '@private.me/full-control/server';

const server = createBillingServer({
  port: 3000,
  checkPayment: async (connectionId) => {
    // Your billing logic here
    const account = await db.accounts.findOne({ connectionId });
    return account?.paymentCurrent === true;
  }
});

server.listen();

Customer Setup

docker pull vendor.example/product:latest

docker run -d \
  -e VENDOR_ENDPOINT=https://billing.vendor.example/api \
  -e CUSTOMER_DID=did:key:z6Mk... \
  -v /data:/opt/vendor/data \
  vendor.example/product:latest

// Inside container runtime
import { FullControlClient } from '@private.me/full-control';

const client = new FullControlClient({
  shareStorePath: '/opt/vendor/share1.bin',
  vendorEndpoint: process.env.VENDOR_ENDPOINT
});

// Automatically fetches Share 2, reconstructs, executes
const result = await client.execute(inputData);

ACI Interface

Security model

Full Control provides information-theoretic confidentiality and cryptographic billing enforcement.

Threat Model

Attacker Goals

• Reverse-engineer the algorithm from Share 1 alone
• Execute the algorithm without payment by bypassing Share 2 delivery
• Replay old Share 2 to extend usage beyond payment period
• Clone the deployment to multiple instances with one license

Security Guarantees

• Information-theoretic confidentiality: Share 1 alone reveals zero information about the algorithm, even against quantum computers or unlimited time.
• Cryptographic binding: Share 2 is HMAC-signed with connection ID (derived from customer DID + vendor DID + scope). Replay or forgery is detectable.
• Epoch enforcement: Share 2 includes expiry timestamp. After expiry, reconstruction fails. Customer must re-fetch with current payment.
• Tamper detection: HMAC verification happens before reconstruction. Modified shares are rejected.

Attack Scenarios

1. Reverse-Engineering Share 1

Attack: Customer extracts Share 1 from Docker image and attempts to reverse-engineer the algorithm.

Defense: XorIDA 2-of-2 split. Share 1 is uniformly random gibberish. An attacker with infinite computing power learns nothing. This is information-theoretic security, not computational.

2. Replaying Old Share 2

Attack: Customer caches Share 2 from a paid period and attempts to reuse it after payment lapses.

Defense: Share 2 includes HMAC-signed timestamp and nonce. Expired Share 2 fails reconstruction. Nonce prevents replay across epochs.

3. Cloning to Multiple Instances

Attack: Customer deploys Share 1 to multiple VMs and shares one Share 2 across all instances.

Defense: Connection ID is derived from SHA-256(customerDID + vendorDID + scope). Each deployment must register a unique DID. Vendor billing server tracks active connections per DID.

4. Man-in-the-Middle on Share 2 Delivery

Attack: Intercept Share 2 during HTTPS delivery and inject malicious data.

Defense: HTTPS with certificate pinning. HMAC verification before reconstruction. Tampered Share 2 fails HMAC check and is rejected.

Compliance Certifications

Full Control is designed to support FedRAMP Moderate, HIPAA, SOC 2 Type II, and ISO 27001 deployments. The vendor does not process customer data, simplifying compliance boundaries.

Benchmarks

Full Control adds minimal overhead. Share delivery dominates latency, reconstruction is sub-millisecond.

Share Delivery Latency

xBind Secure vs Basic Performance

Full Control Basic tier delivers Share 2 via HTTPS with 24-hour caching (minimal overhead). xBind Secure tier adds frequent billing verification via the xBind gateway. The performance difference matters for specific compliance scenarios.

When to Use xBind Secure vs Basic

Use xBind Secure when:

• Need frequent billing verification (compliance requirement)
• Need fast revocation (≤5min)
• Enterprise customers with strict audit requirements
• Can tolerate ~7ms overhead per call

Use Basic tier when:

• Performance is critical (<1ms required)
• 24h billing verification is acceptable
• ≤24h revocation window is acceptable
• General use cases

Cache Hit Rate Expectations

• >95% cache hit rate with normal usage patterns
• Gateway cache: 5min TTL
• Typical customer: ~100 calls/day → ~99% cache hits

Performance Characteristics

• Gateway overhead: ~6ms (1ms Basic → 7ms xBind Secure)
• Network latency: Minimal (localhost:3002, no external calls on cache hit)
• Server-side decryption: <1ms (AES-256-CBC)

Reconstruction Overhead

Software Hardened overhead: Control flow obfuscation, string encryption, and anti-debugging checks add 5-15ms to reconstruction time. For most workloads, this is negligible. Execution performance remains 98-92% of native speed (2-8% slowdown due to opaque predicates and control flow flattening).

Epoch Rotation

Default 24-hour epoch. Share 2 re-fetch happens in background every 24 hours. If fetch fails (payment lapsed, network down), the algorithm stops working after current Share 2 expires.

Total overhead: Initial share fetch occurs once per epoch, with negligible per-call reconstruction cost. After the first execution within an epoch, overhead is effectively zero until the next epoch rotation.

What Full Control cannot do

Every technology has boundaries. Here are ours.

1. Real-Time Billing Enforcement

Full Control uses epoch-based enforcement (default 24 hours). If a customer's payment lapses, their algorithm continues working until the current Share 2 expires. For real-time enforcement (immediate cutoff), the epoch must be shortened to minutes, increasing network overhead.

2. Protection Against Determined Offline Reverse-Engineering

While Share 1 alone is information-theoretically useless, a sophisticated attacker with access to both shares (e.g., by compromising the vendor billing server) can reconstruct the algorithm. Full Control protects against customers reverse-engineering from Share 1 alone, not against attackers who steal Share 2.

3. Usage-Based Metering (Basic Tier Only)

Full Control Basic tier enforces "is payment current?" (binary check), not "how many times did the algorithm execute?" For zero-surveillance usage metering, upgrade to xBind Secure tier, which logs Share 2 requests (interaction counts) without seeing algorithm inputs or outputs. See FAQ "Does xBind Secure support usage metering?" for details.

4. Post-Execution Content Inspection

The vendor cannot see what the algorithm computed or what data it processed. If compliance requires vendor visibility into outputs (e.g., for content moderation or audit), Full Control is insufficient. Use enterprise compliance modules (xfuse, deaddrop) instead.

5. Instant Revocation

Revoking access requires waiting for the current epoch to expire. A customer with a valid Share 2 can continue using the algorithm until expiry, even if payment is revoked mid-epoch. For instant revocation, use MPC Plus tier with real-time consensus.

When NOT to Use Full Control

• Consumer software: Overhead and complexity are overkill for $10/month SaaS apps.
• Open-source projects: If the algorithm is already public, splitting it provides no benefit.
• Usage-based billing (Basic tier): Per-API-call pricing requires xBind Secure tier for zero-surveillance metering.
• Real-time revocation: If you need instant cutoff (not epoch-based), use online activation instead.
• Compliance visibility: If regulators require vendor access to outputs, Full Control hides too much.

xBind Secure FAQs

Common questions about xBind Secure tier for Full Control deployments.

// Example email notification (triggered server-side)
Subject: Full Control Usage Alert - 80% Spend Threshold

You've used 8,000 of your 10,000 monthly interactions.
Current pace: ~400 calls/day
Projected overage: $2.40 (if trend continues)

[View Usage Dashboard] [Upgrade Plan]

{
  "connection_id": "sub_xyz789",
  "billing_cycle": "2026-05-01T00:00:00Z",
  "total_interactions": 57000,
  "usage": {
    "xbind": 45000,
    "xformat": 12000
  },
  "threshold_reached": true,
  "threshold_pct": 0.80
}

Custom K-of-N Thresholds

Default is 2-of-2 (maximum security, zero fault tolerance). For enterprise deployments requiring redundancy, use 2-of-3 or 3-of-5. Share 1 deploys to customer, Shares 2 and 3 held by vendor (primary + backup servers).

const protected = await createFullControl({
  algorithm: yourFunction,
  customerDID: 'did:key:z6Mk...',
  threshold: { k: 2, n: 3 }
});

// Share 1 → customer infrastructure
// Share 2 → vendor primary billing server
// Share 3 → vendor backup billing server

// Customer needs ANY 2 of the 3 shares to execute
// If primary server is down, backup Share 3 works

Multi-Tenant Isolation

Each customer gets a unique connectionId = SHA-256(customerDID + vendorDID + scope). Scope can encode product version, feature tier, or deployment environment (e.g., trading-algo-v2-prod). This allows per-customer, per-product billing control.

Audit Trails via Xfuse

Enterprises requiring compliance records can integrate xfuse orchestration. Every Share 2 delivery is logged to an immutable audit trail with timestamp, customer DID, payment status, and HMAC signature.

import { createBillingServer } from '@private.me/full-control/server';
import { XfuseLogger } from '@private.me/xfuse';

const logger = new XfuseLogger({ auditStorePath: '/var/log/billing-audit' });

const server = createBillingServer({
  checkPayment: async (connectionId) => {
    const paymentOK = await db.checkPayment(connectionId);

    // Log every payment check to immutable audit trail
    await logger.log({
      event: 'share2_request',
      connectionId,
      paymentStatus: paymentOK,
      timestamp: new Date().toISOString()
    });

    return paymentOK;
  }
});

// Audit log is HMAC-chained, tamper-evident
// Compliance officers can verify delivery history

Hybrid Cloud + On-Prem

Some enterprises want cloud convenience with on-prem security for sensitive data. Deploy the algorithm on-prem (Full Control) but use cloud infrastructure for non-sensitive auxiliary services (logging, monitoring, dashboards).

Share 1 + proprietary algorithm run on-prem. Share 2 fetched from cloud billing server. Customer data never leaves on-prem network, but vendor retains cloud-based billing control.

Custom Epoch Durations

Default 24 hours. Configurable from 1 hour (near-real-time enforcement) to 1 month (air-gapped deployments). Shorter epochs increase network overhead. Longer epochs delay payment enforcement.

const protected = await createFullControl({
  algorithm: yourFunction,
  customerDID: 'did:key:z6Mk...',
  epochDuration: 3600 // 1 hour (near-real-time)
});

// OR for air-gapped:
const airGapProtected = await createFullControl({
  algorithm: yourFunction,
  customerDID: 'did:key:z6Mk...',
  epochDuration: 2592000 // 30 days (monthly manual import)
});

xBind Secure: Per-Call Billing Verification

For maximum security, use xBind Secure mode. Every algorithm call verifies billing authorization in real-time via the xBind protocol. Vendor retains complete control over execution without storing Share 2 locally.

import { FullControlRuntime } from '@private.me/langchain';

// xBind Secure mode - per-call billing verification
const runtime = await FullControlRuntime.create({
  mode: 'xbind-secure',
  customerDID: 'did:private:customer123'
});

// Every call checks billing (cached 5min)
const result = await runtime.executeCall('sendMessage', {
  to: 'recipient',
  payload: { text: 'Hello' }
});

import { FullControlRuntime } from '@private.me/langchain';

// Software Hardened - obfuscated algorithm
const runtime = await FullControlRuntime.create({
  mode: 'software-hardened'
});

// Algorithm is obfuscated, harder to reverse engineer
const result = await runtime.executeCall('sendMessage', params);

import { FullControlRuntime } from '@private.me/langchain';

// xBind Secure + Software Hardened
const runtime = await FullControlRuntime.create({
  mode: 'xbind-secure-hardened',
  customerDID: 'did:private:customer123'
});

// Per-call billing verification + obfuscated algorithm
const result = await runtime.executeCall('sendMessage', params);

const runtime = await FullControlRuntime.create({
  mode: 'xbind-secure',
  customerDID: 'did:private:customer123',
  gatewayURL: 'https://private.me/gateway', // optional override
  registryURL: 'https://private.me/registry', // optional override
  timeout: 10000 // 10s timeout for authorization requests
});

Security guarantees: xBind Secure eliminates local Share 2 caching. The vendor gateway authorizes each call in real-time. Payment lapses immediately revoke execution. No epoch delays, no stale cache, no offline execution.

Performance trade-off: Each call adds minimal network latency for xBind authorization. For latency-sensitive workloads, use standard epoch-based mode. For maximum control, use xBind Secure.

Store Front + Vault Store Architecture

How Full Control protects proprietary algorithms using 2-share threshold cryptography with usage-based payment gating. Technical deep-dive for vendors implementing IP protection.

Architecture Overview

Full Control (patent US 11,972,000) splits proprietary algorithms into two cryptographic shares using XorIDA threshold cryptography. Neither share is useful alone—both are required to reconstruct the complete algorithm. This enables on-premises deployment with cryptographic billing enforcement.

Two-Component Distribution

Usage-Based Payment Model

CRITICAL DESIGN PRINCIPLE: Full Control uses usage-based metering, NOT feature-gating. All paid customers can access the Vault Store (Share 2) within their usage quota. Free tier users also get access within limits.

Runtime Flow (Customer Perspective)

// 1. Customer installs vendor package (includes Share 1)
// npm install @vendor/trading-algorithm

// 2. Initialize algorithm runtime
const algo = await TradingAlgorithm.create(config);

// 3. First execution triggers Vault Store fetch:
//    - Detects missing Share 2
//    - POST /api/vault-store/trading-algorithm-v2
//    - Auth: Customer DID signature (Ed25519)
//    - Vendor verifies: payment current? quota available?
//    - Response: { share2, cryptoBundle, expiresAt }

// 4. XorIDA reconstruction: Share 1 + Share 2 = complete algorithm
// 5. Ephemeral execution (xGhost pattern): algorithm exists <5ms
// 6. Result returned, algorithm purged from memory

const prediction = await algo.predict(marketData);
// Algorithm reconstructed, executed, purged—all within single call

4-Layer Security Defense (Vendor Implementation)

Revenue Protection Mechanisms

Why Full Control Matters (Vendor Business Impact)

Deployment Procedures (Vendor Guide)

import { splitForDeployment } from '@private.me/full-control';

// Your proprietary algorithm source code
const algorithmSource = `
  export function predictPrice(marketData) {
    // Trade secret logic here
    return computePrediction(marketData);
  }
`;

// Split into 2 shares using XorIDA
const { share1, share2, metadata } = await splitForDeployment({
  source: algorithmSource,
  exportedFunctions: ['predictPrice'],
  vendorDID: 'did:key:z6MkVendor...',
  scope: 'trading-v2'
});

// share1 → npm package (public)
// share2 → Vault Store server (payment-gated)

// Create npm package with Share 1 + wrapper code
await writeFile('share1.dat', share1);
await writeFile('package.json', {
  name: '@vendor/trading-algorithm',
  version: '2.0.0',
  main: 'index.js',
  files: ['share1.dat', 'index.js', 'types.d.ts']
});

// Publish to npm (Share 1 is safe to distribute publicly)
// npm publish --access public

// Store Share 2 on your billing server (encrypted at rest)
await storeShare2Encrypted({
  share2Data: share2,
  scope: 'trading-v2',
  encryptionKey: process.env.VAULT_MASTER_KEY, // AES-256-GCM
  storagePath: '/opt/vault-store/trading-v2-share2.bin'
});

// CRITICAL: NEVER serve Share 2 via static nginx location
// ALWAYS serve via payment-gated API endpoint

import { createVaultStoreServer } from '@private.me/full-control/server';

const server = createVaultStoreServer({
  // Verify payment status before delivering Share 2
  checkPayment: async (customerDID, scope) => {
    const subscription = await stripe.subscriptions.retrieve(customerDID);
    return subscription.status === 'active';
  },

  // Verify usage quota (Free: 120K, Pro: unlimited)
  checkQuota: async (deploymentID, scope) => {
    const usage = await db.getMonthlyUsage(deploymentID, scope);
    const tier = await db.getTier(deploymentID);
    if (tier === 'pro') return true; // unlimited
    return usage < 120000; // Free tier hard cap
  }
});

server.listen(3000);

Technical Implementation Details