LogoLogo
WebsiteEnter AppHyperliquid
  • Unit
    • About Unit
      • Team
  • How To
    • Deposit
    • Withdraw
  • Architecture
    • Overview
    • Components
    • Security
  • Developers
    • API
      • Generate Address
        • Guardian Signatures
      • Operations
        • Deposit Lifecycle
        • Withdrawal Lifecycle
      • Withdraw Queue
    • Key Addresses
      • Mainnet
        • Bitcoin
        • Solana
        • Ethereum
      • Testnet
        • Bitcoin (Testnet)
        • Ethereum (Testnet)
        • Solana (Testnet)
          • SPL Tokens
  • FAQ
    • How do I get in touch with Unit?
    • Where's my transaction?
    • How do fees on Unit work?
    • What type of Bitcoin deposit address does Unit derive?
    • How long does a deposit/withdrawal take?
    • Are there any audits planned?
    • Is my unique deposit address permanent?
    • Can I generate multiple deposit addresses for my Hyperliquid wallet?
  • Legal
    • Regulatory Compliance
    • Terms of Service
    • Privacy Policy
Powered by GitBook
On this page
  • Protocol Security Measures
  • Consensus and Key Management
  • Communication Security
  • Build and Runtime Integrity
  • Validation Procedures
  1. Architecture

Security

Protocol components and security.

Protocol Security Measures

A deterministic state machine underlies all protocol actions, guaranteeing that transactions follow a strict, verifiable workflow. Each Guardian independently checks blockchain data, addresses, and transaction details before consenting to proceed. The network’s endpoints are rate-limited to prevent abuse, and Guardians collectively maintain circuit-breaker policies: if malicious activity is detected, the system can pause operations until issues are resolved.

Consensus and Key Management

Consensus relies on a 2-of-3 MPC threshold signature scheme (TSS), requiring a majority of Guardians to sign any critical protocol event. During distributed key generation, each Guardian receives an independent share of the private key, which remains encrypted at rest using KMS services and is only combined at runtime for signing in the secure enclaves. These enclaves keep key material isolated from the broader system, preserving confidentiality even if one Guardian’s environment is compromised.

Communication Security

All Guardian-to-Guardian transmissions are end-to-end encrypted to prevent tampering or eavesdropping. The relay server does not introduce additional cryptographic assumptions: it simply forwards ciphertext. Out-of-band ID checks authenticate Guardians to one another before any communication can begin, further reducing the risk of impersonation. If a relay server fails or is compromised, the network remains safe, since no key material resides on it.

Build and Runtime Integrity

For runtime integrity all Guardians validate configurations via hash-based checks, preventing divergence from the expected settings. Guardian's public keys are distributed and confirmed out-of-band, making it difficult for attackers to intercept or spoof critical key exchanges. Guardians perform deployments securely after manually verifying the authenticity of the version used.

Validation Procedures

Because every Guardian monitors blockchain data independently and confirms the signing of transactions, no single Guardian can stealthily subvert the system. Guardians log operations for audit, enforce consistent runtime configurations, and share authenticated status updates. This distributed validation framework—where each party operates indexers, Agents, and secure enclaves—creates multiple lines of defense, enhancing overall robustness.

PreviousComponentsNextAPI

Last updated 3 months ago