Authentication
Multi-chain signature verification and replay protection
Authentication Overview
Wallet Abstraction
Users are identified by their wallet address as a (Chain, Address) tuple:
(Bitcoin, "bc1q...")(Ethereum, "0x...")(Solana, "7Np4...")
Principal Derivation
A deterministic principal is derived from the wallet:
Principal = SHA224(chain:address) + 0x02
This creates a unique, verifiable identity for each wallet.
Signature Verification
Chain | Standard | Description |
|---|---|---|
Bitcoin | BIP322 | Message signing standard, supports P2WPKH, P2TR, P2PKH, P2SH-P2WPKH |
Ethereum | EIP-191 | personal_sign standard with prefix, recovers signer address |
Solana | Ed25519 | Direct signature verification against public key |
Message Format
Signed requests include:
- data: Operation-specific data
- signature: Wallet signature
- account: User's account identifier
- chain: Bitcoin, Ethereum, or Solana
The message to sign includes:
- Current nonce (replay protection)
- Request data (operation-specific)
- Timestamp (optional freshness check)
Replay Protection
Nonce System
Each account has an incrementing nonce. The provided nonce must match the expected value, and is incremented after each successful request.
Properties
- Monotonic: Nonces only increase
- Per-account: Each account has its own nonce
- Atomic increment: Nonce incremented with operation
Account Initialization
New accounts are initialized with a challenge-response flow:
- User calls
initialize_account(chain, address) - Protocol generates random nonce and returns challenge message
- User signs challenge with their wallet
- User submits signature to
complete_initialization - Protocol verifies signature and creates account
Multi-Wallet Profiles
Users can link multiple wallets to a single profile:
Benefits:
- Unified positions across wallets
- Deposit from Bitcoin, withdraw to Ethereum
- Single health factor for all collateral
Authorization Checks
Context | Verification |
|---|---|
User Operations | Signature verification + account ownership + nonce increment |
Inter-Canister Calls | Caller must be the lending canister |
Admin Operations | Caller must have admin privileges |
Security Properties
Property | Mechanism |
|---|---|
Authentication | Cryptographic signature verification |
Non-repudiation | Only private key holder can sign |
Replay protection | Incrementing nonce per account |
Freshness | Nonce must match expected value |
Authorization | Profile ownership verification |
Users can interact with Liquidium using their existing wallets. No new keys or accounts needed - just sign with Bitcoin, Ethereum, or Solana.