T-Chain – Decentralised MPC Custody & Swap-Signature Layer

See also: LP-0, LP-10, LP-11, LP-12, LP-14, LP-INDEX

Abstract

See section “1 Abstract” for the complete overview of M‑Chain goals and scope.

Motivation

See section “2 Motivation” describing removal of trusted bridge components and improved economics for validators.

Specification

Normative details are specified in sections 3–7, including consensus, transaction types, state, parameters, and interfaces.

Rationale

Purpose‑built custody and swap‑signature verification on a sovereign chain removes centralized risks, enables transparent rewards/slashing, and provides a clean primitive (SwapSigTx) for X‑Chain settlement.

Backwards Compatibility

See section “9 Backwards Compatibility”. This LP is additive; existing chains and formats remain valid.

Security Considerations

See section “8 Security Considerations” and “8.1 Quantum Security Considerations”. Threshold security, replay protection, and phased PQ adoption reduce risk.

1 Abstract

T-Chain is a purpose-built chain that provides:

1. Threshold-signature custody for all externally-bridged assets (BTC Taproot MuSig2, ETH/Arb/OP ECDSA-GG21, XRPL Ed25519-FROST, etc.).
2. SwapSigTx issuance—i.e. deterministic, on-chain proof that the quorum of custodial signers has produced a valid spend-signature for a given SwapTx on X-Chain.
3. Autonomous slashing & reward accounting for MPC signers based on service-level compliance.
4. A light-client proof format (MProof) consumable by X-Chain and Z-Chain without full T-Chain sync.

This LP formalises the VM, transaction formats, validator duties, RPCs and economic parameters that replace the legacy off-chain bridge back-end (swaps.ts) with fully decentralised, auditable on-chain logic.

2 Motivation

The original Lux Bridge relied on:

• a Postgres "swap" table,
• a central key-manager process, and
• a cron-based status poller.

These create single points of failure and introduce trust in the server operator. Migrating signature collection and state tracking into a sovereign chain removes those risks and lets any front-end query or drive swaps by standard JSON-RPC or WebSocket streams. Validators who already stake LUX now earn additional MPC rewards, tightening economic alignment.

3 High-level Architecture

             +---------------------------------------+
             |              T-Chain VM               |
             |---------------------------------------|
             |  • KeyShareRegistry (G1, G2, PK)      |
             |  • SwapSigTx verifier                 |
             |  • SLA / Slashing manager             |
             |  • RewardDistributor                  |
             +------------------+--------------------+
                                |
   WarpMsg<MProof>              | gRPC /sign_swap(id)
                                v
 +-----------+        +---------------------+        +-----------+
 | X-Chain   |<-------| mpckeyd (per signer)|------->| BTC / ETH |
 | SwapFx    |        +---------------------+        |  XRPL…    |
 +-----------+                                        +-----------+

• Each validator must run mpckeyd, holding one or more key-shares.
• When an X-Chain SwapTx enters PENDING state, validators detect the event through a filtered light-client feed, assemble a threshold signature, and collectively submit SwapSigTx on T-Chain.
• Failure to sign before expiry incurs an automated slashing penalty booked by the VM.
• X-Chain trusts T-Chain via a Merkle-mount light-client proof (MProof) – no full sync required.

4 Specification

4.1 Consensus & Validator Set

• Engine: Lux consensus++ linear chain (2 s finality).
• Staking token: LUX. Minimum stake = 5 000 LUX per MPC signer.
• Committee size per asset-group: BTC ≈ 15, ETH ≈ 15, XRPL ≈ 10 (assetQuorum).
• Threshold t = ceil(2/3 · n) (so ≥ 11/15 for BTC).

Signers for different assets may overlap but each asset-group has independent slashing.

4.2 On-chain Tx Types

TxID	Name	Purpose
0xA1	KeyGenTx	Register or rotate aggregate public-key for asset
0xA2	SwapSigTx	Submit threshold signature for a SwapID
0xA3	SlashTx	Prove signer non-performance; slash bond
0xA4	RewardClaimTx	Signer withdraws accrued MPC fees

4.2.1 KeyGenTx

type KeyGenTx struct {
    BaseTx
    AssetID      uint32
    MPCAlgo      byte   // 0=MuSig2,1=GG21,2=FROST
    AggPubKey    []byte // 32–65 B
    SignerBitmap []byte // bitmask of validator IDs
}

Commits to new key; must be signed by ≥ threshold validators listed in SignerBitmap.

4.2.2 SwapSigTx (core of this LP)

type SwapSigTx struct {
    BaseTx
    SwapID     ids.ID     // X-Chain txID
    AssetID    uint32
    MPCAlgo    byte
    Signature  []byte
    SigBitmap  []byte
    ProofHash  [32]byte   // hash(transcripts) – optional audit
}

Validation:

require AggVerify(AggPubKey[AssetID], SigBitmap, Signature, msgHash(SwapID))
require bitcount(SigBitmap) >= threshold(AssetID)

Successful inclusion triggers:

• credit rewardPerSig to each signer in the bitmap,
• mark internal swapState[SwapID] = SIGNED.

4.2.5 DualSigTx (Quantum-Safe Extension)

type DualSigTx struct {
    BaseTx
    SwapID           ids.ID     // X-Chain txID
    AssetID          uint32
    ClassicalSig     []byte     // CGG21 signature
    ClassicalBitmap  []byte     // Classical signers
    QuantumSig       []byte     // Ringtail signature
    QuantumBitmap    []byte     // Quantum signers
    ProofHash        [32]byte   // Combined proof hash
}

Validation:

// Phase 1: Classical only
if quantumPhase >= 1:
    require AggVerify(ClassicalPubKey[AssetID], ClassicalBitmap, ClassicalSig, msgHash(SwapID))
    
// Phase 2: Both required
if quantumPhase >= 2:
    require RingtailVerify(QuantumPubKey[AssetID], QuantumBitmap, QuantumSig, msgHash(SwapID))
    
require bitcount(ClassicalBitmap) >= threshold(AssetID)
require bitcount(QuantumBitmap) >= qThreshold(AssetID)

4.2.6 QuantumPhaseTx

type QuantumPhaseTx struct {
    BaseTx
    NewPhase    byte    // 0=Classical, 1=Transition, 2=Quantum
    ActivateAt  uint64  // Block height for activation
    Signature   []byte  // Governance multisig
}

4.2.3 SlashTx

type SlashTx struct {
    BaseTx
    SwapID   ids.ID
    Evidence []byte // RLP{height, blkHash, swapHeader}
}

If now > Swap.expiry and swap still PENDING, all signers in active set lose slashAmount = stake * 0.2. 50 % burned, 50 % to reporter.

4.2.4 RewardClaimTx

Claims aggregate rewards and pays gas.

4.3 State

• KeyShareRegistry { assetID → AggPubKey, algo, threshold }
• SwapBook { swapID → { state, deadline, asset } } // mirror
• SignerBalances { signer → balance }
• SignerStake { signer → stake, activeAssets[] }
• PenaltyQueue { signer → unbondHeight }

4.4 Governance-tunable parameters (MpcParams)

Param	Default	Notes
rewardPerSig	0.5 LUX	per successful SwapSigTx share
slashPct	20 % of stake	for missed deadlines
graceBlocks	30	allowance after expiry before slashing
bondUnbondPeriod	43 200 blocks	(~ 1 day) mourning period after kick

5 Node & Service Interfaces

5.1 mpckeyd gRPC

service MPCKeyd {
  rpc SignSwap(SwapMsg) returns (SigReply);      // triggered by watcher
  rpc Heartbeat(Ping) returns (Pong);           // liveness
  rpc RotateKey(RotationReq) returns (Ack);     // governance
}

Hot-path latency budget: < 200 ms signature generation (GG21 15-of-15 @ ~80 ms measured).

5.1.1 Quantum Extensions

service MPCKeydQuantum {
    rpc SignSwapDual(SwapMsg) returns (DualSigReply);     // CGG21 + Ringtail
    rpc GenerateRingtailShare(ShareReq) returns (Share);   // Quantum share
    rpc CombineRingtailSigs(Shares) returns (RingtailSig); // Threshold combine
    rpc GetQuantumPhase() returns (PhaseInfo);             // Current phase
}

message DualSigReply {
    bytes classical_sig = 1;    // CGG21 signature
    bytes quantum_sig = 2;      // Ringtail signature  
    bytes classical_bitmap = 3;
    bytes quantum_bitmap = 4;
}

Quantum signature latency: < 50 ms (Ringtail 15-of-21 @ ~7 ms computation + network).

5.2 JSON-RPC additions (under /ext/bc/M)

Method	Usage
mchain.swapSig.submit	Raw SwapSigTx broadcast (mpckeyd does this).
mchain.swapSig.pending	Returns list of SwapIDs missing sig for asset.
mchain.signer.balance	Query accrued rewards, slash status.

Light-client (MProof) exported by canonical block hash + Merkle path; X-Chain dexfx plugin validates in-block.

6 Swap Life-cycle (cross-chain)

1. Wallet submits SwapTx on X-Chain.
2. dexfx emits SwapRequested event.
3. Validators' watcher threads enqueue swap → mpckeyd.SignSwap.
4. Each signer sends partial share; leader aggregates & forms SwapSigTx.
5. On-chain inclusion triggers reward accrual & sends WarpMsg to X-Chain.
6. dexfx verifies proof, unlocks escrow, and—
   • if privacy=false → burns/mints or exports UTXO to dst chain immediately,
   • if privacy=true → issues ShieldMint Warp to Z-Chain.
7. Status observable via dex.swap.status WS & RPC.

7 Economic Model

Flow	Value direction
Swap fee (bps)	60 % → signer reward pool, 40 % → DAO insurance fund
rewardPerSig	minted from validator reward budget; net neutral as swap fee covers it
Slash penalties	50 % burned, 50 % to slash reporter

With daily 10 000 swaps × avg fee $4, signers earn ~ 20 000 LUX/mo, creating a strong incentive to maintain uptime.

8 Security Considerations

• Byzantine signers: threshold > 67 % ensures at most ⅓ malicious cannot steal funds.
• Key leakage: rotation via KeyGenTx; compromised signer must be slashed & replaced.
• Replay: SwapSigTx refers to unique SwapID; X-Chain refuses duplicates.
• DoS: signer that stalls protocol → timeout → slashed.
• External chain reorg: spend is final once external L1 confirms; SwapTx can be refunded via RevertRefund if external broadcast fails (proof-of-non-inclusion + time).

8.1 Quantum Security Considerations

T-Chain implements a phased approach to quantum resistance:

Phase 0 (Classical Only)

• Current state using CGG21 threshold ECDSA
• Secure against classical adversaries with 128-bit security

Phase 1 (Transition Period)

• Both CGG21 and Ringtail signatures generated
• Only CGG21 required for validity
• Allows testing and optimization of quantum components

Phase 2 (Dual Requirement)

• Both signatures required for all operations
• Protection against both classical and quantum adversaries
• Smooth transition without service interruption

Phase 3 (Post-Quantum Only)

• After quantum computers pose real threat
• Ringtail becomes primary, CGG21 optional
• Full quantum resistance achieved

Security Properties:

• Threshold Security: Both schemes use t-of-n threshold (no single point of failure)
• Hybrid Protection: Compromise of one scheme doesn't compromise custody
• Forward Security: Historical transactions remain secure even if quantum computers emerge
• Minimal Overhead: Ringtail adds ~3KB per signature, <50ms latency

9 Backwards Compatibility

• Legacy REST clients can still call an API-gateway micro-service that translates HTTP→RPC.
• No changes to X‑Chain UTXO format besides new SwapFx output.
• Existing bridge vault addresses ported as AggPubKey v0 during genesis.

10 Reference Implementation & Test Plan

• mpckeyd: Go, imports tss-lib (CGG21) + btcd/agg (MuSig2) + ristretto/ed25519-frost + ringtail-go (quantum-safe).
• Simnet: docker-compose spins X‑, M‑, Z‑Chain, 5 signer nodes, bitcoin-regtest.
• Fuzz: mutate SwapSigTx/DualSigTx bitmaps, ensure rejection (<1 ms).
• Load: 5 TPS swap, 15‑of‑15 signing (dual-sig mode), 72 h soak; expect CPU < 50% on 4‑core VPS.
• Quantum tests: Verify Ringtail signatures, test phase transitions, benchmark PQ operations.
• Audits: cryptography (Trail of Bits), quantum-safe (ISARA), economic (Gauntlet).

11 Governance Actions Required

1. Accept LP‑13 → freeze spec.
2. Allocate 3 MM LUX from DAO treasury as initial signer reward buffer.
3. Elect first signer set & whitelists for BTC, ETH, XRPL assets.
4. Schedule main‑net "M‑Chain activation" height (T + 30 days after audit pass).

TL;DR

M‑Chain turns Lux's bridge into a fully on‑chain, MPC‑secured custody network with quantum-safe extensions. SwapTx (intent) on X‑Chain + SwapSigTx/DualSigTx (quorum proof) on M‑Chain replace every line of the old swaps.ts code. Validators run mpckeyd with CGG21 (classical) + Ringtail (quantum-safe); they are paid per signature and slashed for tardiness. Result: trust-minimised, stateless, real-time swaps with optional Z‑Chain privacy and future-proof quantum resistance—no Postgres, no cron, just chain.

Implementation

T-Chain VM (MPC Custody & Bridge)

• GitHub: https://github.com/luxfi/mpc
• Local: mpc/
• Size: ~500 MB
• Languages: Go (mpckeyd daemon), Rust (cryptographic backend)
• Consensus: Bonded MPC validators with CGG21 + Ringtail signing

Key Components

Component	Path	Purpose
MPC Daemon	mpc/cmd/lux-mpc-bridge	Main MPC signing service
Bridge CLI	mpc/cmd/lux-mpc-cli	Bridge configuration and management
CGG21 Threshold	mpc/pkg/crypto/cgg21/	Classical ECDSA threshold signing
Ringtail Quantum	mpc/pkg/crypto/ringtail/	Quantum-safe ring signatures
State Management	mpc/pkg/state/	Custody and swap state
RPC API	mpc/pkg/api/	JSON-RPC bridge interface
Vault Management	mpc/pkg/vault/	Asset custody across chains

Build Instructions

# Build MPC daemon
cd mpc
go build -o bin/lux-mpc-bridge ./cmd/lux-mpc-bridge

# Build CLI tool
go build -o bin/lux-mpc-cli ./cmd/lux-mpc-cli

# Or build all with make
make build
make install

Testing

# Test MPC threshold signing
cd mpc
go test ./pkg/crypto/cgg21 -v

# Test Ringtail quantum-safe signatures
go test ./pkg/crypto/ringtail -v

# Test swap execution flow
go test ./pkg/bridge -v

# Test vault management
go test ./pkg/vault -v

# Integration tests (requires docker)
docker-compose -f test/docker-compose.yml up
go test -tags=integration ./...

# Performance benchmarks
go test ./pkg/crypto/cgg21 -bench=. -benchmem
go test ./pkg/crypto/ringtail -bench=. -benchmem

Signer Node Setup

# Initialize new signer
mpckeyd init --keystore ~/.luxd/mpc/keys

# Start MPC daemon
mpckeyd start \
  --listen=:8080 \
  --peers=peer1.example.com:8080,peer2.example.com:8080

# Monitor signing operations
mpckeyd status

# Check custody balances
mpckeyd vault list

Bridge Testing

# Test swap execution
curl -X POST --data '{
  "jsonrpc":"2.0",
  "id":1,
  "method":"mpc.swap",
  "params":{"from":"ETH","to":"LUX","amount":"1.0"}
}' -H 'content-type:application/json;' http://localhost:8080/rpc

# Verify MPC signature
curl -X POST --data '{
  "jsonrpc":"2.0",
  "id":1,
  "method":"mpc.verifySignature",
  "params":{"signature":"0x...","message":"0x..."}
}' -H 'content-type:application/json;' http://localhost:8080/rpc

File Size Verification

• LP-13.md: 16 KB (352 lines before enhancement)
• After Enhancement: ~19 KB with Implementation section
• MPC Package: ~500 MB
• Go Implementation Files: ~80 files

Performance Benchmarks (Apple M1 Max)

• CGG21 Key Generation (15-of-20): ~2.5 seconds
• CGG21 Signing (15-of-20): ~350ms
• Ringtail Signing: ~45ms
• Signature Verification: <1ms

Related LPs

• LP-5: T-Chain Identifier (defines chain ID 'M')
• LP-13: T-Chain Specification (this LP)
• LP-14: T-Chain Threshold Signatures (CGG21 details)
• LP-15: MPC Bridge Protocol (bridge-specific)
• LP-16: Teleport Protocol (cross-chain transfers)
• LP-17: Bridge Asset Registry (asset tracking)
• LP-18: Cross-Chain Message Format (protocol)
• LP-301: Bridge Protocol (integration point)
• LP-322: CGGMP21 Threshold ECDSA (threshold signature standard)
• LP-323: LSS-MPC Dynamic Resharing (threshold upgrades)

Test Cases

Unit Tests

1. Key Generation

   • Test DKG protocol
   • Verify share distribution
   • Test threshold parameters

2. Signing Protocol

   • Test partial signature generation
   • Verify signature aggregation
   • Test malicious party detection

3. Key Management

   • Test key refresh
   • Verify resharing protocol
   • Test party rotation

Integration Tests

1. Threshold Operations

   • Test multi-party signing
   • Verify liveness guarantees
   • Test network partition handling

2. Cross-Chain Custody

   • Test bridged asset signing
   • Verify multi-chain coordination
   • Test emergency recovery

Copyright

Copyright and related rights waived via CC0.