bridge/docs/LLM.md

Lux Bridge

Project: Lux Bridge Organization: Lux Network

Project Overview

The Lux Bridge is a decentralized cross-chain bridge infrastructure that enables secure, trustless asset transfers between multiple blockchain networks using Multi-Party Computation (MPC) technology. It serves as the primary interoperability layer for the Lux ecosystem, connecting 15+ blockchain networks.

Package layout — public vs internal

Two scopes, one canonical SDK entrypoint. Downstream consumers (Lux, Hanzo, Zoo, any white-label) import @luxfi/bridge and nothing else.

Path	npm name	Scope	Published
pkg/bridge/	@luxfi/bridge	public SDK	pending — see §Publishing
pkg/core/	@luxfi/core	public shared types	yes (last 10.0.5, 2025-05-09)
pkg/threshold/	@luxfi/threshold	public MPC SDK	pending — see §Publishing
pkg/utila/	@luxfi/utila	public utila client	yes (last 3.0.0, 2024-11-21)
pkg/settings/	@luxbridge/settings	private workspace	no
pkg/ui/	@luxbridge/ui-automation	private workspace	no
app/bridge/	@luxbridge/lux-tenant	private workspace	no
app/explorer/	@luxbridge/explorer	private workspace; migration to ghcr.io/luxfi/explorer planned — see §Explorer migration	no
app/server/	@luxbridge/server	private workspace	no

Rules:

• @luxfi/bridge is the ONLY package consumers import. It re-exports mountBridge, Bridge, and the config/brand types. Internals are hidden.
• @luxbridge/* packages are workspace-only. They are not published and must not be imported by anything outside this repo.
• @luxfi/{core,threshold,utila} are generic Lux building-block libraries — bridge-agnostic, may be reused elsewhere in the Lux ecosystem.

Canonical brand sourcing — @luxfi/brand is the only source

Every Lux-ecosystem tenant app — bridge, exchange, id, pay, etc. — pulls its brand identity from one package: @luxfi/brand (source repo: ~/work/lux/brand). No Lux-specific brand strings, colors, logos, or support email addresses are baked into the SDK or any other downstream artefact.

How the bridge tenant does it (app/bridge/src/bridge.config.ts):

import luxBrandJson from '@luxfi/brand/brand.json'
const { shortName, primaryColor, supportEmail } = luxBrandJson.brand

export const bridgeConfig: BridgeConfig = {
  apiHost: env('BRIDGE_API_HOST', 'https://api.bridge.lux.network')!,
  brand: {
    name:         `${shortName ?? 'Lux'} Bridge`,   // composed at runtime
    primaryColor: primaryColor ?? '#000000',
    supportEmail: supportEmail ?? '[email protected]',
  },
  // …
}

Rules:

• The SDK (pkg/bridge/) is jurisdiction-neutral. It declares no Lux-specific brand. Tenants supply brand at mount time via BridgeConfig.brand. The SDK has no direct dependency on @luxfi/brand — that'd be a layering violation (Zoo, Hanzo, or any white-label tenant must be able to consume @luxfi/bridge without pulling Lux brand metadata into their bundle).
• App-specific endpoints (api.bridge.lux.network, docs.lux.network/bridge) belong to the bridge product and are independent of @luxfi/brand's appDomain (lux.exchange — that's the exchange product's domain).
• SSR / no-window fallbacks in the SDK derive from cfg.apiHost rather than hardcoding a Lux URL — see deriveAppOrigin in pkg/bridge/src/app/lib/wagmi-config.ts.

Other Lux apps follow the same pattern: ~/work/lux/exchange reads the full brand block; ~/work/lux/id reads name + primaryColor + appDomain; etc. If you find a hardcoded brand string in any Lux app, it's a leak — file it as a follow-up issue and route the value through @luxfi/brand.

History — what got folded together

• app/bridge3/ (formerly @luxbridge/app-v3) was folded into pkg/bridge/src/app/ at commit abed909 ("feat(pkg/bridge): inline bridge UI under src/app/", phase 1.5). The old lazy-loaded workspace cycle that produced the blank-page bug is gone. Bridge.tsx no longer references any sibling workspace package.
• app/bridge/ was collapsed to a single canonical tenant build at 6bc55b2 ("phase2-r2: collapse to canonical app/bridge tenant"). It is now @luxbridge/lux-tenant (~120 LOC: bridge.config.ts, main.tsx, index.html + Vite config), not the multi-variant Next.js app shown in stale diagrams.

SDK mount pattern

import { mountBridge } from '@luxfi/bridge'

mountBridge({
  config: {
    apiHost: 'https://api.bridge.lux.network',
    env: 'mainnet',
    brand: { name: 'Lux Bridge', primaryColor: '#0066ff' },
  },
})

Mirrors mountExchange from the upstream exchange SDK. One declarative entry, build-time brand config, no hostname detection inside the SDK.

Publishing

.github/workflows/publish.yml fires on v* tag push, runs on the self-hosted lux-build runner. Runs pnpm publish -r --access public --no-git-checks — pnpm walks the workspace, skips private: true packages, and publishes any @luxfi/* package whose version is not yet on npmjs.org. Bump versions in PRs; tag once merged.

Status as of 2026-05-22: the workflow is wired and hardened (fail-fast on missing NPM_TOKEN/NODE_AUTH_TOKEN; token baked into the NPM_CONFIG_USERCONFIG path because pnpm doesn't expand ${VAR} in .npmrc) but @luxfi/bridge and @luxfi/threshold are still 404 on npmjs.org. Confirmed by @luxfi/core 10.0.5 and @luxfi/utila 3.0.0 both pre-dating every v1.1.x tag — no v1.1.x release has ever shipped to npm. Most likely missing NPM_TOKEN secret on the luxfi/bridge repo (Settings → Secrets and variables → Actions) OR an unavailable lux-build runner pool. The v1.1.10 fail-fast guard will surface either clearly on the next run.

Explorer migration

app/explorer/ (@luxbridge/explorer, Next.js standalone) is on a deprecation path. The canonical replacement is ghcr.io/luxfi/explorer — a single Go binary at ~/work/lux/explorer that:

• Indexes EVM chains via luxfi/indexer
• Exposes per-chain GraphQL via luxfi/graph
• Serves the embedded SPA from luxfi/explore via go:embed

Routes (served from one binary, port-flexible):

Path	Purpose
/	SPA (embedded; SPA-routing fallback)
/envs.js	Runtime window.ENV = {…}
/v1/indexer/{slug}/*	Per-chain explorer REST API
/v1/graph/{slug}/{subgraph}/graphql	Per-chain, per-subgraph GraphQL
/v1/explorer/realtime	WebSocket realtime hub

Migration plan: deploy luxfi/explorer alongside app/explorer/, hostname-cutover (bridge-explorer.lux.network) on K8s, delete the Next.js app after one-week soak.

The bridge backend (app/server/) does not depend on app/explorer/; the migration is UI-only.

Architecture Summary

Core Technology Stack

• SDK: @luxfi/bridge — TypeScript source-published; React 18 + Tamagui (@hanzo/gui v7 + @hanzogui/* peer-optional primitives); wagmi 2 + viem 2
  • @tanstack/react-query 5 for wallet; @luxfi/threshold for native MPC threshold sign sessions
• Tenant apps: Vite + React 18.3.1 (app/bridge/ = @luxbridge/lux-tenant, app/explorer/ = @luxbridge/explorer)
• Backend: Node.js + Express + Prisma (app/server/ = bridge API at api.bridge.lux.network)
• MPC Framework: 2-of-3 threshold signature scheme using github.com/luxfi/mpc (Go); client-side session helper via @luxfi/threshold (TS)
• Smart Contracts: Solidity (OpenZeppelin), deployed on multiple chains
• Infrastructure: Docker, Kubernetes, PostgreSQL, NATS, Consul, Vault (KMS)
• Authentication: Lux ID (Casdoor) for unified auth
• Runtime config: window.__ENV (templated from BRIDGE_* env at container boot by nginx docker-entrypoint) with build-time import.meta.env.VITE_* fallback. One image, N envs.

System Architecture

                   ┌──────────────────────────────────┐
Tenant app         │ @luxfi/bridge  (pkg/bridge/)     │
(app/bridge/,      │ exports: Bridge, mountBridge,    │
 app/explorer/)    │   BridgeConfig, types            │
imports SDK +      │                                  │
brand:             │ Bridge UI is INLINED at          │
  @luxfi/bridge ─▶ │   pkg/bridge/src/app/            │
  @luxfi/brand     │ (no @luxbridge/app-v3, no        │
                   │  workspace cycle, no lazy load)  │
                   │                                  │
                   │ Direct deps:                     │
                   │   @hanzo/gui, @luxfi/threshold,  │
                   │   wagmi, viem, react-query       │
                   └─────────────┬────────────────────┘
                                 │
                ┌────────────────┴─────────────────┐
                ▼                                  ▼
    ┌───────────────────────┐         ┌──────────────────────┐
    │ app/server            │         │ @luxfi/threshold     │
    │ Bridge API            │         │ MPC threshold SDK    │
    │ Express + Prisma      │         │ (consumed by BOTH    │
    │ api.bridge.lux.network│         │  SDK + server)       │
    └──────────┬────────────┘         └──────────┬───────────┘
               │                                 │
               ▼                                 ▼
    ┌─────────────────────┐            ┌──────────────────┐
    │ b-chain             │            │ m-chain (public  │
    │ Lux primary network │            │ MPC, m-chain)    │
    │ consensus + state   │            │                  │
    └─────────────────────┘            │ + optional       │
                                       │ private cluster  │
                                       │ (treasury fees)  │
                                       │                  │
                                       │ + optional       │
                                       │ layered cosign:  │
                                       │   Utila          │
                                       │   Fireblocks     │
                                       └──────────────────┘

MPC Network Configuration

• Node Count: 3 nodes (2-of-3 threshold) on m-chain (public MPC)
• Ports:
  • HTTP API: 6000-6002
  • gRPC: 9090-9092
  • NATS: 4223
  • Consul: 8501
• Security: TLS 1.3, mutual authentication, HSM integration
• Protocols: cggmp21 (default), frost, bls, doerner (classical); pulsar (MLWE), corona (RLWE), magnetar (lattice research variant) — PQ-safe, leaderless, permissionless-safe by design.

Standalone mode — running the bridge without the Lux platform

The bridge can boot with the absolute minimum: Postgres + bridge-server + bridge-ui. Every other Lux service (IAM / KMS / m-chain MPC / cosigners) is optional at runtime — the backend graceful-degrades when the corresponding env block is unset and picks up the integration the moment the block appears.

docker compose -f compose.standalone.yml up --build
# bridge UI    http://localhost:3001
# bridge API   http://localhost:5000/healthz
# postgres     localhost:5433 (user=bridge, pass=bridge, db=bridge)

What's intentionally NOT in compose.standalone.yml (but is in compose.local.yml):

Service	Why standalone can skip it
Casdoor (Lux ID)	bridge does not require auth in dev mode
Vault (KMS)	fetchCosignerSecret falls back to env-var pattern when BRIDGE_KMS_URL is unset
NATS	only mpc-service.ts consumes it; backend logs a warn and skips its initialise()
Consul	same — mpc-service.ts only
3-node MPC cluster	LuxMPCClient is constructed on demand; native MPC sign requires it but cosigner-layered swaps don't

To enable any of the optional layers, set the matching env block on the bridge-server service in compose.standalone.yml (commented stubs are already there). The bridge picks them up on next request — no restart required for cosigner config, only BRIDGE_MPC_URL requires a restart (cached at server start).

ZAP serialization — canonical home is ~/work/zap, npm scope @zap-proto

The bridge currently uses plain JSON over HTTP for every wire call (mpcd, KMS, IAM, cosigner adapters, f-chain). It does not depend on any binary RPC codec. If a future surface needs Cap'n-Proto-style binary RPC (e.g. mpcd → bridge events stream), use ZAP — the canonical Lux / Hanzo zero-copy app protocol.

Aspect	Canonical
Source repo	~/work/zap (not ~/work/lux/zap or ~/work/hanzo/zap — those are forks / legacy clones being consolidated upstream)
GitHub org	zap-proto
npm scope	@zap-proto/*
TS package	@zap-proto/zap (lives at ~/work/zap/zap-js) — pure-TS codec, no third-party Cap'n Proto deps. The package.json once listed capnp-es in dependencies but no source file imports it; that dep is stale and slated for removal in the next ZAP TS publish
WASM binding	@zap-proto/wasm (~/work/zap/zap-wasm)
Go / Rust	wire-compatible siblings; same ZAP framing

Rules for the bridge (and any other downstream consumer):

• Never pnpm add capnp-es to add binary RPC. If we need Cap'n-Proto- style framing, use @zap-proto/zap (pure TS, no third-party dep). The whole point of ZAP is to be brand-neutral and wire-compatible across Go / Rust / TS without pulling in the upstream Cap'n Proto JS ecosystem.
• The @zap-proto/* scope is brand-neutral. Don't publish @luxfi/zap-* or @hanzoai/zap-* variants — they'd fork the wire format and break cross-stack RPC.
• Source of truth for the wire format: ~/work/zap/README.md (Go) + ~/work/zap/zap-js/src/protocol.ts (TS). Match either.

Foreign-brand bridge tenants — out of this repo

The canonical Lux cross-chain bridge protocol lives at ~/work/lux/teleport (Warp 2.0 envelopes + m-chain custody, LP-021v2 / LP-7330). The user-facing UI + SDK is ~/work/lux/bridge (this repo) and ships ONE Lux-branded tenant (app/bridge/). Foreign-brand bridge surfaces (Hanzo, Zoo, Pars, third-party) MUST live in their own repos and own their brand assets there — typically a thin shim repo (e.g. zooai/bridge-shim) that consumes @luxfi/bridge plus its own brand package. No foreign-brand tenant manifests, logos, or color tokens belong in luxfi/bridge. The SDK is the integration point; tenants are thin and live where their brand lives.

Native Lux services — m-chain (MPC) + KMS + f-chain

The bridge backend talks to the canonical Lux ecosystem services via HTTP clients in app/server/src/clients/:

• lux-iam.ts — LuxIAMClient.mint(audience) mints OAuth2 client_credentials JWTs against Lux IAM (https://iam.lux.network). Per-audience cache with early refresh. The bridge mints one token for aud=lux-kms and another for aud=lux-mpc; both rotate independently.
• lux-kms.ts — LuxKMSClient.getSecret(path) reads from ~/work/lux/kms (https://kms.lux.network). Bearer JWT auth, path layout bridge/cosigners/{utila|fireblocks}/{publicId}/{sa_pem|secret_pem}. Replaces every env-var fallback in domain/cosigners.ts::fetchCosignerSecret.
• lux-mpc.ts — LuxMPCClient.keygen({...}) / .sign({...}) / .status() against mpcd (https://mpc.lux.network). This is THE m-chain entrypoint — the canonical Lux MPC daemon at ~/work/lux/mpc, speaking the same wire protocol as the Go client at ~/work/lux/kms/pkg/mpc/client.go. Supports the full Lux protocol set (CGGMP21 / FROST / BLS / SR25519 / Pulsar / Corona / Magnetar / Doerner). Per-call 120s timeout matches mpcd's threshold-completion ceiling.

Configuration via env (bridge backend startup):

BRIDGE_IAM_ISSUER        https://iam.lux.network
BRIDGE_KMS_URL           https://kms.lux.network
BRIDGE_KMS_ORG           lux
BRIDGE_IAM_CLIENT_ID     lux-bridge
BRIDGE_IAM_CLIENT_SECRET (from KMS at boot OR --kms-bootstrap-secret)
BRIDGE_MPC_URL           https://mpc.lux.network

When BRIDGE_KMS_URL is unset (local dev), fetchCosignerSecret falls back to per-tenant env vars. Production deployments MUST set the KMS env block — env-var fallback is dev-only.

Lux software frontends (administrative UIs)

Three Lux ecosystem services ship their own administrative UIs separate from the bridge tenant SDK:

Service	Frontend repo / path	Stack	Domain
m-chain (mpcd)	~/work/lux/mpc/dashboard/ (@luxfi/mpc-dashboard)	Next.js 15 + React 19 + zustand	mpc.lux.network/dashboard
KMS	~/work/lux/kms/frontend/ (@hanzo/kms-frontend)	Vite + React	kms.lux.network
f-chain (fhed)	DOES NOT EXIST — see below	—	—

The bridge does not embed these dashboards; they're separate operator surfaces.

f-chain frontend — what it would look like

~/work/lux/fhe (the FHE daemon fhed) currently has no dedicated UI. The bridge tenant's TRANSFERS panel surfaces per-swap f-chain attestation status (a CosignerStep row when the bridge backend processes a swap with fchain: { publicUrl, scheme } config), but that's per-bridge-tenant, not a cluster-wide operator surface.

A standalone f-chain dashboard, when built, would mirror the mpc-dashboard layout and surface:

1. Cluster status — GET /v1/fhe/cluster/status: peer count, FHE scheme registry, share health per node.
2. Public key registry — GET /v1/fhe/publickey: published FHE public keys per scheme (CKKS / BGV / BFV), with an export button.
3. Encryption sessions — recent /v1/fhe/encrypt calls and their ciphertext bindings (txHash → ciphertext_hex), filterable by requesting service (bridge / pay / id / ...).
4. Reshare history — /v1/fhe/cluster/reshare events.
5. Health probe — GET /v1/fhe/health rolled up to per-node status.

Recommended scaffold (when scheduled):

~/work/lux/fhe/dashboard/   # new Next.js app, mirror of mpc/dashboard
  package.json              @luxfi/fchain-dashboard
  app/                      # Next.js app router
  components/cluster/       # ClusterStatus, PeerList
  components/keys/          # PublicKeyRegistry, ExportButton
  components/sessions/      # EncryptHistory, CiphertextViewer
  lib/fchain-client.ts      # mirrors lux-mpc.ts / lux-kms.ts shape

Optional layered cosigners (since SDK v1.0.3)

External MPC custodians can be layered ON TOP of the native threshold network as additional cosigners. The bridge backend enforces 2-of-2 (native + layered) before releasing settlement. Use when tenants are already on Utila or Fireblocks for institutional custody and need regulated-cosigner gating without giving up the native threshold property.

Browser SDK declares config only; the secret half (Utila JWT / Fireblocks secret key) lives on app/server/ (sourced from KMS at boot). No secret material is ever shipped in the page bundle.

mountBridge({
  config: {
    apiHost: 'https://api.bridge.lux.network',
    env: 'mainnet',
    mpc: {
      publicUrl: 'https://mpc.lux.network',
      protocol: 'cggmp21',
      // optional — layered cosigner #1
      utila: { orgId: 'tenant-x', clientId: 'lux-bridge' },
      // optional — layered cosigner #2 (both may be enabled together)
      fireblocks: { apiKey: 'pub-key-id', vaultAccountId: '0' },
    },
  },
})

Per-swap, the SDK forwards a cosigners[] array of public identifiers (orgId, clientId, apiKey, vault ids) to POST /api/swaps. The backend pairs each entry with a KMS-held secret and completes the cosign on behalf of the tenant.

Supported Networks & Assets

Chain support — ground truth (v1.1.41, 2026-06-26)

The cmd/bridge MPC pipeline routes by address family (internal/mchain AddressType enum + switch dispatch — there is NO polymorphic Chain interface). Per-chain reality (stale "TODO"/"coming soon" comments elsewhere lag the code — this table is authoritative):

Family	Inbound (depositcheck)	Outbound (assemble+sign+broadcast)	Config	Status
ETH/EVM	done (eth_getBalance / ERC-20)	done (hand-rolled RLP, no go-ethereum)	enabled	full, live
BTC	done (Blockstream REST)	code-complete	deposit-only	withdrawal gated on mpcd Schnorr
SOL	done (getBalance)	code-complete	disabled both	gated on mpcd Ed25519/FROST
TON	done (TON Center)	code-complete	disabled both	gated on mpcd Ed25519
XRP	done — rippled account_info, validated ledger, drops (internal/depositcheck)	done — DestinationTag plumbed into the SHA-512Half signing digest; X-addr rejected	testnet on; mainnet gated	secp256k1 (same curve as ETH/BTC) → no mpcd gap

XRP is the only non-EVM family with no external mpcd blocker. XRP per-swap deposit addresses must hold the ≥10-XRP AccountRoot reserve (per-XRP minUSD floor set); the reserve is a known capital-leak follow-up (shared-deposit + dest-tag is the robust model).

Withdrawal/deposit gate — AUTHORITATIVE (v1.1.41)

Config.WithdrawalEnabled / DepositEnabled (cmd/bridge/config.go) are enforced SERVER-SIDE at create (403), sign (skip = kill-switch), broadcast (hold in-flight), and operator inject (403) — not just the SPA /currencies list. Match is case-INSENSITIVE with default-DENY for wired non-EVM families (so an asset-case variant xrp or network-case bitcoin_testnet can't dodge a disabled row into a release pool — the gate key aligns with the network-only/case-folded signer routing).

Mainnet-readiness follow-ups (pre-existing, bridge-wide; tracked, NOT XRP-specific)

• /admin/swaps/:id/{reset,inject-raw-tx} have no auth middleware (bounded by 64-bit random swap IDs + the now-gated inject). Gate behind operator token / mTLS.
• GET /v1/bridge/swaps has no tenant scoping (IDOR).
• depositcheck is the SOLE runtime payout gate (single hardcoded RPC, no quorum) — multi-RPC quorum / on-chain proof is the platform hardening. Point only at trusted RPCs.
• mainnet XRP withdrawal stays isWithdrawalEnabled:false until the above + a live testnet tag-carrying-payout proof.

Blockchain Networks (15+)

Layer 1: Lux, Ethereum, BSC, Polygon, Fantom Layer 2: Arbitrum, Optimism, zkSync Era, Polygon zkEVM, Base, Blast Other: TON, Solana (gated on mpcd Ed25519), XRP (testnet live), Cosmos (via IBC)

Supported Assets

Stablecoins: USDT, USDC, DAI, ZUSD Native Tokens: LUX, ETH, BNB, MATIC Wrapped Assets: ZETH, ZBNB, ZPOL, ZTON (ERC20B standard)

Key Smart Contracts

Core Contracts

• Bridge.sol - Main bridge contract with deposit/withdraw logic
• LuxVault.sol - Asset vault for Lux Network
• ETHVault.sol - Ethereum vault contract
• ZooVault.sol - Multi-asset aggregated vault
• LERC4626.sol - Tokenized vault shares

Wrapped Token Contracts (ERC20B)

All wrapped tokens follow the ERC20B standard with mint/burn capabilities:

• Location: /contracts/contracts/zoo/
• Examples: Z.sol, ZETH.sol, ZUSD.sol, ZBNB.sol

API Endpoints

REST API (Port 5000)

• GET /api/v1/status - Bridge operational status
• GET /api/v1/chains - Supported blockchains
• GET /api/v1/assets - Supported tokens
• POST /api/v1/quote - Get transfer quote
• POST /api/v1/transfer - Initiate transfer
• GET /api/v1/transfer/{id} - Transfer status

WebSocket API

• Subscribe to transfer updates
• Real-time status notifications
• Event streaming for bridge operations

Essential Commands

Development

# Clone and install
git clone https://github.com/luxfi/bridge
cd bridge
pnpm install

# Install MPC tools
make install-mpc

# Start infrastructure
make up

# Start MPC nodes
make start-mpc-nodes

# Start services
cd app/bridge && pnpm dev  # UI on :3001
cd app/server && pnpm dev  # API on :5000

Infrastructure Management

# Infrastructure
make up                     # Start all infra services
make down                   # Stop all services
make logs                   # View aggregated logs

# MPC Operations
make start-mpc-nodes        # Start 3-node MPC network
make stop-mpc-nodes         # Stop MPC nodes
make generate-mpc-keys      # Generate new MPC keys
lux-mpc-cli status          # Check MPC status

# Development
pnpm dev                    # Start development servers
pnpm build                  # Build for production
pnpm test                   # Run test suite
pnpm lint                   # Run linters

# Deployment
make deploy-testnet         # Deploy to testnet
make deploy-mainnet         # Deploy to mainnet

Architecture

The bridge uses a multi-layered architecture:

1. Presentation Layer: React/Next.js UI for user interaction
2. API Layer: Node.js server handling business logic
3. MPC Layer: Distributed nodes for threshold signatures
4. Blockchain Layer: Smart contracts on multiple chains
5. Infrastructure Layer: Supporting services (DB, messaging, KMS)

Data Flow

1. User initiates transfer on source chain
2. Bridge contract locks assets in vault
3. Event emitted and detected by MPC nodes
4. MPC nodes reach consensus and generate signature
5. Signed message relayed to destination chain
6. Destination contract mints wrapped tokens
7. User receives tokens on destination chain

Key Technologies

• Multi-Party Computation (MPC): Distributed key management
• Threshold Signatures: 2-of-3 security model
• Smart Contracts: Solidity with OpenZeppelin
• Message Queue: NATS for inter-node communication
• Service Discovery: Consul for dynamic configuration
• Key Management: HashiCorp Vault
• Authentication: Casdoor (Lux ID)
• Database: PostgreSQL for state management
• Container Orchestration: Docker/Kubernetes

Development Workflow

Local Development

1. Start infrastructure: make up
2. Initialize MPC network: make start-mpc-nodes
3. Deploy contracts: cd contracts && npx hardhat deploy
4. Start API server: cd app/server && pnpm dev
5. Start tenant UI: cd app/bridge && pnpm dev (Vite on :3001)
6. SDK dev: edit pkg/bridge/src/ — tenant Vite picks up changes live through the workspace symlink. No publish needed for local iteration.

Testing

• Unit tests: pnpm test:unit
• Integration tests: pnpm test:integration
• Contract tests: cd contracts && npx hardhat test
• E2E tests: pnpm test:e2e

Deployment

1. Build artifacts: pnpm build
2. Deploy contracts: make deploy-{network}
3. Update configuration
4. Deploy services via CI/CD
5. Verify deployment: make verify-deployment

Configuration

Environment Variables

# Network
NETWORK=mainnet|testnet|local
CHAIN_ID=31337

# Database
DATABASE_URL=postgresql://user:pass@localhost:5433/bridge

# MPC
MPC_NODE_COUNT=3
MPC_THRESHOLD=2

# KMS (Vault)
VAULT_ADDR=http://localhost:8200
VAULT_TOKEN=<token>

# Authentication (Lux ID)
CASDOOR_ENDPOINT=http://localhost:8000

Service Ports

• Bridge UI (tenant app/bridge/): 3001 (Vite dev/preview server)
• Bridge API (app/server/): 5000 (Express)
• Bridge explorer (app/explorer/, legacy): 3002 (Next.js)
• Bridge explorer (ghcr.io/luxfi/explorer, replacement): port-flexible
• MPC Nodes: 6000-6002 (HTTP), 9090-9092 (gRPC)
• PostgreSQL: 5433 (bridge), 5434 (auth)
• Vault (KMS): 8200
• Lux ID: 8000
• NATS: 4223
• Consul: 8501

Security Best Practices

1. Never commit secrets - Use environment variables
2. Validate all inputs - Prevent injection attacks
3. Use secure communication - TLS 1.3 everywhere
4. Implement rate limiting - Prevent DDoS
5. Regular security audits - Contract and code reviews
6. Monitor everything - Logs, metrics, alerts
7. Incident response plan - Be prepared for emergencies

Monitoring & Debugging

Health Checks

• Bridge API: curl http://localhost:5000/health
• MPC Nodes: curl http://localhost:6000/health
• Infrastructure: http://localhost:8501/ui (Consul)

Debugging Commands

# Check MPC status
lux-mpc-cli status --url http://localhost:6000

# View logs
tail -f logs/mpc-node-*.log

# Database queries
psql $DATABASE_URL -c "SELECT * FROM transfers WHERE status='pending';"

# NATS monitoring
nats-top -s localhost:4223

Documentation

Comprehensive Documentation Site (Nextra)

• Location: ~/work/lux/bridge/docs/ (Next.js + Nextra)
• Pages: docs/pages/*.mdx
• Build: cd docs && pnpm install && pnpm build
• Dev: cd docs && pnpm dev → http://localhost:3000

Key Documentation Files

• docs/LLM.md — this file, canonical AI/onboarding doc (single source of truth)
• docs/LUX-ID-INTEGRATION.md — Casdoor-based unified auth integration
• pkg/bridge/README.md — consumer-facing SDK docs (mountBridge, BridgeConfig)
• Top-level README.md — quick-start + architecture pointer (kept consistent with this file)

The legacy migration .md files (BRIDGE-STATUS, LOCAL-SETUP, the four MPC migration notes, DEPLOYMENT, CI-CD-DOCKER-IMAGES) were deleted in v1.1.12 (commit b04e805, issue #391) — they described an architecture from before the SDK rationalization and confused new readers. Migration history lives in git log and the GH release notes.

Context for All AI Assistants

This file (LLM.md) is symlinked as:

• AGENTS.md
• CLAUDE.md
• QWEN.md
• GEMINI.md

All files reference the same knowledge base. Updates here propagate to all AI systems.

Rules for AI Assistants

1. ALWAYS update LLM.md with significant discoveries
2. NEVER commit symlinked files (AGENTS.md, CLAUDE.md, etc.) - they're in .gitignore
3. NEVER create random summary files - update THIS file

---

Note: This file serves as the single source of truth for all AI assistants working on this project.