Wallet Infrastructure & Custody Model

use.com's custody architecture eliminates single points of failure through Multi-Party Computation (MPC) combined with Hardware Security Modules (HSM), while maintaining operational efficiency through intelligent wallet segregation.

Multi-Party Computation (MPC) + HSM

Key Generation: Private keys are never created as complete entities. Instead, they're generated as distributed shares across 5 parties in different geographic locations.

Threshold Signing: Transactions require 3-of-5 key shares, meaning:

• No single party can sign transactions

• System remains operational if 2 parties are unavailable

• Attacker must compromise 3 separate locations + HSMs

Security Properties: $Security\_Level = P(Compromise\_3\_of\_5\_locations) \times P(Compromise\_3\_HSMs) \times P(Compromise\_3\_operators)$

With proper operational security, this probability is < 10⁻¹⁵ (effectively impossible).

Wallet Segregation Model

Cold Storage (70-80% of assets)

Purpose: Long-term secure storage

Characteristics:

• Completely offline (air-gapped)

• Geographic distribution across 5 vaults

• Quarterly rebalancing only

• Multi-signature + time-locks

• Lloyd's of London insurance coverage

Access Process:

1. Quarterly rebalancing proposal

2. Risk committee approval

3. Dual-control authorization

4. MPC signing ceremony (3-of-5)

5. Transaction broadcast

6. Confirmation monitoring

Warm Wallets (15-25% of assets)

Purpose: Batched withdrawal processing

Characteristics:

• Online but not directly connected to trading

• Automated sweeps from hot wallets

• Manual transfers to cold storage

• Policy engine with risk scoring

• Daily reconciliation

Rebalancing Logic: $Sweep\_Amount = Hot\_Balance - Target\_Hot\_Balance$

Executed every 15 minutes when hot wallet exceeds target by 20%.

Hot Wallets (2-5% of assets)

Purpose: Instant deposit credits and urgent withdrawals

Characteristics:

• Directly connected to trading system

• Automated within policy limits

• Velocity limits per user/asset

• Real-time anomaly detection

• Sub-second monitoring

Velocity Limit: $Max\_Withdrawal_{24h} = \min(User\_Tier\_Limit, Hot\_Wallet\_Balance \times 0.1)$

Withdrawal Policy Engine

Each withdrawal receives a risk score:

$Risk\_Score = w_1 \times Device\_Risk + w_2 \times Geo\_Risk + w_3 \times Velocity\_Risk + w_4 \times Behavioral\_Risk$

Where weights sum to 1.0 and are calibrated based on historical fraud patterns.

Risk Tiers:

• Low Risk (< 0.3): Automatic processing from hot wallet

• Medium Risk (0.3-0.7): Enhanced verification, warm wallet

• High Risk (≥ 0.7): Manual review + potential delay

Example Factors:

• Device Risk: New device, VPN usage, device fingerprint mismatch

• Geo Risk: New location, high-risk jurisdiction, impossible travel

• Velocity Risk: Unusual withdrawal amount, frequency spike

• Behavioral Risk: Recent password change, new address, account age

Proof-of-Reserves (PoR)

Quarterly Attestation:

$\sum OnChain\_Reserves \geq \sum User\_Liabilities + Operational\_Buffer$

Methodology:

1. Snapshot all user balances (liabilities)

2. Construct Merkle tree of balances

3. Publish Merkle root

4. Verify on-chain reserves match or exceed liabilities

5. Provide individual proof to each user

6. Publish third-party attestation report

User Verification: Each user receives a Merkle proof enabling cryptographic verification that their balance is included in the tree without revealing other users' balances.

Target: Reserve Ratio ≥ 105% (5% operational buffer)

Multi-Chain Support

use.com supports deposits and withdrawals across multiple blockchains:

Supported Chains:

• Bitcoin (native + Lightning Network)

• Ethereum (ERC-20 tokens)

• BNB Chain (BEP-20 tokens)

• Polygon, Arbitrum, Optimism (L2s)

• Solana (SPL tokens)

• Additional chains based on demand

Chain Selection: Users can deposit/withdraw via preferred chain, with automatic bridging handled internally.

Fee Optimization: System selects lowest-cost chain for withdrawals when user doesn't specify preference.

Deposit Processing

Confirmation Requirements:

Chain	Confirmations	Time
Bitcoin	3	~30 min
Ethereum	12	~3 min
BNB Chain	15	~45 sec
Polygon	128	~5 min
Solana	32	~15 sec

Instant Credit: For trusted users (Tier 3+), deposits credited instantly with risk-based limits, pending final confirmation.

Withdrawal Processing

Batching Strategy:

• Small withdrawals (< $10k): Processed every 15 minutes

• Medium withdrawals ($10k-$100k): Processed hourly

• Large withdrawals (> $100k): Manual review + batched daily

Fee Structure:

• Network Fee: Actual blockchain fee (passed through)

• Processing Fee: 0.0005 BTC or equivalent (covers operational costs)

Optimization: System batches multiple withdrawals into single transactions when possible, reducing per-user costs.

Address Whitelisting

Optional Security Feature: Users can whitelist withdrawal addresses

Benefits:

• Prevents unauthorized withdrawals to new addresses

• Reduces phishing risk

• Provides additional security layer

Activation: 24-hour delay before whitelist becomes active (prevents attacker from immediately whitelisting their address).

Operational Wallet Segregation

Critical Principle: User funds and operational funds are completely segregated.

Operational Wallets: Separate wallets for:

• Employee salaries

• Vendor payments

• Marketing expenses

• Infrastructure costs

Transparency: Monthly reporting of operational wallet balances and major transactions.

Insurance Coverage

Lloyd's of London Policy:

• Coverage: Up to $100M per incident

• Scope: Cold storage theft, internal fraud, cyber attacks

• Exclusions: Market risk, regulatory seizure, war

Self-Insurance: Insurance fund covers operational losses and liquidation shortfalls.

Disaster Recovery

Geographic Distribution: Key shares and wallet backups stored across 5 jurisdictions to prevent single-jurisdiction risk.

Recovery Scenarios:

• Single location loss: System continues operating with 4 remaining shares

• Two location loss: System continues operating with 3 remaining shares

• Three+ location loss: Disaster recovery procedures activated

Recovery Time Objective (RTO): < 24 hours for full operational restoration.

Conclusion

use.com's wallet infrastructure provides institutional-grade security through MPC + HSM key management, intelligent segregation, and comprehensive monitoring. By eliminating single points of failure while maintaining operational efficiency, the system protects user assets without sacrificing user experience.

---

Previous: ← Risk Engine & Liquidation System Next: Deposit & Withdrawal Architecture →

Related Sections:

• Security Architecture

• Core Principles & Design Philosophy