> For the complete documentation index, see [llms.txt](https://leveracc.gitbook.io/leveracc-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://leveracc.gitbook.io/leveracc-docs/basics/account-system-security-enhancement.md).

# Account System Security Enhancement

## 1. HyperLiquid Account Hierarchy

LeverAcc enhances HyperLiquid's native account structure through a multi-layered security model:

<figure><img src="/files/cTWOFWBM56081LFRFUwB" alt=""><figcaption></figcaption></figure>

**Key Relationships:**

* **Master Account**:\
  Administrative entity with limited permissions:
  * Create sub-accounts
  * Generate API wallets
  * NO asset access or transfer capabilities
* **Sub-Accounts**:\
  Isolated trading environments:
  * Contract Trading Sub-Account (Perpetuals)
  * Spot Trading Sub-Account
  * Fully controlled by user wallet
* **API Wallets**:\
  Transaction execution proxies:
  * Limited to signing pre-authorized trades
  * Cannot withdraw funds
  * Automatically expire after 24 hours

## 2. User Wallet Binding Process

Secure account integration follows a strict verification protocol:

**Step 1: Identity Verification**

1. The **user's wallet** initiates the flow by requesting a new sub-account from the **LeverAcc smart contract**.
2. The contract interacts with **HyperLiquid's MPC (Multi-Party Computation) system** to generate a dedicated sub-account address.
3. HyperLiquid returns the newly created **sub-account address** to the contract.
4. To prove ownership, the contract sends a **verification challenge** back to the user's wallet.
5. The user **signs this challenge** with their wallet's private key and submits it.
6. The contract **verifies the signature** matches the original wallet address.
7. Once confirmed, the contract instructs HyperLiquid to **permanently bind the user's main wallet** to the sub-account.

**Step 2: Dual Authorization System**\
All critical operations require:

1. User wallet signature (ownership proof)
2. API wallet signature (execution authorization)

## 3. MPC-Enhanced Master Account Security

LeverAcc implements enterprise-grade protection for administrative functions:

**Sharded Key Architecture**&#x20;

The keys are distributed into multiple network and physical place

* AWS KMS (Tokyo)
* Azure Key Vault (Frankfurt)
* Google Cloud HSM (Iowa)
* Physical HSM (Singapore)
* User Cold Storage

**Operational Workflow**

1. **Signature Request Initiation**
   * User triggers account management action
   * System generates signature payload
2. **Distributed Shard Activation**

<figure><img src="/files/7XhGgL5hK2BlxtpeTRu2" alt=""><figcaption></figcaption></figure>

1. **Signature Reconstruction**
   * Combines shards via Lagrange interpolation
   * Validates complete signature
   * Executes authorized action
   * Immediately discards combined key

#### Security Enhancements Matrix

| Feature            | Traditional Model   | LeverAcc Enhanced      | Security Improvement               |
| ------------------ | ------------------- | ---------------------- | ---------------------------------- |
| **Key Storage**    | Single server       | 5-region sharding      | Eliminates single point of failure |
| **Authorization**  | API keys            | Dual-signature binding | Requires active user consent       |
| **Access Control** | Permanent tokens    | 24-hour API wallets    | Limits exposure window             |
| **Recovery**       | Manual intervention | MPC shard rotation     | Automated key regeneration         |
| **Auditability**   | Limited logs        | Full on-chain records  | Transparent operation history      |

#### Protection Mechanisms

1. **Time-Limited API Wallets**
   * Automatic expiration every 24 hours
   * Requires user reauthorization
   * Historical wallets become cryptographically inert
2. **Geographic Dispersion**
   * Key shards stored across 3 continents
   * Jurisdictional redundancy prevents regulatory seizure
3. **Action-Specific Permissions**

   | Operation           | Required Signatures |
   | ------------------- | ------------------- |
   | Create Sub-Account  | 3/5 MPC shards      |
   | Generate API Wallet | User + 2/5 MPC      |
   | Trade Execution     | API Wallet only     |
   | Withdraw Funds      | User wallet only    |
4. **Compromise Response Protocol**
   1. **Breach Detected：**&#x53;ystem identifies unauthorized access attempts or signature anomalies.
   2. **Shard Invalidation：**&#x43;ompromised shards (AWS/Azure/Google HSM nodes) are instantly revoked via broadcast.
   3. **New Shard Generation：**&#x4D;PC network regenerates fresh shards using distributed key generation (DKG).
   4. **User Re-Authentication：**&#x4F;wner must verify identity via MFA + cold storage signature.
   5. **Seamless Migration：**&#x41;ssets/contracts transfer to new shards with zero downtime.
   6. **Forensics & Patch：**&#x41;ttack vector analyzed using HSM/blockchain logs; security patches deployed.

#### Real-World Attack Mitigation

**Scenario: Exchange Hot Wallet Compromise**

* Attacker gains access to exchange systems
* Attempts to drain LeverAcc-connected accounts

**Defense Response:**

1. API wallets contain no withdrawal permissions
2. User funds secured in MPC-controlled sub-accounts
3. Withdrawal requires user's personal wallet signature
4. Unauthorized transfer attempts automatically blocked

**Result:** Zero funds lost despite exchange-level breach

This security architecture creates unprecedented protection: Users maintain complete control of their assets through personal wallet binding, while administrative functions benefit from military-grade MPC protection. The system ensures that even if multiple components are compromised, attackers cannot access funds or execute unauthorized actions.