# 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://leveracc.gitbook.io/leveracc-docs/basics/account-system-security-enhancement.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.