Implementation status (code-audited 2026-07-03): SHIPPED SigTypes, PQ-lane params, ML-KEM-768 + AES-GCM, and the 7 TeleportMessage types confirmed (node/vms/platformvm/warp/teleport.go, signature.go); the shipped PQ signature lane is Corona (Ringtail, eprint 2024/1113 — signature.go:175-177).

Canonical naming (per LP-134). Chain roles: MPC / threshold custody → M-Chain (MVM, LP-7100); FHE → F-Chain (FVM, LP-8200); teleport / cross-chain messaging → B-Chain (bridgevm, LP-6000). Teleport is the protocol B-Chain runs. See the migration map LP-7050.

LP-603: Warp 1.5 - Quantum-Safe Cross-Chain Messaging

TL;DR

Warp 1.5 upgrades Lux cross-chain messaging to be quantum-safe:

• Corona signatures replace BLS for post-quantum security
• ML-KEM-768 encryption for confidential messages
• Teleport protocol standardizes 7 cross-chain operation types
• Backward compatible with Warp 1.0 (BLS still supported during transition)

Source Chain → [Create TeleportMessage] → [Sign with Corona] → Warp Layer → Destination Chain
                     ↓                           ↓
              (optional encrypt)         (2/3 validator threshold)

---

Prerequisites

Before reading this LP, you should understand:

Concept	Description	Reference
Warp 1.0	Basic cross-chain messaging with BLS	LP-602
BLS Signatures	Aggregatable signatures using bilinear pairings	-
Threshold Signatures	t-of-n signing without reconstructing full key	LP-7100
Post-Quantum Crypto	Cryptography resistant to quantum computers	LP-4

Related LPs:

• LP-7100 - M-Chain (MVM) for MPC signing
• LP-331 - BridgeVM (B-Chain) orchestration
• LP-332 - Teleport architecture
• LP-333 - LP-333 signer management

---

Abstract

This proposal specifies Warp 1.5, a major upgrade to Lux's cross-chain messaging protocol that introduces post-quantum security through Corona lattice-based threshold signatures (Ringtail-derived, eprint 2024/1113; earlier revisions of this LP misnamed this lane "Pulsar" — Pulsar is the separate FIPS 204 byte-equal threshold ML-DSA scheme, LP-4450) and ML-KEM-768 key encapsulation. Warp 1.5 maintains backward compatibility with existing BLS-based signatures while providing a migration path to full quantum resistance. The upgrade includes the Teleport high-level protocol for standardized cross-chain operations (transfers, swaps, attestations, governance, private transfers) and integrates with BridgeVM (B-Chain) and M-Chain (MVM) for MPC-based signing.

---

Motivation

The Quantum Threat

Quantum computers threaten all classical cryptography used in blockchains:

Algorithm	Quantum Attack	Impact
ECDSA	Shor's algorithm	Private keys recoverable in polynomial time
BLS	Shor's algorithm	Signatures forgeable
RSA	Shor's algorithm	Completely broken
AES-256	Grover's algorithm	Reduced to 128-bit security (still safe)

Timeline: NIST estimates cryptographically relevant quantum computers by 2030-2035. We must migrate NOW.

Current State (Warp 1.0)

Warp 1.0 uses BLS aggregate signatures:

• ✅ Compact 96-byte signatures
• ✅ Efficient verification
• ❌ Completely broken by quantum computers

Warp 1.5 Solution

Three cryptographic upgrades:

1. Corona Signatures - LWE-based threshold signatures
2. ML-KEM-768 Encryption - NIST FIPS 203 key encapsulation
3. AES-256-GCM - Symmetric encryption (quantum-safe with 128-bit security)

---

Glossary

Term	Definition
LWE	Learning With Errors - hard mathematical problem underlying post-quantum crypto
Ring-LWE	Variant of LWE using polynomial rings for efficiency
Corona	LWE-based threshold signature scheme with native t-of-n support
ML-KEM	Module-Lattice Key Encapsulation Mechanism (NIST FIPS 203)
KEM	Key Encapsulation Mechanism - asymmetric crypto for key exchange
Threshold Signature	Signature requiring t-of-n parties without reconstructing full key
Teleport	High-level cross-chain messaging protocol built on Warp
Warp	Low-level cross-chain message format with validator signatures

---

How It Works: End-to-End Flow

Standard Cross-Chain Transfer

┌─────────────────────────────────────────────────────────────────────────────┐
│                         CROSS-CHAIN TRANSFER FLOW                           │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  1. USER INITIATES TRANSFER                                                 │
│     ┌──────────────────────────────────────────────────────────────┐        │
│     │ User: "Send 100 LUX from C-Chain to Ethereum"                │        │
│     └──────────────────────────────────────────────────────────────┘        │
│                              ↓                                              │
│  2. CREATE TELEPORT MESSAGE                                                 │
│     ┌──────────────────────────────────────────────────────────────┐        │
│     │ TeleportMessage {                                            │        │
│     │   MessageType: TeleportTransfer                              │        │
│     │   SourceChain: C-Chain                                       │        │
│     │   DestChain:   Ethereum                                      │        │
│     │   Payload:     {AssetID, Amount, Sender, Recipient}          │        │
│     │ }                                                            │        │
│     └──────────────────────────────────────────────────────────────┘        │
│                              ↓                                              │
│  3. SIGN WITH VALIDATORS (Corona threshold)                               │
│     ┌──────────────────────────────────────────────────────────────┐        │
│     │                    BridgeVM (B-Chain)                        │        │
│     │  ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐                    │        │
│     │  │ V1  │ │ V2  │ │ V3  │ │ V4  │ │ V5  │  ... (up to 100)   │        │
│     │  └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘ └──┬──┘                    │        │
│     │     │       │       │       │       │                        │        │
│     │     └───────┴───────┼───────┴───────┘                        │        │
│     │                     ↓                                        │        │
│     │           M-Chain (MVM)                              │        │
│     │           [Corona t-of-n signing]                          │        │
│     │           Needs 67% validators to sign                       │        │
│     └──────────────────────────────────────────────────────────────┘        │
│                              ↓                                              │
│  4. WARP MESSAGE CREATED                                                    │
│     ┌──────────────────────────────────────────────────────────────┐        │
│     │ WarpMessage {                                                │        │
│     │   Message: [TeleportMessage bytes]                           │        │
│     │   Signature: CoronaSignature {                             │        │
│     │     Signers: [bitset of who signed]                          │        │
│     │     Signature: [~3-5KB Corona sig]                         │        │
│     │   }                                                          │        │
│     │ }                                                            │        │
│     └──────────────────────────────────────────────────────────────┘        │
│                              ↓                                              │
│  5. VERIFY ON DESTINATION                                                   │
│     ┌──────────────────────────────────────────────────────────────┐        │
│     │ Ethereum Bridge Contract:                                    │        │
│     │ 1. Verify Corona signature against Lux validator set       │        │
│     │ 2. Check 67%+ weight threshold                               │        │
│     │ 3. Execute: Mint 100 wrapped LUX to recipient                │        │
│     └──────────────────────────────────────────────────────────────┘        │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

Private Transfer (Encrypted)

┌─────────────────────────────────────────────────────────────────────────────┐
│                      PRIVATE (ENCRYPTED) TRANSFER                           │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  1. ENCRYPT PAYLOAD                                                         │
│     ┌───────────────────────────────────────────────────────────────┐       │
│     │                                                               │       │
│     │  Plaintext ──► ML-KEM-768 ──► Shared Secret ──► AES-256-GCM  │       │
│     │  Payload        Encapsulate     (32 bytes)       Encrypt      │       │
│     │                                                               │       │
│     │  Result: EncryptedWarpPayload {                               │       │
│     │    EncapsulatedKey: 1088 bytes (ML-KEM ciphertext)            │       │
│     │    Nonce: 12 bytes                                            │       │
│     │    Ciphertext: [encrypted payload + 16-byte auth tag]         │       │
│     │    RecipientKeyID: [identifies recipient's ML-KEM key]        │       │
│     │  }                                                            │       │
│     └───────────────────────────────────────────────────────────────┘       │
│                              ↓                                              │
│  2. CREATE PRIVATE TELEPORT MESSAGE                                         │
│     ┌───────────────────────────────────────────────────────────────┐       │
│     │ TeleportMessage {                                             │       │
│     │   MessageType: TeleportPrivate                                │       │
│     │   Encrypted: true                                             │       │
│     │   Payload: [EncryptedWarpPayload bytes]                       │       │
│     │ }                                                             │       │
│     └───────────────────────────────────────────────────────────────┘       │
│                              ↓                                              │
│  3. SIGN & TRANSMIT (same as standard)                                      │
│                              ↓                                              │
│  4. RECIPIENT DECRYPTS                                                      │
│     ┌───────────────────────────────────────────────────────────────┐       │
│     │ ML-KEM Decapsulate → Shared Secret → AES-GCM Decrypt          │       │
│     │ Only recipient with matching private key can read payload     │       │
│     └───────────────────────────────────────────────────────────────┘       │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

---

Specification

Signature Types

Warp 1.5 defines three signature types for different security/compatibility needs:

// SignatureType indicates which signature algorithm to use
type SignatureType uint8

const (
    // SigTypeBLS uses classical BLS signatures (Warp 1.0 compatibility)
    SigTypeBLS SignatureType = iota
    // SigTypeCorona uses quantum-safe Corona signatures (recommended)
    SigTypeCorona
    // SigTypeHybrid uses BLS+Corona hybrid (deprecated)
    SigTypeHybrid
)

When to Use Each Type

Type	Use Case	Security	Size
SigTypeBLS	Legacy compatibility, small messages	Classical only	96 bytes
SigTypeCorona	New deployments (recommended)	Post-quantum	~3-5 KB
SigTypeHybrid	Migration period (deprecated)	Both	~3.1-5.1 KB

Migration Timeline

Phase	Timeline	Default	Notes
Phase 1	Current	BLS	Existing messages work unchanged
Phase 2	Q1 2025	Corona	New default for all messages
Phase 3	Q3 2025	Corona-only	BLS support deprecated

---

Corona Signature (Recommended)

Corona is a lattice-based threshold signature scheme based on Module-LWE:

// CoronaSignature is the Warp 1.5 quantum-safe signature type
type CoronaSignature struct {
    // Signers is a big-endian byte slice encoding which validators signed
    Signers []byte `serialize:"true"`

    // Signature is the Corona threshold signature
    // Contains: c (challenge polynomial), z (response vector), Delta (hint vector)
    Signature []byte `serialize:"true"`
}

Cryptographic Parameters (from github.com/luxfi/corona):

Parameter	Value	Description
Q	0x1000000004A01	48-bit NTT-friendly prime
M	8	Matrix dimension M
N	7	Matrix dimension N
Kappa	23	Hash output bound
Dbar	48	Signature dimension

Why Corona?

Aspect	Corona	ML-DSA
Threshold Support	Native 2-round	Requires complex MPC
Implementation	Simple	Complex MPC around ML-DSA
Security	LWE-based (proven)	Module-LWE (proven)
Paper	eprint.iacr.org/2024/1113	NIST FIPS 204

---

Encrypted Payload (ML-KEM + AES-256-GCM)

For confidential cross-chain messages:

// EncryptedWarpPayload provides quantum-safe encryption
type EncryptedWarpPayload struct {
    // EncapsulatedKey is the ML-KEM ciphertext (1088 bytes for ML-KEM-768)
    EncapsulatedKey []byte `serialize:"true"`

    // Nonce is the AES-GCM nonce (12 bytes)
    Nonce []byte `serialize:"true"`

    // Ciphertext is the AES-256-GCM encrypted payload (includes 16-byte auth tag)
    Ciphertext []byte `serialize:"true"`

    // RecipientKeyID identifies which ML-KEM public key was used
    RecipientKeyID []byte `serialize:"true"`
}

Constants:

const (
    MLKEM768CiphertextLen   = 1088  // ML-KEM-768 ciphertext size
    MLKEM768PublicKeyLen    = 1184  // ML-KEM-768 public key size
    MLKEM768SharedSecretLen = 32    // Shared secret size
    AESGCMNonceLen          = 12    // AES-GCM nonce size
    AESGCMTagLen            = 16    // Authentication tag size
)

Why ML-KEM-768?

Level	Algorithm	Security	Ciphertext Size
1	ML-KEM-512	128-bit	768 bytes
3	ML-KEM-768	192-bit	1088 bytes
5	ML-KEM-1024	256-bit	1568 bytes

ML-KEM-768 provides the best balance of security (192-bit post-quantum) and size.

---

Teleport Protocol

Teleport is the high-level cross-chain messaging protocol:

// TeleportMessage wraps a Warp message for cross-chain bridging operations
type TeleportMessage struct {
    Version       uint8        `serialize:"true"` // Protocol version (1)
    MessageType   TeleportType `serialize:"true"` // Operation type
    SourceChainID ids.ID       `serialize:"true"` // Source chain
    DestChainID   ids.ID       `serialize:"true"` // Destination chain
    Nonce         uint64       `serialize:"true"` // Replay protection
    Payload       []byte       `serialize:"true"` // Application data
    Encrypted     bool         `serialize:"true"` // Encryption flag
}

Message Types:

Type	Value	Description	Example Use
TeleportTransfer	0	Asset transfer	Bridge deposits/withdrawals
TeleportSwap	1	Atomic swap	Cross-chain DEX trades
TeleportLock	2	Lock assets	Bridge collateral
TeleportUnlock	3	Unlock assets	Bridge release
TeleportAttest	4	Attestation	Oracle data, price feeds
TeleportGovernance	5	Governance	DAO voting across chains
TeleportPrivate	6	Encrypted transfer	MEV protection, privacy

---

Transfer Payload

type TeleportTransferPayload struct {
    AssetID   ids.ID `serialize:"true"` // Asset being transferred
    Amount    uint64 `serialize:"true"` // Transfer amount
    Sender    []byte `serialize:"true"` // Source address
    Recipient []byte `serialize:"true"` // Destination address
    Fee       uint64 `serialize:"true"` // Bridge fee
    Memo      []byte `serialize:"true"` // Optional metadata
}

Attestation Payload

type TeleportAttestPayload struct {
    AttestationType uint8       `serialize:"true"` // What is being attested
    Timestamp       uint64      `serialize:"true"` // When created
    Data            []byte      `serialize:"true"` // Attestation data
    AttesterID      ids.NodeID  `serialize:"true"` // Who created it
}

---

Integration Architecture

BridgeVM (B-Chain)

BridgeVM orchestrates bridge operations using Teleport:

┌─────────────────────────────────────────────────────────────┐
│                      BridgeVM (B-Chain)                      │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐   │
│  │ LP-333       │    │ Teleport     │    │ Warp 1.5     │   │
│  │ Signer Set   │◄──►│ Message      │◄──►│ Signature    │   │
│  │ Management   │    │ Processing   │    │ Selection    │   │
│  └──────────────┘    └──────────────┘    └──────────────┘   │
│         │                   │                   │            │
│         ▼                   ▼                   ▼            │
│  100M LUX Bond        7 Message Types      BLS/Corona      │
│  Opt-in (first 100)   Transfer/Swap/etc    Quantum-Safe      │
│                                                              │
└─────────────────────────────────────────────────────────────┘

Key RPC Endpoints:

Method	Description
bridge_registerValidator	Opt-in as signer (LP-333)
bridge_getSignerSetInfo	Get current signer set
bridge_replaceSigner	Replace failed signer (triggers reshare)
bridge_slashSigner	Slash misbehaving signer's bond

M-Chain (MVM)

M-Chain provides MPC signing services:

┌─────────────────────────────────────────────────────────────┐
│                     M-Chain (MVM)                    │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐   │
│  │ LSS Protocol │    │ Corona     │    │ CGGMP21      │   │
│  │ (reshare)    │    │ Protocol     │    │ Protocol     │   │
│  └──────────────┘    └──────────────┘    └──────────────┘   │
│         │                   │                   │            │
│         ▼                   ▼                   ▼            │
│  Dynamic Validator     Post-Quantum        Classical         │
│  Set Changes           Threshold Sig       ECDSA             │
│                                                              │
└─────────────────────────────────────────────────────────────┘

Supported Protocols:

Protocol	Type	Use Case
LSS	Dynamic resharing	Validator set changes
Corona	Post-quantum	Warp 1.5 signatures
CGGMP21	Classical ECDSA	EVM chain signing
FROST	EdDSA	Solana, Cosmos
BLS	Aggregate	Legacy Warp 1.0

---

Code Examples

Creating a Standard Transfer

import "github.com/luxfi/node/vms/platformvm/warp"

// Create transfer payload
payload := warp.NewTransferPayload(
    assetID,
    1000000000, // 1 LUX
    senderAddr,
    recipientAddr,
    10000, // 0.00001 LUX fee
    nil,   // no memo
)
payloadBytes, _ := payload.Bytes()

// Create Teleport message
msg := warp.NewTeleportMessage(
    warp.TeleportTransfer,
    sourceChainID,
    destChainID,
    nonce,
    payloadBytes,
)

// Convert to Warp message for signing
warpMsg, _ := msg.ToWarpMessage(networkID)

Creating a Private Transfer

// Create encrypted private message
privateMsg, err := warp.NewPrivateTeleportMessage(
    sourceChainID,
    destChainID,
    nonce,
    payloadBytes,
    recipientMLKEMPubKey, // ML-KEM-768 public key
    recipientKeyID,       // Key identifier
)
if err != nil {
    return err
}

// Message is now encrypted, only recipient can decrypt
warpMsg, _ := privateMsg.ToWarpMessage(networkID)

Decrypting a Private Message

// On recipient side
if teleportMsg.Encrypted {
    plaintext, err := teleportMsg.DecryptPayload(myMLKEMPrivateKey)
    if err != nil {
        return err
    }
    // plaintext contains the original payload
}

---

Security Considerations

Threat Model

Adversary	BLS	Corona	ML-KEM
Classical	✅ Safe	✅ Safe	✅ Safe
Quantum	❌ Broken	✅ Safe	✅ Safe

Key Management

• Validators MUST secure both BLS and Corona private keys
• HSM storage recommended for production
• Key rotation via LSS resharing protocol (LP-333)

Upgrade Security

• Transition period allows fallback to BLS
• Hybrid mode provides belt-and-suspenders security
• Network upgrade coordinates cutoff timing

---

Performance

Signature Sizes

Type	Size	Notes
BLS	96 bytes	Compact, aggregatable
Corona	~3-5 KB	Variable, threshold-dependent
Hybrid	~3.1-5.1 KB	Both signatures

Verification Times (Apple M1 Max)

Operation	Time
BLS Verify	~2.5 ms
Corona Verify	~5-8 ms
ML-KEM Decapsulate	~0.2 ms
AES-GCM Decrypt	~0.01 ms

Network Impact

• Larger signatures increase block size by ~3-5KB per message
• ML-KEM ciphertext adds 1088 bytes for encrypted payloads
• Recommended: Batch multiple transfers in single message

---

Test Cases

Running Tests

# Warp package tests (30+ tests)
cd ~/work/lux/node
go test -v ./vms/platformvm/warp/...

# BridgeVM integration tests
go test -v ./vms/bridgevm/...

# M-Chain (MVM) integration tests
go test -v ./vms/mvm/...

Test Coverage

• TestCoronaSignatureNumSigners - Signer bitset encoding
• TestCoronaSignatureVerify - Signature verification
• TestEncryptWarpPayload - ML-KEM encryption
• TestEncryptedPayloadRoundTrip - Encrypt/decrypt cycle
• TestTeleportMessageValidate - Message validation
• TestTeleportBridgeIntegration - End-to-end bridge flow

---

Reference Implementation

Component	Repository	Path
Warp 1.5 Core	github.com/luxfi/node	vms/platformvm/warp/
Teleport Protocol	github.com/luxfi/node	vms/platformvm/warp/teleport.go
Signature Types	github.com/luxfi/node	vms/platformvm/warp/signature.go
BridgeVM	github.com/luxfi/node	vms/bridgevm/
M-Chain (MVM)	github.com/luxfi/node	vms/mvm/
Corona Crypto	github.com/luxfi/threshold	protocols/corona/

Git Tag: warp/v1.5.0

---

FAQ

Q: Do I need to upgrade immediately?

A: No. Warp 1.5 is backward compatible. BLS signatures continue to work. However, you should plan to migrate to Corona before Phase 3 (Q3 2025).

Q: How much larger are Corona signatures?

A: About 30-50x larger than BLS (~3-5KB vs 96 bytes). This is the tradeoff for quantum safety. For most applications, this is acceptable.

Q: Can I use encryption without Corona?

A: Yes. The ML-KEM encryption is independent of signature type. You can encrypt payloads with any signature type.

Q: What if a validator's key is compromised?

A: Use LP-333's bridge_replaceSigner to remove the compromised validator and trigger a reshare. The compromised key cannot sign new messages after removal.

Q: Is Corona NIST approved?

A: Corona is based on LWE, which is NIST-approved (ML-KEM/ML-DSA use similar assumptions). Corona specifically provides native threshold support not available in ML-DSA.

---

Rationale

Why Corona Over ML-DSA for Threshold Signatures?

ML-DSA is NIST-approved but was designed for single-signer scenarios. Converting ML-DSA to threshold form requires complex MPC protocols with significant overhead. Corona was purpose-built for threshold signing:

• Native Threshold Support: Corona's algebraic structure directly supports threshold operations without generic MPC protocols
• Two-Round Protocol: Only 2 communication rounds for distributed signing (vs. 5+ for generic threshold ML-DSA)
• Same Security Foundation: Based on Module-LWE, sharing security assumptions with NIST-approved ML-KEM and ML-DSA

Why Hybrid Mode?

The hybrid BLS+Corona approach provides:

1. Immediate Classical Security: BLS signatures provide proven security against classical adversaries
2. Future Quantum Security: Corona component provides protection against future quantum attacks
3. Graceful Migration: Validators can progressively upgrade to full quantum-safe mode
4. Backwards Compatibility: Classical clients can still verify the BLS component

Why Not ML-KEM for Key Exchange?

ML-KEM is excellent for key encapsulation but Warp messages require digital signatures (authentication), not key exchange (confidentiality). Corona provides post-quantum signatures directly.

---

Backwards Compatibility

• Warp 1.0 clients can verify BLS signatures (unchanged)
• Signature type indicated by codec type ID
• Unknown signature types rejected safely
• Upgrade path: BLS → Hybrid → Corona

---

Copyright

Copyright and related rights waived via CC0.