LP-41: Wallet Standards

Abstract

Defines interfaces and guidance for Lux wallet interoperability across chains and dApps.

Motivation

Consistent wallet behavior and interfaces reduce integration friction, improve UX, and enhance security across the ecosystem.

Specification

This LP's normative content is the set of algorithms, data models, and parameters described herein. Implementations MUST follow those details for interoperability.

Key Derivation (BIP-39 / BIP-32 / BIP-44)

Lux wallets derive all keys hierarchically from a single BIP-39 mnemonic (BIP-32 master seed). Derivation follows BIP-44:

m / purpose' / coin_type' / account' / change / address_index

purpose' is always 44'. The coin_type selects the address family and is the only level that differs between the EVM and UTXO chains:

Chain(s)	Address family	coin_type	Canonical path	Curve	Address encoding
C-Chain	EVM (Ethereum-compatible)	`60'`	`m/44'/60'/0'/0/i`	secp256k1	`keccak256(pubkey)[12:]` → `0x…` (20 bytes)
X-Chain, P-Chain	UTXO (Avalanche-lineage)	`9000'`	`m/44'/9000'/0'/0/i`	secp256k1	`ripemd160(sha256(pubkey))` → bech32 with chain HRP

coin_type 60' is Ethereum's SLIP-44 registration. The C-Chain is an EVM chain, so it reuses Ethereum's path and address scheme verbatim — a MetaMask/Ledger-style wallet addresses the C-Chain with the exact path it uses for Ethereum mainnet.
coin_type 9000' is the SLIP-44 registration inherited from the Avalanche UTXO lineage the X/P-Chains descend from. It is retained for hardware/wallet compatibility (Ledger, Trezor, Core). The X- and P-Chains share the same key but render different bech32 strings via their human-readable prefix (HRP).

9000 = UTXO, 60 = EVM. These are not interchangeable. 9000' is the Avalanche/Lux UTXO family (X, P); 60' is the Ethereum/EVM family (C). A wallet that funds the C-Chain at m/44'/9000'/… or the X/P-Chain at m/44'/60'/… is non-conformant.

Address encoding per chain

The same private key produces a different address on each family:

C-Chain: 0x + last 20 bytes of keccak256(uncompressed_pubkey).
X-Chain: X- + bech32(hrp, ripemd160(sha256(compressed_pubkey))).
P-Chain: P- + bech32(hrp, ripemd160(sha256(compressed_pubkey))).

The hrp (human-readable part) is network-scoped:

Network	networkID	HRP	Example X-Chain address
mainnet	1	`lux`	`X-lux1…`
testnet	2	`test`	`X-test1…`
devnet	3	`dev`	`X-dev1…`
localnet	1337	`local`	`X-local1…`

So address_index 0 of one mnemonic yields, e.g., 0xAbc… (C), X-lux1… (X), and P-lux1… (P) — the X and P strings share the same underlying UTXO key (…/9000'/…); the C string is a distinct EVM key (…/60'/…).

Denomination

Amounts on the UTXO chains (X, P) are 6 decimals (microLUX base, uint64); the C-Chain is 18 decimals (wei, uint256). Wallets MUST display and convert balances accordingly. The normative denomination spec is LP-1 §Denominations.

Post-quantum accounts

The PQ account type (LP-172 / HIP-0085) keeps the UTXO coin_type (9000') but pins account' to the network ID: m/44'/9000'/nid'/0/n, deriving an ML-DSA-65 account under the LUX_STRICT_PQ profile. Classical and PQ accounts therefore never collide in the tree.

Implementation

Wallet Standard Contracts

Location: ~/work/lux/standard/src/wallets/ (~/work/lux/standard/contracts/wallets)

Primary Wallet Interfaces:

ILuxWallet.sol - Base wallet interface
IMultiChainWallet.sol - Cross-chain wallet support
IWalletFactory.sol - Wallet deployment factory

Testing:

cd ~/work/lux/standard
forge test --match-contract WalletTest
forge coverage --match-contract Wallet

Rationale

Design choices favor simplicity and reliability while meeting Lux performance and ecosystem requirements.

Backwards Compatibility

Additive change; existing APIs and formats remain valid. Adoption is opt-in.

Security Considerations

Consider typical threat models (input validation, replay/DoS resistance, key handling). Apply recommended safeguards outlined in the text:

Strict input validation for all external calls
Replay protection via nonces and chain IDs
Secure key derivation using BIP-39/BIP-44 standards
Hardware wallet support via standard signing interfaces

Test Cases

Unit Tests

Component Initialization
- Verify correct initialization of all components
- Test configuration validation
- Validate error handling for invalid configurations
Core Functionality
- Test primary operations under normal conditions
- Verify expected outputs for standard inputs
- Test edge cases and boundary conditions
Error Handling
- Verify graceful handling of invalid inputs
- Test recovery from transient failures
- Validate error messages and codes

Integration Tests

Cross-Component Integration
- Test interaction between related components
- Verify data flow across module boundaries
- Validate state consistency
Performance Tests
- Benchmark critical operations
- Verify performance under load
- Test resource utilization limits

Wallet Standards