teleport/WARP2_BRIDGE.md

Teleport with Warp 2.0 — Post-Quantum Cross-Chain Mint/Burn

Status: Draft (spec + skeleton). Production deployment requires the Lux EVM precompile suite (LP-2517 / LP-2311 / LP-2312) and the luxfi/warp EnvelopeV2 aggregator pipeline.

This document describes how the Teleport bridge is upgraded from an EIP-712 MPC-oracle authorisation model to a Lux Warp 2.0 envelope authorisation model. The Warp 2.0 envelope is the canonical cross-chain attestation format defined in github.com/luxfi/warp and LP-105 §"Warp evolution".

1. Why Warp 2.0

Teleport v1 authorises a destination-chain mint by an EIP-712 typed signature from one of the bridge oracle keys (Bridge.sol, bridgeMint). That model relies on a single classical primitive (secp256k1 ECDSA) and a single trust anchor (the configured oracle key set). A break of secp256k1 — by quantum advance, key compromise, or oracle takeover — is catastrophic.

Warp 2.0 (LP-021v2, implemented in github.com/luxfi/warp/envelope.go) binds three independent attestations into a single envelope:

Lane	Primitive	Size	Function
Beam	BLS12-381 aggregate	48 B + signer bitmap	classical fast path (LP-075)
ML-DSA cert set	ML-DSA-65 (FIPS 204)	~3.3 KB × N validators	per-validator post-quantum identity proof (LP-070)
Pulse	Pulsar threshold (Lux's lattice threshold scheme built on the two-round Corona construction, eprint 2024/1113, with DKG2 + Pulsar-SHA3)	~33 KB Ring-LWE	threshold post-quantum proof per round (LP-073)

A quantum break of any single primitive does not let an attacker forge a Teleport claim — the destination-chain bridge requires the envelope to satisfy all three lanes (configurable per asset and per deployment).

2. Architecture

   SOURCE CHAIN                    LUX VALIDATOR SET                    DESTINATION CHAIN
   ─────────────                   ─────────────────                    ──────────────────

   user calls                      observe burn log ──────►  build      verify EnvelopeV2
   BridgeV2.burn(...)              UnsignedMessage           via IWarp2Verifier
        │                          (sourceChainId,                         │
        ▼                           destChainId,                  Beam:    BLS aggregate
   emits BridgeBurnedV2             messageHash)                           (BLS12-381 precompile,
   event with                       │                                       LP-118 / LP-2311)
   messageHash                      ├── Beam aggregator ─────►              │
                                    │   (BLS12-381 over hash)      Cert:    ML-DSA-65 set
                                    ├── ML-DSA per-validator ─►              (FIPS 204 precompile,
                                    │   FIPS 204 sigs                        LP-070 / LP-2517)
                                    └── Pulsar Pulse ─────────►              │
                                        DKG2 + Pulsar-SHA3            Pulse: Pulsar threshold
                                                                              (LP-073 / LP-2312)
                                                                              │
                                                                      claim() mints / releases
                                                                      to recipient

The full envelope wire format (RLP) is documented in luxfi/warp/envelope.go — EnvelopeV2 carries the v1 Message (so the Beam fast path stays byte-equal to Warp 1.x), four transcript-binding fields (SourceNebulaRoot, SourceKeyEraID, SourceGeneration, HashSuiteID), and the two PQ-lane byte slices.

3. Envelope flow on Teleport

3.1 Burn (source chain)

// BridgeV2.sol
function burn(BurnRequest calldata r) external returns (bytes32 messageHash);

The BurnRequest commits all destination data into the on-chain event so the validator set can reconstruct the canonical UnsignedMessage purely from logs (no off-chain inputs).

messageHash is keccak256(abi.encode(sourceChainId, destChainId, asset, amount, recipient, nonce)) and is also the EnvelopeV2.ID() returned by luxfi/warp.EnvelopeV2.ID() (the v1 UnsignedMessage ID is preserved across v1/v2 envelopes — see envelope.go line 207-212).

3.2 Validator-set signing (off-chain)

The Lux validator set runs three concurrent attestation pipelines:

1. Beam aggregator — BLS12-381 sign of messageHash, aggregated per signature_aggregator.go.
2. ML-DSA cert set — each validator emits a FIPS 204 ML-DSA-65 signature; the set is concatenated into EnvelopeV2.MLDSACertSet.
3. Pulsar Pulse — the Pulsar (built on the two-round Corona construction, eprint 2024/1113) lattice threshold kernel (luxfi/pulsar) produces a single Pulse over the canonical transcript built by pulsar.BuildSigningBytes (see warp/README.md §"Pulse path").

The completed EnvelopeV2 is relayed to the destination chain.

3.3 Claim (destination chain)

// BridgeV2.sol
function claim(IWarp2Verifier.Envelope calldata env, ClaimData calldata claim) external;

claim():

1. Calls IWarp2Verifier.verify(env) — the on-chain verifier dispatches to the BLS, ML-DSA, and Pulsar precompiles as configured.
2. Checks that env.messageHash == keccak256(abi.encode(claim)) — binds the envelope to this specific mint.
3. Checks usedMessages[env.messageHash] == false — replay protection uses the envelope's canonical ID, identical across v1/v2.
4. Marks usedMessages[env.messageHash] = true and mints / releases.

4. Threat model

The Warp 2.0 envelope is post-quantum agile: a single failure mode does not produce a forgery.

Attack	Mitigation
secp256k1 break (today's oracle EIP-712 model)	N/A — no ECDSA in the envelope path
BLS12-381 break (quantum)	Beam alone is insufficient; ML-DSA + Pulse must also verify
ML-DSA break (lattice cryptanalysis vs. FIPS 204)	Per-validator signatures alone are insufficient; Beam + Pulse must verify
Pulsar lattice break	Threshold pulse alone is insufficient; Beam + ML-DSA must verify
Validator set takeover (>quorum)	Same residual trust as v1 BLS quorum (LP-075); the PQ lanes do not lower this bar
Replay across chains	messageHash includes (sourceChainId, destChainId)
Replay within a chain	usedMessages[messageHash] + monotonic nonce
Cross-version reuse	Warp 1.x bytes do not parse as v2 (leading 0x02 mismatch) — see envelope.go line 88-95

The destination-chain BridgeV2 deployer chooses the policy via IWarp2Verifier config: requireBeam, requireCertSet, requirePulse. For high-value assets (BTC, ETH custodied via M-Chain MPC), all three are required. For low-value or test assets, Beam-only is allowed during the migration window.

5. M-Chain custody

For external chains (BTC, ETH, SOL, …) the underlying private material is held in M-Chain threshold custody (per LP-134 / LP-7330 T-Chain ThresholdVM in the lp-6332 family). M-Chain holds the per-asset MPC key share set; Teleport never sees the raw key. The Warp 2.0 envelope is the authorisation that M-Chain releases the underlying asset (or that the destination wrapped-asset contract mints).

This separates two distinct trust surfaces:

• Warp 2.0 envelope — proves the Lux validator set saw a valid burn on the source chain (cross-chain message authentication).
• M-Chain custody — proves the released funds match the authorised amount (per-asset key custody).

Teleport composes both: the envelope is consumed by BridgeV2.claim, which then either mints a wrapped token (no M-Chain interaction) or calls into the M-Chain T-Chain for an external-asset release.

6. Migration path

1. Phase 1 (current): Bridge.sol (EIP-712 MPC oracle). BridgeV2.sol is deployed alongside as opt-in.
2. Phase 2: Migrate Beam-only — BridgeV2 accepts envelopes with only the BLS aggregate populated (PQ lanes empty). This is functionally equivalent to Warp 1.x with quorum-based authorisation instead of single-oracle ECDSA.
3. Phase 3: Enable ML-DSA cert set verification. Validators begin signing with their FIPS 204 keys; the cert set lane is required.
4. Phase 4: Enable Pulsar Pulse verification (requires Lux EVM precompile, LP-2312). All three lanes mandatory.
5. Phase 5: Decommission Bridge.sol. Disable token allowlist on v1 and migrate residual TVL.

The on-chain verifier IWarp2Verifier is a precompile dispatcher — the actual ML-DSA / Pulsar verification happens inside the Lux EVM (LP-2517 / LP-2312). On non-Lux destination chains (Ethereum, Arbitrum, Base) the precompile is replaced by a Solidity-only verifier of the Beam lane plus a ZK rollup of the cert set (Z-Chain Groth16 proof bundling per LP-105 §"HorizonCertificate").

7. References

• github.com/luxfi/warp — Warp 1.x + 2.0 protocol implementation
• github.com/luxfi/warp/envelope.go — EnvelopeV2 wire format
• github.com/luxfi/warp/pulsar — Pulse path (Pulsar threshold)
• github.com/luxfi/pulsar — Pulsar lattice kernel
• LP-021v2 — Warp 2.0 hybrid envelope (vocabulary in LP-105)
• LP-070 — ML-DSA-65 (FIPS 204) signatures
• LP-073 — Pulsar lattice threshold kernel
• LP-075 — BLS12-381 aggregate (Beam)
• LP-105 — Lux Stack Lexicon (Beam, Pulse, Prism, Horizon)
• LP-118 — Warp signature aggregation protocol
• LP-110 — Quasar consensus (triple BLS + Pulsar + ML-DSA)
• LP-6332 — Teleport bridge architecture (this upgrade fits in here)
• LP-6331 — B-Chain BridgeVM specification
• LP-7330 — T-Chain ThresholdVM (M-Chain custody)
• FIPS 203 — ML-KEM (post-quantum KEM, used for transport)
• FIPS 204 — ML-DSA (post-quantum signature)
• FIPS 205 — SLH-DSA (hash-based PQ signature; not used in Warp 2.0 but referenced for completeness in the Lux PQ stack)