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.

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

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.

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 orchestrates three building blocks: crypto (XorIDA), xpass (billing), and xghost (ephemeral execution).

Building Block Composition

1. Crypto: 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. Xpass: Billing Enforcement

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. Xghost: Ephemeral Execution

Ensures shares are never persisted to disk after use. Reconstructed algorithm executes in memory only. Shares are purged after each execution or epoch expiry. Heartbeat mechanism enforces epoch rotation.

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

// 2. Share 1 → Docker image, deployed to customer
// 3. Share 2 → Vendor billing server

// 4. Customer runtime requests Share 2
const connectionId = SHA256(customerDID + vendorDID + scope);
const paymentOK = await xpass.checkPayment(connectionId);

if (paymentOK) {
  // 5. Share 2 delivered via HTTPS
  const share2Encrypted = await vendor.fetchShare2(connectionId);

  // 6. Xghost reconstructs algorithm in memory
  const algorithm = await xghost.reconstruct([share1, share2Encrypted]);

  // 7. Execute and purge
  const result = await algorithm.execute(input);
  await xghost.purge(); // Algorithm erased from memory
} else {
  throw new PaymentRequiredError('Payment lapsed');
}

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.

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);

API Surface

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

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: ~50ms initial share fetch + ~75µs reconstruction per algorithm call. 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

Full Control enforces "is payment current?" (binary check), not "how many times did the algorithm execute?" Usage-based billing (per-API-call, per-transaction) requires telemetry, which violates the zero-surveillance design. If you need usage metering, Full Control is not the right solution.

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: Per-API-call or per-transaction pricing requires telemetry.
• 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.

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)
});