Bridge Integration

The Lux Bridge uses MPC for threshold signing of cross-chain transfers. Each bridge transaction requires t-of-n MPC nodes to produce a valid signature before assets are released on the destination chain.

Transfer Flow

1. User initiates transfer via Bridge UI at bridge.lux.network
2. Bridge API validates the request and creates an intent document
3. HSM co-signs the intent (if --hsm-attest is enabled)
4. MPC nodes receive the signing request via the consensus transport
5. Each participating node produces a threshold signature share
6. Shares are aggregated into a valid ECDSA signature
7. The bridge server broadcasts the signed transaction to the destination chain
8. Bridge API updates the transfer status

Supported Protocols

The native MPC threshold signature is the complete, permissionless signing path — it is sufficient on its own and requires no external custodian.

Layered External-Custodian Cosigning (optional, institutional)

Regulated and institutional flows can require an external custodian to co-sign on top of the native MPC signature. This is opt-in compatibility for tenants who must keep a regulated custodian (e.g. Utila or Fireblocks) in the approval path; it is not part of the public permissionless bridge.

How it composes, per swap:

1. The SDK declares the required cosigners by public identifier only (org_id, api_key, vault ids) — secret material never crosses the wire.
2. The native MPC network produces its threshold signature first.
3. Each declared custodian independently attests to the same transaction hash.
4. All listed must approve — any rejection fails the swap.

The custodian secret (Utila PEM, Fireblocks signing key) is fetched at dispatch time from KMS, keyed by the public identifier — never stored in the swap record and never sent by the client. The vendor set is an extensible family (adding one is a new Kind + dispatcher branch).

Bridge Architecture

Bridge UI (Next.js)
  -> Bridge API (Node.js, port 3000)
    -> MPC Cluster (3 nodes, consensus mode)
      -> node-0 (port 9651)
      -> node-1 (port 9652)
      -> node-2 (port 9653)
    -> Destination chain RPC

MPC Node Configuration for Bridge

mpcd start --mode consensus \
  --node-id node0 \
  --listen :9651 \
  --api :9800 \
  --data /data/mpc/node0 \
  --threshold 2 \
  --peer node1@10.0.0.2:9652 \
  --peer node2@10.0.0.3:9653

Security Properties

Kubernetes Deployment

The bridge MPC nodes run in the lux-bridge namespace with separate PostgreSQL and Valkey instances from the main MPC cluster:

lux-bridge namespace:
  mpc-node-0, mpc-node-1, mpc-node-2
  bridge-postgres
  bridge-api
  bridge-ui