Articles on: Whitepaperchevron-right

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)×P(Compromise_3_HSMs)×P(Compromise_3_operators)Security_Level = P(Compromise_3_of_5_locations) \times P(Compromise_3_HSMs) \times P(Compromise_3_operators)Security_Level=P(Compromise_3_of_5_locations)×P(Compromise_3_HSMs)×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_BalanceSweep_Amount = Hot_Balance - Target_Hot_BalanceSweep_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_Withdrawal24h=min⁡(User_Tier_Limit,Hot_Wallet_Balance×0.1)Max_Withdrawal_{24h} = \min(User_Tier_Limit, Hot_Wallet_Balance \times 0.1)Max_Withdrawal24h​=min(User_Tier_Limit,Hot_Wallet_Balance×0.1)


Withdrawal Policy Engine


Each withdrawal receives a risk score:


Risk_Score=w1×Device_Risk+w2×Geo_Risk+w3×Velocity_Risk+w4×Behavioral_RiskRisk_Score = w_1 \times Device_Risk + w_2 \times Geo_Risk + w_3 \times Velocity_Risk + w_4 \times Behavioral_RiskRisk_Score=w1​×Device_Risk+w2​×Geo_Risk+w3​×Velocity_Risk+w4​×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:


∑OnChain_Reserves≥∑User_Liabilities+Operational_Buffer\sum OnChain_Reserves \geq \sum User_Liabilities + Operational_Buffer∑OnChain_Reserves≥∑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:


Updated on: 10/03/2026

Was this article helpful?

Share your feedback

Cancel

Thank you!