xFuse: Threshold Identity Fusion

The Problem

Traditional MFA is broken. Each factor independently has partial value. A stolen fingerprint, a compromised device token, a phished TOTP code — each gives the attacker partial identity information.

Password + TOTP: Both are shared symmetric secrets. The password is stored as a hash on the server — breach the server and you get every hash. TOTP seeds are stored on both the server and the user's device. A phished 6-digit code is valid for 30 seconds, and attackers operate in milliseconds. The "second factor" is not an independent channel — it is a second shared secret with the same single point of failure.

Biometric + device: Two factors, but each is independently valuable to an attacker. A stolen fingerprint template can be replayed. A cloned device token can be presented. Combining them adds difficulty, not impossibility. An attacker with one factor has reduced the problem, not eliminated it. Traditional MFA treats factors as additive layers — each one individually leaks partial information about the identity.

Risk-based scoring: Behavioral analytics assign a probability that the user is who they claim to be. The score is heuristic, probabilistic, and gameable. Sophisticated attackers can mimic typing patterns, spoof location data, and replay device fingerprints. A risk score is a bet, not a proof.

MFA fatigue attacks: Push-based MFA sends repeated approval requests until the user taps "Approve" out of frustration or habit. The Uber breach (September 2022), the Cisco breach (May 2022), and the Microsoft breach (March 2022) all exploited MFA fatigue. The attacker already had one factor — the push notification gave them the second.

The Core Failure

The Solution

XorIDA threshold convergence. K-1 factors = zero information. Not "hard to crack" — mathematically impossible. The threshold IS the assurance level.

xFuse replaces additive MFA scoring with threshold identity fusion. An identity seed is generated, padded, HMAC-tagged, and XorIDA-split into N shares. Each share is bound to an independent verification channel: biometric enclave, device TPM, push auth, hardware token, credential verifier, location attestation, or network proof. Any K of N channels must converge within a time-bounded window to reconstruct the identity seed.

The critical difference: K-1 shares contain zero information about the identity seed. Not "reduced information." Not "computationally hard to extract." Mathematically zero. This is an information-theoretic guarantee over GF(2) — it holds regardless of the attacker's computational power, including quantum computers.

Three Key Properties

• Information-theoretic zero-knowledge below threshold: An attacker who compromises K-1 channels learns nothing. Not one bit. The remaining shares are uniformly random and independent of the identity seed.
• Any K-of-N combination works: Lose your phone? Use biometric + hardware token + credential. Traveling without your YubiKey? Use biometric + device + push auth. Fault tolerance is built into the threshold.
• Re-split on every mutation invalidates old shares: Enroll a new channel, revoke a compromised channel, or upgrade the threshold — the identity seed is re-split with fresh randomness. All previous shares become useless.

Convergence Pipeline

The Face ID Analogy

Face ID uses 30,000 infrared dots that only mean something when they converge. Take away one dot — the other 29,999 still identify you. Take away half — they probably still do. XorIDA threshold sharing is fundamentally different: take away ONE share below threshold, and the remaining K-1 shares contain ZERO information. Not partial. Not degraded. Zero. Face ID degrades gracefully. xFuse provides an absolute boundary: above threshold = full identity. Below threshold = nothing.

Identity Architecture: Where xFuse Fits

xFuse is Layer 3 of the PRIVATE.ME identity stack. It sits on top of xLink (Layer 1: transport-layer authenticated channels) and xID (Layer 2: ephemeral unlinkable identities). Each layer solves a different problem. Together, they provide the full spectrum from low-friction anonymous communication to high-assurance regulated identity.

The Three-Layer Stack

The PRIVATE.ME platform provides three distinct identity layers. Each layer is independent — you can use xLink without xID, or xID without xFuse. But when combined, they compose into a unified identity architecture that spans from zero-knowledge anonymous messaging (IAL0) to government-grade biometric fusion (IAL3).

Layer 1: xLink (Authenticated Channels)

What it does: xLink establishes authenticated, encrypted agent-to-agent channels using Ed25519 + X25519 key pairs. Every agent has a DID (did:key:z6Mk...). Messages are signed and encrypted. The recipient knows the message came from a specific DID, but the DID itself reveals no real-world identity.

Assurance level: IAL0 (zero identity). xLink proves "This message came from the same agent I spoke to yesterday" — but it doesn't tell you who that agent is. Perfect for anonymous messaging, whistleblower communication, or any use case where pseudonymity is required.

When to use xLink alone: Low-stakes communication where you don't need to know the sender's real-world identity. Developer APIs, IoT device-to-device messaging, encrypted chat between pseudonymous parties. See the xLink white paper for full details.

Layer 2: xID (Ephemeral Unlinkable Identity)

What it does: xID generates per-verifier ephemeral DIDs from a XorIDA-split master seed. Every verifier (bank, hospital, government agency) sees a different DID. The DIDs are cryptographically unlinkable — no one can correlate your identity across contexts. The master seed is never at rest — it's reconstructed only during DID derivation, then purged immediately.

Assurance level: IAL1 (self-asserted identity). xID proves "I am the same person across sessions with this verifier" without revealing who you are to other verifiers. Fills the eIDAS 2.0 ARF unlinkability requirement. Exposure window: ~50µs.

When to use xID alone: Privacy-preserving authentication where you need persistent identity with a single verifier but unlinkability across verifiers. Online services that don't require regulated KYC. See the xID white paper for convergence mechanics, biometric binding, and epoch rotation.

Layer 3: xFuse (High-Assurance Threshold Fusion)

What it does: xFuse converges K-of-N independent verification channels (biometric enclave, device TPM, push auth, hardware token, credential verifier, location attestation, network proof) into a single identity seed. Below threshold: mathematically zero information. At threshold: full identity reconstruction with HMAC integrity verification. The convergence pipeline enforces consent, time-bounded windows, channel diversity, and HMAC verification before releasing the identity seed.

Assurance level: IAL1/2/3 (configurable). xFuse is the only layer that can reach IAL2 (remote proofing with government-issued credential) and IAL3 (in-person proofing with biometric binding). It's designed for regulated environments: banking (KYC/AML), healthcare (HIPAA), government (FedRAMP), legal (privilege).

When to use xFuse alone: High-assurance identity without the need for transport-layer anonymity or cross-context unlinkability. Enterprise SSO with threshold MFA. Government access control. Financial transaction signing. Any use case where regulatory compliance requires verified identity.

When to Combine All Three Layers

The full stack — xLink + xID + xFuse — is used when you need high-assurance verified identity with privacy-preserving unlinkability and encrypted transport. Example: a healthcare provider messaging platform where:

• xLink provides the encrypted messaging transport layer (no plaintext, no server-side keys).
• xID ensures each patient's identity is unlinkable across different departments (cardiology sees DID A, oncology sees DID B, but no one can correlate).
• xFuse enforces biometric + device + credential convergence for high-assurance IAL2/3 authentication before accessing medical records.

// Layer 1: xLink channel
import { Agent } from '@private.me/xlink';
const agent = await Agent.create();

// Layer 2: xID ephemeral DID for this verifier
import { EphemeralID } from '@private.me/xid';
const ephemeralDID = await EphemeralID.deriveForVerifier(
  verifier: 'did:web:hospital.example.com',
  masterSeed: /* XorIDA-reconstructed seed */
);

// Layer 3: xFuse threshold identity fusion (IAL2)
import { IdentityFusion } from '@private.me/xfuse';
const result = await IdentityFusion.converge({
  threshold: 2,
  totalShares: 3,
  channels: [
    { type: 'biometric', enclave: 'platform' },
    { type: 'device', tpm: true },
    { type: 'credential', issuer: 'did:web:gov.example' }
  ],
  assuranceLevel: 'IAL2',
  convergenceWindow: 60000 // 60 seconds
});

if (result.ok) {
  // Identity seed reconstructed at IAL2 assurance
  // Use ephemeralDID for unlinkable session, agent for transport
  await agent.send({
    to: 'did:web:hospital.example.com',
    from: ephemeralDID,
    payload: encryptedMedicalRecord,
    assurance: result.value.assuranceLevel // IAL2
  });

  // Purge identity seed immediately after use
  result.value.seed.purge();
}

Decision Table: Which Layer Do You Need?

Why Separate Layers?

Flexibility: Not every use case needs high-assurance identity. Forcing IAL2/3 verification for a developer API would kill adoption. Separating the layers lets you choose the right level of friction for your use case.

Privacy: xID's unlinkability only works if identity verification (xFuse) is a separate, opt-in layer. If every xID derivation required biometric fusion, the system would leak timing metadata that could correlate identities.

Composability: Each layer is a standalone ACI with its own API surface. You can swap xLink for a different transport (HTTP, WebSocket, native sockets) without changing xID or xFuse. You can use xFuse for high-assurance SSO without adopting the full PRIVATE.ME stack.

Regulatory alignment: IAL0/1/2/3 map directly to NIST 800-63-3 assurance levels. Regulators understand this spectrum. A single monolithic "identity system" would struggle to fit both anonymous messaging (IAL0) and biometric government ID (IAL3) in one API.

Cross-References

• xLink White Paper: Transport-layer authenticated channels, Ed25519 signing, X25519 encryption, hybrid PQ-KEM, multi-transport routing.
• xID White Paper: Ephemeral identity, per-verifier DID derivation, biometric binding, convergence mechanics, epoch rotation, eIDAS 2.0 ARF compliance.

Architecture

CREATE / CONVERGE / UPGRADE / REVOKE — four operations, one identity seed. Channel binding, time-bounded windows, diversity enforcement, and HMAC integrity at every step.

CREATE Pipeline

CONVERGE Pipeline

Assurance Levels

Three assurance levels mapping directly to eIDAS Levels of Assurance. The threshold IS the assurance level — not a heuristic, not a probability, but a mathematical guarantee.

Traditional MFA assigns a score. xFuse provides a proof. The threshold IS the assurance level — not a heuristic, not a probability, but a mathematical guarantee. IAL2 means exactly 3 independent channels converged within a time-bounded window with verified channel diversity. There is no way to achieve IAL2 with 2 channels, regardless of how "strong" those channels are.

The mapping to eIDAS is direct because eIDAS Levels of Assurance are defined by the number and independence of verification factors. xFuse makes this explicit: Low = 2-of-3, Substantial = 3-of-5, High = 4-of-7. The N value provides fault tolerance — you can lose N-K channels and still authenticate.

ACI Surface

7 functions. Create profiles, enroll factors, converge identity, upgrade thresholds, revoke channels, compute assurance, and generate convergence proofs.

Use Cases

From consumer social login to classified defense systems. The threshold determines the assurance level. The channels determine the user experience.

Cross-ACI Composition

xFuse composes with every identity and credential ACI in the PRIVATE.ME platform. Fused identity flows downstream into ephemeral DIDs, credential wallets, push auth, split storage, and verifiable proofs.

xFuse + xID

The fused identity seed becomes the master seed for xID ephemeral DID derivation. Each verifier receives a unique, unlinkable DID derived via HKDF from the fused seed. The verifier never sees the master identity — only the per-context ephemeral DID. xFuse provides the assurance level and xID provides the privacy layer.

xFuse + xWallet

Fused identity gates access to the xWallet credential store. Credentials are XorIDA-split for storage, and the wallet requires threshold convergence to present credentials. The assurance level of the fusion determines which credentials can be accessed — IAL1 for low-sensitivity, IAL3 for government-issued credentials.

xFuse + xLock

xLock push auth serves as one factor channel in the fusion profile. A user taps "Approve" on their device, and the signed push response contributes one share to the convergence. xFuse provides the threshold; xLock provides the frictionless UX for one of the K channels.

xFuse + xStore

Share distribution uses xStore pluggable backends. Each share is routed to an independent storage node — local encrypted storage, cloud relay, hardware security module, or paper QR code. xStore handles the transport; xFuse handles the threshold logic and channel binding.

xFuse + xProve

Every convergence generates a verifiable proof via xProve. The convergenceProof() function produces an HMAC audit chain that records the assurance level, factor count, channel diversity, and timestamp. Auditors and regulators can verify the proof without access to the identity seed.

Orchestration Pipeline

One request. Five steps. Atomic execution. xFuse fuses identity + permissions + session + execution + audit into a single verified pipeline — no gaps between verification and action.

Traditional secure systems verify identity in one service, check permissions in another, execute in a third, and log in a fourth. Each boundary is a gap — a moment where state is assumed rather than proven. xFuse eliminates these gaps by fusing all five steps into one atomic pipeline.

The Five-Step Pipeline

Why this matters: In a traditional system, a race condition between the permission check and the execution can allow unauthorized actions. An expired session can still execute if the check and the action are in different services. xFuse eliminates these gaps — identity, session, policy, and execution are verified in the same execution context, in the same millisecond.

Secure Execution with xProve

Without xProve, the system says “we checked everything and executed correctly.” With xProve, the system says “here is cryptographic proof we checked everything and executed correctly.”

The orchestration pipeline produces correct results. xProve makes those results provably correct. Every step in the pipeline generates a cryptographic receipt, and the composite proof bundle lets any verifier confirm the entire execution independently.

Composite Proof Bundle

The proof is not a single monolithic ZK circuit. Each step maps to the optimal xProve tier:

The composite proof ties all receipts together with a SHA-256 hash. A verifier checks each component independently and confirms the hash binds them into a single execution attestation.

Execute vs Execute-and-Prove

Proof generation is optional. Most requests use the standard pipeline — fast, verified, logged. When a request needs provable correctness (audit, compliance, agent accountability), the caller opts in:

// Standard: verified execution (~5ms)
const result = await xfuse.execute(request);

// Provable: verified execution + cryptographic proof (~40ms)
const { result, proof } = await xfuse.executeAndProve(request);
// proof.type === 'composite'
// proof.components: [signatureReceipt, sessionT1, policyT2, executionT4b]
// proof.compositeHash === sha256(all components)

AI Agent Accountability

Autonomous agents need more than permission — they need proof. xFuse + xProve produces an accountability receipt for every agent action: who acted, what was authorized, what happened, and cryptographic proof it was done correctly.

The AI agent economy is projected at $11.3B by 2028 (non-human identity market). Enterprises will not deploy autonomous agents that can transfer funds, access patient records, or modify infrastructure unless those agents can prove they acted correctly. “Trust me, I’m an AI” is not sufficient. xFuse provides the accountability layer.

Agent Accountability Receipt

An AI agent running through the xFuse pipeline produces four provable claims:

Regulatory Alignment

The accountability receipt maps directly to emerging AI governance requirements:

• EU AI Act (2026): Article 14 requires human oversight of high-risk AI systems. xFuse receipts provide auditable proof of what the agent did and why.
• DORA (2025): Financial institutions must demonstrate ICT risk management. xFuse proves automated trading agents followed authorized strategies.
• HIPAA: Healthcare AI accessing patient records must log who accessed what. xFuse proves the agent had authorization and accessed only permitted data.
• SOC 2 Type II: Continuous monitoring requires evidence of access controls. xFuse receipts serve as cryptographic audit evidence.

Security Model

Information-theoretic. Not computational. K-1 channels compromised = zero information. Quantum-safe unconditionally. HMAC before reconstruction. Channel diversity enforced.

HMAC Before Reconstruction

Every share carries an HMAC-SHA256 integrity tag computed at split time. Before XorIDA reconstruction, all K shares are independently HMAC-verified. If any tag fails, reconstruction is aborted and the tampered share is rejected. This prevents corrupted or maliciously modified shares from producing an invalid identity seed. The HMAC verification uses timingSafeEqual() to eliminate timing side-channels.

Channel Diversity Enforcement

xFuse rejects convergence attempts where multiple shares come from the same channel type. An attacker who clones a device token cannot present it as both the "device" and "push_auth" channels. The convergence validator checks that presented channels span at least two distinct channel types for IAL1, three for IAL2, and four for IAL3.

Verifiable Convergence

Every xFuse convergence can generate a cryptographic proof via convergenceProof(). The HMAC audit chain records the assurance level, factor count, channel diversity, and timestamp.

Benchmarks

Performance characteristics measured on Node.js 22, Apple M2. xFuse completes identity convergence in single-digit milliseconds — the fusion pipeline is faster than a single OAuth token exchange.

Identity Verification Comparison

Ship Proofs, Not Source

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

Use Cases

Honest Limitations

Seven known limitations documented transparently. xFuse provides threshold identity convergence and secure execution orchestration with explicit constraints on channel availability, assurance mapping, and proof generation.

Enterprise CLI

Self-hosted fusion server. Docker-ready. Air-gapped capable. 5-role RBAC + ABAC. Port 4800. 479 tests. Part of the Enterprise CLI Suite.

@private.me/xfuse-cli v0.4.0 provides a production-grade identity orchestration hub with full REST API, 5-role RBAC + attribute-based access control (ABAC), session-bound cryptographic identity, delegation controls, credential orchestration, agent accountability, MPC convergence, and cancelable biometric templates. Integrates 10 PRIVATE.ME packages for comprehensive identity orchestration.

v0.3.0 Production Integrations

IntegrationBundle: Opt-in production integrations via IntegrationBundle pattern. Zero-config = v0.2.0 behavior. Each integration independently toggleable.

4 integrations: xID (ephemeral DID derivation from convergence seed), xPass (billing gate per ACI connection), xLock (push auth as convergence step), xStore (XorIDA-split audit entry persistence).

Redis AsyncRateLimiter: Upgraded from in-memory sliding window to Redis-backed async rate limiting. Graceful fallback to sync limiter if Redis unavailable.

Ed25519 service DID auth: X-Service-DID, X-Service-Signature, X-Service-Timestamp headers for machine-to-machine authentication. Allowlist-based DID verification.

v0.4.0 Platform Identity Hub

ABAC Policy Engine: Attribute-based access control layered on RBAC. Deny-first evaluation. Policies based on assurance level, delegation chain, agent type, risk score, and extensible attributes. Admin-only policy creation. Immutable after creation.

Session-bound cryptographic identity: Ed25519-signed session tokens issued after convergence. Stateless verification. Binds ephemeral DID, assurance level, convergence proof hash, and risk score. Continuous re-evaluation via POST /session/reattest.

Delegation controls: Agent-on-behalf-of-human scenarios. Ed25519-signed delegation grants with chain depth limits (default 0 = no sub-delegation). Max assurance level enforcement. Full audit trail.

Credential orchestration: xWallet integration for convergence attestation credentials. OID4VP-style presentation endpoints. Selective disclosure. XorIDA-split credential storage. Revocation registry.

Agent accountability: AI agent registration with capability tracking, human supervisor requirements, and human-in-the-loop gates for high-risk actions. Per-step lineage chains with optional xProve proofs. Maps to EU AI Act Art. 14.

MPC convergence: xCompute-verified share convergence without cleartext seed reconstruction. Equality circuits verify share consistency via MPC. Optional KKW proof of correct convergence.

Cancelable biometric templates: ISO 24745 compliant. HMAC-based non-invertible transforms. Compromised templates reissued with new seeds. Transform seeds XorIDA-split via xStore.

Risk scoring: Dynamic composite risk score from convergence time, session age, device posture, and behavioral signals. Feeds into ABAC policy evaluation and re-attestation decisions.

CLI Commands

# Start the xFuse fusion server
xfuse serve --port 4800
  → HTTP server on :4800 with RBAC + JSONL stores

# Create a fusion profile (3-of-5, IAL2)
xfuse create --did "did:key:z6Mk..." --threshold 3 --channels 5
  → Generates identity seed, XorIDA-splits, returns shares

# Converge factors to reconstruct identity
xfuse converge --profile "profile-id" --shares "s0.bin,s1.bin,s3.bin"
  → Validates consent, window, diversity, reconstructs seed

# Enroll a new factor channel
xfuse enroll --profile "profile-id" --channel-type "hardware_token"
  → Re-splits with new channel, invalidates old shares

# Upgrade threshold (IAL1 to IAL2)
xfuse upgrade --profile "profile-id" --new-threshold 3 --new-total 5
  → Atomic re-split with upgraded K-of-N parameters

# Revoke a compromised channel
xfuse revoke --profile "profile-id" --channel "channel-id"
  → Re-splits without the revoked channel

# Compute assurance level
xfuse assurance --threshold 3 --total 5
  → IAL2 (Substantial, eIDAS Substantial)

Docker Deployment

# Pull and run the xFuse fusion server
docker compose up -d xfuse

# Verify health
curl http://localhost:4800/health
# {"status":"ok","version":"0.4.0","uptime":42}

# Air-gapped deployment
docker save private.me/xfuse-cli > xfuse-cli.tar
# Transfer to air-gapped environment
docker load < xfuse-cli.tar
docker compose up -d

Get Started

Create a fusion profile, distribute shares to channels, converge factors, and derive an ephemeral DID — all in under 20 lines.

import { createFusionProfile, presentFactors, convergenceProof } from '@private.me/xfuse';

// 1. Create a 3-of-5 fusion profile (IAL2)
const channels = [
  { channelType: 'biometric', label: 'Face ID' },
  { channelType: 'device', label: 'iPhone 16' },
  { channelType: 'credential', label: 'Government ID' },
  { channelType: 'push_auth', label: 'xLock Push' },
  { channelType: 'hardware_token', label: 'YubiKey' },
];

const { profile, shares } = (await createFusionProfile(
  'did:key:z6MkhaXg...', channels,
  { threshold: 3, totalShares: 5 }
)).value;

// 2. Distribute shares to channels (caller responsibility)
// shares[0] -> biometric enclave, shares[1] -> device TPM, etc.

// 3. Later: converge 3 factors to reconstruct identity
const responses = [
  { channelId: profile.channels[0].id, shareData: biometricShare, shareIndex: 0, consented: true, presentedAt: Date.now() },
  { channelId: profile.channels[1].id, shareData: deviceShare, shareIndex: 1, consented: true, presentedAt: Date.now() },
  { channelId: profile.channels[3].id, shareData: pushShare, shareIndex: 3, consented: true, presentedAt: Date.now() },
];

const { identitySeed, assuranceLevel } = (await presentFactors(profile, responses)).value;
// assuranceLevel === 'IAL2'

// 4. Generate convergence proof for audit
const proof = (await convergenceProof(fusionResult, profile)).value;
// proof.assuranceLevel === 'IAL2', proof.factorCount === 3

// 5. Derive ephemeral DID from fused identity seed
// const ephemeralDid = deriveContextDid(identitySeed, verifierId, scope);

// 6. MUST purge after derivation
identitySeed.fill(0);

Fast Onboarding: 3 Acceleration Levels

Get from zero to identity fusion in under 2 minutes. Zero-Click Accept auto-configures from invite codes — no manual setup, no API keys, no complexity.

Level 1: Quick Start (Node.js/TypeScript)

Clone template, configure invite, run. No infrastructure, no dependencies beyond npm.

# Clone template
git clone https://github.com/xail-io/xfuse-starter.git
cd xfuse-starter/node-typescript

# Install dependencies
npm install

# Set invite code (from partner or create your own)
echo "XFUSE_INVITE_CODE=https://xfuse.to/invite/XFS-abc123" > .env

# Run
npm run dev

# ✅ Fusion profile created, identity converged

import { Xfuse } from '@private.me/xfuse';

// Auto-accepts from XFUSE_INVITE_CODE env var
const fusionEngine = await Xfuse.lazy({
  name: 'my-fusion',
  // No invite code parameter needed — reads from env
});

// K-of-N threshold identity convergence
const signals = [
  { channelId: 'ch1', shareData: biometricShare, shareIndex: 0, consented: true },
  { channelId: 'ch2', shareData: deviceShare, shareIndex: 1, consented: true },
];

const result = await fusionEngine.converge(signals);

// CRITICAL: Purge after use
result.value.identitySeed.fill(0);

Level 2: Serverless Deploy (Vercel)

One-click deploy to Vercel Edge Runtime. REST API live in < 60 seconds.

# Visit deployment URL (opens in browser):
https://vercel.com/new/clone?repository-url=https://github.com/xail-io/xfuse-starter

# Vercel prompts:
# 1. Connect GitHub (forks template)
# 2. Set XFUSE_DEFAULT_ASSURANCE_LEVEL (optional)
# 3. Deploy (~15 seconds)
# 4. Done — API live at https://your-project.vercel.app/api/xfuse

# Create fusion profile
curl -X POST https://your-project.vercel.app/api/xfuse/profile \
  -H "Content-Type: application/json" \
  -d '{
    "ownerDid": "did:key:z6Mk...",
    "channels": [
      { "channelType": "biometric", "label": "Face ID" },
      { "channelType": "device", "label": "iPhone" }
    ],
    "config": { "threshold": 2, "totalShares": 2 }
  }'

# Converge identity from 2 factors
curl -X POST https://your-project.vercel.app/api/xfuse/converge \
  -H "Content-Type: application/json" \
  -d '{
    "profileId": "profile_xyz",
    "responses": [
      { "channelId": "ch1", "shareData": "base64...", "shareIndex": 0 },
      { "channelId": "ch2", "shareData": "base64...", "shareIndex": 1 }
    ]
  }'

Level 3: Multi-Platform Starter (Vercel + Netlify + Railway)

GitHub repo with deploy buttons for all major platforms. Choose your stack, click button, deployed.

# GitHub repo includes:
# • Vercel:  vercel.json + api/xfuse.ts
# • Netlify: netlify.toml + netlify/functions/xfuse.ts
# • Railway: railway.json + src/server.js

# All configs included — just click deploy button
https://github.com/xail-io/xfuse-starter

# Setup time by platform:
# Vercel:  ~15 seconds (recommended)
# Netlify: ~20 seconds
# Railway: ~30 seconds

Why Zero-Click Accept?

Traditional fusion setup requires manual channel configuration, share distribution, and K-of-N threshold negotiation. Zero-Click Accept eliminates all of this:

Get Templates

All templates available in the @private.me/xfuse package:

@private.me/xfuse/
├── templates/
│   ├── node-typescript/        # Local dev, full TypeScript
│   │   ├── package.json
│   │   ├── tsconfig.json
│   │   ├── src/index.ts
│   │   └── .env.example
│   ├── vercel/                 # Serverless edge function
│   │   ├── api/xfuse.ts
│   │   ├── vercel.json
│   │   └── package.json
│   └── github-starter/         # Multi-platform deploy
│       └── README.md           # Platform buttons + docs

Ready to deploy xFuse?

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