xPass: XorIDA-Based Billing Enforcement

The Problem

M2M billing enforcement is unsolved. Every existing approach trades latency for control, or gives up control entirely.

Machine-to-machine agent communication creates a fundamental billing challenge: how do you ensure that every connection between agents is paid for, without introducing latency that kills the performance advantage of direct communication?

Gateway Relay

Route all traffic through a billing server. The server verifies payment status before forwarding. Problem: Every message takes a detour through the gateway, adding 10-50ms of latency. At scale, the gateway becomes a single point of failure and a bottleneck.

HMAC Tickets

Server issues time-limited HMAC tokens. Agents present tokens to prove they have paid. Problem: A forked SDK can simply skip token verification. The enforcement is behavioral — it relies on the SDK checking the token.

Key Oracle

Server holds the encryption key and distributes it only to paid agents. Problem: Once the key is distributed, nothing prevents the agent from caching it indefinitely or sharing it with unpaid agents.

API Metering

Count API calls or bytes transferred and bill based on usage. Problem: Usage-based billing requires centralized metering infrastructure, adds latency to every call, and has no cryptographic binding between the metering event and the actual data exchange. Agents can communicate out-of-band once they have each other's identity.

Competitive Analysis

Existing billing platforms were designed for human-to-server interactions. None embeds billing enforcement inside the cryptographic layer.

The Gap

Every existing billing platform assumes trust between the billing server and the consuming application. The server says "this customer has paid" and the application trusts that signal. In M2M agent ecosystems, applications are autonomous software — they can be forked, modified, or run in environments where the billing check is stripped out. You need enforcement that survives hostile environments.

xPass closes this gap by making the billing relationship a cryptographic precondition for communication. The connection secret is split via XorIDA. Without both shares — which requires an active billing relationship — there is no secret. Without the secret, there is no encryption. Without encryption, there is no communication.

Market Context

The M2M communication market is projected to reach $27B by 2028. As AI agents proliferate, the need for enforceable billing between autonomous systems grows exponentially. Traditional SaaS billing (Stripe, Zuora, Chargebee) was designed for human-to-server interactions where the human has a payment method attached to their account. M2M billing requires a fundamentally different model where enforcement is embedded in the communication protocol itself.

xPass is purpose-built for this market. It does not replace Stripe for human billing — it solves the problem that Stripe cannot: ensuring that autonomous agents pay for every communication channel they use, without relying on the agent's cooperation or honest behavior.

The Solution

xPass embeds enforcement inside encryption. The connection secret is XorIDA-split. Both shares are required to decrypt. Reconstruction IS verification.

Instead of verifying payment and then encrypting, xPass makes the encryption itself dependent on the billing relationship. The server generates a connection secret and immediately splits it via XorIDA into 2-of-2 shares. Each agent receives one share. To encrypt or decrypt a message, both shares must be combined to reconstruct the connection secret.

A single share is information-theoretically indistinguishable from random noise. This is not a computational claim — it is a mathematical proof. No amount of computing power, including quantum computers of any size, can extract any information from a single share.

How It Works

Billable Unit

The fundamental billing primitive is a connection: the tuple (DID_A, DID_B, scope). Each unique connection is one billable unit. The connection is symmetric — A-to-B is the same connection as B-to-A. Scope isolates different communication contexts between the same pair of agents (e.g., "xlink" for messaging, "xcompute" for MPC sessions).

Why Connection-Based, Not Usage-Based

Usage-based billing (per-message, per-byte, per-API-call) requires centralized metering infrastructure that adds latency and complexity. It also creates perverse incentives: agents are penalized for communicating more, which conflicts with the goal of enabling rich M2M interaction. Connection-based billing is simple, predictable, and adds zero per-message overhead.

The connection model mirrors how human subscriptions work: you pay for a phone line, not per minute. The connection exists, and within it, communication is unlimited. This model is particularly well-suited for M2M agent ecosystems where communication patterns are bursty and unpredictable.

// Deterministic, symmetric: A→B = B→A
ConnectionId = SHA-256(sort(didA, didB) + "|" + scope)

// Example
createConnectionId(
  "did:key:z6MkAgent1",
  "did:key:z6MkAgent2",
  "xlink"
) // → "a3f8...7b2c" (64-char hex)

Architecture

Two tiers: xPass Basic for P2P with 24h epoch rotation, and xPass+ for server-mediated MPC with near-zero bypass window.

xPass Basic (2-of-2, P2P)

Server generates a 256-bit connection secret, splits it via XorIDA into 2-of-2 shares, and distributes one share to each agent. After distribution, the server discards the secret. Shares rotate every 24 hours (configurable epoch).

Bypass window: 24 hours. If both agents collude to cache the reconstructed secret, they can communicate without contacting the server for one epoch.

xPass+ (3-Party MPC)

Server holds Share 3 and participates in an xCompute 3-party MPC session to generate a session key. Session keys are valid for 5-60 minutes (configurable). If the server does not participate, no session key is generated.

Bypass window: Near-zero. The server must participate in every session.

Epoch Rotation

Connection secrets rotate on a configurable epoch (default 24 hours). At epoch boundary, the server generates a new secret, splits it, and distributes new shares. Old shares are invalidated. Agents must contact the billing server at least once per epoch to receive their new share — this is the enforcement checkpoint.

Rotation is designed to be seamless: agents request their new-epoch share proactively before the current epoch expires. A 15-minute overlap window ensures no messages are lost during transition. Both the old and new epoch shares are valid during the overlap period.

Share Structure

Each share is wrapped in an xFormat binary envelope with the IDA5 magic header (0x49444135). The envelope includes the share index, threshold parameters (n, k), a UUID linking all shares from the same split, an epoch number, the ConnectionId, and an HMAC-SHA256 integrity tag. The envelope is Base45-encoded for transport.

// xFormat binary envelope for xPass shares
[IDA5 magic: 4 bytes]        // 0x49444135
[product type: 2 bytes]      // 0x0042 (xPass)
[share index: 1 byte]        // 1-based index
[n: 1 byte]                  // total shares
[k: 1 byte]                  // threshold
[uuid: 16 bytes]             // links shares from same split
[epoch: 4 bytes]             // epoch number (uint32 BE)
[connectionId: 32 bytes]     // SHA-256 of sorted DIDs + scope
[hmac: 32 bytes]             // HMAC-SHA256 integrity tag
[payload: variable]          // XorIDA share data

Connection Lifecycle

// 1. Creation: billing relationship established
PENDING → createConnection(didA, didB, scope) → ACTIVE

// 2. Active: shares distributed, communication flows
ACTIVE → epochRotate() → ACTIVE  // new shares every 24h

// 3. Suspension: payment lapsed
ACTIVE → suspend() → SUSPENDED  // shares invalidated

// 4. Grace period: 72h to resolve billing
SUSPENDED → grace() → GRACE  // limited communication

// 5. Revocation: permanent disconnection
GRACE → revoke() → REVOKED  // all shares destroyed

// 6. Reactivation: new payment
SUSPENDED | REVOKED → reactivate() → ACTIVE

Benchmarks

xPass Basic adds ~30µs per message. xPass+ adds ~50-200ms per session start, then zero overhead per message within the session. Connection check completes in under 1ms.

Scaling Characteristics

xPass Basic has O(1) per-message cost: the XorIDA reconstruction and AES encryption are constant-time for the 32-byte connection secret, regardless of how many connections an agent maintains. The connection check is a hash table lookup — O(1) amortized.

Server-side, share issuance scales linearly with the number of active connections. A single billing server can manage ~100K active connections with sub-second epoch rotation. For larger deployments, connections are sharded by ConnectionId prefix across multiple billing nodes.

Latency Budget Breakdown

For a typical xPass Basic message send, the total billing enforcement overhead is approximately 30 microseconds, broken down as follows:

ACI Surface

Five core operations plus two pipeline helpers. Every function returns Result<T, XpassError> and never throws.

Error Handling

All functions return Result<T, XpassError> and never throw. Crypto operations fail closed: if HMAC verification fails, the share is rejected and no secret is reconstructed. Billing status failures return structured error codes (BILLING_REQUIRED, CONNECTION_SUSPENDED, EPOCH_EXPIRED, SHARE_INVALID) that consuming code can match against for appropriate error handling.

Developer Experience

Progress callbacks, structured error codes, and billing enforcement patterns designed for production M2M systems.

Progress Callbacks

All long-running operations support progress callbacks. This enables responsive UI updates during connection establishment, secret splitting, and reconstruction operations.

const result = await createConnection(didA, didB, scope, {
  onProgress: (event) => {
    switch (event.stage) {
      case 'generating_connection_id':
        console.log('Computing SHA-256 of sorted DIDs...');
        break;
      case 'creating_secret':
        console.log('Generating 256-bit connection secret...');
        break;
      case 'splitting':
        console.log(`XorIDA split: ${event.progress}%`);
        break;
      case 'distributing':
        console.log(`Distributing share ${event.shareIndex}/2`);
        break;
    }
  }
});

// Reconstruction with progress tracking
const secretResult = await reconstructSecret(share1, share2, {
  onProgress: (event) => {
    if (event.stage === 'hmac_verify') {
      console.log(`Verifying HMAC for share ${event.shareIndex}...`);
    } else if (event.stage === 'reconstructing') {
      console.log(`XorIDA reconstruction: ${event.progress}%`);
    }
  }
});

Error Code Catalog

12 error codes across 4 categories provide precise diagnostics for every failure mode. Each error includes a machine-readable code, human-readable message, and remediation guidance.

// Category 1: Connection ID Errors
CONNECTION_ID_COLLISION    // Regenerate with different nonce
CONNECTION_NOT_FOUND       // Verify connection exists before operations
CONNECTION_ALREADY_EXISTS  // Use existing connection or create with new scope

// Category 2: Secret Generation Errors
SECRET_GENERATION_FAILED   // crypto.getRandomValues() unavailable or failed
SPLIT_FAILED              // XorIDA split operation failed (invalid params)
INSUFFICIENT_SHARES       // Provide at least K shares for reconstruction

// Category 3: Epoch Management Errors
EPOCH_EXPIRED             // Request new session token with fresh epoch
EPOCH_MISMATCH            // Shares from different epochs cannot reconstruct
EPOCH_NOT_READY           // Wait for next epoch boundary (rare timing issue)

// Category 4: Cryptographic Errors
HMAC_VERIFICATION_FAILED  // Share tampered or corrupted; reject immediately
SHARE_INVALID             // Share format invalid (missing fields, bad encoding)
RECONSTRUCTION_FAILED     // XorIDA reconstruction failed (share mismatch)

Billing Gate Pattern

The recommended pattern for production systems: check billing status before expensive operations, provide clear feedback on billing issues, and handle grace periods appropriately.

async function sendSecureMessage(
  didA: string,
  didB: string,
  scope: string,
  plaintext: Uint8Array
): Promise<Result<void, XpassError>> {
  // Step 1: Derive connection ID
  const connectionId = computeConnectionId(didA, didB, scope);

  // Step 2: Check billing status BEFORE crypto operations
  const billingCheck = await checkBilling(connectionId);
  if (!billingCheck.ok) {
    return err(billingCheck.error);
  }

  const status = billingCheck.value;

  // Step 3: Handle billing states with user-facing messages
  if (status.status === 'suspended') {
    return err({
      code: 'CONNECTION_SUSPENDED',
      message: 'Connection suspended due to payment failure',
      remediation: `Update payment method to reactivate. ${status.daysUntilRevocation} days remaining in grace period.`
    });
  }

  if (status.status === 'revoked') {
    return err({
      code: 'CONNECTION_REVOKED',
      message: 'Connection permanently revoked',
      remediation: 'Create a new connection with valid payment method'
    });
  }

  if (status.status === 'grace') {
    // Allow communication but warn user
    console.warn(
      `Connection in grace period. ${status.daysUntilRevocation} days until revocation.`
    );
  }

  // Step 4: Retrieve shares (these are pre-distributed during connection creation)
  const share1 = await getShareForAgent(connectionId, didA);
  const share2 = await getShareForAgent(connectionId, didB);

  if (!share1.ok || !share2.ok) {
    return err({
      code: 'SHARE_RETRIEVAL_FAILED',
      message: 'Unable to retrieve connection shares',
      remediation: 'Verify connection exists and shares were distributed'
    });
  }

  // Step 5: Reconstruct secret with progress tracking
  const secretResult = await reconstructSecret(
    share1.value,
    share2.value,
    {
      onProgress: (event) => {
        if (event.stage === 'hmac_verify' && event.shareIndex === 1) {
          console.log('Verifying share 1 HMAC...');
        }
      }
    }
  );

  if (!secretResult.ok) {
    // Detailed error handling based on code
    switch (secretResult.error.code) {
      case 'EPOCH_EXPIRED':
        return err({
          ...secretResult.error,
          remediation: 'Request new session token. Epoch rotates every 24h.'
        });
      case 'HMAC_VERIFICATION_FAILED':
        return err({
          ...secretResult.error,
          remediation: 'Share corrupted or tampered. Request fresh shares from server.'
        });
      case 'EPOCH_MISMATCH':
        return err({
          ...secretResult.error,
          remediation: 'Shares from different epochs. Both agents must use current epoch.'
        });
      default:
        return err(secretResult.error);
    }
  }

  // Step 6: Encrypt with reconstructed secret
  const ciphertext = await encryptWithConnectionSecret(
    secretResult.value,
    plaintext
  );

  if (!ciphertext.ok) {
    return err(ciphertext.error);
  }

  // Step 7: Send ciphertext to recipient
  await transmit(didB, ciphertext.value);

  return ok(void 0);
}

Error Recovery Strategies

Each error category has a specific recovery path. Production systems should implement these patterns to minimize user friction while maintaining billing integrity.

// CONNECTION_ID_COLLISION (rare, ~1 in 2^256)
// Recovery: Add random nonce to scope, regenerate connection ID
if (error.code === 'CONNECTION_ID_COLLISION') {
  const nonce = crypto.getRandomValues(new Uint8Array(16));
  const newScope = `${scope}-${hex(nonce)}`;
  return await createConnection(didA, didB, newScope);
}

// EPOCH_EXPIRED (24h boundary crossed)
// Recovery: Request fresh session token from billing server
if (error.code === 'EPOCH_EXPIRED') {
  const newSession = await requestSessionToken(connectionId);
  const freshShares = await getSharesForEpoch(newSession.epoch);
  return await reconstructSecret(freshShares[0], freshShares[1]);
}

// HMAC_VERIFICATION_FAILED (tampered or corrupted share)
// Recovery: Request fresh shares, do NOT retry with same shares
if (error.code === 'HMAC_VERIFICATION_FAILED') {
  logSecurityEvent('share_integrity_failure', { connectionId });
  const freshShares = await requestFreshShares(connectionId);
  return await reconstructSecret(freshShares[0], freshShares[1]);
}

// CONNECTION_SUSPENDED (grace period, payment failure)
// Recovery: Prompt user to update payment, allow 72h grace period
if (error.code === 'CONNECTION_SUSPENDED') {
  const daysRemaining = error.metadata.daysUntilRevocation;
  await notifyUser({
    severity: 'warning',
    title: 'Payment Required',
    message: `Connection will be revoked in ${daysRemaining} days`,
    action: { label: 'Update Payment', href: '/billing' }
  });
  // Optionally allow send during grace period (business decision)
  if (daysRemaining > 0) {
    return await proceedWithWarning();
  }
}

// CONNECTION_REVOKED (permanent, payment lapsed)
// Recovery: Create new connection, no bypass possible
if (error.code === 'CONNECTION_REVOKED') {
  await notifyUser({
    severity: 'error',
    title: 'Connection Closed',
    message: 'Payment lapsed. Create new connection to resume communication.',
    action: { label: 'New Connection', href: '/connections/new' }
  });
  return err(error); // No recovery, must create new connection
}

TypeScript Integration

Full TypeScript support with discriminated unions for error types. IDE autocomplete guides developers through every error code and recovery path.

// XpassError is a discriminated union of all 12 error codes
type XpassError =
  | { code: 'CONNECTION_ID_COLLISION';    message: string; remediation: string }
  | { code: 'EPOCH_EXPIRED';             message: string; remediation: string; metadata: { epochNumber: number } }
  | { code: 'HMAC_VERIFICATION_FAILED';  message: string; remediation: string; metadata: { shareIndex: number } }
  | { code: 'CONNECTION_SUSPENDED';      message: string; remediation: string; metadata: { daysUntilRevocation: number } }
  | /* ... 8 more error types */;

// Exhaustive pattern matching enforced by TypeScript
function handleError(error: XpassError): UserMessage {
  switch (error.code) {
    case 'EPOCH_EXPIRED':
      return {
        severity: 'info',
        title: 'Session Expired',
        message: `Epoch ${error.metadata.epochNumber} expired. Requesting new session...`
      };
    case 'CONNECTION_SUSPENDED':
      return {
        severity: 'warning',
        title: 'Payment Required',
        message: `${error.metadata.daysUntilRevocation} days until connection revoked`
      };
    // TypeScript enforces that all 12 codes are handled
    default:
      const _exhaustive: never = error;
      return _exhaustive;
  }
}

Use Cases

xPass serves any scenario where two machines need to communicate and the operator needs to ensure every connection is paid for.

Regulatory Alignment

xPass addresses billing security, audit trail, and financial resilience requirements across multiple regulatory frameworks.

Audit Trail Architecture

Every xPass operation produces an HMAC-chained audit entry. The chain is append-only: each entry includes the HMAC of the previous entry, making it tamper-evident. Auditors can verify the entire billing history for a connection without accessing the connection secrets themselves.

The audit trail records: connection creation, share distribution, epoch rotation, billing status changes, suspension, grace period entry/exit, revocation, and reactivation. Each entry includes timestamps, DID identifiers, epoch numbers, and HMAC integrity tags.

// Each audit entry is HMAC-chained
{
  "eventType": "EPOCH_ROTATE",
  "connectionId": "a3f8...7b2c",
  "epoch": 42,
  "timestamp": "2026-04-05T00:00:00Z",
  "didA": "did:key:z6MkAgent1",
  "didB": "did:key:z6MkAgent2",
  "scope": "xlink",
  "prevHash": "b4e2...9f1a",  // chain link
  "hmac": "c7d3...0e8b"        // integrity tag
}

Compliance Reporting

xPass generates structured compliance reports suitable for SOX auditors, PCI assessors, and financial regulators. Reports include: total connections by status (active, suspended, revoked), epoch rotation history, billing dispute timeline, grace period utilization, and connection-level activity summaries. All reports are generated from the HMAC-chained audit trail, ensuring tamper-evidence.

Cross-ACI Patterns

xPass integrates with the PRIVATE.ME platform as the billing enforcement layer for M2M communication.

xPass + xLink: Billing-Gated M2M

xLink provides the agent-to-agent communication channel (Ed25519 + X25519, hybrid PQ KEM). xPass layers underneath as the billing enforcement. When Agent A sends a message to Agent B via xLink, the xPass layer transparently verifies that the connection is paid and encrypts using the connection secret. Application code calls xLink as before — xPass enforcement is invisible.

import { Agent } from '@private.me/xlink';
import { withBilling } from '@private.me/xpass';

// Wrap the agent with billing enforcement
const agent = withBilling(
  await Agent.fromSeed(seed),
  { billingServer: 'https://billing.private.me' }
);

// Send as normal — xPass enforcement is transparent
const result = await agent.send(recipientDid, payload);
// If connection is not paid: err('BILLING_REQUIRED')
// If connection is active: encrypts + sends transparently

xPass + xCompute: MPC-Verified Billing

xPass+ uses xCompute for 3-party MPC session key generation. The billing server holds Share 3 and participates in the MPC protocol. This eliminates the 24h bypass window of xPass Basic — the server must be present for every session. xCompute ensures that the session key is generated correctly without any party learning the others' shares.

xPass + xGate: Rate-Limited Billing Checks

xGate provides rate limiting for billing check endpoints. Without rate limiting, a malicious agent could flood the billing server with checkBilling() calls to probe connection states or cause denial of service. xGate limits billing checks to 100 per minute per DID, with exponential backoff on repeated failures.

xPass + xProve: Verifiable Billing

xProve chains billing events into a tamper-evident audit trail. Each epoch rotation, share distribution, and connection state change generates an HMAC-SHA256 integrity tag. xProve links these tags into a verifiable chain that auditors can validate without accessing the underlying billing data or connection secrets.

xPass + xStore: Split-Stored Billing State

For high-availability billing infrastructure, xStore can split-store the billing server's state across multiple backends. If the billing server fails, a replacement can reconstruct its state from K-of-N stored shares without exposing the complete billing database to any single storage provider.

xPass + Xauditlog: Tamper-Evident Billing History

Xauditlog provides enterprise-grade append-only audit logging with HMAC-chained entries. xPass integrates with Xauditlog to create a complete, tamper-evident history of every billing event: connection creation, epoch rotation, suspension, grace period, revocation, and reactivation. The audit log is independently verifiable by third-party auditors.

Integration Architecture

// Full billing enforcement with PRIVATE.ME platform

// 1. xLink: establish agent-to-agent channel
const agent = await Agent.fromSeed(seed);

// 2. xPass: verify billing before communication
const billing = await xpass.checkBilling(connectionId);
if (!billing.ok || billing.value.status !== 'active') {
  throw new Error('Billing required');
}

// 3. xGate: rate-limit billing check
const allowed = await xgate.checkRate(agent.did, 'billing');

// 4. xPass: reconstruct connection secret
const secret = await xpass.reconstructSecret(share1, share2);

// 5. Encrypt and send via xLink
const encrypted = await xpass.encryptWithConnectionSecret(
  secret.value, payload
);
await agent.send(recipientDid, encrypted.value);

// 6. xProve: log to audit trail
await xprove.logEvent({
  type: 'MESSAGE_SENT',
  connectionId,
  epoch: billing.value.currentEpoch,
});

Billing Flow Diagram

Security Analysis

Enforcement is information-theoretic, not computational. A single share reveals exactly zero bits about the connection secret.

Enforcement Model Comparison

Threat Model

Collusion Analysis

If both agents collude, they can reconstruct the secret and bypass billing for one epoch (24h). This is the fundamental trade-off of xPass Basic. Four economic defenses make collusion uneconomical:

1. DPoP binding: Shares are bound to device attestations via Demonstration of Proof-of-Possession. Transferring a share to a different device requires re-attestation through the billing server.

2. Recipient revenue sharing: Recipients earn a fraction of the connection fee for maintaining their share. Reporting a colluding peer is more profitable than participating in collusion.

3. DID registration deposits: DID registration requires a refundable deposit. Proven collusion forfeits the deposit. The deposit exceeds the cost of one year of connection fees.

4. Enterprise hub pricing: Enterprise connections are priced per-seat, not per-connection. Collusion between two agents does not reduce the enterprise's total bill, removing the financial incentive entirely.

Server Compromise

After share distribution, the server does not retain the connection secret. A compromise after distribution does not expose past messages. The server stores only connection metadata (DIDs, scope, billing status, epoch numbers) — never connection secrets or shares.

A compromised server could issue fraudulent shares or withhold shares from legitimate agents. Both attacks are detectable: agents can verify share consistency via HMAC tags, and share withholding triggers grace period notifications that alert the affected agent. Multi-server redundancy (distributing the billing role across multiple servers) eliminates single-point compromise risk.

Quantum Resistance

XorIDA splitting is unconditionally secure: its security does not depend on computational hardness assumptions. A quantum computer of any size cannot extract information from a single share because the information literally does not exist in the share. This is not post-quantum cryptography (which relies on problems believed to be quantum-hard) — it is information-theoretic security, which is provably unbreakable regardless of computational advances.

The AES-256-GCM layer used for message encryption within a connection IS computationally secure (and thus theoretically quantum-vulnerable for the 256-bit key). However, the connection secret is ephemeral (24h epoch) and split across two parties. An attacker would need to compromise both shares within a single epoch AND break AES-256 — the epoch rotation limits the window of exposure to 24 hours, making quantum attacks impractical even in a theoretical post-quantum scenario.

Ship Proofs, Not Source

xPass generates cryptographic proofs of correct execution without exposing proprietary algorithms. Verify integrity using zero-knowledge proofs — no source code required.

Use Cases

Honest Limitations

Six known limitations documented transparently. Credibility requires honesty about constraints.

Limitation Details

On initial connection requirement: The initial connection handshake requires both agents to be reachable by the billing server for share distribution. This is fundamentally required — the server must deliver one share to each agent. However, the distribution is asynchronous: the server queues each agent's share and delivers it on next contact. Both agents do not need to be online simultaneously.

On epoch granularity: xPass bills per-connection, not per-message. This means a connection that sends 1 message per month costs the same as one that sends 1 million. For most M2M use cases, this is a feature, not a limitation: flat-rate pricing enables agents to communicate freely without cost anxiety. For use cases requiring metered billing, xGate rate counters can layer on top of xPass connections to provide usage metrics without replacing the fundamental enforcement mechanism.

On the 24h bypass window: This is the most commonly asked-about limitation. The short answer: if both agents are colluding, they already have access to the plaintext — the encryption is protecting against external observers, not the communicating parties themselves. The economic defenses (DPoP, revenue sharing, deposits, hub pricing) make sustained collusion more expensive than paying for the connection.

Enterprise CLI

xpass-cli provides a standalone HTTP server for enterprise deployments. Port 3600. Docker-ready. Air-gapped capable.

Endpoints

// Connection management
POST   /connections              // Create new connection
GET    /connections              // List connections for a DID
GET    /connections/:id          // Get connection details
DELETE /connections/:id          // Revoke connection

// Billing operations
GET    /connections/:id/status   // Check billing status
POST   /connections/:id/rotate   // Force epoch rotation
POST   /connections/:id/suspend  // Suspend connection
POST   /connections/:id/activate // Reactivate connection

// Share operations
POST   /shares/reconstruct       // Reconstruct from two shares
POST   /encrypt                  // Encrypt with connection secret
POST   /decrypt                  // Decrypt with two shares

// Health
GET    /health                   // Server status + connection count

Docker Deployment

services:
  xpass:
    image: private.me/xpass-cli:latest
    ports:
      - "3600:3600"
    environment:
      - XPASS_PORT=3600
      - XPASS_EPOCH_HOURS=24
      - XPASS_GRACE_HOURS=72
    volumes:
      - xpass-data:/data
    restart: always

Configuration

xpass-cli is configured via environment variables. All settings have sensible defaults for development. Production deployments should explicitly set epoch duration, grace period, and rate limiting parameters.

Air-Gapped Operation

xpass-cli operates in air-gapped environments with no external dependencies. All cryptographic operations (XorIDA splitting, HMAC-SHA256, AES-256-GCM) use the built-in Web Crypto API. No external key management service required. Connection metadata stored locally in JSONL append-only logs.

Why XorIDA

XorIDA provides the mathematical foundation that makes xPass possible. No other splitting algorithm offers the same combination of speed, security, and simplicity for billing enforcement.

Verifiable Billing Integrity

Every operation in this ACI produces a verifiable audit trail via xProve. HMAC-chained integrity proofs let auditors confirm that connection secrets were split, distributed, and rotated correctly — without accessing the secrets themselves.

Integration Example

Full lifecycle: create connection, distribute shares, encrypt, decrypt, rotate, and revoke.

import {
  createConnection,
  verifyConnection,
  revokeConnection,
  listConnections,
  checkBilling,
  reconstructSecret,
  encryptWithConnectionSecret,
  decryptWithShares,
} from '@private.me/xpass';

// 1. Create a billing connection
const conn = await createConnection(
  'did:key:z6MkAgentA',
  'did:key:z6MkAgentB',
  'xlink'
);
if (!conn.ok) throw new Error(conn.error);

// 2. Distribute shares (server sends one to each agent)
const { share1, share2, connectionId } = conn.value;

// 3. Agent A encrypts a message
const secret = await reconstructSecret(share1, share2);
if (!secret.ok) throw new Error(secret.error);
const encrypted = await encryptWithConnectionSecret(
  secret.value,
  new TextEncoder().encode('Hello, Agent B')
);

// 4. Agent B decrypts (full pipeline)
const decrypted = await decryptWithShares(
  share1, share2, encrypted.value
);

// 5. Check billing status
const status = await checkBilling(connectionId);
console.log(status.value);
// { status: 'active', epochRemaining: '23h 14m', ... }

// 6. List all connections for an agent
const connections = await listConnections(
  'did:key:z6MkAgentA'
);

// 7. Revoke when billing ends
await revokeConnection(connectionId, 'subscription_cancelled');

Ready to deploy xPass?

Talk to Sol, our AI platform engineer, or book a live demo with our team.