HIP-101: Hanzo-Lux Bridge Protocol Integration. Status Draft. Hanzo's own standard — read this before implementing against it.
This proposal specifies a lock-and-mint bridge between Hanzo's sovereign L1 chain (HIP-0024, chain ID 36963) and the Lux Network. The bridge enables bidirectional asset transfer ($AI, wrapped LUX, stablecoins, NFT model certificates) secured by a 7-of-11 multi-signature validator set drawn from both networks. It serves as the economic backbone of the AI compute marketplace, connecting Hanzo's AI execution environment to Lux's settlement and DeFi infrastructure.
The protocol defines three layers: a transport layer (cross-chain message passing with Merkle proof verification), a consensus layer (shared validator set coordination using ML-DSA-65 threshold signatures), and a settlement layer (lock-mint-burn-unlock state machine with HMM invoice integration). Together these layers provide sub-10-second bridge finality, post-quantum security from day one, and native integration with Lux's multi-consensus architecture.
This section explains the reasoning behind each major design decision. A bridge is critical infrastructure. Every choice must be justified from first principles, not by convention or convenience.
Third-party bridges like Wormhole and LayerZero introduce trust assumptions that do not match the Hanzo-Lux security model:
by third-party entities. LayerZero relies on independent oracle and relayer separation. In both cases, Hanzo and Lux must trust external parties with no stake in either network. The Hanzo-Lux bridge uses validators drawn directly from both chains, with staking requirements that align economic incentives.
opaque message buses. The Hanzo-Lux bridge has direct access to chain state on both sides: it can verify Merkle proofs against both Hanzo's state trie and Lux's C-Chain state trie without relying on external attestation.
use ML-DSA-65 (post-quantum). Adapting third-party bridges to PQC would require forking their guardian/oracle software and maintaining a custom build indefinitely. Building natively avoids this maintenance burden.
own consensus (Wormhole: ~15-20s for guardian consensus; LayerZero: variable based on oracle confirmation). The native bridge achieves 5-9 seconds end-to-end because validators are co-located with chain nodes.
(HIP-0008) that third-party bridges have no awareness of. Building natively allows the bridge to validate invoice structure, enforce settlement rules, and trigger Lux-side payment flows without external adapter contracts.
Quantum computing threatens all current bridge cryptography. ECDSA, the signature scheme used by every major bridge today, is broken by Shor's algorithm on a sufficiently large quantum computer. The question is not whether ECDSA will be broken, but when.
Bridges are especially vulnerable because they hold locked assets. A "harvest now, decrypt later" attack --- recording bridge messages today and forging signatures once quantum hardware matures --- could drain bridge vaults retroactively. Starting with ML-DSA-65 (CRYSTALS-Dilithium, FIPS 204) eliminates this attack vector entirely.
The cost of starting with PQC is larger signature sizes (~2.4 KB for ML-DSA-65 vs ~64 bytes for ECDSA) and slightly higher verification cost. Both Hanzo and Lux have ML-DSA-65 verification as a native precompile, so the on-chain cost is manageable. The off-chain cost (bandwidth for relaying signatures) is negligible given modern network speeds.
Starting post-quantum avoids the complexity of a future migration. Hybrid schemes (ECDSA + PQC) are transitional by design and add implementation surface area. Since the bridge is new infrastructure with no backward-compatibility requirement, there is no reason to support legacy cryptography.
The bridge consists of three components: on-chain vaults (one per chain), an off-chain relayer service, and the shared validator set.
Hanzo L1 (chain 36963) Bridge Validators Lux Network
┌──────────────────┐ ┌───────────────────┐ ┌──────────────────┐
│ │ Lock event │ │ Mint tx │ │
│ Lock Vault │───────────>│ Relayer Service │─────────>│ Mint Vault │
│ (Solidity) │ │ (off-chain) │ │ (C-Chain EVM) │
│ │<───────────│ │<─────────│ │
│ │ Unlock tx │ 7-of-11 ML-DSA │ Burn evt │ │
└──────────────────┘ │ threshold sigs │ └──────────────────┘
└───────────────────┘
│
┌───────────┼───────────┐
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
│Relayer 1│ │Relayer 2│ │Relayer 3│
│(leader) │ │(follower│ │(follower│
└─────────┘ └─────────┘ └─────────┘
Raft consensus for leader electionUser Hanzo L1 Relayer Validators Lux C-Chain
│ │ │ │ │
│── lock(AI, 1000) ──────>│ │ │ │
│ │── Lock event ─>│ │ │
│ │ │── verify proof ─>│ │
│ │ │ │── sign msg ────>│
│ │ │<── 7 sigs ───────│ │
│ │ │── mint(wAI) ─────────────────────>│
│ │ │ │ │── wAI to user
│<──────────── receipt ───│ │ │ │
│ │ │ │ │
│ Total time: 5-9 seconds │User Lux C-Chain Relayer Validators Hanzo L1
│ │ │ │ │
│── burn(wAI, 1000) ─────>│ │ │ │
│ │── Burn event ─>│ │ │
│ │ │── verify proof ─>│ │
│ │ │ │── sign msg ────>│
│ │ │<── 7 sigs ───────│ │
│ │ │── unlock(AI) ────────────────────>│
│ │ │ │ │── AI to user
│<──────────── receipt ───│ │ │ │| Asset | Hanzo Representation | Lux Representation | Direction | Notes | |-------|---------------------|-------------------|-----------|-------| | $AI | Native token | wAI (ERC-20 on C-Chain) | Hanzo -> Lux | Core bridge asset | | LUX | wLUX (ERC-20 on Hanzo) | Native token | Lux -> Hanzo | For staking rewards | | USDC | wUSDC (bridged) | USDC (native C-Chain) | Bidirectional | Stablecoin settlement | | USDT | wUSDT (bridged) | USDT (native C-Chain) | Bidirectional | Stablecoin settlement | | Model NFTs | ERC-721 (native) | wModel (ERC-721 C-Chain) | Hanzo -> Lux | Model certificates | | Compute Credits | ERC-1155 (native) | wCredits (ERC-1155) | Bidirectional | HMM credit tokens |
Bridge messages use canonical ABI encoding for cross-chain communication:
struct BridgeMessage {
uint256 nonce; // Monotonically increasing per-chain
uint32 sourceChainId; // 36963 (Hanzo) or Lux chain ID
uint32 destChainId; // Target chain ID
address sender; // Sender on source chain
address recipient; // Recipient on destination chain
address token; // Token address on source chain (0x0 for native)
uint256 amount; // Amount in wei (18 decimals)
bytes payload; // Optional: HMM invoice data, stake proof, etc.
uint64 timestamp; // Block timestamp of lock/burn event
bytes32 txHash; // Source transaction hash
bytes32 stateRoot; // State root of source chain at lock/burn block
}Messages are serialized as ABI-encoded bytes and signed by each validator using ML-DSA-65 (HIP-0005). The destination contract verifies that at least 7 of 11 signatures are valid before executing. The stateRoot field enables Merkle proof verification: the destination contract can verify that the lock/burn event is included in the source chain's state at the claimed block.
The bridge uses Merkle proof verification to confirm that events on the source chain actually occurred. This is stronger than simply trusting validator attestations --- it provides cryptographic proof anchored to chain state.
Source Chain State Root
│
┌──────┴──────┐
│ │
┌────┴────┐ ┌────┴────┐
│ │ │ │
┌──┴──┐ ┌──┴──┐ ...
│ │ │ │
... Lock Event
ReceiptThe verification flow:
proving the lock event is included in the block's state.
destination chain contract.
validators, (b) Merkle proof is valid against the block's receipts root, (c) at least 7-of-11 bridge validators have signed the bridge message.
This triple verification (chain consensus + Merkle proof + bridge multi-sig) provides defense in depth. An attacker must compromise source chain consensus, forge a valid Merkle proof, AND compromise 7 bridge validators simultaneously.
The bridge validator set consists of 11 members: 6 drawn from Hanzo's L1 validator set and 5 from Lux's primary network validators. This ensures neither chain has unilateral control.
validator_set:
total: 11
threshold: 7 # 7-of-11 required for any bridge operation
composition:
hanzo_validators: 6 # Top 6 by stake from Hanzo L1
lux_validators: 5 # Top 5 by stake from Lux primary network
rotation:
epoch_length: 7 days
max_rotation_per_epoch: 2 # At most 2 validators rotate per epoch
cooldown_after_rotation: 14 days # New validators cannot be rotated for 2 epochs
requirements:
min_stake_hanzo: 5000 AI # Higher than base validation (2000 AI)
min_stake_lux: 10000 LUX # Higher than base Lux validation
uptime: 99.5%
signature_scheme: ML-DSA-65
key_encapsulation: ML-KEM-768 # For validator-to-validator communicationValidator selection is determined by stake weight within each chain's validator set. Rotation occurs every 7 days, with at most 2 validators replaced per epoch to prevent sudden set changes that could compromise the bridge.
The bridge integrates with all three Lux chains, each serving a different purpose.
Hanzo operates as a sovereign L1 on the Lux Network (HIP-0024). The P-Chain manages validator registration, staking, and delegation for both the Lux primary network and all L1s including Hanzo.
The bridge reads P-Chain state to:
respective chains.
// Bridge validator eligibility check (uses luxfi packages, NOT go-ethereum)
import (
"github.com/luxfi/node/vms/platformvm"
"github.com/luxfi/node/ids"
)
func IsEligibleBridgeValidator(nodeID ids.NodeID, chainID ids.ID) (bool, error) {
validators, err := platformvm.GetCurrentValidators(chainID)
if err != nil {
return false, fmt.Errorf("fetch validators: %w", err)
}
for _, v := range validators {
if v.NodeID == nodeID && v.StakeAmount >= MinBridgeStake {
return true, nil
}
}
return false, nil
}The Lux X-Chain runs the XVM (UTXO virtual machine) for asset operations under Quasar 3.0 Nova-mode consensus. After $AI arrives on the C-Chain as wAI (ERC-20), users can export it to the X-Chain for fast UTXO-based transfers.
X-Chain integration enables:
The bridge does not interact with the X-Chain directly. It bridges to the C-Chain only. Users move assets between Lux chains using Lux's native cross-chain transfer mechanism (export/import transactions).
The C-Chain is the primary bridge endpoint on Lux. It runs the EVM and hosts:
Lux's multi-VM architecture supports custom virtual machines. The bridge leverages a lightweight AI Verification VM deployed as a Lux L1:
ai_verification_vm:
purpose: Verify AI compute proofs relayed from Hanzo
consensus: nova
chain_type: L1
capabilities:
- TEE attestation verification
- Compute invoice validation
- Model hash verification
- GPU benchmark proof checking
integration:
- Reads proofs from bridge messages (payload field)
- Writes verification results to C-Chain via cross-chain call
- Enables Lux DeFi contracts to trust Hanzo compute claimsThis VM allows Lux-side contracts to verify that compute work claimed in HMM invoices actually occurred, without trusting the bridge validators' word alone. The VM replays the TEE attestation proof and confirms the claimed GPU-hours against known hardware benchmarks.
A bridge transfer is considered final when all three conditions are met:
| Step | Chain | Expected Time | Description | |------|-------|---------------|-------------| | 1 | Source | ~1-2s | Transaction finality on source chain (Nova) | | 2 | Validators | ~3-5s | 7-of-11 validators sign the bridge message | | 3 | Destination | ~1-2s | Mint/unlock transaction finality on destination chain |
Total expected bridge time: 5-9 seconds.
The relayer waits for source chain finality (Hanzo Nova: ~2s, Lux Quasar: ~1s) before presenting the lock/burn event to the validator set. Validators independently verify the event against their own chain state before signing.
For large transfers (>100,000 AI), the elevated 9-of-11 threshold adds ~2-3 seconds to signature collection, bringing total time to 7-12 seconds.
fees:
bridge_fee: 0.1% # Of transferred amount
min_fee: 1 AI # Minimum fee regardless of amount
max_fee: 10000 AI # Cap for very large transfers
destination_gas: paid_by_user # User pays gas on destination chain
fee_distribution:
validators: 70% # Split among signing validators
protocol_treasury: 20% # Hanzo DAO treasury
insurance_fund: 10% # Emergency fund for bridge incidents
validator_rewards:
bridge_fees: denominated in $AI # Validators earn $AI for signing
lux_staking: denominated in $LUX # Lux validators also earn LUX staking rewardsTo prevent exploits, the bridge enforces rate limits:
rate_limits:
per_user:
max_per_tx: 1000000 AI # 1M AI per transaction
max_per_hour: 5000000 AI # 5M AI per hour
max_per_day: 20000000 AI # 20M AI per day
global:
max_per_hour: 50000000 AI # 50M AI per hour across all users
max_per_day: 200000000 AI # 200M AI per day across all users
cooldown:
after_large_tx: 60s # 60-second cooldown after >100k AI transfer
elevated_threshold:
amount: 1000000 AI # Transfers >1M AI require 9-of-11 sigs
threshold: 9Rate limits are configurable via governance (see Emergency Controls).
The bridge exposes a REST API for client interaction:
bridge_api:
base_url: /v1/bridge
endpoints:
POST /v1/bridge/transfer:
description: Initiate a bridge transfer
request:
sourceChain: string # "hanzo" or "lux"
destChain: string # "hanzo" or "lux"
token: string # Token address or "native"
amount: string # Amount in wei
recipient: string # Destination address
payload: bytes # Optional HMM invoice data
response:
transferId: string # Unique transfer identifier
nonce: uint256 # Bridge nonce
estimatedTime: uint64 # Estimated completion in seconds
status: string # "pending_finality"
GET /v1/bridge/status/{transferId}:
description: Query transfer status
response:
transferId: string
status: string # pending_finality | pending_signatures |
# pending_destination | completed | failed
sourceChain: string
destChain: string
amount: string
signatures: uint8 # Number of validator signatures collected
sourceTxHash: string
destTxHash: string # Populated on completion
timestamp: uint64
completedAt: uint64 # Populated on completion
POST /v1/bridge/verify:
description: Verify a bridge message and its Merkle proof
request:
message: bytes # ABI-encoded BridgeMessage
proof: bytes # Merkle proof against source state root
signatures: bytes[] # ML-DSA-65 validator signatures
response:
valid: bool
validSignatures: uint8
proofValid: bool
stateRootMatch: bool
GET /v1/bridge/validators:
description: Current bridge validator set
response:
validators: array
- nodeId: string
- chain: string # "hanzo" or "lux"
- stake: string
- publicKey: string # ML-DSA-65 public key
- uptime: float
threshold: uint8
epoch: uint64
nextRotation: uint64
GET /v1/bridge/stats:
description: Bridge statistics
response:
totalLocked: string # Total AI locked on Hanzo side
totalMinted: string # Total wAI minted on Lux side
volume24h: string # 24-hour transfer volume
transferCount24h: uint64
avgBridgeTime: float # Average bridge time in seconds
rateLimitStatus: object # Current rate limit utilizationThe bridge can be paused under the following conditions:
Requires simple majority of bridge validators (6 of 11).
3x the 7-day moving average within a 1-hour window.
24 hours, during which governance must vote to resume or extend.
total_locked_hanzo diverges from total_minted_lux by more than 0.01% (accounting for in-flight transfers), the bridge pauses for manual audit.
During a pause, no new locks or burns are processed. Pending transfers that have already been signed by validators but not yet executed on the destination chain are held in a queue and processed when the bridge resumes.
The Lock Vault is deployed on Hanzo's L1 (chain ID 36963):
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import {IMLDSA} from "./interfaces/IMLDSA.sol";
contract HanzoLockVault {
uint256 public nonce;
mapping(bytes32 => bool) public processedMessages;
mapping(address => bool) public supportedTokens;
bool public paused;
address[] public validators;
uint8 public constant THRESHOLD = 7;
uint8 public constant ELEVATED_THRESHOLD = 9;
uint256 public constant ELEVATED_AMOUNT = 1_000_000 ether;
event Locked(
uint256 indexed nonce,
address indexed sender,
address indexed token,
uint256 amount,
uint32 destChainId,
address recipient,
bytes payload
);
event Unlocked(
bytes32 indexed messageHash,
address indexed recipient,
address indexed token,
uint256 amount
);
event Paused(address indexed triggeredBy, string reason);
event Unpaused(address indexed triggeredBy);
modifier whenNotPaused() {
require(!paused, "bridge paused");
_;
}
/// @notice Lock tokens for bridging to Lux
function lock(
address token,
uint256 amount,
uint32 destChainId,
address recipient,
bytes calldata payload
) external payable whenNotPaused {
require(amount > 0, "zero amount");
require(recipient != address(0), "zero recipient");
if (token == address(0)) {
require(msg.value == amount, "incorrect native amount");
} else {
require(supportedTokens[token], "unsupported token");
IERC20(token).transferFrom(msg.sender, address(this), amount);
}
uint256 currentNonce = nonce++;
emit Locked(currentNonce, msg.sender, token, amount, destChainId, recipient, payload);
}
/// @notice Unlock tokens returning from Lux (called by relayer with validator sigs)
function unlock(
bytes calldata message,
bytes[] calldata signatures
) external whenNotPaused {
bytes32 msgHash = keccak256(message);
require(!processedMessages[msgHash], "already processed");
BridgeMessage memory bm = abi.decode(message, (BridgeMessage));
uint8 required = bm.amount >= ELEVATED_AMOUNT ? ELEVATED_THRESHOLD : THRESHOLD;
require(
_verifySignatures(msgHash, signatures) >= required,
"insufficient signatures"
);
processedMessages[msgHash] = true;
if (bm.token == address(0)) {
payable(bm.recipient).transfer(bm.amount);
} else {
IERC20(bm.token).transfer(bm.recipient, bm.amount);
}
emit Unlocked(msgHash, bm.recipient, bm.token, bm.amount);
}
function _verifySignatures(
bytes32 msgHash,
bytes[] calldata signatures
) internal view returns (uint8 validCount) {
for (uint i = 0; i < signatures.length; i++) {
// ML-DSA-65 verification via precompile (HIP-0005)
if (IMLDSA(ML_DSA_PRECOMPILE).verify(
validators[i], msgHash, signatures[i]
)) {
validCount++;
}
}
}
}The Mint Vault is deployed on Lux C-Chain. It mints wrapped tokens when assets are locked on Hanzo, and burns them when assets are returned:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;
import {ERC20Burnable} from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";
contract LuxMintVault {
mapping(bytes32 => bool) public processedMessages;
mapping(address => address) public wrappedTokens;
bool public paused;
address[] public validators;
uint8 public constant THRESHOLD = 7;
event Minted(bytes32 indexed messageHash, address indexed recipient,
address indexed wrappedToken, uint256 amount);
event Burned(uint256 indexed nonce, address indexed sender,
address indexed wrappedToken, uint256 amount,
uint32 destChainId, address recipient);
/// @notice Mint wrapped tokens (called by relayer with validator sigs)
function mint(bytes calldata message, bytes[] calldata signatures) external {
require(!paused, "bridge paused");
bytes32 msgHash = keccak256(message);
require(!processedMessages[msgHash], "already processed");
require(_verifySignatures(msgHash, signatures) >= THRESHOLD, "insufficient sigs");
processedMessages[msgHash] = true;
BridgeMessage memory bm = abi.decode(message, (BridgeMessage));
address wrappedToken = wrappedTokens[bm.token];
require(wrappedToken != address(0), "no wrapped token");
uint256 fee = _calculateFee(bm.amount);
uint256 netAmount = bm.amount - fee;
WrappedToken(wrappedToken).mint(bm.recipient, netAmount);
WrappedToken(wrappedToken).mint(feeCollector, fee);
emit Minted(msgHash, bm.recipient, wrappedToken, netAmount);
}
/// @notice Burn wrapped tokens to unlock on Hanzo
function burn(address wrappedToken, uint256 amount,
uint32 destChainId, address recipient) external {
require(!paused, "bridge paused");
require(amount > 0, "zero amount");
ERC20Burnable(wrappedToken).burnFrom(msg.sender, amount);
emit Burned(nonce++, msg.sender, wrappedToken, amount, destChainId, recipient);
}
function _calculateFee(uint256 amount) internal pure returns (uint256) {
uint256 fee = (amount * 10) / 10000; // 0.1%
if (fee < 1 ether) return 1 ether; // min 1 AI
if (fee > 10000 ether) return 10000 ether; // max 10k AI
return fee;
}
}The relayer is an off-chain service that monitors both chains and coordinates the validator set:
relayer:
architecture: event-driven, stateless with respect to bridge balances
redundancy:
instances: 3 # Active-active with Raft leader election
failover: < 10s # Automatic leader promotion
components:
chain_monitor:
- watches Hanzo L1 for Lock events via WebSocket subscription
- watches Lux C-Chain for Burn events via WebSocket subscription
- confirms finality (waits for Nova acceptance) before relaying
- constructs Merkle proofs from source chain receipt tries
validator_coordinator:
- presents events + Merkle proofs to validator set
- collects ML-DSA-65 signatures via encrypted channels (ML-KEM-768)
- submits signed messages to destination chain
- retries failed submissions with exponential backoff
anomaly_detector:
- tracks transfer volume (1h, 24h, 7d rolling windows)
- triggers pause if volume exceeds 3x 7-day moving average
- monitors balance divergence between locked and minted totals
- flags suspicious validator signing patterns
- alerts operators via webhook (PagerDuty, Slack)
rate_limiter:
- enforces per-user and global rate limits
- maintains cooldown timers per address
- escalates threshold for large transfersThe relayer is stateless with respect to bridge balances. All state lives in the on-chain contracts. If all relayer instances fail, the bridge pauses. No funds are at risk because the lock vault holds all assets and only releases them upon valid multi-sig authorization.
The bridge carries compute invoice settlement messages from HMM (HIP-0008). When a compute job completes on Hanzo:
message payload field.
struct ComputeInvoice {
bytes32 jobId; // Unique job identifier
address provider; // Compute provider address
address consumer; // Consumer address
uint256 cost; // Cost in $AI (18 decimals)
uint64 gpuHours; // GPU-hours consumed
uint64 tokensProcessed; // Tokens processed (inference)
bytes32 modelHash; // Hash of model used
bytes attestation; // TEE attestation proof
}The compute marketplace operates as a cycle:
Lux-side balance or relaying payment to Hanzo.
The bridge is not an accessory to the compute marketplace. It is the economic backbone that connects staking (Lux) to compute allocation (Hanzo) to settlement (Lux).
Validator rotation follows a controlled schedule:
recalculated based on stake weight.
significantly, only 2 slots rotate. At least 9 of 11 validators persist across any single epoch.
incoming validators. Destination contracts update their validator registries only upon receiving a valid rotation message signed by the current 7-of-11 set.
Any bridge validator or staked observer can challenge a transfer within 30 minutes of the mint/unlock transaction on the destination chain. A challenge asserts that the source-chain event is invalid (e.g., a forged Merkle proof or a reorged source block).
challenge_period:
duration: 30 minutes
bond: 100 AI # Challenger must post bond
resolution:
- If challenge succeeds: transfer is reversed, challenger receives bond back
plus a reward from the insurance fund.
- If challenge fails: bond is forfeited to the insurance fund.
dispute_resolution:
- Re-verify Merkle proof against source chain state.
- Check source chain for block reorgs since the original verification.
- 9-of-11 validator vote on dispute outcome.In practice, challenges are expected to be extremely rare because the triple verification (chain consensus + Merkle proof + multi-sig) makes forgery prohibitively expensive.
Large transfers receive additional scrutiny:
queue until the next hour window.
The relayer maintains rolling volume statistics:
if volume_1h > 3 * avg_volume_7d:
trigger emergency_pause
alert operators
require governance_vote to resumeAdditional anomaly signals:
Lux by more than 0.01%, the bridge pauses for manual audit.
physically possible given network latency, flag for investigation.
All bridge signatures use ML-DSA-65 (CRYSTALS-Dilithium, FIPS 204) as specified in HIP-0005. This applies to:
The bridge does not support legacy ECDSA signatures. This is deliberate: the bridge is new infrastructure with no backward-compatibility requirement. Starting with ML-DSA-65 avoids the complexity of a hybrid transition.
Key encapsulation for validator-to-validator communication (during signature coordination) uses ML-KEM-768, also per HIP-0005. Key sizes:
| Algorithm | Public Key | Signature/Ciphertext | Security Level | |-----------|-----------|---------------------|----------------| | ML-DSA-65 | 1,952 bytes | 3,293 bytes | NIST Level 3 (AES-192 equivalent) | | ML-KEM-768 | 1,184 bytes | 1,088 bytes | NIST Level 3 (AES-192 equivalent) |
Before mainnet deployment, the bridge contracts must undergo:
invariant: total_locked_hanzo == total_minted_lux at all times (within 0.01% tolerance for in-flight transactions).
create arbitrage opportunities or denial-of-service vectors.
(simulated validator failures, network partitions, volume spikes).
pause/unpause, elevated threshold for large transfers.
invalid signature rejection, mixed valid/invalid sets.
validation, state root inclusion.
wrong state root.
honest: 6 < 7 threshold).
anomaly detection trigger pause).
graceful pause and recovery).
| Metric | Target | Measurement Method | |--------|--------|--------------------| | Bridge latency (lock to mint) | < 10s | End-to-end timer | | Throughput | > 100 transfers/min | Sustained load test | | Validator signature collection | < 5s for 7-of-11 | Coordination timer | | Relayer failover | < 10s | Kill primary, measure recovery | | Merkle proof verification | < 50ms on-chain | Gas profiling | | ML-DSA-65 verification | < 10ms per sig | Precompile benchmark |
| Dependency | HIP/LP | Status | Required For | |-----------|--------|--------|-------------| | $AI Token | HIP-0001 | Draft | Native asset bridging | | Post-Quantum Security | HIP-0005 | Final | ML-DSA-65 signatures | | HMM Market Maker | HIP-0008 | Draft | Compute invoice settlement | | Hanzo Sovereign L1 | HIP-0024 | Final | Lock Vault deployment, chain ID 36963 | | Lux PQC | LP-100 | Final | ML-DSA-65 on Lux side | | Lux Cross-Chain Messaging | LP-226 | Draft | Warp message compatibility |
The fee must be:
settlement where margins are thin.
signing, key management, infrastructure).
variable; most bridges: 0.05-0.3%).
The 10% allocation to the insurance fund creates a growing reserve to cover potential bridge incidents without relying on external insurance.
Copyright and related rights waived via CC0.